From nobody Tue Mar 1 01:20:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D10EB1B368A for ; Tue, 1 Mar 2016 01:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Chw9GIId5q3d for ; Tue, 1 Mar 2016 01:20:39 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF9E1B3689 for ; Tue, 1 Mar 2016 01:20:39 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id 9so212602824iom.1 for ; Tue, 01 Mar 2016 01:20:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=KXpRa3OUSvXFjdJrC18JeM4JozXFw+1GNr6A0CJBuA8=; b=ECiFH0CsoPtorX5gHdiBnFjmOQt/TmepSmMxB2JenZj3Jy2T0IKaPyCMZSZU0AiAuN O18xE//1tk/tpxoQVgzogIAgAChrtfHtLIjVQJG+Q8GeXXZjHHH/nawLIJ1kfPXGzeU9 9aacFvdWaVbrcaXepiNQcS2VcTsCBrCIoh/08JzXIWqN48kGFDmMdmNoWwXFRHTZboLG bFe6MPbhCoKBKas0ycUyWq/Cxth8d72uWG7UdCYEYqxNq+t5KipsbtF/dTyETZD31nf+ ySbqKzRpysmRKFSpwNvWV0fJLK3bhw39lUNSxTI6FA3UTwZpY6l5zqztosGOTZAh9umE G7gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=KXpRa3OUSvXFjdJrC18JeM4JozXFw+1GNr6A0CJBuA8=; b=J0cpxC0D0CvkS3OOqmfggk8jt1JlDfZ7F66bwyC75zglK6L1imOBLOStQP9m05L1Dk S8XZLJ8cTsfHezUvV9dGEJW23N82aCM0XgfLyTD1AFJcQEp5kd975o0hxoNSOMqdk30O BOiurdyKa9w5s6pzlUgrjbHcQWuqmgUx+6AqAKxAnNO0Ydcix1ZCBu72dK26gXoIiqh8 9O7x64+FwlpsGM+yEiC8JENh20KDAAnDPUmzGDFshRvLcVC4n4Lw6c9r8g99RjUAwm04 XEZO7yhtfE6EPBKTEworN9FkCU6biGpNktU2HLo9lKWxDkPrA7JS6xj/bs1wVSQ1W1by jB2Q== X-Gm-Message-State: AG10YOQjylRLLjeX1XICFt8V/iUbsAcFB4Mx9rblE49k2qfSeUT5hwxdw9hhI7j7Fmlu6b9RHCnD8aSPbbQCyA== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr24710001iop.100.1456824038943; Tue, 01 Mar 2016 01:20:38 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 1 Mar 2016 01:20:38 -0800 (PST) In-Reply-To: <20160301050647.GW12869@mournblade.imrryr.org> References: <20160301045947.GV12869@mournblade.imrryr.org> <20160301050647.GW12869@mournblade.imrryr.org> Date: Tue, 1 Mar 2016 20:20:38 +1100 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 09:20:41 -0000 On 1 March 2016 at 16:06, Viktor Dukhovni wrote: >> It is much easier to mandate PSS in TLS 1.3 now, than to remove it >> later. Servers that can't do PSS will use TLS 1.2. This avoids >> a break-the-web day. > > Sorry, ... than to remove *PKCS#1.5* later ... Yes, this is true for some people, and likely it will be more true in the future. However, a MUST implement PSS is enough for me. If it seems like consensus is against this position, I'll back that all the way. However, on the web side of things, we've some experience with killing stuff that we don't like. It's not always painless (see SHA-1), but I'd rather rely on that system than risk holding back 1.3. From nobody Tue Mar 1 02:02:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA19A1B3C85 for ; Tue, 1 Mar 2016 02:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.907 X-Spam-Level: X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFU6fq1yOWez for ; Tue, 1 Mar 2016 02:02:14 -0800 (PST) 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 733291B3CAC for ; Tue, 1 Mar 2016 02:02:14 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 2E20D7F6A2; Tue, 1 Mar 2016 10:02:14 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.188]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u21A2AO1030731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 1 Mar 2016 05:02:12 -0500 Message-ID: <1456826530.3417.31.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Joseph Salowey , "tls@ietf.org" Date: Tue, 01 Mar 2016 11:02:10 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 10:02:16 -0000 On Mon, 2016-02-29 at 09:32 -0800, Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from > PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take > some hardware implementations some time to move to RSA-PSS.  After an > off list discussion with a few folks here is a proposal for moving > forward.   > > We make RSA-PSS mandatory to implement (MUST implement instead of > MUST offer).   Clients can advertise support for PKCS-1.5 for > backwards compatibility in the transition period.    > Please respond on the list on whether you think this is a reasonable > way forward or not.   The mandatory to implement approach didn't help TLS 1.0 (which had a DHE-RSA ciphersuite implemented by no-one for several years). If you want to push for RSA-PSS, then please only define RSA-PSS. That, in addition would allow to prevent that sharing of keys between TLS 1.2 and TLS 1.3 (i.e., prevent any cross-protocol attacks). regards, Nikos From nobody Tue Mar 1 03:32:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4A01A1A70 for ; Tue, 1 Mar 2016 03:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUQ4ZoDbcTLx for ; Tue, 1 Mar 2016 03:32:24 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB211A1A6E for ; Tue, 1 Mar 2016 03:32:24 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id n186so31979130wmn.1 for ; Tue, 01 Mar 2016 03:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AlDNcPBETBXSCpUmdS+Y4gBgWCi+1A6cy+sRYhNjyDE=; b=BaJRIpyJeLhei/9GLcnzFQeAoRG2oFcRmG/8JShMweFYvF/eL+h+Hd8eZQk0b/HmOu qAN6mW8jYgY9oPs0X9Fg+OGwIPP3LGoENSrNL4Iws46C1TAu/q/9gpZ2swd46IHOlsyB AmY9Wj4i96aBvRJkzUVp3wVbAHTcxEiUpXpiPg7ocFZwsYI+y1SfvbgIXwKe0satGAqG Qbzrf5wexNZfe5/Q84dPKsG/KnFYkpYEfPVhjFfl23S7ADnvrtqf1BeGn1oCknS3fGTx zdxPC94ZpeK0QEPwseLgp8VHQVZbgenvpu2iKVj3lWZ0D6aMsMWvoQaY6qQjzZdZuWMU xX+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=AlDNcPBETBXSCpUmdS+Y4gBgWCi+1A6cy+sRYhNjyDE=; b=MWNzd1M7n5vSfRK/xHLMSYlHIVMXBGXSs+TpdB1najOf6rK7ipemKppd83Jeh1nj3F Daqq8doAFMXvNNfgMXhwTk4z1R/QSIJPl5wt0tuQJR1TmkIAj3XpDUq7cOzoxIKG3r3B eb2XmYr+2V+4aZKtvv7wjhSW5rE9BA0joGrvmKvZeDikrq58HFkDzstwdWvzvsrADmyc 1zowHG8YOHvihGpb1+ycsFPzFVQ/cLaEyj7K4Y1993FcHBLjORx3tV0lZmj9jsTSyOo0 r+W7BAsTwE0nHqj4VoTaQ2fB749KK/7F3uEFuPMZNSHio+RR5oy96IorfLw1+2jwlzb2 wtIA== X-Gm-Message-State: AD7BkJKgXuvE5+v5Z9kh1n14FecSV+/VArLB8jojd2j36WJjFx5/ojIeStyeNclKjAn0Ng== X-Received: by 10.28.175.139 with SMTP id y133mr3008831wme.45.1456831942768; Tue, 01 Mar 2016 03:32:22 -0800 (PST) Received: from [172.24.251.185] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id da6sm20975778wjb.24.2016.03.01.03.32.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 03:32:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Tue, 1 Mar 2016 13:32:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 11:32:26 -0000 > On 1 Mar 2016, at 6:56 AM, Martin Thomson = wrote: >=20 > On 1 March 2016 at 04:32, Joseph Salowey wrote: >> We make RSA-PSS mandatory to implement (MUST implement instead of = MUST >> offer). Clients can advertise support for PKCS-1.5 for backwards >> compatibility in the transition period. >=20 >> =46rom my perspective, this is fine. I would like to say that we = won't > ever support PKCS#1.5 for TLS 1.3, but I think that I would rather > have users on 1.3 with PKCS#1.5 than have them stuck on 1.2. >=20 > It seems like others are taking the position that we should say "MUST > NOT use PKCS#1.5=E2=80=9D. =20 I=E2=80=99d go even further. I=E2=80=99d remove the rsapss(4) value from = SignatureAlgorithm, leaving just rsa(1), and say that in TLS 1.3 an RSA = signature is PSS just as it was PKCS#1.5 in TLS 1.2. Certificates are a different issue altogether. Yoav From nobody Tue Mar 1 03:35:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42411A1B24 for ; Tue, 1 Mar 2016 03:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy0Iiis7KJfw for ; Tue, 1 Mar 2016 03:35:31 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59D61A1B1E for ; Tue, 1 Mar 2016 03:35:30 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id l68so31152631wml.0 for ; Tue, 01 Mar 2016 03:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aIh4+k+f9UodfCkMKXesweojuOFsDOMDIwJdL9JIBzM=; b=PqS3AnSGYBepCoyIMTCwlgEaPzcWsThJIBi+1yY6Pk1N9vC+lRoYAy/QVeoHknApZN tY3iYn0A4PpMR+gGqyYsjktyD9LaA0/QWAMOtmV3gHG2IL2mDv1f3QUSv2XxeBUKxHx9 MtmSXhbhZK9W1tb0CzZAO4sOMsLQhFL4AoJbHs02zYKnVt4h7Ed59R4FmRQLBdOQM6g1 wlaJiYORkx+RmlpR2eEMcrxIP7GcsJF20YLedHEc9dLIMWB+TjGEe5e5Fyvyzx4ZWlOC OTgFuc4Pz7dzcWSpyuStCH9psAWW5MJ7/Yb9ZQhXFnCtmNjFRVucJ9+VgOaUYjPenQtp YWmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aIh4+k+f9UodfCkMKXesweojuOFsDOMDIwJdL9JIBzM=; b=K7lozoPOO87jvqR0aO4iMrKeDtjOwGTB8zH5ObmGcphj2VKu/8AIgT+vJEu6kf6NtE +VBaN39g+5+nKhhiPcbiOdQkv/bOpYyl+Z2A6wTQpm0Ad+3L81jLfzK7g4KvYnWT33g7 FJ+NfhKSNlA+FAdudeflZ0ug2sHTCLrR67gL9u03BRpnt/XCoKt9x0Df1qEArOrQNhem /zGFr2jeKBZeB/LxoTZQVJODCEwTg5qevXyX28nCEnFA66kgDJN+rYEsURLN2sVS3XUd bawKiLiLEa21fWUKW1dpixjtCahbl16viL9KXama7WIG5J1vAe6dYThwpq1Up2T68o11 wnsw== X-Gm-Message-State: AD7BkJIYeSftagDdomSinItD5VkpjlS03bjd15H1NTofDWlZfv2tP1GNTL9mjburAi8H0w== X-Received: by 10.194.63.242 with SMTP id j18mr23589259wjs.114.1456832129314; Tue, 01 Mar 2016 03:35:29 -0800 (PST) Received: from [172.24.251.185] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id w136sm20848622wmw.0.2016.03.01.03.35.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 03:35:28 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <56D51FFB.9050909@brainhub.org> Date: Tue, 1 Mar 2016 13:35:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 11:35:32 -0000 > On 1 Mar 2016, at 6:52 AM, Andrey Jivsov wrote: >=20 > On 02/29/2016 02:36 PM, Hanno B=F6ck wrote: >> We have an RFC for PSS since 2003. >> We had several attacks showing the weakness of PKCS #1 1.5. >=20 > In the face of such danger, what's your opinion on PKCS #1.5 = signatures being perfectly fine in TLS 1.3 ? I refer to signatures in = X.509 certs in the latest = https://tools.ietf.org/html/draft-ietf-tls-tls13-11. >=20 > Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make = TLS 1.3 more secure, but code simpler and footprint smaller. Besides, = it's reasonable: TLS 1.2 already allows PSS in X.509 It would be cool to ban PKCS#1.5 from certificates, but we are not the = PKIX working group. Nor are we the CA/Browser forum. When a CA issues a = certificate it has to work with every client and server out there, When = we use TLS 1.3, the other side supports TLS 1.3 as well, so it=92s fair = to assume that it knows PSS. Yoav From nobody Tue Mar 1 10:23:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EA91B34EB for ; Tue, 1 Mar 2016 10:23:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCmlFyw5YgFy for ; Tue, 1 Mar 2016 10:23:23 -0800 (PST) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4119B1B3434 for ; Tue, 1 Mar 2016 10:23:22 -0800 (PST) To: tls@ietf.org References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> From: Alyssa Rowan Message-ID: <56D5DE1D.3000708@akr.io> Date: Tue, 1 Mar 2016 18:23:25 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 18:23:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2016-03-01 11:35, Yoav Nir wrote: >>> [HB] We have an RFC for PSS since 2003. We had several attacks >>> showing the weakness of PKCS #1 1.5. And so (maybe not entirely coincidentally!): another attack, dubbed DROWN, just emerged¹, using SSLv2 as - you guessed it - a Bleichenbacher padding oracle against RSA PKCS#1 v1.5! (Please do stop me if you've heard this one before! ) >> [AJ] Why not ban PKCS #1.5 altogether from TLS 1.3? It will not >> only make TLS 1.3 more secure, but code simpler and footprint >> smaller. Besides, it's reasonable: TLS 1.2 already allows PSS in >> X.509 A very strong +1 as far as I'm concerned. > [YN] It would be cool to ban PKCS#1.5 from certificates, but we > are not the PKIX working group. Nor are we the CA/Browser forum. > When a CA issues a certificate it has to work with every client > and server out there, When we use TLS 1.3, the other side supports > TLS 1.3 as well, so it’s fair to assume that it knows PSS. Perhaps the PKIX working group and CAB/Forum could both use a friendly reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains? ___ [1] - -- /akr -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW1d4SAAoJEOyEjtkWi2t6kIQP/2Ziaeu2RGqHqV1Oa6dB0+Go iPbrrHe9C7l7yHxWfhur6ldGUnqAKyzhD5X0RHby0lbpXTcBFQjWPQ3shZE8CUV2 mM4N2UyoAu5w1kOkSvHImeWrtdOPDTBTZhwFJjzEHtLkri6+CXzKE82B94WfhX8/ ddQxg9uaV7eDEcW4um+vn0NG/+IuiJvfVTX7YtNj0yVSvEO7bm6/WRHsWV0FaQ+C HtNawk+KP966PLUPH1N6vBvhNpiZkMtv3QUsKbzAQDn8SPfXHWGy2CBxPLjtIv2w dTmY9dOxJsc7KswtM7DJQqx7azgeGAlLc8MV1PyXw1fIq2qtVI4Fk1+DNrMteC5B cNkez/nPwR01FFj3QV5OnbpcqIX1v9nmGrpDuFw+99xcMjgRrSRc3boclV8/H0PA k8XllkgmXj75TkqSkPV1YXVwOJAT65Uwke7tKHf4TwXSwz+qZVji+y8ZqZ7ACs2/ Pp3IrlNLuJUmFjE+p8zhhEQU6fQjEdkAxT/3KY8/1nKxlXByFVHu1p1jZk7aWBtw aSEDLCI4XKKAJ118yXRtHXxA7LGNujsBYCoSp1A4Rkce57Ea7iuVd4pmctbMgiTA g3UAb7cE4NflzRyQd1Gbycu6wenovj9bOD4HRdTuADRdfGpXv8HMEG+eOUuE7DHx Af4y+IDpfW7HTraWjiKX =iX03 -----END PGP SIGNATURE----- From nobody Tue Mar 1 10:26:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45E71B37D8 for ; Tue, 1 Mar 2016 10:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13tFwiZWYiHK for ; Tue, 1 Mar 2016 10:26:45 -0800 (PST) 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 79CCB1B34C1 for ; Tue, 1 Mar 2016 10:26:37 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id e185so176686410vkb.1 for ; Tue, 01 Mar 2016 10:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vQXkITl3Qd3tyu01tbT+zAJ3EnvKax3e7qj++B5OeEs=; b=RPd32DLrj6eu7SL15wu/tlI5cB6iu9WxDSt5l1rF59sTBQl+c3ut7WIDGVQLYXwThA e7tk6ReqgUdBXTnwB1qy8gQnHQ2bYMryWlLfFnO825GrFsJ3CEIfP0TplzgJqtA1GEMq u02UjTOJySRJOGR61/lA7h1mtchMT11m+x54fNJH/I/icuSRlcD1rz4dsH8fZNWitnai +DoNHZomWKPLJsnbpoyNqxdysDS2ITIugQSZNdlY//TC908pCNR5k5ShdBapMMN1wEUN kGx4T3CiixW56rlFeH8YrKgc9ChDcGEls3nzAUQcAHiMN5yfbtObsjBfWuXRUmX40Nte Ae3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vQXkITl3Qd3tyu01tbT+zAJ3EnvKax3e7qj++B5OeEs=; b=YGjegcRZP8cgOUerjBLIpAh6zY5gPEZM8zUKI2THRdMfIKtPxXtUri/ldqdlfU5twb rM69IxDnathhUZsp+1qJUK1PuirD3KfU8iCXV+FbXZEGfIkYH2ub4JtAGTc5D6VRTGI5 44PNaD/2rbc3scQk7TD+eDLnQo7CV+u0ZWcSoorrNOeTPbtlFm4Yq9HoKLUH2ZqwBNyj +DnCjDytzalSRgvtnVpucJeXm1PETRf/sgCOMFqCSRNjev0ekBxP/mxy788zTHXNCQNg /grFAYtN/IAJ4MEglctdLYLAyYdMuyheIH9/F9aHMvRDL24jlqI9KRBnhKGTKd6W/719 mo1w== X-Gm-Message-State: AD7BkJKwm/iFj0kx6cTw8w1QHmaVpytA8tFN1eAkLG6YF9DVnHTM4nBfDdUxIkfqyZS/3AU5FwBJRdVndeV/Jg== MIME-Version: 1.0 X-Received: by 10.31.162.3 with SMTP id l3mr17088284vke.68.1456856796517; Tue, 01 Mar 2016 10:26:36 -0800 (PST) Received: by 10.176.1.183 with HTTP; Tue, 1 Mar 2016 10:26:35 -0800 (PST) Received: by 10.176.1.183 with HTTP; Tue, 1 Mar 2016 10:26:35 -0800 (PST) In-Reply-To: <56D5DE1D.3000708@akr.io> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> Date: Tue, 1 Mar 2016 10:26:35 -0800 Message-ID: From: Watson Ladd To: Alyssa Rowan Content-Type: multipart/alternative; boundary=001a114406ead85b6f052d00e7ba Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 18:26:46 -0000 --001a114406ead85b6f052d00e7ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mar 1, 2016 10:23 AM, "Alyssa Rowan" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 2016-03-01 11:35, Yoav Nir wrote: > > >>> [HB] We have an RFC for PSS since 2003. We had several attacks > >>> showing the weakness of PKCS #1 1.5. > > And so (maybe not entirely coincidentally!): another attack, dubbed > DROWN, just emerged=C2=B9, using SSLv2 as - you guessed it - a > Bleichenbacher padding oracle against RSA PKCS#1 v1.5! PSS doesn't help against Bleichenbacher attacks on encryption. The attack still can compute a private key operation. What we really need is key seperation or use of ECC certs only. > > (Please do stop me if you've heard this one before! ) > > >> [AJ] Why not ban PKCS #1.5 altogether from TLS 1.3? It will not > >> only make TLS 1.3 more secure, but code simpler and footprint > >> smaller. Besides, it's reasonable: TLS 1.2 already allows PSS in > >> X.509 > > A very strong +1 as far as I'm concerned. > > > [YN] It would be cool to ban PKCS#1.5 from certificates, but we > > are not the PKIX working group. Nor are we the CA/Browser forum. > > When a CA issues a certificate it has to work with every client > > and server out there, When we use TLS 1.3, the other side supports > > TLS 1.3 as well, so it=E2=80=99s fair to assume that it knows PSS. > > Perhaps the PKIX working group and CAB/Forum could both use a friendly > reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains? > ___ > [1] > > - -- > /akr > -----BEGIN PGP SIGNATURE----- > > iQIcBAEBCgAGBQJW1d4SAAoJEOyEjtkWi2t6kIQP/2Ziaeu2RGqHqV1Oa6dB0+Go > iPbrrHe9C7l7yHxWfhur6ldGUnqAKyzhD5X0RHby0lbpXTcBFQjWPQ3shZE8CUV2 > mM4N2UyoAu5w1kOkSvHImeWrtdOPDTBTZhwFJjzEHtLkri6+CXzKE82B94WfhX8/ > ddQxg9uaV7eDEcW4um+vn0NG/+IuiJvfVTX7YtNj0yVSvEO7bm6/WRHsWV0FaQ+C > HtNawk+KP966PLUPH1N6vBvhNpiZkMtv3QUsKbzAQDn8SPfXHWGy2CBxPLjtIv2w > dTmY9dOxJsc7KswtM7DJQqx7azgeGAlLc8MV1PyXw1fIq2qtVI4Fk1+DNrMteC5B > cNkez/nPwR01FFj3QV5OnbpcqIX1v9nmGrpDuFw+99xcMjgRrSRc3boclV8/H0PA > k8XllkgmXj75TkqSkPV1YXVwOJAT65Uwke7tKHf4TwXSwz+qZVji+y8ZqZ7ACs2/ > Pp3IrlNLuJUmFjE+p8zhhEQU6fQjEdkAxT/3KY8/1nKxlXByFVHu1p1jZk7aWBtw > aSEDLCI4XKKAJ118yXRtHXxA7LGNujsBYCoSp1A4Rkce57Ea7iuVd4pmctbMgiTA > g3UAb7cE4NflzRyQd1Gbycu6wenovj9bOD4HRdTuADRdfGpXv8HMEG+eOUuE7DHx > Af4y+IDpfW7HTraWjiKX > =3DiX03 > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a114406ead85b6f052d00e7ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 1, 2016 10:23 AM, "Alyssa Rowan" <akr@akr.io> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 2016-03-01 11:35, Yoav Nir wrote:
>
> >>> [HB] We have an RFC for PSS since 2003. We had several at= tacks
> >>> showing the weakness of PKCS #1 1.5.
>
> And so (maybe not entirely coincidentally!): another attack, dubbed > DROWN, just emerged=C2=B9, using SSLv2 as - you guessed it - a
> Bleichenbacher padding oracle against RSA PKCS#1 v1.5!

PSS doesn't help against Bleichenbacher attacks on encry= ption. The attack still can compute a private key operation.

What we really need is key seperation or use of ECC certs on= ly.

>
> (Please do stop me if you've heard this one before! <g>)
>
> >> [AJ] Why not ban PKCS #1.5 altogether from TLS 1.3? It will n= ot
> >> only make TLS 1.3 more secure, but code simpler and footprint=
> >> smaller. Besides, it's reasonable: TLS 1.2 already allows= PSS in
> >> X.509
>
> A very strong +1 as far as I'm concerned.
>
> > [YN] It would be cool to ban PKCS#1.5 from certificates, but we > > are not the PKIX working group. Nor are we the CA/Browser forum.<= br> > > When a CA issues a certificate it has to work with every client > > and server out there, When we use TLS 1.3, the other side support= s
> > TLS 1.3 as well, so it=E2=80=99s fair to assume that it knows PSS= .
>
> Perhaps the PKIX working group and CAB/Forum could both use a friendly=
> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remain= s?
> ___
> [1] <htt= ps://drownattack.com/drown-attack-paper.pdf>
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJW1d4SAAoJEOyEjtkWi2t6kIQP/2Ziaeu2RGqHqV1Oa6dB0+Go
> iPbrrHe9C7l7yHxWfhur6ldGUnqAKyzhD5X0RHby0lbpXTcBFQjWPQ3shZE8CUV2
> mM4N2UyoAu5w1kOkSvHImeWrtdOPDTBTZhwFJjzEHtLkri6+CXzKE82B94WfhX8/
> ddQxg9uaV7eDEcW4um+vn0NG/+IuiJvfVTX7YtNj0yVSvEO7bm6/WRHsWV0FaQ+C
> HtNawk+KP966PLUPH1N6vBvhNpiZkMtv3QUsKbzAQDn8SPfXHWGy2CBxPLjtIv2w
> dTmY9dOxJsc7KswtM7DJQqx7azgeGAlLc8MV1PyXw1fIq2qtVI4Fk1+DNrMteC5B
> cNkez/nPwR01FFj3QV5OnbpcqIX1v9nmGrpDuFw+99xcMjgRrSRc3boclV8/H0PA
> k8XllkgmXj75TkqSkPV1YXVwOJAT65Uwke7tKHf4TwXSwz+qZVji+y8ZqZ7ACs2/
> Pp3IrlNLuJUmFjE+p8zhhEQU6fQjEdkAxT/3KY8/1nKxlXByFVHu1p1jZk7aWBtw
> aSEDLCI4XKKAJ118yXRtHXxA7LGNujsBYCoSp1A4Rkce57Ea7iuVd4pmctbMgiTA
> g3UAb7cE4NflzRyQd1Gbycu6wenovj9bOD4HRdTuADRdfGpXv8HMEG+eOUuE7DHx
> Af4y+IDpfW7HTraWjiKX
> =3DiX03
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a114406ead85b6f052d00e7ba-- From nobody Tue Mar 1 10:38:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFC21B3F98 for ; Tue, 1 Mar 2016 10:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qt_N6Dt5uETF for ; Tue, 1 Mar 2016 10:38:18 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43B641B3F94 for ; Tue, 1 Mar 2016 10:38:18 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1CDF0284AED; Tue, 1 Mar 2016 18:38:17 +0000 (UTC) Date: Tue, 1 Mar 2016 18:38:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160301183816.GH12869@mournblade.imrryr.org> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 01 Mar 2016 18:38:20 -0000 On Tue, Mar 01, 2016 at 10:26:35AM -0800, Watson Ladd wrote: > > And so (maybe not entirely coincidentally!): another attack, dubbed > > DROWN, just emerged, using SSLv2 as - you guessed it - a > > Bleichenbacher padding oracle against RSA PKCS#1 v1.5! > > PSS doesn't help against Bleichenbacher attacks on encryption. The attack > still can compute a private key operation. Yes, fortunately TLS 1.3 eliminates RSA key transport. Otherwise, for key transport we'd want OAEP rather than PSS. Still, even though DROWN does not attack RSA signatures, we cannot say that ongoing use of PKCS#1 v1.5 signatures is particularly wise. http://www.automatednetworkedstorage.biz/emc-plus/rsa-labs/historical/raising-standard-rsa-signatures-rsa-pss.htm Burt Kaliski, RSA Laboratories February 26, 2003 Executive Summary RSA-PSS is a new signature scheme that is based on the RSA cryptosystem and provides increased security assurance. It was added in version 2.1 of PKCS #1. While the traditional and widely deployed PKCS #1 v1.5 signature scheme is still appropriate to use, RSA Laboratories encourages a gradual transition to RSA-PSS as new applications are developed. So the question is how "gradual" we want the transition to be. If v1.5 is negotiable, in TLS 1.3, we're looking at another decade or two, perhaps by then QC will make RSA obsolete? -- Viktor. From nobody Tue Mar 1 11:20:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6134B1B401F for ; Tue, 1 Mar 2016 11:20:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1roRjQhODLQE for ; Tue, 1 Mar 2016 11:20:46 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9571B403C for ; Tue, 1 Mar 2016 11:20:44 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id n186so52850458wmn.1 for ; Tue, 01 Mar 2016 11:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3zfVrnMAGEIPpo2Z82Z4dkBA7DrvOlLWgTz0p3nKiMo=; b=iISI5Wo17Qyu+I77U6/8OfSY1ZP0igBXqCUwQ76nM2UMu9QEQnyxjp+J8KQQhVQX9j r3AxuncOVg0djUs92eq7oCzSB5FbGsPUWG0RhuuhE8A9IPPWhL4aLDO2ifLhwEZTL+rs MiCchyz7XLem/FLCr77HItmfDO9qB2uOMku2sFL83ifgpxVA76Itap0Ra3xU5EqxNnCK ZW/FgLEmtwO1/myYQWQ3IOqtg6myjcPYQEus8T8hud5JAc1RdWtU/XS2pLvLOxFIvWUn hp3Sz342a60JXpzff+9jEYUZfIcIaN2ObcgRU/eouZOwEMSmDt0v7903M31eSkMNs9O4 yKtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3zfVrnMAGEIPpo2Z82Z4dkBA7DrvOlLWgTz0p3nKiMo=; b=TFh2re83rzeXrIONZA8wIBKc+zKUegB7n87IyefMafBcqeZFyufqqRXbmR/KRjlQhx JEORz/7oXZ4RY0IE1XBk87E4ZeYHdb58M8mRIE4XjF7l8ba7HK5oz1/a4ol8zh3wPcTI OIYq1qqPwCJFm0O//f8Y5Tk/fpLvvIJdbEuhnWToRMs8Hg5wMfBdoywtHlBR5zWm6n44 VF0ZMCeLsV80ZRpVng5wYimlGWBVCfbJhyaBrLGj8os7MxpKtgRxvkZXJh2k0Oz3HJE0 KHlFTQty+pQEap6ydoqydwK2Qe45E81FzP/jKc2H9pV313HzQXqVq8NpMdnWB+Hdd2KG 0H0g== X-Gm-Message-State: AD7BkJJIafgU+UIi7cLw4Bz+6Cu7w1IEGo249peAqgrR+kyQPfuure1x1PLapFxx8YC2cg== X-Received: by 10.28.22.74 with SMTP id 71mr632620wmw.47.1456860042764; Tue, 01 Mar 2016 11:20:42 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id q139sm594432wmd.2.2016.03.01.11.20.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 11:20:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <56D5DE1D.3000708@akr.io> Date: Tue, 1 Mar 2016 21:20:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> To: Alyssa Rowan X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 19:20:47 -0000 On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: > > [YN] It would be cool to ban PKCS#1.5 from certificates, but we > > are not the PKIX working group. Nor are we the CA/Browser forum. > > When a CA issues a certificate it has to work with every client > > and server out there, When we use TLS 1.3, the other side supports > > TLS 1.3 as well, so it=E2=80=99s fair to assume that it knows PSS. >=20 > Perhaps the PKIX working group and CAB/Forum could both use a friendly > reminder not to ignore how perilous using RSA PKCS#1 v1.5 still = remains? Neither you nor I can post in any of the CA/Browser forum=E2=80=99s = lists, because neither of us has either a browser or a public CA.=20 There are some people who are active there and are reading this list, so = they might take such a proposal there. I=E2=80=99m not very optimistic, = though. While only CAs and browsers are members, they are keenly aware = that even the public CAs have a wide variety of relying parties, running = all sorts of software. And it=E2=80=99s much harder to scan clients than = it is to scan servers, so it=E2=80=99s difficult to say how many clients = will not be able to connect to a server with a certificate signed with = RSA-PSS. Probably far too many for the CA/BF to be comfortable = deprecating PKCS#1. =20 The PKIX working group has shut down several years ago. The Curdle WG is = a new working group whose charter includes deprecating obsolete stuff. = Perhaps they might be interested. Yoav=20 From nobody Tue Mar 1 12:45:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078621B4183 for ; Tue, 1 Mar 2016 12:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 BEZ5XDeAgaeX for ; Tue, 1 Mar 2016 12:45:10 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD371B4181 for ; Tue, 1 Mar 2016 12:45:09 -0800 (PST) Received: from pc1 (0x3ec7b91c.inet.dsl.telianet.dk [::ffff:62.199.185.28]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 01 Mar 2016 21:45:06 +0100 id 00000000000000A4.0000000056D5FF52.00004841 Date: Tue, 1 Mar 2016 21:45:06 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160301214506.639ee3d4@pc1> In-Reply-To: <56D5DE1D.3000708@akr.io> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-18497-1456865107-0001-2" Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 20:45:12 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-18497-1456865107-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 1 Mar 2016 18:23:25 +0000 Alyssa Rowan wrote: > And so (maybe not entirely coincidentally!): another attack, dubbed > DROWN, just emerged=C2=B9, using SSLv2 as - you guessed it - a > Bleichenbacher padding oracle against RSA PKCS#1 v1.5! To be fair, the issues surrounding RSA encryption are different ones than the ones about RSA signatures. We already agreed to deprecate RSA encryption entirely. Therefore DROWN is irrelevant for the discussion here. (What causes often confusion is that Daniel Bleichenbacher is responsible for *two* major and completely unrelated attacks against RSA PKCS #1 1.5, one against encryption and one against - badly implemented - signatures) --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-18497-1456865107-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW1f9SAAoJEKWIAHK7tR5CjA4P/3UCHegde6vjnS/UFlZLetak cT3SoAzvLN4hZYz8DJmYQGt2E521W+CPADh09uS4bssLkIVhERl3kw5dzTP//tXe 34bENxHa2O0GxHd5/vfefexB62Ih7jDkyZSHr9HJyCWnxw/gDLv9rEZk4irLD3YE NV66MVZrP1CnlhQeLZ/k/riwAM8Sb0lBRMs5Ttb6kfeDlmW2W+YEvXdL4Jl839om g0hRNnhY4CkZnMoBO1QUqRS1oxV59QCv/o6yEe40+pm8wY7cuarwrnhNm4P4W82R +B1LUL1qFRhdyuj515dZam5wiCofcHo4AaWO+CbBsMgkHMKmy9CO7gJkT8dag9Tr bwteociXXCT0RWTrcHismSbVL4BHPJiAdzEJcO4lGQgFlFInejazIXRX6Zqqb+PT 788u0QW/QSlQzVJ/9QhD6ijLoYTnrXctL0chGRv8WmVNtw3kmYFj1mt0v4KsrsGc fEuq0eh8cszNK/JfareDZxGCOYr5pCcW9FuQb4Tsr2kzLAjXYsVGv46Nw76JKqmC KI0LEJed/OJi/Su6qBK5Z/XrNN3ZqPXjkx/cF74jPOKe0VEei6+VoNR4r1qISuQy JvvJIz5LFDEdbs6/vNABb7EW0JzP8uQTpX0CshQncEm1LOYe4bjX/+lWG3UKahQC 898LXHh+BrknGGXKqQyY =/kKe -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-18497-1456865107-0001-2-- From nobody Tue Mar 1 14:23:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5201B4282 for ; Tue, 1 Mar 2016 14:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3f2Qoz5sNkM for ; Tue, 1 Mar 2016 14:23:39 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFF5B1B3CDD for ; Tue, 1 Mar 2016 14:23:39 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id o6so75757390qkc.2 for ; Tue, 01 Mar 2016 14:23:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=F2dba5gVniuABP+sTjL8l2A1ZoeddxsGDqLjaov9RcM=; b=RefSa5IIyfPyvib6KBPs79hBGk+pPHKFtHSpLoCXw3iVHSEuGKjvtCFM+JZiZWsbws JDZpxSKxy+ozHUxJOKItuIXSqciZJOM/pZh5IznhP9FHZhY4HDYwX8JI51+4pLVzgT8X O0+nBXumeeKBN5p8yVODMGYMbptBtR6IHR2YU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=F2dba5gVniuABP+sTjL8l2A1ZoeddxsGDqLjaov9RcM=; b=S19yNqCYyvipYTP+76kz0rEoqo6vCPR+ckk//GC4VTammsi3q6/lqBqMVMMdfxU1OS 2YioutfjvFnd+V854Wyc/gh+S462l/y2wGR7C7f+UiwhmwK487MbEVU8f9Ww5jrLO/l1 VDiBNn8xBHFjfLzylV4NclcqUCDo2Ddt289ZEbKjcuuBtVGX3AGMUKFg7dxnhN3Xo+r5 0mi5BtszlXQliS7LmFvDBA2HsmmkHHM+LelzTwHPvRAnzrbUkDH35L8FaWJLkg8d255X ofxm0yhBTlaAthKfeHqLiwjffx8+lt12PpFtRTl3usN4gzF0DahHCZ4CQrJ15m2+hk51 eXEA== X-Gm-Message-State: AD7BkJJniQfCazpCMaRSlq+iWM78aoSfYevx2L9uNnkgK+mcaOOuIwZrBJFzMdMGoBlpwg== X-Received: by 10.55.209.148 with SMTP id o20mr29860762qkl.5.1456871018687; Tue, 01 Mar 2016 14:23:38 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id 5sm13830709qgz.8.2016.03.01.14.23.37 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 14:23:37 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <676EDB5B-CC49-4C75-AC8E-FB3FAFAD1589@sn3rd.com> Date: Tue, 1 Mar 2016 17:23:36 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] ecdh_x25519 and ecdh_x448 code points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 22:23:41 -0000 All, After completing the early code point assignment process, IANA has added = the following values to the Supported Groups Registry: 29 ecdh_x25519 30 ecdh_x448 You can see the entries here: = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-8 spt PS - We=E2=80=99ll get the =E2=80=9CTEMPORARY=E2=80=9D tag removed once = we get 4492bis/TLS1.3 published. =20= From nobody Tue Mar 1 14:23:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31D81B428B for ; Tue, 1 Mar 2016 14:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bRtJIk5nzTJ for ; Tue, 1 Mar 2016 14:23:45 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::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 164071B428A for ; Tue, 1 Mar 2016 14:23:45 -0800 (PST) Received: by mail-qg0-x229.google.com with SMTP id u110so25599926qge.3 for ; Tue, 01 Mar 2016 14:23:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=hKIDEoSC3chmTdVIgvxbQv69yM1gHcjQaxAYg/3NDLY=; b=FS+dyPeB/NSEEw9vp0txTgG369hIfTYAIqH69WQ+/3gsn133u0MVYS7mRbzs8I1JJU h/zjo45j9Ip4YJNDIPNVb/YEypsUL/Sv8GFO2l3BpQeKNbDpFGH3OGV22JHVcZEY+h/9 pwW5ZLZDMuGfAWKtd19mVMoziGNHAGKYcMMjE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=hKIDEoSC3chmTdVIgvxbQv69yM1gHcjQaxAYg/3NDLY=; b=jBZBpNLv9gzGuUYmAOqsX+K2YBvJn77pJcr0VbfV/R4wwFUr4FDv/FLfRNRGDCRPsE t9yHnAXD9p8C2HDpll0q9YrahrmXhgYCy+P5CjTF6oeV7LmyRnvx9SBfnzG/wVleAq1Y EuK4Z2V3DUZITSZO0dPwaHD7TJvjxdnI6FOXNRiMTZQMP89p4bb0CoG+xhYHhw8LqjbT K+RMQTulNMViD6eqzRU5a5symqkDJofLH3fy/zhzLDEwy8M8or9w0u4Fin8zPrtiql0Z yGCTAwqwGvl5WF9HdkGPo5w9qpTmLrPD5lOr8QK1LYufDtp1r+Zx57jdDQjkxvdvIImH rW9A== X-Gm-Message-State: AD7BkJIbhCDBEC6dZy/xoH2V9a9cOrGv2h87uPxqvHYyABX8ipwk6mL0bJnz6SowPFm6Eg== X-Received: by 10.141.2.11 with SMTP id e11mr2609116qhd.69.1456871024259; Tue, 01 Mar 2016 14:23:44 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id 5sm13830709qgz.8.2016.03.01.14.23.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 14:23:43 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1E6C853C-1DE7-44AE-BE66-A3549A44DF28@sn3rd.com> Date: Tue, 1 Mar 2016 17:23:43 -0500 To: "" , draft-ietf-tls-chacha20-poly1305@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] ChaCha20 Poly1305 code points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 22:23:47 -0000 All, IANA has assigned code points for draft-ietf-tls-chacha20-poly1305. = They can be found in the following registry: = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 Authors, Feel free to update your draft to reflect just the assigned numbers, = which happen to match the suggested values. spt= From nobody Tue Mar 1 14:36:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7C71B42B4 for ; Tue, 1 Mar 2016 14:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnpvT7ZaQxWr for ; Tue, 1 Mar 2016 14:36:48 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EA771B42B3 for ; Tue, 1 Mar 2016 14:36:48 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id l68so59407039wml.0 for ; Tue, 01 Mar 2016 14:36:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DdP8w2zyQbpin+zSPfo1yEMsT9orYgzIZgtpwCPpaoM=; b=ifKxTuwzSvDMTgdvCwm9EIDEEqOtY2QiknpJHAoJZtycnK1vF1mQmggEs1gvWl3yty b2zXaNDSOY8OCyYTLVQW3+jzjYNPm5rQ5AJZFL1zpja+HwWAAS3Ttzf85TsflX2AUtLf XJdcbP2HDhgReIVJ0mZqcEAzfibCcoi4De5UiP6LgYypmEZYML4DoOtqvwRdCZiRv1XV 6qhbJryqmMhGC4lsCbPsnXTNto0VzioFxu2takqSd9KDiEalQnpiT2XkU9c492US7kzB 2yXJYJ6vW+KRYQ01zxn/otxQiTbaA2bRjltbiiYEnbJ4bOmovyC2+6QhLEGDhHTDOtTC f22g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DdP8w2zyQbpin+zSPfo1yEMsT9orYgzIZgtpwCPpaoM=; b=SzXs31DS9b31mJ9kaZpcKPqTA0MaNEBaAC1XE8+fyMV3ML5mzTb087OpnMsA15eLSj R6a008iY5S7E3uBDP2VX9cqzz2nFdzeoeietAw3CntUYjUAnWtr6K2Z4yIO3HKknSK+b gzZYpHMV5txegH9gqbwKZe5ACc3CEfHePuokSYz9LPPn94PrIsuyPaTcqGCDN9PdqF7u rf7v96whbjEUD/qTTW2hXe3Tuc4lKIcHIgO57ZI5Q5pyeuhqvRfFQW/l8W/fYxyOu/8a 6VEbbEaC1LqIk/NehFMtYBvFAJRaSyccgr0kxFJQMV3PXAaKOFNmdnChsiuoZFZdXLf2 pOGA== X-Gm-Message-State: AD7BkJJZ1a7Kh2pT/UO4iYDSOyDXBrYyY5nhjdCuymIS+wosxkOleRDSnuUqPUol5VTJcw== X-Received: by 10.28.9.71 with SMTP id 68mr1245624wmj.33.1456871806742; Tue, 01 Mar 2016 14:36:46 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id u4sm33000062wjz.4.2016.03.01.14.36.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 14:36:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <676EDB5B-CC49-4C75-AC8E-FB3FAFAD1589@sn3rd.com> Date: Wed, 2 Mar 2016 00:36:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <676EDB5B-CC49-4C75-AC8E-FB3FAFAD1589@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] ecdh_x25519 and ecdh_x448 code points X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 22:36:50 -0000 OK, I=E2=80=99ve created a pull request to update 4492bis. https://github.com/tlswg/rfc4492bis/pull/20 There=E2=80=99s still the curves for EDDSA that are not yet assigned. Yoav > On 2 Mar 2016, at 12:23 AM, Sean Turner wrote: >=20 > All, >=20 > After completing the early code point assignment process, IANA has = added the following values to the Supported Groups Registry: >=20 > 29 ecdh_x25519 > 30 ecdh_x448 >=20 > You can see the entries here: > = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-8 >=20 > spt >=20 > PS - We=E2=80=99ll get the =E2=80=9CTEMPORARY=E2=80=9D tag removed = once we get 4492bis/TLS1.3 published. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 1 14:46:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDEFA1B3DB8 for ; Tue, 1 Mar 2016 14:46:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsbaSgt0S4sZ for ; Tue, 1 Mar 2016 14:46:33 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709DD1B3DB6 for ; Tue, 1 Mar 2016 14:46:33 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id l127so240061837iof.3 for ; Tue, 01 Mar 2016 14:46:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=l+T/nEfAQJn5aA9zcgV728mmQUGloSQhQNrlWTfqwwM=; b=qyx5ANUY+8ZcRtxjMSF9aGcAhv+SUuHEWVlR2cZyEFijLeZGxtIpMerSRjWS2KIQnG /7E+8O3JeytOV/kamtn8DY1P/a4c96uaoLA6ARC2k0PGqUDfGR7gWGCJidIZctyk7hqd as8ChX3GabXs4sSNz9loCisBQX7W5Ut7ZpSGl5/iHoSefUtsG+Te8LR2pLabEDEWhrcd cuculsbAfGwkrO8tG6jax0o4mI/iGt7NlG8yWU5C7OEcO7ZxpugoPo33VZ8oxhUcp5Rr tY57X99fKTF/oLppto/t7GXiNUM9v5d/WFpSizmZkcWBTeyRkmWl+0vrjxY84KEmVTOc ZISA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=l+T/nEfAQJn5aA9zcgV728mmQUGloSQhQNrlWTfqwwM=; b=Iu59R7QHn8Osuohlh6gw4NRhGj4+1lzFu2vdpuDNPVHQWaqhTxId0GcONWN3xuEAnW HPD5GzQyRSmPaTXII9k6WS+oD7XvFOQDFfZQO54J71jnV5qrk2FVvJx8ftRWb+U5Omby ZdGtKRHQVw5DD8sDwS4GjqtkV7s/Qxc9PQx3n2CsrWUi5OMC7qUkFg6Bo2AU3S8KOuQu doB+0pETI89Ahoe1HhlPc4Mt8DgD6VbW0LIkkEQ7w/zqcAZOo5ieqiw8lsL5EU34qoQK mD3VnbnfjikKbd0uA2ChLYuFXFbUN2mro7gm2cKqdD6fUiwTC6mXE1r7UDIwuX4FJV9s Cemw== X-Gm-Message-State: AG10YOTjhoulb1T4qnz6Nq1tY2o3RUuoCK5c4RFMpdG6UtjvZzTMpxRdaBmAe6Yov0ZjZJq906FnKled5KnxTg== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr28244747iop.100.1456872392828; Tue, 01 Mar 2016 14:46:32 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 1 Mar 2016 14:46:32 -0800 (PST) In-Reply-To: <20160301183816.GH12869@mournblade.imrryr.org> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <20160301183816.GH12869@mournblade.imrryr.org> Date: Wed, 2 Mar 2016 09:46:32 +1100 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 22:46:35 -0000 On 2 March 2016 at 05:38, Viktor Dukhovni wrote: > Yes, fortunately TLS 1.3 eliminates RSA key transport. It does not. It just doesn't *use* RSA key transport. That's the unfortunate part. Hence the call for key separation. From nobody Tue Mar 1 17:05:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD2B1B4445 for ; Tue, 1 Mar 2016 17:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71sz1gx1KWD9 for ; Tue, 1 Mar 2016 17:05:20 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E533D1B443D for ; Tue, 1 Mar 2016 17:05:19 -0800 (PST) Received: from resomta-po-04v.sys.comcast.net ([96.114.154.228]) by resqmta-po-01v.sys.comcast.net with comcast id Qp5D1s0044vw8ds01p5Gva; Wed, 02 Mar 2016 01:05:16 +0000 Received: from [10.65.229.79] ([68.177.129.79]) by resomta-po-04v.sys.comcast.net with comcast id Qp331s00Q1ivTfo01p36YZ; Wed, 02 Mar 2016 01:03:14 +0000 To: tls@ietf.org References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> From: Andrey Jivsov Message-ID: <56D63BC7.5010302@brainhub.org> Date: Tue, 1 Mar 2016 17:03:03 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456880716; bh=qHXUzGhQzDc4hQY386oiQfp+dHISwUY2FbC/HzTSMOU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=l8R+TVbKU6h4IbPr00v76/TePcaY6U2dg+FNs9j6GEiMfDHwnqktKhjKpuyr2YvXf 4lMkeSG+HRwBszpUis42wjdXvRl266uCIqHxabCYfhd1kKuxSdcnhsG2BGw40jdR6e Tm6TO1lD/8SpPD7X3EUdwYAlAILSbU9ORUu7sgK+ckUQa8lu16nqLKLFALNtGJ+0tI vBE1QARKwVzOKH2WEVSU3X4Z81sV/VA2lD2NLqxcfuIqljNbJ6ILt8eKa/aiPRDk4m JY8Wfsq1+tZSULSRSzm9WCPFPcQduoDXiMKS36XM9MmxnDzGZVgOGqHtnbl4fkNI6R Ng994pzoYVleA== Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 01:05:22 -0000 On 03/01/2016 11:20 AM, Yoav Nir wrote: > > On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: > >>> [YN] It would be cool to ban PKCS#1.5 from certificates, but we >>> are not the PKIX working group. Nor are we the CA/Browser forum. >>> When a CA issues a certificate it has to work with every client >>> and server out there, When we use TLS 1.3, the other side supports >>> TLS 1.3 as well, so it’s fair to assume that it knows PSS. >> >> Perhaps the PKIX working group and CAB/Forum could both use a friendly >> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains? > > Neither you nor I can post in any of the CA/Browser forum’s lists, because neither of us has either a browser or a public CA. > > There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though. While only CAs and browsers are members, they are keenly aware that even the public CAs have a wide variety of relying parties, running all sorts of software. And it’s much harder to scan clients than it is to scan servers, so it’s difficult to say how many clients will not be able to connect to a server with a certificate signed with RSA-PSS. Probably far too many for the CA/BF to be comfortable deprecating PKCS#1. > > The PKIX working group has shut down several years ago. The Curdle WG is a new working group whose charter includes deprecating obsolete stuff. Perhaps they might be interested. > > Yoav > The removal of PKCS #1.5 signature support in TLS 1.3 is a client issue when client authentication is used. See examples here: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html . Regarding server-only authentication, it seems that there is assumption that TLS 1.3 will continue to use PKCS#1.5 for a long time in X.509 certs. Then why "break Internet" or slow down adoption of TLS 1.3 by mandating PSS in one field of handshake? Imagine that there is PSS#2 in the future. Is the intent to issue new TLS 1.4 that bans PSS and hardwires PSS#2? If not, there may still be a signature negotiation mechanism in TLS 1.3 in the future. The reasons CAs are cold to adoption of PSS are similar to these of TLS servers or clients: 3d-party dependence, prior investment, FIPS 140 certification, cost. TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely doesn't. Why one signature field is an exception? IMO this will lead to slower adoption of TLS 1.3, on balance. Nothing prevents e.g. OpenSSL from implementing PSS in HS (which is proposed as MUST anyway). Nothing prevents servers from not negotiating TLS 1.3. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Mar 1 17:44:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384C51A8862 for ; Tue, 1 Mar 2016 17:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmL4XglK1vg0 for ; Tue, 1 Mar 2016 17:44:35 -0800 (PST) Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBEA91A700C for ; Tue, 1 Mar 2016 17:44:34 -0800 (PST) Received: from [172.20.10.2] (51.sub-70-213-0.myvzw.com [70.213.0.51]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O3E01D1Y2672A30@st11p02im-asmtp001.me.com> for tls@ietf.org; Wed, 02 Mar 2016 01:44:34 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-03-01_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1603020031 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Shin'ichiro Matsuo In-reply-to: <20160225201124.GB30171@LK-Perkele-V2.elisa-laajakaista.fi> Date: Tue, 01 Mar 2016 17:44:30 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20160225201124.GB30171@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: "" Subject: Re: [TLS] Formal Verification of TLS 1.3 Full Handshake Protocol Using ProVerif (Draft-11) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 01:44:36 -0000 Hi Ilari, Thank you for your kind comments. We will try to commented cases. Regards, Shin=E2=80=99ichiro Matsuo > On Feb 25, 2016, at 12:11 PM, Ilari Liusvaara = wrote: >=20 > On Thu, Feb 25, 2016 at 08:05:58AM -0800, Shin'ichiro Matsuo wrote: >=20 >>=20 >> ------------------------------------- >>=20 >> [What's checked] >> We checked the TLS draft-11 full handshake protocol for the following = two properties. >> * Secrecy of payload: Can the attacker know the encrypted payload? >> * Authenticity: Can the attacker impersonate the server? >=20 > I think the following should be checked as well (once the relevant > definitions are available): >=20 > - signed TLS-EXPORTER results can be used for authentication. > - TLS-EXPORTER results can be used as secure encryption keys. >=20 > There are many pieces of sofware that rely on those two properties. >=20 >=20 > Also, reading the .pv file, it seems like only 1-RTT GDHE-CERT mode is > verified, not GDHE-PSK nor PSK nor any kind of 0-RTT mode. >=20 > (And then there are possibly even worse problems with usage... Not = that > I know what's the "correct" model there). >=20 >=20 >=20 > -Ilari From nobody Tue Mar 1 18:42:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518CB1B4559 for ; Tue, 1 Mar 2016 18:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id criCNPZ6_A8k for ; Tue, 1 Mar 2016 18:42:55 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CEB41B4558 for ; Tue, 1 Mar 2016 18:42:55 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id k196so189439140vka.0 for ; Tue, 01 Mar 2016 18:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=tj+diqadzAb7GPVx3F1GUGtssLtIOVz6t55cQp6zFy0=; b=UjUCaAgwIAUgMt7VpV/mGt36kjewPJk8J6NxTdvLfYh1xbQwSmVo5JyXlvIxpbWVyM HGJmLhejpTrEaEsvBzSeNwyDdz6EW2/iHhQIyHxPe3yCeokV45gWal1phX2SQO/TDVZo MfcUjqkzb7NEFll0h+sY5fg7E/FdARjErkBzwob/8Iq1hDg6+wOeccyZdIx/PgLHzryp NPP6S6zbKd1XaBXWPSoUBCmT5W3DpLyCwSZ5zDDlTdOXlzLsvgc5wRtr3wNyLsGeYvdG 1iL0WVwJce9v8o5PoSeYLa3ZIWQaeZ6zM+j3uKmBPImIDJxbr0W1hGeSZX2pfZDfTiCz 61lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=tj+diqadzAb7GPVx3F1GUGtssLtIOVz6t55cQp6zFy0=; b=cgW1EUfkJNQtw2RlIziYV5mLnKXWXgWOP4a5QOeWuxUEkOLTJXRondIGCTliuMAX+D qeXvlZKRrOaG51ACyVviYvUIKU0NfRyQ/npNscNAEYt6oX902QWAVmGfuKmN6c/oBX/W eK7oZ08bxye6GEYAQkVn1zrlGo2cffvtxodtK5G9DZJKVs/zaWirNwqfnMMNShHmefEz r88iRoSnqhRF/8SYZ9t2znDS8pWa0xceCC9En11Ax3lTPz2kBSjdd8Ia1yKew9e4ocn9 cZzW4SGBadotWyOQ3U4rwScyvznvTB4ZnYYqzqQmjA6KiKTnkhA5rZz6b8eAh1R1pddJ B4JQ== X-Gm-Message-State: AD7BkJJXJ9G8UIcWVIm4rkA1YZY42dze5paqSIqsnX27owhhS24CHJOFJ7ivOILOyU1sa2uSKu/NC2Qm41YF/A== MIME-Version: 1.0 X-Received: by 10.31.162.3 with SMTP id l3mr18670357vke.68.1456886574062; Tue, 01 Mar 2016 18:42:54 -0800 (PST) Received: by 10.176.1.183 with HTTP; Tue, 1 Mar 2016 18:42:54 -0800 (PST) In-Reply-To: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> References: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> Date: Tue, 1 Mar 2016 18:42:54 -0800 Message-ID: From: Watson Ladd To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 02:42:57 -0000 On Mon, Feb 29, 2016 at 6:45 AM, Sean Turner wrote: > At the TRON workshop [0], we (Joe and Sean) were asked to provide our vie= ws about the status and timeline for TLS 1.3; we wanted to share the same i= nformation with the WG. > > Before that though, we want to thank the researchers for the time they pu= t into analyzing the protocol as well as the TRON Workshop sponsors. The w= orkshop was constructive and helpful. There are a number of groups formall= y analyzing the protocol, some by hand and some with automated tools, they= =E2=80=99ve already discovered issues that we=E2=80=99ve fixed [1]. > > The workshop made the following clear to us wrt TLS 1.3: > > o - Basically OK overall, but there was some sentiment that we should onl= y do 0-RTT with PSK (see recent list discussion). > > o - Some researchers prefer the key schedule that is currently documented= in the draft because it eases modular analysis of the protocol. Others pre= fer the simplified proposals in [2,3]. > > We are hoping to be able to do a WGLC sometime shortly after Buenos Aires= (i.e., mid-April). Of course, this timeline is entirely dependent on the = WG reaching consensus on the remaining issues. > > At this point we are looking at reducing change to the protocol. We are = not looking to add any more features, removal of features and slight change= s that improve the protocol are still on the table. Obviously, if we find a= ny glaring issues we will fix them regardless. > > One thing that was reinforced at TRON and we think the TLS WG should be a= ware of is that the research community needs time to do their analysis. Wi= th that in mind, the chairs are very strongly leaning towards an extended W= GLC of 6 weeks. Is the Core TLS proposal something that the Chairs and WG think should be adopted? Essentially this is a stripped down TLS 1.3 without dangerous bits that we encourage highly reliable implementations to stick to. I know I still need to make a concrete proposal: probably this weekend will see it done. The idea is that we've already done the analysis of the Core TLS, and implementations can be significantly simplified if they only support this core, thus removing the possibility of very nasty bugs. Sincerely, Watson > > J&S > > [0] https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-rea= dy-or-not-tron-workshop-programme > [1] https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA > [2] https://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg > [3] https://mailarchive.ietf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Mar 1 18:56:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192611B45B6 for ; Tue, 1 Mar 2016 18:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 nHs0qBLMBR3x for ; Tue, 1 Mar 2016 18:56:09 -0800 (PST) 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 6286A1B45B5 for ; Tue, 1 Mar 2016 18:56:08 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id g127so166587803ywf.2 for ; Tue, 01 Mar 2016 18:56:08 -0800 (PST) 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=+72/1xQYof/T6AL8KTob0DYpVsPr2fzBmFaDFk6XMGA=; b=XZVV2BtziewKhtJ6ZSQfW7j2B7jSI9IaoC4ncyQ3MzOIeVrcEiusKoyDXek1spCNCQ djkCdMdfpsro+AM3Y+1CsmH44CrXsIcifHTFM6EZIecijk3qXIVnoSPj95PPzEkDdON2 z4bN1//WCxis/yDoH489HuO0s+8o1uw9MxIHuvSkZGkk6z9hdMBcQkSj+KS/1gI2hRkb wZGVv18GeM8ClJb25tIFg5ECc24Wwy89dqzxsZErwu07lumJEb2Z1RvYWBh2fEnCvibw WS+Xw2aco85qBj6drgvMvQdPRwdogdGRffQbNGO0O4kR16qRVM8Std9kEOmFASeBdzIM TOFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+72/1xQYof/T6AL8KTob0DYpVsPr2fzBmFaDFk6XMGA=; b=MvmAzkOWkiIpVbV8DGRBcgmtxlhCMg6tzyZuYFkaK/xoZdoBEdAjtVwsoHnkpDHeuD SeQeZrqTwjgCoWw4JOio6nQBj7NHX0Fls9xuCNoFbBW/dkJh/Q5gaa95baxEnJ2GpDoO xqtSOBueo0OD6yh8Xd87Pm8S7zmOMSfS2enjobt2zw4Mvomd3vv1zqY+Geaeo/6iJPIV cDmvZk1ndpb/lEatghvMkg2rYfU4fpkNoP5IKXwe9A+cjVWrvY6Jusl7RS4q85anv521 bUBPvnKefSVrFX2KaIdWXTAQd5N1YekyClXDPzL4TWJs24LsWFo5PBL9vrAbw+mCy+Tr 8qkw== X-Gm-Message-State: AD7BkJIAIyapxLD/wh6QR2FYyH7Hk50YOFs/VHOSnwZXNL1TBQyS0km7EO1UpLXX93C1aXFKkNvG3mfefqPfPA== X-Received: by 10.129.38.135 with SMTP id m129mr13631003ywm.155.1456887367484; Tue, 01 Mar 2016 18:56:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 1 Mar 2016 18:55:27 -0800 (PST) In-Reply-To: References: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> From: Eric Rescorla Date: Tue, 1 Mar 2016 18:55:27 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1141618c04891e052d0806d6 Archived-At: Cc: "" Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 02:56:11 -0000 --001a1141618c04891e052d0806d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 1, 2016 at 6:42 PM, Watson Ladd wrote: > On Mon, Feb 29, 2016 at 6:45 AM, Sean Turner wrote: > > At the TRON workshop [0], we (Joe and Sean) were asked to provide our > views about the status and timeline for TLS 1.3; we wanted to share the > same information with the WG. > > > > Before that though, we want to thank the researchers for the time they > put into analyzing the protocol as well as the TRON Workshop sponsors. T= he > workshop was constructive and helpful. There are a number of groups > formally analyzing the protocol, some by hand and some with automated > tools, they=E2=80=99ve already discovered issues that we=E2=80=99ve fixed= [1]. > > > > The workshop made the following clear to us wrt TLS 1.3: > > > > o - Basically OK overall, but there was some sentiment that we should > only do 0-RTT with PSK (see recent list discussion). > > > > o - Some researchers prefer the key schedule that is currently > documented in the draft because it eases modular analysis of the protocol= . > Others prefer the simplified proposals in [2,3]. > > > > We are hoping to be able to do a WGLC sometime shortly after Buenos > Aires (i.e., mid-April). Of course, this timeline is entirely dependent = on > the WG reaching consensus on the remaining issues. > > > > At this point we are looking at reducing change to the protocol. We ar= e > not looking to add any more features, removal of features and slight > changes that improve the protocol are still on the table. Obviously, if w= e > find any glaring issues we will fix them regardless. > > > > One thing that was reinforced at TRON and we think the TLS WG should be > aware of is that the research community needs time to do their analysis. > With that in mind, the chairs are very strongly leaning towards an extend= ed > WGLC of 6 weeks. > > Is the Core TLS proposal something that the Chairs and WG think should > be adopted? Essentially this is a stripped down TLS 1.3 without > dangerous bits that we encourage highly reliable implementations to > stick to. I think a "safer" profile of TLS, as in "implement the following features (section XXX, YYY) and not the following (section ZZZ)" then that seems like something that might potentially be a useful exercise. Depending on length, this might eventually make sense to pull into TLS 1.3 as an appendix or just leave as a self-contained document. Just to preempt this, I think a separate self-contained draft would be bad. -Ekr > I know I still need to make a concrete proposal: probably > this weekend will see it done. The idea is that we've already done the > analysis of the Core TLS, and implementations can be significantly > simplified if they only support this core, thus removing the > possibility of very nasty bugs. > > Sincerely, > Watson > > > > > J&S > > > > [0] > https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-o= r-not-tron-workshop-programme > > [1] > https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA > > [2] > https://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg > > [3] > https://mailarchive.ietf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1141618c04891e052d0806d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 1, 2016 at 6:42 PM, Watson Ladd <watsonbladd@gmail.com= > wrote:
On Mon, Feb = 29, 2016 at 6:45 AM, Sean Turner <sean@sn3rd.com> wrote:
> At the TRON workshop [0], we (Joe and Sean) were asked to provide our = views about the status and timeline for TLS 1.3; we wanted to share the sam= e information with the WG.
>
> Before that though, we want to thank the researchers for the time they= put into analyzing the protocol as well as the TRON Workshop sponsors.=C2= =A0 The workshop was constructive and helpful.=C2=A0 There are a number of = groups formally analyzing the protocol, some by hand and some with automate= d tools, they=E2=80=99ve already discovered issues that we=E2=80=99ve fixed= [1].
>
> The workshop made the following clear to us wrt TLS 1.3:
>
> o - Basically OK overall, but there was some sentiment that we should = only do 0-RTT with PSK (see recent list discussion).
>
> o - Some researchers prefer the key schedule that is currently documen= ted in the draft because it eases modular analysis of the protocol. Others = prefer the simplified proposals in [2,3].
>
> We are hoping to be able to do a WGLC sometime shortly after Buenos Ai= res (i.e., mid-April).=C2=A0 Of course, this timeline is entirely dependent= on the WG reaching consensus on the remaining issues.
>
> At this point we are looking at reducing change to the protocol.=C2=A0= We are not looking to add any more features, removal of features and sligh= t changes that improve the protocol are still on the table. Obviously, if w= e find any glaring issues we will fix them regardless.
>
> One thing that was reinforced at TRON and we think the TLS WG should b= e aware of is that the research community needs time to do their analysis.= =C2=A0 With that in mind, the chairs are very strongly leaning towards an e= xtended WGLC of 6 weeks.

Is the Core TLS proposal something that the Chairs and WG think shou= ld
be adopted? Essentially this is a stripped down TLS 1.3 without
dangerous bits that we encourage highly reliable implementations to
stick to.

I think a "safer" profi= le of TLS, as in "implement the following features (section XXX, YYY) = and not the following (section ZZZ)" then that seems like something th= at might potentially be a useful exercise. Depending on length, this might = eventually make sense to pull into TLS 1.3 as an appendix or just leave as = a self-contained document.

Just to preempt this, I= think a separate self-contained draft would be bad.

-Ekr
=C2=A0
I know = I still need to make a concrete proposal: probably
this weekend will see it done. The idea is that we've already done the<= br> analysis of the Core TLS, and implementations can be significantly
simplified if they only support this core, thus removing the
possibility of very nasty bugs.

Sincerely,
Watson

>
> J&S
>
> [0] https://www.internetsociety.org/events/ndss-symposium-2016/tls-= 13-ready-or-not-tron-workshop-programme
> [1] https://mailarchive.ie= tf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA
> [2] https://mailarchive.ie= tf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg
> [3] https://mailarchive.ie= tf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

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

--001a1141618c04891e052d0806d6-- From nobody Tue Mar 1 19:01:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 118231A8A85 for ; Tue, 1 Mar 2016 19:01:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lf_Kx9cOwsXR for ; Tue, 1 Mar 2016 19:01:28 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 9E8D21B45E4 for ; Tue, 1 Mar 2016 19:01:28 -0800 (PST) Received: by mail-ig0-x233.google.com with SMTP id y8so35902174igp.0 for ; Tue, 01 Mar 2016 19:01:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=oS8IwLNG75YzGYMSc2FWwHCUrOQOFC4ENGBGvLMIdgE=; b=myScJCa8O42c+qljMGJBNCJTwFzbyNNOIdFp7o6nnFagxR4vN21vpDv+cfFZErN4UP JOQAXlz48HYmDa9AcKN+BxS8XLmgAMsUgQA9dFHaZu3x4XNHvz9fcw87In97ifQmkQBa Q8FxLa2LUHDn8LAzIUyk+aWBW+wcQ69sR+Cj+ZQ5DxKI1thUcXiWhlVvUuHnen1aso0R VPaJwQLsGRXkBLKTNV2oriTmmdedr+270pbkhXyfs/4mfIYMTiY9FukinL7qK+kejxdg egGoJuPZwAruRJXWgFWB3LBhIBn4sBB10XOhy8r8UGOjFFiUZcMUXOuSplXRhNfTcmpy lggw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=oS8IwLNG75YzGYMSc2FWwHCUrOQOFC4ENGBGvLMIdgE=; b=LX710D/PEpXMuTX3lHpZh8tQFyK+FQ1zBiZLuSoo93ff1V1yJpsyIjtb+lJVfnvfju i8WWNaLag8oy/87MQUHLIXfN1SMqyHoWI7R9q6pxtGkxToSx2BKKnIWc+CCdgFs43tzq D/A+7ldF4ajUveuexaxU4Tr79PZlJAJSC/gCMYozgLCbu/4Zx1TzFx2jIjUZmRxnN7uR O74f2xRFEiFOq0IcvrO+Wpg6+URtPTuO50b4cC8XnzBWLUTsf2RRwqSwEmeWB9yz9y1m +rdqpXNKrt+3k28n3j5/6LZrJarjVcV0eMFKb3TSu97AEpcRpZurzLpaVUTBx18a2bjq 4zyQ== X-Gm-Message-State: AD7BkJIo4VIyEzbXnGVYN/Dmq/CJIxByA0wrp5JJ795HyeAEO/kMjMURV74T4578qehvZeQwwIYl2eDBbmolvA== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr2520699igh.94.1456887688060; Tue, 01 Mar 2016 19:01:28 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 1 Mar 2016 19:01:28 -0800 (PST) In-Reply-To: References: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> Date: Wed, 2 Mar 2016 14:01:28 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 03:01:30 -0000 On 2 March 2016 at 13:55, Eric Rescorla wrote: > I think a "safer" profile of TLS, as in "implement the following features > (section XXX, YYY) and not the following (section ZZZ)" then that seems like > something that might potentially be a useful exercise. Depending on length, > this might eventually make sense to pull into TLS 1.3 as an appendix or just > leave as a self-contained document. Yeah, something like this would have been very helpful for TCPINC. Or for protocols like COAP. I think that a description of the "good parts" of TLS 1.3 would be a relatively short document if it were self-contained. The core is pretty simple. Though, as ekr mentioned, copying the main spec could be bad. The point of something like this is to create something that would talk to a full implementation, not to create a protocol fork. From nobody Tue Mar 1 19:06:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EB81B441C for ; Tue, 1 Mar 2016 19:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DGPLRkvfn4R for ; Tue, 1 Mar 2016 19:06:22 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 658E21A8A91 for ; Tue, 1 Mar 2016 19:06:22 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id k196so189838928vka.0 for ; Tue, 01 Mar 2016 19:06:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Vb/7wBO6UvrdHgezxKkBd9PZoqpfHQONtIPYTaxJCEg=; b=SmMkyJAyj28J52RrLFBk2caZwOYAUUFXrnX5WUt3rj2rmiCwk20Fl2rcyDCz92tv41 Ud/uQJMQCsOLQoIbs9MGVeDKrJF4ABVnBdT+pMTO9gVopX4L8SOzOIO6uZLEXD57blkh xONfVttyCO79VAd0YopDkwx4c0T0hStrTTy8yvaHcmAM+1kLP1ZxXqIM+o3E2UruubsQ GGcXDUBg010EYd8HVzekDpexkr136pvukgGU9mcMlJgVzJiRcixHBlBKAAY0yuUnD0vU U3KlC8vTjHXEr3iPyWl6JV7y/4leT640FUV1JbIbZ4o7YQDGLcx90AQKZMnfUat+Tq7+ LYUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Vb/7wBO6UvrdHgezxKkBd9PZoqpfHQONtIPYTaxJCEg=; b=F86LcaaOKzXlzGXrAVjCM5foq9ptg25Y5+gEEfG7mIGfpU0InHXqRat+hXgWn+J/tQ 0bgwmUNaoFnBOKduieeYp5cmRKuJrjNao1yJrFhJPihU8/q7CLowU316esIlbrlWCXhR D3+ADqyHNA8UqjRdzIIe/FWhemEqdLUZiPKPqMOxrzaf/LnvgkTauHMpdmbOIo2nul9W vY/hMxbuRLMjXBQjk+B7BwsJAVL0HfjG1PwgzNvsOkviuXDsMGZvUNjPELqdlIQ6M5qs UN/Qa/DfvfqGu0BjikjbiSJ5LEUbbc/4zAu+ndpVP0MtNNrERhqSrN8dg0l/bP1aT6Sg eDNQ== X-Gm-Message-State: AD7BkJLvwRo/K0awJeGVirznbATNhsUtq8VmelczUnkgbw6uRJsCVEreikdYlW4e+0kbtjW9yiFJGUi8LLDeIA== MIME-Version: 1.0 X-Received: by 10.31.138.73 with SMTP id m70mr18492136vkd.70.1456887981497; Tue, 01 Mar 2016 19:06:21 -0800 (PST) Received: by 10.176.1.183 with HTTP; Tue, 1 Mar 2016 19:06:21 -0800 (PST) In-Reply-To: References: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> Date: Tue, 1 Mar 2016 19:06:21 -0800 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 03:06:23 -0000 On Tue, Mar 1, 2016 at 7:01 PM, Martin Thomson wrote: > On 2 March 2016 at 13:55, Eric Rescorla wrote: >> I think a "safer" profile of TLS, as in "implement the following features >> (section XXX, YYY) and not the following (section ZZZ)" then that seems like >> something that might potentially be a useful exercise. Depending on length, >> this might eventually make sense to pull into TLS 1.3 as an appendix or just >> leave as a self-contained document. > > Yeah, something like this would have been very helpful for TCPINC. Or > for protocols like COAP. > > I think that a description of the "good parts" of TLS 1.3 would be a > relatively short document if it were self-contained. The core is > pretty simple. > > Though, as ekr mentioned, copying the main spec could be bad. The > point of something like this is to create something that would talk to > a full implementation, not to create a protocol fork. I'll make a pull request containing the text against the main document then, and we can see how it looks from there. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Mar 1 19:40:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7A91B46B7 for ; Tue, 1 Mar 2016 19:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 b3U1yk9ZSmLS for ; Tue, 1 Mar 2016 19:40:36 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B931B46B3 for ; Tue, 1 Mar 2016 19:40:35 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id z13so86458504ykd.0 for ; Tue, 01 Mar 2016 19:40:35 -0800 (PST) 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=hX7voc7ChWZDLbkoHkVT74JxGgqXpc1R97Ms9kGJv2M=; b=kyGXdYS3p7WLWGR6K+UsJz+0AbF4ut716IEW7hMWcD3KmVLMSwoSsckIzliZ/ViDAz 8/ppN052rlquCvnm/SeMaG6Y4XorZ5+mi6RfHIfnclBFnqjyimzxF3bOhVtdW63aKCY6 ASbJDOR3sqIXnJ6gqJdpCW1WiYkATzqEn84WbUMww7hnpk/thpk0PIeTBR5kPTYAncmX hH+Q8URww9oyJLEkpnj7/xthoQW9lbcJpStG9TT/2fvBGyyHRe+CglkPwqaGIEqwLzAO x9HIHrwVhEp+LISotAk1O3Nzkwc4yhOHsDW66DeVb6cdYpdGTAB+2Ap+MHSCAJoyClD2 XZ3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hX7voc7ChWZDLbkoHkVT74JxGgqXpc1R97Ms9kGJv2M=; b=auT7x/ka5+eJvMOuL+MFA5QD6yoKa7/nyPgqNewaPBUQCNHIOh9ZSJryJu3sheHdKI upwWssUazBU/iROkVSxnQRxoOIZ2ByxVajesyjZQ6lhdxW0u2kw8veTYSFBuprebDslr Ktc2QxhowXDgYPO2VwDYnBNXLwJpGQtDfG7gTpAjpaK65HWlRqZUenl2+ZjVZM0vpqkU 481Zsjhbj7U3T0wnlxTc9vYEd/Vd8tLs8UKRvCjWwxNu+TV4AAXkPDwrVdVk7mcu9KLI zsig1UxzrdkBkN0yOzfl2sQV71ryuFf3em1YpuLG5mreFv+y8x21PR5qQ7ErQlA7Qk5/ ejTg== X-Gm-Message-State: AD7BkJJu4IU9Va/y8v0Cb121kVTaeEZ3NJ4SZlgVU/n8Xja4UhM/42FGFTYR652ZTaYthGlYbbvBgVCKXYOONw== X-Received: by 10.37.231.70 with SMTP id e67mr14471514ybh.57.1456890035088; Tue, 01 Mar 2016 19:40:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 1 Mar 2016 19:39:55 -0800 (PST) In-Reply-To: References: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> From: Eric Rescorla Date: Tue, 1 Mar 2016 19:39:55 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0b137c04e3f5052d08a5a8 Archived-At: Cc: "" Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 03:40:37 -0000 --94eb2c0b137c04e3f5052d08a5a8 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 1, 2016 at 7:01 PM, Martin Thomson wrote: > On 2 March 2016 at 13:55, Eric Rescorla wrote: > > I think a "safer" profile of TLS, as in "implement the following features > > (section XXX, YYY) and not the following (section ZZZ)" then that seems > like > > something that might potentially be a useful exercise. Depending on > length, > > this might eventually make sense to pull into TLS 1.3 as an appendix or > just > > leave as a self-contained document. > > Yeah, something like this would have been very helpful for TCPINC. Or > for protocols like COAP. > > I think that a description of the "good parts" of TLS 1.3 would be a > relatively short document if it were self-contained. The core is > pretty simple. > Reading this over, I wonder if we're talking about the same thing. It's probably my fault for using the word "self-contained" here, so in the interest of clarifying, what I meant here was "separate". Specifically, I think it's not going to work well to have a document that (for instance) replicates the rules about wire encodings, crypto, etc. [0] I do think it would probably be OK to have a document that profiled TLS 1.3 and then referred to the relevant sections in the main document for details. -Ekr [0] Though of course simplifications to this text are welcome. > Though, as ekr mentioned, copying the main spec could be bad. The > point of something like this is to create something that would talk to > a full implementation, not to create a protocol fork. > --94eb2c0b137c04e3f5052d08a5a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 1, 2016 at 7:01 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On= 2 March 2016 at 13:55, Eric Rescorla <ekr@rtfm.com> wrote:
> I think a "safer" profile of TLS, as in "implement the = following features
> (section XXX, YYY) and not the following (section ZZZ)" then that= seems like
> something that might potentially be a useful exercise. Depending on le= ngth,
> this might eventually make sense to pull into TLS 1.3 as an appendix o= r just
> leave as a self-contained document.

Yeah, something like this would have been very helpful for TCPINC.= =C2=A0 Or
for protocols like COAP.

I think that a description of the "good parts" of TLS 1.3 would b= e a
relatively short document if it were self-contained.=C2=A0 The core is
pretty simple.

Reading this over, I won= der if we're talking about the same thing. It's probably my fault f= or
using the word "self-contained" here, so in the inte= rest of clarifying, what I meant here was
=C2=A0"separate&qu= ot;.

Specifically, I think it's not going to w= ork well to have a document that (for instance)
replicates the ru= les about wire encodings, crypto, etc. [0] =C2=A0I do think it would probab= ly
be OK to have a document that profiled TLS 1.3 and then referr= ed to the relevant
sections in the main document for details.

-Ekr


[0] Thou= gh of course simplifications to this text are welcome.

=



Though, as ekr mentioned, copying the main spec could be bad.=C2=A0 The
point of something like this is to create something that would talk to
a full implementation, not to create a protocol fork.

--94eb2c0b137c04e3f5052d08a5a8-- From nobody Tue Mar 1 19:43:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 070DB1B46BE for ; Tue, 1 Mar 2016 19:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P-pwtA6dHCG for ; Tue, 1 Mar 2016 19:43:19 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 5FD911B46BD for ; Tue, 1 Mar 2016 19:43:19 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id e185so189302673vkb.1 for ; Tue, 01 Mar 2016 19:43:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/utzkr2zsibnh672f4+gy053dHsYzyZK93iQbV97wCg=; b=HkhkJH87s/5Lkme3UVqyxXHvhBJS9wSUvFTW+uYcyxok0fVNaXJP9m0+eucKOLyhdS uDfpHFib8LDi6foXDzITmyVBmKDbz2pfRspULy9YvtlqRFWiPIp2iSUWrjTzLnESvNGM 8z5KOHcbe+4B9vFSR085gUzJZ6J4z4BaehuwtoxcQrzNBaw3sJBsqUj37IswKph+6G/T XXlEoC9VflkV2VDtCkXnRLx0ToilxBgQmXSL4+WzMS0oWXLXM3PjIJpKvwpFmoFAJJYw EGD+hB4WcstPFh3GyLGv8nJPw8vkJcPAoZ5n1LAmVbwn9tipv1/5mDpBq1jfa1Male9+ CRKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/utzkr2zsibnh672f4+gy053dHsYzyZK93iQbV97wCg=; b=UzqJUi+NCO/3mfFWfR8Huaa0BKP80pKJxY2vzk2vopOooDOpJ8RLOhdZzodYbDcplb /8GAp0az6Xh+ybdZrd6ynK3B0oYOVPircoju1eQCIN3zafE9+LRtteSAJ93++LqlzNUW U9XwO4im1aIP5mo/WiaKkb7wSQLWhSvPzoGCZ1DDdxiemFLGm2POwx/h/l052yhqytgx e3LFuPypm5Tc187QFKNmxhUgR5zlg8pyRYfU5mgX0+v7YyFAdjM0kBZ8yDyhiIQAW2pt 1hCw8O5tvNDhdwA9tEVbJsCKvKlaxGmadeyRg6VBVlS6N5KOs/FL2/5IAk0P+/0Seils 80aw== X-Gm-Message-State: AD7BkJJLlP5HyinAuc/iLQOhZyP8z9IyrVIuBlIP1kES4bErMucnrdV9ZRcP+fU7albux07Nn9/QpQPqxboz/g== MIME-Version: 1.0 X-Received: by 10.31.192.78 with SMTP id q75mr8704517vkf.96.1456890198479; Tue, 01 Mar 2016 19:43:18 -0800 (PST) Received: by 10.176.0.115 with HTTP; Tue, 1 Mar 2016 19:43:18 -0800 (PST) In-Reply-To: References: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> Date: Wed, 2 Mar 2016 14:43:18 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 03:43:21 -0000 On 2 March 2016 at 14:39, Eric Rescorla wrote: > > Reading this over, I wonder if we're talking about the same thing. It's > probably my fault for > using the word "self-contained" here, so in the interest of clarifying, what > I meant here was > "separate". Yes, separate was my thought. > Specifically, I think it's not going to work well to have a document that > (for instance) > replicates the rules about wire encodings, crypto, etc. [0] I do think it > would probably > be OK to have a document that profiled TLS 1.3 and then referred to the > relevant > sections in the main document for details. Yes, that was my point regarding a fork. From nobody Tue Mar 1 22:37:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451371A1A25 for ; Tue, 1 Mar 2016 22:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUtT7479GqUB for ; Tue, 1 Mar 2016 22:37:49 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50CC1A0470 for ; Tue, 1 Mar 2016 22:37:48 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id l68so65784717wml.0 for ; Tue, 01 Mar 2016 22:37:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Nc9gZB6xGItpO1Zv8zMorlLZa/IirBvhLJB4XzYd8w=; b=owHjZEuZBkvFquwBiffAPsxr6Wwa1goqzz9ZvsMLjQseP/hOjUd5hN1wr5jUXnqJ+x kVfVJJ7oqtU9nHdxTIZmzBTObt39+JczDsKOv3Rgzc33JhdMnZt2zPkUAZpoySV2uvVF ezxR6XMN3g6g+KOIkOdBTQHpp0WeaJmOudlDqv5JA+RPNo1bDPgblCQ9lEzk2efeQowW nUjXPJfNWzeum3/OLK7vz7mmWHak76vcRoJBF1xcZO2RXs4+RFtytNKywNFiEOreM+aR SCOvpKBFv3X3VPl479UZVyaSSV3+j9jpmCP9ALxq6pWlRf0JF+Zw2iEAH+TQGM6OP81p /dOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4Nc9gZB6xGItpO1Zv8zMorlLZa/IirBvhLJB4XzYd8w=; b=WpI35QCxKL3YPKEfehFkmxOEdNPXJV16ZOJirSDkZMsdiolq07ZFwR9DqLFtcPJmS1 5BXF/tL+q7WE4UKC0kM85u+1vWzuZ4xOmvERMdVvnTYhHG3NcCqosr2J2Vb91MOOEsPu TX+uTyMzpkvQERHxtbUtF6rOf8QlUsH3OPj9qVLlB0Yt9Lhqdrzbnbox0thfej6KiSBf stfQwcwTiR0ZEXOZZQj7LFejJcMQGpQVu+pSXvESJJ9qI7QLPHUk1ei6LqCoeRDts1k9 YjvYEyvKvELL6f310IQRmR5adIS60aGhycFEANom61CLiA7J36AwgGzLa6Ia3E6wQiNW kB5w== X-Gm-Message-State: AD7BkJJLVGwx5Kh5fQzPCiOu/FTrEabIZQE37dgmKIwAzbOfp/9C12YDIayv8LWDY2bRAw== X-Received: by 10.28.145.8 with SMTP id t8mr2735715wmd.103.1456900667216; Tue, 01 Mar 2016 22:37:47 -0800 (PST) Received: from [192.168.137.52] ([176.13.3.32]) by smtp.gmail.com with ESMTPSA id av3sm34361880wjc.44.2016.03.01.22.37.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 22:37:46 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <56D63BC7.5010302@brainhub.org> Date: Wed, 2 Mar 2016 08:37:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <56D63BC7.5010302@brainhub.org> To: Andrey Jivsov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 06:37:51 -0000 > On 2 Mar 2016, at 3:03 AM, Andrey Jivsov wrote: >=20 > On 03/01/2016 11:20 AM, Yoav Nir wrote: >>=20 >> On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: >>=20 >>>> [YN] It would be cool to ban PKCS#1.5 from certificates, but we >>>> are not the PKIX working group. Nor are we the CA/Browser forum. >>>> When a CA issues a certificate it has to work with every client >>>> and server out there, When we use TLS 1.3, the other side supports >>>> TLS 1.3 as well, so it=E2=80=99s fair to assume that it knows PSS. >>>=20 >>> Perhaps the PKIX working group and CAB/Forum could both use a = friendly >>> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still = remains? >>=20 >> Neither you nor I can post in any of the CA/Browser forum=E2=80=99s = lists, because neither of us has either a browser or a public CA. >>=20 >> There are some people who are active there and are reading this list, = so they might take such a proposal there. I=E2=80=99m not very = optimistic, though. While only CAs and browsers are members, they are = keenly aware that even the public CAs have a wide variety of relying = parties, running all sorts of software. And it=E2=80=99s much harder to = scan clients than it is to scan servers, so it=E2=80=99s difficult to = say how many clients will not be able to connect to a server with a = certificate signed with RSA-PSS. Probably far too many for the CA/BF to = be comfortable deprecating PKCS#1. >>=20 >> The PKIX working group has shut down several years ago. The Curdle WG = is a new working group whose charter includes deprecating obsolete = stuff. Perhaps they might be interested. >>=20 >> Yoav >>=20 >=20 > The removal of PKCS #1.5 signature support in TLS 1.3 is a client = issue when client authentication is used. See examples here: = https://www.ietf.org/mail-archive/web/tls/current/msg19096.html . >=20 > Regarding server-only authentication, it seems that there is = assumption that TLS 1.3 will continue to use PKCS#1.5 for a long time in = X.509 certs. Then why "break Internet" or slow down adoption of TLS 1.3 = by mandating PSS in one field of handshake? The easy answer is: because we can. We can=E2=80=99t mandate for the CA = industry what kind of certificates they should issue, or rather, we can, = but they=E2=80=99ll rightly ignore us. We *can* mandate how a new TLS = 1.3 implementation signs for another new TLS 1.3 implementation. = Mandating that the certificates are signed with PSS would definitely = slow down the adoption of TLS 1.3. Mandating what algorithm is used = within the protocol does not.=20 As long as the spec allows PKCS#1 all implementations will support it = and many implementors will delay PSS because it=E2=80=99s not needed for = interoperability. That=E2=80=99s what a rational manager would do: = implement TLS 1.3 with PKCS#1 now, and place implementing PSS =E2=80=9Con = the roadmap=E2=80=9D. I don=E2=80=99t think we should give them that = incentive. > Imagine that there is PSS#2 in the future. Is the intent to issue new = TLS 1.4 that bans PSS and hardwires PSS#2? If not, there may still be a = signature negotiation mechanism in TLS 1.3 in the future. That depends. Did we find that PSS is insecure in this future?=20 > The reasons CAs are cold to adoption of PSS are similar to these of = TLS servers or clients: 3d-party dependence, prior investment, FIPS 140 = certification, cost. Both servers and clients tend to use libraries that implement both the = protocol and the algorithms. OpenSSL springs to mind, as do NSS, GNUTLS, = SChannel and whatever Apple calls their library. Sure there are separate = libraries with software handshakes and hardware algorithms. Even OpenSSL = does this with their =E2=80=9Cengines=E2=80=9D. I don=E2=80=99t think = this is reason enough to keep dragging obsolete algorithms with us. > TLS WG can ban PKCS #1.5 in CA certs in TLS 1.3, but it wisely = doesn't. Why one signature field is an exception? IMO this will lead to = slower adoption of TLS 1.3, on balance. Nothing prevents e.g. OpenSSL = from implementing PSS in HS (which is proposed as MUST anyway). Nothing = prevents servers from not negotiating TLS 1.3. Because this is a particular field that we control. Yoav From nobody Tue Mar 1 22:57:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C591A1B8C for ; Tue, 1 Mar 2016 22:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3MS7M1CXUlF for ; Tue, 1 Mar 2016 22:57:49 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1251A1B8B for ; Tue, 1 Mar 2016 22:57:48 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 10948284D9E; Wed, 2 Mar 2016 06:57:48 +0000 (UTC) Date: Wed, 2 Mar 2016 06:57:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160302065747.GC10917@mournblade.imrryr.org> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <56D63BC7.5010302@brainhub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 02 Mar 2016 06:57:50 -0000 On Wed, Mar 02, 2016 at 08:37:46AM +0200, Yoav Nir wrote: > Because this is a particular field that we control. Which is in itself a reasonable argument for leaving legacy behind, ... but also because adaptive attacks are I think a greater potential threat against interactive TLS than against a bunch of CA-authored bits at rest. -- Viktor. From nobody Wed Mar 2 01:11:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 257951A9171 for ; Wed, 2 Mar 2016 01:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBtbQkekGR1X for ; Wed, 2 Mar 2016 01:11:01 -0800 (PST) Received: from mmextmx2.mcr.colo.comodoca.net (mmextmx2.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (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 16CEC1A9163 for ; Wed, 2 Mar 2016 01:11:00 -0800 (PST) Received: (qmail 6104 invoked by uid 1004); 2 Mar 2016 09:10:58 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx2.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 02 Mar 2016 09:10:58 +0000 Received: (qmail 21853 invoked by uid 1000); 2 Mar 2016 09:10:58 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 02 Mar 2016 09:10:58 +0000 To: Yoav Nir , Alyssa Rowan References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> From: Rob Stradling Message-ID: <56D6AE21.7050108@comodo.com> Date: Wed, 2 Mar 2016 09:10:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 09:11:17 -0000 On 01/03/16 19:20, Yoav Nir wrote: > > On 1 Mar 2016, at 8:23 PM, Alyssa Rowan wrote: >>> When a CA issues a certificate it has to work with every client >>> and server out there, That doesn't have to be true. For example, many OpenSSL-based servers can be configured to serve an ECC certificate to TLS clients that indicate support for ECC, and to serve an RSA certificate to other TLS clients. >>> When we use TLS 1.3, the other side supports >>> TLS 1.3 as well, so it’s fair to assume that it knows PSS. >> >> Perhaps the PKIX working group and CAB/Forum could both use a friendly >> reminder not to ignore how perilous using RSA PKCS#1 v1.5 still remains? +1 > Neither you nor I can post in any of the CA/Browser forum’s lists, because neither of us has either a browser or a public CA. > > There are some people who are active there and are reading this list, so they might take such a proposal there. I’m not very optimistic, though. Please don't give up without even trying! If you have a proposal, I'd be happy to post it to the public@cabforum.org list on your behalf. Alternatively, you could post it to the questions@cabforum.org list yourself. -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Mar 2 01:16:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF201A92B1 for ; Wed, 2 Mar 2016 01:16:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFJCjCLDkTW9 for ; Wed, 2 Mar 2016 01:16:14 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 359371A92AF for ; Wed, 2 Mar 2016 01:16:13 -0800 (PST) Received: (qmail 24587 invoked by uid 1004); 2 Mar 2016 09:16:11 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Wed, 02 Mar 2016 09:16:11 +0000 Received: (qmail 29858 invoked by uid 1000); 2 Mar 2016 09:16:11 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Wed, 02 Mar 2016 09:16:11 +0000 To: Yoav Nir , Alyssa Rowan References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <56D6AE21.7050108@comodo.com> From: Rob Stradling Message-ID: <56D6AF5B.5010103@comodo.com> Date: Wed, 2 Mar 2016 09:16:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56D6AE21.7050108@comodo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 09:16:15 -0000 On 02/03/16 09:10, Rob Stradling wrote: >> Neither you nor I can post in any of the CA/Browser forum’s lists, >> because neither of us has either a browser or a public CA. >> >> There are some people who are active there and are reading this list, >> so they might take such a proposal there. I’m not very optimistic, >> though. > > Please don't give up without even trying! > > If you have a proposal, I'd be happy to post it to the > public@cabforum.org list on your behalf. Oh, somebody else beat me to it: https://cabforum.org/pipermail/public/2016-March/006910.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Wed Mar 2 01:25:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078B01ABD38 for ; Wed, 2 Mar 2016 01:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQttbV_7oFEM for ; Wed, 2 Mar 2016 01:25:12 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EAC61ABD3A for ; Wed, 2 Mar 2016 01:25:12 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id l68so68791778wml.1 for ; Wed, 02 Mar 2016 01:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=29OqqexF3OCkh54Q/1TaXvzKnDJFZF8BLJS0X4fnt64=; b=Via20k9WChh14S4XnKNRhYHjxtG+gUaW0IN0qTf8Zpzka71UYPUZG5rzx019jD8R6S noqWqcUmL0jekbwCMHTVdFqk1r/7ixDbpQndhx++xbqJBEIqLt/qZ9R+8d4c1xH5ZQ3/ rtkGdz0BiDjunGTHILOz5WXBZBc1bsKJD6fr0obI5Ngkscakg0zWw+4qeWjLlsotL0gb cCIIs6aiJrxtTqawTjdmTvAFXBSPVpUv5Tz9V2aJWPBzkKJg4t7rguW8sHUhk8VfzzXL cPD6JkbM0ImhzQchfC2tsaORbNq/7k0TGKWSzWVab+ENRNU4gQn+L1FWqRBdNYTZydAj LHmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=29OqqexF3OCkh54Q/1TaXvzKnDJFZF8BLJS0X4fnt64=; b=gpVbDkz1wcPLK0DhCvZdFwN/0TOhX26XfzNw60YjNWy9e1OLkPo2k4IgtPkrBcOlw2 jo+oZaPKVMZx2EC3jNsp6qKRMq0rZWdtGtjogFkXs8vZDufaDgzghPCKgo0SXTgzEqy7 HbrQ68ZFjuCRM2I/eRyptW2YmyTT2KQE6/EzVNnN5jienGfIfKvR7/83fGK3aBmgRNYi xgMbR3AlAttj+no7Mg45eLD7KpnYH+l+M14QrXe5l5ruTxGo40WuAMI768NrmLSCsblG e+D8WjJGTNWNU6ROVNwEKT4oAJz98q//3hju3nP4r/cBslXr4JjZ2iUIFoQrKneAc3tg dWkQ== X-Gm-Message-State: AD7BkJKz0fjZgH7+e3oy+pdj3pr/B5aPi6/nWJSp9kyfMh1SenCvZp1kmjMX2vJ758m/Wg== X-Received: by 10.28.222.214 with SMTP id v205mr3291237wmg.92.1456910710580; Wed, 02 Mar 2016 01:25:10 -0800 (PST) Received: from [172.24.251.185] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id et11sm34892460wjc.30.2016.03.02.01.25.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Mar 2016 01:25:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <56D6AF5B.5010103@comodo.com> Date: Wed, 2 Mar 2016 11:25:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7BA6CABC-077A-4DAA-BF9C-FE1209FD32C0@gmail.com> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <56D6AE21.7050108@comodo.com> <56D6AF5B.5010103@comodo.com> To: Rob Stradling X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 09:25:14 -0000 > On 2 Mar 2016, at 11:16 AM, Rob Stradling = wrote: >=20 > On 02/03/16 09:10, Rob Stradling wrote: > >>> Neither you nor I can post in any of the CA/Browser forum=E2=80=99s = lists, >>> because neither of us has either a browser or a public CA. >>>=20 >>> There are some people who are active there and are reading this = list, >>> so they might take such a proposal there. I=E2=80=99m not very = optimistic, >>> though. >>=20 >> Please don't give up without even trying! >>=20 >> If you have a proposal, I'd be happy to post it to the >> public@cabforum.org list on your behalf. >=20 > Oh, somebody else beat me to it: >=20 > https://cabforum.org/pipermail/public/2016-March/006910.html Right. And the response was that while PSS in in NSS, it=E2=80=99s not = in Firefox. No word on the other browsers out there, and definitely no = word on a bunch of non-browser clients that connect to servers using = certificates from the public CA. I totally understand that the commercial CAs cannot afford to deprecate = PKCS#1 now. It might be prudent to announce some long-term deprecation = plan such as the one for SHA-1 signatures. We can hope that by the time the transition is complete RSA will have = been abandoned in favor of ECDSA and/or EDDSA, but I would not bet on = it. Yoav From nobody Wed Mar 2 07:01:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150661B2B59 for ; Wed, 2 Mar 2016 06:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.908 X-Spam-Level: X-Spam-Status: No, score=-106.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz1V0D8G06Wf for ; Wed, 2 Mar 2016 06:34:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A03371B2B5F for ; Wed, 2 Mar 2016 06:34:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 6E6C1180004; Wed, 2 Mar 2016 06:33:13 -0800 (PST) To: sblakewilson@safenet-inc.com, nelson@bolyard.com, vipul.gupta@sun.com, chris@corriente.net, bodo@openssl.org, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160302143313.6E6C1180004@rfc-editor.org> Date: Wed, 2 Mar 2016 06:33:13 -0800 (PST) Archived-At: X-Mailman-Approved-At: Wed, 02 Mar 2016 07:01:07 -0800 Cc: rfc-editor@rfc-editor.org, tls@ietf.org Subject: [TLS] [Editorial Errata Reported] RFC4492 (4633) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 14:34:11 -0000 The following errata report has been submitted for RFC4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=4633 -------------------------------------- Type: Editorial Reported by: Kurt Roeckx Section: 5.1.1 Original Text ------------- struct { NamedCurve elliptic_curve_list<1..2^16-1> } EllipticCurveList; Corrected Text -------------- struct { NamedCurve elliptic_curve_list<2..2^16-1> } EllipticCurveList; Notes ----- The count is in bytes, not items. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4492 (draft-ietf-tls-ecc-12) -------------------------------------- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Publication Date : May 2006 Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Mar 2 07:32:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EEF31A88D3; Wed, 2 Mar 2016 07:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X8NhhSTmXzN; Wed, 2 Mar 2016 07:31:58 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526A01A88C6; Wed, 2 Mar 2016 07:31:57 -0800 (PST) X-AuditID: c1b4fb2d-f79836d000006396-46-56d7076afd64 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.FB.25494.A6707D65; Wed, 2 Mar 2016 16:31:55 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.59) with Microsoft SMTP Server id 14.3.248.2; Wed, 2 Mar 2016 16:31:54 +0100 To: Marc Petit-Huguenin , Dave Garrett , References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> From: Magnus Westerlund Message-ID: <56D7076A.1020703@ericsson.com> Date: Wed, 2 Mar 2016 16:31:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56CA239F.6010107@acm.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2K7pW42+/Uwg/8XWSxe9qxkt1j+p4vR 4sKau0wWn853MTqweFy+4u2xc9Zddo8lS34yBTBHcdmkpOZklqUW6dslcGW0XLvKVtCsWfHk xWv2BsbNSl2MnBwSAiYSz87PYoSwxSQu3FvP1sXIxSEkcJhRor1vIiuEs4xRYsvaayxdjBwc wgJeEiv2ZIM0iAgkS9ydvRqsWUhgJ6PEyX5xEJtZQEji9JxvrCA2m4CFxM0fjWwgNq+AtsTq 5l1g9SwCKhIf759jAbFFBWIkjr87xwhRIyhxcuYTsDingLrE8nn3GUHWMgvYSzzYWgYxXl6i eetsZoi12hINTR2sExgFZyHpnoXQMQtJxwJG5lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsY gWF8cMtv3R2Mq187HmIU4GBU4uH9IHctTIg1say4MvcQowQHs5IIbzzL9TAh3pTEyqrUovz4 otKc1OJDjNIcLErivGyfLocJCaQnlqRmp6YWpBbBZJk4OKUaGOfbWLpMmRzKzOA2y2BOp6OJ TIDawcrElozVWbIehl8mOnF0ryqe8rewXGP10zOHJ7A4xslWz62ZofqleOqtcr05Tu+3+Ms+ 8Pv7VoQ9liV9BcsHudN874w3HJ2iHJU8Qer6rxkCcY01cgvS1f0u7rwkZ/Po14XVdZNDXdtf bzliKts19dTsJCWW4oxEQy3mouJEAINYWm1fAgAA Archived-At: Cc: avt@ietf.org Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 15:32:00 -0000 Hi Dave and TLS WG, To my understanding the changes proposed by the draft-ietf-avtcore-rfc5764-mux-fixes is not an issue if any TLS 1.3+ extension, i.e. any TLS extension that is not to be used in 1.0-1.2 can safely be allocated in the reserved range as they will not be externally visible. Such a simple motivation fulfil the coordination requirement as I see it. As the AVTCORE WG chair and document shepherd I will continue with a publication request as soon as I done the paper work for it. If you have any additional feedback on this, then please provide it now. Cheers Magnus Westerlund AVTCORE WG chair Den 2016-02-21 kl. 21:52, skrev Marc Petit-Huguenin: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 02/07/2016 11:17 PM, Dave Garrett wrote: >> Permanently gobbling up the majority of the codespace feels like >> excessive force here. > > This is not what the RFC-to-be is proposing. We are just marking the values that can create an issue when used with RFC 5764 as reserved, with a note in the IANA registry that ask to read the RFC-to-be to understand the problem. If a new proposed ContentType codepoint will never ever be used in the context of RTCWeb, then it can be allocated in the reserved range. > >> For TLS 1.3, the first byte will always be one >> of alert(21), handshake(22), or application_data(23), even for custom >> types. The stated type for TLSCiphertext has been frozen to >> application_data(23) with the actual type for the payload now in the >> encrypted fragment. (this is of course assuming we don't eventually >> drop the frozen type & version here, which now sounds unlikely if >> we're having to deal with design flaws like this) Even handshake >> records after the hellos will have an opaque_type of >> application_data(23), with the encrypted fragment.type containing the >> actual handshake(22) designation. All TLS 1.3+ packets will be >> detected with the RFC 5764 Section 5.1.2 algorithm even if new types >> are allocated in the proposed reserved ranges. >> >> Locking down the <1.2 registry seems fine, however 1.3+ should be >> able to do whatever it needs as its encrypted type is not going to >> get accidentally read & misinterpreted by anything. >> >> https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 >> https://tools.ietf.org/html/rfc5764#section-5.1.2 >> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05#section-4 >> >> >> >> Dave >> >> >> On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: >>> This document is relevant to the TLS working because it reserves a >>> large portion of the TLS content type space. The values 0-19 and >>> 64-255 cannot be used without checking for conflicts with >>> SRTP-DTLS's wacky demultiplexing scheme. In TLS 1.3 we will move >>> more encrypted content types which should limit the impact this >>> unfortunate design on TLS evolution, but the working group should >>> be aware of this. >>> >>> >>> On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund >>> wrote: >>> >>>> AVTCORE and TLS, >>>> >>>> TLS WG, you are included in this WG last call, as this document >>>> affects the TLS ContentType IANA registry. >>>> >>>> This email starts a two week WG last call, that ends on the 10th >>>> of February. The intended status of this document is standards >>>> track (Proposed Standard). >>>> >>>> The document can be retrieved here: >>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > - -- >>>> > Marc Petit-Huguenin > Email: marc@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBCAAGBQJWyiOZAAoJECnERZXWan7EpAwQALT42q+uWbjk9qfPZmJI4dzU > EKhNuQw+yJZ6Pk0TO5EbLtbLb0U9huWIXfL/qnMhoZKmtyBI05yL08KIIucJQJ74 > Y/vTcVuYhminD4Ug8p4ytu9v5RotexQFbomFKqZP3TC0hCISrrWbbg+LU0EEPpZM > jT+D8pYdzAXGEYQvZ8k9xq/rjZfksYLjQOUPLHgoCC1L3wzr3xvswKQ7c0NEoSC8 > rDbVxTp4f+q15W3/HG29+wFN6npgapFK49bXPzAR2LYTHO8yw6mHpHMEd3zq9Kd/ > HsdOWH2ETqFiLOaszFO+rzQPx+/OsEwZWDTf2tcKLamogCoKfRJKICmFWAvHSf9G > 56aiBiwL6kdKZHIcOJ4zQZqG7UdZ1pVy78czPfkjSwB8TD1RMFXNwS6WTgF9RmYy > Ixe1lrvzOdfrL02NvGz2DdEAM7ETS9ujIxbrOUTEg6d7IDJ7FQdT97zHxvCUfjLY > kDd4RtVqIr825+78uJxeXCJ5fZfXOG0VbwpwlC2smyxHUUVwTWQMCJ32EvZynuFo > f7yNMkdSolr3C2Bkt5ELwnKxUtiTqFMZj52rtBzhqAN6iDt289JSvO1e87EORBin > N1ingAw1bEJz1raNF0uA8u7N12QUtAsPrc9hYpmYjxl6I3+d/lFevvmWne/YbWbU > UduqXpPezcNInD7bMDOD > =J64B > -----END PGP SIGNATURE----- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Mar 2 07:58:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A231ACD47 for ; Wed, 2 Mar 2016 07:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 0mb6TAOysHUb for ; Wed, 2 Mar 2016 07:58:05 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50F8D1ACD05 for ; Wed, 2 Mar 2016 07:58:05 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id u9so93387601ykd.1 for ; Wed, 02 Mar 2016 07:58:05 -0800 (PST) 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=hbuUjgrW6g6G46PVMvyttngVzou14+DnUJJW2DHVvjw=; b=Jnz4K6zjdGWryRsMgDqwCEJsAluQHE+BRBBVGQ2RUGhbgrjKvIiCIKsqit7Ww/7+XZ GlwvW9hcscP2LpPuI/5rAbfJ7XB7wkLtmRhbMENSBF2JfZIJJ8J2NP5A9cdokTxt1MZW 7X0urNq6QYog+FEWyofnEYrUfRsvFev43Tj7F8C5sygWuCMUM92XQ1UqR+mqmBuzIeRI iejoAa2wGLOTYdbKyVH2hVfZoljgg1Tx0nkwgwAlUGTbHA9P3QVInXsqDL0hjFD/Djr3 mW7yELArRr1LN1JV9IYLUZRXwsuglsL4YOPSGpZYLNfoYVUbyRQ8aegTUMMxyQ2tiFc4 28hA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hbuUjgrW6g6G46PVMvyttngVzou14+DnUJJW2DHVvjw=; b=lSD1X52p3/pdjuZiPE4vmVWS9/1ueBrDIpSBQz1m2KoP8pxLb1ZJERIxHpLvpaAWGT SqPhdRuJ+GNJwu0XmYQAeqAXSs3VowZUqjkeBbMRcuDTdYSI+JJsHBybX+WHh+PtYdrT 7Ui2schaIjRl+Cn2FQNZERv11xKNzf80K8sreQ+pYKj6DNAmQD1+pELQHXBYH+L8Scz0 S7Gxq1jawtwtd2oTSPsRnJaRb2KtepFrafv2ZwoLIlenSwsHz+ffKUSHyhZzRCr0TUPu cU6VKLsgiZyyUL25GZkDq9rX9LepU20qwAf+XFQG9l0DJzZusltzcoH+NIqqjRTRsZ0W BcUg== X-Gm-Message-State: AD7BkJIcvlAvpenVrdYK/9kYua3R/5/FZiPWABVRx55VXtrgQj1T3C7hcb33ptld7Sgfcf1g4riU9tkxYLwx6g== X-Received: by 10.37.101.11 with SMTP id z11mr15082647ybb.162.1456934284457; Wed, 02 Mar 2016 07:58:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 2 Mar 2016 07:57:24 -0800 (PST) In-Reply-To: <7BA6CABC-077A-4DAA-BF9C-FE1209FD32C0@gmail.com> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <56D6AE21.7050108@comodo.com> <56D6AF5B.5010103@comodo.com> <7BA6CABC-077A-4DAA-BF9C-FE1209FD32C0@gmail.com> From: Eric Rescorla Date: Wed, 2 Mar 2016 07:57:24 -0800 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a1142fbe67cad72052d12f2a9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 15:58:07 -0000 --001a1142fbe67cad72052d12f2a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir wrote: > > > On 2 Mar 2016, at 11:16 AM, Rob Stradling > wrote: > > > > On 02/03/16 09:10, Rob Stradling wrote: > > > >>> Neither you nor I can post in any of the CA/Browser forum=E2=80=99s l= ists, > >>> because neither of us has either a browser or a public CA. > >>> > >>> There are some people who are active there and are reading this list, > >>> so they might take such a proposal there. I=E2=80=99m not very optimi= stic, > >>> though. > >> > >> Please don't give up without even trying! > >> > >> If you have a proposal, I'd be happy to post it to the > >> public@cabforum.org list on your behalf. > > > > Oh, somebody else beat me to it: > > > > https://cabforum.org/pipermail/public/2016-March/006910.html > > Right. And the response was that while PSS in in NSS, it=E2=80=99s not in= Firefox. > No word on the other browsers out there, and definitely no word on a bunc= h > of non-browser clients that connect to servers using certificates from th= e > public CA. > For what it's worth, I expect PSS support to appear in Firefox sometime in the not too distant future, since it's clear we need it for 1.3 and it's not much effort to add it for 1.2 and below. -Ekr I totally understand that the commercial CAs cannot afford to deprecate > PKCS#1 now. It might be prudent to announce some long-term deprecation pl= an > such as the one for SHA-1 signatures. > > We can hope that by the time the transition is complete RSA will have bee= n > abandoned in favor of ECDSA and/or EDDSA, but I would not bet on it. > > Yoav > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1142fbe67cad72052d12f2a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On 2 Mar 2016, at 11:16 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
>
> On 02/03/16 09:10, Rob Stradling wrote:
> <snip>
>>> Neither you nor I can post in any of the CA/Browser forum=E2= =80=99s lists,
>>> because neither of us has either a browser or a public CA.
>>>
>>> There are some people who are active there and are reading thi= s list,
>>> so they might take such a proposal there. I=E2=80=99m not very= optimistic,
>>> though.
>>
>> Please don't give up without even trying!
>>
>> If you have a proposal, I'd be happy to post it to the
>> public@cabforum.org lis= t on your behalf.
>
> Oh, somebody else beat me to it:
>
> https://cabforum.org/pipermail/publ= ic/2016-March/006910.html

Right. And the response was that while PSS in in NSS, it=E2=80=99s n= ot in Firefox. No word on the other browsers out there, and definitely no w= ord on a bunch of non-browser clients that connect to servers using certifi= cates from the public CA.

For what it&#= 39;s worth, I expect PSS support to appear in Firefox sometime in the
=
not too distant future, since it's clear we need it for 1.3 and it= 's not much effort
to add it for 1.2 and below.
-Ekr

I totally understand that the commercial CAs cannot afford to deprecate PKC= S#1 now. It might be prudent to announce some long-term deprecation plan su= ch as the one for SHA-1 signatures.

We can hope that by the time the transition is complete RSA will have been = abandoned in favor of ECDSA and/or EDDSA, but I would not bet on it.

Yoav

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

--001a1142fbe67cad72052d12f2a9-- From nobody Wed Mar 2 09:08:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807181B2C9D for ; Wed, 2 Mar 2016 09:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FXuPLCyclZF for ; Wed, 2 Mar 2016 09:08:16 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA981B2C76 for ; Wed, 2 Mar 2016 09:08:15 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id l68so89581150wml.0 for ; Wed, 02 Mar 2016 09:08:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=73j1L1qfD2G9GaGwBoKgfAXsi7EPmkEdHPC+8WG5zas=; b=V8x6+1jFU3Gcj/UCfcwNY2x8aIzYc6/UDFJ4jF+CAfT1A60AOLTK0aouGOX2pUK+2u 3/x6/s/FItllcVyYF+elSZrPRuCcCl80tKH4L+jCisq3PAZbux25l8NDPCR08V9c2iUx SizDXXdHvpQd1b+h6SMXwrklFGFKbNFAU98+2Gmr7m8/6Z+fFg4ONus/5UcNiLtiGQGU W6NrOjTvzm+ND7pIORBfpgk0tZIJ2zp5NKjT0k1WyOWFJID/Yv5LPTBnTrOY97GBldBP nX5fb5UXQ2jGqMFVQMOOcWcjbsi9slkp2Ab9ZLUaxOh02TZey6Yx2F6XPy+5ckab4pCK vK3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=73j1L1qfD2G9GaGwBoKgfAXsi7EPmkEdHPC+8WG5zas=; b=Xre6HQgxQvLU/HDKp6IjwmIsxcBgzMa4HwL+ggDVfyx5c6ZYExr+iOS6Y6gbM4Mx2N MoBMai/u8YDVxocF/0LtFqIMfMOdwo/5XmbM0LxK+kjS2FZcCqmz0MxftMMUjuUyCOtI I27qcgVy76Yxfs7ElHvhCsf25juC62hQRmnhuzXAvF86n/hxsvWamO/B84HBjEfBOAvV zDiRiEcQmgi4pjv25wrtbntKT4Aeoop2MGGCmm8yRAGXpeEH3SmfCuJAH0xG3k313kNO tZwOaVhihztMDJR5QYpC0tu0iaYYCHCotEyJNd9jyXcx0XFT/5YUNineqvRpb/THjIRm dfjQ== X-Gm-Message-State: AD7BkJKgQ+s6NgAT098soxqX3ThdkYwnuR9lk8AsCFGcGes4AddVNZbDl5njGdSBGxsq9Q== X-Received: by 10.28.223.8 with SMTP id w8mr1063101wmg.54.1456938493968; Wed, 02 Mar 2016 09:08:13 -0800 (PST) Received: from [192.168.137.52] ([176.13.4.189]) by smtp.gmail.com with ESMTPSA id m67sm5033110wma.10.2016.03.02.09.08.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 02 Mar 2016 09:08:13 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B7F5F7F0-3015-4DF4-8BBA-22ACF1373582" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Wed, 2 Mar 2016 19:08:10 +0200 Message-Id: <9A7EEFD6-1D76-4583-9C3E-EC7F6768FE16@gmail.com> References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> <56D51FFB.9050909@brainhub.org> <56D5DE1D.3000708@akr.io> <56D6AE21.7050108@comodo.com> <56D6AF5B.5010103@comodo.com> <7BA6CABC-077A-4DAA-BF9C-FE1209FD32C0@gmail.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 17:08:22 -0000 --Apple-Mail=_B7F5F7F0-3015-4DF4-8BBA-22ACF1373582 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Mar 2016, at 5:57 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Wed, Mar 2, 2016 at 1:25 AM, Yoav Nir > wrote: >=20 > > On 2 Mar 2016, at 11:16 AM, Rob Stradling > wrote: > > > > On 02/03/16 09:10, Rob Stradling wrote: > > > >>> Neither you nor I can post in any of the CA/Browser forum=E2=80=99s = lists, > >>> because neither of us has either a browser or a public CA. > >>> > >>> There are some people who are active there and are reading this = list, > >>> so they might take such a proposal there. I=E2=80=99m not very = optimistic, > >>> though. > >> > >> Please don't give up without even trying! > >> > >> If you have a proposal, I'd be happy to post it to the > >> public@cabforum.org list on your = behalf. > > > > Oh, somebody else beat me to it: > > > > https://cabforum.org/pipermail/public/2016-March/006910.html = >=20 > Right. And the response was that while PSS in in NSS, it=E2=80=99s not = in Firefox. No word on the other browsers out there, and definitely no = word on a bunch of non-browser clients that connect to servers using = certificates from the public CA. >=20 > For what it's worth, I expect PSS support to appear in Firefox = sometime in the > not too distant future, since it's clear we need it for 1.3 and it's = not much effort > to add it for 1.2 and below. I expect the version of our firewall that comes out in 2017 will support = PSS as well in TLS and the PKI. The enterprise CA part of the product? = Probably not because it has to support the legacy. Yoav --Apple-Mail=_B7F5F7F0-3015-4DF4-8BBA-22ACF1373582 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 2 Mar 2016, at 5:57 PM, Eric Rescorla <ekr@rtfm.com> = wrote:



On Wed, Mar 2, 2016 = at 1:25 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 2 Mar 2016, at 11:16 AM, Rob Stradling <rob.stradling@comodo.com> wrote:
>
> On 02/03/16 09:10, Rob Stradling wrote:
>= <snip>
>>> Neither you nor I can post in = any of the CA/Browser forum=E2=80=99s lists,
>>> = because neither of us has either a browser or a public CA.
>>>
>>> There are some people = who are active there and are reading this list,
>>>= so they might take such a proposal there. I=E2=80=99m not very = optimistic,
>>> though.
>>
>> Please don't give up without even trying!
>>
>> If you have a proposal, I'd = be happy to post it to the
>> public@cabforum.org list on your behalf.
>
> Oh, somebody else beat me to it:
>
> https://cabforum.org/pipermail/public/2016-March/006910.html

Right. And the response was that = while PSS in in NSS, it=E2=80=99s not in Firefox. No word on the other = browsers out there, and definitely no word on a bunch of non-browser = clients that connect to servers using certificates from the public = CA.

For what it's worth, I expect PSS support to appear in = Firefox sometime in the
not too distant future, = since it's clear we need it for 1.3 and it's not much effort
to add it for 1.2 and = below.




= --Apple-Mail=_B7F5F7F0-3015-4DF4-8BBA-22ACF1373582-- From nobody Wed Mar 2 13:16:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AABB11B3106 for ; Wed, 2 Mar 2016 13:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNJM67YuQocD for ; Wed, 2 Mar 2016 13:16:18 -0800 (PST) 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 50AE11B3104 for ; Wed, 2 Mar 2016 13:16:18 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id g127so1580126ywf.2 for ; Wed, 02 Mar 2016 13:16:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=s/TYkJ57V6vTmkPy4NWTdNbhE1kiLrpEOr7wI5ni+Zs=; b=z/A6Hgi7Mw9rtuT0Z75tMYeBxpjLlJ849ykT42zc3IG8aI/3iStbwRIp0yrlgBajeR t66Bew9NIdCbet5GxllJU/UJVjmGCbVyIjxjREsnOrEkaLakL8sIFtxfVwALqlPn2DtY P4cgYLDVOzCZ0DQ20JS0oszdL909eUqX6XBso3oAZn2tpkXg9Fdiiu0OqTPM1NhUYYYp K7meyCiqJVhgXov7eytnBzm00ZkXr4Z8D+3mRSzHkEFqIrpnw6UX9z2RXkr9BEP09ZsW 7T2gsM326VOotqhUO737G9/06xzT4oTx5CP5nBlhetNUr+6hynwwwHak0zgTPer/MxuK sK2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=s/TYkJ57V6vTmkPy4NWTdNbhE1kiLrpEOr7wI5ni+Zs=; b=bJ2JE2yUXeG5hH9M/faEmXzIvBAT1GxjOJCexYXJ5Q+I/JTougM8F48muAWyj+l4ih fFyuttfv/03r0FhfLAXKL2TGiQYT2yEgUMmuOCl/Gcle1I73uUo9d8CCLbRMMXWxelOU lfydWnYtUmzldSkMj/7AxhtQNWcg7fvnZ0CsPSXNa0Qc435Fw6zXsbaM2ZrC1i7xq1wN /r56VOrBv0cBXvdfC7DUBfvybUsz8LhX/mutaIEM5L8YmRBi7CwV9xead02f/xlTC9xi fgaARZmJ0Ckb51xKWxpgYcolPQQFKJhq0eFP1B/3NSHj7LRkSfMtnEq+2f/+TVfwiOSu D8tw== X-Gm-Message-State: AD7BkJKW6x/f+7djgEH2snfGZ2zZkCLw/ZIcMtR47gI6z8Oy6Gj7/QGnP0g3gStkK5KxHQ== X-Received: by 10.13.220.197 with SMTP id f188mr15860551ywe.172.1456953377695; Wed, 02 Mar 2016 13:16:17 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id e132sm29901209ywa.18.2016.03.02.13.16.16 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 02 Mar 2016 13:16:16 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Wed, 2 Mar 2016 16:16:15 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20160302065747.GC10917@mournblade.imrryr.org> In-Reply-To: <20160302065747.GC10917@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201603021616.15731.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 21:16:19 -0000 On Wednesday, March 02, 2016 01:57:48 am Viktor Dukhovni wrote: > adaptive attacks are I think a greater potential > threat against interactive TLS than against a bunch of CA-authored > bits at rest. +1 From nobody Wed Mar 2 14:08:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231DC1B32A4 for ; Wed, 2 Mar 2016 14:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.678 X-Spam-Level: X-Spam-Status: No, score=-0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=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 pSYJZKXMvKbD for ; Wed, 2 Mar 2016 14:08:50 -0800 (PST) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 080211B32A7 for ; Wed, 2 Mar 2016 14:08:50 -0800 (PST) Received: by mail-lb0-x233.google.com with SMTP id k15so1787232lbg.0 for ; Wed, 02 Mar 2016 14:08:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QAp1M6XeGalusA4y25Oi4wGr2+V2aoszyRO3Qm3NoGA=; b=Jx8Hc+SW/YZMbt+AXF0nXI7uN33y8sxUBN0r8iJwugF6a2Qmtgzh+iLE2H+rk/R2ea f3ofHZuAGOf00thr/bq3Edxy+cr7XopJjDm2EpnpRujf+/525xgJNf2OW4sFxgpFuNKP /2fzgd6IlUbcMGsWbBc29XKNzklP/fcTRn8/kC9gAumNoUNdprINaCIZkHmJZKw5YS5G WAN7TcQuqVSHexQDCI3RR8RJgdP5x9IAgqJvJc70xh55mj4dWqX8Gj5BepveEUKIyUtX aFlOWICwSlkaeNWhcbr1r1rxY1Dq6O7FsOLHbOCjwgqv3BYI3DUcbl7P24cw/8/NqQ5t CQiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QAp1M6XeGalusA4y25Oi4wGr2+V2aoszyRO3Qm3NoGA=; b=V9P5PilI9Pes2YpWTkB4QGSBDi27tb4sQH6MlOCH47QdI/xcN4P180J4qEcSwaiiTh DEwWmnE+FNLyk1hCYuzI2SewGr/zohtAjYOsD6UCcUz3UAaFA6p/7Fu/Jv6lxLMi0Crm ZDLo/ZNucv3HB60XzM/8MIqIFWTr/4l4kYMlk4hK1QPk1HGHS0/ykf3MR8pONgU6kjp9 5nKQfAclX2GGLPlKf/bNIkh3qz/mpVqUT4V9tVd4/LIC83uG45/xV+MDdq4to2KMRS9A 7zX2NfyOoDDdIsf4mA2OxE0yiJN3Hj4qsXGUVuhMzMWXuuaLVrNTfXhlaVuGrljTvzjs r18A== X-Gm-Message-State: AD7BkJKglPjTrvBV/kIbMN331ZkdFP+eBWi2cHcyT2kYG8D+0SEraax43TfNOwbM/t9ArvXeL+yEp4QaanySKg== X-Received: by 10.25.169.82 with SMTP id s79mr11341353lfe.47.1456956528066; Wed, 02 Mar 2016 14:08:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.2.104 with HTTP; Wed, 2 Mar 2016 14:08:28 -0800 (PST) In-Reply-To: <56D7076A.1020703@ericsson.com> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> From: Joseph Salowey Date: Wed, 2 Mar 2016 14:08:28 -0800 Message-ID: To: Magnus Westerlund Content-Type: multipart/alternative; boundary=001a114106d84f1770052d1820e9 Archived-At: Cc: "tls@ietf.org" , avt@ietf.org Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 22:08:53 -0000 --001a114106d84f1770052d1820e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Reserving large portions of other protocols number spaces is not a good way to do things. This will quickly become unworkable if other protocols decide to do the same thing. This type of behavior needs to be discouraged. There is no guarantee that the multiplexing scheme prompting this registration request will work with TLS 1.3 or any future version of TLS. On Wed, Mar 2, 2016 at 7:31 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi Dave and TLS WG, > > To my understanding the changes proposed by the > draft-ietf-avtcore-rfc5764-mux-fixes is not an issue if any TLS 1.3+ > extension, i.e. any TLS extension that is not to be used in 1.0-1.2 can > safely be allocated in the reserved range as they will not be externally > visible. Such a simple motivation fulfil the coordination requirement as = I > see it. > > As the AVTCORE WG chair and document shepherd I will continue with a > publication request as soon as I done the paper work for it. If you have > any additional feedback on this, then please provide it now. > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > > > > Den 2016-02-21 kl. 21:52, skrev Marc Petit-Huguenin: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> On 02/07/2016 11:17 PM, Dave Garrett wrote: >> >>> Permanently gobbling up the majority of the codespace feels like >>> excessive force here. >>> >> >> This is not what the RFC-to-be is proposing. We are just marking the >> values that can create an issue when used with RFC 5764 as reserved, wit= h a >> note in the IANA registry that ask to read the RFC-to-be to understand t= he >> problem. If a new proposed ContentType codepoint will never ever be use= d >> in the context of RTCWeb, then it can be allocated in the reserved range= . >> >> For TLS 1.3, the first byte will always be one >>> of alert(21), handshake(22), or application_data(23), even for custom >>> types. The stated type for TLSCiphertext has been frozen to >>> application_data(23) with the actual type for the payload now in the >>> encrypted fragment. (this is of course assuming we don't eventually >>> drop the frozen type & version here, which now sounds unlikely if >>> we're having to deal with design flaws like this) Even handshake >>> records after the hellos will have an opaque_type of >>> application_data(23), with the encrypted fragment.type containing the >>> actual handshake(22) designation. All TLS 1.3+ packets will be >>> detected with the RFC 5764 Section 5.1.2 algorithm even if new types >>> are allocated in the proposed reserved ranges. >>> >>> Locking down the <1.2 registry seems fine, however 1.3+ should be >>> able to do whatever it needs as its encrypted type is not going to >>> get accidentally read & misinterpreted by anything. >>> >>> https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 >>> https://tools.ietf.org/html/rfc5764#section-5.1.2 >>> >>> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05#sec= tion-4 >>> >>> >>> >>> Dave >>> >>> >>> On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: >>> >>>> This document is relevant to the TLS working because it reserves a >>>> large portion of the TLS content type space. The values 0-19 and >>>> 64-255 cannot be used without checking for conflicts with >>>> SRTP-DTLS's wacky demultiplexing scheme. In TLS 1.3 we will move >>>> more encrypted content types which should limit the impact this >>>> unfortunate design on TLS evolution, but the working group should >>>> be aware of this. >>>> >>>> >>>> On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund >>>> wrote: >>>> >>>> AVTCORE and TLS, >>>>> >>>>> TLS WG, you are included in this WG last call, as this document >>>>> affects the TLS ContentType IANA registry. >>>>> >>>>> This email starts a two week WG last call, that ends on the 10th >>>>> of February. The intended status of this document is standards >>>>> track (Proposed Standard). >>>>> >>>>> The document can be retrieved here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes= / >>>>> >>>> >> - -- >> >>> >>>>> Marc Petit-Huguenin >> Email: marc@petit-huguenin.org >> Blog: http://blog.marc.petit-huguenin.org >> Profile: http://www.linkedin.com/in/petithug >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iQIcBAEBCAAGBQJWyiOZAAoJECnERZXWan7EpAwQALT42q+uWbjk9qfPZmJI4dzU >> EKhNuQw+yJZ6Pk0TO5EbLtbLb0U9huWIXfL/qnMhoZKmtyBI05yL08KIIucJQJ74 >> Y/vTcVuYhminD4Ug8p4ytu9v5RotexQFbomFKqZP3TC0hCISrrWbbg+LU0EEPpZM >> jT+D8pYdzAXGEYQvZ8k9xq/rjZfksYLjQOUPLHgoCC1L3wzr3xvswKQ7c0NEoSC8 >> rDbVxTp4f+q15W3/HG29+wFN6npgapFK49bXPzAR2LYTHO8yw6mHpHMEd3zq9Kd/ >> HsdOWH2ETqFiLOaszFO+rzQPx+/OsEwZWDTf2tcKLamogCoKfRJKICmFWAvHSf9G >> 56aiBiwL6kdKZHIcOJ4zQZqG7UdZ1pVy78czPfkjSwB8TD1RMFXNwS6WTgF9RmYy >> Ixe1lrvzOdfrL02NvGz2DdEAM7ETS9ujIxbrOUTEg6d7IDJ7FQdT97zHxvCUfjLY >> kDd4RtVqIr825+78uJxeXCJ5fZfXOG0VbwpwlC2smyxHUUVwTWQMCJ32EvZynuFo >> f7yNMkdSolr3C2Bkt5ELwnKxUtiTqFMZj52rtBzhqAN6iDt289JSvO1e87EORBin >> N1ingAw1bEJz1raNF0uA8u7N12QUtAsPrc9hYpmYjxl6I3+d/lFevvmWne/YbWbU >> UduqXpPezcNInD7bMDOD >> =3DJ64B >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114106d84f1770052d1820e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Reserving large portions of other protocols number spaces = is not a good way to do things. =C2=A0 This will quickly become unworkable = if other protocols decide to do the same thing.=C2=A0 This type of behavior= needs to be discouraged.=C2=A0 There is no guarantee that the multiplexing= scheme prompting this registration request will work with TLS 1.3 or any f= uture version of TLS. =C2=A0=C2=A0

On Wed, Mar 2, 2016 at 7:31 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
Hi Dave and TLS WG,

To my understanding the changes proposed by the draft-ietf-avtcore-rfc5764-= mux-fixes is not an issue if any TLS 1.3+ extension, i.e. any TLS extension= that is not to be used in 1.0-1.2 can safely be allocated in the reserved = range as they will not be externally visible. Such a simple motivation fulf= il the coordination requirement as I see it.

As the AVTCORE WG chair and document shepherd I will continue with a public= ation request as soon as I done the paper work for it. If you have any addi= tional feedback on this, then please provide it now.

Cheers

Magnus Westerlund
AVTCORE WG chair




Den 2016-02-21 kl. 21:52, skrev Marc Petit-Huguenin:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/07/2016 11:17 PM, Dave Garrett wrote:
Permanently gobbling up the majority of the codespace feels like
excessive force here.

This is not what the RFC-to-be is proposing.=C2=A0 We are just marking the = values that can create an issue when used with RFC 5764 as reserved, with a= note in the IANA registry that ask to read the RFC-to-be to understand the= problem.=C2=A0 If a new proposed ContentType codepoint will never ever be = used in the context of RTCWeb, then it can be allocated in the reserved ran= ge.

For TLS 1.3, the first byte will always be one
of alert(21), handshake(22), or application_data(23), even for custom
types. The stated type for TLSCiphertext has been frozen to
application_data(23) with the actual type for the payload now in the
encrypted fragment. (this is of course assuming we don't eventually
drop the frozen type & version here, which now sounds unlikely if
we're having to deal with design flaws like this) Even handshake
records after the hellos will have an opaque_type of
application_data(23), with the encrypted fragment.type containing the
actual handshake(22) designation. All TLS 1.3+ packets will be
detected with the RFC 5764 Section 5.1.2 algorithm even if new types
are allocated in the proposed reserved ranges.

Locking down the <1.2 registry seems fine, however 1.3+ should be
able to do whatever it needs as its encrypted type is not going to
get accidentally read & misinterpreted by anything.

https://tools.ietf.org/html/draft-i= etf-tls-tls13-11#section-5.2.2
https://tools.ietf.org/html/rfc5764#section-5.1.2
https://tools.ietf.org/= html/draft-ietf-avtcore-rfc5764-mux-fixes-05#section-4



Dave


On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote:
This document is relevant to the TLS working because it reserves a
large portion of the TLS content type space.=C2=A0 The values 0-19 and
64-255 cannot be used without checking for conflicts with
SRTP-DTLS's wacky demultiplexing scheme.=C2=A0 =C2=A0In TLS 1.3 we will= move
more encrypted content types which should limit the impact this
unfortunate design on TLS evolution, but the working group should
be aware of this.


On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund
<mag= nus.westerlund@ericsson.com> wrote:

AVTCORE and TLS,

TLS WG, you are included in this WG last call, as this document
affects the TLS ContentType IANA registry.

This email starts a two week WG last call, that ends on the 10th
of February. The intended status of this document is standards
track (Proposed Standard).

The document can be retrieved here:
https://datatracker.ietf.org/d= oc/draft-ietf-avtcore-rfc5764-mux-fixes/

- --

Marc Petit-Huguenin
Email: marc@pe= tit-huguenin.org
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWyiOZAAoJECnERZXWan7EpAwQALT42q+uWbjk9qfPZmJI4dzU
EKhNuQw+yJZ6Pk0TO5EbLtbLb0U9huWIXfL/qnMhoZKmtyBI05yL08KIIucJQJ74
Y/vTcVuYhminD4Ug8p4ytu9v5RotexQFbomFKqZP3TC0hCISrrWbbg+LU0EEPpZM
jT+D8pYdzAXGEYQvZ8k9xq/rjZfksYLjQOUPLHgoCC1L3wzr3xvswKQ7c0NEoSC8
rDbVxTp4f+q15W3/HG29+wFN6npgapFK49bXPzAR2LYTHO8yw6mHpHMEd3zq9Kd/
HsdOWH2ETqFiLOaszFO+rzQPx+/OsEwZWDTf2tcKLamogCoKfRJKICmFWAvHSf9G
56aiBiwL6kdKZHIcOJ4zQZqG7UdZ1pVy78czPfkjSwB8TD1RMFXNwS6WTgF9RmYy
Ixe1lrvzOdfrL02NvGz2DdEAM7ETS9ujIxbrOUTEg6d7IDJ7FQdT97zHxvCUfjLY
kDd4RtVqIr825+78uJxeXCJ5fZfXOG0VbwpwlC2smyxHUUVwTWQMCJ32EvZynuFo
f7yNMkdSolr3C2Bkt5ELwnKxUtiTqFMZj52rtBzhqAN6iDt289JSvO1e87EORBin
N1ingAw1bEJz1raNF0uA8u7N12QUtAsPrc9hYpmYjxl6I3+d/lFevvmWne/YbWbU
UduqXpPezcNInD7bMDOD
=3DJ64B
-----END PGP SIGNATURE-----

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



--

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--001a114106d84f1770052d1820e9-- From nobody Wed Mar 2 14:20:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358571B32DE; Wed, 2 Mar 2016 14:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 HMH4uQTqFBQa; Wed, 2 Mar 2016 14:20:16 -0800 (PST) Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id 17E341B32DD; Wed, 2 Mar 2016 14:20:16 -0800 (PST) Received: from [IPv6:2602:ae:1762:1200:b842:b7a9:cab9:49c1] (unknown [IPv6:2602:ae:1762:1200:b842:b7a9:cab9:49c1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 756EB20171; Wed, 2 Mar 2016 23:20:14 +0100 (CET) To: Joseph Salowey , Magnus Westerlund References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> From: Marc Petit-Huguenin Message-ID: <56D76716.1090506@acm.org> Date: Wed, 2 Mar 2016 15:20:06 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="OV3W3pWxO5KvCk6pwdeR7Tuurxa1uBAfS" Archived-At: Cc: "tls@ietf.org" , avt@ietf.org Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 22:20:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OV3W3pWxO5KvCk6pwdeR7Tuurxa1uBAfS Content-Type: multipart/mixed; boundary="3EeC5iFKnse7e6gNnV39kLrmF8mkUfUOK" From: Marc Petit-Huguenin To: Joseph Salowey , Magnus Westerlund Cc: "tls@ietf.org" , avt@ietf.org, Dave Garrett Message-ID: <56D76716.1090506@acm.org> Subject: Re: [AVTCORE] [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> In-Reply-To: --3EeC5iFKnse7e6gNnV39kLrmF8mkUfUOK Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/02/2016 03:08 PM, Joseph Salowey wrote: > Reserving large portions of other protocols number spaces is not a good= way > to do things. This will quickly become unworkable if other protocols > decide to do the same thing. This type of behavior needs to be > discouraged. There is no guarantee that the multiplexing scheme prompt= ing > this registration request will work with TLS 1.3 or any future version = of > TLS. draft-ietf-avtcore-rfc5764-mux-fixes does not reserve large portions of t= he ContentType codepoints, RFC 5764 did. The damage is already done as R= FC 5764 is deployed as a component of RTCWeb. This draft just put an emphasis on the fact that allocating ContentType c= odepoints in the ranges that *RFC5764* reserved can have consequences. >=20 > On Wed, Mar 2, 2016 at 7:31 AM, Magnus Westerlund < > magnus.westerlund@ericsson.com> wrote: >=20 >> Hi Dave and TLS WG, >> >> To my understanding the changes proposed by the >> draft-ietf-avtcore-rfc5764-mux-fixes is not an issue if any TLS 1.3+ >> extension, i.e. any TLS extension that is not to be used in 1.0-1.2 ca= n >> safely be allocated in the reserved range as they will not be external= ly >> visible. Such a simple motivation fulfil the coordination requirement = as I >> see it. >> >> As the AVTCORE WG chair and document shepherd I will continue with a >> publication request as soon as I done the paper work for it. If you ha= ve >> any additional feedback on this, then please provide it now. >> >> Cheers >> >> Magnus Westerlund >> AVTCORE WG chair >> >> >> >> >> Den 2016-02-21 kl. 21:52, skrev Marc Petit-Huguenin: >> > On 02/07/2016 11:17 PM, Dave Garrett wrote: >=20 >>>>> Permanently gobbling up the majority of the codespace feels like >>>>> excessive force here. >>>>> >=20 > This is not what the RFC-to-be is proposing. We are just marking the > values that can create an issue when used with RFC 5764 as reserved, wi= th a > note in the IANA registry that ask to read the RFC-to-be to understand = the > problem. If a new proposed ContentType codepoint will never ever be us= ed > in the context of RTCWeb, then it can be allocated in the reserved rang= e. >=20 > For TLS 1.3, the first byte will always be one >>>>> of alert(21), handshake(22), or application_data(23), even for cust= om >>>>> types. The stated type for TLSCiphertext has been frozen to >>>>> application_data(23) with the actual type for the payload now in th= e >>>>> encrypted fragment. (this is of course assuming we don't eventually= >>>>> drop the frozen type & version here, which now sounds unlikely if >>>>> we're having to deal with design flaws like this) Even handshake >>>>> records after the hellos will have an opaque_type of >>>>> application_data(23), with the encrypted fragment.type containing t= he >>>>> actual handshake(22) designation. All TLS 1.3+ packets will be >>>>> detected with the RFC 5764 Section 5.1.2 algorithm even if new type= s >>>>> are allocated in the proposed reserved ranges. >>>>> >>>>> Locking down the <1.2 registry seems fine, however 1.3+ should be >>>>> able to do whatever it needs as its encrypted type is not going to >>>>> get accidentally read & misinterpreted by anything. >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 >>>>> https://tools.ietf.org/html/rfc5764#section-5.1.2 >>>>> >>>>> https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05= #section-4 >>>>> >>>>> >>>>> >>>>> Dave >>>>> >>>>> >>>>> On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: >>>>> >>>>>> This document is relevant to the TLS working because it reserves a= >>>>>> large portion of the TLS content type space. The values 0-19 and >>>>>> 64-255 cannot be used without checking for conflicts with >>>>>> SRTP-DTLS's wacky demultiplexing scheme. In TLS 1.3 we will move= >>>>>> more encrypted content types which should limit the impact this >>>>>> unfortunate design on TLS evolution, but the working group should >>>>>> be aware of this. >>>>>> >>>>>> >>>>>> On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund >>>>>> wrote: >>>>>> >>>>>> AVTCORE and TLS, >>>>>>> >>>>>>> TLS WG, you are included in this WG last call, as this document >>>>>>> affects the TLS ContentType IANA registry. >>>>>>> >>>>>>> This email starts a two week WG last call, that ends on the 10th >>>>>>> of February. The intended status of this document is standards >>>>>>> track (Proposed Standard). >>>>>>> >>>>>>> The document can be retrieved here: >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-f= ixes/ >>>>>>> >>>>>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> >> -- >> >> Magnus Westerlund >> >> ----------------------------------------------------------------------= >> Services, Media and Network features, Ericsson Research EAB/TXM >> ----------------------------------------------------------------------= >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ----------------------------------------------------------------------= >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug --3EeC5iFKnse7e6gNnV39kLrmF8mkUfUOK-- --OV3W3pWxO5KvCk6pwdeR7Tuurxa1uBAfS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW12cWAAoJECnERZXWan7EtJ4QAIl7NdIhWVkEurfi4B5m3Ug/ KTauIkXIpv8Jb+UqDdK4WizvlK1tX5msFWdZpykZDnFboPBGGQvvkByCgfo1MPOu c9691Z3/mfu8abmu+8Eo+2IdS1xdvrLF1Mbjx3YBO6K/y8grysLFA3tv62sNHk1S NWswxy3Ac+hTrcYNeZxvzLI7r4LeWkZxfW+HRdzF5H1GgLPxUlvSZKOZ7cwfrA5P Z0wDQQ6nSwR9azntPeZ4h40Wske06vp9c/f+cJBfzLZKlOa1RNBcNYOTCa3sPMRc s735a61SPviFhQqohpJpTjpLrZM8nKXWbHZbTNIivbyZyvomZkzlczJ1NIu3SYyj WawbGoBBh6bT7uuGLjgO1sj6fBzWnEbxpJA4slpD2xYZbF1/AZnDHKXH9JbSbEar YUgetFtYPEBJquzsh6M4QWh+x0A7PwLVITiv5Hkum2PFWX3z4zq/5c+iccxWhnFN m2EDbGO7TMUsKK64EKEpoFJcHhqCuDPritqPc4xcGi8Avh4jiToBDZ5tUfs757jZ 7lM3wOMScLbEvtUoswrlcAyW6vxAJsDuQRo3ANDRBnoLqEdd2/IFxz1YTnoOrLVm oqsS0fMNklz9S7oe6AddU/aJsTQ3mSpq1i6punaCNj2WJsSeKQdsOr0IvwhB7epg ghIo9qVQxuYxt6EdrDzL =vpwA -----END PGP SIGNATURE----- --OV3W3pWxO5KvCk6pwdeR7Tuurxa1uBAfS-- From nobody Wed Mar 2 14:22:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BC81B32E7 for ; Wed, 2 Mar 2016 14:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FMUgji7kbrzn for ; Wed, 2 Mar 2016 14:22:32 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 082DE1B32E6 for ; Wed, 2 Mar 2016 14:22:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id EBBAF19C4; Thu, 3 Mar 2016 00:22:21 +0200 (EET) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 2GSpm29XtToR; Thu, 3 Mar 2016 00:22:21 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A84DE28D; Thu, 3 Mar 2016 00:22:21 +0200 (EET) Date: Thu, 3 Mar 2016 00:22:16 +0200 From: Ilari Liusvaara To: Joseph Salowey Message-ID: <20160302222216.GA12028@LK-Perkele-V2.elisa-laajakaista.fi> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 22:22:34 -0000 On Wed, Mar 02, 2016 at 02:08:28PM -0800, Joseph Salowey wrote: > Reserving large portions of other protocols number spaces is not a good way > to do things. This will quickly become unworkable if other protocols > decide to do the same thing. This type of behavior needs to be > discouraged. There is no guarantee that the multiplexing scheme prompting > this registration request will work with TLS 1.3 or any future version of > TLS. Well, outside of some very exotic extensions (none are defined to date, and I'm having problems even imagining what such things would actually do), it would work in TLS 1.3 Editor's Draft (since it only ever uses 21, 22 and 23[1]). Future versions of TLS are another matter... And even if there was some extension to omit the version from record header, it would still work (the demuxer would however need to be aware of that extension). [1] For comparision, TLS 1.2 uses 21-23 and also 20 and in presence of certain (infamous) extension, 24. -Ilari From nobody Wed Mar 2 14:44:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A17581B335B for ; Wed, 2 Mar 2016 14:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 A9kHFOrJEdge for ; Wed, 2 Mar 2016 14:44:21 -0800 (PST) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 2215E1B3358 for ; Wed, 2 Mar 2016 14:44:21 -0800 (PST) Received: by mail-lb0-x232.google.com with SMTP id of3so2604571lbc.1 for ; Wed, 02 Mar 2016 14:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vouscNWsOMkKiCxSY1dHASjjtmiBu09HOORMKDdLYGI=; b=ZUluR69jpYYFpQuJqeeoLUPuSy5SpFhHW9Kcl2wLgHTGa91rL1+AG6f731YNC2aMUY pGonJx/zQfPbFQl6pQS264rSE/2zpS1AGHRwWv9+mv+PQUz61oQxCjx3eDwRccrmpH/F fpvAeR8hybyZii/YzX6sRe6Y+stpzLyAiHyCYamcCH6lzirzWqhcgx2FzPKKsVOiyVci lOUftgRz9WzmJGXef0rYyMnPzXPhS2TMTwdcxUQlxoulFFx+0gJBwKaVTG4By4wYRAt8 QbPtLlq3tcX9+KWYHydGlL+/wexqALDpXDdHBpNigK3LBqzyhHr0UXmV3nadFIVwWboF otPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vouscNWsOMkKiCxSY1dHASjjtmiBu09HOORMKDdLYGI=; b=I2PwvSYCvdsyi7GyUiw3UDm2z9S7Wy59Fvo/ReyHqRnPJpqtOrFnalnY5mofypVfmS LNK23PGxspBzRGhS5QK1eHprYlHhHVFwRXKiwcRaWZ4ZackI08qWVYcj8oODDzVghKn5 ew+QbsJQQabB97h3N3vBLZvfWPUap4GlRS5kvQSkK2yX3JO8JtoF6D4vL4qYzt0wFHBk SNZVOdyIP8PNH6NZY0nmtOSQuvU9+JP7UhVGN7phersLGbCc9KkbZ7LxeUEkGlw+/OJa e5zmWdAR9B2t/8nGW9vVJbAjFo337e3afN+jaPjWlu4rlSTEwjvUkZAD89Fo3s1x3rvo kWZw== X-Gm-Message-State: AD7BkJLFzZ8TUrWfp7BWRrfp2wj9MdaTQ+RTckmrt0SBIROEw5G4krdx5gdJQG94wS7i8Uh5jUAlPPbRfRDFvA== X-Received: by 10.112.17.5 with SMTP id k5mr11041720lbd.46.1456958659376; Wed, 02 Mar 2016 14:44:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.2.104 with HTTP; Wed, 2 Mar 2016 14:43:59 -0800 (PST) In-Reply-To: <20160302222216.GA12028@LK-Perkele-V2.elisa-laajakaista.fi> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <20160302222216.GA12028@LK-Perkele-V2.elisa-laajakaista.fi> From: Joseph Salowey Date: Wed, 2 Mar 2016 14:43:59 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11c3dc2e585229052d189f54 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 22:44:22 -0000 --001a11c3dc2e585229052d189f54 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 2, 2016 at 2:22 PM, Ilari Liusvaara wrote: > On Wed, Mar 02, 2016 at 02:08:28PM -0800, Joseph Salowey wrote: > > Reserving large portions of other protocols number spaces is not a good > way > > to do things. This will quickly become unworkable if other protocols > > decide to do the same thing. This type of behavior needs to be > > discouraged. There is no guarantee that the multiplexing scheme > prompting > > this registration request will work with TLS 1.3 or any future version of > > TLS. > > Well, outside of some very exotic extensions (none are defined to date, > and I'm having problems even imagining what such things would actually > do), it would work in TLS 1.3 Editor's Draft (since it only ever uses > 21, 22 and 23[1]). > > Future versions of TLS are another matter... > > And even if there was some extension to omit the version from record > header, it would still work (the demuxer would however need to be > aware of that extension). > > > [1] For comparision, TLS 1.2 uses 21-23 and also 20 and in presence of > certain (infamous) extension, 24. > > > [Joe] Yes you are correct that the current draft includes a dummy header, however the working group has discussed not using the dummy header which I believe would cause problems for the multiplexing scheme because the location where the contentType was would no longer contain the contentType. It seems unlikely that we would make this change at this point, however there are some folks who would like to get rid of the dummy header. > -Ilari > --001a11c3dc2e585229052d189f54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 2, 2016 at 2:22 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On We= d, Mar 02, 2016 at 02:08:28PM -0800, Joseph Salowey wrote:
> Reserving large portions of other protocols number spaces is not a goo= d way
> to do things.=C2=A0 =C2=A0This will quickly become unworkable if other= protocols
> decide to do the same thing.=C2=A0 This type of behavior needs to be > discouraged.=C2=A0 There is no guarantee that the multiplexing scheme = prompting
> this registration request will work with TLS 1.3 or any future version= of
> TLS.

Well, outside of some very exotic extensions (none are defined to da= te,
and I'm having problems even imagining what such things would actually<= br> do), it would work in TLS 1.3 Editor's Draft (since it only ever uses 21, 22 and 23[1]).

Future versions of TLS are another matter...

And even if there was some extension to omit the version from record
header, it would still work (the demuxer would however need to be
aware of that extension).


[1] For comparision, TLS 1.2 uses 21-23 and also 20 and in presence of
certain (infamous) extension, 24.



[Joe] Yes you are correc= t that the current draft includes a dummy header, =C2=A0however the working= group has discussed not using the dummy header which I believe would cause= problems for the multiplexing scheme because the location where the conten= tType was would no longer contain the contentType. =C2=A0 =C2=A0It seems un= likely that we would make this change at this point, however there are some= folks who would like to get rid of the dummy header. =C2=A0

=
=C2=A0
-Ilari

--001a11c3dc2e585229052d189f54-- From nobody Wed Mar 2 14:48:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B7A1B336E; Wed, 2 Mar 2016 14:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3no1RZ-Iuin; Wed, 2 Mar 2016 14:48:01 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 370601B3369; Wed, 2 Mar 2016 14:48:01 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id g203so8477172iof.2; Wed, 02 Mar 2016 14:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gZMxkvR2TVwTrOIhQXo5QEKP9b1QiqvELT9Yv1+Tf70=; b=OAZAJ3uZ7/AA/jYsy1BWpJlxnxfIKcIg0018iY5/DHb6pHUHdACSkxRL/qVGNiciid jVn/GjZrHlTgk8VfdrQv9bMA+p48n5selCfg1MYP6e0mAX+xY/pxajfdBU6W7LtuHsSN 1zCXg+jlzRB+9UeXxFP3RuP7fi3auzchajtoEhWeDTRAnx6OL1WNmtXL24nPvgcy5Ysn E3ezZ7Hh4En75trvdm5sO9/YVAhRua/jFXJ3x7lPKARm2aFHDF+XiMba4RHa9VGXH2T9 4uXxCYJJuugJs40dK4RVazMd8niIHkcos06BtauJJPO5snZdGiEE5JbQcZGdZ+QnbPAl JvEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gZMxkvR2TVwTrOIhQXo5QEKP9b1QiqvELT9Yv1+Tf70=; b=lypUIQZadMF03YOkHRbbfyfF6S5DP8VqQBJnwweqD51cpfxT+A0cMBrWIf3WTA8Xvs 2VgONZTQ1uceExyPLwIKoE7NjdqFRwFqSwAYgZmuiPyz8w8yqrdkiguUnveLiKdzoRf2 BcmF4h0pDUuolbOTWknoSFay5vuDh47yR3lLWbfb4CB1pHzb+wbzMZ4nUdGyeByCzSp9 WvL8sQZVYkfWk54CD52rMPWrW6KCej4E1rvHB5ROm8TIBCY3/C7ut6smIlW8AWMNkwwH 3B2FD+mNAOIOMmZdQDTTymb9AlYEPTS/RMCFJ9W+jpDm7kmNiXsh7PIOB9BqzDBor0K+ r0uA== X-Gm-Message-State: AG10YOS58JkMlonbtvAoEX7jcsP3tPnBIDwB4NABO1ZFPjBOrwJqqdpOpQJ8FqGIAsLthnWCJqJjLhYb4wl0tg== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr34452201iod.190.1456958880661; Wed, 02 Mar 2016 14:48:00 -0800 (PST) Received: by 10.36.43.5 with HTTP; Wed, 2 Mar 2016 14:48:00 -0800 (PST) In-Reply-To: <56D76716.1090506@acm.org> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <56D76716.1090506@acm.org> Date: Thu, 3 Mar 2016 09:48:00 +1100 Message-ID: From: Martin Thomson To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" , "avt@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 22:48:02 -0000 On 3 March 2016 at 09:20, Marc Petit-Huguenin wrote: > draft-ietf-avtcore-rfc5764-mux-fixes does not reserve large portions of the ContentType codepoints, RFC 5764 did. The damage is already done as RFC 5764 is deployed as a component of RTCWeb. I think that we can resolve this by saying this instead: RFC 5764 describes a narrow use of DTLS that works as long as the specific DTLS version used abides by the restrictions on the first byte (the ones that mux-fixes wants to put in the TLS registry). Any extension or revision to DTLS that no causes DTLS to no longer meet these constraints prevents that extension or version from being used in the fashion RFC 5764 describes. That means that DTLS 1.2 is safe. Thus far. DTLS 1.3 is also safe so far, though we're a lot further from done there[3]. I'm sorry that I didn't see this option before; I figured that with content type encryption in TLS 1.3, we wouldn't need those code points. However, Joe is right to protest the incursion onto sovereign territory. [3] I actually hope that we can change DTLS 1.3 so that it won't mux properly. That will have a size benefit that should outweigh the cost of having to rev 5764 for 1.3. From nobody Thu Mar 3 05:35:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB271A1A2E for ; Thu, 3 Mar 2016 05:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8c5WWm4Y29W for ; Thu, 3 Mar 2016 05:35:50 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0129.outbound.protection.outlook.com [23.103.200.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDD651A0545 for ; Thu, 3 Mar 2016 05:35:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BliSQH8zgBMSWBZWBYmYm1BErHMMc3IEBHwDI+/BT1w=; b=QlAUgR6uurq+HSjfZerhNPis0OO33ucIJEpDv6QV/aQRS5Q9WPqtwVdcMN71VcGCsOBNSJMeW1A7n7yahzh/7NLuqCyrt74Q4LebdWWFnc4Sz4sC4wl3rBrpOc0IOR0yd3JP1p/B9C2u7SVQFzlQRQAMMqsXAmWxMWhHZTULSx8= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB122.namprd09.prod.outlook.com (10.255.200.156) with Microsoft SMTP Server (TLS) id 15.1.415.20; Thu, 3 Mar 2016 13:35:46 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0415.024; Thu, 3 Mar 2016 13:35:46 +0000 From: "Dang, Quynh (Fed)" To: "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AQHRcxcw0LczJ8DOZUibIUJHHuPVmp9De2eAgAAhn4CAAGkGgIAAcKsAgABx/YCAAA/+gIAAX6qAgABdhQCAAAWZAIAA79mAgAEPhOA= Date: Thu, 3 Mar 2016 13:35:46 +0000 Message-ID: References: <20160302065747.GC10917@mournblade.imrryr.org>, <201603021616.15731.davemgarrett@gmail.com> In-Reply-To: <201603021616.15731.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; BN1PR09MB122; 5:gMa/eGP54ixVePOJkopYd8e78qoe25dVUOyU2/obAn1nvB7WMkpww4Uny0hM9zDJPqBjOtK4stJTHnXXySrnDsWXNjg80BnMDg9eRKcasEquEbpWflJMfLR7TquU0vDv+KVvRlahtz4ekVLT+QOPJg==; 24:9oHgIcAreoKqTHMscmNNQklCwxOLBPW9Q64hk2rD3wLQ6WiC3wWqiGVqWAwNhpqbccGrJoTTEKRuLJx3ujemw7cLZFJ2LUHGTlnMITjUcag= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB122; x-ms-office365-filtering-correlation-id: 4dfdaac7-b503-4a83-0655-08d34368ba3d x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB122; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB122; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(53754006)(377454003)(2351001)(5004730100002)(76176999)(586003)(86362001)(54356999)(450100001)(107886002)(50986999)(15975445007)(110136002)(93886004)(189998001)(87936001)(11100500001)(19580405001)(74316001)(2501003)(19580395003)(5008740100001)(1220700001)(99286002)(106116001)(1096002)(77096005)(33656002)(102836003)(6116002)(92566002)(3846002)(66066001)(5003600100002)(122556002)(1730700002)(5002640100001)(2950100001)(10400500002)(2900100001)(2906002)(3900700001)(5001960100004)(40100003)(3660700001)(3280700002)(76576001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB122; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 13:35:46.4437 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB122 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 13:35:53 -0000 Hi all, Why don't we use an even more elegant RSA signature called " full-domain ha= sh RSA signature" ? As you know, a SHAKE (as a variable output-length hash function) naturally = produces a hash value which fits any given modulus size. Therefore, no padd= ings are needed which avoids any potential issues with the paddings and the= signature algorithm would be very simple.=20 Regards, Quynh.=20 ________________________________________ From: TLS on behalf of Dave Garrett Sent: Wednesday, March 2, 2016 4:16 PM To: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 On Wednesday, March 02, 2016 01:57:48 am Viktor Dukhovni wrote: > adaptive attacks are I think a greater potential > threat against interactive TLS than against a bunch of CA-authored > bits at rest. +1 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls= From nobody Thu Mar 3 05:49:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646271ACDCB for ; Thu, 3 Mar 2016 05:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 gig8x5pot1cv for ; Thu, 3 Mar 2016 05:49:48 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8579C1ACDC4 for ; Thu, 3 Mar 2016 05:49:48 -0800 (PST) Received: from pc1 (0x3ec7b91c.inet.dsl.telianet.dk [::ffff:62.199.185.28]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 03 Mar 2016 14:49:45 +0100 id 000000000000002B.0000000056D840F9.00005A65 Date: Thu, 3 Mar 2016 14:49:47 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160303144947.0402bad9@pc1> In-Reply-To: References: <20160302065747.GC10917@mournblade.imrryr.org> <201603021616.15731.davemgarrett@gmail.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-23141-1457012985-0001-2" Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 13:49:50 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-23141-1457012985-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 3 Mar 2016 13:35:46 +0000 "Dang, Quynh (Fed)" wrote: > Why don't we use an even more elegant RSA signature called " > full-domain hash RSA signature" ? Full Domain Hashing was originally developed by Rogaway and Bellare and then later dismissed because they found that they could do better. Then they developed PSS. See http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf So in essence FDH is a predecessor of PSS and the authors of both schemes came to the conclusion that PSS is the superior scheme. > As you know, a SHAKE (as a variable output-length hash function) > naturally produces a hash value which fits any given modulus size. > Therefore, no paddings are needed which avoids any potential issues > with the paddings and the signature algorithm would be very simple.=20 You could also use SHAKE in PSS to replace MGF1. This is probably desirable if you intent to use PSS with SHA-3. PSS doesn't really have any padding in the traditional sense. That is, all the padding is somehow either hashed or xored with a hashed value. I don't think any of the padding-related issues apply in any way to PSS, if you disagree please explain. (shameless plug: I wrote my thesis about PSS, in case anyone wants to read it: https://rsapss.hboeck.de/ - it's been a while, don't be too hard on me if I made mistakes) --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-23141-1457012985-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW2ED7AAoJEKWIAHK7tR5CMx0P/RrbYDLdQv9XcTGp/EZxrl1g D2vQL5BJv/uUZwwfFFMFO/9/bzTmVajIwp7JljqhXWcCSB8arsjEHH0d5KJWGQyK K25S+kmphDAACRvI2Tj2xvPC1nFglO+HMiScmMktZVIYLeXee+rkUW7whwnzfsmb cK0dW9NbQEl+WylJMAVTNV/OqujpjpA/RnAYJZXAHKWVGKuk0FacCisvoZE/vZRb aEfQVIzg2a2Y+8L78SIoCYHVJPUGV+p5rkQQNUJ7lG+sPNa+LrXnkbIDhetGZQiX bFAfx9mSZYprtonDLdc7yUaW3mSTxbY9ydaXy4WmuCiTMTMX97LsuCSxmreKGJeb rvjCojATRBjnQeHAJmYCIXJeodd0oRv3ZZTrQJPpDig9/UtUFonoBrAVGjNXpMey IM66Qr9HeJOrFLodUwzGTYm4/eQTqJfwQuF1w5iny5ieRnb3l0VVQ8jWmBimlxW1 Dlel+uGEzRJRCuB/4lO4USFYgk/yobLgzSfQxX6ZXQtqXUBdv0vk1TEDnCRYdE3z yGSv62JtO0jS7C+ycSTy82+F1I9+Q0mslDO9nFykCo6TrUKcjgRfWeYK2/PftawT aPLrZC8yIFaxRdL7m+RIeIdtnRu/sCYkKlfAdPnynlzDifkbgvlvY50dQwAPWPL4 3vd5H6Q3YUxMsRe35h5m =6P+D -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-23141-1457012985-0001-2-- From nobody Thu Mar 3 06:21:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C65B1ACE8B for ; Thu, 3 Mar 2016 06:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Vc9xHhYWH5NX for ; Thu, 3 Mar 2016 06:21:03 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0104.outbound.protection.outlook.com [23.103.201.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C401ACE88 for ; Thu, 3 Mar 2016 06:21:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nbHSS51bIx2kl/ekVOwPwGx0GqI95xLBwy4n++PEuEs=; b=NksYsHq3idFYAd8uOiDCcd2r5FyGdRDWN+NXRGzSBcUJi3YcbJ+Gk9S6/2moSRJDeuVB3lLv1mLZhmy0tO5LJ/bLUXFdWG0mVuRAIBFH2jp4BefgoPH5U42b8uQ0q8iqaz2OEsHwzBsNlBejTb2wuzCmY9YpLA23U2ZTtZzSCU4= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB123.namprd09.prod.outlook.com (10.255.200.25) with Microsoft SMTP Server (TLS) id 15.1.415.20; Thu, 3 Mar 2016 14:21:01 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0415.024; Thu, 3 Mar 2016 14:21:01 +0000 From: "Dang, Quynh (Fed)" To: =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AQHRcxcw0LczJ8DOZUibIUJHHuPVmp9De2eAgAAhn4CAAGkGgIAAcKsAgABx/YCAAA/+gIAAX6qAgABdhQCAAAWZAIAA79mAgAEPhOCAAAYTgIAABjju Date: Thu, 3 Mar 2016 14:21:01 +0000 Message-ID: References: <20160302065747.GC10917@mournblade.imrryr.org> <201603021616.15731.davemgarrett@gmail.com> , <20160303144947.0402bad9@pc1> In-Reply-To: <20160303144947.0402bad9@pc1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hboeck.de; dkim=none (message not signed) header.d=none;hboeck.de; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; BN1PR09MB123; 5:e/EzFOIePuio3vIb4Q4e5yUVwBxq40ibI7oo4MhPrTRefDfDqyAz6wiC25NSCVHl96sVOKFlLjHZLE9pZ4kGZkuYvePWRhfR5uZr/Row+kMmnyNR0+d3kFdK9Wdp4iUfbFDj/O/XJdAVOWkIb7Ip5Q==; 24:PyT8BnjXx4Ao8kJ4TrdKsaDZY+I95APurYNSOuGCdiL1D5fJXiQ8U4nhMUl66RZXvYn9QH0dd347KqKy/vndjlHpr6JFNYFJYq57fNZ76tY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB123; x-ms-office365-filtering-correlation-id: e1085a87-2d6f-45c5-5663-08d3436f0c60 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(66011452539121); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB123; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB123; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(243025005)(377454003)(24454002)(86362001)(97736004)(107886002)(19580395003)(5001770100001)(19580405001)(189998001)(122556002)(40100003)(10400500002)(76176999)(2501003)(54356999)(50986999)(74316001)(102836003)(5004730100002)(5003600100002)(3900700001)(11100500001)(5002640100001)(93886004)(1220700001)(1096002)(2950100001)(5008740100001)(3280700002)(2900100001)(2906002)(33656002)(15975445007)(99286002)(66066001)(77096005)(3846002)(6116002)(5001960100004)(586003)(92566002)(87936001)(106116001)(76576001)(3660700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB123; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 14:21:01.4317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB123 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 14:21:07 -0000 Hi Hanno, I think the PSS uses a random salt to get the hashing probabilistic. A customized version of a SHAKE can/may take a domain-separation string or/= and a random salt. Quynh.=20 ________________________________________ From: TLS on behalf of Hanno B=F6ck Sent: Thursday, March 3, 2016 8:49 AM To: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 On Thu, 3 Mar 2016 13:35:46 +0000 "Dang, Quynh (Fed)" wrote: > Why don't we use an even more elegant RSA signature called " > full-domain hash RSA signature" ? Full Domain Hashing was originally developed by Rogaway and Bellare and then later dismissed because they found that they could do better. Then they developed PSS. See http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf So in essence FDH is a predecessor of PSS and the authors of both schemes came to the conclusion that PSS is the superior scheme. > As you know, a SHAKE (as a variable output-length hash function) > naturally produces a hash value which fits any given modulus size. > Therefore, no paddings are needed which avoids any potential issues > with the paddings and the signature algorithm would be very simple. You could also use SHAKE in PSS to replace MGF1. This is probably desirable if you intent to use PSS with SHA-3. PSS doesn't really have any padding in the traditional sense. That is, all the padding is somehow either hashed or xored with a hashed value. I don't think any of the padding-related issues apply in any way to PSS, if you disagree please explain. (shameless plug: I wrote my thesis about PSS, in case anyone wants to read it: https://rsapss.hboeck.de/ - it's been a while, don't be too hard on me if I made mistakes) -- Hanno B=F6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 From nobody Thu Mar 3 07:25:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C241A004A; Thu, 3 Mar 2016 07:25:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HuA49oW4_rnq; Thu, 3 Mar 2016 07:25:26 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E4C71A0060; Thu, 3 Mar 2016 07:25:25 -0800 (PST) X-AuditID: c1b4fb30-f79d26d000006389-67-56d857640915 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 06.B9.25481.46758D65; Thu, 3 Mar 2016 16:25:24 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Thu, 3 Mar 2016 16:25:23 +0100 To: Martin Thomson , Marc Petit-Huguenin References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <56D76716.1090506@acm.org> From: Magnus Westerlund Message-ID: <56D85763.7070000@ericsson.com> Date: Thu, 3 Mar 2016 16:25:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM2K7hG5K+I0wgy0r+C1e9qxkt1j+p4vR Ytum/ewW1878Y7S4sOYuk8Wn812MDmwel694e+ycdZfdY8mSn0wex3dtYA9gieKySUnNySxL LdK3S+DK+L2epWCaRMXtedeZGxinCHcxcnJICJhIzP10kQXCFpO4cG89WxcjF4eQwGFGiUsP t0M5yxglHn3+yw5SJSwQJtH/7iQjiC0iEC5xdfoNRoiiNmaJpVO3gHUwC3QzSqw4u5cVpIpN wELi5o9GNhCbV0BbouP4f7B9LAIqEruuN4PViArESBx/d44RokZQ4uTMJ2A1nAKBEgf3X2cG sZmB5sycf54RwpaXaN46GywuBDSzoamDdQKj4Cwk7bOQtMxC0rKAkXkVo2hxanFSbrqRkV5q UWZycXF+nl5easkmRmCwH9zy22AH48vnjocYBTgYlXh4N6y4HibEmlhWXJl7iFGCg1lJhDck 4EaYEG9KYmVValF+fFFpTmrxIUZpDhYlcV7WT5fDhATSE0tSs1NTC1KLYLJMHJxSDYyTq01V +aoaIjtO8cSdDo4X/p5onmMXeLy4YUcc/66vQTINCyJmWMV2bE3L2v6R24F/hnnDuvLJptMd VUym/7w3IzkiK7B10zver482WDq+a/O8/u13Vi1b5bmca21z17H9OZjXWHqKYVf2xqfbb2/T aq+qfK7q2q34WfNwi8i5qedkQywC5ZVYijMSDbWYi4oTATFNA+NyAgAA Archived-At: Cc: "tls@ietf.org" , "avt@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 15:25:30 -0000 Hi, To be clear I will not continue with a publication request while we are having a discussion. I hope we can resolve this with an agreement on how to proceed. Den 2016-03-02 kl. 23:48, skrev Martin Thomson: > On 3 March 2016 at 09:20, Marc Petit-Huguenin > wrote: >> draft-ietf-avtcore-rfc5764-mux-fixes does not reserve large >> portions of the ContentType codepoints, RFC 5764 did. The damage is already done as RFC 5764 is deployed as a component of RTCWeb. > > I think that we can resolve this by saying this instead: > > RFC 5764 describes a narrow use of DTLS that works as long as the > specific DTLS version used abides by the restrictions on the first > byte (the ones that mux-fixes wants to put in the TLS registry). Any > extension or revision to DTLS that no causes DTLS to no longer meet > these constraints prevents that extension or version from being used > in the fashion RFC 5764 describes. > Sorry, I am not certain I understand what you suggest. Do you want the above text in RFC 5764, or as a comment in the TLS content type registry, or what? > That means that DTLS 1.2 is safe. Thus far. DTLS 1.3 is also safe so > far, though we're a lot further from done there[3]. It is "Thus far" comment for DTLS 1.2 that is one reason that we want to put in sufficient warnings into the TLS content type registry. And clearly DTLS 1.3 will also have to take into account this. It is one out of many usages of DTLS, but it is not insignificant amount of usage that relies on the possibility to separate the protocols on first byte. > > I'm sorry that I didn't see this option before; I figured that with > content type encryption in TLS 1.3, we wouldn't need those code > points. However, Joe is right to protest the incursion onto sovereign > territory. > I want to make it clear that the goal is to have something that is mutually agreeable here. The situation with the multiplexing is already existing and widely deployed, whatever one thinks of it. The goal with the update is to clarify the situation, resolve uncertainties and points of confusion, as well as reducing the risk for future issues due to ignorance. > [3] I actually hope that we can change DTLS 1.3 so that it won't mux > properly. That will have a size benefit that should outweigh the cost > of having to rev 5764 for 1.3. > I really hope before that decision is taken that one analyse and propose a solution for how to handle the need for multiplexing so that discussion has happened. Cheers Magnus Westerlund AVTCORE WG chair ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Thu Mar 3 07:29:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 756861A00F6 for ; Thu, 3 Mar 2016 07:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.695 X-Spam-Level: X-Spam-Status: No, score=0.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.006, UNPARSEABLE_RELAY=0.001] autolearn=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 K5ox40OaJcXx for ; Thu, 3 Mar 2016 07:29:45 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id BF3B51A00E7 for ; Thu, 3 Mar 2016 07:29:44 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u23FSuA0015201; Thu, 3 Mar 2016 10:28:56 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "Dang, Quynh (Fed)" , =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6h3O7iji/YNEOG5tIXPX7flQ== Date: Thu, 3 Mar 2016 15:29:37 +0000 Message-ID: <20160303152945.18296912.40009.55386@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="===============1102755948==" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-03_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1601100000 definitions=main-1603030282 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 15:29:46 -0000 --===============1102755948== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Also, wasn't PSS =E2=80=8Edeveloped before SHA3 and SHAKE were known, let a= lone available?=C2=A0 It may be worth asking the authors what's their opinion of FDH vs PSS in vi= ew of the state of the art *today*. Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the Verizon=C2=A0Wireless=C2=A04G=C2=A0LTE=C2=A0network. =C2=A0 Original Message =C2=A0 From: Dang, Quynh (Fed) Sent: Thursday, March 3, 2016 09:21 To: Hanno B=C3=B6ck; tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 Hi Hanno, I think the PSS uses a random salt to get the hashing probabilistic. A customized version of a SHAKE can/may take a domain-separation string or/= and a random salt. Quynh.=20 ________________________________________ From: TLS on behalf of Hanno B=C3=B6ck Sent: Thursday, March 3, 2016 8:49 AM To: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 On Thu, 3 Mar 2016 13:35:46 +0000 "Dang, Quynh (Fed)" wrote: > Why don't we use an even more elegant RSA signature called " > full-domain hash RSA signature" ? Full Domain Hashing was originally developed by Rogaway and Bellare and then later dismissed because they found that they could do better. Then they developed PSS. See http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf So in essence FDH is a predecessor of PSS and the authors of both schemes came to the conclusion that PSS is the superior scheme. > As you know, a SHAKE (as a variable output-length hash function) > naturally produces a hash value which fits any given modulus size. > Therefore, no paddings are needed which avoids any potential issues > with the paddings and the signature algorithm would be very simple. You could also use SHAKE in PSS to replace MGF1. This is probably desirable if you intent to use PSS with SHA-3. PSS doesn't really have any padding in the traditional sense. That is, all the padding is somehow either hashed or xored with a hashed value. I don't think any of the padding-related issues apply in any way to PSS, if you disagree please explain. (shameless plug: I wrote my thesis about PSS, in case anyone wants to read it: https://rsapss.hboeck.de/ - it's been a while, don't be too hard on me if I made mistakes) -- Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --===============1102755948== Content-Type: application/x-pkcs7-signature; name="smime.p7s" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDTALBglghkgBZQMEAgEwgAYJKoZIhvcNAQcBAACggg7NMIIE 6jCCA9KgAwIBAgIKMz1Y1wAAAABunjANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zMB4XDTE2MDExNDE3MzU1MloXDTE5MDExMzE3MzU1MlowYTELMAkGA1UEBhMCVVMxHzAd BgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCz HVEw2ojNZjWEnTASyJaQIvzziBmrH07FzMEY2xFGNDJpss38CcFRjfRx1EyEp7BrFdAXC2pHjFwa gFr+McYdXZiKEci0Mzna2uibsMDVbhlT6TwtmAL6QzdtjN28dn+7vQUkRUWUm9VVaBVVxUgX3f2l oEZsJNvWb7C8vj2DZF/uEt/EU/9KcUuodMgCR4zYLFVpNh1U6tCYACNDNtj/nmNjubtez1Y56zjZ AVOXZWsjNCPrC2jVwDdg1AIcs5ayDMOC2p1F95kSxWsJwinKfSe8p2/YR/cwUo8ljFoBPj60AGW3 WjaJyKXK+ZgJwjwl9gG/pg2T4mQhIAIZWZQ9AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUtKJz3aEd G/MvxjE38EW6PHdcUDQwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0be yMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExD QTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBl AHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAJTu0/WcX0ebe9UfUMslvy9fC2aCQong cVcEKlEjU8IvCKa6YpZHQKTVXQ3e4KKvw1DgzFvq8/rOv87Woj45q8smgNyivgAMCnrT7a6B/9Kn 85l9BjeoLMPLypvsmz1l7oX45NPr3LF4VEMzxqczdovS14woPKdegEKQYyPSZGhKTCCe/9FhtgEc 3gfVyE1mH6ZNeDEalr7nx7F0qemhh3QN6i6XPrudzv9el5JeovPedZ0JqDT0ctXj6ECYOiEyEfJm 85C5QGmpjLmCM99gAmgpP5Tx6APB/tvcUw/mgt4HOvqavGkvUkoJ8XEEwt9AgXaznS626Kb8RpAh w2zN2yMwggTqMIID0qADAgECAgozPVjXAAAAAG6eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTMwHhcNMTYwMTE0MTczNTUyWhcNMTkwMTEzMTczNTUyWjBhMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSAw HgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALMdUTDaiM1mNYSdMBLIlpAi/POIGasfTsXMwRjbEUY0MmmyzfwJwVGN9HHUTISnsGsV 0BcLakeMXBqAWv4xxh1dmIoRyLQzOdra6JuwwNVuGVPpPC2YAvpDN22M3bx2f7u9BSRFRZSb1VVo FVXFSBfd/aWgRmwk29ZvsLy+PYNkX+4S38RT/0pxS6h0yAJHjNgsVWk2HVTq0JgAI0M22P+eY2O5 u17PVjnrONkBU5dlayM0I+sLaNXAN2DUAhyzlrIMw4LanUX3mRLFawnCKcp9J7ynb9hH9zBSjyWM WgE+PrQAZbdaNonIpcr5mAnCPCX2Ab+mDZPiZCEgAhlZlD0CAwEAAaOCAbIwggGuMB0GA1UdDgQW BBS0onPdoR0b8y/GMTfwRbo8d1xQNDAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJ jXVMDf3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dGNybC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0 LmVkdS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3Nw MD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXL3jKH/4pz AgFkAgEGMCIGA1UdJQEB/wQYMBYGCCsGAQUFBwMEBgorBgEEAYI3CgMMMBgGA1UdIAQRMA8wDQYL KoZIhvcSAgEDAQgwGQYDVR0RBBIwEIEOdXJpQGxsLm1pdC5lZHUwJwYJKwYBBAGCNxQCBBoeGABM AEwAVQBzAGUAcgBTAGkAZwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAlO7T9ZxfR5t71R9QyyW/ L18LZoJCieBxVwQqUSNTwi8IprpilkdApNVdDd7goq/DUODMW+rz+s6/ztaiPjmryyaA3KK+AAwK etPtroH/0qfzmX0GN6gsw8vKm+ybPWXuhfjk0+vcsXhUQzPGpzN2i9LXjCg8p16AQpBjI9JkaEpM IJ7/0WG2ARzeB9XITWYfpk14MRqWvufHsXSp6aGHdA3qLpc+u53O/16Xkl6i8951nQmoNPRy1ePo QJg6ITIR8mbzkLlAaamMuYIz32ACaCk/lPHoA8H+29xTD+aC3gc6+pq8aS9SSgnxcQTC30CBdrOd LrbopvxGkCHDbM3bIzCCBO0wggPVoAMCAQICCjM4lI8AAAAAbpYwDQYJKoZIhvcNAQELBQAwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQxNzMwMzlaFw0xOTAxMTMxNzMwMzlaMGEx CzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQ ZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUwMDEwNTg0MIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuIiWvivQHEzd8volNcoLbxxuHKLXgwX++2 TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwLwFCMLJeQI853KST/u/FIuLt+GjDbHXT/ kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CCLXWYStQ1maiEdGre59mIwkkLGTV9JSeC cK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGLh8GKSkhavNEhIenDAy3U3tWQI1sbJ28i guuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3ArsA8BnpKUFbmyvQIDAQABo4IBtTCCAbEw HQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAW gBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1p dC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8d hevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYD VR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTAnBgkrBgEE AYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBXMA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7P ZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3tkjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X 3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1mPOC3KLH6MNDKKZV7PJrzu056M8DPj7R mbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFXtWjeIryJFPLL5CjIIL+WWjrKJ2lvCUun VGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U44fUP6RypuwERYRa90ACeqHAo8syxeYrL GtVbIcexJQSJNHF4XqepizC6hjV92swJMYIB8TCCAe0CAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0G A1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRM TCBDQS0zAgozPVjXAAAAAG6eMAsGCWCGSAFlAwQCAaBpMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDMwMzE1Mjk0M1owLwYJKoZIhvcNAQkEMSIEII5pWEy3v+Hx zsE9X2fmW64Bh1xnLGi6Asv0sqxU9fu2MAsGCSqGSIb3DQEBCwSCAQBGLv2hpMWY8M2OJKww5/T7 51FMfnIxTUBqdjcs9VgIuAhLdO0TVQ4Qk/uQGaDN3IdhoaGo3v/K95dveJdBbtoAgP5+nF2BBx8h Ivb8vj4d1oblKlqzDqSD6ETMT0nsJ/MCfKMUsyqHo20hohOOad94KzV3202a9ds+8Mtgp2eGADwf 5wOsd1zj5hvQTP3zZyyWaW+MZBigS+wwtoXqiyn8GGkrPVWHeqvJohUYz+X/LwGbiuRfN5pK23Kv t+wlcmt3YQwDVsi1puDPBu3aSzqyuKhUWO7XXLjTuHX6tAFPPna3/Ov8EzmVBbAKYaFKGrSM8M0T 3nWVmZS9+Km6FesCAAAAAAAA --===============1102755948==-- From nobody Thu Mar 3 08:11:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 981161A1B60 for ; Thu, 3 Mar 2016 08:11:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 WeVVsSynNUGi for ; Thu, 3 Mar 2016 08:11:19 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0A51A1EF1 for ; Thu, 3 Mar 2016 08:11:19 -0800 (PST) Received: from pc1 (0x3ec7b91c.inet.dsl.telianet.dk [::ffff:62.199.185.28]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 03 Mar 2016 17:11:15 +0100 id 000000000000003A.0000000056D86223.000036FB Date: Thu, 3 Mar 2016 17:11:17 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Message-ID: <20160303171117.12e627b3@pc1> In-Reply-To: <20160303152945.18296912.40009.55386@ll.mit.edu> References: <20160303152945.18296912.40009.55386@ll.mit.edu> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-14075-1457021476-0001-2" Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 16:11:21 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-14075-1457021476-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, 3 Mar 2016 15:29:37 +0000 "Blumenthal, Uri - 0553 - MITLL" wrote: > Also, wasn't PSS =E2=80=8Edeveloped before SHA3 and SHAKE were known, let > alone available?=C2=A0 Yeah, more than 10 years before. It's more the other way found: PSS and other constructions showed the need for hash functions with a defined output length. SHAKE is such a function. PSS uses a construction called MGF1, which essentially takes an existing fixed-output-length hash, combines that with a counter and produces some construction. SHAKE deprecates the need for such a workaround. So instead of using PSS+SHA256+MGF1-with-SHA256 you could say you use PSS+SHA-3-256+SHAKE256. I don't think this changes a whole lot in regards to security (as long as we assume both sha256 and sha-3-256 are very secure algorithms). > It may be worth asking the authors what's their opinion of FDH vs PSS > in view of the state of the art *today*. You may do that, but I doubt that changes much. I think FDH really is not an option at all here. It may very well be that there are better ways to do RSA-padding, but I don't think that this is viable for TLS 1.3 (and I don't think FDH is better). PSS has an RFC (3447) and has been thoroughly analyzed by research. I think there has been far less analyzing effort towards FDH (or any other construction) and it is not in any way specified in a standards document. If one would want to use FDH or anything else one would imho first have to go through some standardization process (which could be CFRG or NIST or someone else) and call for a thorough analysis of it by the cryptographic community. Which would take at least a couple of years. Given that there probably is no long term future for RSA anyway (people want ECC and postquantum is ahead) I doubt anything else than the primitives we already have in standards will ever be viable. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-14075-1457021476-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW2GIlAAoJEKWIAHK7tR5ColwP+gKq5J3SGs3UaUVqBM/V2nmI d6EzZcFZfv/C1NCib8E+u2z7J4TdtfazXwIHRQj0rc8HyIH7cHKJ9ZbY4jgq87cg Hrbmum77rfaZf1kZriyReMZ4l8FL0vzKCpS1KUrOJtdMBSnTSiRCoTe+b6+/0g62 mwqAwJ3XprIWPmi09rNSffD4Idc8IGfmDXKj2LTnN/URkVVCT0+ViUQUXsH0JpML tYUJ4pIwr5ptmB6Ldf8a1lLY7TBmwXdTU+2BVbpt3u2+PJGPUbUFspFYwOHDKEK3 v3xwQd7SN4gvwi0Lo5T+pRhqXXxvX5qDI2UK1znRE98wPqEV2ZH6Dn/MxFb6SGYT 7uqp62p9vwfLO5/GzFmXaLayLoDCXEGS2+33XPt+Ti0n6dk880UZcfr7CgpIqs1k mRTlFOXxvjeO2JMncEbFElELZ3+5Ew+AnzZqOz+Oo2wd9JX8TGZJoQklVWaBn6j5 ApCAavNHAgkXI41sMAY+nonynl9PMZvAQSfRqZqZZBia+tBIk7by+tp9BqeVE5Fm zWfrJXEb5igUj5oaBLNLf+Q5dSD1GH2d6lMu3QuGQPwuFL01qvQ5RzJ5ovs/NF7Y 5fHeMYtR6g+RlZpVg6ZPiU19rJtqXBJGlpGZX34vWew66swB5i8i0cDtbaduiK+h 7nRbZ1iRYH9Hi4ivtriW =LLYZ -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-14075-1457021476-0001-2-- From nobody Thu Mar 3 08:43:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21E91A8763 for ; Thu, 3 Mar 2016 08:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o_MCmwru6Bji for ; Thu, 3 Mar 2016 08:43:17 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AC9291A8750 for ; Thu, 3 Mar 2016 08:43:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 800853268; Thu, 3 Mar 2016 18:43:15 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id y4OwfpkbiDkD; Thu, 3 Mar 2016 18:43:15 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 40D7F27B; Thu, 3 Mar 2016 18:43:15 +0200 (EET) Date: Thu, 3 Mar 2016 18:43:09 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160303164309.GA13882@LK-Perkele-V2.elisa-laajakaista.fi> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <56D76716.1090506@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 16:43:20 -0000 On Thu, Mar 03, 2016 at 09:48:00AM +1100, Martin Thomson wrote: > > [3] I actually hope that we can change DTLS 1.3 so that it won't mux > properly. That will have a size benefit that should outweigh the cost > of having to rev 5764 for 1.3. I thought about this a bit... It occurs to me that a way to compress most headers to 2 bytes (from present 5) is: Unencrypted: 16 03 01 xx xx or 15 03 01 xx xx Encrypted: 80|xx xx Where xx xx is the length bytes. The unencrypted headers need to be kept for backward compatiblity. The ranges don't overlap, since the first xx can be at most 0x41 (which occurs for maximum 16640 byte encrypted record payload), so the first byte would be 0x80-0xC1, which doesn't overlap with 0x15 and 0x16 (which are used for unencrypted packets). That would interfere with muxing however (requring at least changing how muxing is done, e.g. by inserting a marker byte for DTLS packets). -Ilari From nobody Thu Mar 3 08:44:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338311A8771 for ; Thu, 3 Mar 2016 08:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQpsqmu_u9KB for ; Thu, 3 Mar 2016 08:44:32 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1B31A8765 for ; Thu, 3 Mar 2016 08:44:32 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CAA4D43349B; Thu, 3 Mar 2016 16:44:31 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B209A433402; Thu, 3 Mar 2016 16:44:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457023471; bh=x0RC9xa+bSOZORnQsuwK4XMMf8odaG7fOh5Lb2jxygk=; l=109; h=From:To:CC:Date:References:In-Reply-To:From; b=D85wDnsGy7W29HcvAxOEXMVk2Ss48R7OtOXrwyIC7zl0XhB67m5WXm5cSN2tmQJws x1ZDH2EmuF9AYfg6yYzS2r2seS9oOEAcad/lOOft0hzrykWj8h37GLRIbMgMf14KKr d6MMsfyXYUSnwgKyNJcq+TFOC+vdyJ0YT/iWoW6M= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id ACD911FC95; Thu, 3 Mar 2016 16:44:31 +0000 (GMT) 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.1130.7; Thu, 3 Mar 2016 11:44:31 -0500 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.1130.005; Thu, 3 Mar 2016 11:44:31 -0500 From: "Salz, Rich" To: Ilari Liusvaara , Martin Thomson Thread-Topic: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 Thread-Index: AQHRdNG338gnVUACX0ORsVB/WtNjx59HFVIAgAEsZYD//6x/QA== Date: Thu, 3 Mar 2016 16:44:30 +0000 Message-ID: References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <56D76716.1090506@acm.org> <20160303164309.GA13882@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160303164309.GA13882@LK-Perkele-V2.elisa-laajakaista.fi> 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.115.160] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 16:44:34 -0000 > The unencrypted headers need to be kept for backward compatiblity. Even for a new protocol revision? From nobody Thu Mar 3 09:04:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1D1B3076 for ; Wed, 2 Mar 2016 12:59:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=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 z7FU3csMpuNV for ; Wed, 2 Mar 2016 12:59:08 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27DB71B3071 for ; Wed, 2 Mar 2016 12:59:07 -0800 (PST) Received: from mail-lb0-f173.google.com ([209.85.217.173]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0MNQhV-1aYjwp1h1t-006sam for ; Wed, 02 Mar 2016 21:59:06 +0100 Received: by mail-lb0-f173.google.com with SMTP id bc4so669201lbc.2 for ; Wed, 02 Mar 2016 12:59:05 -0800 (PST) X-Gm-Message-State: AD7BkJK6iPJdeXdFXipaa27kx4EQI/ZM9Y01V8HNlXM6QEAGbWssbHD9Xd+LGzYpAh3N9GRLDVsN3nBqIKXoVA== MIME-Version: 1.0 X-Received: by 10.112.13.33 with SMTP id e1mr8991843lbc.79.1456952345674; Wed, 02 Mar 2016 12:59:05 -0800 (PST) Received: by 10.112.22.67 with HTTP; Wed, 2 Mar 2016 12:59:05 -0800 (PST) In-Reply-To: <20160302143313.6E6C1180004@rfc-editor.org> References: <20160302143313.6E6C1180004@rfc-editor.org> Date: Wed, 2 Mar 2016 21:59:05 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: RFC Errata System Content-Type: multipart/alternative; boundary=001a11c39e2604d013052d1727a6 X-Provags-ID: V03:K0:FIIgv15pYxRYtx+sxA1cnvBYHC9Z+YiyEmn3lb4BffuKIyhwTH+ DcuhJU7ljRsjffQ+r0gvnxNP/ylEbDqQNWyWiYabM7XzsznkUiMwcZ7cGeE4EbmZZWRrdyo qYxrBaOqWvsW9VFqAeCfZcqZFzboN6D1qYzt2jFwx7JcEgz84jpgjjFNRm+nT2oaNUy9jiC N1KszCfo6hjvVMtUI9z0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:lMptfjS2/yA=:gxqRb0Ex2/6Y8fvELkZMXc 97no20Le7Pg3BW3ffRSNXyNhoMoyKYVxJPN//dGZXysL5ET+aY0fXlUwKr9efUltpftij0Npg M/cDk/uhL49WzYL5UR80edvB9JVBBOG8lQaer2ruHJl6yRffKTNDDUqrDslN6GAETfQD8EXgB xjmBkoloFFs2oRvZ3E3ElFrDj+d+J6GqmocrlGk00aIY3O9pnRZk44yhflrGQus/ZWdK8MlIV 1m0jfgLBSvajSNxKAvQLUQ2uceLsBDp2SD1OMl4yCrsuOm3dLdaXCRzK202INA7YVWtyg7c79 e1EFVRthe9M7dt5V0HBK/8wbS2yEOWlh8B8mqVv3MAQaFIIBavp844vdwkuvv1OGhyWHWIj1M Kg+cIpwvEiwHNJye2RakbZEGVXjR4UMyN0bv2/ory9vLm+dj/fR0gIgJWNyO/q/QkXBEWTx8g O0cyjRc74UW5jAUlk8Iu+fITTHZ5jO7P7/qOjlVtdO7GdX1Z56BepSpqYq3ugC3tBJGKELkZ1 ODLd2gF0yRK7Sj6D2o3zyDk9Ik4C/nP0nTqmxlumGsMHPhVab0BL8a8OMIrkck2FiY3PDOycm p6nYxxs1qgsE7VlEU16NbRqYy4PCH/lLhOr7+7rtKiTqPZvjwORwNSn6o88xP3b2TVAMkHfrN wzGO6VkVgsevqZRIRSWy9kchqYl0sNIqIgwTeVKQTCJE4lnhPQRtaxwGxZFMGrz7FAwQ4fm1H H2sxIjWB+4qpipJt Archived-At: X-Mailman-Approved-At: Thu, 03 Mar 2016 09:04:12 -0800 Cc: sean+ietf@sn3rd.com, Chris Hawk , Kathleen Moriarty , Nelson B Bolyard , "tls@ietf.org" , Vipul Gupta Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (4633) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 02 Mar 2016 20:59:10 -0000 --001a11c39e2604d013052d1727a6 Content-Type: text/plain; charset=UTF-8 RFC Errata System : > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer > Security (TLS)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=4633 > > -------------------------------------- > Type: Editorial > Reported by: Kurt Roeckx > > Section: 5.1.1 > > Original Text > ------------- > struct { > NamedCurve elliptic_curve_list<1..2^16-1> > } EllipticCurveList; > > Corrected Text > -------------- > struct { > NamedCurve elliptic_curve_list<2..2^16-1> > } EllipticCurveList; > > Notes > ----- > The count is in bytes, not items. > I agree with this finding. Each NamedCurve value takes exactly two bytes, so the floor should have been specified as 2, not 1. Bodo --001a11c39e2604d013052d1727a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RFC = Errata System <rfc-editor@rfc-editor.org>:
The following errata report has been submitted for= RFC4492,
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer S= ecurity (TLS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/err= ata_search.php?rfc=3D4492&eid=3D4633

--------------------------------------
Type: Editorial
Reported by: Kurt Roeckx <kurt@roeckx.= be>

Section: 5.1.1

Original Text
-------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NamedCurve elliptic_curve_list<= ;1..2^16-1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } EllipticCurveList;

Corrected Text
--------------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NamedCurve elliptic_curve_list<= ;2..2^16-1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } EllipticCurveList;

Notes
-----
The count is in bytes, not items.

I agr= ee with this finding.=C2=A0 Each NamedCurve value takes exactly two bytes, = so the floor should have been specified as 2, not 1.

Bodo

--001a11c39e2604d013052d1727a6-- From nobody Thu Mar 3 09:06:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7100A1B29C4 for ; Thu, 3 Mar 2016 09:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubZ91AXStrMp for ; Thu, 3 Mar 2016 09:06:41 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8251A88B8 for ; Thu, 3 Mar 2016 09:04:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 01FFA183D; Thu, 3 Mar 2016 19:04:48 +0200 (EET) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id zLBAg0ZjCW1m; Thu, 3 Mar 2016 19:04:47 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C6406C4; Thu, 3 Mar 2016 19:04:47 +0200 (EET) Date: Thu, 3 Mar 2016 19:04:42 +0200 From: Ilari Liusvaara To: "Salz, Rich" Message-ID: <20160303170442.GB13882@LK-Perkele-V2.elisa-laajakaista.fi> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <56D76716.1090506@acm.org> <20160303164309.GA13882@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 17:06:47 -0000 On Thu, Mar 03, 2016 at 04:44:30PM +0000, Salz, Rich wrote: > > > The unencrypted headers need to be kept for backward compatiblity. > > Even for a new protocol revision? Well, actually, it might be possible to compress everything except ClientHello headers. One should still avoid the 15 and 16 values (and presumably also 17) if one does. E.g.: For ClientHello: 16 03 vv xx xx For ServerHello: 3F+xx xx For Alert on *Hello: 3E xx (Alerts are short) For encrypted message: 80|xx xx (If one wanted to get fancy, one could even try to negotiate this via vv byte (a'la: "record version: TLS 1.3"). -Ilari From nobody Thu Mar 3 10:13:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74BD1B2C77 for ; Thu, 3 Mar 2016 10:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.698 X-Spam-Level: X-Spam-Status: No, score=0.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 Y7lZMC0zD00u for ; Thu, 3 Mar 2016 10:13:25 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0103.outbound.protection.outlook.com [23.103.201.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876691B2C39 for ; Thu, 3 Mar 2016 10:13:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P84r8uLoQa6Je3znsbv4OF/O3vUJDmwSidK5XXGvh3M=; b=kIRSSgsl47bK9pwEgMMKb3IuwWCI6Zr2j6qCoLSGFKXNa7LelPcfwUKjfRLMS1Tl6IgecQDp61VnePlgQeHtTw5bXeccWed7NiOtTyTMWRW1o5RpWQ1wlJNkq+rQI4n3afxeUZnETLeiJRdcALm9iWeppkfSmiUvRccCP46zMec= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB121.namprd09.prod.outlook.com (10.255.200.145) with Microsoft SMTP Server (TLS) id 15.1.415.20; Thu, 3 Mar 2016 18:13:23 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0415.024; Thu, 3 Mar 2016 18:13:23 +0000 From: "Dang, Quynh (Fed)" To: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6h0LczJ8DOZUibIUJHHuPVmgABdJKAAAAkjow= Date: Thu, 3 Mar 2016 18:13:22 +0000 Message-ID: References: <20160303152945.18296912.40009.55386@ll.mit.edu>, <20160303171117.12e627b3@pc1> In-Reply-To: <20160303171117.12e627b3@pc1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: hboeck.de; dkim=none (message not signed) header.d=none;hboeck.de; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-microsoft-exchange-diagnostics: 1; BN1PR09MB121; 5:qjuS6fw7XU0PU4ekoKQBLrBeWZFx6aS2J9UqQoqQ7VD4L4EAn1Y4jCe3V0MmMKhHNxF6cjUWLjD87Fvm43OiXJubhQ3AaYfJ4dawVnzk1fBiOKLpvjXUQ96ze0QImGkzsAsLfdhuEaaq5N9ld1llIw==; 24:MdR0wKxSHkdFiNXIg857d83C1as4+raqG2EuFgt2xurqTXlQ3IpcfFa9e7uT1Jpga0DkXz2hTohNxwvW2moVV3CzPFZL88hLwa+HhSSfbxY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB121; x-ms-office365-filtering-correlation-id: f9b50fe6-13f6-4f3f-6903-08d3438f8209 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN1PR09MB121; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB121; x-forefront-prvs: 0870212862 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(92566002)(3900700001)(6116002)(1096002)(1220700001)(50986999)(5003600100002)(102836003)(586003)(3660700001)(77096005)(2501003)(2900100001)(15975445007)(54356999)(2950100001)(76176999)(81166005)(66066001)(5004730100002)(3280700002)(2906002)(122556002)(40100003)(19580405001)(189998001)(5002640100001)(74316001)(19580395003)(10400500002)(76576001)(86362001)(107886002)(33656002)(99286002)(11100500001)(5001770100001)(5008740100001)(2171001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB121; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2016 18:13:22.6036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB121 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 18:13:29 -0000 UFNTK1NIQUtFMTI4LzUxMitTSEFLRTEyOCBvciBQU1MrU0hBS0UyNTYvNTEyK1NIQUtFMjU2IChh cyBTSEFLRXMgYmVpbmcgdXNlZCBhcyBNR0YpIHdvdWxkIGJlIG1vcmUgZWZmaWNpZW50IG9wdGlv bnMuIE5JU1QgaXMgd29ya2luZyBvbiBhIGZvcm1hbCBzcGVjaWZpY2F0aW9uIGZvciB0aGUgU0hB S0VzIGJlaW5nIHVzZWQgYXMgZml4ZWQgb3V0cHV0LWxlbmd0aCBoYXNoIGZ1bmN0aW9ucyBzdWNo IGFzIFNIQUtFMTI4LzI1NiwgU0hBS0UxMjgvNTEyIGFuZCBTSEFLRTI1Ni81MTIuIA0KDQpQcmVw ZW5kaW5nIGEgcmFuZG9tIHNhbHQgb2YgNTEyLWJpdCBpbiBsZW5ndGggKGZpeGVkIGxlbmd0aCBv ZiA1MTIgYml0cykgdG8gdGhlIG1lc3NhZ2Ugc2hvdWxkIHdvcmsgYW5kIHRoaXMgaXMgdmVyeSBz aW1wbGUgYW5kIGVmZmljaWVudC4NCg0KUXV5bmguIA0KDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogVExTIDx0bHMtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIEhhbm5vIELDtmNrIDxoYW5ub0BoYm9lY2suZGU+DQpTZW50OiBUaHVyc2Rh eSwgTWFyY2ggMywgMjAxNiAxMToxMSBBTQ0KVG86IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBN SVRMTDsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUlNBLVBTUyBpbiBUTFMgMS4z DQoNCk9uIFRodSwgMyBNYXIgMjAxNiAxNToyOTozNyArMDAwMA0KIkJsdW1lbnRoYWwsIFVyaSAt IDA1NTMgLSBNSVRMTCIgPHVyaUBsbC5taXQuZWR1PiB3cm90ZToNCg0KPiBBbHNvLCB3YXNuJ3Qg UFNTIOKAjmRldmVsb3BlZCBiZWZvcmUgU0hBMyBhbmQgU0hBS0Ugd2VyZSBrbm93biwgbGV0DQo+ IGFsb25lIGF2YWlsYWJsZT8NCg0KWWVhaCwgbW9yZSB0aGFuIDEwIHllYXJzIGJlZm9yZS4NCkl0 J3MgbW9yZSB0aGUgb3RoZXIgd2F5IGZvdW5kOiBQU1MgYW5kIG90aGVyIGNvbnN0cnVjdGlvbnMg c2hvd2VkIHRoZQ0KbmVlZCBmb3IgaGFzaCBmdW5jdGlvbnMgd2l0aCBhIGRlZmluZWQgb3V0cHV0 IGxlbmd0aC4gU0hBS0UgaXMgc3VjaCBhDQpmdW5jdGlvbi4gUFNTIHVzZXMgYSBjb25zdHJ1Y3Rp b24gY2FsbGVkIE1HRjEsIHdoaWNoIGVzc2VudGlhbGx5IHRha2VzDQphbiBleGlzdGluZyBmaXhl ZC1vdXRwdXQtbGVuZ3RoIGhhc2gsIGNvbWJpbmVzIHRoYXQgd2l0aCBhIGNvdW50ZXIgYW5kDQpw cm9kdWNlcyBzb21lIGNvbnN0cnVjdGlvbi4gU0hBS0UgZGVwcmVjYXRlcyB0aGUgbmVlZCBmb3Ig c3VjaCBhDQp3b3JrYXJvdW5kLg0KDQpTbyBpbnN0ZWFkIG9mIHVzaW5nIFBTUytTSEEyNTYrTUdG MS13aXRoLVNIQTI1NiB5b3UgY291bGQgc2F5IHlvdSB1c2UNClBTUytTSEEtMy0yNTYrU0hBS0Uy NTYuIEkgZG9uJ3QgdGhpbmsgdGhpcyBjaGFuZ2VzIGEgd2hvbGUgbG90IGluDQpyZWdhcmRzIHRv IHNlY3VyaXR5IChhcyBsb25nIGFzIHdlIGFzc3VtZSBib3RoIHNoYTI1NiBhbmQgc2hhLTMtMjU2 IGFyZQ0KdmVyeSBzZWN1cmUgYWxnb3JpdGhtcykuDQoNCj4gSXQgbWF5IGJlIHdvcnRoIGFza2lu ZyB0aGUgYXV0aG9ycyB3aGF0J3MgdGhlaXIgb3BpbmlvbiBvZiBGREggdnMgUFNTDQo+IGluIHZp ZXcgb2YgdGhlIHN0YXRlIG9mIHRoZSBhcnQgKnRvZGF5Ki4NCg0KWW91IG1heSBkbyB0aGF0LCBi dXQgSSBkb3VidCB0aGF0IGNoYW5nZXMgbXVjaC4NCg0KSSB0aGluayBGREggcmVhbGx5IGlzIG5v dCBhbiBvcHRpb24gYXQgYWxsIGhlcmUuIEl0IG1heSB2ZXJ5IHdlbGwgYmUNCnRoYXQgdGhlcmUg YXJlIGJldHRlciB3YXlzIHRvIGRvIFJTQS1wYWRkaW5nLCBidXQgSSBkb24ndCB0aGluayB0aGF0 DQp0aGlzIGlzIHZpYWJsZSBmb3IgVExTIDEuMyAoYW5kIEkgZG9uJ3QgdGhpbmsgRkRIIGlzIGJl dHRlcikuDQpQU1MgaGFzIGFuIFJGQyAoMzQ0NykgYW5kIGhhcyBiZWVuIHRob3JvdWdobHkgYW5h bHl6ZWQgYnkgcmVzZWFyY2guIEkNCnRoaW5rIHRoZXJlIGhhcyBiZWVuIGZhciBsZXNzIGFuYWx5 emluZyBlZmZvcnQgdG93YXJkcyBGREggKG9yIGFueQ0Kb3RoZXIgY29uc3RydWN0aW9uKSBhbmQg aXQgaXMgbm90IGluIGFueSB3YXkgc3BlY2lmaWVkIGluIGEgc3RhbmRhcmRzDQpkb2N1bWVudC4g SWYgb25lIHdvdWxkIHdhbnQgdG8gdXNlIEZESCBvciBhbnl0aGluZyBlbHNlIG9uZSB3b3VsZCBp bWhvDQpmaXJzdCBoYXZlIHRvIGdvIHRocm91Z2ggc29tZSBzdGFuZGFyZGl6YXRpb24gcHJvY2Vz cyAod2hpY2ggY291bGQgYmUNCkNGUkcgb3IgTklTVCBvciBzb21lb25lIGVsc2UpIGFuZCBjYWxs IGZvciBhIHRob3JvdWdoIGFuYWx5c2lzIG9mIGl0DQpieSB0aGUgY3J5cHRvZ3JhcGhpYyBjb21t dW5pdHkuIFdoaWNoIHdvdWxkIHRha2UgYXQgbGVhc3QgYSBjb3VwbGUgb2YNCnllYXJzLg0KDQpH aXZlbiB0aGF0IHRoZXJlIHByb2JhYmx5IGlzIG5vIGxvbmcgdGVybSBmdXR1cmUgZm9yIFJTQSBh bnl3YXkgKHBlb3BsZQ0Kd2FudCBFQ0MgYW5kIHBvc3RxdWFudHVtIGlzIGFoZWFkKSBJIGRvdWJ0 IGFueXRoaW5nIGVsc2UgdGhhbiB0aGUNCnByaW1pdGl2ZXMgd2UgYWxyZWFkeSBoYXZlIGluIHN0 YW5kYXJkcyB3aWxsIGV2ZXIgYmUgdmlhYmxlLg0KDQoNCi0tDQpIYW5ubyBCw7Zjaw0KaHR0cHM6 Ly9oYm9lY2suZGUvDQoNCm1haWwvamFiYmVyOiBoYW5ub0BoYm9lY2suZGUNCkdQRzogQkJCNTFF NDI= From nobody Thu Mar 3 10:49:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19261B3BB5 for ; Thu, 3 Mar 2016 10:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 4aPwHyeEKKTT for ; Thu, 3 Mar 2016 10:49:38 -0800 (PST) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 D5DF61B40A0 for ; Thu, 3 Mar 2016 10:49:37 -0800 (PST) Received: by mail-qg0-x235.google.com with SMTP id y89so24499537qge.2 for ; Thu, 03 Mar 2016 10:49:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to :content-transfer-encoding; bh=4JiKxCUvONUHO7SneWIvKoCDyCEFiVrZQ/j0+7r+Yhw=; b=uQetrsA+hlvxXbtCpuNDEj5z6hYz4Fx+Gnp5Rs1RZqcRwBVWjxNaKG6Z+NeArrbYCi awSpjRUoZcqds9Sgb9NdcvHaog69S23CSNtX0Ap/hQ2hnJBIM+8K0LTr0WjtJo/QPfRT Z7BnI1NXlQzITtgPW0rUweWFc1i+Jg4hRNe5ScizwFDS9HeAfrJcTDN0qS3L7aBRP77c CLdYyRkX52S126GUyndOaxnTYITKezyBRhEs0m6qI4IIW+ymBkvaE/ro9dJ7jE+2n8ET kz+PcJf2BDTc0vl4OTPJtJ/WF2kkgjz7LXhV6E1s1T1wvusFa3SGrnXuQhmSO/PYybqn 23oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-transfer-encoding; bh=4JiKxCUvONUHO7SneWIvKoCDyCEFiVrZQ/j0+7r+Yhw=; b=Xt61icPDPNSjmGa04nImnImAAwtXIUQekzyajOCY1lkH1u2WwYbuPpmekCWaYJ+k2I hqRFZZKjWjfj+cPh734i3qBN6Pk2ByaRNkcbHPH26G7wC+Jo/lcPPQAe24217zW1N3md 6GHhC3bFosvm8wP9R0TKyPOtHi2bsdCDmerevlQwRHKlBSricaIcakO/aVAlOkkGT9zG ag4k4vCnPy8jvzOhaP1NIkIluQLy69siVktQXMtQwyMELoeIMO4wz+lsSiZJcRKS02Ie X5qAD5SNXh8eZXYW+XDzKVivo60LWijZIp97cxS3n+JJwhuThGv6a60zH34ca48Ggdk4 3LPg== X-Gm-Message-State: AD7BkJIW6st4S4U4tMcovymbogjV3U2k2DbHpS67jOFjqRyr2q4DcvsY/HsQ9zX/vTjivZQiweE/S6AuhaOsag== MIME-Version: 1.0 X-Received: by 10.140.93.84 with SMTP id c78mr4904747qge.101.1457030976960; Thu, 03 Mar 2016 10:49:36 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.22 with HTTP; Thu, 3 Mar 2016 10:49:36 -0800 (PST) Date: Thu, 3 Mar 2016 10:49:36 -0800 X-Google-Sender-Auth: Fu0HTJzBe3czvjy69W4vH8tE440 Message-ID: From: Adam Langley To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 18:49:39 -0000 The Server Name Indication (SNI) extension in TLS has a provision to provide names other than host names[1]. None have even been defined to my knowledge, but it's there. OpenSSL (and possibly others) have had a long-standing bug[2] (fixed in master) that means that different types of names will cause an error. To be clear: I live in a glass house and am not throwing stones; these things happen. However, it means that a huge fraction of the TLS deployment will not be able to accept a different name type should one ever be defined. (This issue might have been caused by the fact that the original[3] spec didn't define the extension in such a way that unknown name types could be skipped over.) Therefore we (i.e. BoringSSL, and thus Google) are proposing to give up on this and implement our parser such that the SNI extension is only allowed to contain a single host name value. (This is compatible with all known clients.) We're assuming that since this is already the de-facto reality that there will be little objection. I'm sending this mostly to record the fact so that, if someone tries to define a new name type in the future, they won't waste their time. If the community wishes to indicate a different type of name in the future, a new extension can be defined. This is already effectively the case because we wouldn't fight this level of incompatibility when there's any other option. (I think the lesson here is that protocols should have a single joint, and that it should be kept well oiled. For TLS, that means that extensions should have minimal extensionality in themselves and that we should generally rely on the main extensions mechanism for these sorts of things.) [1] https://tools.ietf.org/html/rfc6066#section-3 [2] https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib= .c#L1066 =E2=80=93 note that the data pointer is not updated. [3] https://tools.ietf.org/html/rfc4366#section-3.1 Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Mar 3 10:57:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921511B40BA for ; Thu, 3 Mar 2016 10:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 dS5AQqr7U44u for ; Thu, 3 Mar 2016 10:57:11 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F4C91B2CBA for ; Thu, 3 Mar 2016 10:57:11 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id b72so22928734ywe.0 for ; Thu, 03 Mar 2016 10:57:11 -0800 (PST) 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=kyiuNvL4Qufyt+VuRMOfP648EzFipWJkkarB3szRI2Q=; b=pnBgsIpm0ES0lObOqVgXB+/wpQVyA8sUBG/6H+2R37tauotnGoeQg45MTJsJf0FAMb Ud+hR5Mji/XNUSAcTRF6xowsgaGGBVlSezhcsZRMmRi/8x8KtoyIlN2Ou/DaGMHcr+OP iUSHwQy8OKnwUwRkmII+UxDBT7n4yWNbR67gULr/K10SSCT9YnRGQty5ktfj2i3kAnT4 rYZbnw67PNyU3K55DoOPlUmmQsvpiL6z9HLl7o7DRB576eoyfFZf46mc25ZhWAl654Bo Jch+Ma6zTsw5hLMrGG7r52ddSMJDAEIW/HQzKxreeclIr/au7SaKqerOWXA/G+wkkkf8 PVqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kyiuNvL4Qufyt+VuRMOfP648EzFipWJkkarB3szRI2Q=; b=RmR8hfM3WuCpnW21O9in6s/LPCVEq8gD5efu+uWVb4IxvfNY5dG2B4oI3MSGxcVMbx YKyblGVzGeJXrCzG2wjBQ9n6je5WV8y5wU/8pStWPMfAJN/mF+qnlgbOy80Tgac0bEVl wXdBktKixn6F9zxYPpkTZVh80RAzDflkrp3EY2OmkZwODG7A3WUToC5X1Dr4cJg4x37K CDMmrRxc2sQJk2gXKUJHUVmSN81JX3jvkMU10gfEP0sSy13PTu87aQMN97xnSkkiRD75 jli39EnbjWRLC+IFihZXQX3/2RYvU2mgTCLAQqWTTD1dAhNbuBLqkUBwx3d/tiOS7o8N 2WFQ== X-Gm-Message-State: AD7BkJIUfprF2+PMs+6uYS7Upo6SJAbl+mOMCQ0Sa3UTnlgHOFQ0crFryb/3+S+iUOFnW5Nox1thGneyC6ytXQ== X-Received: by 10.129.73.207 with SMTP id w198mr2523265ywa.223.1457031430640; Thu, 03 Mar 2016 10:57:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 3 Mar 2016 10:56:31 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 3 Mar 2016 10:56:31 -0800 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=001a114dc91cd9c5a4052d29907f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 18:57:12 -0000 --001a114dc91cd9c5a4052d29907f Content-Type: text/plain; charset=UTF-8 On Thu, Mar 3, 2016 at 10:49 AM, Adam Langley wrote: > The Server Name Indication (SNI) extension in TLS has a provision to > provide names other than host names[1]. None have even been defined to > my knowledge, but it's there. > > OpenSSL (and possibly others) have had a long-standing bug[2] (fixed > in master) that means that different types of names will cause an > error. To be clear: I live in a glass house and am not throwing > stones; these things happen. However, it means that a huge fraction of > the TLS deployment will not be able to accept a different name type > should one ever be defined. (This issue might have been caused by the > fact that the original[3] spec didn't define the extension in such a > way that unknown name types could be skipped over.) > > Therefore we (i.e. BoringSSL, and thus Google) are proposing to give > up on this and implement our parser such that the SNI extension is > only allowed to contain a single host name value. (This is compatible > with all known clients.) We're assuming that since this is already the > de-facto reality that there will be little objection. I'm sending this > mostly to record the fact so that, if someone tries to define a new > name type in the future, they won't waste their time. > Note: it's already the case that it's forbidden to send >1 of any given type of name. NSS does not presently enforce this rule but will do so soon. Regardless, I am in favor of this proposal. -Ekr --001a114dc91cd9c5a4052d29907f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 3, 2016 at 10:49 AM, Adam Langley <agl@imperialviolet= .org> wrote:
The Server Nam= e Indication (SNI) extension in TLS has a provision to
provide names other than host names[1]. None have even been defined to
my knowledge, but it's there.

OpenSSL (and possibly others) have had a long-standing bug[2] (fixed
in master) that means that different types of names will cause an
error. To be clear: I live in a glass house and am not throwing
stones; these things happen. However, it means that a huge fraction of
the TLS deployment will not be able to accept a different name type
should one ever be defined. (This issue might have been caused by the
fact that the original[3] spec didn't define the extension in such a way that unknown name types could be skipped over.)

Therefore we (i.e. BoringSSL, and thus Google) are proposing to give
up on this and implement our parser such that the SNI extension is
only allowed to contain a single host name value. (This is compatible
with all known clients.) We're assuming that since this is already the<= br> de-facto reality that there will be little objection. I'm sending this<= br> mostly to record the fact so that, if someone tries to define a new
name type in the future, they won't waste their time.
<= div>
Note: it's already the case that it's forbidden = to send >1 of any given type
of name. NSS does not presently e= nforce this rule but will do so soon.

Regardless, = I am in favor of this proposal.

-Ekr
--001a114dc91cd9c5a4052d29907f-- From nobody Thu Mar 3 11:02:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ECA1B4124 for ; Thu, 3 Mar 2016 11:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 J0LIId4iwFZF for ; Thu, 3 Mar 2016 11:02:35 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 A10571B4116 for ; Thu, 3 Mar 2016 11:02:00 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id w104so24947861qge.1 for ; Thu, 03 Mar 2016 11:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=gxg1lvYPKKWJylKroRIU7+payJy/nauSXx5I6CeY1mA=; b=S8U9SZkQs+RJfPDbNjRNAyiSA8IoM4uVb2NiYW5xm8JbNgX72B87u1ckfHuEVVTi0W Vp80GewzkjV/GnawUPw/aX5azGWYOH4h8iULlCpDzyUHTEbK8GNuzZWwY3TVdnMQRusZ D0kJXyN79B/t/KXmvecUqZ028OlEWKiWgzs6KMPOVhj2sPYWvi6c/1EzFm18ke2ZZVOG IPZGQ6oSOjOEjCsGfIdM2csJEBVVTLFlInGO2JoJUasA9zrSx+YDVwZnif4AayRXMI4s mpjxdXAvo/v2XYi9R0xSPhmFKrUnxMocKSipwolng/amxtyYZ57GUsH2gS5p9Z3jG87U MtBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gxg1lvYPKKWJylKroRIU7+payJy/nauSXx5I6CeY1mA=; b=ArmbplBcPBefDWbMjr7oxb6e7jRTcSjNjuKrJp/B7q0a9EsjTB/Bt/6JsX31cUUeSj E+zBd3Ht8wpnlx8UplI6coQWCDLyOXwzFG33LXg91B+O2rlcn53HMV8q+MlU6Mx/bgk4 RxTsw4JzhUtd17Q5dyp87/fcoie5w+dcjZ0vu8vfCvjCYw7KDPxNbbbmcgT0Ks4CskHN GtU/+77DtiE7yCScNanXfM7rc6v+s3JYxAOZS+Gwx/pPGyTOBAssX9T4ukthpcRt1yCs 2t+SegoTkYhLQosMboIEqdkwNhjzgP59oU53tfwuHP/Eogi8j1mrMByMnE2zlHPiRJhq VHxA== X-Gm-Message-State: AD7BkJLtYDtaU1Vy/p1Is4g5apyriMTPKwbZrtyfGKE9c3qeRZca8fsZGd+T/2VIgo6/qn6D1qVeOeTW7AMU6w== MIME-Version: 1.0 X-Received: by 10.140.232.211 with SMTP id d202mr5498907qhc.27.1457031719836; Thu, 03 Mar 2016 11:01:59 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.22 with HTTP; Thu, 3 Mar 2016 11:01:59 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2016 11:01:59 -0800 X-Google-Sender-Auth: uwDEQt0SEslqbtuUBGmYDJfmE0E Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 19:02:37 -0000 On Thu, Mar 3, 2016 at 10:56 AM, Eric Rescorla wrote: > Note: it's already the case that it's forbidden to send >1 of any given type > of name. NSS does not presently enforce this rule but will do so soon. (We have enforced that for a while without issues.) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Mar 3 11:04:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8D51B40B2 for ; Thu, 3 Mar 2016 11:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 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.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJ7gvCb7Qn3K for ; Thu, 3 Mar 2016 11:04:25 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD4C1B410F for ; Thu, 3 Mar 2016 11:03:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9CA6D4334A1; Thu, 3 Mar 2016 19:03:50 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 867354334A0; Thu, 3 Mar 2016 19:03:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457031830; bh=MZt3c022xwdrrc5yAUv6PfUeXPeBIsT4R583SX8ZXno=; l=5134; h=From:To:CC:Date:References:In-Reply-To:From; b=oBF9VCGuGo4V++Ml2QzGoYD22MrpxA9v9/6/9wB9w70/gTElnX/RCN1JjcNZlsYqi ZGrvBtOXRz80FD1jfKGM1/+iZDIr2K03KbWe1999dhJxFkTZySOUf0HENgDADkSZUD n82EVq3HLrZh2/wg/98C9ITkJs6j9lrw30PXEoKc= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8366B1FC8A; Thu, 3 Mar 2016 19:03:50 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 3 Mar 2016 14:03:49 -0500 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.1130.005; Thu, 3 Mar 2016 14:03:49 -0500 From: "Salz, Rich" To: Eric Rescorla , Adam Langley Thread-Topic: [TLS] Accepting that other SNI name types will never work. Thread-Index: AQHRdX1zuTC0M4YSiEineZj3dIEZkJ9IZaOA//+tv9A= Date: Thu, 3 Mar 2016 19:03:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.112.149] Content-Type: multipart/alternative; boundary="_000_fe2f1f0050f74e34ae231839ab425ddfusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 19:04:27 -0000 --_000_fe2f1f0050f74e34ae231839ab425ddfusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gaW4gZmF2b3IsIHdlYXJpbmcgYm90aCBPcGVuU1NMIGFuZCBBa2FtYWkgaGF0cy4NCg0K QW5kIHdvdWxkbuKAmXQgaXQgYmUgYSBtdWNoIGtpbmRlciB3b3JsZCBpZiBBZGFtIHdyb3RlIGFs bCBwb3N0cyBvbiB0aGlzIGxpc3Q/IOKYug0KDQotLQ0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFp IFRlY2hub2xvZ2llcw0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K DQo= --_000_fe2f1f0050f74e34ae231839ab425ddfusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1h aWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PknigJltIGluIGZhdm9yLCB3ZWFyaW5nIGJvdGggT3BlblNTTCBhbmQgQWthbWFpIGhhdHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5BbmQgd291bGRu4oCZdCBpdCBiZSBhIG11Y2gga2luZGVyIHdvcmxkIGlmIEFkYW0g d3JvdGUgYWxsIHBvc3RzIG9uIHRoaXMgbGlzdD8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLSZu YnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlbmlvciBBcmNoaXRlY3QsIEFr YW1haSBUZWNobm9sb2dpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU06IHJpY2hz YWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_fe2f1f0050f74e34ae231839ab425ddfusma1exdag1mb1msgcorpak_-- From nobody Thu Mar 3 13:38:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBB7E1B2C24 for ; Thu, 3 Mar 2016 13:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qmFQa42SmsN for ; Thu, 3 Mar 2016 13:38:06 -0800 (PST) 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 C63821B2C19 for ; Thu, 3 Mar 2016 13:38:05 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id l127so42430630iof.3 for ; Thu, 03 Mar 2016 13:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ZTgF7Rf04aSjTr65qY/hXpL6yJHoDST+vjENKCzxUbk=; b=VknAyj6OeSgWs3e41un0sXlof7JJsMBXXbrzKn+a0fvPBsKtw38edy3xFdbYtAPdzI chONW9SO8xI3SElTdfOuMskOH1eAmYOnx9jptbpiTEzc7NipNuYeI7aZMpzisZYTt84Y qghvjuUTXnBs4xxLMrZnDDRJmvAywkK6LQXmEszGJ18DmF1kbcMp8r+2zp66oZ0KeTtX 58CVUqGHdj7eLNGzEXiayWo68HO7KRtRLnPAxbSkuM5cn9M+/iWL3yrh6UUBpfw1ckGf 62YBHDKNXGSLmlCfyod0Od3DPSBd6+H58QnF6Hjg2twr2tHzxrHs3lmsmW6YsgArGRoP wlYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZTgF7Rf04aSjTr65qY/hXpL6yJHoDST+vjENKCzxUbk=; b=PidNdawW08s8XostHUgsA8YJoSlIpvLIfgDLbSYsEHoqXLUc8FHOzodxyAHk4h5F7P WDIzijFrPUWiRPJE4nJz92U5+SIPq9Fr5Zj2ryPUbw2hqG0FqPNi7Oy0ACGIn3ifOiaX X9we0A0LFfdEl42p24XP2QiMmNM1XfxirKP9GS6aIBaBsDW3vnD8M5X9zhp6lzaRX+CN RkVt0+MWCy0xRQPnAQKuoypYQp0vgKJoB/1Xf345GOFE4XEe7fuRjq4Me155FfXXh+Br 8F0HSLf8y+Nr46ocobIOGRRZACgV4fZkZWOhxu6YT0G1wlMjoO1a48kmIT2rISJ49iC7 XCUg== X-Gm-Message-State: AD7BkJLDn5Q7dINVtXq/1LnwFJtLmm+GVLbqzqBodUFXpZpHZtt4ps6l6eatIwKf2oJDpiTmxPpBgqZO4ZvRzg== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr4775501ioi.108.1457041085117; Thu, 03 Mar 2016 13:38:05 -0800 (PST) Received: by 10.36.43.5 with HTTP; Thu, 3 Mar 2016 13:38:05 -0800 (PST) In-Reply-To: <20160303170442.GB13882@LK-Perkele-V2.elisa-laajakaista.fi> References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> <56CA239F.6010107@acm.org> <56D7076A.1020703@ericsson.com> <56D76716.1090506@acm.org> <20160303164309.GA13882@LK-Perkele-V2.elisa-laajakaista.fi> <20160303170442.GB13882@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 4 Mar 2016 08:38:05 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 21:38:07 -0000 On 4 March 2016 at 04:04, Ilari Liusvaara wrote: > Well, actually, it might be possible to compress everything except > ClientHello headers. ServerHello too, just to make it easy. Might as well include HelloRetryRequest at the same time, so that all unencrypted packets have the same header. From nobody Thu Mar 3 14:24:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AB71B2DB3 for ; Thu, 3 Mar 2016 14:24:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CWvKTBd1tFN for ; Thu, 3 Mar 2016 14:24:41 -0800 (PST) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 23EC51B2DB0 for ; Thu, 3 Mar 2016 14:24:41 -0800 (PST) Received: by mail-wm0-x233.google.com with SMTP id l68so54703066wml.0 for ; Thu, 03 Mar 2016 14:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cDSBp+AdWkM2OMB0bvVIhoylaPdx2jQAcGG2uY8gfsg=; b=0Wz9CgedRAPgF5jqL4c4H8XrzuRAXVwf06kl1ogp6rbh91NPEGtJFhE/TZCy+uzMyS 48Qkt111ehQ9RvkJPJVZ1aVyCAnvgdR30anarUgMhPY31uwGjxDgNPheH+K4N2amDExA QrHL0RWZ5Q3UWd1waCzJuhq+R9Hl2EsTbkIV9qnX3sUTmV+bmfqlpT2OdV/j0RWtrehm J6sK3qi+pq6ahkga33ddXMN4XmVFBJjdW0DN2xSQxa+4kTylg9sWwWjn339HBACGyD2N yulA+XSUh1STDpcAi1eas6UlzuEkgPL2DyBMJ85vJZh7fdXIpuT+x2x1+nLFGldNDSRn 8NyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cDSBp+AdWkM2OMB0bvVIhoylaPdx2jQAcGG2uY8gfsg=; b=TAnv4Uw/bmDM62Vivcb0mCSNZYiaO6e+Gj8CDnG2bcdD49q7bxUB5ZC59T/IFobuMV Vd1c5WxyjleKp7TYbPY+JC3R7M8X+noa43cPinPRtK/7t56icL4Onum+TwIKeP0W18ux ec2bayvZwZKfnMtGr7xGBOgzgno1Abgij16p6R+IHiNmKTMIPPidV0H9umFGgAZsZErN A8PfNz7w9cVAwYhvKmfju1OpSw/lEtLCguQqrBrCtuFN/P93RxJHfecs+tSd2kq6gOE5 ogABAoc0+vhY/G26cR3IcqaWtXYLCJavL2oO9HKMem8QT3HMrCph/EXdSiX9tapDA3hq d9ug== X-Gm-Message-State: AD7BkJKyhNsUSNV/zRCOZd3n5HtR5meD/6efF1oJVIYAwnV1tSLY7nKVx5nfHxav/1ToBg== X-Received: by 10.194.185.108 with SMTP id fb12mr5665699wjc.89.1457043879533; Thu, 03 Mar 2016 14:24:39 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id n131sm487083wmf.9.2016.03.03.14.24.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 03 Mar 2016 14:24:38 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3A98BA17-A2D5-4ACB-8930-88EB6F97B92F" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Fri, 4 Mar 2016 00:24:35 +0200 Message-Id: <937342A0-BE4C-417B-BF94-1260C8EDEAAF@gmail.com> References: <20160302143313.6E6C1180004@rfc-editor.org> To: Bodo Moeller X-Mailer: Apple Mail (2.3112) Archived-At: Cc: sean+ietf@sn3rd.com, Chris Hawk , Kathleen Moriarty , Nelson B Bolyard , "tls@ietf.org" , Vipul Gupta , RFC Errata System Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (4633) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 22:24:43 -0000 --Apple-Mail=_3A98BA17-A2D5-4ACB-8930-88EB6F97B92F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Mar 2016, at 10:59 PM, Bodo Moeller wrote: >=20 > RFC Errata System >: > The following errata report has been submitted for RFC4492, > "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer = Security (TLS)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D4633 = >=20 > -------------------------------------- > Type: Editorial > Reported by: Kurt Roeckx > >=20 > Section: 5.1.1 >=20 > Original Text > ------------- > struct { > NamedCurve elliptic_curve_list<1..2^16-1> > } EllipticCurveList; >=20 > Corrected Text > -------------- > struct { > NamedCurve elliptic_curve_list<2..2^16-1> > } EllipticCurveList; >=20 > Notes > ----- > The count is in bytes, not items. >=20 > I agree with this finding. Each NamedCurve value takes exactly two = bytes, so the floor should have been specified as 2, not 1. >=20 > Bodo Yup. This should be closed as =E2=80=9Cheld for document update=E2=80=9D. Speaking of which: https://github.com/tlswg/rfc4492bis/pull/21 = Yoav --Apple-Mail=_3A98BA17-A2D5-4ACB-8930-88EB6F97B92F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 2 Mar 2016, at 10:59 PM, Bodo Moeller <bmoeller@acm.org> = wrote:

RFC Errata System <rfc-editor@rfc-editor.org>:
The following errata = report has been submitted for RFC4492,
"Elliptic Curve = Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3D4492&eid=3D= 4633

--------------------------------------
Type: = Editorial
Reported by: Kurt Roeckx <kurt@roeckx.be>

Section: 5.1.1

Original Text
-------------
  =       struct {
 =           NamedCurve = elliptic_curve_list<1..2^16-1>
      =   } = EllipticCurveList;

Corrected Text
--------------
        struct {
 =           NamedCurve = elliptic_curve_list<2..2^16-1>
      =   } = EllipticCurveList;

Notes
-----
The count is in bytes, not items.

I agree with this finding.  Each NamedCurve value takes = exactly two bytes, so the floor should have been specified as 2, not = 1.

Bodo

Yup. This should be closed as =E2=80=9Cheld for = document update=E2=80=9D.

Speaking = of which:

Yoav

= --Apple-Mail=_3A98BA17-A2D5-4ACB-8930-88EB6F97B92F-- From nobody Thu Mar 3 14:44:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32081B2E9D for ; Thu, 3 Mar 2016 14:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwwLjy8HyA8Q for ; Thu, 3 Mar 2016 14:44:24 -0800 (PST) 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 ECA0E1B2E9C for ; Thu, 3 Mar 2016 14:44:23 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id m184so44107616iof.1 for ; Thu, 03 Mar 2016 14:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2D40VulIkTEAJWokGIxghDHqQvG8oCjrSTBRgM05AIk=; b=hfskwj7VORLbUp2Igreiyc6CL9JX/Aoghdt4axZ1StW7wJko8/pcqEO0cbgjuTN1fY 0JBLgJX5HVxJErEdFfT5rcutysEAmXvosNZ51BVvgCNjNhYQeO20wR1fzdSDcGjfXYj+ HHui2G6GVrodanfIn3+NkbaVRelXuXGLgfwjY86w0hZsRXUvriyqDl8ywGlMtpvAe1VL ZDA4LQ5a+phsFVr+LylInc7J8yz1JdM6Qxb7e74gAUs1q1ogBd7EMI8pm6OXlsiuMXdu ctjuAPc+fMIjTbMFux1xRqLfMf0W6IgYU/4PaWQh7R08ikWqyyhz1nucvh5RrKv+qD7f PwgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2D40VulIkTEAJWokGIxghDHqQvG8oCjrSTBRgM05AIk=; b=mqvY/lnUCENkwIk6huCSfCHMRmqWxt+885A3lELRHXRD/rqA1jmWdIW/eAtZ/NXZfW cfFBozZK5uVMirudzHjunNw2hp+XgY6Ti37Mm8XCPPLGSCCDwIJTCDJ/hTCEkI4eFN9p sWgzxFE/f7RjlPvbvN71ZNxt9Hep4uoVLpZ3k6eKv9drqLt2njS3FiJAvxtfNtqf5e6J pwxnbhCT24N0OOHkCJAB+/j0dMrerZVvpjBX8M1FDoCGeFlc28A1NC14HtvpUe/IziKO fa2nFbHRTyRp6aztEt+CPaxw01taRnC0tKXkusdX5i0Gb4v0QG7ssn5L7YDSzL4/wGIE R4VA== X-Gm-Message-State: AD7BkJIvj8/j3AaeC2eQITPwiDMmaDpg7VhVoOLdXDwtYdgsUxeHslDsz4iE1wDLiCAN3XSshGBCs+k8VER/2w== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr4983869ioi.108.1457045063420; Thu, 03 Mar 2016 14:44:23 -0800 (PST) Received: by 10.36.43.5 with HTTP; Thu, 3 Mar 2016 14:44:23 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 09:44:23 +1100 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 22:44:25 -0000 On 4 March 2016 at 05:49, Adam Langley wrote: > (I think the lesson here is that protocols should have a single joint, > and that it should be kept well oiled. For TLS, that means that > extensions should have minimal extensionality in themselves and that > we should generally rely on the main extensions mechanism for these > sorts of things.) Big +1 Note that the NSS bug also entailed non-zero SNI name types overwriting the actual SNI. From nobody Thu Mar 3 14:52:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8B91B2EF7 for ; Thu, 3 Mar 2016 14:52:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 NON1O7Hw-hJx for ; Thu, 3 Mar 2016 14:52:37 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F121B2EF8 for ; Thu, 3 Mar 2016 14:52:37 -0800 (PST) Received: by mail-yk0-x229.google.com with SMTP id 1so15916911ykg.3 for ; Thu, 03 Mar 2016 14:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=1EHlWMQ7XmnVgC+zZG3yKmXxw5Atd6j5ya9T5jFw0Yw=; b=qUXzDEsL6n407mLPe7QWfhjtb+t5uFT09LlFe6lFKmn7jgQM77k31N2zUQsKWf547n pJvKShrQopeEetkC31POksCJ9sEybvHUneBH/PTkfa1sdlNOMQRfLi0nzxC/MK0lM2ML NBhQJ/efF4HEG+4cdFPgRqEI9gJsvMfvJrUntbleXbW8O0OK35CoYRmmpYktIZE0u64E jKrT7QXD3pAmM4w97CHb0YBCcSFQofmif6/4e5sMS7IKNwmPSLaji0+w5FDi9Mzcv8va qpaYhtx6y3ONKmQV1zz2zEnTDU0gI4dRqwcY7lko8A7SIMaL8qPIb2zY0zY7ihWho0TN ECuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1EHlWMQ7XmnVgC+zZG3yKmXxw5Atd6j5ya9T5jFw0Yw=; b=bRpen8ChcAdHytW9KQrLamZoX0GhOwjgV4wscDYW8TRHCTEbHNmFGl8Kl49C2XIkEv qoF0fvXXR14ZVcpd6sQOnWBQtgKmg8ZdDynYWpNepl8uI3YSARRyYIe+C2wUgR1uMzQf yqU5e0hDFOLF0HuTksmJ3hu99gtz4JGsVmwZmRP3m3a89j9rHt5fbS58PyMFQ/7H8a77 xWm8OV6s2SWkoSCQexzi6HiVoU/WozaK07IWKNohS1UuNtzp9jj/6Awmx0jZR0DItQuB FnoRaKaC3o+6/hQepqJtwXqSGY3AMtBVjx8tKugbNPRzn/8NLZz9eWLuNRY5KyiZG2no ABAQ== X-Gm-Message-State: AD7BkJKQgntgPi1AbVfym8DQogF/tXXe5uX2PQvmsCFChCNfZmZWgGms6LD3SIiMwLnwFLKdC0JPPpkry1KFnw== MIME-Version: 1.0 X-Received: by 10.37.29.193 with SMTP id d184mr3116691ybd.111.1457045556473; Thu, 03 Mar 2016 14:52:36 -0800 (PST) Sender: richmoore44@gmail.com Received: by 10.37.4.139 with HTTP; Thu, 3 Mar 2016 14:52:36 -0800 (PST) In-Reply-To: References: Date: Thu, 3 Mar 2016 22:52:36 +0000 X-Google-Sender-Auth: dr5dqbsJ3a86Ah8gWiUqivnEV2A Message-ID: From: Richard Moore To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11427890d0b57f052d2cda47 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 22:52:39 -0000 --001a11427890d0b57f052d2cda47 Content-Type: text/plain; charset=UTF-8 If you're fixing that then maybe standardising the errors makes sense too. My fingerprinter sees the following: For an empty name: SNIEmptyName: *(301)alert:DecodeError:fatal| SNIEmptyName: *(301)alert:HandshakeFailure:fatal| SNIEmptyName: *(301)alert:IllegalParameter:fatal| SNIEmptyName: *(303)alert:UnexpectedMesage:fatal| SNIEmptyName: error:Unexpected EOF receiving record header - server closed connection| For a long name (x repeated 500 times): SNILongName: *(301)alert:HandshakeFailure:fatal| SNILongName: *(301)alert:IllegalParameter:fatal| SNILongName: *(301)alert:UnrecognizedName:fatal| SNILongName: *(303)alert:UnexpectedMesage:fatal| SNILongName: error:Unexpected EOF receiving record header - server closed connection| Rich. On 3 March 2016 at 22:44, Martin Thomson wrote: > On 4 March 2016 at 05:49, Adam Langley wrote: > > (I think the lesson here is that protocols should have a single joint, > > and that it should be kept well oiled. For TLS, that means that > > extensions should have minimal extensionality in themselves and that > > we should generally rely on the main extensions mechanism for these > > sorts of things.) > > Big +1 > > Note that the NSS bug also entailed non-zero SNI name types > overwriting the actual SNI. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11427890d0b57f052d2cda47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you're fixing that then maybe standardising the errors m= akes sense too. My fingerprinter sees the following:

For an empty na= me:

SNIEmptyName: *(301)alert:= DecodeError:fatal|
SNIEmptyName: *(301)alert:HandshakeFailure:fatal|
<= div class=3D"gmail_default" style=3D"font-family:verdana,sans-serif">SNIEmp= tyName: *(301)alert:IllegalParameter:fatal|
SNIEmptyName: *(303)alert:Unexp= ectedMesage:fatal|
SNIEmptyName: error:Unexpected EOF receiving record = header - server closed connection|

For a lo= ng name (x repeated 500 times):

SNILongName: *(301)alert:HandshakeFailure:fatal|
SNILongName: *(301)alert:Ill= egalParameter:fatal|
SNILongName: *(301)alert:UnrecognizedName:fatal|
SNILongName: *(30= 3)alert:UnexpectedMesage:fatal|
SNILongName: error:Unexpected EOF receiving record= header - server closed connection|

Rich.


On 3 Ma= rch 2016 at 22:44, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 4 Marc= h 2016 at 05:49, Adam Langley <agl@imperialviolet.org> wrote:
> (I think the lesson here is that protocols should have a single joint,=
> and that it should be kept well oiled. For TLS, that means that
> extensions should have minimal extensionality in themselves and that > we should generally rely on the main extensions mechanism for these > sorts of things.)

Big +1

Note that the NSS bug also entailed non-zero SNI name types
overwriting the actual SNI.

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

--001a11427890d0b57f052d2cda47-- From nobody Thu Mar 3 15:16:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570231B2F9C for ; Thu, 3 Mar 2016 15:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0ErPNbtTTIN for ; Thu, 3 Mar 2016 15:16:26 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 658271B2F55 for ; Thu, 3 Mar 2016 15:16:26 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id hb3so6695897igb.0 for ; Thu, 03 Mar 2016 15:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=IudQrjw5gW63nFyygIt8oUR6cQb3hCh+gIULTqEGJ8c=; b=DNpXDNs16RwHtHkdnRaTyU/7x+b8SVYgs0AI2iGhuToCi1XOt+9hr6lGhZ6c/V1XCq ekuk0twMKtOdZmttwqmEoVHkFihTLHv8TSaddI1dbvd9fi4Ch0xCo7LvHDqAUK4suQTV Uf5WrIaBl4DkGga3vgNMx9lM1B8fHlZgGd2Z2MP53BTKqUq55XE0G6yY+2qqcGn8jlI3 izvHUTtycBFeporXCBiFNnfVuu1NC1IMFdzSO2eqWgDEbuqcoIVl606TIymexhpWANhM gQoUwOhNnscLJe+QRqV4C9DoqK0rGhJLvmVx9dQ3aJahcvE0yZTg8h3ViR0i6+b1XICx U3dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IudQrjw5gW63nFyygIt8oUR6cQb3hCh+gIULTqEGJ8c=; b=Gwk2mvvxSoCk5JStwfb1RURxkomUhV6rPk0czFZKexPdNZyLwynTroRmGDwLV8/f2r pFIewNKh1Y6YFh25RsM4th5v14U4FmyJVMnz2wF/GLHOIRWAmCLM/n9ZaktnF3j0ZO5b wiKesI7kwICbq17pEP3CWe9wJYYl3j6m/PNt0X/GzicnfQ842Vh5x+CW9oeUrzIVr7/N p7++F12VGrIo1e2j1AxeSw2dpivnWBYn2KrtH3aalO487gFN9GJBXk3Zwx7iz6WQ/e1I B8RnVrP4p4pcmYfqOrHRrkNNpFsVBA5SOuNOndJOnpyUVQREoFeJ6V9ZAVIqOaCmjrcN PcGA== X-Gm-Message-State: AD7BkJJvMnLXvDbjan4scBA5i+2yATFU/JyueUHFepSU5bwsQHUQLYgs2oZk0GzWalrP1ABK8J9oJN9EzDMgLQ== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr513221igh.94.1457046985724; Thu, 03 Mar 2016 15:16:25 -0800 (PST) Received: by 10.36.43.5 with HTTP; Thu, 3 Mar 2016 15:16:25 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 10:16:25 +1100 Message-ID: From: Martin Thomson To: Richard Moore Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 03 Mar 2016 23:16:28 -0000 If we actually have a volunteer for sni-bis, then that would be OK with me. However, I don't regard the errors as important. Any hope that they might be used in some automated fashion died a long time ago. Mainly due to this complete lack of consistency. I assume that the last error indicates that you didn't get an alert, which I find is alarmingly common in TLS. On 4 March 2016 at 09:52, Richard Moore wrote: > If you're fixing that then maybe standardising the errors makes sense too. > My fingerprinter sees the following: > > For an empty name: > > SNIEmptyName: *(301)alert:DecodeError:fatal| > SNIEmptyName: *(301)alert:HandshakeFailure:fatal| > SNIEmptyName: *(301)alert:IllegalParameter:fatal| > SNIEmptyName: *(303)alert:UnexpectedMesage:fatal| > SNIEmptyName: error:Unexpected EOF receiving record header - server closed > connection| > > For a long name (x repeated 500 times): > > SNILongName: *(301)alert:HandshakeFailure:fatal| > SNILongName: *(301)alert:IllegalParameter:fatal| > SNILongName: *(301)alert:UnrecognizedName:fatal| > SNILongName: *(303)alert:UnexpectedMesage:fatal| > SNILongName: error:Unexpected EOF receiving record header - server closed > connection| > > Rich. > > > On 3 March 2016 at 22:44, Martin Thomson wrote: >> >> On 4 March 2016 at 05:49, Adam Langley wrote: >> > (I think the lesson here is that protocols should have a single joint, >> > and that it should be kept well oiled. For TLS, that means that >> > extensions should have minimal extensionality in themselves and that >> > we should generally rely on the main extensions mechanism for these >> > sorts of things.) >> >> Big +1 >> >> Note that the NSS bug also entailed non-zero SNI name types >> overwriting the actual SNI. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From nobody Thu Mar 3 17:43:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D58C1B3211 for ; Thu, 3 Mar 2016 17:43:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_lokdWIBBD1 for ; Thu, 3 Mar 2016 17:43:46 -0800 (PST) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 E16791B320D for ; Thu, 3 Mar 2016 17:43:45 -0800 (PST) Received: by mail-qg0-x22e.google.com with SMTP id w104so32905858qge.1 for ; Thu, 03 Mar 2016 17:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=5XLp0seIt8xcvSVm8zHCgL+MfO//1fGIAHmvtS8Qe68=; b=XEk7qjavU/e+F0jDHU4ZJFJBuyzdyCGFUaLKZQDszcJrknYwarGwXdBSeefV3t5JDx yYGZwsgBTTH+vYBoOcoKuOZ1F6Nm8aJkMB4wxZyCbAP0RQtxVioiujoIeL5bO/z8Rwsp UTuxBTgOIYp5N9qTEsRYu3M22fAHhyNwVhsft4t2XfXDGAs5Tp5sTZKvrck54jHkOhuY on8bkrENFdPZTqYffJZSYc2a9NGmMvZ9XSW0quPbeq0jbI9WXAA404reTU6Rv37B9JDj c4iLDb4FDRVmKTrNNOwindba/4XbOsYyYDLnwEQNq0PyvQhufopB0WaaH3n4KX5p639r GD+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=5XLp0seIt8xcvSVm8zHCgL+MfO//1fGIAHmvtS8Qe68=; b=cwH7PkHYWNyhlbu+hts9Po1K+iH0SyZ+pFVwBlyVJGiwabTdy95T/N+Dm9cBo9a2wn mO0VpgCAnAuvhpuDdNoivoQfc5c9Y/D8jbXfTady7sxvj3OyhwIK0QHuhoQ68hWooBXP kyGIosF7mAc2u1yIyoyFghgDUDRwhLP14XRwfN2szJzSyPwVMoMJZGJmyjH/q7fhbaJq ijmui4gbvjIOfIrvi8l/IEEjz87thg+89TgOgVIaPeCHbLXUbjc0R7AczQTSI2Tg+zK1 MqQIGcWFvETB3I9Vm4UDqDCTSTvq4VHuhXcPsPEbbr0LpMT8f8xDNn00WUCM4Y8/EcUF BkMQ== X-Gm-Message-State: AD7BkJICeAgekpa7y6SLliDM5PHBpQtMrBoujmdsgidK4hWlrPeOIUT24Mw0zuBEcerR1g== X-Received: by 10.140.234.11 with SMTP id f11mr7654721qhc.51.1457055825120; Thu, 03 Mar 2016 17:43:45 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id 85sm635155qkw.19.2016.03.03.17.43.44 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 03 Mar 2016 17:43:44 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Thu, 3 Mar 2016 20:43:42 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201603032043.43158.davemgarrett@gmail.com> Archived-At: Cc: Adam Langley Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:43:47 -0000 Do we want to stick some simple new constraints on SNI in the TLS 1.3 draft spec? e.g. SHOULD have exactly one host_name which SHOULD be less than N bytes (significantly less than the current theoretical 64kB ceiling). Just adding a quick blurb for this in there somewhere seems like the simplest solution to me. Dave On Thursday, March 03, 2016 06:16:25 pm Martin Thomson wrote: > If we actually have a volunteer for sni-bis, then that would be OK with me. > > However, I don't regard the errors as important. Any hope that they > might be used in some automated fashion died a long time ago. Mainly > due to this complete lack of consistency. I assume that the last > error indicates that you didn't get an alert, which I find is > alarmingly common in TLS. > > On 4 March 2016 at 09:52, Richard Moore wrote: > > If you're fixing that then maybe standardising the errors makes sense too. > > My fingerprinter sees the following: > > > > For an empty name: > > > > SNIEmptyName: *(301)alert:DecodeError:fatal| > > SNIEmptyName: *(301)alert:HandshakeFailure:fatal| > > SNIEmptyName: *(301)alert:IllegalParameter:fatal| > > SNIEmptyName: *(303)alert:UnexpectedMesage:fatal| > > SNIEmptyName: error:Unexpected EOF receiving record header - server closed > > connection| > > > > For a long name (x repeated 500 times): > > > > SNILongName: *(301)alert:HandshakeFailure:fatal| > > SNILongName: *(301)alert:IllegalParameter:fatal| > > SNILongName: *(301)alert:UnrecognizedName:fatal| > > SNILongName: *(303)alert:UnexpectedMesage:fatal| > > SNILongName: error:Unexpected EOF receiving record header - server closed > > connection| > > > > Rich. > > > > > > On 3 March 2016 at 22:44, Martin Thomson wrote: > >> > >> On 4 March 2016 at 05:49, Adam Langley wrote: > >> > (I think the lesson here is that protocols should have a single joint, > >> > and that it should be kept well oiled. For TLS, that means that > >> > extensions should have minimal extensionality in themselves and that > >> > we should generally rely on the main extensions mechanism for these > >> > sorts of things.) > >> > >> Big +1 > >> > >> Note that the NSS bug also entailed non-zero SNI name types > >> overwriting the actual SNI. From nobody Thu Mar 3 22:00:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E401B33B8 for ; Thu, 3 Mar 2016 22:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.962 X-Spam-Level: X-Spam-Status: No, score=-0.962 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=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 jODrR0pvIOut for ; Thu, 3 Mar 2016 22:00:30 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31A441B33B9 for ; Thu, 3 Mar 2016 22:00:30 -0800 (PST) Received: from mail-lb0-f176.google.com ([209.85.217.176]) by mrelayeu.kundenserver.de (mreue101) with ESMTPSA (Nemesis) id 0MJTPH-1aZoAx0g9r-00332d for ; Fri, 04 Mar 2016 07:00:28 +0100 Received: by mail-lb0-f176.google.com with SMTP id cf7so32992971lbb.1 for ; Thu, 03 Mar 2016 22:00:26 -0800 (PST) X-Gm-Message-State: AD7BkJLbump8kbeAJ1ij+Ya8PmiRgT2/WAcO9p4yhcgv5AjC+uA/kvp5WvPijRY8wwanN3YuYMwtaRxvYGbDmw== MIME-Version: 1.0 X-Received: by 10.25.135.8 with SMTP id j8mr2433594lfd.64.1457071226358; Thu, 03 Mar 2016 22:00:26 -0800 (PST) Received: by 10.112.22.67 with HTTP; Thu, 3 Mar 2016 22:00:26 -0800 (PST) Received: by 10.112.22.67 with HTTP; Thu, 3 Mar 2016 22:00:26 -0800 (PST) In-Reply-To: References: <20160302143313.6E6C1180004@rfc-editor.org> Date: Fri, 4 Mar 2016 07:00:26 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: Glen Knowles Content-Type: multipart/alternative; boundary=001a113fc32cdc17b1052d32d41b X-Provags-ID: V03:K0:CHZ8LEewvycQTq1ndBIVE+00MJisa83USnCOrN1VtWwY21PA2qC blUUFQRbFq8VoWzeGmtqw9PX/o85aqMx0vOEPCqeAdbcy5Ph+PfFgachpmUtOlfcAS1700P OGEC6qcuQeBK+KDwb7kb2SoNMwcTGcCX7Snii2i/y0uPskQQNwkYGJclz+0v+Xp+vOZLpyV +twPk9wHehVTPPm5s1Ibw== X-UI-Out-Filterresults: notjunk:1;V01:K0:o8GX7v4j4rs=:v1WJcGAawezOCZqxXP/bA1 Ibsc12mRaNjJUWPZvESMsPCmpTKeKztbjvclGShYLmuVw57Ss/mg6i6F0P7F8ifW3vOK0JIeI RuLUzSFisA+SeVBn1floo+AeVDaDrKFMK4pBVozGgckQRUf/mjR8XaERjp7gVOBlX1am8sqBJ /FyUJRlMKVlyEsN0WbBthB998DPUQI22tk+SICgykIW1UUyZ00k1FgyOvSuq6ikOiL/eKaIwk OSjpobN4JDI5FYlglDc8vxHIy9xVV0ChPmSFnI0L1jNq7Youfd+p9wrIWv6H0mSIQyRDbw/Uz /LPTrHIaIP3hJwopNwNiL50tWgBncWXy05cSY3r9ZfVm9a5YYjc4f5LfNYW/YTta/Z2NAhWJN E6CFnmeK92Fsx1uLfCKipfXJz4zm5WBcNcxN9Y5bCWFunvYsVtu2fzuZjYldkzqiwyVXvciyl 0Fbhz+IUczaVl1BV4AqJ1Sd4k5k7IJ0qx+j4U3sGw6thIeolGe6t10EMdE0u8kYBiumVJKuTB Mir398db+76Jui9kYn55iu8bbp0+nUudm0UN5YQru8itmPiRKeZBfpQRu20D6mKAJa/MXTBXt Rvym5TUpz67GujnWEhRi8y5WZf4fl75nVNoRDt2t4PLtVWCaqH8kqn8LDwGLMtiBqTwAXh62O cWdAE/WpVGvtEjCNfd1vROslws0YQtkEYNl0U9HQK/zeZQbyRZeTRTdpRFB1zxmDKyooRfA1A gM7FwFcGE4kAmJTa Archived-At: Cc: sean+ietf@sn3rd.com, Kathleen Moriarty , Chris Hawk , Nelson B Bolyard , tls@ietf.org, Vipul Gupta , RFC Editor Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (4633) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 06:00:32 -0000 --001a113fc32cdc17b1052d32d41b Content-Type: text/plain; charset=UTF-8 "Glen Knowles" : > To be pedantic wouldn't it be: > NamedCurve elliptic_curve_list<2..2^16-2> Arguably so, but that's not how the TLS RFCs use the presentation language in practice (see ClientHello.cipher_suites for just one example), and we'd want to be consistent with that, not extra nitpicky. Bodo --001a113fc32cdc17b1052d32d41b Content-Type: text/html; charset=UTF-8

"Glen Knowles" <gknowles@ieee.org>:

> To be pedantic wouldn't it be:
> NamedCurve elliptic_curve_list<2..2^16-2>

Arguably so, but that's not how the TLS RFCs use the presentation language in practice (see ClientHello.cipher_suites for just one example), and we'd want to be consistent with that, not extra nitpicky.

Bodo

--001a113fc32cdc17b1052d32d41b-- From nobody Thu Mar 3 22:14:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93171B33CB for ; Thu, 3 Mar 2016 22:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibsX0HD-xUAP for ; Thu, 3 Mar 2016 22:14:42 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DE701B33C9 for ; Thu, 3 Mar 2016 22:14:42 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id z8so10772803ige.0 for ; Thu, 03 Mar 2016 22:14:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9eZffpSqEu6c93YkruYiNH4Azooq9Ucj7coZhxp3UpA=; b=b5CuLmoGFrKqowmP3WJOEuDkLKmD1NG2st8lehgHY9Ir+ERxRIF443Ffez+UKG+in0 OcbPCiPTo4bGCg7MOy/oyHCnBlY4aMDUy4GYBqmhUIIgW4JkV7TschUsX9Yjl7mOy9vS Y73AoEx0vUvw+dJxiPSGqvUZLSvrTx0DmDeDZb8buoLX1+ufddaAcQBPTuVCFJf1KtH1 b+U30ncTj30CZZe4BgH9/AppZp44mxx+hzNznMQZeXyf+uy8sgYtaTQB1B1nWBoggRMV 29bXqDrA6gHl1Zx/x/5WhxBXcAF42ujB4dyepP5iLw9ORbM3HmAaK957rLTkEQT2MNTn pIFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9eZffpSqEu6c93YkruYiNH4Azooq9Ucj7coZhxp3UpA=; b=M4G10Pw8vzsVMWBZhHBWstw02dUZQkCZuQflTBaUWkNWbOlIrXzLVBjnOwcZKRbWS0 ipBDIQqEEiSZnV8ERtNhBCrksVyG0w6njuwBTE83NocylR8vH4spsIFwmpa9X2ojgJNx xzFyeMnZJDSMjSRnjLBQ+rQIskiOAjFE/02HCY0/W2eL7qJiP8Rzf31kHFvjVTuk93JS uDw7M1EPuHnidpzMA7gGLaqrQpapl74iCXPJJvuW3M5RB+I8GjtKuA7sIb+PBWWYsVCF CrYh15cS7MuchVpZ7aF17oH3jaiThF7XnciVmEuH7I88tpPI1ywyzdHa9RwzfTS8Zziu Z5Dw== X-Gm-Message-State: AD7BkJI+iASHp9nJQ8R1cRj3XI8BxpNKNAQTfYprNNgzfDG/WUVa/PyABsSQneul9hPGAI+If2LwbivT5aTAaQ== MIME-Version: 1.0 X-Received: by 10.50.41.106 with SMTP id e10mr2169026igl.94.1457072081891; Thu, 03 Mar 2016 22:14:41 -0800 (PST) Received: by 10.36.43.5 with HTTP; Thu, 3 Mar 2016 22:14:41 -0800 (PST) In-Reply-To: <201603032043.43158.davemgarrett@gmail.com> References: <201603032043.43158.davemgarrett@gmail.com> Date: Fri, 4 Mar 2016 17:14:41 +1100 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 06:14:43 -0000 On 4 March 2016 at 12:43, Dave Garrett wrote: > Just adding a quick blurb for this in there somewhere seems like the simplest solution to me. That doesn't fix it for 1.2, but I'd be OK with that. Define SNI as: struct { uint16 extension_tag = 0; uint16 extension_length = strlen(name) + 5; uint16 name_list_length = strlen(name) + 3; uint8 name_type = 0; uint16 name_length = strlen(name); uint8 name[strlen(name)]; } SNI; Or something like that. From nobody Thu Mar 3 23:15:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EFE1B345E for ; Thu, 3 Mar 2016 23:15:01 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m29rdcxbRg6A for ; Thu, 3 Mar 2016 23:15:00 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 C43CC1B345B for ; Thu, 3 Mar 2016 23:14:59 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 4E410F0C52BA; Fri, 4 Mar 2016 07:14:56 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u247EvCd008273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2016 07:14:57 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u247CRsq011871 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Mar 2016 08:14:50 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.130]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 4 Mar 2016 08:06:09 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Adam Langley , "tls@ietf.org" Thread-Topic: [TLS] Accepting that other SNI name types will never work. Thread-Index: AQHRdX12Q+nwt3mZlUq33/gRSAaAQ59IzOaA Date: Fri, 4 Mar 2016 07:06:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 07:15:01 -0000 Hi Adam, On 03/03/2016 18:49, "TLS on behalf of Adam Langley" wrote: >The Server Name Indication (SNI) extension in TLS has a provision to >provide names other than host names[1]. None have even been defined to >my knowledge, but it's there. > >OpenSSL (and possibly others) have had a long-standing bug[2] (fixed >in master) that means that different types of names will cause an >error. To be clear: I live in a glass house and am not throwing >stones; these things happen. However, it means that a huge fraction of >the TLS deployment will not be able to accept a different name type >should one ever be defined. (This issue might have been caused by the >fact that the original[3] spec didn't define the extension in such a >way that unknown name types could be skipped over.) > >Therefore we (i.e. BoringSSL, and thus Google) are proposing to give >up on this and implement our parser such that the SNI extension is >only allowed to contain a single host name value. (This is compatible >with all known clients.) We're assuming that since this is already the >de-facto reality that there will be little objection. I'm sending this >mostly to record the fact so that, if someone tries to define a new >name type in the future, they won't waste their time. > >If the community wishes to indicate a different type of name in the >future, a new extension can be defined. This is already effectively >the case because we wouldn't fight this level of incompatibility when >there's any other option. > >(I think the lesson here is that protocols should have a single joint, >and that it should be kept well oiled. For TLS, that means that >extensions should have minimal extensionality in themselves and that >we should generally rely on the main extensions mechanism for these >sorts of things.) > >[1] https://tools.ietf.org/html/rfc6066#section-3 >[2]=20 >https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c# >L1066 >=AD note that the data pointer is not updated. >[3] https://tools.ietf.org/html/rfc4366#section-3.1 > > >Cheers > >AGL > >--=20 >Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Thu Mar 3 23:19:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363431B3475 for ; Thu, 3 Mar 2016 23:19:14 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKc65Sx8vRRW for ; Thu, 3 Mar 2016 23:19:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-02.alcatel-lucent.com [135.245.210.23]) (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 5FB4B1B3472 for ; Thu, 3 Mar 2016 23:19:08 -0800 (PST) Received: from fr711umx2.dmz.alcatel-lucent.com (unknown [135.245.210.39]) by Websense Email Security Gateway with ESMTPS id 063B07AA49FB; Fri, 4 Mar 2016 07:19:05 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr711umx2.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u247J6S5019469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2016 07:19:06 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u247Hvl2030075 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Mar 2016 08:18:58 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.130]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 4 Mar 2016 08:10:06 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Adam Langley , "tls@ietf.org" Thread-Topic: [TLS] Accepting that other SNI name types will never work. Thread-Index: AQHRdX12Q+nwt3mZlUq33/gRSAaAQ59IzOaAgAABGAA= Date: Fri, 4 Mar 2016 07:10:06 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="euc-kr" Content-ID: <74FBD3139A5FB7439C4B0942C28367D0@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 07:19:14 -0000 VHJ5aW5nIGFnYWluLi4uDQoNCj4gSGkgQWRhbSwNCg0KDQpJbiBDb1JFIHdlIG1pZ2h0IG5lZWQg dG8gYWxsb2NhdGUgYSBuZXcgU05JIE5hbWVUeXBlIGZvciBub24tRE5TIGhvc3QNCm5hbWVzIFsx XS4NCg0KUmVtb3ZpbmcgU05JIGV4dGVuc2liaWxpdHkgd291bGQgbWFrZSBpdCB1bmZlYXNpYmxl Lg0KDQpDaGVlcnMsIHQNCg0KWzFdIA0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWZvc3NhdGktY29yZS1jZXJ0bW9kZS1yZC1uYW1lcy0wMCNzZWN0aW9uDQotMy4zDQoNCg0KPk9u IDAzLzAzLzIwMTYgMTg6NDksICJUTFMgb24gYmVoYWxmIG9mIEFkYW0gTGFuZ2xleSIgPHRscy1i b3VuY2VzQGlldGYub3JnDQo+b24gYmVoYWxmIG9mIGFnbEBpbXBlcmlhbHZpb2xldC5vcmc+IHdy b3RlOg0KPj5UaGUgU2VydmVyIE5hbWUgSW5kaWNhdGlvbiAoU05JKSBleHRlbnNpb24gaW4gVExT IGhhcyBhIHByb3Zpc2lvbiB0bw0KPj5wcm92aWRlIG5hbWVzIG90aGVyIHRoYW4gaG9zdCBuYW1l c1sxXS4gTm9uZSBoYXZlIGV2ZW4gYmVlbiBkZWZpbmVkIHRvDQo+Pm15IGtub3dsZWRnZSwgYnV0 IGl0J3MgdGhlcmUuDQo+Pg0KPj5PcGVuU1NMIChhbmQgcG9zc2libHkgb3RoZXJzKSBoYXZlIGhh ZCBhIGxvbmctc3RhbmRpbmcgYnVnWzJdIChmaXhlZA0KPj5pbiBtYXN0ZXIpIHRoYXQgbWVhbnMg dGhhdCBkaWZmZXJlbnQgdHlwZXMgb2YgbmFtZXMgd2lsbCBjYXVzZSBhbg0KPj5lcnJvci4gVG8g YmUgY2xlYXI6IEkgbGl2ZSBpbiBhIGdsYXNzIGhvdXNlIGFuZCBhbSBub3QgdGhyb3dpbmcNCj4+ c3RvbmVzOyB0aGVzZSB0aGluZ3MgaGFwcGVuLiBIb3dldmVyLCBpdCBtZWFucyB0aGF0IGEgaHVn ZSBmcmFjdGlvbiBvZg0KPj50aGUgVExTIGRlcGxveW1lbnQgd2lsbCBub3QgYmUgYWJsZSB0byBh Y2NlcHQgYSBkaWZmZXJlbnQgbmFtZSB0eXBlDQo+PnNob3VsZCBvbmUgZXZlciBiZSBkZWZpbmVk LiAoVGhpcyBpc3N1ZSBtaWdodCBoYXZlIGJlZW4gY2F1c2VkIGJ5IHRoZQ0KPj5mYWN0IHRoYXQg dGhlIG9yaWdpbmFsWzNdIHNwZWMgZGlkbid0IGRlZmluZSB0aGUgZXh0ZW5zaW9uIGluIHN1Y2gg YQ0KPj53YXkgdGhhdCB1bmtub3duIG5hbWUgdHlwZXMgY291bGQgYmUgc2tpcHBlZCBvdmVyLikN Cj4+DQo+PlRoZXJlZm9yZSB3ZSAoaS5lLiBCb3JpbmdTU0wsIGFuZCB0aHVzIEdvb2dsZSkgYXJl IHByb3Bvc2luZyB0byBnaXZlDQo+PnVwIG9uIHRoaXMgYW5kIGltcGxlbWVudCBvdXIgcGFyc2Vy IHN1Y2ggdGhhdCB0aGUgU05JIGV4dGVuc2lvbiBpcw0KPj5vbmx5IGFsbG93ZWQgdG8gY29udGFp biBhIHNpbmdsZSBob3N0IG5hbWUgdmFsdWUuIChUaGlzIGlzIGNvbXBhdGlibGUNCj4+d2l0aCBh bGwga25vd24gY2xpZW50cy4pIFdlJ3JlIGFzc3VtaW5nIHRoYXQgc2luY2UgdGhpcyBpcyBhbHJl YWR5IHRoZQ0KPj5kZS1mYWN0byByZWFsaXR5IHRoYXQgdGhlcmUgd2lsbCBiZSBsaXR0bGUgb2Jq ZWN0aW9uLiBJJ20gc2VuZGluZyB0aGlzDQo+Pm1vc3RseSB0byByZWNvcmQgdGhlIGZhY3Qgc28g dGhhdCwgaWYgc29tZW9uZSB0cmllcyB0byBkZWZpbmUgYSBuZXcNCj4+bmFtZSB0eXBlIGluIHRo ZSBmdXR1cmUsIHRoZXkgd29uJ3Qgd2FzdGUgdGhlaXIgdGltZS4NCj4+DQo+PklmIHRoZSBjb21t dW5pdHkgd2lzaGVzIHRvIGluZGljYXRlIGEgZGlmZmVyZW50IHR5cGUgb2YgbmFtZSBpbiB0aGUN Cj4+ZnV0dXJlLCBhIG5ldyBleHRlbnNpb24gY2FuIGJlIGRlZmluZWQuIFRoaXMgaXMgYWxyZWFk eSBlZmZlY3RpdmVseQ0KPj50aGUgY2FzZSBiZWNhdXNlIHdlIHdvdWxkbid0IGZpZ2h0IHRoaXMg bGV2ZWwgb2YgaW5jb21wYXRpYmlsaXR5IHdoZW4NCj4+dGhlcmUncyBhbnkgb3RoZXIgb3B0aW9u Lg0KPj4NCj4+KEkgdGhpbmsgdGhlIGxlc3NvbiBoZXJlIGlzIHRoYXQgcHJvdG9jb2xzIHNob3Vs ZCBoYXZlIGEgc2luZ2xlIGpvaW50LA0KPj5hbmQgdGhhdCBpdCBzaG91bGQgYmUga2VwdCB3ZWxs IG9pbGVkLiBGb3IgVExTLCB0aGF0IG1lYW5zIHRoYXQNCj4+ZXh0ZW5zaW9ucyBzaG91bGQgaGF2 ZSBtaW5pbWFsIGV4dGVuc2lvbmFsaXR5IGluIHRoZW1zZWx2ZXMgYW5kIHRoYXQNCj4+d2Ugc2hv dWxkIGdlbmVyYWxseSByZWx5IG9uIHRoZSBtYWluIGV4dGVuc2lvbnMgbWVjaGFuaXNtIGZvciB0 aGVzZQ0KPj5zb3J0cyBvZiB0aGluZ3MuKQ0KPj4NCj4+WzFdIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM2MDY2I3NlY3Rpb24tMw0KPj5bMl0gDQo+Pmh0dHBzOi8vZ2l0aHViLmNvbS9v cGVuc3NsL29wZW5zc2wvYmxvYi9PcGVuU1NMXzFfMF8xLXN0YWJsZS9zc2wvdDFfbGliLmMNCj4+ Iw0KPj5MMTA2Ng0KPj6hqSBub3RlIHRoYXQgdGhlIGRhdGEgcG9pbnRlciBpcyBub3QgdXBkYXRl ZC4NCj4+WzNdIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0MzY2I3NlY3Rpb24tMy4x DQo+Pg0KPj4NCj4+Q2hlZXJzDQo+Pg0KPj5BR0wNCj4+DQo+Pi0tIA0KPj5BZGFtIExhbmdsZXkg YWdsQGltcGVyaWFsdmlvbGV0Lm9yZyBodHRwczovL3d3dy5pbXBlcmlhbHZpb2xldC5vcmcNCj4+ DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PlRM UyBtYWlsaW5nIGxpc3QNCj4+VExTQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdGxzDQo+DQo+DQoNCg0K From nobody Thu Mar 3 23:58:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B0A1B34A3 for ; Thu, 3 Mar 2016 23:58:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb_B-uSQEyx0 for ; Thu, 3 Mar 2016 23:58:07 -0800 (PST) Received: from BLU004-OMC2S4.hotmail.com (blu004-omc2s4.hotmail.com [65.55.111.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC6B1B34A1 for ; Thu, 3 Mar 2016 23:58:07 -0800 (PST) Received: from BLU177-W1 ([65.55.111.72]) by BLU004-OMC2S4.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 3 Mar 2016 23:58:06 -0800 X-TMN: [AEc2oZSt2N1kqOtyEwgi8yi2HKp5qU8M] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "Fossati, Thomas Nokia - GB" , Adam Langley , "tls@ietf.org" Date: Thu, 3 Mar 2016 23:58:05 -0800 Importance: Normal In-Reply-To: References: , , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2016 07:58:06.0069 (UTC) FILETIME=[95C14250:01D175EB] Archived-At: Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 07:58:10 -0000 ----------------------------------------=0A= > From: thomas.fossati@nokia.com=0A= > To: agl@imperialviolet.org=3B tls@ietf.org=0A= > Date: Fri=2C 4 Mar 2016 07:10:06 +0000=0A= > Subject: Re: [TLS] Accepting that other SNI name types will never work.= =0A= >=0A= > Trying again...=0A= >=0A= >> Hi Adam=2C=0A= >=0A= >=0A= > In CoRE we might need to allocate a new SNI NameType for non-DNS host=0A= > names [1].=0A= >=0A= > Removing SNI extensibility would make it unfeasible.=0A= >=0A= > Cheers=2C t=0A= >=0A= > [1]=0A= > https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#secti= on=0A= > -3.3=0A= Is limiting the list to only one SNI name entry feasible?=0A= =0A= Yuhong Bao = From nobody Fri Mar 4 00:09:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F052B1B34B4 for ; Fri, 4 Mar 2016 00:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYdr9W3a42oL for ; Fri, 4 Mar 2016 00:09:38 -0800 (PST) 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 E166E1B2B51 for ; Fri, 4 Mar 2016 00:09:37 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 35469C09FAAF; Fri, 4 Mar 2016 08:09:37 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.239]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2489Yd1013996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 4 Mar 2016 03:09:36 -0500 Message-ID: <1457078973.19296.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hanno =?ISO-8859-1?Q?B=F6ck?= , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Date: Fri, 04 Mar 2016 09:09:33 +0100 In-Reply-To: <20160303171117.12e627b3@pc1> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:09:41 -0000 On Thu, 2016-03-03 at 17:11 +0100, Hanno Böck wrote: > It may be worth asking the authors what's their opinion of FDH vs > > PSS > > in view of the state of the art *today*. > You may do that, but I doubt that changes much. > > I think FDH really is not an option at all here. It may very well be > that there are better ways to do RSA-padding, but I don't think that > this is viable for TLS 1.3 (and I don't think FDH is better). > PSS has an RFC (3447) and has been thoroughly analyzed by research. I > think there has been far less analyzing effort towards FDH (or any > other construction) and it is not in any way specified in a standards > document. If one would want to use FDH or anything else one would > imho > first have to go through some standardization process (which could be > CFRG or NIST or someone else) and call for a thorough analysis of it > by the cryptographic community. Which would take at least a couple of > years. > > Given that there probably is no long term future for RSA anyway > (people > want ECC and postquantum is ahead) I doubt anything else than the > primitives we already have in standards will ever be viable. On the contrary. If we have a future with quantum computers available, the only thing that we have now and would work is RSA with larger keys, not ECC. regards, Nikos From nobody Fri Mar 4 00:42:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D4F1B3514 for ; Fri, 4 Mar 2016 00:42:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03tiU4eQOacP for ; Fri, 4 Mar 2016 00:42:47 -0800 (PST) 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 08A4C1B350F for ; Fri, 4 Mar 2016 00:42:47 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id l127so55630736iof.3 for ; Fri, 04 Mar 2016 00:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Uop5v6w2JFLNSWqQtWCwdWPbz7x8Ox1A27mYe3SGZVY=; b=jMRNcrz0eE/V9ewsRhcr5k7SyqTuOJrRHESqzJDLNzOAP1lvXuVHP0BK98Vq48qC/I EfnIKBsxbGkMBIDH6PUK2UYWQyRVadVrh0dUs3RtsGbbbzIXsOzCItClkE/XT+IyNlip p/3GVinItNkC3jYaPsAtL5Srwmxq99WIyyvAR01NcRkiqvD5badlZ/WJQSHivh8vq1BO IVNtamCctWDchWFtAvKxmLBK1obn1z0JdX+mOl/r2eqhj6K3ormbg+FPJv55ceJEycNx 2r+oQ9+it5blhAlwW4o2s7gJUUbdfEnzNs8JBqVPzdIlRF/hKRDBQ2Gk8O9m80bNT/F1 usRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Uop5v6w2JFLNSWqQtWCwdWPbz7x8Ox1A27mYe3SGZVY=; b=K1Zr4kGGG1VAA0ggiZXA/ICs5DLDzX9c9h60LlAetd5Ypn1CCrca70ntuNYYFlLB7i 3CD+tFi34u8qnLw09THMUXg11kVbFw1l7cu44fmKY74KjbKmsEDkru2Ui1rrxqg0lFKO r55/BH9BB+E82TwTtOD1iHLSnnCvzi//RjqT/DprpKkF/blr6arBWaLSfkSQRdm4xjNK /qlhrCjq1eRtBRpwFLX56V2m4pSY3zCueDcsdmse04bk1f0mBJhXapk8T4BRig28AltU rFsHEyTtYKYAJHdrax4/9lZhMyR37kVw6xpLF/4Dtab/hmB5ar8vI2gJqvzvig+Clzqe 77Ow== X-Gm-Message-State: AD7BkJKC1cUsShNfi4F6o4fO7FAE2JxIQhVa7NI7zIBjmNjZFRuh1Wt1pymNToG9CgnVzm+olyZnTbLSPsNptQ== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr7751407iod.190.1457080966393; Fri, 04 Mar 2016 00:42:46 -0800 (PST) Received: by 10.36.43.5 with HTTP; Fri, 4 Mar 2016 00:42:46 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 19:42:46 +1100 Message-ID: From: Martin Thomson To: "Fossati, Thomas (Nokia - GB)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:42:48 -0000 On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB) wrote: > In CoRE we might need to allocate a new SNI NameType for non-DNS host > names [1]. > > Removing SNI extensibility would make it unfeasible. Not at all. Define a new extension. We have evidence that that works. From nobody Fri Mar 4 01:51:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56771B3598 for ; Fri, 4 Mar 2016 01:51:10 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASMtTmy1eVYA for ; Fri, 4 Mar 2016 01:51:09 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 864AA1A6F6D for ; Fri, 4 Mar 2016 01:51:08 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C1389A89A6BD0; Fri, 4 Mar 2016 09:51:04 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u249p67R024348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2016 09:51:06 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u249nP2v018619 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Mar 2016 10:50:54 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.130]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 4 Mar 2016 10:03:41 +0100 From: "Fossati, Thomas (Nokia - GB)" To: EXT Yuhong Bao , Adam Langley , "tls@ietf.org" Thread-Topic: [TLS] Accepting that other SNI name types will never work. Thread-Index: AQHRdX12Q+nwt3mZlUq33/gRSAaAQ59IzOaAgAABGACAAA1tgIAAEk4A Date: Fri, 4 Mar 2016 09:03:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BF35C5BF85B4F48B68A6957284BCE69@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:51:11 -0000 On 04/03/2016 07:58, "EXT Yuhong Bao" wrote: >---------------------------------------- >> From: thomas.fossati@nokia.com >> To: agl@imperialviolet.org; tls@ietf.org >> Date: Fri, 4 Mar 2016 07:10:06 +0000 >> Subject: Re: [TLS] Accepting that other SNI name types will never work. >> >> Trying again... >> >>> Hi Adam, >> >> >> In CoRE we might need to allocate a new SNI NameType for non-DNS host >> names [1]. >> >> Removing SNI extensibility would make it unfeasible. >> >> Cheers, t >> >> [1] >>=20 >>https://tools.ietf.org/html/draft-fossati-core-certmode-rd-names-00#secti >>on >> -3.3 >Is limiting the list to only one SNI name entry feasible? Yes, I think so. From nobody Fri Mar 4 01:51:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5E11B3599 for ; Fri, 4 Mar 2016 01:51:33 -0800 (PST) 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksAxchgIPNrN for ; Fri, 4 Mar 2016 01:51:32 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 2453B1B3598 for ; Fri, 4 Mar 2016 01:51:32 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D67CBEE490BF1; Fri, 4 Mar 2016 09:51:28 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u249pUFo025322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 4 Mar 2016 09:51:30 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u249mn8b017062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Mar 2016 10:51:14 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.130]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 4 Mar 2016 10:03:54 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Martin Thomson Thread-Topic: [TLS] Accepting that other SNI name types will never work. Thread-Index: AQHRdX12Q+nwt3mZlUq33/gRSAaAQ59IzOaAgAABGACAABnpAIAABeKA Date: Fri, 4 Mar 2016 09:03:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:51:33 -0000 On 04/03/2016 08:42, "TLS on behalf of Martin Thomson" wrote: >On 4 March 2016 at 18:10, Fossati, Thomas (Nokia - GB) > wrote: >> In CoRE we might need to allocate a new SNI NameType for non-DNS host >> names [1]. >> >> Removing SNI extensibility would make it unfeasible. > >Not at all. It would, the way it is formulated at the moment. But that doesn't matter, we can change it to whatever as long as we can make it work. >Define a new extension. We have evidence that that works. That can be done, of course. Although it strikes me as odd to add another extension given the exact same facility is already in place. There are various ways SNI can be tightened other than removing the parametrisation on NameType, e.g. limiting the number of ServerName entries to 1. From nobody Fri Mar 4 05:45:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969031A00B5 for ; Fri, 4 Mar 2016 05:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BmFEde7J82FU for ; Fri, 4 Mar 2016 05:45:17 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FB1F1A00B1 for ; Fri, 4 Mar 2016 05:45:17 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 7C8062A97C; Fri, 4 Mar 2016 14:45:14 +0100 (CET) X-purgate-ID: 152705::1457099114-00007292-A7062D6A/0/0 X-purgate-size: 1788 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 457F340C14; Fri, 4 Mar 2016 14:45:14 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EED9E1A45C; Fri, 4 Mar 2016 14:45:13 +0100 (CET) In-Reply-To: <20160229190021.59516808@pc1> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Fri, 4 Mar 2016 14:45:13 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20160304134513.EED9E1A45C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Mar 2016 13:45:19 -0000 Hanno B=F6ck wrote: > Joseph Salowey wrote: >>=20 >> We make RSA-PSS mandatory to implement (MUST implement instead of MUST >> offer). Clients can advertise support for PKCS-1.5 for backwards >> compatibility in the transition period. >> Please respond on the list on whether you think this is a reasonable >> way forward or not. >=20 > I recently already saw the message here asking for PKCS #1 1.5 > compatibilty and was quite angry about it, but as there wasn't much > discussion I thought this issue would go away. It seems it did not. >=20 > RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. RSA-PSS signatures are crap, and they're pretty close to useless. What should have adopted for TLSv1.2 already, however, is the less forgiving PKCS#1 v1.5 signature check, that re-creates the encoding and then compares the recreated inner encoding with the RSA-decrypted encoding only. Get rid of the de-padding and get rid of the ASN.1 decoding of the contents. This is also the recommended fashion for PKCS#1 v1.5 signature verification in rfc3447. The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA signatures is that one can clearly distinguish "wrong public key" from "signature does not fit plaintext" errors, and loosing this capability makes certain kinds of programming goofs (plus a few admin configuration goofs) much harder to distinguish from data corruption during transfer. XMLdsig and XML canonicalization is another source of endless fun, where being able to distinguish these causes for signature verification failure facilitates troubleshooting. Signature verification itself is a public key operation, so RSA-PSS is a wholly different beast than RSA-OAEP. -Martin From nobody Fri Mar 4 05:49:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677BD1A00DB for ; Fri, 4 Mar 2016 05:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.902 X-Spam-Level: X-Spam-Status: No, score=-11.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giLKbbdzZTuA for ; Fri, 4 Mar 2016 05:49:13 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 186FD1A00D4 for ; Fri, 4 Mar 2016 05:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3216; q=dns/txt; s=iport; t=1457099353; x=1458308953; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=GRQIYRauLCTYsWzvtZg/QgCdmK3oxCVp5QyG+55+yjQ=; b=BBi8Eu0eGU9LwmtOO5CGk3GUu1TSNWaBpgnt8srEhbzaxDZAolFk8/O5 R/eBj6hklty1L1KpRiymQtrtVzbfkpfmdZBSTYLfQi0pYQNaQe8i2noFq aqIfkgA7cmanScvsCObf/pcLO9IQQsJmIiFr2R5FKAtHcdKitUt90xeVA g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOBQD6kNlW/51dJa1dDoMsgT8GukCBa?= =?us-ascii?q?YYPAhyBFzoSAQEBAQEBAWQnhEEBAQEEHQYRQBEEAgEIEQQBAQECAiMDAgICMBQ?= =?us-ascii?q?BCAgBAQQBEggMiA6uSo59AQEBAQEBAQEBAQEBAQEBAQEBARd7hRyEPIc5gToFl?= =?us-ascii?q?yEBjWCPAI5RASYBO4MpO2qIJH4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,535,1449532800"; d="scan'208";a="244080158" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Mar 2016 13:49:12 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u24DnBcc023755 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 4 Mar 2016 13:49:11 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 4 Mar 2016 07:49:11 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Fri, 4 Mar 2016 07:49:11 -0600 From: "Scott Fluhrer (sfluhrer)" To: Nikos Mavrogiannopoulos , =?utf-8?B?SGFubm8gQsO2Y2s=?= , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AA== Date: Fri, 4 Mar 2016 13:49:11 +0000 Message-ID: <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> In-Reply-To: <1457078973.19296.1.camel@redhat.com> 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: [10.98.2.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:49:14 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogVExTIFttYWlsdG86dGxz LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOaWtvcw0KPiBNYXZyb2dpYW5ub3BvdWxv cw0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDA0LCAyMDE2IDM6MTAgQU0NCj4gVG86IEhhbm5vIELD tmNrOyBCbHVtZW50aGFsLCBVcmkgLSAwNTUzIC0gTUlUTEw7IHRsc0BpZXRmLm9yZw0KPiBTdWJq ZWN0OiBSZTogW1RMU10gUlNBLVBTUyBpbiBUTFMgMS4zDQo+IA0KPiBPbiBUaHUsIDIwMTYtMDMt MDMgYXQgMTc6MTEgKzAxMDAsIEhhbm5vIELDtmNrIHdyb3RlOg0KPiA+IEl0IG1heSBiZSB3b3J0 aCBhc2tpbmcgdGhlIGF1dGhvcnMgd2hhdCdzIHRoZWlyIG9waW5pb24gb2YgRkRIIHZzDQo+ID4g PiBQU1MNCj4gPiA+IGluIHZpZXcgb2YgdGhlIHN0YXRlIG9mIHRoZSBhcnQgKnRvZGF5Ki4NCj4g PiBZb3UgbWF5IGRvIHRoYXQsIGJ1dCBJIGRvdWJ0IHRoYXQgY2hhbmdlcyBtdWNoLg0KPiA+DQo+ ID4gSSB0aGluayBGREggcmVhbGx5IGlzIG5vdCBhbiBvcHRpb24gYXQgYWxsIGhlcmUuIEl0IG1h eSB2ZXJ5IHdlbGwgYmUNCj4gPiB0aGF0IHRoZXJlIGFyZSBiZXR0ZXIgd2F5cyB0byBkbyBSU0Et cGFkZGluZywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdA0KPiA+IHRoaXMgaXMgdmlhYmxlIGZvciBU TFMgMS4zIChhbmQgSSBkb24ndCB0aGluayBGREggaXMgYmV0dGVyKS4NCj4gPiBQU1MgaGFzIGFu IFJGQyAoMzQ0NykgYW5kIGhhcyBiZWVuIHRob3JvdWdobHkgYW5hbHl6ZWQgYnkgcmVzZWFyY2gu IEkNCj4gPiB0aGluayB0aGVyZSBoYXMgYmVlbiBmYXIgbGVzcyBhbmFseXppbmcgZWZmb3J0IHRv d2FyZHMgRkRIIChvciBhbnkNCj4gPiBvdGhlciBjb25zdHJ1Y3Rpb24pIGFuZCBpdCBpcyBub3Qg aW4gYW55IHdheSBzcGVjaWZpZWQgaW4gYSBzdGFuZGFyZHMNCj4gPiBkb2N1bWVudC4gSWYgb25l IHdvdWxkIHdhbnQgdG8gdXNlIEZESCBvciBhbnl0aGluZyBlbHNlIG9uZSB3b3VsZCBpbWhvDQo+ ID4gZmlyc3QgaGF2ZSB0byBnbyB0aHJvdWdoIHNvbWUgc3RhbmRhcmRpemF0aW9uIHByb2Nlc3Mg KHdoaWNoIGNvdWxkIGJlDQo+ID4gQ0ZSRyBvciBOSVNUIG9yIHNvbWVvbmUgZWxzZSkgYW5kIGNh bGwgZm9yIGEgdGhvcm91Z2ggYW5hbHlzaXMgb2YgaXQNCj4gPiBieSB0aGUgY3J5cHRvZ3JhcGhp YyBjb21tdW5pdHkuIFdoaWNoIHdvdWxkIHRha2UgYXQgbGVhc3QgYSBjb3VwbGUgb2YNCj4gPiB5 ZWFycy4NCj4gPg0KPiA+IEdpdmVuIHRoYXQgdGhlcmUgcHJvYmFibHkgaXMgbm8gbG9uZyB0ZXJt IGZ1dHVyZSBmb3IgUlNBIGFueXdheQ0KPiA+IChwZW9wbGUgd2FudCBFQ0MgYW5kIHBvc3RxdWFu dHVtIGlzIGFoZWFkKSBJIGRvdWJ0IGFueXRoaW5nIGVsc2UgdGhhbg0KPiA+IHRoZSBwcmltaXRp dmVzIHdlIGFscmVhZHkgaGF2ZSBpbiBzdGFuZGFyZHMgd2lsbCBldmVyIGJlIHZpYWJsZS4NCj4g DQo+IE9uIHRoZSBjb250cmFyeS4gSWYgd2UgaGF2ZSBhIGZ1dHVyZSB3aXRoIHF1YW50dW0gY29t cHV0ZXJzIGF2YWlsYWJsZSwgdGhlDQo+IG9ubHkgdGhpbmcgdGhhdCB3ZSBoYXZlIG5vdyBhbmQg d291bGQgd29yayBpcyBSU0Egd2l0aCBsYXJnZXIga2V5cywgbm90IEVDQy4NCg0KUlNBIGlzbid0 ICp0aGF0KiBtdWNoIG1vcmUgc2VjdXJlIGFnYWluc3QgYSBRdWFudHVtIENvbXB1dGVyIHRoYW4g RUNDLiAgSXQgd291bGQgYXBwZWFyIHRvIHRha2UgYSBsYXJnZXIgUXVhbnR1bSBDb21wdXRlciB0 byBicmVhayBSU0EgdGhhbiBpdCB3b3VsZCB0byBicmVhayBFQ0MgKGZvciByZWFzb25hYmxlIG1v ZHVsaS9jdXJ2ZSBzaXplcyksIGhvd2V2ZXIgbm90IHRoYXQgbXVjaCBtb3JlLiAgSXQgaXMgcG9z c2libGUgdGhhdCwgYXQgb25lIHN0YWdlLCB3ZSdsbCBiZSBhYmxlIHRvIGJ1aWxkIGEgUUMgdGhh dCdzIGp1c3QgbGFyZ2UgZW5vdWdoIHRvIGJyZWFrIEVDIGN1cnZlcywgYnV0IG5vdCBsYXJnZXIg UlNBIGtleXMgLSBob3dldmVyLCB3ZSB3b3VsZCBiZSBsaWtlbHkgdG8gYmUgYWJsZSB0byBzY2Fs ZSB1cCBvdXIgUUMgdG8gYmUgYSBiaXQgbGFyZ2VyOyBwb3NzaWJseSBpbiBhIGZldyBtb250aHMs IHF1aXRlIGxpa2VseSBpbiBhIHllYXIgb3IgdHdvLiAgSGVuY2UsIG1vdmluZyBiYWNrIHRvIFJT QSB3b3VsZCBhcHBlYXIgbGlrZWx5IHRvIGJ1eSB1cyBvbmx5IGEgc2hvcnQgd2luZG93Li4uDQoN CkkgYWdyZWUgd2l0aCBIYW5ubzsgaWYgd2UncmUgaW50ZXJlc3RlZCBpbiBkZWZlbmRpbmcgYWdh aW5zdCBhIFF1YW50dW0gQ29tcHV0ZXIsIHBvc3QgUXVhbnR1bSBhbGdvcml0aG1zIGFyZSB0aGUg d2F5IHRvIGdvDQo= From nobody Fri Mar 4 05:55:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A811A00B6 for ; Fri, 4 Mar 2016 05:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 B_l_16f9ixHz for ; Fri, 4 Mar 2016 05:55:27 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63301A0113 for ; Fri, 4 Mar 2016 05:55:27 -0800 (PST) Received: from pc1 (0x3ec6eda7.inet.dsl.telianet.dk [::ffff:62.198.237.167]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 04 Mar 2016 14:55:23 +0100 id 0000000000000027.0000000056D993CB.0000306F Date: Fri, 4 Mar 2016 14:55:25 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: mrex@sap.com (Martin Rex) Message-ID: <20160304145525.1fe5cb63@pc1> In-Reply-To: <20160304134513.EED9E1A45C@ld9781.wdf.sap.corp> References: <20160229190021.59516808@pc1> <20160304134513.EED9E1A45C@ld9781.wdf.sap.corp> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-12399-1457099723-0001-2" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:55:29 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-12399-1457099723-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 4 Mar 2016 14:45:13 +0100 (CET) mrex@sap.com (Martin Rex) wrote: > What should have adopted for TLSv1.2 already, however, is the less > forgiving PKCS#1 v1.5 signature check, that re-creates the encoding > and then compares the recreated inner encoding with the RSA-decrypted > encoding only. Get rid of the de-padding and get rid of the ASN.1 > decoding of the contents. The Problem with this is that you're relying on the implementor to get it right. Sure, you're giving them a receip how they could implement the check to be correct, but you have no way of checking whether they actually follow that receip. Given all past experiences I'd bet you can write whatever you want in your new standards document, no implementor will replace their (seemingly working, but insecure) PKCS #1 1.5 implementation as long as it works, just because you say they have to do it in a different way than they did in the past. > The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA > signatures is that one can clearly distinguish "wrong public key" > from "signature does not fit plaintext" errors, and loosing this > capability makes certain kinds of programming goofs (plus a few > admin configuration goofs) much harder to distinguish from > data corruption during transfer. Actually I see this as a disadvantage. Separating different error states has been the source of a whole number of vulnerabilities. The original Bleichenbacher attack (and all its variants including drown) is based on separating different errors, the Vaudenay attack is. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-12399-1457099723-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW2ZPOAAoJEKWIAHK7tR5CVSIP/11m4WBIEOPcI7UcZyjElXUm Lb7k8crlSlFtKpOQlU/5Pdek/zMABnY1fzXzmQNBAMSig6YfM/+asxUNxhGP9L3x kTzyt5NutPNfdXYeqoV+KomIKNwPM4J3+gZIsRCRKLg6CBYF3cuQK0a8DXGNRqyF cB0WPlX6pw/upG3i2Np7MpTIwXushKq7MwZfPfNwB7CnJcyhxTBlXu2UFZXOEm+T AC9LET92JGvBuOUB7krlmmEZBCOpuEfE1srtWExrkBafYLatD3kHyGwNRoEAB8fr 7a7zDPfI0Rk4HugzVY5EkRwDft6Bsft5Nyghba2jYHeH2CA62Nf8Mri26cMl0RjV a65eq/cB15qdkpMSrfCC3M/KPY7fHCzOWC97+4g26Zmg6ffShqSCBO3RS05CvYnW NGrtx53S40TQTFbOo9Aa13CE/0KoVh9mnB8pUpzst8Loz0ANBB3JS8yuuakWTfKY SnoQUFYe3g7xRItozfE4uy8jPTlmdxQgF5oM2mM1Bv+NK4uBRQpOLq9yvMu+5iMh +YxuP0eqw/87NYnUfwDMAnbP7zXbUaJWo8vsZfqRfc/DY5aqkUh9ZtY/iFjYp55K ULiaANJ+XhLjZZczOByT0DVuXIaDoKw8+x2LFLb7kHZJVXEtwSK6VDZfrYoR6T9D HyeW9lztiSgwHwWkAi+Z =W6Hc -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-12399-1457099723-0001-2-- From nobody Fri Mar 4 06:20:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374861A01D6 for ; Fri, 4 Mar 2016 06:20:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.251 X-Spam-Level: X-Spam-Status: No, score=-6.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjgPjogK7lmg for ; Fri, 4 Mar 2016 06:20:26 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431521A022C for ; Fri, 4 Mar 2016 06:20:26 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 881592AE27; Fri, 4 Mar 2016 15:20:24 +0100 (CET) X-purgate-ID: 152705::1457101224-000073AB-63B2442F/0/0 X-purgate-size: 1023 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4B752413D2; Fri, 4 Mar 2016 15:20:24 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2A7191A45C; Fri, 4 Mar 2016 15:20:24 +0100 (CET) In-Reply-To: <20160304145525.1fe5cb63@pc1> To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Date: Fri, 4 Mar 2016 15:20:24 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20160304142024.2A7191A45C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Mar 2016 14:20:30 -0000 Hanno B=F6ck wrote: > mrex@sap.com (Martin Rex) wrote: >> >> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA >> signatures is that one can clearly distinguish "wrong public key" >> from "signature does not fit plaintext" errors, and loosing this >> capability makes certain kinds of programming goofs (plus a few >> admin configuration goofs) much harder to distinguish from >> data corruption during transfer. >=20 > Actually I see this as a disadvantage. Separating different error > states has been the source of a whole number of vulnerabilities. The > original Bleichenbacher attack (and all its variants including drown) > is based on separating different errors, the Vaudenay attack is. I'm sorry, but this is clueless. Signature verification is a PUBLIC KEY operation. You're not creating an oracle with a public key operation. The examples you cite are about secret key and private key operations which create oracles. That isn't even in the same universe. -Martin From nobody Fri Mar 4 07:42:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8493E1A1EEE for ; Fri, 4 Mar 2016 07:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VntJU8dY4YpE for ; Fri, 4 Mar 2016 07:42:30 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5911C1A21A9 for ; Fri, 4 Mar 2016 07:42:30 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id h129so47369096ywb.1 for ; Fri, 04 Mar 2016 07:42:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=yUW7q0RdqYd0yFtvA6YrUUpt9upevihHwQkcVdiDavQ=; b=YK8B+nTVF2+Zxf/9+7ObgGhJBE3XJgx0KORcr5mirHELLUp7ubh9w8WhbaYpTgpzjh /GczULv5PHAlLSyIWJb24YbzhjOhGYXfJEP8qCXaDOYYodBbq5gTy0K3fXvDgbo/HDnx O6RraXg7VlIm621GxhzCFqnlfMKJUUFW5FO/BnLnQC0wol0wJsN11OqtscokttIK+KeI 25sKvr98hAaa3XcwfWQfazV2sW8UpTUYPCcyMmFtYO/DciLEqN4zU+BcAwl3/4anFxvI QFp3ptq3GkJXjx785dQ37ZGoZqVeBO96vC8a03PKsy37FHE5tj5O2Os0L8GalUPnszx6 EzMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=yUW7q0RdqYd0yFtvA6YrUUpt9upevihHwQkcVdiDavQ=; b=OoIlPl5uz/qTtdI0vV20BkanXc8S04wCILLqBUxLEEdt3qS8GAXaDLDJxEqKqnBxxe ouoB1kN1ZRS4CP0vgQz2cHRRRgp7WqY+HzSDb1+OTkNMjgNpqMdpVRpTCap39A6PmlH+ HnJBbrshkO6sYyArOmpNSb1W6o33ZOZC9tplQYbjanX32bsjMaExlHpCgq8QJxxwfNTu OK7jeLno3q2V6uhzVR8Pl+J5paUsY5Mjm6sPeurAapp89NfXkSgr/xuP1LOQvNHvjbIa vHb4Cuv/VAEqtATsUwKh7wgrH7HfSrmRWKYZ8QTqB/X84cNlGHhj8nqoSrwhaY78pmuS JQqQ== X-Gm-Message-State: AD7BkJJWrmLUtxpAzsjjma3+cP2RuyPxMjEE5+jDofVwJw+8+LjYokh0Ruk/q9n8lE3HvjgaGoIjaHIecYuNGg== MIME-Version: 1.0 X-Received: by 10.129.55.199 with SMTP id e190mr5077889ywa.55.1457106149654; Fri, 04 Mar 2016 07:42:29 -0800 (PST) Sender: richmoore44@gmail.com Received: by 10.37.4.139 with HTTP; Fri, 4 Mar 2016 07:42:29 -0800 (PST) In-Reply-To: References: Date: Fri, 4 Mar 2016 15:42:29 +0000 X-Google-Sender-Auth: QPrdENDQh8U6DZdynZD8D2auhCQ Message-ID: From: Richard Moore To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1143fcc0734a0b052d3af61d Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:42:31 -0000 --001a1143fcc0734a0b052d3af61d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 3 March 2016 at 23:16, Martin Thomson wrote =E2=80=8B:=E2=80=8B > > I assume that the last > error indicates that you didn't get an alert, which I find is > alarmingly common in TLS. > > =E2=80=8BYes, that's right. Cheers Rich. --001a1143fcc0734a0b052d3af61d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 3 March 2016 at 23:16, Martin Thomson <martin.thomson@gmail= .com> wrote
=E2=80=8B:=E2=80=8B
=C2=A0I assume that the last
error indicates that you didn't get an alert, which I find is
alarmingly common in TLS.

<= br>
=E2=80=8BYes, that's right.

Cheers

=
Rich.
--001a1143fcc0734a0b052d3af61d-- From nobody Fri Mar 4 08:45:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46AF1A1A68 for ; Fri, 4 Mar 2016 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.803 X-Spam-Level: * X-Spam-Status: No, score=1.803 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 ldhPj0nQNZrk for ; Fri, 4 Mar 2016 08:45:32 -0800 (PST) Received: from smtp-01-out.s.azet.sk (smtp-05-out.s.azet.sk [91.235.53.55]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCDD1A1A4D for ; Fri, 4 Mar 2016 08:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1457109931; bh=uBjep+ACL+Nq6t8WS1UlDGgbB5x4NJZG+Osap73BfUQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XsVneRWUfVCIJWapy3PLn/10ZEm+jfGlhbyQqLgNqHQsDnDF3j8oPgjhz/9v/3Oor iAjomaHTd84lduUA0pBwLw/MRCNDXM4xLYhqgdQK9WiLpa85/FAdwq7djYDuv+2bHZ jGbgEKlFdC1TRZYhOhyPyrlCebtfG5HWfjserw84= X-Virus-Scanned: by AntiSpam at azet.sk X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk C9AF99A Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk To: tls@ietf.org References: <20160302065747.GC10917@mournblade.imrryr.org> <201603021616.15731.davemgarrett@gmail.com> <20160303144947.0402bad9@pc1> From: Fedor Brunner Message-ID: <56D9BB9F.5090102@azet.sk> Date: Fri, 4 Mar 2016 17:45:19 +0100 MIME-Version: 1.0 In-Reply-To: <20160303144947.0402bad9@pc1> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:45:35 -0000 Hanno Bck: > On Thu, 3 Mar 2016 13:35:46 +0000 > "Dang, Quynh (Fed)" wrote: > >> Why don't we use an even more elegant RSA signature called " >> full-domain hash RSA signature" ? > > Full Domain Hashing was originally developed by Rogaway and Bellare and > then later dismissed because they found that they could do better. Then > they developed PSS. > > See > http://web.cs.ucdavis.edu/~rogaway/papers/exact.pdf > > So in essence FDH is a predecessor of PSS and the authors of both > schemes came to the conclusion that PSS is the superior scheme. > > >> As you know, a SHAKE (as a variable output-length hash function) >> naturally produces a hash value which fits any given modulus size. >> Therefore, no paddings are needed which avoids any potential issues >> with the paddings and the signature algorithm would be very simple. > > You could also use SHAKE in PSS to replace MGF1. This is probably > desirable if you intent to use PSS with SHA-3. > > PSS doesn't really have any padding in the traditional sense. That is, > all the padding is somehow either hashed or xored with a hashed value. > I don't think any of the padding-related issues apply in any way to > PSS, if you disagree please explain. > > (shameless plug: I wrote my thesis about PSS, in case anyone wants to > read it: https://rsapss.hboeck.de/ - it's been a while, don't be too > hard on me if I made mistakes) > > Please see the paper "Another Look at ``Provable Security''" from Neal Koblitz and Alfred Menezes. https://eprint.iacr.org/2004/152 Section 7: Conclusion "There is no need for the PSS or Katz-Wang versions of RSA; one might as well use just the basic hash and exponentiate signature scheme (with a full-domain hash function)." Fedor From nobody Fri Mar 4 09:01:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE6E1A1ADD for ; Fri, 4 Mar 2016 09:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Im-nzKgTHmLx for ; Fri, 4 Mar 2016 09:01:23 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DD3C1A1AA7 for ; Fri, 4 Mar 2016 09:01:23 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 717092AE78; Fri, 4 Mar 2016 18:01:21 +0100 (CET) X-purgate-ID: 152705::1457110881-00007292-D927B88B/0/0 X-purgate-size: 462 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 407934152C; Fri, 4 Mar 2016 18:01:21 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 01C9A1A45C; Fri, 4 Mar 2016 18:01:20 +0100 (CET) In-Reply-To: <56D9BB9F.5090102@azet.sk> To: Fedor Brunner Date: Fri, 4 Mar 2016 18:01:20 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20160304170121.01C9A1A45C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Mar 2016 17:01:28 -0000 Fedor Brunner wrote: > > Please see the paper "Another Look at ``Provable Security''" from Neal > Koblitz and Alfred Menezes. > > https://eprint.iacr.org/2004/152 > > Section 7: Conclusion > > "There is no need for the PSS or Katz-Wang versions of RSA; > one might as well use just the basic ?hash and exponentiate? signature > scheme (with a full-domain hash function)." Thanks a million for adding some clue to this discussion! -Martin From nobody Sat Mar 5 00:46:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 173A61A88DA for ; Sat, 5 Mar 2016 00:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ETwwNfy6HS7 for ; Sat, 5 Mar 2016 00:46:13 -0800 (PST) Received: from smtp2.cs.Stanford.EDU (smtp2.cs.stanford.edu [171.64.64.26]) (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 8DF8D1A88D7 for ; Sat, 5 Mar 2016 00:46:13 -0800 (PST) Received: from [64.129.13.2] (port=57197 helo=[192.168.6.15]) by smtp2.cs.Stanford.EDU with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1ac7qk-00026r-9e; Sat, 05 Mar 2016 00:46:11 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Philip Levis In-Reply-To: Date: Sat, 5 Mar 2016 00:46:01 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4E97445F-95CD-49A1-91A6-9F9FE94F0C48@cs.stanford.edu> References: <20160226122425.GA32313@LK-Perkele-V2.elisa-laajakaista.fi> To: Eric Rescorla X-Mailer: Apple Mail (2.3112) X-Scan-Signature: 6c66c47a22907c63296a3ecdec1f9d62 Archived-At: Cc: Dan Boneh , Judson Wilson , Keith Winstein , Henry Corrigan-Gibbs , "Riad S. Wahby" , "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:46:15 -0000 Comments inline. > On Feb 27, 2016, at 9:53 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara = wrote: > On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote: > > Hello folks, > > > > How this helps: In the current draft, an endpoint that sends a = KeyUpdate > > message and later receives a KeyUpdate message cannot know whether = the > > other side has actually updated its receive keys. The two messages = may have > > been generated independently and crossed in flight. Putting a > > receive_generation field in the KeyUpdate message lets an endpoint = confirm > > that the other side has received and acted upon an earlier KeyUpdate > > message. >=20 > Well, the KeyUpdates are designed to be asynchronous so that the other > end does not need to know if the other has acted on KeyUpdate. >=20 > That's correct. And would continue to be the case here. Absolutely. This mechanism doesn=E2=80=99t in any way compromise the = asynchronous behavior of KeyUpdate. However, there=E2=80=99s a big = difference between whether an endpoint has to know, and whether an = endpoint can know. The goal of this mechanism is to provide a very = simple, lightweight way for an endpoint to (asynchronously) learn when = the other side has acted on KeyUpdate (asynchronously).=20 >=20 > =20 >=20 > > One way for a client to grant delayed read-only access in TLS 1.3 is = with a > > "rotate and release." The client starts by sending a KeyUpdate. = Later, > > after all traffic keys from the previous generation have been = superseded on > > both sides, the client releases the (superseded) traffic keys to the > > middlebox. The middlebox can use the keys to decrypt the previous > > generation of ciphertext, without danger of compromising the = integrity of > > the session. The challenge is that an endpoint can't safely release = its old > > send keys until it knows that the other side has updated its receive = keys. > > Hence the receive_generation field. >=20 > There are better (and less broken) ways to do this kind of thing > (involving two MACs). >=20 > I agree that there are arguably more elegant approaches if you are = willing > to change TLS. It seems like the argument here is that this doesn't = require > ay significant changes. Exactly. Two MACs might be elegant, but elegant !=3D deployable. >=20 > > We think this is a pretty lightweight way to resolve the ambiguity = from > > KeyUpdates crossing in flight; it doesn't add any blocking, waiting, = or > > extra rounds or messages. Thanks in advance for any feedback. >=20 > The KeyUpdate design is so that crossings don't matter. Something I think that might not have been clear is this proposal = doesn=E2=80=99t in any way change how KeyUpdates are generated or = processed. In that way, crossings do not matter for the protocol. = However, from an application standpoint, when a KeyUpdate is performed, = there can be ambiguities on which keys are in use. Ambiguities in secure = protocols can create problematic edge cases, like the one Judson = outlined. We=E2=80=99d like it to be possible to resolve those = ambiguities without changing TLS or adding any significant complexity. Ilari, do you see a security flaw in having one side know which keys the = other side is using? Explicit information between the two endpoints = seems like a good idea to me. Or do you think this change makes TLS more = complex and harder to implement correctly? Phil From nobody Sat Mar 5 01:48:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383341B2BA7 for ; Sat, 5 Mar 2016 01:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_E4DSd-4BgS for ; Sat, 5 Mar 2016 01:48:51 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id F3E331B2BA4 for ; Sat, 5 Mar 2016 01:48:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 913DD21FB; Sat, 5 Mar 2016 11:48:49 +0200 (EET) 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 ySViq92q6hcv; Sat, 5 Mar 2016 11:48:49 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 44C8A21C; Sat, 5 Mar 2016 11:48:49 +0200 (EET) Date: Sat, 5 Mar 2016 11:48:43 +0200 From: Ilari Liusvaara To: Philip Levis Message-ID: <20160305094843.GA13115@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160226122425.GA32313@LK-Perkele-V2.elisa-laajakaista.fi> <4E97445F-95CD-49A1-91A6-9F9FE94F0C48@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E97445F-95CD-49A1-91A6-9F9FE94F0C48@cs.stanford.edu> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Dan Boneh , Judson Wilson , Keith Winstein , Henry Corrigan-Gibbs , "Riad S. Wahby" , "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:48:54 -0000 On Sat, Mar 05, 2016 at 12:46:01AM -0800, Philip Levis wrote: > Something I think that might not have been clear is this proposal > doesn’t in any way change how KeyUpdates are generated or processed. > In that way, crossings do not matter for the protocol. However, from > an application standpoint, when a KeyUpdate is performed, there can > be ambiguities on which keys are in use. Ambiguities in secure > protocols can create problematic edge cases, like the one Judson > outlined. We’d like it to be possible to resolve those ambiguities > without changing TLS or adding any significant complexity. There should be no ambiguities from application standpoint. The whole reason for fully asynchronous design is that the application does not have to care about rekeying (other than setting parameters if the defaults aren't suitable). And TLS stacks only need to know current valid receive keys (which is just one key for non-datagram TLS) and the newest send key. > Ilari, do you see a security flaw in having one side know which > keys the other side is using? Explicit information between the > two endpoints seems like a good idea to me. Or do you think this > change makes TLS more complex and harder to implement correctly? I don't think the application needs to know that. And TLS stacks know valid receive keys anyway. And thanks to fully asynchronous design, have fun if client requests 27GB Blu-Ray ISO over HTTP/1.1 and server decides to rekey... The security problems arise when one uses this as basis to reveal keys (which is not something TLS libraries should even support, just the existence of API breaks the security models in all sorts of nasty ways). -Ilari From gknowles92603@gmail.com Thu Mar 3 18:49:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667D1B29C0 for ; Thu, 3 Mar 2016 18:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Vohksax2oCIs for ; Thu, 3 Mar 2016 18:49:52 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD951A88EB for ; Thu, 3 Mar 2016 18:49:51 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id m184so49082265iof.1 for ; Thu, 03 Mar 2016 18:49:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=G+mpA5JLDozyevUjrfihfpRKDLz/0PhlBI0BHH0AMTw=; b=ZKM4DPxC/3Wjq24pOmGaZpRp+Ll3KKIOgRLAgL35rBfkaAqt1/ZFOl7UnkD07n2XV4 MyVmoZMx2zQ4alsF0+Ycut5XWjORfnWSzCUlK9l2RX9YFso+QL0FOM/CB48Y9sCQQWsA YaHHWQnee9NaR2ebzXatD8c08lrwgr5+o5f6+yERYutyM6x0ig4SRD4XbJ3E9OImCOD5 9ERlS/M8g2wi9jdEvV79UWWrtTI/Lcd8h3ECi3YHczaeDU4Myox7j909TF1JLhOrhK69 X/SMeU0921/f3bWhUgg8/7X/vb7HXnaLQ60PI1NxV7ZTUZB+62abmbS3R3cP1XFgGdk9 EWWA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=G+mpA5JLDozyevUjrfihfpRKDLz/0PhlBI0BHH0AMTw=; b=cechi5M8vJ361JEWILWWLgCVTj0cqJHbD3EN6cRrn8k/WPQt8MFRijJN2aB6dyBuzp x79Vs7FWoF7FVQev5VsnV6hYKVNIFFbu7K1qV0bHxP7kr/WkMmIhLDaFMz9zR0vnYG8f O+oSabEEfD8CNC2eBq4VukahdrLBO2nxbsamaOnDcno8iKxeXG63MgbyNR8Tql8wVlvJ Kjkoj49M7IfsITOrTqJIjnI9xsRVZ7XzikZ0xb7echzRN2ZA7Zdvir0m0RbK8TfR+DUP YRidtGwEGH4DEAuGlRxQN1rhO1u6I52U1Hfylt0ndA5e+xfBMaMPD12Gr9Ypk/NhBeuf dhBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=G+mpA5JLDozyevUjrfihfpRKDLz/0PhlBI0BHH0AMTw=; b=TN9JP1gfE3qNmYV5xLoPeEowp0iFTErfeBpVJpDE5JwwqCL6YPulxhVDyO6QMgYl6H K3aSNx+CsYZV2vXKABBoJ0y7aqMVdzi4CXEU2fu8A7A+hEBbgw/G/ERbSmo8aW14dQuh pv4MEd/MQT33/2R6ZmiCfYbAjS0ngfIONutCEbl8Z2yDVJdIBCiGzt6lnySCuYlBg7EG Em7qIJyTcDnOW4WehHw9FcaO1TidyN7meM2cG6XeTW2xMusJyJ4S9gNmCKVW7AUq/446 Rvqn/Tuedv0n9M7nf6eqwwmRIrqs3JZYXV99877J+CW5YkP0Q+xwkwf4i9PMhaIXQ8vE OJ8w== X-Gm-Message-State: AD7BkJJdoC+KgrdPFsbBtxGaK2aFgXLJRfNBJ7qTo77qBYl/6HMu2Ha86KXgOp4FskY36CFb0idiES2k2uY/4Q== MIME-Version: 1.0 X-Received: by 10.107.132.162 with SMTP id o34mr6026114ioi.154.1457059791345; Thu, 03 Mar 2016 18:49:51 -0800 (PST) Sender: gknowles92603@gmail.com Received: by 10.107.7.21 with HTTP; Thu, 3 Mar 2016 18:49:51 -0800 (PST) In-Reply-To: References: <20160302143313.6E6C1180004@rfc-editor.org> Date: Thu, 3 Mar 2016 18:49:51 -0800 X-Google-Sender-Auth: J9dDZnznLnZRSqQR63X-ns3hdG4 Message-ID: From: Glen Knowles To: Bodo Moeller Content-Type: multipart/alternative; boundary=001a113f33e847a05c052d302b64 Archived-At: Cc: sean+ietf@sn3rd.com, Chris Hawk , Kathleen Moriarty , Nelson B Bolyard , "tls@ietf.org" , Vipul Gupta , RFC Errata System Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (4633) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:24:24 -0000 --001a113f33e847a05c052d302b64 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 2, 2016 at 12:59 PM, Bodo Moeller wrote: > RFC Errata System : > >> struct { >> NamedCurve elliptic_curve_list<2..2^16-1> >> } EllipticCurveList; >> >> I agree with this finding. Each NamedCurve value takes exactly two > bytes, so the floor should have been specified as 2, not 1. > > To be pedantic wouldn't it be: NamedCurve elliptic_curve_list<2..2^16-2> --001a113f33e847a05c052d302b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 2, 2016 at 12:59 PM, Bodo Moeller <bmoeller@acm.org> = wrote:
RFC Errata System &l= t;rfc-editor= @rfc-editor.org>:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NamedCurve elliptic_curve_list<= ;2..2^16-1>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } EllipticCurveList;

I agree with this finding.=C2=A0 Each NamedCur= ve value takes exactly two bytes, so the floor should have been specified a= s 2, not 1.

To be pedantic wouldn= 't it be:
NamedCurve elliptic_curve_list<2..2^16-2>

--001a113f33e847a05c052d302b64-- From nobody Sun Mar 6 03:49:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278F61B2BBD for ; Sun, 6 Mar 2016 03:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtUW_q8abZLS for ; Sun, 6 Mar 2016 03:49:13 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 6413D1B2BBC for ; Sun, 6 Mar 2016 03:49:13 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 695BFA8A0169; Sun, 6 Mar 2016 11:49:10 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 1CAC91FE0237; Sun, 6 Mar 2016 12:49:09 +0100 (CET) Date: Sun, 6 Mar 2016 12:49:09 +0100 From: Kurt Roeckx To: Glen Knowles Message-ID: <20160306114909.GA395@roeckx.be> References: <20160302143313.6E6C1180004@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: sean+ietf@sn3rd.com, Chris Hawk , Kathleen Moriarty , Nelson B Bolyard , "tls@ietf.org" , Vipul Gupta , RFC Errata System Subject: Re: [TLS] [Editorial Errata Reported] RFC4492 (4633) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:49:15 -0000 On Thu, Mar 03, 2016 at 06:49:51PM -0800, Glen Knowles wrote: > On Wed, Mar 2, 2016 at 12:59 PM, Bodo Moeller wrote: > > > RFC Errata System : > > > >> struct { > >> NamedCurve elliptic_curve_list<2..2^16-1> > >> } EllipticCurveList; > >> > >> I agree with this finding. Each NamedCurve value takes exactly two > > bytes, so the floor should have been specified as 2, not 1. > > > > To be pedantic wouldn't it be: > NamedCurve elliptic_curve_list<2..2^16-2> It's a good point. Looking at various RFCs, 2..2^16-1 and 2..2^16-2 seem to be mixed all over. Kurt From nobody Mon Mar 7 03:42:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2481B3EA5 for ; Mon, 7 Mar 2016 03:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MANGLED_BACK=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9m-qwpNw5ny for ; Mon, 7 Mar 2016 03:42:49 -0800 (PST) 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 9D9DF1B3F63 for ; Mon, 7 Mar 2016 03:42:48 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id F2A2672097; Mon, 7 Mar 2016 11:42:47 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27Bgjw4015294 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 06:42:46 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 07 Mar 2016 12:42:39 +0100 Message-ID: <5209728.bPpGhxeIz8@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.3.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1715409.DF22txT6Jk"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 07 Mar 2016 11:42:48 +0000 (UTC) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:42:50 -0000 --nextPart1715409.DF22txT6Jk Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote: > > -----Original Message----- > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nikos > > Mavrogiannopoulos > > Sent: Friday, March 04, 2016 3:10 AM > > To: Hanno B=C3=B6ck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org > > Subject: Re: [TLS] RSA-PSS in TLS 1.3 > >=20 > > On Thu, 2016-03-03 at 17:11 +0100, Hanno B=C3=B6ck wrote: > >=20 > > > It may be worth asking the authors what's their opinion of FDH vs= > > >=20 > > > > PSS > > > > in view of the state of the art *today*. > > >=20 > > > You may do that, but I doubt that changes much. > > > > > > > > > > > > I think FDH really is not an option at all here. It may very well= > > > be > > > that there are better ways to do RSA-padding, but I don't think > > > that > > > this is viable for TLS 1.3 (and I don't think FDH is better). > > > PSS has an RFC (3447) and has been thoroughly analyzed by > > > research. I think there has been far less analyzing effort > > > towards FDH (or any other construction) and it is not in any way > > > specified in a standards document. If one would want to use FDH > > > or anything else one would imho first have to go through some > > > standardization process (which could be CFRG or NIST or someone > > > else) and call for a thorough analysis of it by the cryptographic= > > > community. Which would take at least a couple of years. > > > > > > > > > > > > Given that there probably is no long term future for RSA anyway > > > (people want ECC and postquantum is ahead) I doubt anything else > > > than the primitives we already have in standards will ever be > > > viable.>=20 > >=20 > > On the contrary. If we have a future with quantum computers > > available, the only thing that we have now and would work is RSA > > with larger keys, not ECC. >=20 > RSA isn't *that* much more secure against a Quantum Computer than ECC= . > It would appear to take a larger Quantum Computer to break RSA than > it would to break ECC (for reasonable moduli/curve sizes), however > not that much more. It is possible that, at one stage, we'll be able= > to build a QC that's just large enough to break EC curves, but not > larger RSA keys - however, we would be likely to be able to scale up > our QC to be a bit larger; possibly in a few months, quite likely in > a year or two. Hence, moving back to RSA would appear likely to buy > us only a short window... =20 > I agree with Hanno; if we're interested in defending against a Quantu= m > Computer, post Quantum algorithms are the way to go except that using RSA keys nearly an order of magnitude larger than the= =20 biggest ECC curve that's widely supported (secp384) is the current=20 recommended minimum by ENISA and long term minimum by NIST (3072). Using keys 5 times larger still is not impossible, so while it may not=20= buy us extra 20 years after ECC is broken, 10 years is not impossible=20= and 5 is almost certain (if Moore's law holds for quantum computers).=20= It's not much, but it may be enough to make a difference. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1715409.DF22txT6Jk 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 iQIcBAABCgAGBQJW3WkvAAoJEJKo0bgB0vX1IFgQAJj1H0iKAmCEIt+xxmcHc+Li jveu7b+hD+lOhSYKb01z9A8QGTNVqorOyke4EL9knjHJta4fMBoq4Cnz+RTZ9m0Z Ua2p52WCw0Nj6FuyjR0SGMH4648D+dtqadMO6m1dgc0H0E4y7axhFX+VkniJtO1g 6VSWGsAa5QXFs+BJnrRcGwYjvMdeEdVmwv6X6YQgplwztwiVAQaOeNfPRFfpqmPV bghQASB05X8gNYAFRJCQt0Rq3XiYw6d0liXxZ5dtqV/WbRLecnuNtuHMkKW7/rmP UGnQADpKOebNFz0QJBFOsPwQy132UQUXNq4tBfyA+hghCz/qOpaEir1E37b5z9UH WnULYznEDrlFo5Tfze+5b+skK59puPf0D8uZp5ABdohzZyqsgAjctPQOpzY2R+SO TUXdqMzk4BPcGN5WnlrHSF863HFRyp9ai/oQmnEfBcZZBkYlUILgmVLJcZbGJDF3 /UU0uLsbGvOzIbW6Lm6C/QGSbqbG+At+fwRaxq7K0YmZAjrB1MT5UvQTt9U33Cw5 lkuZIUsMYSlRyThZP2BSKdLmDQPkJKvE8KZ//smBi1VrTiHKNH+unZPErwFd05gY 6Z1WX8x0DAbJwhmRxDomn431spF9NRlJRW0W51/TXT4mKMNVEzl2xqJKyg9PgnDw nC3Wox/VCXeX3ABYopbJ =RL3t -----END PGP SIGNATURE----- --nextPart1715409.DF22txT6Jk-- From nobody Mon Mar 7 04:01:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A151B3F95 for ; Mon, 7 Mar 2016 04:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hecJkMZHb-qh for ; Mon, 7 Mar 2016 04:00:59 -0800 (PST) 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 15AF31B3F96 for ; Mon, 7 Mar 2016 04:00:57 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id C2371C00F5F7; Mon, 7 Mar 2016 12:00:56 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27C0tls030963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 07:00:56 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 07 Mar 2016 13:00:54 +0100 Message-ID: <2907995.2gNzvv7EmL@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.3.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <201603032043.43158.davemgarrett@gmail.com> References: <201603032043.43158.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4706039.pONXHUG23a"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: Adam Langley Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:01:01 -0000 --nextPart4706039.pONXHUG23a Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Thursday 03 March 2016 20:43:42 Dave Garrett wrote: > Do we want to stick some simple new constraints on SNI in the TLS 1.3= > draft spec? e.g. SHOULD have exactly one host_name which SHOULD be > less than N bytes (significantly less than the current theoretical > 64kB ceiling). Just adding a quick blurb for this in there somewhere > seems like the simplest solution to me. The standard says that it must be a valid domain name, and those are=20= IIRC limited to 255 characters. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart4706039.pONXHUG23a 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 iQIcBAABCgAGBQJW3W12AAoJEJKo0bgB0vX1ZN4P/0AJk0QW1PdyU9Ylr2CF4stC srkuxF6ByETY0VAmbNOTSITZ9SPrVcGnPteG1MzGLXJ0OEnTC+ccYCnsFUegYdGt MjKdeEfqTc81PsV+3atLFU50YbBGCFbUQMN5+UfJkto8T/zIR9VNnDRk61/29XnE wObKkrE5SjT8BbCcYmkhxljherkeMG42V26n6vXN9OdldiJJeWgm+pqoupmjzgPJ A2VPVJdOYAnmPscS6ktxtcXhwya6N5N56flW4OkLY+bz+nPbJvQnCqoTJXfU9NBv 4LpntNtdS/bsQ1uIlXKjO9fThJnlMiHhDQ1/Nk5M+0ps5FZBTrBbbTad5Z/KD9GV cI4vb2CwDb5Vu7Yr8Tdju4O9jPBBCJGIWCDRHuFuDQFlZA4ZdI6zi9z/+TN6+baP mrRPxFkVOmJk0mYbFW2mYWp6dTKBZdNEbbixAVhFVL9MTAEcgHfI6QfiZcfgOILb QVBzCI8WIVu2L+cugI5c/xybTShqB8izvZ4mZgyrt+kmhAcY9gXmoGfTwDjSs90W 4kTJCnAYlKLq7UcwgAGM0eR3ybgsS9i2T2LWqVQXyKtcQILU61m3fQUc12L9g6cf sE4pfwzCyB5FIvQt2hp8u99p1Q6uNG+2HXEmV1t1X97VaYXzAHhSqCGzDyNrBgt9 5ZZcaPoehx1dXQimJEos =WdaT -----END PGP SIGNATURE----- --nextPart4706039.pONXHUG23a-- From nobody Mon Mar 7 04:03:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7D01B3FAA for ; Mon, 7 Mar 2016 04:03:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qGE16ECNaRI for ; Mon, 7 Mar 2016 04:02:56 -0800 (PST) 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 952F11B3F79 for ; Mon, 7 Mar 2016 04:02:48 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 56C828C570; Mon, 7 Mar 2016 12:02:48 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27C2kjn013200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 07:02:48 -0500 From: Hubert Kario To: tls@ietf.org Date: Mon, 07 Mar 2016 13:02:45 +0100 Message-ID: <5191210.88NEgq11Kq@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.3.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1750235.ynxs3zveG6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: Adam Langley Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:03:02 -0000 --nextPart1750235.ynxs3zveG6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 04 March 2016 10:16:25 Martin Thomson wrote: > If we actually have a volunteer for sni-bis, then that would be OK > with me. >=20 > However, I don't regard the errors as important. Any hope that they > might be used in some automated fashion died a long time ago. Mainly= > due to this complete lack of consistency. I assume that the last > error indicates that you didn't get an alert, which I find is > alarmingly common in TLS. well, if some people don't care about their implementation being=20 fingerprintable, let them be, but there should but at least a=20 recommendation what to do if you want to avoid that. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1750235.ynxs3zveG6 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 iQIcBAABCgAGBQJW3W3lAAoJEJKo0bgB0vX1IooP/1BmsVtHKD0Wu99ariHP/U7V Y63s3xLrmEJOrOl7xihkxEdk6tpha9kPzn/z6H10aD9YTkGlGtZNTjUwA5GemWDM UrEFSVf9lYld2VjFDrgLAUPiPfKc+tAcf3dCRVWWBPAERCw894YvKpQrA7ouvqT7 LFwygWCVMsmdcJ44NOO1bJAQFsH82DiJMHgbrGv4uhAkfEHAGLFsjXT4EUo5dxuj 46ITxDdnJ3ChshIjeTmEJWipb+Nw3uSXjwsrHYzJeBDY7xMyIpBzIHM5Q4qSRgdY koXLW3ICVonoGAglqVvJJtc5ZUzlqIRgvVet9xxgrdkr0rdQE0AeXUgZS4ajLdTo Sv7skewMCM4+cW8IjVYMIgNFrn1FkhRZTlMrN+WO73p1uYLXEDRW3lBQu1awWZmA DeE+7wSutNbACunxZoMiPoq6TKuaeabaCwgZEKizd8A6R6nQ0zXT3r6XidtrCs21 vXzCcr/BiGXZwcHsrf5uIvi6sRB5SU7VxlKmwX3MnH+y/6oFa3rQpd/c30lxpPKP OEKUP0t7OXhoDTzY3cJixSOqxixNjayfeB9REypgS+C462a0+Ufdzq75LpedUVyA sqGswJ2s78qPR2G82X95rPOjVWiJP5oZ42PglSWlj4uqBv8DjPyCLyX4bmVRBMej W4gHrujrBssvDFF8rSeO =gOgK -----END PGP SIGNATURE----- --nextPart1750235.ynxs3zveG6-- From nobody Mon Mar 7 04:32:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8531B4043 for ; Mon, 7 Mar 2016 04:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X57yuji9rj7y for ; Mon, 7 Mar 2016 04:32:56 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 8A4DD1B4036 for ; Mon, 7 Mar 2016 04:32:56 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id g203so129146656iof.2 for ; Mon, 07 Mar 2016 04:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=uLIGmCSIVdWv3txb+5u/Ps+7wKHOraof+OCg0AhSL5o=; b=YE67mFpgGg9gdQQ72O0Qdi40SAoU8p6tuSmo2AkFy9KQE+1ylCYLiwpkcatEcIXhSP MkP1y7kG4yYcc41EKfyOLvFLNdiviHSrmCFLK4LEAYULGk9X2QXvnrjdD1QuodVr8rTQ /s8AcKjvpmN5pmB1ULNoD4aQFdrlO27Fpio//RwOVITn5vbOL5H69h2BUJqc9TS7Xeyw YiE/wt4yfcnoHDwnwQyrgHTnnWZuAGFkWsx/Qec3ZHT3ymbi4zJkpHTZokCTUe8k8pAR j1q2q5ZhGjmWF4Xv62D8ZB/HPi7OHwF/UC5dKXmdKpZJUm3AAofs7ztwsNI9Vf+sG9S0 rqOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uLIGmCSIVdWv3txb+5u/Ps+7wKHOraof+OCg0AhSL5o=; b=DGuclAkMmb0yLful6fR5oc0j5f4/FoCLfaPgRSDDA5pTPC0XvbmSi47O/IiCuXQBRe jXYqUQjc5x6ucD4i6bQ6Rv3JMSO7SFz1VojN47Kf319pU//gys5e8x+wsE+Jf/aVlRtO Aunv494odfaqOaMqwi2hO4wIq24RhvkPVuarnS9n5rupsq7HoRYZedPV64SZffPnO03c lfl3cfglLpnCMfm1BbMy55fdjLU+TB650QQ+svdej1lGpZrCUOVrHeI0KWHKQBgZZWen wTIpG3P2+PnJRiN8FNFqsTuXF4l7gAI5fU3IyB3oXzPIL9kfpB8ae9GS+FBo0n7uFSxs Dm3A== X-Gm-Message-State: AD7BkJLBOq8m6c40KtIQCOZeGlz1Db2ZwEV6dEv6wfHuPnSWnuah2AH5xeCF2dF1OQ8Y7pp3456rNQKQLOelKQ== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr21276556iop.100.1457353975900; Mon, 07 Mar 2016 04:32:55 -0800 (PST) Received: by 10.36.43.5 with HTTP; Mon, 7 Mar 2016 04:32:55 -0800 (PST) In-Reply-To: <5191210.88NEgq11Kq@pintsize.usersys.redhat.com> References: <5191210.88NEgq11Kq@pintsize.usersys.redhat.com> Date: Mon, 7 Mar 2016 23:32:55 +1100 Message-ID: From: Martin Thomson To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:32:58 -0000 On 7 March 2016 at 23:02, Hubert Kario wrote: > well, if some people don't care about their implementation being > fingerprintable, let them be, but there should but at least a > recommendation what to do if you want to avoid that. I'd be very surprised if this added anything to the fingerprinting entropy already present in TLS implementations. You can't use this sort of thing to distinguish one user of NSS from another NSS user. BTW, I'm pretty much not willing to volunteer to review the patch that made NSS less fingerprintable as NSS. I'm pretty sure that involves replacing NSS with OpenSSL. From nobody Mon Mar 7 04:41:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5CB91B4019 for ; Mon, 7 Mar 2016 04:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMe6floVlYek for ; Mon, 7 Mar 2016 04:41:46 -0800 (PST) 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 A3B211B4060 for ; Mon, 7 Mar 2016 04:41:46 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 684D01837; Mon, 7 Mar 2016 12:41:46 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27CfiBs006869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 07:41:46 -0500 From: Hubert Kario To: Martin Thomson Date: Mon, 07 Mar 2016 13:41:44 +0100 Message-ID: <3694409.ykmGAtXXCk@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.3.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <5191210.88NEgq11Kq@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart85731639.zeW0e6KOZY"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:41:47 -0000 --nextPart85731639.zeW0e6KOZY Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 07 March 2016 23:32:55 Martin Thomson wrote: > On 7 March 2016 at 23:02, Hubert Kario wrote: > > well, if some people don't care about their implementation being > > fingerprintable, let them be, but there should but at least a > > recommendation what to do if you want to avoid that. >=20 > I'd be very surprised if this added anything to the fingerprinting > entropy already present in TLS implementations. You can't use this > sort of thing to distinguish one user of NSS from another NSS user. correct, but that's not what I meant by fingerprinting > BTW, I'm pretty much not willing to volunteer to review the patch tha= t > made NSS less fingerprintable as NSS. I'm pretty sure that involves > replacing NSS with OpenSSL. the current fingerprinting depends on alert descriptions sent for=20 different invalid messages in most cases it's just a question of changing a decode_error to=20 illegal_parameter or similar simple changes =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 99/71, 612 45, Brno, Czech Republi= c --nextPart85731639.zeW0e6KOZY 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 iQIcBAABCgAGBQJW3XcIAAoJEJKo0bgB0vX1A5sP/Rwg2JlPPFMqEaGoi0QMFsgR O2JHf/EJiygiiwQekfzOoxMysBL8zEfMFKxFZYMjnKsyzB0lqTfODoFVMFbimEEs A30lT6LDoOkX/DRhHZhHN7usu/+wyF0bpadNyMGBIhd6mQhQx+Gfwy3/sZ+Ipz06 xa/0hZishX8EKXoIHibTP3FQ8iYgYJJhSOLnNzCho0P3SsCS8x7retwZAQQBNB71 wRNj+vBk61+/xMqcw66S5vy3CXnUJQwx44VZLpuh1+zNWY36lPZnuvjM/dT+SJiw qgOFgKLt9W4h7TsJX/eVIrRqEGp3n30alm+JII0KlZdwp9BqzTsKEZC3XKVne3C9 F89PZIWFv1tYmGvsHyaGb02Ps3Y5tQbyyhrt82pHwaLhepHbzMau59q+uILPCrZN K1CGVgjBljaLFOz1dIdkqIb1I5VFCobAeAn1go2y2Mcmp6nwwGNLvW4j0Sa6TCJu 1LBcyTIWdPckpBnPOD+V7dD4UK+r+WFMjztHedakh43StWnFF09iZeVVJTBPzg3e mbNqXGYMVO4QWETVmQXxs50H8kF84EOnw7EtWKAwj4Ga7zIyTiWao7fUecJSbZff QzbTQDe1MA4d8S9+HtTSFdEA28wAoRh7W9AJXWfgpwtrdj9ib+yF5rO9IVF5tWU4 oION0+beHy4I62/SAI1z =smWA -----END PGP SIGNATURE----- --nextPart85731639.zeW0e6KOZY-- From nobody Mon Mar 7 05:42:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C8C1B410A for ; Mon, 7 Mar 2016 05:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.602 X-Spam-Level: X-Spam-Status: No, score=-6.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CmEWMQqFy9js for ; Mon, 7 Mar 2016 05:42:19 -0800 (PST) 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 79E731B2F46 for ; Mon, 7 Mar 2016 05:42:19 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id CE7FB1E58; Mon, 7 Mar 2016 13:42:18 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.105]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27DgFda017501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Mar 2016 08:42:17 -0500 Message-ID: <1457358135.3117.43.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "Scott Fluhrer (sfluhrer)" , Hanno =?ISO-8859-1?Q?B=F6ck?= , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Date: Mon, 07 Mar 2016 14:42:15 +0100 In-Reply-To: <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:42:20 -0000 On Fri, 2016-03-04 at 13:49 +0000, Scott Fluhrer (sfluhrer) wrote: > Given that there probably is no long term future for RSA anyway > > > (people want ECC and postquantum is ahead) I doubt anything else > > > than > > > the primitives we already have in standards will ever be viable. > > On the contrary. If we have a future with quantum computers > > available, the > > only thing that we have now and would work is RSA with larger keys, > > not ECC. > RSA isn't *that* much more secure against a Quantum Computer than > ECC.  It would appear to take a larger Quantum Computer to break RSA > than it would to break ECC (for reasonable moduli/curve sizes), > however not that much more.  It is possible that, at one stage, we'll > be able to build a QC that's just large enough to break EC curves, > but not larger RSA keys - however, we would be likely to be able to > scale up our QC to be a bit larger; possibly in a few months, quite > likely in a year or two.  Hence, moving back to RSA would appear > likely to buy us only a short window... > > I agree with Hanno; if we're interested in defending against a > Quantum Computer, post Quantum algorithms are the way to go Assuming that we have such algorithms which are practical to manage and deploy we would first need to enhance existing protocols with them, including TLS and PKI. Then it is only the (simple) task of upgrading/replacing every single piece of infrastructure we have today from certificates to implementations with the new algorithms.  Unless you can use the quantum computer to complete the above transition overnight, the quickest way to defend against the presence of a quantum computer is by allowing larger RSA keys. regards, Nikos From nobody Mon Mar 7 05:51:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 677161B4153 for ; Mon, 7 Mar 2016 05:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBp1YPHUZHw4 for ; Mon, 7 Mar 2016 05:51:54 -0800 (PST) Received: from mail.mehnert.org (mail.mehnert.org [213.73.89.200]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04A4E1B4157 for ; Mon, 7 Mar 2016 05:51:52 -0800 (PST) Received: from [128.232.110.198] (c198.al.cl.cam.ac.uk [128.232.110.198]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "hannes@mehnert.org", Issuer "mehnert root CA" (not verified)) by mail.mehnert.org (Postfix) with ESMTPS id 587AE1FDA for ; Mon, 7 Mar 2016 14:51:50 +0100 (CET) To: tls@ietf.org References: From: Hannes Mehnert Message-ID: <56DD876D.2060001@mehnert.org> Date: Mon, 7 Mar 2016 13:51:41 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:51:57 -0000 On 01/03/2016 11:32, Yoav Nir wrote: >> On 1 Mar 2016, at 6:56 AM, Martin Thomson wrote: >> >> On 1 March 2016 at 04:32, Joseph Salowey wrote: >>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST >>> offer). Clients can advertise support for PKCS-1.5 for backwards >>> compatibility in the transition period. >> >>> From my perspective, this is fine. I would like to say that we won't >> ever support PKCS#1.5 for TLS 1.3, but I think that I would rather >> have users on 1.3 with PKCS#1.5 than have them stuck on 1.2. >> >> It seems like others are taking the position that we should say "MUST >> NOT use PKCS#1.5”. > > I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm, leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just as it was PKCS#1.5 in TLS 1.2. I strongly agree to Yoav's proposal! No need to have both RSA(-PKCS) and RSA-PSS numbers in SignatureAlgorithms. hannes From nobody Mon Mar 7 07:23:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CE21B42B1 for ; Mon, 7 Mar 2016 07:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.202 X-Spam-Level: X-Spam-Status: No, score=-12.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_BACK=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBtJ8s4MOzEz for ; Mon, 7 Mar 2016 07:23:19 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946C41B42AE for ; Mon, 7 Mar 2016 07:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6614; q=dns/txt; s=iport; t=1457364199; x=1458573799; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cEMjHpIv3BUYQ7cYfiWRFGGpzzOikjy8wyGU021x9Gc=; b=dwvmNfRua9BO+SM9jFg1KkGYvrw21wCfi9lUhlKxH8iDv8KrQP1C0tCB 6EIUmxWI+rYTMMEQXpE3Sr95IPs9iMBJLFOC4kis2RVjmP1mr8jVh2cn4 YBKG0fT9y7eLQuSd1OmUWM0vAwN3+kA6nwerjStB/38gTBN62JRjG4yIm I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AQAtnN1W/51dJa1dgzpSbQa6OgENg?= =?us-ascii?q?WkdhXICHIENOBQBAQEBAQEBZCeEQQEBAQQdBhEVKQIFDAQCAQgOAwQBAQECAiM?= =?us-ascii?q?DAgICMBQBCAgBAQQBDQUIDIgOsBCOXAEBAQEBAQEBAQEBAQEBAQEBAQEBARV7h?= =?us-ascii?q?RyEPYRQgmqBOgWXKgGIUYUUjwGOVAEeAQFCg2RqAYg+fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,551,1449532800"; d="scan'208";a="246653366" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 15:23:18 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u27FNI6D010039 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 15:23:18 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 09:23:17 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 09:23:17 -0600 From: "Scott Fluhrer (sfluhrer)" To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AACdU9uAAAV12dA= Date: Mon, 7 Mar 2016 15:23:17 +0000 Message-ID: <720dc8ee9c9a49209c1e76271d0dd403@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <5209728.bPpGhxeIz8@pintsize.usersys.redhat.com> In-Reply-To: <5209728.bPpGhxeIz8@pintsize.usersys.redhat.com> 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: [10.98.2.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:23:21 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEh1YmVydCBLYXJpbyBbbWFp bHRvOmhrYXJpb0ByZWRoYXQuY29tXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDY6 NDMgQU0NCj4gVG86IHRsc0BpZXRmLm9yZw0KPiBDYzogU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIp OyBOaWtvcyBNYXZyb2dpYW5ub3BvdWxvczsgSGFubm8gQsO2Y2s7DQo+IEJsdW1lbnRoYWwsIFVy aSAtIDA1NTMgLSBNSVRMTA0KPiBTdWJqZWN0OiBSZTogW1RMU10gUlNBLVBTUyBpbiBUTFMgMS4z DQo+IA0KPiBPbiBGcmlkYXkgMDQgTWFyY2ggMjAxNiAxMzo0OToxMSBTY290dCBGbHVocmVyIHdy b3RlOg0KPiA+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFRMUyBb bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmlrb3MNCj4gPiA+IE1h dnJvZ2lhbm5vcG91bG9zDQo+ID4gPiBTZW50OiBGcmlkYXksIE1hcmNoIDA0LCAyMDE2IDM6MTAg QU0NCj4gPiA+IFRvOiBIYW5ubyBCw7ZjazsgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExM OyB0bHNAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbVExTXSBSU0EtUFNTIGluIFRMUyAx LjMNCj4gPiA+DQo+ID4gPiBPbiBUaHUsIDIwMTYtMDMtMDMgYXQgMTc6MTEgKzAxMDAsIEhhbm5v IELDtmNrIHdyb3RlOg0KPiA+ID4NCj4gPiA+ID4gSXQgbWF5IGJlIHdvcnRoIGFza2luZyB0aGUg YXV0aG9ycyB3aGF0J3MgdGhlaXIgb3BpbmlvbiBvZiBGREggdnMNCj4gPiA+ID4NCj4gPiA+ID4g PiBQU1MNCj4gPiA+ID4gPiBpbiB2aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUgYXJ0ICp0b2RheSou DQo+ID4gPiA+DQo+ID4gPiA+IFlvdSBtYXkgZG8gdGhhdCwgYnV0IEkgZG91YnQgdGhhdCBjaGFu Z2VzIG11Y2guDQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+DQo+ID4gPiA+IEkgdGhpbmsgRkRI IHJlYWxseSBpcyBub3QgYW4gb3B0aW9uIGF0IGFsbCBoZXJlLiBJdCBtYXkgdmVyeSB3ZWxsDQo+ ID4gPiA+IGJlIHRoYXQgdGhlcmUgYXJlIGJldHRlciB3YXlzIHRvIGRvIFJTQS1wYWRkaW5nLCBi dXQgSSBkb24ndCB0aGluaw0KPiA+ID4gPiB0aGF0IHRoaXMgaXMgdmlhYmxlIGZvciBUTFMgMS4z IChhbmQgSSBkb24ndCB0aGluayBGREggaXMgYmV0dGVyKS4NCj4gPiA+ID4gUFNTIGhhcyBhbiBS RkMgKDM0NDcpIGFuZCBoYXMgYmVlbiB0aG9yb3VnaGx5IGFuYWx5emVkIGJ5DQo+ID4gPiA+IHJl c2VhcmNoLiBJDQo+ICB0aGluayB0aGVyZSBoYXMgYmVlbiBmYXIgbGVzcyBhbmFseXppbmcgZWZm b3J0DQo+ID4gPiA+IHRvd2FyZHMgRkRIIChvciBhbnkgb3RoZXIgY29uc3RydWN0aW9uKSBhbmQg aXQgaXMgbm90IGluIGFueSB3YXkNCj4gPiA+ID4gc3BlY2lmaWVkIGluIGEgc3RhbmRhcmRzIGRv Y3VtZW50LiBJZiBvbmUgd291bGQgd2FudCB0byB1c2UgRkRIIG9yDQo+ID4gPiA+IGFueXRoaW5n IGVsc2Ugb25lIHdvdWxkIGltaG8gZmlyc3QgaGF2ZSB0byBnbyB0aHJvdWdoIHNvbWUNCj4gPiA+ ID4gc3RhbmRhcmRpemF0aW9uIHByb2Nlc3MgKHdoaWNoIGNvdWxkIGJlIENGUkcgb3IgTklTVCBv ciBzb21lb25lDQo+ID4gPiA+IGVsc2UpIGFuZCBjYWxsIGZvciBhIHRob3JvdWdoIGFuYWx5c2lz IG9mIGl0IGJ5IHRoZSBjcnlwdG9ncmFwaGljDQo+ID4gPiA+IGNvbW11bml0eS4gV2hpY2ggd291 bGQgdGFrZSBhdCBsZWFzdCBhIGNvdXBsZSBvZiB5ZWFycy4NCj4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4NCj4gPiA+ID4gR2l2ZW4gdGhhdCB0aGVyZSBwcm9iYWJseSBpcyBubyBsb25nIHRlcm0g ZnV0dXJlIGZvciBSU0EgYW55d2F5DQo+ID4gPiA+IChwZW9wbGUgd2FudCBFQ0MgYW5kIHBvc3Rx dWFudHVtIGlzIGFoZWFkKSBJIGRvdWJ0IGFueXRoaW5nIGVsc2UNCj4gPiA+ID4gdGhhbiB0aGUg cHJpbWl0aXZlcyB3ZSBhbHJlYWR5IGhhdmUgaW4gc3RhbmRhcmRzIHdpbGwgZXZlciBiZQ0KPiA+ ID4gPiB2aWFibGUuPg0KPiA+ID4NCj4gPiA+IE9uIHRoZSBjb250cmFyeS4gSWYgd2UgaGF2ZSBh IGZ1dHVyZSB3aXRoIHF1YW50dW0gY29tcHV0ZXJzDQo+ID4gPiBhdmFpbGFibGUsIHRoZSBvbmx5 IHRoaW5nIHRoYXQgd2UgaGF2ZSBub3cgYW5kIHdvdWxkIHdvcmsgaXMgUlNBDQo+ID4gPiB3aXRo IGxhcmdlciBrZXlzLCBub3QgRUNDLg0KPiA+DQo+ID4gUlNBIGlzbid0ICp0aGF0KiBtdWNoIG1v cmUgc2VjdXJlIGFnYWluc3QgYSBRdWFudHVtIENvbXB1dGVyIHRoYW4gRUNDLg0KPiA+ICBJdCB3 b3VsZCBhcHBlYXIgdG8gdGFrZSBhIGxhcmdlciBRdWFudHVtIENvbXB1dGVyIHRvIGJyZWFrIFJT QSB0aGFuDQo+ID4gaXQgd291bGQgdG8gYnJlYWsgRUNDIChmb3IgcmVhc29uYWJsZSBtb2R1bGkv Y3VydmUgc2l6ZXMpLCBob3dldmVyIG5vdA0KPiA+IHRoYXQgbXVjaCBtb3JlLiAgSXQgaXMgcG9z c2libGUgdGhhdCwgYXQgb25lIHN0YWdlLCB3ZSdsbCBiZSBhYmxlIHRvDQo+ID4gYnVpbGQgYSBR QyB0aGF0J3MganVzdCBsYXJnZSBlbm91Z2ggdG8gYnJlYWsgRUMgY3VydmVzLCBidXQgbm90IGxh cmdlcg0KPiA+IFJTQSBrZXlzIC0gaG93ZXZlciwgd2Ugd291bGQgYmUgbGlrZWx5IHRvIGJlIGFi bGUgdG8gc2NhbGUgdXAgb3VyIFFDDQo+ID4gdG8gYmUgYSBiaXQgbGFyZ2VyOyBwb3NzaWJseSBp biBhIGZldyBtb250aHMsIHF1aXRlIGxpa2VseSBpbiBhIHllYXINCj4gPiBvciB0d28uICBIZW5j ZSwgbW92aW5nIGJhY2sgdG8gUlNBIHdvdWxkIGFwcGVhciBsaWtlbHkgdG8gYnV5IHVzIG9ubHkN Cj4gPiBhIHNob3J0IHdpbmRvdy4uLg0KPiANCj4gPiBJIGFncmVlIHdpdGggSGFubm87IGlmIHdl J3JlIGludGVyZXN0ZWQgaW4gZGVmZW5kaW5nIGFnYWluc3QgYSBRdWFudHVtDQo+ID4gQ29tcHV0 ZXIsIHBvc3QgUXVhbnR1bSBhbGdvcml0aG1zIGFyZSB0aGUgd2F5IHRvIGdvDQo+IA0KPiBleGNl cHQgdGhhdCB1c2luZyBSU0Ega2V5cyBuZWFybHkgYW4gb3JkZXIgb2YgbWFnbml0dWRlIGxhcmdl ciB0aGFuIHRoZQ0KPiBiaWdnZXN0IEVDQyBjdXJ2ZSB0aGF0J3Mgd2lkZWx5IHN1cHBvcnRlZCAo c2VjcDM4NCkgaXMgdGhlIGN1cnJlbnQNCj4gcmVjb21tZW5kZWQgbWluaW11bSBieSBFTklTQSBh bmQgbG9uZyB0ZXJtIG1pbmltdW0gYnkgTklTVCAoMzA3MikuDQo+IA0KPiBVc2luZyBrZXlzIDUg dGltZXMgbGFyZ2VyIHN0aWxsIGlzIG5vdCBpbXBvc3NpYmxlLCBzbyB3aGlsZSBpdCBtYXkgbm90 IGJ1eSB1cw0KPiBleHRyYSAyMCB5ZWFycyBhZnRlciBFQ0MgaXMgYnJva2VuLCAxMCB5ZWFycyBp cyBub3QgaW1wb3NzaWJsZSBhbmQgNSBpcyBhbG1vc3QNCj4gY2VydGFpbiAoaWYgTW9vcmUncyBs YXcgaG9sZHMgZm9yIHF1YW50dW0gY29tcHV0ZXJzKS4NCj4gSXQncyBub3QgbXVjaCwgYnV0IGl0 IG1heSBiZSBlbm91Z2ggdG8gbWFrZSBhIGRpZmZlcmVuY2UuDQoNCklmIHdlIGJlbGlldmUgdGhh dCBncm93dGggaW4gTW9vcmUncyBsYXcgd2lsbCBiZSBhY2N1cmF0ZSBmb3IgUXVhbnR1bSBDb21w dXRlcnMsIHRoZW4gbm8gb25lIGhhcyB0byB3b3JyeSBhYm91dCBRdWFudHVtIENvbXB1dGVycyBm b3IgdGhlIG5leHQgbWlsbGVubmlhLg0KDQpJbiAyMDAxLCBhIFF1YW50dW0gQ29tcHV0ZXIgZmFj dG9yZWQgYSA0IGJpdCBudW1iZXIuICBJbiAyMDE0LCB0aGUgZmFjdG9yaXphdGlvbiBvZiBhIDE2 IGJpdCBudW1iZXIgd2FzIGFubm91bmNlZCAoaG93ZXZlciwgdGhlIGZhY3Rvcml6YXRpb24gdXNl ZCBhIHNwZWNpYWwgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIGZhY3RvcnMsIHNvIEkgZG9u4oCZ dCB0aGluayBpdCBjb3VudHMgYXMgYSBnZW5lcmFsIGZhY3Rvcml6YXRpb24sIGJ1dCBsZXQncyBp Z25vcmUgdGhhdCBmb3Igbm93KS4gIFRoYXQncyBub3QgdG9vIGZhciBvZmYgZnJvbSBhIE1vb3Jl J3MgbGF3IHR5cGUgZXhwYW5zaW9uLiAgSWYgdGhpcyByYXRlIGNvbnRpbnVlcywgd2VsbCBzZWUg dGhlIGZpcnN0IDEwMjQgYml0IGZhY3Rvcml6YXRpb24gY2lyY2EgdGhlIHllYXIgMzEwMCBBRCAo YWthIENFKS4NCg0KSG93ZXZlciwgcmlnaHQgbm93IG9uZSBvZiB0aGUgY2hpZWYgcHJvYmxlbXMg aW4gYnVpbGRpbmcgYSBRdWFudHVtIENvbXB1dGVyIGlzIGVycm9yIGNvcnJlY3Rpb247IGNhdGNo aW5nIHdoZW4gZGVjb2hlcmVuY2UgaGFzIG9jY3VycmVkLCBhbmQgZml4aW5nIGl0IGJlZm9yZSBp dCBzcG9pbHMgdGhlIGVudGlyZSBvcGVyYXRpb24uICBPbmNlIHRoZXkgaGF2ZSB0aGF0IHNvbHZl ZCwgcHJhY3RpY2FsIFF1YW50dW0gQ29tcHV0ZXJzIG1heSBnZXQgbXVjaCBiaWdnZXIgdmVyeSBm YXN0Lg0KDQpNaWdodCB0aGV5LCBhZnRlciB0aGUgaW5pdGlhbCBleHBsb3NpdmUgZ3Jvd3RoICh0 byAxMDAwIHFiaXRzIG9yIDEsMDAwLDAwMCBxYml0cywgSSBkb24ndCB0aGluayBhbnlvbmUga25v d3Mgd2hlcmUgdGhhdCBwb2ludCB3b3VsZCBiZSksIG1pZ2h0IGl0IGNvbnRpbnVlIHRvIGdyb3cg aW4gYSBNb29yZSdzIGxhdyBmYXNoaW9uPyAgSXQgbWlnaHQ7IGhvd2V2ZXIgd2UncmUgbm90IHN1 cmUuICBVc2luZyBSU0Ega2V5cyB3aGljaCBhcmUgNSB0aW1lcyBsYXJnZXIgbWlnaHQgbm90IGJ1 eSB1cyBhbnkgdGltZSBhdCBhbGwuLi4NCg0KPiANCj4gLS0NCj4gUmVnYXJkcywNCj4gSHViZXJ0 IEthcmlvDQo+IFNlbmlvciBRdWFsaXR5IEVuZ2luZWVyLCBRRSBCYXNlT1MgU2VjdXJpdHkgdGVh bQ0KPiBXZWI6IHd3dy5jei5yZWRoYXQuY29tDQo+IFJlZCBIYXQgQ3plY2ggcy5yLm8uLCBQdXJr ecWIb3ZhIDk5LzcxLCA2MTIgNDUsIEJybm8sIEN6ZWNoIFJlcHVibGljDQo= From nobody Mon Mar 7 08:04:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E70F1B4375 for ; Mon, 7 Mar 2016 08:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EC4KecaYjEsm for ; Mon, 7 Mar 2016 08:04:34 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5928B1B4373 for ; Mon, 7 Mar 2016 08:04:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 46E4D488F; Mon, 7 Mar 2016 18:04:31 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id u5uOovNcoYlB; Mon, 7 Mar 2016 18:04:29 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E27D32310; Mon, 7 Mar 2016 18:04:29 +0200 (EET) Date: Mon, 7 Mar 2016 18:04:23 +0200 From: Ilari Liusvaara To: Hannes Mehnert Message-ID: <20160307160423.GA15882@LK-Perkele-V2.elisa-laajakaista.fi> References: <56DD876D.2060001@mehnert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <56DD876D.2060001@mehnert.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:04:36 -0000 On Mon, Mar 07, 2016 at 01:51:41PM +0000, Hannes Mehnert wrote: > On 01/03/2016 11:32, Yoav Nir wrote: > >> On 1 Mar 2016, at 6:56 AM, Martin Thomson wrote: > >> > >> On 1 March 2016 at 04:32, Joseph Salowey wrote: > >>> We make RSA-PSS mandatory to implement (MUST implement instead of MUST > >>> offer). Clients can advertise support for PKCS-1.5 for backwards > >>> compatibility in the transition period. > >> > >>> From my perspective, this is fine. I would like to say that we won't > >> ever support PKCS#1.5 for TLS 1.3, but I think that I would rather > >> have users on 1.3 with PKCS#1.5 than have them stuck on 1.2. > >> > >> It seems like others are taking the position that we should say "MUST > >> NOT use PKCS#1.5”. > > > > I’d go even further. I’d remove the rsapss(4) value from SignatureAlgorithm, > > leaving just rsa(1), and say that in TLS 1.3 an RSA signature is PSS just > > as it was PKCS#1.5 in TLS 1.2. > > I strongly agree to Yoav's proposal! No need to have both RSA(-PKCS) > and RSA-PSS numbers in SignatureAlgorithms. Doesn't SignatureAlgorithms also negotiate the algorithms supported for the cert chain? If it does, I think that complicates things. Also, making the same ClientHello mean two different things depending on yet-unnegotiated version seems odd to me. -Ilari From nobody Mon Mar 7 08:34:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F571B4432 for ; Mon, 7 Mar 2016 08:34:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.902 X-Spam-Level: X-Spam-Status: No, score=-11.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64zJZBcR850B for ; Mon, 7 Mar 2016 08:34:30 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E7FE1B4423 for ; Mon, 7 Mar 2016 08:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5526; q=dns/txt; s=iport; t=1457368467; x=1458578067; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=RH0SNi7VVFtP3EwDpN1/2guMDeakdtB2aAGOhdbn/BY=; b=iVeUCzqBLfLByVowncZaxojESzrASGKYAErtpkQ1JfHzzUpBjXd0OteD dKghmPQND5xNAmL5akrzCdvYeQeZaVnDcfwrFATQ71gnrGA8JBheDKCoo MXxJCSfTixj0m5lmD0KaBIiPkYh0Jn4k7Amz4fLdiReqWbIoSP1oVJwrB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqAgAArd1W/51dJa1cDoMsgT8GujoBD?= =?us-ascii?q?YFphg8CHIENOBQBAQEBAQEBZCeEQQEBAQMBIxFAEQQCAQgRBAEBAQICIwMCAgI?= =?us-ascii?q?wFAEICAEBBAESCIgUCLAHjn8BAQEBAQEBAQEBAQEBAQEBAQEBF3uFHIQ9hCIJg?= =?us-ascii?q?w+BOgWXKgGNZYFqjReFeYhbAR4BAUKCAhqBDTtqiAQ7fgEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,552,1449532800"; d="scan'208";a="245701693" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2016 16:34:26 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u27GYQrw020923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 16:34:26 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 10:34:25 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 10:34:25 -0600 From: "Scott Fluhrer (sfluhrer)" To: Nikos Mavrogiannopoulos , =?utf-8?B?SGFubm8gQsO2Y2s=?= , "Blumenthal, Uri - 0553 - MITLL" , "tls@ietf.org" Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AAChgSqAAAfIBWA= Date: Mon, 7 Mar 2016 16:34:25 +0000 Message-ID: <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> In-Reply-To: <1457358135.3117.43.camel@redhat.com> 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: [10.98.2.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:34:32 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IE5pa29zIE1hdnJvZ2lhbm5v cG91bG9zIFttYWlsdG86bm1hdkByZWRoYXQuY29tXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA3 LCAyMDE2IDg6NDIgQU0NCj4gVG86IFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKTsgSGFubm8gQsO2 Y2s7IEJsdW1lbnRoYWwsIFVyaSAtIDA1NTMgLSBNSVRMTDsNCj4gdGxzQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbVExTXSBSU0EtUFNTIGluIFRMUyAxLjMNCj4gDQo+IE9uIEZyaSwgMjAxNi0w My0wNCBhdCAxMzo0OSArMDAwMCwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpIHdyb3RlOg0KPiA+ IEdpdmVuIHRoYXQgdGhlcmUgcHJvYmFibHkgaXMgbm8gbG9uZyB0ZXJtIGZ1dHVyZSBmb3IgUlNB IGFueXdheQ0KPiA+ID4gPiAocGVvcGxlIHdhbnQgRUNDIGFuZCBwb3N0cXVhbnR1bSBpcyBhaGVh ZCkgSSBkb3VidCBhbnl0aGluZyBlbHNlDQo+ID4gPiA+IHRoYW4gdGhlIHByaW1pdGl2ZXMgd2Ug YWxyZWFkeSBoYXZlIGluIHN0YW5kYXJkcyB3aWxsIGV2ZXIgYmUNCj4gPiA+ID4gdmlhYmxlLg0K PiA+ID4gT24gdGhlIGNvbnRyYXJ5LiBJZiB3ZSBoYXZlIGEgZnV0dXJlIHdpdGggcXVhbnR1bSBj b21wdXRlcnMNCj4gPiA+IGF2YWlsYWJsZSwgdGhlIG9ubHkgdGhpbmcgdGhhdCB3ZSBoYXZlIG5v dyBhbmQgd291bGQgd29yayBpcyBSU0ENCj4gPiA+IHdpdGggbGFyZ2VyIGtleXMsIG5vdCBFQ0Mu DQo+ID4gUlNBIGlzbid0ICp0aGF0KiBtdWNoIG1vcmUgc2VjdXJlIGFnYWluc3QgYSBRdWFudHVt IENvbXB1dGVyIHRoYW4NCj4gRUNDLg0KPiA+IEl0IHdvdWxkIGFwcGVhciB0byB0YWtlIGEgbGFy Z2VyIFF1YW50dW0gQ29tcHV0ZXIgdG8gYnJlYWsgUlNBIHRoYW4gaXQNCj4gPiB3b3VsZCB0byBi cmVhayBFQ0MgKGZvciByZWFzb25hYmxlIG1vZHVsaS9jdXJ2ZSBzaXplcyksIGhvd2V2ZXIgbm90 DQo+ID4gdGhhdCBtdWNoIG1vcmUuwqDCoEl0IGlzIHBvc3NpYmxlIHRoYXQsIGF0IG9uZSBzdGFn ZSwgd2UnbGwgYmUgYWJsZSB0bw0KPiA+IGJ1aWxkIGEgUUMgdGhhdCdzIGp1c3QgbGFyZ2UgZW5v dWdoIHRvIGJyZWFrIEVDIGN1cnZlcywgYnV0IG5vdCBsYXJnZXINCj4gPiBSU0Ega2V5cyAtIGhv d2V2ZXIsIHdlIHdvdWxkIGJlIGxpa2VseSB0byBiZSBhYmxlIHRvIHNjYWxlIHVwIG91ciBRQw0K PiA+IHRvIGJlIGEgYml0IGxhcmdlcjsgcG9zc2libHkgaW4gYSBmZXcgbW9udGhzLCBxdWl0ZSBs aWtlbHkgaW4gYSB5ZWFyDQo+ID4gb3IgdHdvLsKgwqBIZW5jZSwgbW92aW5nIGJhY2sgdG8gUlNB IHdvdWxkIGFwcGVhciBsaWtlbHkgdG8gYnV5IHVzIG9ubHkNCj4gPiBhIHNob3J0IHdpbmRvdy4u Lg0KPiA+DQo+ID4gSSBhZ3JlZSB3aXRoIEhhbm5vOyBpZiB3ZSdyZSBpbnRlcmVzdGVkIGluIGRl ZmVuZGluZyBhZ2FpbnN0IGEgUXVhbnR1bQ0KPiA+IENvbXB1dGVyLCBwb3N0IFF1YW50dW0gYWxn b3JpdGhtcyBhcmUgdGhlIHdheSB0byBnbw0KPiANCj4gQXNzdW1pbmcgdGhhdCB3ZSBoYXZlIHN1 Y2ggYWxnb3JpdGhtcyB3aGljaCBhcmUgcHJhY3RpY2FsIHRvIG1hbmFnZSBhbmQNCj4gZGVwbG95 IHdlIHdvdWxkIGZpcnN0IG5lZWQgdG8gZW5oYW5jZSBleGlzdGluZyBwcm90b2NvbHMgd2l0aCB0 aGVtLA0KPiBpbmNsdWRpbmcgVExTIGFuZCBQS0kuIFRoZW4gaXQgaXMgb25seSB0aGUgKHNpbXBs ZSkgdGFzayBvZiB1cGdyYWRpbmcvcmVwbGFjaW5nDQo+IGV2ZXJ5IHNpbmdsZSBwaWVjZSBvZiBp bmZyYXN0cnVjdHVyZSB3ZSBoYXZlIHRvZGF5IGZyb20gY2VydGlmaWNhdGVzIHRvDQo+IGltcGxl bWVudGF0aW9ucyB3aXRoIHRoZSBuZXcgYWxnb3JpdGhtcy4NCg0KVGhlcmUgYXJlIHR3byB0aHJl YXRzIHRoYXQgYSBRdWFudHVtIENvbXB1dGVyIG1heSBicmluZzoNCg0KLSBTb21lb25lICh3aG8g bWlnaHQgbm90IGhhdmUgYSBRQyBub3cpIHJlY29yZGluZyB0aGUgZW5jcnlwdGluZyB0cmFmZmlj LCBhbmQgdGhlbiAod2hlbiB0aGV5IGRvIGhhdmUgYSBRQykgZGVjcnlwdGluZyB0aGUgdHJhZmZp Yw0KLSBTb21lb25lIHdpdGggYSBRQyBmb3JnaW5nIG91ciBhdXRoZW50aWNhdGlvbiAoY2VydGlm aWNhdGVzKSxhbmQgYWN0aW5nIGVpdGhlciBhcyBhbiBpbXBvc3Rlciwgb3IgYXMgYSBtYW4taW4t dGhlLW1pZGRsZS4NCg0KVGhlIHNlY29uZCBhdHRhY2sgaXNuJ3QgZmVhc2libGUgdW50aWwgc29t ZW9uZSBhY3R1YWxseSBoYXMgYSBRQyBhdCB0aGUgdGltZSBvZiB0aGUgYXR0YWNrOyBmb3IgdGhl IGZpcnN0IGF0dGFjaywgdGhhdCdzIGEgdGhyZWF0IHVudGlsIHRoZSBkYXRhIGJlaW5nIHByb3Rl Y3RlZCBpcyBubyBsb25nZXIgb2YgYW55IGludGVyZXN0IC0gZGVwZW5kaW5nIG9uIHdoYXQgdGhh dCBkYXRhIGlzLCB0aGF0IG1heSBiZSBkZWNhZGVzLg0KDQpUbyBkZWZlbmQgYWdhaW5zdCB0aGUg Zmlyc3QgYXR0YWNrLCB3ZSBkb24ndCBuZWVkIHRvIHVwZGF0ZSB0aGUgZW50aXJlIGluZnJhc3Ry dWN0dXJlLiAgSW5zdGVhZCwgYWxsIHdlIG5lZWQgdG8gZG8gaXMgdXBkYXRlIHRoZSBjbGllbnQg YW5kIHRoZSBzZXJ2ZXIgdG8gdXNlIGEgUXVhbnR1bS1SZXNpc3RhbnQgY2lwaGVyc3VpdGUgKEkn ZCBhcmd1ZSB0aGF0IGEgUVIgbmFtZWQgZ3JvdXAgd291bGQgYWN0dWFsbHkgYmUgcHJlZmVyYWJs ZSwgaG93ZXZlciB0aGF0J3MgYW4gYXJndW1lbnQgZm9yIGFub3RoZXIgdGltZSkuICBXZSBrbm93 IGhvdyB0byBkbyBhIGdyYWR1YWwgcm9sbG91dCBvZiB0aGlzLg0KDQpUbyBkZWZlbmQgYWdhaW5z dCB0aGUgc2Vjb25kIGF0dGFjaywgeWVzLCB0aGF0IHdvdWxkIHJlcXVpcmUgY2hhbmdlcyB0byBQ S0ksIHdoaWNoIHRoaXMgV0cgaXNuJ3QgaW4gY2hhcmdlIG9mLiAgSG93ZXZlciwgdGhlc2UgYXR0 YWNrcyBiZWNvbWUgYSB0aHJlYXQgbGF0ZXIuDQoNCg0KU28sIHRoZSBwb2ludHMgSSB3YW50IHRv IG1ha2UgYXJlOg0KDQotIERlZmVuc2VzIGFnYWluc3QgdGhlIGZpcnN0IHR5cGUgb2YgYXR0YWNr IChwYXNzaXZlIGV2ZXNkcm9wcGluZyBieSBzb21lb25lIHdobyB3aWxsIGJ1aWxkIGEgUUMgc29t ZXRpbWUgaW4gdGhlIGZ1dHVyZSkgYXJlIHNvbWV0aGluZyB0aGF0IHRoaXMgV0cgc2hvdWxkIGFk ZHJlc3M7IGV2ZW4gaWYgdGhlIFBLSSBwZW9wbGUgZG9uJ3QgaGF2ZSBhbiBhbnN3ZXIsIHdlIHdv dWxkIGF0IGxlYXN0IGJlIHNlY3VyZSBmcm9tIHNvbWVvbmUgcmVjb3JkaW5nIHRoZSB0cmFmZmlj IGFuZCBkZWNyeXB0aW5nIGl0IGxhdGVyDQotIExhcmdlIHNpemUgUlNBIGtleXMgKGFjdHVhbGx5 LCBESCBncm91cHM7IFRMUyAxLjMgZG9lc24ndCB1c2UgUlNBIGZvciBrZXkgdHJhbnNwb3J0KSBk b24ndCBuZWNlc3NhcmlseSBhZGQgYW55IHByb3RlY3Rpb24gZnJvbSBhIFFDIChkZXBlbmRpbmcg b24gaG93IGZhc3QgcHJhY3RpY2FsIFFDJ3MgcmFtcCB1cCkuDQoNCj4gDQo+IFVubGVzcyB5b3Ug Y2FuIHVzZSB0aGUgcXVhbnR1bSBjb21wdXRlciB0byBjb21wbGV0ZSB0aGUgYWJvdmUgdHJhbnNp dGlvbg0KPiBvdmVybmlnaHQsIHRoZSBxdWlja2VzdCB3YXkgdG8gZGVmZW5kIGFnYWluc3QgdGhl IHByZXNlbmNlIG9mIGEgcXVhbnR1bQ0KPiBjb21wdXRlciBpcyBieSBhbGxvd2luZyBsYXJnZXIg UlNBIGtleXMuDQoNCkFjdHVhbGx5LCB0aGF0IGJyaW5ncyB1cCBhIHBvaW50OyBpZiB3ZSBhcmUg d29ycmllZCBhYm91dCBzb21lIG9sZCwgdW51cGRhdGFibGUgc2VydmVycywgaG93IGFyZSB3ZSBn b2luZyB0byBldmVyIHVwZ3JhZGUgb3VyIGF1dGhlbnRpY2F0aW9uIGluZnJhc3RydWN0dXJlPyAg QSBsb3Qgb2YgdGhvc2UgYXJlIGJ1aWx0IG9uIGNyeXB0b2xpYnJhcmllcyB0aGF0IGNhbm5vdCBo YW5kbGUgMTZLIFJTQSBrZXlzIGFueSBtb3JlIHRoYW4gdGhleSBjYW4gaGFuZGxlIEhhc2ggQmFz ZWQgb3IgQkxJU1MgY2VydGlmaWNhdGVzLiAgSG93ZXZlciwgdGhhdCdzIGFuIGFyZ3VtZW50IGZv ciBhbm90aGVyIHRpbWUgKGFuZCBwcm9iYWJseSBub3QgYnkgdGhpcyBXRykNCg== From nobody Mon Mar 7 09:21:49 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B77E71CD60B for ; Mon, 7 Mar 2016 09:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.621 X-Spam-Level: X-Spam-Status: No, score=-12.621 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly3LLxtGqR4C for ; Mon, 7 Mar 2016 09:21:47 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 40F671CD609 for ; Mon, 7 Mar 2016 09:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11244; q=dns/txt; s=iport; t=1457371307; x=1458580907; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=p+szWQKYKJQZvT+9nUoUcMrweeI4M5CmLdeAPxlddFY=; b=Tb/z18+imsJPgJkvW+ilCMxkNyVmopZkxanfYOpZaqCqahwmHFeyQirU fuXCPmVxNkTHq0PMigaNClCZJFJMfbRCGSMdvVIW5BxJOwBYJuhy8mwYO 5Bxo632yUK/vCvXduhlRV+EJ6Jz3I4Up+v3fbtJoMl5M5c54LRnd0q7E4 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ArAgBXuN1W/40NJK1cgm5MUm0GujoBD?= =?us-ascii?q?YFphg8CHIEOOBQBAQEBAQEBZCeEQQEBAQQjCkwQAgEIDgMEAQEoAwICAh8RFAk?= =?us-ascii?q?IAgQOBQiIBwMSr3GKMw2EQgEBAQEBAQEBAQEBAQEBAQEBAQEBARWGF4Q9gj2CE?= =?us-ascii?q?yCCSoE6BYg3jnMBi3eBbo8BhwyHSAEeAQFCg2RqiD9+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,552,1449532800"; d="scan'208,217";a="246699308" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2016 17:21:45 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u27HLjjf031766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 17:21:45 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 11:21:38 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 11:21:32 -0600 From: "Scott Fluhrer (sfluhrer)" To: Tony Arcieri Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AAChgSqAAAfIBWD///NnAIAAWx/g Date: Mon, 7 Mar 2016 17:21:32 +0000 Message-ID: References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.61] Content-Type: multipart/alternative; boundary="_000_d7bbbb10fa7a42368717ee47a45c07d6XCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:21:48 -0000 --_000_d7bbbb10fa7a42368717ee47a45c07d6XCHRCD006ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGcm9tOiBUb255IEFyY2llcmkgW21haWx0bzpiYXNjdWxlQGdtYWlsLmNvbV0NClNlbnQ6IE1v bmRheSwgTWFyY2ggMDcsIDIwMTYgMTE6NDAgQU0NClRvOiBTY290dCBGbHVocmVyIChzZmx1aHJl cikNCkNjOiBOaWtvcyBNYXZyb2dpYW5ub3BvdWxvczsgSGFubm8gQsO2Y2s7IEJsdW1lbnRoYWws IFVyaSAtIDA1NTMgLSBNSVRMTDsgdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUlNB LVBTUyBpbiBUTFMgMS4zDQoNCk9uIE1vbiwgTWFyIDcsIDIwMTYgYXQgODozNCBBTSwgU2NvdHQg Rmx1aHJlciAoc2ZsdWhyZXIpIDxzZmx1aHJlckBjaXNjby5jb208bWFpbHRvOnNmbHVocmVyQGNp c2NvLmNvbT4+IHdyb3RlOg0KRGVmZW5zZXMgYWdhaW5zdCB0aGUgZmlyc3QgdHlwZSBvZiBhdHRh Y2sgKHBhc3NpdmUgZXZlc2Ryb3BwaW5nIGJ5IHNvbWVvbmUgd2hvIHdpbGwgYnVpbGQgYSBRQyBz b21ldGltZSBpbiB0aGUgZnV0dXJlKSBhcmUgc29tZXRoaW5nIHRoYXQgdGhpcyBXRyBzaG91bGQg YWRkcmVzczsgZXZlbiBpZiB0aGUgUEtJIHBlb3BsZSBkb24ndCBoYXZlIGFuIGFuc3dlciwgd2Ug d291bGQgYXQgbGVhc3QgYmUgc2VjdXJlIGZyb20gc29tZW9uZSByZWNvcmRpbmcgdGhlIHRyYWZm aWMgYW5kIGRlY3J5cHRpbmcgaXQgbGF0ZXINCg0KSSB0aGluayBpdCB3b3VsZCBtYWtlIHNlbnNl IHRvIHdhaXQgZm9yIHRoZSBDRlJHIHRvIHdlaWdoIGluIG9uIHBvc3QtcXVhbnR1bSBjcnlwdG8u IE1vdmluZyB0byBhIHBvb3JseSBzdHVkaWVkIHBvc3QtcXVhbnR1bSBrZXkgZXhjaGFuZ2UgYWxn b3JpdGhtIGV4Y2x1c2l2ZWx5IHJ1bnMgdGhlIHJpc2sgdGhhdCB3aGVuIGl0IGRvZXMgcmVjZWl2 ZSB3aWRlciBzY3J1dGlueSBuZXcgYXR0YWNrcyB3aWxsIGJlIGZvdW5kLiBJIHRoaW5rIHdlIG5l ZWQgdG8gZGVmaW5lIGh5YnJpZCBwcmUvcG9zdC1xdWFudHVtIGtleSBleGNoYW5nZSBhbGdvcml0 aG1zIChlLmcuIEVDQytSaW5nLUxXRStIS0RGKSwgYW5kIHRoYXQgc291bmRzIGxpa2Ugd29yayBi ZXR0ZXIgc3VpdGVkIGZvciB0aGUgQ0ZSRyB0aGFuIHRoZSBUTFMgV0cuDQoNCg0KSeKAmW0gc29y cnkgdGhhdCBJIHdhc27igJl0IGNsZWFyZXI7IEkgYWdyZWUgdGhhdCAqbm93KiBpc27igJl0IHRo ZSB0aW1lIHRvIGRlZmluZSBhIHBvc3RxdWFudHVtIGNpcGhlcnN1aXRlL25hbWVkIGdyb3VwOyB3 ZeKAmXJlIG5vdCByZWFkeSB5ZXQgKGFuZCB0aGlzIFdHIHByb2JhYmx5IGlzbuKAmXQgdGhlIHJp Z2h0IGdyb3VwIHRvIGRlZmluZSBpdCkuICBIb3dldmVyLCBJIGJlbGlldmUgdGhhdCB3ZSB3aWxs IG5lZWQgdG8gZG8gYXQgc29tZSBwb2ludDsgbXkgZ3Vlc3MgaXMgdGhhdCBpdOKAmWxsIGJlIHNv b25lciByYXRoZXIgdGhhbiBsYXRlci4gIFdoYXQgKElNSE8pIHRoaXMgV0cgc2hvdWxkIGJlIGRv aW5nIG5vdyBpcyBtYWtpbmcgc3VyZSB0aGF0IHRoZXJlIGlzbuKAmXQgc29tZXRoaW5nIGluIFRM UyAxLjMgdGhhdOKAmWxsIG1ha2UgaXQgaGFyZGVyIHRvIHRyYW5zaXRpb24gdG8gcG9zdHF1YW50 dW0gY3J5cHRvIHdoZW4gd2UgZG8gaGF2ZSBhIGNvbmNyZXRlIHByb3Bvc2FsLg0KDQpPbmUgdGhp bmcgdGhhdCBwcm9wb3NlZCBRUiBrZXkgZXhjaGFuZ2VzIGhhdmUgaXMgdGhhdCB0aGV5IGRvbuKA mXQgaGF2ZSB0aGUgZnVsbCBmbGV4aWJpbGl0eSB0aGF0IChFQylESCBoYXZlOyBlaXRoZXIgdGhl eSBhcmVu4oCZdCBzZWN1cmUgd2l0aCBzdGF0aWMga2V5IHNoYXJlcywgb3Igd2UgY2Fu4oCZdCB1 c2UgdGhlIHNhbWUga2V5IHNoYXJlIGFzIGJvdGggYW4g4oCYaW5pdGlhdG9y4oCZIGFuZCBhIOKA mHJlc3BvbmRlcuKAmSBrZXkgc2hhcmUuICBUaGlzIHdvdWxkIGluZGljYXRlIHRvIG1lIHRoYXQg d2UgbmVlZCB0byBtYWtlIHN1cmUgdGhhdCBUTFMgMS4zIHNob3VsZCBiZSBlbmdpbmVlcmVkIHRv IHVzZSAoRUMpREggYXMgb25seSBhIHNpbXBsZSwgZXBoZW1lcmFsLW9ubHkga2V5IGV4Y2hhbmdl IOKAkyB5ZXMsIGl0IGhhcyBtb3JlIGZsZXhpYmlsaXR5IHRoYW4gdGhhdCwgaG93ZXZlciB0YWtp bmcgYWR2YW50YWdlIG9mIHN1Y2ggZmxleGliaWxpdHkgbWlnaHQgY2F1c2UgdXMgcHJvYmxlbXMg aW4gdGhlIGZ1dHVyZQ0KDQo= --_000_d7bbbb10fa7a42368717ee47a45c07d6XCHRCD006ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv YT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEu NXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBUb255IEFy Y2llcmkgW21haWx0bzpiYXNjdWxlQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIE1hcmNoIDA3LCAyMDE2IDExOjQwIEFNPGJyPg0KPGI+VG86PC9iPiBTY290dCBGbHVocmVy IChzZmx1aHJlcik8YnI+DQo8Yj5DYzo8L2I+IE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zOyBIYW5u byBCw7ZjazsgQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMOyB0bHNAaWV0Zi5vcmc8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFJTQS1QU1MgaW4gVExTIDEuMzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIE1vbiwgTWFyIDcsIDIwMTYgYXQgODozNCBBTSwgU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIp ICZsdDs8YSBocmVmPSJtYWlsdG86c2ZsdWhyZXJAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ c2ZsdWhyZXJAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5EZWZlbnNlcyBhZ2FpbnN0IHRoZSBmaXJzdCB0eXBlIG9mIGF0dGFjayAo cGFzc2l2ZSBldmVzZHJvcHBpbmcgYnkgc29tZW9uZSB3aG8gd2lsbCBidWlsZCBhIFFDIHNvbWV0 aW1lIGluIHRoZSBmdXR1cmUpIGFyZSBzb21ldGhpbmcgdGhhdCB0aGlzIFdHIHNob3VsZCBhZGRy ZXNzOyBldmVuIGlmIHRoZSBQS0kgcGVvcGxlIGRvbid0IGhhdmUgYW4gYW5zd2VyLCB3ZSB3b3Vs ZCBhdCBsZWFzdCBiZSBzZWN1cmUgZnJvbQ0KIHNvbWVvbmUgcmVjb3JkaW5nIHRoZSB0cmFmZmlj IGFuZCBkZWNyeXB0aW5nIGl0IGxhdGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCkkgdGhpbmsgaXQgd291bGQgbWFrZSBzZW5zZSB0byB3YWl0IGZv ciB0aGUgQ0ZSRyB0byB3ZWlnaCBpbiBvbiBwb3N0LXF1YW50dW0gY3J5cHRvLiBNb3ZpbmcgdG8g YSBwb29ybHkgc3R1ZGllZCBwb3N0LXF1YW50dW0ga2V5IGV4Y2hhbmdlIGFsZ29yaXRobSBleGNs dXNpdmVseSBydW5zIHRoZSByaXNrIHRoYXQgd2hlbiBpdCBkb2VzIHJlY2VpdmUgd2lkZXIgc2Ny dXRpbnkgbmV3IGF0dGFja3Mgd2lsbCBiZSBmb3VuZC4gSSB0aGluayB3ZSBuZWVkDQogdG8gZGVm aW5lIGh5YnJpZCBwcmUvcG9zdC1xdWFudHVtIGtleSBleGNoYW5nZSBhbGdvcml0aG1zIChlLmcu IEVDQyYjNDM7UmluZy1MV0UmIzQzO0hLREYpLCBhbmQgdGhhdCBzb3VuZHMgbGlrZSB3b3JrIGJl dHRlciBzdWl0ZWQgZm9yIHRoZSBDRlJHIHRoYW4gdGhlIFRMUyBXRy48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+SeKAmW0gc29ycnkgdGhhdCBJIHdhc27igJl0IGNsZWFyZXI7IEkgYWdyZWUgdGhhdCAqPGI+ bm93PC9iPiogaXNu4oCZdCB0aGUgdGltZSB0byBkZWZpbmUgYSBwb3N0cXVhbnR1bSBjaXBoZXJz dWl0ZS9uYW1lZCBncm91cDsgd2XigJlyZSBub3QgcmVhZHkgeWV0IChhbmQgdGhpcyBXRw0KIHBy b2JhYmx5IGlzbuKAmXQgdGhlIHJpZ2h0IGdyb3VwIHRvIGRlZmluZSBpdCkuJm5ic3A7IEhvd2V2 ZXIsIEkgYmVsaWV2ZSB0aGF0IHdlIHdpbGwgbmVlZCB0byBkbyBhdCBzb21lIHBvaW50OyBteSBn dWVzcyBpcyB0aGF0IGl04oCZbGwgYmUgc29vbmVyIHJhdGhlciB0aGFuIGxhdGVyLiZuYnNwOyBX aGF0IChJTUhPKSB0aGlzIFdHIHNob3VsZCBiZSBkb2luZyBub3cgaXMgbWFraW5nIHN1cmUgdGhh dCB0aGVyZSBpc27igJl0IHNvbWV0aGluZyBpbiBUTFMgMS4zIHRoYXTigJlsbA0KIG1ha2UgaXQg aGFyZGVyIHRvIHRyYW5zaXRpb24gdG8gcG9zdHF1YW50dW0gY3J5cHRvIHdoZW4gd2UgZG8gaGF2 ZSBhIGNvbmNyZXRlIHByb3Bvc2FsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T25lIHRoaW5nIHRoYXQgcHJvcG9zZWQg UVIga2V5IGV4Y2hhbmdlcyBoYXZlIGlzIHRoYXQgdGhleSBkb27igJl0IGhhdmUgdGhlIGZ1bGwg ZmxleGliaWxpdHkgdGhhdCAoRUMpREggaGF2ZTsgZWl0aGVyIHRoZXkgYXJlbuKAmXQgc2VjdXJl IHdpdGggc3RhdGljIGtleSBzaGFyZXMsDQogb3Igd2UgY2Fu4oCZdCB1c2UgdGhlIHNhbWUga2V5 IHNoYXJlIGFzIGJvdGggYW4g4oCYaW5pdGlhdG9y4oCZIGFuZCBhIOKAmHJlc3BvbmRlcuKAmSBr ZXkgc2hhcmUuJm5ic3A7IFRoaXMgd291bGQgaW5kaWNhdGUgdG8gbWUgdGhhdCB3ZSBuZWVkIHRv IG1ha2Ugc3VyZSB0aGF0IFRMUyAxLjMgc2hvdWxkIGJlIGVuZ2luZWVyZWQgdG8gdXNlIChFQylE SCBhcyBvbmx5IGEgc2ltcGxlLCBlcGhlbWVyYWwtb25seSBrZXkgZXhjaGFuZ2Ug4oCTIHllcywg aXQgaGFzIG1vcmUgZmxleGliaWxpdHkNCiB0aGFuIHRoYXQsIGhvd2V2ZXIgdGFraW5nIGFkdmFu dGFnZSBvZiBzdWNoIGZsZXhpYmlsaXR5IG1pZ2h0IGNhdXNlIHVzIHByb2JsZW1zIGluIHRoZSBm dXR1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_d7bbbb10fa7a42368717ee47a45c07d6XCHRCD006ciscocom_-- From nobody Mon Mar 7 09:25:12 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A27E21CD647 for ; Mon, 7 Mar 2016 09:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.023 X-Spam-Level: X-Spam-Status: No, score=-5.023 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRV2b3w5y4Sh for ; Mon, 7 Mar 2016 09:25:09 -0800 (PST) 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 ietfc.amsl.com (Postfix) with ESMTPS id 5D9841CD645 for ; Mon, 7 Mar 2016 09:25:09 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 3FC0D7F092; Mon, 7 Mar 2016 17:18:38 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u27HIaLo008149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 12:18:37 -0500 From: Hubert Kario To: "Scott Fluhrer (sfluhrer)" Date: Mon, 07 Mar 2016 18:18:30 +0100 Message-ID: <1780021.yiLHCh9FZ9@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.3.6-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <720dc8ee9c9a49209c1e76271d0dd403@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <5209728.bPpGhxeIz8@pintsize.usersys.redhat.com> <720dc8ee9c9a49209c1e76271d0dd403@XCH-RCD-006.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5504417.c4YvPBIqsT"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:25:10 -0000 --nextPart5504417.c4YvPBIqsT Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote: > > -----Original Message----- > > From: Hubert Kario [mailto:hkario@redhat.com] > > Sent: Monday, March 07, 2016 6:43 AM > > To: tls@ietf.org > > Cc: Scott Fluhrer (sfluhrer); Nikos Mavrogiannopoulos; Hanno B=C3=B6= ck; > > Blumenthal, Uri - 0553 - MITLL > > Subject: Re: [TLS] RSA-PSS in TLS 1.3 > >=20 > > On Friday 04 March 2016 13:49:11 Scott Fluhrer wrote: > >=20 > > > > -----Original Message----- > > > > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Nikos > > > > Mavrogiannopoulos > > > > Sent: Friday, March 04, 2016 3:10 AM > > > > To: Hanno B=C3=B6ck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.o= rg > > > > Subject: Re: [TLS] RSA-PSS in TLS 1.3 > > > > > > > > > > > > > > > > On Thu, 2016-03-03 at 17:11 +0100, Hanno B=C3=B6ck wrote: > > > > > > > > > > > > > > > > > It may be worth asking the authors what's their opinion of FD= H > > > > > vs > > > > > > > > > > > > > > > > > > > > > PSS > > > > > > in view of the state of the art *today*. > > > > > > > > > > > > > > > > > > > > You may do that, but I doubt that changes much. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think FDH really is not an option at all here. It may very > > > > > well > > > > > be that there are better ways to do RSA-padding, but I don't > > > > > think > > > > > that this is viable for TLS 1.3 (and I don't think FDH is > > > > > better). > > > > > PSS has an RFC (3447) and has been thoroughly analyzed by > > > > > research. I > > =20 > > think there has been far less analyzing effort > > =20 > > > > > towards FDH (or any other construction) and it is not in any > > > > > way > > > > > specified in a standards document. If one would want to use > > > > > FDH or > > > > > anything else one would imho first have to go through some > > > > > standardization process (which could be CFRG or NIST or > > > > > someone > > > > > else) and call for a thorough analysis of it by the > > > > > cryptographic > > > > > community. Which would take at least a couple of years. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Given that there probably is no long term future for RSA > > > > > anyway > > > > > (people want ECC and postquantum is ahead) I doubt anything > > > > > else > > > > > than the primitives we already have in standards will ever be= > > > > > viable.> > > > > > > > > > > > > > > > > On the contrary. If we have a future with quantum computers > > > > available, the only thing that we have now and would work is > > > > RSA > > > > with larger keys, not ECC. > > > > > > > > > > > > RSA isn't *that* much more secure against a Quantum Computer than= > > > ECC. > >=20 > > > It would appear to take a larger Quantum Computer to break RSA > > > than > > >=20 > > > it would to break ECC (for reasonable moduli/curve sizes), howeve= r > > > not that much more. It is possible that, at one stage, we'll be > > > able to build a QC that's just large enough to break EC curves, > > > but not larger RSA keys - however, we would be likely to be able > > > to scale up our QC to be a bit larger; possibly in a few months, > > > quite likely in a year or two. Hence, moving back to RSA would > > > appear likely to buy us only a short window... > >=20 > >=20 > >=20 > > > I agree with Hanno; if we're interested in defending against a > > > Quantum Computer, post Quantum algorithms are the way to go > >=20 > >=20 > > except that using RSA keys nearly an order of magnitude larger than= > > the biggest ECC curve that's widely supported (secp384) is the > > current recommended minimum by ENISA and long term minimum by NIST > > (3072).=20 > > Using keys 5 times larger still is not impossible, so while it may > > not buy us extra 20 years after ECC is broken, 10 years is not > > impossible and 5 is almost certain (if Moore's law holds for > > quantum computers). > > It's not much, but it may be enough to make a difference. >=20 >=20 > If we believe that growth in Moore's law will be accurate for Quantum= > Computers, then no one has to worry about Quantum Computers for the > next millennia. =20 > In 2001, a Quantum Computer factored a 4 bit number. In 2014, the > factorization of a 16 bit number was announced (however, the > factorization used a special relationship between the factors, so I > don=E2=80=99t think it counts as a general factorization, but let's i= gnore > that for now). That's not too far off from a Moore's law type > expansion. If this rate continues, well see the first 1024 bit > factorization circa the year 3100 AD (aka CE). GIGO, you're extrapolating from two data points when we have no idea ho= w=20 fast or how slow will be the progress in general and I meant Moore's 18-24 months per double, not the idea of exponentia= l=20 growth in general; in other words P-256 succumbing to quantum computers= =20 4 to 8 years before 1024 bit RSA and we already aren't using 1024 bit RSA and deprecating 1024 bit DH > However, right now one of the chief problems in building a Quantum > Computer is error correction; catching when decoherence has occurred,= > and fixing it before it spoils the entire operation. Once they have > that solved, practical Quantum Computers may get much bigger very > fast. or the error correction issues may scale in tandem with the number of=20= bits that need to be error corrected, or it may be a problem that never= =20 really gets solved (like 4GHz barrier of silicon) > Might they, after the initial explosive growth (to 1000 qbits or > 1,000,000 qbits, I don't think anyone knows where that point would > be), might it continue to grow in a Moore's law fashion? It might; > however we're not sure. Using RSA keys which are 5 times larger > might not buy us any time at all... they might also get unicorn horns as a by-product; everything is=20 possible in this crazy world /s probability of that happening is rather low though, looking at the past= =20 few centuries of scientific development... yes, they may jump ahead one or two doubles by getting really lucky or=20= spending a lot of money, but it won't be sustainable for the whole=20 growth between 256 or 384 bit and 16k bit, let alone from the current 1= 6=20 bits to 16k bits while for libraries to go from current 2k RSA and DH to 16k RSA and DH=20= is trivial in comparison =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 99/71, 612 45, Brno, Czech Republi= c --nextPart5504417.c4YvPBIqsT 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 iQIcBAABCgAGBQJW3bfmAAoJEJKo0bgB0vX1n4EP/3BQ9bSuM2kBjdYvJ34HanSA WyNkZ3iht8YEstLSQ0r7zBj57Lbt5LrdJVaXvu+3bpFVvYHmGZ9ccefft5JU4Vi7 XIvJD8T3zmwvuEzM26nZVAq9AL7T0qGl6npdzG/brGpS4KPoewYVPG02jubxppO+ /p0oKhpBU8/Y0IS/kgGGq+OJ9qOwO5AYHZTI3uZYSyu+a46/hGa3auSqcRSLCROR 8CA8ke78wNXWLKmiGRPuF+w8JFgcOmtugpZVkZ27B21/MF0UrKu9rpgOnE3rHmlm xWgJ0bh5dcOJrPOmmPszNdLe/v3CWibknwUwBF7fXcOFS4RSvitbDYes2b7i2tO9 b9M1xn3DjVXWP6JeAUxzlinPrN9Y+X6PkOGDFWjpW1G3xjo4f5zXZDFx40GAijnc 7FMFQAYSwBghmz6AVA0xX0Tc5yfVagjOVCfRlZs10so5AkEY95QH+++swGYSTHzq 9jI8eh/7nmqtDTk0UAG+uQgvIdAACu+e8vpDw59aGRc57MEq6KMOUDrIRGWzUt4Y 1xOwylzKA1G4rQ7vVXV6rDyP9jT+xTOWmbQgWLpEVD8UdHiFqpkuF+njWIKew1HI OK1a3ya2R9jvmwM1oNLgrCn0eXSozS3z91R/CIdH5RA9U/uxUVF5qclZDugRuT68 4ogUkwAeL/QzRPySo9Lp =Ovh6 -----END PGP SIGNATURE----- --nextPart5504417.c4YvPBIqsT-- From nobody Mon Mar 7 09:44:17 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 489151CD627 for ; Mon, 7 Mar 2016 09:44:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tfj2IwsC6Lej for ; Mon, 7 Mar 2016 09:44:15 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 85F371CD641 for ; Mon, 7 Mar 2016 09:44:12 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id d205so84631467oia.0 for ; Mon, 07 Mar 2016 09:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CWqTzUETskHwfN3UDlretqrQntfv33xZVFEzIKxWVjg=; b=s9PGyW1os6ceykXjHCvYq35EvYBv5PwYtc1wNGSBeZGm4/SvtNBaixvrscJzCJiP9a pouWiih0ddXzLfLCFAwHolSA2iq7gEOD4y/Au1LztVRDvFS6CcKGhlF8J4wvgOGrVMh0 Dh/XdGnvok/yJQt7pX3xMnhHOqjL5wAzXPmQ4oSTqm6s2ZDyHyQESMRNd2abm26tDuT4 qPmene6Z/LsFo96GMM8+ro55TQDFm9UjRksFhca5qfmchSwNWfSF+ilN6scIof3QlMYl U8I1mOiF+ugxPGKF1L87DWfOSg7d7V4Mnyfv20nZ0mOPNgCQLS895c5UizoOrP2Mc3Kj hXag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CWqTzUETskHwfN3UDlretqrQntfv33xZVFEzIKxWVjg=; b=dmKrA5pfqcWAjuzhNVjsG7Xyc+4uluVdOK+/SbY0TsYo9jVs+Hf684Vn08aDRcqLBo d6d0oF9+vGjayC9xe3WBHYJoMeG1UKwWiKzaNgPuhslhQaAV7R297iNbOWAQ/CriyPcQ DEyAzXRqSYe3OI6diK4YkhUcL+79xRUbBy782s8DBshlxWd6MueCiAmqzpQfUFoBsMQ2 ckqHmUphJAqpthjzYB4eyUOrwu9l6rKlyK3iqiogh3eWWVL4VJ/wSdYEnUXUrx7j3cZ2 NtuAJGmG28O2qcOcvtIJp//kPo4CIU/w7Lg6YdSEDhArsv7ozqWKz1xAvcLu2OonoOn5 q14Q== X-Gm-Message-State: AD7BkJJvex2c8FZ/jjOrMOMdjUgwAF0UdO3Zkexk11OOtvr7AtukMZ6qsNzt8YKgv6536btLK7AtTERjMZyEsQ== X-Received: by 10.202.215.86 with SMTP id o83mr14317860oig.55.1457368818502; Mon, 07 Mar 2016 08:40:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.51.73 with HTTP; Mon, 7 Mar 2016 08:39:58 -0800 (PST) In-Reply-To: <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> From: Tony Arcieri Date: Mon, 7 Mar 2016 08:39:58 -0800 Message-ID: To: "Scott Fluhrer (sfluhrer)" Content-Type: multipart/alternative; boundary=001a113d3c30bbd456052d781eb9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:44:16 -0000 --001a113d3c30bbd456052d781eb9 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) wrote: > Defenses against the first type of attack (passive evesdropping by someone > who will build a QC sometime in the future) are something that this WG > should address; even if the PKI people don't have an answer, we would at > least be secure from someone recording the traffic and decrypting it later I think it would make sense to wait for the CFRG to weigh in on post-quantum crypto. Moving to a poorly studied post-quantum key exchange algorithm exclusively runs the risk that when it does receive wider scrutiny new attacks will be found. I think we need to define hybrid pre/post-quantum key exchange algorithms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better suited for the CFRG than the TLS WG. -- Tony Arcieri --001a113d3c30bbd456052d781eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) <= sfluhrer@cisco.com<= /a>> wrote:
Defenses against the first type o= f attack (passive evesdropping by someone who will build a QC sometime in t= he future) are something that this WG should address; even if the PKI peopl= e don't have an answer, we would at least be secure from someone record= ing the traffic and decrypting it later

I think it wo= uld make sense to wait for the CFRG to weigh in on post-quantum crypto. Mov= ing to a poorly studied post-quantum key exchange algorithm exclusively run= s the risk that when it does receive wider scrutiny new attacks will be fou= nd. I think we need to define hybrid pre/post-quantum key exchange algorith= ms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better suited for th= e CFRG than the TLS WG.

--
Tony Arcieri
--001a113d3c30bbd456052d781eb9-- From nobody Mon Mar 7 11:48:54 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 2DF9D1CDA2F for ; Mon, 7 Mar 2016 11:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu9pi-YirMd1 for ; Mon, 7 Mar 2016 11:48:50 -0800 (PST) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 6774C1CDA2A for ; Mon, 7 Mar 2016 11:48:50 -0800 (PST) Received: by mail-qg0-x230.google.com with SMTP id y89so105324238qge.2 for ; Mon, 07 Mar 2016 11:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=Z1R7xPkaWgpoOij1fOUiAOzcmbQGFjmnR3Q0ca1AZBc=; b=wV2aJ9vBqAXySrt8VHdmlSpqFIEtFZvh9aInYWDMTmzEzzrLR8nytRsK2pUqaVl4tD S+XcW6pAVgAXlThxH1ECqdV/z7Z7h1wM9BH4SQvcq7oQxMgV7YUcwhC/2uEyihSSY/XQ CYggw4JKIM0yzakKSsoK3sMlSfITvtUuAw+wtxFqN5Fy+TgcNtP2e+yIkYf9KPnjqbKH YG6tO1BN88dF0ox/WyDBAAGDHvFttS1Bx5rRMxu/InIVGMsPZ5XUyYFJQa0k0rtLlolH jrsYDWgqMSjZ599rBwgvrP+8a+i1CPm2fnJ9CIqlwbXNG3L6XIleX1/BKuuKVMfPVveC 6qbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=Z1R7xPkaWgpoOij1fOUiAOzcmbQGFjmnR3Q0ca1AZBc=; b=FokkwebtrTAAb5Kx4jJvjL+JKPfTkLKUNrLTlvwPJs8nDrj5ilVqxW0bvj81gFaG1l 5oOJyX77uPa9xljcl/QIFayOi2+XMXHRgcmtlfKp9B616oF5fa8ns4VceFKrLhFYWilx RdKp0ArCv3+S92nbvgy168ZakENIsLpulVPM8V3LDmqZJSVyKWhtHNT5vDVUBbSJyBBF g56n9QgUcHBj/FJ4LZnot+dHt27Vs93crvOLsAuxQVR0tnMHXF5UY/FvcKM5zTA5XV/W 809bxKEqNc81x+wrz4oYsaRu88ACqYRMT+3fAiCOvomWYiWxBzNrsXd+kemHnIs+el5L BrlA== X-Gm-Message-State: AD7BkJJvmowDMaUt5sAR0pMCVvpzrwvL2G/iHCucMLNS9WfWxRQBpU1C5FY4WDIc2aHLCA== X-Received: by 10.140.91.35 with SMTP id y32mr30422407qgd.42.1457380129495; Mon, 07 Mar 2016 11:48:49 -0800 (PST) Received: from [192.168.0.10] (CPE7cb21b2cb904-CM7cb21b2cb901.cpe.net.cable.rogers.com. [99.231.49.38]) by smtp.gmail.com with ESMTPSA id v66sm8635116qhb.26.2016.03.07.11.48.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Mar 2016 11:48:48 -0800 (PST) To: "Scott Fluhrer (sfluhrer)" , Tony Arcieri References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> From: Rene Struik Message-ID: <56DDDB1E.1090007@gmail.com> Date: Mon, 7 Mar 2016 14:48:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------010400030408050409000403" Archived-At: Cc: "tls@ietf.org" Subject: [TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:48:52 -0000 This is a multi-part message in MIME format. --------------010400030408050409000403 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Scott: I think it is really premature to speculate on features PQ-secure algorithms can or cannot provide (*) and try and have this influence *current* TLS1.3 protocol design. Should one wish to include PQ algorithms in a future update of TLS1.3, one can simply specify which protocol ingredients those updates relate to. As long as the current TLS1.3 specification has some facility for implementing algorithm agility, one can shy away from crystal ball gazing for now. Best regards, Rene (*) I am not sure everyone would concur with your speculation, but crypto conferences may be a better venue to discuss this than a TLS mailing list. On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote: > > *From:*Tony Arcieri [mailto:bascule@gmail.com] > *Sent:* Monday, March 07, 2016 11:40 AM > *To:* Scott Fluhrer (sfluhrer) > *Cc:* Nikos Mavrogiannopoulos; Hanno Bck; Blumenthal, Uri - 0553 - > MITLL; tls@ietf.org > *Subject:* Re: [TLS] RSA-PSS in TLS 1.3 > > On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) > > wrote: > > Defenses against the first type of attack (passive evesdropping by > someone who will build a QC sometime in the future) are something that > this WG should address; even if the PKI people don't have an answer, > we would at least be secure from someone recording the traffic and > decrypting it later > > > I think it would make sense to wait for the CFRG to weigh in on > post-quantum crypto. Moving to a poorly studied post-quantum key > exchange algorithm exclusively runs the risk that when it does receive > wider scrutiny new attacks will be found. I think we need to define > hybrid pre/post-quantum key exchange algorithms (e.g. > ECC+Ring-LWE+HKDF), and that sounds like work better suited for the > CFRG than the TLS WG. > > Im sorry that I wasnt clearer; I agree that **now** isnt the time > to define a postquantum ciphersuite/named group; were not ready yet > (and this WG probably isnt the right group to define it). However, I > believe that we will need to do at some point; my guess is that itll > be sooner rather than later. What (IMHO) this WG should be doing now > is making sure that there isnt something in TLS 1.3 thatll make it > harder to transition to postquantum crypto when we do have a concrete > proposal. > > One thing that proposed QR key exchanges have is that they dont have > the full flexibility that (EC)DH have; either they arent secure with > static key shares, or we cant use the same key share as both an > initiator and a responder key share. This would indicate to me > that we need to make sure that TLS 1.3 should be engineered to use > (EC)DH as only a simple, ephemeral-only key exchange yes, it has > more flexibility than that, however taking advantage of such > flexibility might cause us problems in the future > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------010400030408050409000403 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Hi Scott:

I think it is really premature to speculate on features PQ-secure algorithms can or cannot provide (*) and try and have this influence *current* TLS1.3 protocol design. Should one wish to include PQ algorithms in a future update of TLS1.3, one can simply specify which protocol ingredients those updates relate to. As long as the current TLS1.3 specification has some facility for implementing algorithm agility, one can shy away from crystal ball gazing for now.

Best regards, Rene

(*) I am not sure everyone would concur with your speculation, but crypto conferences may be a better venue to discuss this than a TLS mailing list.

On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote:

From: Tony Arcieri [mailto:bascule@gmail.com]
Sent: Monday, March 07, 2016 11:40 AM
To: Scott Fluhrer (sfluhrer)
Cc: Nikos Mavrogiannopoulos; Hanno Bck; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

Defenses against the first type of attack (passive evesdropping by someone who will build a QC sometime in the future) are something that this WG should address; even if the PKI people don't have an answer, we would at least be secure from someone recording the traffic and decrypting it later


I think it would make sense to wait for the CFRG to weigh in on post-quantum crypto. Moving to a poorly studied post-quantum key exchange algorithm exclusively runs the risk that when it does receive wider scrutiny new attacks will be found. I think we need to define hybrid pre/post-quantum key exchange algorithms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better suited for the CFRG than the TLS WG.

Im sorry that I wasnt clearer; I agree that *now* isnt the time to define a postquantum ciphersuite/named group; were not ready yet (and this WG probably isnt the right group to define it). However, I believe that we will need to do at some point; my guess is that itll be sooner rather than later. What (IMHO) this WG should be doing now is making sure that there isnt something in TLS 1.3 thatll make it harder to transition to postquantum crypto when we do have a concrete proposal.

One thing that proposed QR key exchanges have is that they dont have the full flexibility that (EC)DH have; either they arent secure with static key shares, or we cant use the same key share as both an initiator and a responder key share. This would indicate to me that we need to make sure that TLS 1.3 should be engineered to use (EC)DH as only a simple, ephemeral-only key exchange yes, it has more flexibility than that, however taking advantage of such flexibility might cause us problems in the future



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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------010400030408050409000403-- From nobody Mon Mar 7 12:25:25 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9738E1CDA92 for ; Mon, 7 Mar 2016 12:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Xk0yIPBHkfn for ; Mon, 7 Mar 2016 12:25:23 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfc.amsl.com (Postfix) with ESMTP id 5707B1CDA21 for ; Mon, 7 Mar 2016 12:25:22 -0800 (PST) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u27KOar5013153 for ; Mon, 7 Mar 2016 15:24:36 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3 Thread-Index: AQHReKpiyrTkhq476UOIwxNmmCRUC59ObY8A Date: Mon, 7 Mar 2016 20:25:21 +0000 Message-ID: References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> <56DDDB1E.1090007@gmail.com> In-Reply-To: <56DDDB1E.1090007@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3540209110_57109473" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-07_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1601100000 definitions=main-1603070368 Archived-At: Subject: Re: [TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:25:24 -0000 --B_3540209110_57109473 Content-type: multipart/alternative; boundary="B_3540209110_57067158" --B_3540209110_57067158 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit > I think it is really premature to speculate on features PQ-secure algorithms > can or cannot provide (*) and try and have this influence *current* TLS1.3 > protocol design. Should one wish to include PQ algorithms in a future update > of TLS1.3, one can simply specify which protocol ingredients those updates > relate to. As long as the current TLS1.3 specification has some facility for > implementing algorithm agility, one can shy away from crystal ball gazing for > now. +1 --B_3540209110_57067158 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
I think it is really premature to s= peculate on features PQ-secure algorithms can or cannot provide (*) and try = and have this influence *current* TLS1.3 protocol design.  Should one w= ish to include PQ algorithms in a future update of TLS1.3, one can simply sp= ecify which protocol ingredients those updates relate to. As long as the current= TLS1.3 specification has some facility for implementing algorithm agility, = one can shy away from crystal ball gazing for now.

+1

=
--B_3540209110_57067158-- --B_3540209110_57109473 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwSyLknaV86V5Myl818vKUFpuiLLImj4nACDoxJAWElc2y5v9kvRR6WR+/5W6B1X0gMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDMwNzIwMjUxMFow DQYJKoZIhvcNAQEBBQAEggEAnmXcc/s59DSTp+2esiWyoehRYQ/ReTPXYn4QoANvMdvimM6S sB/5etiV59j82+3Mv8WBkhNFDxn0PLgSwgR9Bvk0Sh3O9pTEwkO3II0pnFJnT9kCCwZdQnyO iXCHwDCOiF71XUJzLhFOPlL+lit5QR8V94mgiIOx2YPdIDd8xjDJdcCQnRIldKGLYw60bveE wrHPxJ7WeTemzZQjtwFFyMyFGRZy84FQZk7sCfPxbi+fGPGiTTxdz7an95knp+6U2+kWu6m9 xmMLObgcnsHsSIdCUL040r4VhfI1mIWq4So6+Np8WJQJgcio4svtBuGQwfL3ZChJHbDTOY1U r5BIGQ== --B_3540209110_57109473-- From nobody Mon Mar 7 14:05:34 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E585E1CDC48 for ; Mon, 7 Mar 2016 14:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfc.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0FlDsa40hxa for ; Mon, 7 Mar 2016 14:05:32 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 15B1B1CDC43 for ; Mon, 7 Mar 2016 14:05:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18899; q=dns/txt; s=iport; t=1457388330; x=1458597930; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8BUBIMlY9BQl/TBLE4yoo74JQFtX3lCO0zsag65fEQI=; b=IocBacwPQdxVlt9D8ercNi5ihaXclPwo4pi8mVvudq+XY20PLYPfMP2z +iFpCMBNzA/BUaORj5b7VzsZG6LjkgJwwLHdBH/iljx5rXz0ESlumoMBG hj4UJ3NQ03cMbXPNowTPf9VZU/e4g4sz3q2zrr63WJUHO6XCUZdPqP+4Z s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAgBs+t1W/4kNJK1ZA4JuTFJtBoU7q?= =?us-ascii?q?U6LMQENgWkXAQmEFYFZAoEwOBQBAQEBAQEBZCeEQQEBAQQBAQEqOwYLEAIBCA4?= =?us-ascii?q?DBAEBJAQHIQYLFAkIAgQBDQUIiAcDEg65fg2EQgEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEhheDQH2CPYFNEQEGOQwJEYNzBYg3hTGDXoU1BSoBi3eBboFqjReFeYE?= =?us-ascii?q?Th0gBHgEBQoFMZIE0aogLNH4BAQE?= X-IronPort-AV: E=Sophos; i="5.22,553,1449532800"; d="scan'208,217"; a="83308862" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Mar 2016 22:05:29 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u27M5Tmb029968 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Mar 2016 22:05:29 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 7 Mar 2016 16:05:28 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 7 Mar 2016 16:05:28 -0600 From: "Scott Fluhrer (sfluhrer)" To: Rene Struik , Tony Arcieri Thread-Topic: (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AAChgSqAAAfIBWD///NnAIAAWx/g///ZoQCAAEUBAA== Date: Mon, 7 Mar 2016 22:05:28 +0000 Message-ID: <3d2ff968e35c4958b8b4efadf607572b@XCH-RCD-006.cisco.com> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <20160303171117.12e627b3@pc1> <1457078973.19296.1.camel@redhat.com> <3611ab23e3f948b4bfa0bdd0b348bcc2@XCH-RCD-006.cisco.com> <1457358135.3117.43.camel@redhat.com> <8063d9927c134546ad3f2226b960b516@XCH-RCD-006.cisco.com> <56DDDB1E.1090007@gmail.com> In-Reply-To: <56DDDB1E.1090007@gmail.com> 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: [10.98.2.61] Content-Type: multipart/alternative; boundary="_000_3d2ff968e35c4958b8b4efadf607572bXCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:05:34 -0000 --_000_3d2ff968e35c4958b8b4efadf607572bXCHRCD006ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not precisely sure what you are really saying. Are you claiming that, = even though currently known PQ key exchange don't give all the flexibility = that (EC)DH has, you're pretty sure that'll change in the future? Or, are = you saying that relying on the full flexibility of (EC)DH isn't a problem, = as the WG will be willing to make changes to the TLS 1.3 0-RTT infrastructu= re in the future? The issue really is the 0-RTT infrastructure, and its static key share. Un= like (EC)DH, known postquantum key agreement protocols either don't securel= y support static key shares (largely because it is impossible to distinguis= h a valid client keyshare from an invalid one, and how the server reacts to= an invalid client keyshare depends on the server's private keyshare value)= , or they are really public key encryption systems being used to do key agr= eement, and the client's key share in the 0-RTT exchange can't be used to n= egotiate a long term set of keys. Outside of 0-RTT, there doesn't appear to be an issue. In those cases, the= client gives an ephemeral key share, the server responds with an ephemeral= key share, they both derive a shared secret, and everyone (other than the = NSA, who can't listen in :-) is happy. However, 0-RTT is an important part= of the protocol; we can't forbid it in a postquantum setting. Of course, we can in the future, we can revise the TLS 1.3 protocol to adap= t to the functionality that postquantum algorithms will give us. However (= based on the protocols we know about) the changes required by the protocol = would be nontrivial. My hope is to make it so that algorithm agility is en= ough; that all the protocol needs to know is that there's this additional c= iphersuite that, from a blackbox standpoint, does precisely the same job as= the other ciphersuites, and that nothing outside of the crypto code needs = to change. However, given that the postquantum algorithms we know about ca= n't do everything that (EC)DH can do, it would appear to be prudent not to = assume (in either our protocol or in our proofs) this additional functional= ity. From: Rene Struik [mailto:rstruik.ext@gmail.com] Sent: Monday, March 07, 2016 2:49 PM To: Scott Fluhrer (sfluhrer); Tony Arcieri Cc: tls@ietf.org Subject: (TLS1.3 - algorithm agility support is enough; no need to crystal = ball gaze PQ right now, except as pass-time) Re: [TLS] RSA-PSS in TLS 1.3 Hi Scott: I think it is really premature to speculate on features PQ-secure algorithm= s can or cannot provide (*) and try and have this influence *current* TLS1.= 3 protocol design. Should one wish to include PQ algorithms in a future up= date of TLS1.3, one can simply specify which protocol ingredients those upd= ates relate to. As long as the current TLS1.3 specification has some facili= ty for implementing algorithm agility, one can shy away from crystal ball g= azing for now. Best regards, Rene (*) I am not sure everyone would concur with your speculation, but crypto c= onferences may be a better venue to discuss this than a TLS mailing list. On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote: From: Tony Arcieri [mailto:bascule@gmail.com] Sent: Monday, March 07, 2016 11:40 AM To: Scott Fluhrer (sfluhrer) Cc: Nikos Mavrogiannopoulos; Hanno B=F6ck; Blumenthal, Uri - 0553 - MITLL; = tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) > wrote: Defenses against the first type of attack (passive evesdropping by someone = who will build a QC sometime in the future) are something that this WG shou= ld address; even if the PKI people don't have an answer, we would at least = be secure from someone recording the traffic and decrypting it later I think it would make sense to wait for the CFRG to weigh in on post-quantu= m crypto. Moving to a poorly studied post-quantum key exchange algorithm ex= clusively runs the risk that when it does receive wider scrutiny new attack= s will be found. I think we need to define hybrid pre/post-quantum key exch= ange algorithms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better = suited for the CFRG than the TLS WG. I'm sorry that I wasn't clearer; I agree that *now* isn't the time to defin= e a postquantum ciphersuite/named group; we're not ready yet (and this WG p= robably isn't the right group to define it). However, I believe that we wi= ll need to do at some point; my guess is that it'll be sooner rather than l= ater. What (IMHO) this WG should be doing now is making sure that there is= n't something in TLS 1.3 that'll make it harder to transition to postquantu= m crypto when we do have a concrete proposal. One thing that proposed QR key exchanges have is that they don't have the f= ull flexibility that (EC)DH have; either they aren't secure with static key= shares, or we can't use the same key share as both an 'initiator' and a 'r= esponder' key share. This would indicate to me that we need to make sure t= hat TLS 1.3 should be engineered to use (EC)DH as only a simple, ephemeral-= only key exchange - yes, it has more flexibility than that, however taking = advantage of such flexibility might cause us problems in the future _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_3d2ff968e35c4958b8b4efadf607572bXCHRCD006ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I’m not precisely sure what you are really saying.  Are you cla= iming that, even though currently known PQ key exchange don’t give al= l the flexibility that (EC)DH has, you’re pretty sure that’ll ch= ange in the future?  Or, are you saying that relying on the full flexi= bility of (EC)DH isn’t a problem, as the WG will be willing to make c= hanges to the TLS 1.3 0-RTT infrastructure in the future?=

 

The issue really is the 0-R= TT infrastructure, and its static key share.  Unlike (EC)DH, known pos= tquantum key agreement protocols either don’t securely support static key shares (largely because it is impossible to distinguish a valid= client keyshare from an invalid one, and how the server reacts to an inval= id client keyshare depends on the server’s private keyshare value), o= r they are really public key encryption systems being used to do key agreement, and the client’s key share i= n the 0-RTT exchange can’t be used to negotiate a long term set of ke= ys.

 

Outside of 0-RTT, there doe= sn’t appear to be an issue.  In those cases, the client gives an= ephemeral key share, the server responds with an ephemeral key share, they both derive a shared secret, and everyone (other than the NSA, who ca= n’t listen in :-) is happy.  However, 0-RTT is an important part= of the protocol; we can’t forbid it in a postquantum setting.

 

Of course, we can in the fu= ture, we can revise the TLS 1.3 protocol to adapt to the functionality that= postquantum algorithms will give us.  However (based on the protocols we know about) the changes required by the protocol would be= nontrivial.  My hope is to make it so that algorithm agility is enoug= h; that all the protocol needs to know is that there’s this additiona= l ciphersuite that, from a blackbox standpoint, does precisely the same job as the other ciphersuites, and that nothing ou= tside of the crypto code needs to change.  However, given that the pos= tquantum algorithms we know about can’t do everything that (EC)DH can= do, it would appear to be prudent not to assume (in either our protocol or in our proofs) this additional functionality.

 

 <= /p>

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Monday, March 07, 2016 2:49 PM
To: Scott Fluhrer (sfluhrer); Tony Arcieri
Cc: tls@ietf.org
Subject: (TLS1.3 - algorithm agility support is enough; no need to c= rystal ball gaze PQ right now, except as pass-time) Re: [TLS] RSA-PSS in TL= S 1.3

 

Hi Scott:

I think it is really premature to speculate on features PQ-secure algorithm= s can or cannot provide (*) and try and have this influence *current* TLS1.= 3 protocol design.  Should one wish to include PQ algorithms in a futu= re update of TLS1.3, one can simply specify which protocol ingredients those updates relate to. As long as the current= TLS1.3 specification has some facility for implementing algorithm agility,= one can shy away from crystal ball gazing for now.

Best regards, Rene

(*) I am not sure everyone would concur with your speculation, but crypto c= onferences may be a better venue to discuss this than a TLS mailing list.
On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote:

 <= /p>

From: Tony Arc= ieri [mailto:bascule@gmail.com]
Sent: Monday, March 07, 2016 11:40 AM
To: Scott Fluhrer (sfluhrer)
Cc: Nikos Mavrogiannopoulos; Hanno B=F6ck; Blumenthal, Uri - 0553 - = MITLL; tls@ietf.org
Subject: Re: [TLS] RSA-PSS in TLS 1.3

 

On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluh= rer) <sfluhrer@c= isco.com> wrote:

Defenses against the first type of attack (passive e= vesdropping by someone who will build a QC sometime in the future) are some= thing that this WG should address; even if the PKI people don't have an ans= wer, we would at least be secure from someone recording the traffic and decrypting it later


I think it would make sense to wait for the CFRG to weigh in on post-quantu= m crypto. Moving to a poorly studied post-quantum key exchange algorithm ex= clusively runs the risk that when it does receive wider scrutiny new attack= s will be found. I think we need to define hybrid pre/post-quantum key exchange algorithms (e.g. ECC+Ri= ng-LWE+HKDF), and that sounds like work better suited for the CFRG than= the TLS WG.

 <= /p>

 <= /p>

I’m sorry that I wa= sn’t clearer; I agree that *now* isn’t the time to defin= e a postquantum ciphersuite/named group; we’re not ready yet (and thi= s WG probably isn’t the right group to define it).  However, I belie= ve that we will need to do at some point; my guess is that it’ll be s= ooner rather than later.  What (IMHO) this WG should be doing now is m= aking sure that there isn’t something in TLS 1.3 that’ll make it harder to transition to postquantum crypto when we do have a concr= ete proposal.

 <= /p>

One thing that proposed Q= R key exchanges have is that they don’t have the full flexibility tha= t (EC)DH have; either they aren’t secure with static key shares, or we can’t use the same key share as both an ‘initiator’= ; and a ‘responder’ key share.  This would indicate to me = that we need to make sure that TLS 1.3 should be engineered to use (EC)DH a= s only a simple, ephemeral-only key exchange – yes, it has more flexi= bility than that, however taking advantage of such flexibility might cause us pro= blems in the future

 




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




-- 
email: rstruik.ext@gmail.com<=
/a> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--_000_3d2ff968e35c4958b8b4efadf607572bXCHRCD006ciscocom_-- From nobody Mon Mar 7 17:21:16 2016 Return-Path: X-Original-To: tls@ietfc.amsl.com Delivered-To: tls@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B1C4A1CD735 for ; Mon, 7 Mar 2016 17:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.553 X-Spam-Level: X-Spam-Status: No, score=-0.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.41]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9PvAFDUvXHL for ; Mon, 7 Mar 2016 17:21:14 -0800 (PST) Received: from gateway36.websitewelcome.com (gateway36.websitewelcome.com [192.185.200.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfc.amsl.com (Postfix) with ESMTPS id 3C7231CD729 for ; Mon, 7 Mar 2016 17:21:14 -0800 (PST) Received: from cm2.websitewelcome.com (cm2.websitewelcome.com [192.185.178.13]) by gateway36.websitewelcome.com (Postfix) with ESMTP id 4168AFEEFC2F2 for ; Mon, 7 Mar 2016 19:20:05 -0600 (CST) Received: from gator3286.hostgator.com ([198.57.247.250]) by cm2.websitewelcome.com with id TDL31s0155Qt53201DL4Q6; Mon, 07 Mar 2016 19:20:05 -0600 Received: from 19.190.138.210.bf.2iij.net ([210.138.190.19]:50380 helo=[172.16.2.62]) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ad6Jd-000KFX-Us for tls@ietf.org; Mon, 07 Mar 2016 19:20:02 -0600 From: Sean Turner Content-Type: multipart/alternative; boundary="Apple-Mail=_C5E6AA90-9E9F-40CC-A129-966779840EB9" Date: Tue, 8 Mar 2016 10:19:59 +0900 References: To: "" Message-Id: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 210.138.190.19 X-Exim-ID: 1ad6Jd-000KFX-Us X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 19.190.138.210.bf.2iij.net ([172.16.2.62]) [210.138.190.19]:50380 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Subject: [TLS] Fwd: Cached Info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 01:21:15 -0000 --Apple-Mail=_C5E6AA90-9E9F-40CC-A129-966779840EB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, The cached-info draft got all the way to the IESG and then we receive a = couple of comments that require we bring the draft back to the WG to = discuss. spt > Begin forwarded message: >=20 > From: Karthikeyan Bhargavan > Subject: Re: Cached Info > Date: February 23, 2016 at 12:34:31 GMT+9 > To: Sean Turner , Eric Rescorla , = Martin Thomson , "Stephen ie>" = > Cc: Antoine Delignat-Lavaud >=20 > Some corrections: >=20 > Dear All, >=20 > I took a quick look at cached-info at Ekr=E2=80=99 prodding, who was = worried about key synchronization-style attacks (Ekr=E2=80=99s original = email is a the bottom of this email.) > My conclusion is that the use of a 4-byte hash is unnecessarily = fragile. > The attacks are not super-serious, but the following scenario looks = bad. > Maybe I got something wrong about the spec, so do tell me if I did. >=20 > Suppose that the client uses client certificates (or channelID/token = binding) to login to all websites. > The client=E2=80=99s authentication credential is bound to the current = handshake transcript. > If the transcript does not contain the server certificate, then a = malicious server may be able > to forward a credential sent by the client to the malicious server to = a different server. > This kind of credential forwarding attack enables certain kinds of = impersonation (see Triple Handshake) >=20 > In Cached-Info, the transcript includes a 32-bit hash of the = certificate and some signature or RSA encryption that uses the = certificate signing/encryption key. > To mount the attack described above, the attacker would first need to = find a certificate that collides with the honest server certificate = hash. > You can imagine the attacker generating 2^32 self-signed certificates = until the collision is found, this is not hard. > Next, the attacker still has to match the parts of the transcript that = use the server=E2=80=99s public key (if any). > The client could maybe choose the public key to match that of the = server, or carefully choose the RSA signing key to create a signature = value that matches that of the real server etc. > There may be other attacks where the attacker uses a static ECDH = ciphersuite, and so does not need to sign anything. >=20 > So now, the honest client C connects to malicious server M that has a = self-signed cert (for M). > C accepts the cert (for M) and agrees to use certificate/token-bound = authentication at M. > M can then forward the credential and signature to S, which will = accept it. > M would not control the keys between M and S (since it used S=E2=80=99s = public key.) > But if C is using a browser, then C=E2=80=99s window is at M=E2=80=99s = origin, so M can inject=20 > data into the connection which will then be forwarded to S, as if the = authenticated user C intended to send it to M. >=20 > Perhaps the above attack is not very worrisome to some people, but the = silly > bit is that accepting this risk is completely unnecessary. The client = and=20 > server could simply use the full SHA-256 hash for the certificate and = the > client would have a hard time creating a colliding certificate. >=20 > Best, > Karthik > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > Ekr=E2=80=99s original email > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= >=20 > Folks, >=20 > I've been thinking over the cached-info draft, and I'm not convinced > that the security analysis is right. >=20 > In the current design, the client sends a truncated 32-bit hash > of what it believes the server's certificate is. If that matches > the server's certificate, then the server echoes that truncated > hash (if I'm reading it correctly). >=20 > The security considerations section claims: >=20 > The use of the cached info extension allows the server to send > significantly smaller TLS messages. Consequently, these omitted > parts of the messages are not included in the transcript of the > handshake in the TLS Finish message. However, since the client and > the server communicate the hash values of the cached data in the > initial handshake messages the fingerprints are included in the TLS > Finish message. >=20 > But this isn't correct with a short hash, since you're not strongly > binding the hash into the handshake. And elsewhere the text claims > that the hash isn't relevant: >=20 > If an attacker > injects an incorrect fingerprint then two outcomes are possible: = (1) > The fingerprint does not relate to any cached state and the server > has to fall back to a full exchange. (2) If the attacker manages to > inject a fingerprint that refers to data the client has not cached > then the exchange will fail later when the client continues with = the > handshake and aims to verify the digital signature. The signature > verification will fail since the public key cached by the client = will > not correspond to the private key that was used by server to sign = the > message. >=20 > I think this is closer to the truth. But consider the case where > an attacker convinces the client to accept a certificate for > attacker.com but with victim.com = 's public key that *also* > hash the same fingerprint as victim.com 's = certificate. In that case, > you could end up with a UKS between the client and victim.com = > (where the client thinks he's talking to attacker.com = ). What prevents > this (I believe) is the text in Security Considerations: >=20 > Clients MUST ensure that they only cache information from = legitimate > sources. For example, when the client populates the cache from a = TLS > exchange then it must only cache information after the successful > completion of a TLS exchange to ensure that an attacker does not > inject incorrect information into the cache. Failure to do so = allows > for man-in-the-middle attacks. >=20 > If followed, this will stop the client from accepting attacker.com = 's > bogus cert (because he doesn't have the private key). Note, however, = that > you have to follow it strictly. For instance, if you cache after > False Start, then you are vulnerable to this attack. Also, these > instructions seem really counterintuitive, because naively you > would expect to just be able to validate the server's cert and > store the hash once it had been validated. I also note that this > advice was in the draft in -19 when the full hash was used. >=20 > To be honest, I'm not entirely convinced that this advice is = sufficient, > but I don't have a complete analysis either way. However, I do think = it's > clear that the text in the draft is confusing. >=20 > Thoughts? > -Ekr >=20 --Apple-Mail=_C5E6AA90-9E9F-40CC-A129-966779840EB9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 All,

The = cached-info draft got all the way to the IESG and then we receive a = couple of comments that require we bring the draft back to the WG to = discuss.

spt

Begin forwarded = message:

From: = Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
Subject: = Re: Cached = Info
Date: = February 23, 2016 at 12:34:31 = GMT+9
To: = Sean Turner <TurnerS@ieca.com>, = Eric Rescorla <ekr@rtfm.com>, Martin Thomson <martin.thomson@gmail.com>, "Stephen ie>" <stephen.farrell@cs.tcd.ie>
Cc: = Antoine Delignat-Lavaud <antdl@microsoft.com>

Some corrections:

Dear All,

I took a quick look at = cached-info at Ekr=E2=80=99 prodding, who was worried about key = synchronization-style attacks (Ekr=E2=80=99s original email is a the = bottom of this email.)
My conclusion is that the = use of a 4-byte hash is unnecessarily fragile.
The = attacks are not super-serious, but the following scenario looks = bad.
Maybe I got something wrong about the spec, so = do tell me if I did.

Suppose that the client uses client certificates (or = channelID/token binding) to login to all websites.
The client=E2=80=99s authentication credential is bound to = the current handshake transcript.
If the transcript = does not contain the server certificate, then a malicious server may be = able
to forward a credential sent by the client to = the malicious server to a different server.
This = kind of credential forwarding attack enables certain kinds of = impersonation (see Triple Handshake)

In Cached-Info, the transcript includes = a 32-bit hash of the certificate and some signature or RSA encryption = that uses the certificate signing/encryption key.
To = mount the attack described above, the attacker would first need to find = a certificate that collides with the honest server certificate = hash.
You can imagine the attacker generating 2^32 = self-signed certificates until the collision is found, this is not = hard.
Next, the attacker still has to match the = parts of the transcript that use the server=E2=80=99s public key (if = any).
The client could maybe choose the public key = to match that of the server, or carefully choose the RSA signing key to = create a signature value that matches that of the real server = etc.
There may be other attacks where the attacker = uses a static ECDH ciphersuite, and so does not need to sign = anything.

So = now, the honest client C connects to malicious server M that has a = self-signed cert (for M).
C accepts the cert (for = M) and agrees to use certificate/token-bound authentication at = M.
M can then forward the credential and signature = to S, which will accept it.
M would not control the = keys between M and S (since it used S=E2=80=99s public key.)
But if C is using a browser, then C=E2=80=99s window is at = M=E2=80=99s origin, so M can inject 
data into = the connection which will then be forwarded to S, as if the = authenticated user C intended to send it to M.

Perhaps the above attack is not very = worrisome to some people, but the silly
bit is that = accepting this risk is completely unnecessary. The client = and 
server could simply use the full SHA-256 = hash for the certificate and the
client would have = a hard time creating a colliding certificate.

Best,
Karthik
<= div>

=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
Ekr=E2=80=99s original email
=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94

Folks,

I've been thinking over the cached-info draft, and I'm not = convinced
that the security analysis is = right.

In the = current design, the client sends a truncated 32-bit hash
of what it believes the server's certificate is. If that = matches
the server's certificate, then the server = echoes that truncated
hash (if I'm reading it = correctly).

The = security considerations section claims:

   The use of the cached info = extension allows the server to send
  =  significantly smaller TLS messages.  Consequently, these = omitted
   parts of the messages are not = included in the transcript of the
  =  handshake in the TLS Finish message.  However, since the = client and
   the server communicate the = hash values of the cached data in the
  =  initial handshake messages the fingerprints are included in the = TLS
   Finish message.

But this isn't correct = with a short hash, since you're not strongly
binding = the hash into the handshake. And elsewhere the text claims
that the hash isn't relevant:

   If an attacker
   injects an incorrect fingerprint then two = outcomes are possible: (1)
   The = fingerprint does not relate to any cached state and the server
   has to fall back to a full exchange. (2) If the = attacker manages to
   inject a = fingerprint that refers to data the client has not cached
   then the exchange will fail later when the = client continues with the
   handshake = and aims to verify the digital signature.  The signature
   verification will fail since the public key = cached by the client will
   not = correspond to the private key that was used by server to sign = the
   message.

I think this is closer to the truth. = But consider the case where
an attacker convinces = the client to accept a certificate for
attacker.com but = with victim.com's = public key that *also*
hash the same fingerprint = as victim.com's = certificate. In that case,
you could end up with a = UKS between the client and victim.com
(where the client thinks = he's talking to attacker.com). What prevents
this (I = believe) is the text in Security Considerations:

   Clients MUST ensure that = they only cache information from legitimate
  =  sources.  For example, when the client populates the cache = from a TLS
   exchange then it must only = cache information after the successful
  =  completion of a TLS exchange to ensure that an attacker does = not
   inject incorrect information into = the cache.  Failure to do so allows
  =  for man-in-the-middle attacks.

If followed, this will stop the client = from accepting attacker.com's
bogus cert (because = he doesn't have the private key). Note, however, that
you have to follow it strictly. For instance, if you cache = after
False Start, then you are vulnerable to this = attack. Also, these
instructions seem really = counterintuitive, because naively you
would expect = to just be able to validate the server's cert and
store the hash once it had been validated. I also note that = this
advice was in the draft in -19 when the full = hash was used.

To be honest, I'm not entirely convinced that this advice is = sufficient,
but I don't have a complete analysis = either way. However, I do think it's
clear that the = text in the draft is confusing.

Thoughts?
-Ekr


= --Apple-Mail=_C5E6AA90-9E9F-40CC-A129-966779840EB9-- From nobody Tue Mar 8 00:24:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557B412D547 for ; Tue, 8 Mar 2016 00:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=bblfish-net.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 055_67nGNvbY for ; Tue, 8 Mar 2016 00:24:04 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A680812D546 for ; Tue, 8 Mar 2016 00:24:03 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id p65so16932273wmp.0 for ; Tue, 08 Mar 2016 00:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=FOQ5+LdqOT9+su4qneDSIBMD1t7fAFDXRbXTZVhCZRY=; b=YtCLRvWfyNy6WdE/GXjY2Nkrs3JKMtKWnp7XfsE34lD4cyegguomXU5+pKYYPKrark N8c+ljIYDj6K9vxl6cigZOpZyUgWure6BSpZLtGc6o74IBBi1Vxbk/VS6Euwg3zBMIdR 5yOoH9l8EGQerjKSsV5HWutQxcoKF582nZP3IqGPOsIpPYBgE7mJeFKrtRCQY5B3kFly l9F/3nCXunWsqXqxZhlJ1DogkNFNpVYLMYP6bCrPZaost6oGNLpCS181xor0iWl0B8h7 yEdP8Jl/ZwXwG7YnOow+5VwFN9cr5f7ih7w+uDkxcYW8/h7CV6M20f095fvV6+CDePYR ePIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=FOQ5+LdqOT9+su4qneDSIBMD1t7fAFDXRbXTZVhCZRY=; b=SXTz7B4pS1POHhCC1ljwsYyD735qq75yGwuOd5gwFQbsp3vILM8qucNJiVWkcO0qPW mzTHhgF1eU1shPXrgqmkbGzwqFGju/gdy2743aW57wqMud8OJS8LlLyuMeA2XVU/iDI1 eF8Btm5wxEeawNM4A54j9f6GCDujet8lASV08sn7OjZZ3lQq7yNxx7dzTdY39DXNjH0E ILgLExhWTBi5kwAcxtqtbVqpjQ+zFuftzjd47QWO79xh9ZXghxukN4cFUXqCPL0W76CY WytiAMEVXG8VbEr84z5askMRT2o9C5tpogCPgUgBBLVUNX3oiBMCjNHQ4Xl+5QBZDE/U CPsQ== X-Gm-Message-State: AD7BkJLK7rFTp/e++++z5x3v5L7nRYU4VwlcAMT1Gl3S1nzNW1BWyDEyvwtZGdQITfkV+Q== X-Received: by 10.28.176.133 with SMTP id z127mr18207150wme.66.1457425442140; Tue, 08 Mar 2016 00:24:02 -0800 (PST) Received: from [192.168.0.2] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net. [86.21.242.52]) by smtp.gmail.com with ESMTPSA id e4sm2138532wma.10.2016.03.08.00.24.00 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Mar 2016 00:24:01 -0800 (PST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Tue, 8 Mar 2016 08:22:19 +0000 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] Generalising DN's to SAN and IAN in TLS1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 08:24:06 -0000 Hi, I was reading with interest M. Thomson and M. Bishop's "Reactive Certificate-Based Client Authentication" draft RFC [1]. In the section 2.3 "The CERTIFICATE_REQUEST Frame" [[ CA-Count and Certificate-Authorities: "Certificate-Authorities" is a series of distinguished names of acceptable certificate authorities, represented in DER-encoded [X690] format. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space. The number of such structures is given by the 16-bit "CA-Count" field, which MAY be zero. If the "CA-Count" field is zero, then the client MAY send any certificate that meets the rest of the selection criteria in the "CERTIFICATE_REQUEST", unless there is some external arrangement to the contrary. ]] Would it not be possible to extend that so that one could also pass issuer Alternative Names, and not just DNs? Using DNs made sense when it was thought that LDAP and X500 would end up being the protocols for global directories. This turned out not to be the case. It turned out that DNs were a special case of what could be termed a URI (even though DNs are not in URI format). And many (most?) URIs can refer to agents, least but not last http(s) URLs (See the WebID spec [2] for a nice diagram of how this works conceptually and the WebID-TLS spec for one way this can be tied to TLS [3]). If TLS1.3 could start moving away from sole reliance on DNs this would open quite a lot of possibilities, including the ability to build institutional Webs of trust for CAs (ie trust anchors could list CAs by reference at one or more levels of indirection), and CAs could also describe themselves at their URI. Those last two paragraphs are just hints of some possibilities that could emerge from moving away from DNs that I can think of. Others members of this group will certainly find other possibilities. In any case it seems that the time for DNs is passed, and that one should perhaps move away from reliance on those and generalise this part of TLS. Henry [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ From nobody Tue Mar 8 00:30:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F97112D560 for ; Tue, 8 Mar 2016 00:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbUcVNDFZffD for ; Tue, 8 Mar 2016 00:30:47 -0800 (PST) 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 A2FF812D54C for ; Tue, 8 Mar 2016 00:30:47 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id h129so6325536ywb.1 for ; Tue, 08 Mar 2016 00:30:47 -0800 (PST) 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=dfAhUr9ogJWS6SX3QFZGOBXSx1okIOWpBEnRAPyeDXA=; b=d6wYokZrY6W+xy8fq7vKyG/ya7twFk8GqjkTh4Be86Gdw5XDHM9pR6BVvWZcxrpQbr VDdFsd9cvxUDXqE7jJIuWdhRHyMtvtj94Y1dzBhtOktep6FUV76LUsVetKv4OHPqGbO2 AZA6/ACqq26xWubaavB3FwIzGcjIaC+QWgBs2/L7+pd0kzKTQwIYr0gDiRZwlgeZT7ID 9onO3M2agySGHVz0iv/ZG4oGBVHJBM8ZQ3GzHd4AohrfLUgz7BC2kQOJ+aNTsrHuAnzv ybOQDNuGKdOZd8EyujFGUshkHrghrUMFewwuyuDhQ1eKF3Xz+qHnhKP4xteB7FJDsPYz QSTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dfAhUr9ogJWS6SX3QFZGOBXSx1okIOWpBEnRAPyeDXA=; b=ZVSZ6WZLfwKg75u6D3Rx4ya95J0Zu6xoqDSaUQi989j7UA+UNVHpD/TNDs/Y62jLGr x66Y4rnvIh43dpO+beSw0waiPhVTas/KN0G6J1UJHxTY/uQU2ybbVkEOrLKy4OKv1qda 0ke1OoCFrYpJYfE3UJ/dqHNmfrKYNWMldP3NFnfPN4cYl7JvG4jGhmbdK4xxUA1JFKwi JG9iOcfbAN6uPAKn9pKWjCdhNFBlQV0rNBO0jF3XsfIVveVozWlBiJkCA3QRwSWR0Sny fjiAamupkUnaiDMWwBBC2qSVrTwQuz1iaJekR/unA1LIzeh2LaTu1ZLZrtZqCsUuow+2 h6Dw== X-Gm-Message-State: AD7BkJJ2ejW/cNiHX1iN3um3GyndmYPVQbmEJqgNpH70vDICtTR1MqWnQVR4dL9I3MLvIKHbJM6z+X1paOqorw== X-Received: by 10.129.79.209 with SMTP id d200mr13536459ywb.115.1457425846905; Tue, 08 Mar 2016 00:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 8 Mar 2016 00:30:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 8 Mar 2016 00:30:07 -0800 Message-ID: To: Henry Story Content-Type: multipart/alternative; boundary=001a114bbc96e45c1e052d8565ac Archived-At: Cc: "" Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 08:30:49 -0000 --001a114bbc96e45c1e052d8565ac Content-Type: text/plain; charset=UTF-8 CertificateRequest already allows you to pass an arbitrary number of extensions by OID. http://tlswg.github.io/tls13-spec/#certificate-request What more do you think you need? -Ekr On Tue, Mar 8, 2016 at 12:22 AM, Henry Story wrote: > Hi, > > > I was reading with interest M. Thomson and M. Bishop's > "Reactive Certificate-Based Client Authentication" draft RFC [1]. > In the section 2.3 "The CERTIFICATE_REQUEST Frame" > > [[ > CA-Count and Certificate-Authorities: "Certificate-Authorities" is a > series of distinguished names of acceptable certificate > authorities, represented in DER-encoded [X690] format. These > distinguished names may specify a desired distinguished name for a > root CA or for a subordinate CA; thus, this message can be used to > describe known roots as well as a desired authorization space. > The number of such structures is given by the 16-bit "CA-Count" > field, which MAY be zero. If the "CA-Count" field is zero, then > the client MAY send any certificate that meets the rest of the > selection criteria in the "CERTIFICATE_REQUEST", unless there is > some external arrangement to the contrary. > ]] > > Would it not be possible to extend that so that one could also pass > issuer Alternative Names, and not just DNs? > > Using DNs made sense when it was thought that LDAP and X500 would > end up being the protocols for global directories. This turned out > not to be the case. It turned out that DNs were a special case of > what could be termed a URI (even though DNs are not in URI format). > And many (most?) URIs can refer to agents, least but not last > http(s) URLs (See the WebID spec [2] for a nice diagram of how this > works conceptually and the WebID-TLS spec for one way this can be tied > to TLS [3]). > > If TLS1.3 could start moving away from sole reliance on DNs this > would open quite a lot of possibilities, including the ability to > build institutional Webs of trust for CAs (ie trust anchors could > list CAs by reference at one or more levels of indirection), and CAs > could also describe themselves at their URI. > > Those last two paragraphs are just hints of some possibilities that > could emerge from moving away from DNs that I can think of. Others > members of this group will certainly find other possibilities. > > In any case it seems that the time for DNs is passed, and that > one should perhaps move away from reliance on those and generalise > this part of TLS. > > Henry > > > > [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 > [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview > [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114bbc96e45c1e052d8565ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
CertificateRequest already allows you to pass an arbitrary= number of
extensions by OID.


What more d= o you think you need?

-Ekr


On Tue, Mar 8, 2016 at 12:= 22 AM, Henry Story <henry.story@bblfish.net> wrote:
Hi,


=C2=A0 I was reading with interest M. Thomson and M. Bishop's
"Reactive Certificate-Based Client Authentication" draft RFC [1].=
In the section 2.3 "The CERTIFICATE_REQUEST Frame"

[[
=C2=A0 =C2=A0 =C2=A0 CA-Count and Certificate-Authorities:=C2=A0 "Cert= ificate-Authorities" is a
=C2=A0 =C2=A0 =C2=A0 series of distinguished names of acceptable certificat= e
=C2=A0 =C2=A0 =C2=A0 authorities, represented in DER-encoded [X690] format.= =C2=A0 These
=C2=A0 =C2=A0 =C2=A0 distinguished names may specify a desired distinguishe= d name for a
=C2=A0 =C2=A0 =C2=A0 root CA or for a subordinate CA; thus, this message ca= n be used to
=C2=A0 =C2=A0 =C2=A0 describe known roots as well as a desired authorizatio= n space.
=C2=A0 =C2=A0 =C2=A0 The number of such structures is given by the 16-bit &= quot;CA-Count"
=C2=A0 =C2=A0 =C2=A0 field, which MAY be zero.=C2=A0 If the "CA-Count&= quot; field is zero, then
=C2=A0 =C2=A0 =C2=A0 the client MAY send any certificate that meets the res= t of the
=C2=A0 =C2=A0 =C2=A0 selection criteria in the "CERTIFICATE_REQUEST&qu= ot;, unless there is
=C2=A0 =C2=A0 =C2=A0 some external arrangement to the contrary.
]]

Would it not be possible to extend that so that one could also pass
issuer Alternative Names, and not just DNs?

Using DNs made sense when it was thought that LDAP and X500 would
end up being the protocols for global directories. This turned out
not to be the case. It turned out that DNs were a special case of
what could be termed a URI (even though DNs are not in URI format).
And many (most?) URIs can refer to agents, least but not last
http(s) URLs (See the WebID spec [2] for a nice diagram of how this
works conceptually and the WebID-TLS spec for one way this can be tied
to TLS [3]).

If TLS1.3 could start moving away from sole reliance on DNs this
would open quite a lot of possibilities, including the ability to
build institutional Webs of trust for CAs (ie trust anchors could
list CAs by reference at one or more levels of indirection), and CAs
could also describe themselves at their URI.

Those last two paragraphs are just hints of some possibilities that
could emerge from moving away from DNs that I can think of. Others
members of this group will certainly find other possibilities.

In any case it seems that the time for DNs is passed, and that
one should perhaps move away from reliance on those and generalise
this part of TLS.

Henry



[1] https://tools.ietf.org/html/draft= -thomson-http2-client-certs-01
[2] https://www.w3.org/2005/Incubator= /webid/spec/identity/#overview
[3] https://www.w3.org/2005/Incubator/webid/spec/tl= s/

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

--001a114bbc96e45c1e052d8565ac-- From nobody Tue Mar 8 00:38:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7712D554 for ; Tue, 8 Mar 2016 00:38:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=bblfish-net.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vd3fY-49GE0u for ; Tue, 8 Mar 2016 00:38:38 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2415B12D54E for ; Tue, 8 Mar 2016 00:38:38 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id l68so17308727wml.1 for ; Tue, 08 Mar 2016 00:38:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=TrJ8JbRlaiMo7M/XQ4cJRnPeYl4kgUVrRjrCHx5f9Hk=; b=jdfhO/Dqy8bAkS82s23F/T8iRgO6PMUAe4k02RDtsSl2k/jQFlS7W+OaXtWwrZ/uJW q0fAyPNsBiQynqVeBnCHE4LGAQAXx5/BjjM7qU5YSXIsWz1ja1MIrg5SUlLQItFw53uJ etok8jMkTsBKM2CRlIo5id8A02wpHs3HLEK9T3pZy1X0YV+KGe40A/TJXRwRnkIplyu5 kQV77TzSnVSdjzGs85IIITD67Bkc39bCxGk7vCXiEBumYhRPLmmqewLbnrcKoYPkCe0c /2xhR4erqj+baPUdyGWiylKhQSmX6GDGFjS6Fbo6jM+BdSxueuqDORbdm5l3CAXtUjZ3 j2dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=TrJ8JbRlaiMo7M/XQ4cJRnPeYl4kgUVrRjrCHx5f9Hk=; b=Qvq4fV6vJbTh/LK3nvvKXZmojYyef0weWla4kg/BZgOTzAE8eOSmqeaILRYC3PM0EB fPBb19h5ZE7OB6FxPXHI9cL9EdOJcIdcQfNiIrLzBBXsS3ujSxEmLdgAbkfLhAZGFLAK aksRVhe40/37Md0cH3cgW5wtiwV2wLLm2P0stxWptwy4MmsBpvwcl2qY2THABzJZr5o4 yDGZoED6baGBzIgi4KvAzUrBUg0TWiY+0+I04UlJ7WIE34kATKGrY/5AfalL3UOznEXK HvO9v28DDIrIfE4l+M5QB5hRq/DFy36q+VsYAIbnaV7NH1LlQbFObbYITVGVLn7yFrXu pZZQ== X-Gm-Message-State: AD7BkJLxfGCx6P6dKoCPWXuk2Gm0Sh5bUezLpb3WyYEZDpWQhw5/M4eNL//zBZghrtQrGQ== X-Received: by 10.194.24.193 with SMTP id w1mr27321715wjf.33.1457426316647; Tue, 08 Mar 2016 00:38:36 -0800 (PST) Received: from [192.168.0.2] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net. [86.21.242.52]) by smtp.gmail.com with ESMTPSA id fv6sm1768807wjc.12.2016.03.08.00.38.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Mar 2016 00:38:35 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C4F432D6-63DB-406B-A0B7-93CE418DC79F" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Henry Story In-Reply-To: Date: Tue, 8 Mar 2016 08:38:56 +0000 Message-Id: References: To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 08:38:40 -0000 --Apple-Mail=_C4F432D6-63DB-406B-A0B7-93CE418DC79F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Mar 2016, at 08:30, Eric Rescorla wrote: >=20 > CertificateRequest already allows you to pass an arbitrary number of > extensions by OID. >=20 > http://tlswg.github.io/tls13-spec/#certificate-request = >=20 > What more do you think you need? If that would allow one to specify that certificates that match a = specific IAN are acceptable and if those get implemented widely, then that's what I was looking for.=20 Thanks. Look forward to that :-) Henry >=20 > -Ekr >=20 >=20 > On Tue, Mar 8, 2016 at 12:22 AM, Henry Story > wrote: > Hi, >=20 >=20 > I was reading with interest M. Thomson and M. Bishop's > "Reactive Certificate-Based Client Authentication" draft RFC [1]. > In the section 2.3 "The CERTIFICATE_REQUEST Frame" >=20 > [[ > CA-Count and Certificate-Authorities: "Certificate-Authorities" = is a > series of distinguished names of acceptable certificate > authorities, represented in DER-encoded [X690] format. These > distinguished names may specify a desired distinguished name for = a > root CA or for a subordinate CA; thus, this message can be used = to > describe known roots as well as a desired authorization space. > The number of such structures is given by the 16-bit "CA-Count" > field, which MAY be zero. If the "CA-Count" field is zero, then > the client MAY send any certificate that meets the rest of the > selection criteria in the "CERTIFICATE_REQUEST", unless there is > some external arrangement to the contrary. > ]] >=20 > Would it not be possible to extend that so that one could also pass > issuer Alternative Names, and not just DNs? >=20 > Using DNs made sense when it was thought that LDAP and X500 would > end up being the protocols for global directories. This turned out > not to be the case. It turned out that DNs were a special case of > what could be termed a URI (even though DNs are not in URI format). > And many (most?) URIs can refer to agents, least but not last > http(s) URLs (See the WebID spec [2] for a nice diagram of how this > works conceptually and the WebID-TLS spec for one way this can be tied > to TLS [3]). >=20 > If TLS1.3 could start moving away from sole reliance on DNs this > would open quite a lot of possibilities, including the ability to > build institutional Webs of trust for CAs (ie trust anchors could > list CAs by reference at one or more levels of indirection), and CAs > could also describe themselves at their URI. >=20 > Those last two paragraphs are just hints of some possibilities that > could emerge from moving away from DNs that I can think of. Others > members of this group will certainly find other possibilities. >=20 > In any case it seems that the time for DNs is passed, and that > one should perhaps move away from reliance on those and generalise > this part of TLS. >=20 > Henry >=20 >=20 >=20 > [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 = > [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview = > [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ = >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_C4F432D6-63DB-406B-A0B7-93CE418DC79F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 8 Mar 2016, at 08:30, Eric Rescorla <ekr@rtfm.com> = wrote:

CertificateRequest already allows you to pass an = arbitrary number of
extensions by OID.

http://tlswg.github.io/tls13-spec/#certificate-request

What= more do you think you need?

If that would allow one to specify that = certificates that match a specific
IAN are acceptable and if = those get implemented widely, then that's
what I was looking = for. 

Thanks. Look forward to = that :-)

Henry


-Ekr


On Tue, = Mar 8, 2016 at 12:22 AM, Henry Story <henry.story@bblfish.net> wrote:
Hi,


  I was reading with interest M. Thomson and M. Bishop's
"Reactive Certificate-Based Client Authentication" draft RFC [1].
In the section 2.3 "The CERTIFICATE_REQUEST Frame"

[[
      CA-Count and Certificate-Authorities:  = "Certificate-Authorities" is a
      series of distinguished names of acceptable = certificate
      authorities, represented in DER-encoded [X690] = format.  These
      distinguished names may specify a desired = distinguished name for a
      root CA or for a subordinate CA; thus, this message = can be used to
      describe known roots as well as a desired = authorization space.
      The number of such structures is given by the = 16-bit "CA-Count"
      field, which MAY be zero.  If the "CA-Count" = field is zero, then
      the client MAY send any certificate that meets the = rest of the
      selection criteria in the "CERTIFICATE_REQUEST", = unless there is
      some external arrangement to the contrary.
]]

Would it not be possible to extend that so that one could also pass
issuer Alternative Names, and not just DNs?

Using DNs made sense when it was thought that LDAP and X500 would
end up being the protocols for global directories. This turned out
not to be the case. It turned out that DNs were a special case of
what could be termed a URI (even though DNs are not in URI format).
And many (most?) URIs can refer to agents, least but not last
http(s) URLs (See the WebID spec [2] for a nice diagram of how this
works conceptually and the WebID-TLS spec for one way this can be = tied
to TLS [3]).

If TLS1.3 could start moving away from sole reliance on DNs this
would open quite a lot of possibilities, including the ability to
build institutional Webs of trust for CAs (ie trust anchors could
list CAs by reference at one or more levels of indirection), and CAs
could also describe themselves at their URI.

Those last two paragraphs are just hints of some possibilities that
could emerge from moving away from DNs that I can think of. Others
members of this group will certainly find other possibilities.

In any case it seems that the time for DNs is passed, and that
one should perhaps move away from reliance on those and generalise
this part of TLS.

Henry



[1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01=
[2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview=
[3] https://www.w3.org/2005/Incubator/webid/spec/tls/

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


= --Apple-Mail=_C4F432D6-63DB-406B-A0B7-93CE418DC79F-- From nobody Tue Mar 8 08:53:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C89412D835 for ; Tue, 8 Mar 2016 08:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUrEinToIhDh for ; Tue, 8 Mar 2016 08:53:20 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD6E12D811 for ; Tue, 8 Mar 2016 08:53:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6570; q=dns/txt; s=iport; t=1457456000; x=1458665600; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GPToE96h+Y+DsMnyeK5XMMyBHWjCDwHaicre/aPDAg8=; b=AwUsLza5zuYnRkSyQRtIsoS1PPi9h4tPRKnWfAh/dexc3frtHi7O55Nr cMvZBh2GErRMO6lr3wDRrFHJVdIXNDwt8zZ+w8NywQYRJ83AzB4ejvZzL eZi8YrG9GleNryJXjoEbF6WmwCUBjOHxjuMty7NgZEjMS6eDHDnRoOKfr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/BQC3At9W/49dJa1cgzqBPwa6VoFph?= =?us-ascii?q?g8CHIEoORMBAQEBAQEBZCeEQQEBAQMBIxE3BwcMBAIBCA4DBAEBAQICIwMCAgI?= =?us-ascii?q?wFAEICAIEDgUIE4gBCK57jyMBAQEBAQEBAQEBAQEBAQEBAQEBAQEVe4UchEKEU?= =?us-ascii?q?IJqgToFjTCJegGIUoUUjwKOVQEiAT+DZGqJAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.22,557,1449532800"; d="scan'208";a="84479971" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2016 16:53:19 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u28GrJm4002662 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Mar 2016 16:53:19 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Mar 2016 11:53:18 -0500 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1104.009; Tue, 8 Mar 2016 11:53:18 -0500 From: "Scott Fluhrer (sfluhrer)" To: Hubert Kario Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AdF1YX6hVOviuew0z0qjJ4Wpjso/6gAOBziAACF3k4AAAP03AACdU9uAAAV12dAABkTjAAAjYV5w Date: Tue, 8 Mar 2016 16:53:18 +0000 Message-ID: References: <20160303152945.18296912.40009.55386@ll.mit.edu> <5209728.bPpGhxeIz8@pintsize.usersys.redhat.com> <720dc8ee9c9a49209c1e76271d0dd403@XCH-RCD-006.cisco.com> <1780021.yiLHCh9FZ9@pintsize.usersys.redhat.com> In-Reply-To: <1780021.yiLHCh9FZ9@pintsize.usersys.redhat.com> 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: [10.98.2.61] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 16:53:22 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEh1YmVydCBLYXJpbyBbbWFp bHRvOmhrYXJpb0ByZWRoYXQuY29tXQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA3LCAyMDE2IDEy OjE4IFBNDQo+IFRvOiBTY290dCBGbHVocmVyIChzZmx1aHJlcikNCj4gQ2M6IHRsc0BpZXRmLm9y ZzsgTmlrb3MgTWF2cm9naWFubm9wb3Vsb3M7IEhhbm5vIELDtmNrOyBCbHVtZW50aGFsLCBVcmkg LQ0KPiAwNTUzIC0gTUlUTEwNCj4gU3ViamVjdDogUmU6IFtUTFNdIFJTQS1QU1MgaW4gVExTIDEu Mw0KPiANCj4gT24gTW9uZGF5IDA3IE1hcmNoIDIwMTYgMTU6MjM6MTcgU2NvdHQgRmx1aHJlciB3 cm90ZToNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBIdWJl cnQgS2FyaW8gW21haWx0bzpoa2FyaW9AcmVkaGF0LmNvbV0NCj4gPiA+IFNlbnQ6IE1vbmRheSwg TWFyY2ggMDcsIDIwMTYgNjo0MyBBTQ0KPiA+ID4gVG86IHRsc0BpZXRmLm9yZw0KPiA+ID4gQ2M6 IFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKTsgTmlrb3MgTWF2cm9naWFubm9wb3Vsb3M7IEhhbm5v IELDtmNrOw0KPiA+ID4gQmx1bWVudGhhbCwgVXJpIC0gMDU1MyAtIE1JVExMDQo+ID4gPiBTdWJq ZWN0OiBSZTogW1RMU10gUlNBLVBTUyBpbiBUTFMgMS4zDQo+ID4gPg0KPiA+ID4gT24gRnJpZGF5 IDA0IE1hcmNoIDIwMTYgMTM6NDk6MTEgU2NvdHQgRmx1aHJlciB3cm90ZToNCj4gPiA+DQo+ID4g PiA+IEkgYWdyZWUgd2l0aCBIYW5ubzsgaWYgd2UncmUgaW50ZXJlc3RlZCBpbiBkZWZlbmRpbmcg YWdhaW5zdCBhDQo+ID4gPiA+IFF1YW50dW0gQ29tcHV0ZXIsIHBvc3QgUXVhbnR1bSBhbGdvcml0 aG1zIGFyZSB0aGUgd2F5IHRvIGdvDQo+ID4gPg0KPiA+ID4NCj4gPiA+IGV4Y2VwdCB0aGF0IHVz aW5nIFJTQSBrZXlzIG5lYXJseSBhbiBvcmRlciBvZiBtYWduaXR1ZGUgbGFyZ2VyIHRoYW4NCj4g PiA+IHRoZSBiaWdnZXN0IEVDQyBjdXJ2ZSB0aGF0J3Mgd2lkZWx5IHN1cHBvcnRlZCAoc2VjcDM4 NCkgaXMgdGhlDQo+ID4gPiBjdXJyZW50IHJlY29tbWVuZGVkIG1pbmltdW0gYnkgRU5JU0EgYW5k IGxvbmcgdGVybSBtaW5pbXVtIGJ5DQo+IE5JU1QNCj4gPiA+ICgzMDcyKS4NCj4gPiA+IFVzaW5n IGtleXMgNSB0aW1lcyBsYXJnZXIgc3RpbGwgaXMgbm90IGltcG9zc2libGUsIHNvIHdoaWxlIGl0 IG1heQ0KPiA+ID4gbm90IGJ1eSB1cyBleHRyYSAyMCB5ZWFycyBhZnRlciBFQ0MgaXMgYnJva2Vu LCAxMCB5ZWFycyBpcyBub3QNCj4gPiA+IGltcG9zc2libGUgYW5kIDUgaXMgYWxtb3N0IGNlcnRh aW4gKGlmIE1vb3JlJ3MgbGF3IGhvbGRzIGZvcg0KPiA+ID4gcXVhbnR1bSBjb21wdXRlcnMpLg0K PiA+ID4gSXQncyBub3QgbXVjaCwgYnV0IGl0IG1heSBiZSBlbm91Z2ggdG8gbWFrZSBhIGRpZmZl cmVuY2UuDQo+ID4NCj4gPg0KPiA+IElmIHdlIGJlbGlldmUgdGhhdCBncm93dGggaW4gTW9vcmUn cyBsYXcgd2lsbCBiZSBhY2N1cmF0ZSBmb3IgUXVhbnR1bQ0KPiA+IENvbXB1dGVycywgdGhlbiBu byBvbmUgaGFzIHRvIHdvcnJ5IGFib3V0IFF1YW50dW0gQ29tcHV0ZXJzIGZvciB0aGUNCj4gPiBu ZXh0IG1pbGxlbm5pYS4NCj4gDQo+ID4gSW4gMjAwMSwgYSBRdWFudHVtIENvbXB1dGVyIGZhY3Rv cmVkIGEgNCBiaXQgbnVtYmVyLiAgSW4gMjAxNCwgdGhlDQo+ID4gZmFjdG9yaXphdGlvbiBvZiBh IDE2IGJpdCBudW1iZXIgd2FzIGFubm91bmNlZCAoaG93ZXZlciwgdGhlDQo+ID4gZmFjdG9yaXph dGlvbiB1c2VkIGEgc3BlY2lhbCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZmFjdG9ycywgc28g SQ0KPiA+IGRvbuKAmXQgdGhpbmsgaXQgY291bnRzIGFzIGEgZ2VuZXJhbCBmYWN0b3JpemF0aW9u LCBidXQgbGV0J3MgaWdub3JlDQo+ID4gdGhhdCBmb3Igbm93KS4gIFRoYXQncyBub3QgdG9vIGZh ciBvZmYgZnJvbSBhIE1vb3JlJ3MgbGF3IHR5cGUNCj4gPiBleHBhbnNpb24uICBJZiB0aGlzIHJh dGUgY29udGludWVzLCB3ZWxsIHNlZSB0aGUgZmlyc3QgMTAyNCBiaXQNCj4gPiBmYWN0b3JpemF0 aW9uIGNpcmNhIHRoZSB5ZWFyIDMxMDAgQUQgKGFrYSBDRSkuDQo+IA0KPiBHSUdPLCB5b3UncmUg ZXh0cmFwb2xhdGluZyBmcm9tIHR3byBkYXRhIHBvaW50cyB3aGVuIHdlIGhhdmUgbm8gaWRlYSBo b3cNCj4gZmFzdCBvciBob3cgc2xvdyB3aWxsIGJlIHRoZSBwcm9ncmVzcyBpbiBnZW5lcmFsDQoN CkFjdHVhbGx5LCB0aGF0IHNvcnQgb2YgbG9naWMgaXMgd2hhdCB5b3UncmUgdXNpbmcuICBZb3Ug aGF2ZSBubyBpZGVhIGhvdyBmYXN0IG9yIHNsb3cgd2lsbCB0aGUgcHJvZ3Jlc3MgYmUgaW4gZ2Vu ZXJhbCwgaG93ZXZlciB5b3UgYXNzdXJlIHVzIHRoYXQgaXQnbGwgYmUgdGFrZSBzaWduaWZpY2Fu dGx5IGxvbmdlciB0byBjcmVhdGUgYSBRdWFudHVtIENvbXB1dGVyIHRoYXQgY2FuIGJyZWFrIGxh cmdlIGtleSBSU0EgdGhhbiBpdCB3b3VsZCBiZSB0byBicmVhayBFQ0MuDQoNCklmIHlvdSBkb24n dCBiZWxpZXZlIHRoZSBvdmVyc2ltcGxpZmllZCBsb2dpYyBJIHNob3dlZCBhYm92ZSwgeW91IG11 c3QgYXNzdW1lIHRoYXQsIGF0IHNvbWUgcG9pbnQgaW4gdGhlIGZ1dHVyZSwgdGhhdCBRdWFudHVt IENvbXB1dGVycyBtdXN0IGluY3JlYXNlIG11Y2ggbW9yZSByYXBpZGx5IHRoYW4gYSBzaW1wbGUg TW9vcmUncyBsYXcgcHJlZGljdGlvbiAoYmFzZWQgb24gc2ltcGxlIGV4dHJhcG9sYXRpb24gZnJv bSB3aGF0IHdlIGhhdmUgbm93KS4gIEhvd2V2ZXIsIHlvdSBhc3N1bWUgdGhhdCB0aGlzIHJhcGlk IGV4cGFuc2lvbiB3aWxsIHN0b3AgYXQgYSBwb2ludCBpbnN1ZmZpY2llbnQgdG8gYnJlYWsgbGFy Z2Uga2V5IFJTQS4NCg0KPiANCj4gYW5kIEkgbWVhbnQgTW9vcmUncyAxOC0yNCBtb250aHMgcGVy IGRvdWJsZSwgbm90IHRoZSBpZGVhIG9mIGV4cG9uZW50aWFsDQo+IGdyb3d0aCBpbiBnZW5lcmFs OyBpbiBvdGhlciB3b3JkcyBQLTI1NiBzdWNjdW1iaW5nIHRvIHF1YW50dW0gY29tcHV0ZXJzDQo+ IDQgdG8gOCB5ZWFycyBiZWZvcmUgMTAyNCBiaXQgUlNBDQoNCkFzIHlvdSBhcmUgbWFraW5nIGFz c2VydGlvbnMgb24gdGhlIGxpa2VseSBwcm9ncmVzcyBpbiBidWlsZGluZyBRdWFudHVtIENvbXB1 dGVycywgSSBoYXZlIHRvIGFzazogd2hhdCBleHBlcnRpc2UgZG8geW91IGhhdmUgaW4gdGhlIGRl c2lnbiBhbmQgY29uc3RydWN0aW9uIG9mIFF1YW50dW0gQ29tcHV0ZXJzPyAgSG93IHVwIHRvIGRh dGUgYXJlIHlvdSBvbiB0aGUgdGhlb3J5PyAgQXJlIHlvdSBmYW1pbGlhciB3aXRoIFRvZmZvbGkg Z2F0ZXMgb3IgQ2xpZmZvcmQgZ2F0ZXM/ICBIb3cgYWJvdXQgbWFnaWMgc3RhdGUgZmFjdG9yaWVz IFtyZWFsIG5hbWVdPw0KDQpJJ20gbm90IGFuIGV4cGVydCBpbiB0aGlzIGZpZWxkIGVpdGhlciAt IGhvd2V2ZXIsIEkgaGF2ZSB0YWxrZWQgdG8gZXhwZXJ0czsgdGhlIG9waW5pb25zIEkndmUgaGVh cmQgaXMgdGhhdCBhIHJlYWxpc3RpYyBjb21wdXRlciB0aGF0IGNhbiBicmVhayBSU0EgaXMgcGVy aGFwcyAxMC0xNSB5ZWFycyBvZmYgKGVzdGltYXRlcyBkaWZmZXIgYmV0d2VlbiBleHBlcnRzKTsg b25jZSBpdCdzIGJlZW4gYnVpbHQsIHNjYWxpbmcgaXQgdXAgaXNuJ3QgbGlrZWx5IHRvIGJlIG11 Y2ggb2YgYW4gaXNzdWUgKGxhcmdlbHkgYmVjYXVzZSB3ZSBhbHJlYWR5IGtub3cgaG93IHRvIGV0 Y2ggcXVpdGUgbGFyZ2UgY29uc3RydWN0aW9uIG9udG8gU2lsaWNvbikuICBJbiBlc3NlbmNlLCB0 aGUgcHJvYmxlbSBpc24ndCB0aGUgYWN0dWFsIGNvbnN0cnVjdGlvbiBwcm9jZXNzLCBidXQga25v d2luZyB3aGF0IHRvIGJ1aWxkLg0KDQpNaWdodCB0aGV5IGJlIHdyb25nPyAgTWlnaHQgdGhleSBi ZSBvdmVyb3B0aW1pc3RpYyBhYm91dCB0aGVpciB0ZWNobm9sb2d5PyAgTWlnaHQgdGhlcmUgYmUg YSBwcmFjdGljYWwgYnVtcCBpbiB0aGUgcm9hZCB0aGF0IHRoZXkgZG9uJ3QgZm9yZXNlZSB5ZXQ/ ICBQZXJoYXBzOyBob3dldmVyIGl0IHdvdWxkbid0IGFwcGVhciBwcnVkZW50IHRvIGFzc3VtZSB0 aGF0Lg0KDQpBbmQsIEkgd291bGQgYXJndWUgdGhhdCAxMC0xNSB5ZWFycyBpc24ndCB0aGF0IGZh ciBvZmYsIHNpbmNlIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQgc29tZW9uZSBzdG9yaW5nIHRoZSBl bmNyeXB0ZWQgZGF0YSBub3csIGFuZCBkZWNyeXB0aW5nIHRoZW0gbGF0ZXIuDQoNCg0KVGhlIGJv dHRvbSBsaW5lOiBhbSBJIHNheWluZyB0aGF0IHlvdSBzaG91bGRuJ3Qgc3RhcnQgc3VwcG9ydGlu ZyBsYXJnZSBrZXkgUlNBIGFzIGEgc2hvcnQgdGVybSBzb2x1dGlvbiwgaW4gdGhlIGhvcGVzIHRo YXQgaXQgbWlnaHQgZmVuZCBvZmYgYSBRdWFudHVtIENvbXB1dGVyIGZvciBhIGJpdD8gIE5vLCBh cyB0aGF0J3Mgbm90IGxpa2VseSB0byBiZSBoYXJtZnVsLCBnbyBhaGVhZCBhbmQga25vY2sgeW91 cnNlbGYgb3V0LiAgSG93ZXZlciwgSSBhbSBzYXlpbmcgdGhhdCBpdCB3b3VsZCBiZSBmb29saXNo IHRvIHByZXRlbmQgdGhhdCBpcyBhbnl0aGluZyBidXQgYSBzaG9ydHRlcm0gcGF0Y2ggYXQgYmVz dDsgaXQgbWlnaHQgZW5kIHVwIHByb3ZpZGluZyBubyBhZGRpdGlvbmFsIHByb3RlY3Rpb24uICBJ ZiB3ZSdyZSBpbnRlcmVzdGVkIGluIGEgbG9uZ2VyIHRlcm0gc29sdXRpb24sIHdlIHdvdWxkIG5l ZWQgdG8gZXZlbnR1YWxseSBnbyB3aXRoIHJlYWwgcG9zdHF1YW50dW0gY3J5cHRvZ3JhcGh5IChh bmQgSSB3b3VsZCBhcmd1ZSB0aGF0ICdldmVudHVhbGx5JyBpc24ndCB0aGF0IGZhciBpbiB0aGUg ZnV0dXJlKS4NCg0K From nobody Tue Mar 8 10:24:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A993812D96E for ; Tue, 8 Mar 2016 10:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcuKzK8u03A1 for ; Tue, 8 Mar 2016 10:24:49 -0800 (PST) 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 503A012D962 for ; Tue, 8 Mar 2016 10:24:46 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 8ADF42EBCF9; Tue, 8 Mar 2016 18:24:45 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u28IOhqp016341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Mar 2016 13:24:44 -0500 From: Hubert Kario To: "Scott Fluhrer (sfluhrer)" Date: Tue, 08 Mar 2016 19:24:37 +0100 Message-ID: <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.3-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <20160303152945.18296912.40009.55386@ll.mit.edu> <1780021.yiLHCh9FZ9@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2745060.CZmlZPFOIq"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 18:24:50 -0000 --nextPart2745060.CZmlZPFOIq Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 08 March 2016 16:53:18 Scott Fluhrer wrote: > > -----Original Message----- > > From: Hubert Kario [mailto:hkario@redhat.com] > > Sent: Monday, March 07, 2016 12:18 PM > > To: Scott Fluhrer (sfluhrer) > > Cc: tls@ietf.org; Nikos Mavrogiannopoulos; Hanno B=C3=B6ck; Blument= hal, > > Uri - 0553 - MITLL > > Subject: Re: [TLS] RSA-PSS in TLS 1.3 > >=20 > > On Monday 07 March 2016 15:23:17 Scott Fluhrer wrote: > >=20 > >=20 > > > In 2001, a Quantum Computer factored a 4 bit number. In 2014, > > > the > > > factorization of a 16 bit number was announced (however, the > > > factorization used a special relationship between the factors, so= > > > I > > > don=E2=80=99t think it counts as a general factorization, but let= 's > > > ignore > > > that for now). That's not too far off from a Moore's law type > > > expansion. If this rate continues, well see the first 1024 bit > > > factorization circa the year 3100 AD (aka CE). > >=20 > >=20 > > GIGO, you're extrapolating from two data points when we have no ide= a > > how fast or how slow will be the progress in general >=20 >=20 > Actually, that sort of logic is what you're using. You have no idea > how fast or slow will the progress be in general, however you assure > us that it'll be take significantly longer to create a Quantum > Computer that can break large key RSA than it would be to break ECC. No, I said that we have no reason to believe that quantum computers=20 won't follow exponential increase in number of qbits they can handle,=20= with the highest increase not exceeding doubling every year, but more=20= likely doubling every two years (as every other technological=20 development did till now). I'd really like to hear an expert that will say that building a 1,000=20= qbit QC will be just as easy as building a 100,000 qbit one. > If you don't believe the oversimplified logic I showed above, you mus= t > assume that, at some point in the future, that Quantum Computers must= > increase much more rapidly than a simple Moore's law prediction > (based on simple extrapolation from what we have now). However, you > assume that this rapid expansion will stop at a point insufficient to= > break large key RSA. I said that this exponential growth in quantum computers most likely=20= *won't* provide us 20 years of RSA/DH unbreakability after ECC falls.=20= How is that saying that RSA will not be broken by quantum computers? > >=20 > > and I meant Moore's 18-24 months per double, not the idea of > > exponential growth in general; in other words P-256 succumbing to > > quantum computers 4 to 8 years before 1024 bit RSA >=20 >=20 > As you are making assertions on the likely progress in building > Quantum Computers, I have to ask: what expertise do you have in the > design and construction of Quantum Computers? How up to date are you= > on the theory? Are you familiar with Toffoli gates or Clifford > gates? How about magic state factories [real name]? =20 > I'm not an expert in this field either - however, I have talked to > experts; the opinions I've heard is that a realistic computer that > can break RSA is perhaps 10-15 years off (estimates differ between > experts); once it's been built, scaling it up isn't likely to be much= > of an issue (largely because we already know how to etch quite large > construction onto Silicon). In essence, the problem isn't the actual= > construction process, but knowing what to build. RSA of what size? and what about ECC? Using currently known algorithms, to break 256 bit ECC you need 384 qbi= t=20 quantum computer To break 15360 bit RSA or DH you need 23040 qbit quantum computer. Assuming explosive growth of quantum computer sizes (doubling every=20 year), RSA of that size will be broken 6 years after the above ECC. Does that mean that ECC will fall in 4 to 6 years? > Might they be wrong? Might they be overoptimistic about their > technology? Might there be a practical bump in the road that they > don't foresee yet? Perhaps; however it wouldn't appear prudent to > assume that. =20 > And, I would argue that 10-15 years isn't that far off, since we need= > to worry about someone storing the encrypted data now, and decrypting= > them later. =20 Quantum Computers are all or nothing, you can't use a 256 qbit QC to=20= break 512 bit RSA, you need a 768 qbit QC to break it. Any smaller one=20= won't be more effective than classical computer. > The bottom line: am I saying that you shouldn't start supporting larg= e > key RSA as a short term solution, in the hopes that it might fend off= > a Quantum Computer for a bit? No, as that's not likely to be > harmful, go ahead and knock yourself out. However, I am saying that > it would be foolish to pretend that is anything but a shortterm patch= > at best; it might end up providing no additional protection. If > we're interested in a longer term solution, we would need to > eventually go with real postquantum cryptography (and I would argue > that 'eventually' isn't that far in the future). =20 I said quite explicitly that this is just a short term solution, 5 year= s=20 almost certainly, 10 years probably and 20 years being highly unlikely.= and 10 years is not nothing in academia, protocol design or deployment it buys little time, but it does buy time, nothing else does =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2745060.CZmlZPFOIq 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 iQIcBAABCgAGBQJW3xjlAAoJEJKo0bgB0vX1I5oP/2zxdRRlS0XdttyNMpCSZ+9i rmP+tCZyqxb9dynCreFOKVcazD3UVV/d8ffonipC8qyCEoN82/uJ5sXSLr1+qF7P 9W2j5fagssIfm9s/aiM62uxJGNkx78A+ynmjz9rfHmm4BMUhyxO4XJypcQ4Vneq4 QBrdULmcOCZVSdPiG+XJXsRyPsACjvmV3dtyUrohKx8jlG7W6zNDdjqtdWNt+gcm Pp8pFHdtt3lxotxm+0iLj7J9bHlN8XLai18QXYjeNNwTkAWlpmQfZRUquHVoYxpU 9MYVJy/Obv/eNiT53dq+om8Lalk2jCx6Gqgs0rEzldICRDJMDcwMh9IEAAr7Ygd0 knaZ/3948IBMergHRCKcZ/Kd23UU6QVBG5/sMlOI55V/bpWElKZirRp3ZkCMnzLL nNxrUajM5D4UURELpUM2QilwJLDULygUtgiZMubHiDYFL4dpOo+XMYUcSoMWL0XR PcCATJF2jztDxl8WVRQjjfmrNDe1CrZJ2SqgOStm9oiZJx1jqSRFvkHip1IMw5/O 5OwTUWAXJTLzgYrJrVNkw+2PON7Y3fWUwP2Q1Yo/EZJRHjeHTTT6/bZXiz3defNU pZg3C+PKUTlQGsd2ia/6KIO0mY7fPiIJUTXPGSVdtHHzzLaNkk0O2UX43ad+RmR+ fe6GjFl95G35++HAje6X =i3uJ -----END PGP SIGNATURE----- --nextPart2745060.CZmlZPFOIq-- From nobody Tue Mar 8 10:41:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBEB12D98B for ; Tue, 8 Mar 2016 10:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2OZEOla2o2C for ; Tue, 8 Mar 2016 10:41:33 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E39E12D988 for ; Tue, 8 Mar 2016 10:41:33 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 42044284DCB; Tue, 8 Mar 2016 18:41:32 +0000 (UTC) Date: Tue, 8 Mar 2016 18:41:32 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160308184131.GS10917@mournblade.imrryr.org> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <1780021.yiLHCh9FZ9@pintsize.usersys.redhat.com> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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, 08 Mar 2016 18:41:35 -0000 On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote: > No, I said that we have no reason to believe that quantum computers > won't follow exponential increase in number of qbits they can handle, > with the highest increase not exceeding doubling every year, but more > likely doubling every two years (as every other technological > development did till now). There's reason to be skeptical of such analogies. Moore's law was neither a theorem nor a law of nature. It was an observation about progress in feature-size shrink of silicon transistors. It is far from clear that evolution of silicon fabrication is a relevant model. -- Viktor. From nobody Tue Mar 8 11:56:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4D612D9E1 for ; Tue, 8 Mar 2016 11:56:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4rtIVq6JEnj for ; Tue, 8 Mar 2016 11:56:00 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D453312D8DC for ; Tue, 8 Mar 2016 11:55:59 -0800 (PST) Received: by mail-yk0-x230.google.com with SMTP id x17so11048716ykd.1 for ; Tue, 08 Mar 2016 11:55:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=CUX6so1Uj1OVDpvk4lpNsmqqVfydaH5WUKQEfxpulUY=; b=Fd+r1j8mkGaqTOBOHXdisHoSQf/8iQE4cEeTQ653+JrTLyWGRH51pbP0xN4nw4KqYb k5FRG8BoGtMHvj0utcS80S8Dhu0FmjXcupxkmteR8o6wMwcJ2IVmaot1vuLF5GBHy80Q 1DZyvKJAnrQB6InwsSYQq22IsJj321mzBRy1geFLWLRlD10UE1OJGudhmebJmdpHUokx n/hxIRzk9oFOcXBbWecMma178I1rRgRlkhU642890EuIsBPWKbsMRlqkm2Pz0Biwjhz3 jVZFV0o1mjQtEOM5hjfjcG6jSFU0YjBO8t4j7ZQMxb/8iO2WZAijF7webCxpx6YVfR1Q PTpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CUX6so1Uj1OVDpvk4lpNsmqqVfydaH5WUKQEfxpulUY=; b=c2Bu1qCUpBAydeVFfOOd2INaazYhfGtRBr/SgXn7ucTnJQ8bj1AqLISn0FzrjAHwAu ifNlBRXnhZydfORf1ZF3iWoj+MUeOAYSER3WjmzkV0QVfwaPJ4V21TpSfNj+NuYbzFm3 IUnzGU8CWO3DhQaWCzzMZAIWsUrIeI+bbrU8VW5e4c4Hs00KJccY+FODJ2y6aWPNPRH4 isUGzPg0cVAy2x7zctC+SjJZBdKjlvZ97UPshbDpWFPYb/Nq86ZHOPnvQxnZa8PCLyxZ H+KEzRHNN1XUvIyc65b1gf3oyfAF0PxuPOluyvzPUWpygEmxsUjZGuFquGjzBD2lYwNx vfag== X-Gm-Message-State: AD7BkJK1if9fyAofTEIr7Jw7bMaTuzMAXJM76cYB4Z7kfk4RssfGGStP4bOnB+EXMzd0khRQNpGacoWdPkaKmg== MIME-Version: 1.0 X-Received: by 10.37.93.69 with SMTP id r66mr7838630ybb.156.1457466959079; Tue, 08 Mar 2016 11:55:59 -0800 (PST) Sender: richmoore44@gmail.com Received: by 10.37.3.146 with HTTP; Tue, 8 Mar 2016 11:55:58 -0800 (PST) In-Reply-To: References: <5191210.88NEgq11Kq@pintsize.usersys.redhat.com> Date: Tue, 8 Mar 2016 19:55:58 +0000 X-Google-Sender-Auth: 5mqKahQ4hf4IE_erRUtBDvWTGYY Message-ID: From: Richard Moore To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1140f6825e3427052d8ef843 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 19:56:03 -0000 --001a1140f6825e3427052d8ef843 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 7 March 2016 at 12:32, Martin Thomson wrote: > On 7 March 2016 at 23:02, Hubert Kario wrote: > > well, if some people don't care about their implementation being > > fingerprintable, let them be, but there should but at least a > > recommendation what to do if you want to avoid that. > > I'd be very surprised if this added anything to the fingerprinting > entropy already present in TLS implementations. You can't use this > sort of thing to distinguish one user of NSS from another NSS user. > > =E2=80=8BNo, but you can use this sort of thing in combination to determine= the version a server is running not just the implementation. If there was a recommended alert for a given situation I imagine (perhaps over optimistically) that it would be harder. > BTW, I'm pretty much not willing to volunteer to review the patch that > made NSS less fingerprintable as NSS. I'm pretty sure that involves > replacing NSS with OpenSSL. > =E2=80=8BMaking it hard (or at least harder) to distinguish the two would definitely not involve that. That said, I haven't fingerprinted NSS as a server in anywhere near as many configurations as openssl though this is mainly because I see it used that way less frequently. Cheers Rich. --001a1140f6825e3427052d8ef843 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 7 March 2016 at 12:32, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 7 March 2016 at 23:02, Hubert Kario <hkario@redhat.com> wrote:
> well, if some people don't care about their implementation being > fingerprintable, let them be, but there should but at least a
> recommendation what to do if you want to avoid that.

I'd be very surprised if this added anything to the fingerprinti= ng
entropy already present in TLS implementations.=C2=A0 You can't use thi= s
sort of thing to distinguish one user of NSS from another NSS user.


=E2=80=8BNo, but you can use this sort of t= hing in combination to determine the version a server is running not just t= he implementation. If there was a recommended alert for a given situation I= imagine (perhaps over optimistically) that it would be harder.

=C2=A0
BTW, I'm pretty much not willing to volunteer to review the patch that<= br> made NSS less fingerprintable as NSS.=C2=A0 I'm pretty sure that involv= es
replacing NSS with OpenSSL.

=E2=80=8BMaking it hard = (or at least harder) to distinguish the two would definitely not involve th= at. That said, I haven't fingerprinted NSS as a server in anywhere near= as many configurations as openssl though this is mainly because I see it u= sed that way less frequently.

Cheers

Rich.


<= div class=3D"gmail_extra">

--001a1140f6825e3427052d8ef843-- From nobody Tue Mar 8 14:16:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B15B12DB75 for ; Tue, 8 Mar 2016 14:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id So6-Qs_CFKqB for ; Tue, 8 Mar 2016 14:16:12 -0800 (PST) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (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 5ACE912DB7E for ; Tue, 8 Mar 2016 14:16:07 -0800 (PST) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 5F1621380BA.A2BD8 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 5F1621380BA for ; Tue, 8 Mar 2016 23:16:04 +0100 (CET) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 5D37B403B for ; Tue, 8 Mar 2016 23:16:04 +0100 (CET) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 5BCAF6002E for ; Tue, 8 Mar 2016 23:16:04 +0100 (CET) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 4D5F340 for ; Tue, 8 Mar 2016 23:16:04 +0100 (CET) Received: from c-73-223-67-156.hsd1.ca.comcast.net ([73.223.67.156]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Tue, 08 Mar 2016 23:16:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 08 Mar 2016 14:16:04 -0800 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: aluykx To: tls@ietf.org Message-ID: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99 at cobalt X-Virus-Status: Clean Archived-At: Subject: [TLS] Data Volume Limits Analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 08 Mar 2016 22:16:14 -0000 Kenny Paterson and I prepared a document providing an overview of how much data ChaCha20+Poly1305 and AES-GCM can process with a single key. Besides summarizing the results, the document also gives an explanation of why the limits are there. The document confirms the analysis done by Watson and others in the thread on "Data Volume Limits", but goes into more detail. The document can be found on Kenny's website: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf Atul Luykx From nobody Wed Mar 9 02:21:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF91B12D5A3 for ; Wed, 9 Mar 2016 02:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrILRak0ab_X for ; Wed, 9 Mar 2016 02:21:21 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C015812D5A1 for ; Wed, 9 Mar 2016 02:21:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 92CA6BE7D; Wed, 9 Mar 2016 10:21:19 +0000 (GMT) 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 2xVNxzrCaCu9; Wed, 9 Mar 2016 10:21:19 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 09CB4BE56; Wed, 9 Mar 2016 10:21:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457518879; bh=ekDs/ND7IAtr+XGZXdmZGZJM9NxO2hF3T0xevzTUBPk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XsguyYZ190NG7B3PtlWKqOxOTpbPxLqpvmcFURwaQ2DfsmaDwe2EYAX9QdrntmAnr X09qc02DtblXFnJ8IoFXxdBMh6T6kDfyLHLVLM+qpQxafoWmPgmCasL9eIkZDhD5zD napZISprvcGYOQ7lxY64fUyONRb19UpwTPQtDOBI= To: Sean Turner , "" References: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56DFF91E.8030408@cs.tcd.ie> Date: Wed, 9 Mar 2016 10:21:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030704080807040402090502" Archived-At: Subject: Re: [TLS] Fwd: Cached Info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 10:21:24 -0000 This is a cryptographically signed message in MIME format. --------------ms030704080807040402090502 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 08/03/16 01:19, Sean Turner wrote: > All, >=20 > The cached-info draft got all the way to the IESG and then we receive > a couple of comments that require we bring the draft back to the WG > to discuss. Please figure out what changes if any are needed and let me know. If those are uncontroversial and don't affect interop we can just make 'em. (I'll check the IESG are ok too but that should add more delay.) If (more likely maybe) those are uncontroversial but do affect interop, we should probably do another IETF LC just in case and all going well, I'll just check if the IESG are ok with just going ahead (as I'd expect) of if they want do another IESG review. If those are controversial, then I can formally mark it as being back with the WG and when the WG are ready we can start over with a fresh IETF LC and IESG review. Cheers, S. >=20 > spt >=20 >> Begin forwarded message: >>=20 >> From: Karthikeyan Bhargavan Subject: >> Re: Cached Info Date: February 23, 2016 at 12:34:31 GMT+9 To: Sean >> Turner , Eric Rescorla , Martin >> Thomson , "Stephen ie>" >> Cc: Antoine Delignat-Lavaud >> >>=20 >> Some corrections: >>=20 >> Dear All, >>=20 >> I took a quick look at cached-info at Ekr=E2=80=99 prodding, who was >> worried about key synchronization-style attacks (Ekr=E2=80=99s origina= l >> email is a the bottom of this email.) My conclusion is that the use >> of a 4-byte hash is unnecessarily fragile. The attacks are not >> super-serious, but the following scenario looks bad. Maybe I got >> something wrong about the spec, so do tell me if I did. >>=20 >> Suppose that the client uses client certificates (or >> channelID/token binding) to login to all websites. The client=E2=80=99= s >> authentication credential is bound to the current handshake >> transcript. If the transcript does not contain the server >> certificate, then a malicious server may be able to forward a >> credential sent by the client to the malicious server to a >> different server. This kind of credential forwarding attack enables >> certain kinds of impersonation (see Triple Handshake) >>=20 >> In Cached-Info, the transcript includes a 32-bit hash of the >> certificate and some signature or RSA encryption that uses the >> certificate signing/encryption key. To mount the attack described >> above, the attacker would first need to find a certificate that >> collides with the honest server certificate hash. You can imagine >> the attacker generating 2^32 self-signed certificates until the >> collision is found, this is not hard. Next, the attacker still has >> to match the parts of the transcript that use the server=E2=80=99s pub= lic >> key (if any). The client could maybe choose the public key to match >> that of the server, or carefully choose the RSA signing key to >> create a signature value that matches that of the real server etc.=20 >> There may be other attacks where the attacker uses a static ECDH >> ciphersuite, and so does not need to sign anything. >>=20 >> So now, the honest client C connects to malicious server M that has >> a self-signed cert (for M). C accepts the cert (for M) and agrees >> to use certificate/token-bound authentication at M. M can then >> forward the credential and signature to S, which will accept it. M >> would not control the keys between M and S (since it used S=E2=80=99s >> public key.) But if C is using a browser, then C=E2=80=99s window is a= t M=E2=80=99s >> origin, so M can inject data into the connection which will then be >> forwarded to S, as if the authenticated user C intended to send it >> to M. >>=20 >> Perhaps the above attack is not very worrisome to some people, but >> the silly bit is that accepting this risk is completely >> unnecessary. The client and server could simply use the full >> SHA-256 hash for the certificate and the client would have a hard >> time creating a colliding certificate. >>=20 >> Best, Karthik >=20 >=20 >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 Ekr=E2=80=99s original e= mail =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94 >>=20 >> Folks, >>=20 >> I've been thinking over the cached-info draft, and I'm not >> convinced that the security analysis is right. >>=20 >> In the current design, the client sends a truncated 32-bit hash of >> what it believes the server's certificate is. If that matches the >> server's certificate, then the server echoes that truncated hash >> (if I'm reading it correctly). >>=20 >> The security considerations section claims: >>=20 >> The use of the cached info extension allows the server to send=20 >> significantly smaller TLS messages. Consequently, these omitted=20 >> parts of the messages are not included in the transcript of the=20 >> handshake in the TLS Finish message. However, since the client >> and the server communicate the hash values of the cached data in >> the initial handshake messages the fingerprints are included in the >> TLS Finish message. >>=20 >> But this isn't correct with a short hash, since you're not >> strongly binding the hash into the handshake. And elsewhere the >> text claims that the hash isn't relevant: >>=20 >> If an attacker injects an incorrect fingerprint then two outcomes >> are possible: (1) The fingerprint does not relate to any cached >> state and the server has to fall back to a full exchange. (2) If >> the attacker manages to inject a fingerprint that refers to data >> the client has not cached then the exchange will fail later when >> the client continues with the handshake and aims to verify the >> digital signature. The signature verification will fail since the >> public key cached by the client will not correspond to the private >> key that was used by server to sign the message. >>=20 >> I think this is closer to the truth. But consider the case where an >> attacker convinces the client to accept a certificate for=20 >> attacker.com but with victim.com >> 's public key that *also* hash the same >> fingerprint as victim.com 's certificate. In >> that case, you could end up with a UKS between the client and >> victim.com (where the client thinks he's >> talking to attacker.com ). What prevents this >> (I believe) is the text in Security Considerations: >>=20 >> Clients MUST ensure that they only cache information from >> legitimate sources. For example, when the client populates the >> cache from a TLS exchange then it must only cache information after >> the successful completion of a TLS exchange to ensure that an >> attacker does not inject incorrect information into the cache. >> Failure to do so allows for man-in-the-middle attacks. >>=20 >> If followed, this will stop the client from accepting attacker.com >> 's bogus cert (because he doesn't have the >> private key). Note, however, that you have to follow it strictly. >> For instance, if you cache after False Start, then you are >> vulnerable to this attack. Also, these instructions seem really >> counterintuitive, because naively you would expect to just be able >> to validate the server's cert and store the hash once it had been >> validated. I also note that this advice was in the draft in -19 >> when the full hash was used. >>=20 >> To be honest, I'm not entirely convinced that this advice is >> sufficient, but I don't have a complete analysis either way. >> However, I do think it's clear that the text in the draft is >> confusing. >>=20 >> Thoughts? -Ekr >>=20 >=20 >=20 >=20 >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms030704080807040402090502 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMDkx MDIxMThaMC8GCSqGSIb3DQEJBDEiBCDAX0Z1js0nW2lojGwBRea9+2ChvsL8Jp/ex9+NQUeF xzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAOUQJ4B4uz2FAaZKtz8BxjDDPCdQVevThTOuhA/ucSWBm44wlE3BSy zFvq4r2ncAhxn1edaBMvi1uugJLnuWIDMWHUQcLEuGCXGbif6emdhDynqo7y6jgGppLrsf0S 9Vu4DLovYJHknjs1KT9nSjsM/tNDjxwiLSxhS2yF5vv2JP6KqRyAjVJGtQZ4aJ1/sKI5xzXN oRf1Qg+G4bBpYGTu5uiGSYABhmxirb5jhoZbcxqxW+s/12NDqu+hZYYRseWq77GuR3jUB0sG W/lU72wz/DTlxLWFjTXK5WiDXysG4tdVOzyn/7u5RbgBVvHFzqf31q9T+WoDK6gHLeWFOY/n AAAAAAAA --------------ms030704080807040402090502-- From nobody Wed Mar 9 03:05:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F1212D7C8 for ; Wed, 9 Mar 2016 03:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiGROIfwTx6v for ; Wed, 9 Mar 2016 03:05:26 -0800 (PST) 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 3DBCC12D7C4 for ; Wed, 9 Mar 2016 03:05:24 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 985A0C00F5E6; Wed, 9 Mar 2016 11:05:23 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-120.brq.redhat.com [10.34.0.120]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u29B5LKS020468 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Mar 2016 06:05:22 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 09 Mar 2016 12:05:16 +0100 Message-ID: <2223470.EAoG62gjRo@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.3-201.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <20160308184131.GS10917@mournblade.imrryr.org> References: <20160303152945.18296912.40009.55386@ll.mit.edu> <2031124.N80aPK0KD4@pintsize.usersys.redhat.com> <20160308184131.GS10917@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1833780.hGlIGXVUpj"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 11:05:27 -0000 --nextPart1833780.hGlIGXVUpj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 08 March 2016 18:41:32 Viktor Dukhovni wrote: > On Tue, Mar 08, 2016 at 07:24:37PM +0100, Hubert Kario wrote: > > No, I said that we have no reason to believe that quantum computers= > > won't follow exponential increase in number of qbits they can > > handle, > > with the highest increase not exceeding doubling every year, but > > more > > likely doubling every two years (as every other technological > > development did till now). >=20 > There's reason to be skeptical of such analogies. Moore's law was > neither a theorem nor a law of nature. It was an observation about > progress in feature-size shrink of silicon transistors. It is far > from clear that evolution of silicon fabrication is a relevant model.= That's why I'm not saying that it will be exactly like Moore's law. My point is, that processes which have super-exponential growth are the= =20 exception, not the rule (if they exist at all). And you would be hard=20= pressed to find any process in history that experienced exponential=20 growth over a long time span and be at the same time vastly faster than= =20 the Moore's law. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1833780.hGlIGXVUpj 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 iQIcBAABCgAGBQJW4ANsAAoJEJKo0bgB0vX1ENwP/3QYn+6Y3iieoKd0ExS32Zp0 WkRWMh0M/HXkcxOwRoI2XjSAVwClE+R11n/h/dj5GQRKdCCEBJbqfjJontzo786C Gnfeoa204raFsZ5oU7No/Iap2JC8J1qME4eFdV6FquyjihhwA9XxbAAfkF35FqMn cZCug6go+LPrvj2a9LzzhQo0wiKmzx3AQtFalT2jqmAoXSsa8yU6dx28YszdLZhe KncVNK06yGBmpb2mjtNDLLQFHX50mFhB4r2p3ljDDlXbAnDlQRGc+Qj/Lz0eyQsS RAd7whKDbWpU/+/9o3jzYfd337LMsBQxZ5P5uZaZkHeeNKySki+vfl7ZMIRCl0os wWbybJ6Tmy3aR5/UIBtfLsm0c9fhIGKTKqEjRHauPzpPsNag2F5KnHZm6l026vs6 2GUSxKF8XKDqL7mp9sxrd6ept9YtkKLbN6obGqrNXjuHSkcQ0MsgYl6nhBmfLa3x uQk0eRU/wAyuPeQ3qQTJrWNWaQ63pY74jVM0x0M7JM2mJyKMeZucDcQVrvXeWJlg 7zu8zCeu7qcbS7gN4UNEMgVk1q5kNoDVxYJpsr4xo9v+qzzhwBQs2ouYpeoR9zRj FaXvSLlYHGPaNj64it4TT15C8RH7eZl2cGOBuNScGv/rHZT/L9kGcqo48fst7c6Q bgYYqB9HGrDwxcOJqT5W =JNf2 -----END PGP SIGNATURE----- --nextPart1833780.hGlIGXVUpj-- From nobody Wed Mar 9 06:05:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D7B12D61C for ; Wed, 9 Mar 2016 06:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDmBj6tSPAYA for ; Wed, 9 Mar 2016 06:05:43 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04E8E12DE60 for ; Wed, 9 Mar 2016 06:05:36 -0800 (PST) Received: from [192.168.10.140] ([195.149.223.22]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M5uLh-1ZtwoR0y3l-00xtKU; Wed, 09 Mar 2016 15:05:34 +0100 To: Adam Langley , "tls@ietf.org" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56E02DAB.1030104@gmx.net> Date: Wed, 9 Mar 2016 15:05:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nplMOoTlACQcWbDfAKpeGmRQLwJsG1Js1" X-Provags-ID: V03:K0:jXYZvviL2BasjyhhswBoYgHp+h/KTwzdg/oyNqPQ9h38syBMHwb K9yPhrQ6S6lJDCJJ4I3WhyG01vrYO7QPZeqWdCQv6rzFfefRWOmr5UadI1nHe6VSenv0Wg4 007K/3k+wMqpC0qWplvue/xLeeubLVQmjGSRqEeBqBU6R/SoGWs9aKamMO+pt09lC8/zWNt ez49157ujUInF9g/8vVLA== X-UI-Out-Filterresults: notjunk:1;V01:K0:x9BY9LgdeAw=:y6xC+smbRYD6jGwTukmc+W xvSL5yKB7I7HpcEKM2+fEmLXJlOG9t3Vr+z5IFqCW7fgpbIRw9UWI0uPtZpeMTR/L3zw2f64A h5S56F3F2zmFWrNwPOiTojSHRP+6OP5NqGZPlHVuOZweSs+lHeFhLXd5N/0rfwDHlDXALUL68 QeT5fMY3YM6VOe/F7fHkQQN1AOag24aTwl0OuHR2brZzEjZQZEx8VbKCeHgAo/g2CKm/Sbiu/ cduiujxBAPZWS5U3TfwLkzPCQp6UAuAbtnO0KDpl6V0wXZnGWCCwTvHdGAt8bO+Acy1PXY048 HPCjbftFooZmoGMO9aWqb7kyDQ+3CIA5Gd+qN328us8eW6oAZRNFWnc2vuVcNme3/URum4GA3 HZWoSpIuytI80myhQL2azfbgiEfIeH2azbWJzmUqrx60J7My1JAhe9gLCP++KXQYlmYa1iyAQ Y+uN0gd4guaSBWXF6N5mhZfWeXo+k7vzTe9Tu+oqf9uG8Q8NeK2KoOaWafhhuTbDNMa5ycqRa evkiVNSsje67vopLWECk41FfWYz82IeJXCcOMxXvQ1U7m1C/cBQRUsHs1yDYPTn1OdjYV+i4p jfLL7OtqlKsJ6nF874cFfhICb3b3cfp3pDb9GLLKckdXCHoFQsnyNjMpSxtsEiaTI3Svr3HN+ nHT+FnxxPRWOXO5Nh0LidhswBdXIntHsQHn0wiwwokz53m3HXF2AkLzzXjcOQsBoLd+CuI2po x0ZjMZCYGtOHqV8VK4rX5d+jm61yCgIIachctcda6ivdZe62SfjnFTseiZ8= Archived-At: Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 14:05:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nplMOoTlACQcWbDfAKpeGmRQLwJsG1Js1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Adam, as Thomas mentioned in his email we are looking into extending the SNI functionality. Let me explain why we are doing it. We are focused on Internet of Things deployments and we want to use TLS/DTLS there to provide communication security. The use of TLS/DTLS would solve some of the problems we see in deployments today where either no communication security is used (such as in the BMW Connected Drive example) or where custom security solutions are used. We want to make it easy for developers to add commonly used security services to their applications. Everything fine so far. In many deployments the IoT device acts as a client and initiates the connection to some cloud-based infrastructure (or to some gateway). In other deployments the IoT device needs to act as a server. In fact, in many home network/small enterprise deployments this seems to be the envisioned model. Assuming that every IoT device has a domain name is not desired or useful. Instead, the CORE working group has developed the so-called Resource Directory, which acts as a rendezvous point, and may even have more capabilities -- with extensions, like caching of data, while the IoT devices sleeps. ("Sleeping devices" consume less energy.) Now, we had to come up with another story of what information to put into certificates or, alternatively, forget the use of certificates. I know that the timing isn't necessarily in our favor. You guys are trying to move the TLS 1.3 spec along and our contribution is still subject to (longer) discussion at the CORE working group. I also understand that you may not necessarily be super interested in IoT usage either. I still hope that this can be taken into consideration. I saw the proposal from Martin about defining another extension. This may be an option and maybe the answer is as simple as "don't use certificates for such scenarios". I believe other organizations who are also looking into these types of IoT scenarios will sooner or later also figure out that there is a proble= m. Ciao Hannes On 03/03/2016 07:49 PM, Adam Langley wrote: > The Server Name Indication (SNI) extension in TLS has a provision to > provide names other than host names[1]. None have even been defined to > my knowledge, but it's there. >=20 > OpenSSL (and possibly others) have had a long-standing bug[2] (fixed > in master) that means that different types of names will cause an > error. To be clear: I live in a glass house and am not throwing > stones; these things happen. However, it means that a huge fraction of > the TLS deployment will not be able to accept a different name type > should one ever be defined. (This issue might have been caused by the > fact that the original[3] spec didn't define the extension in such a > way that unknown name types could be skipped over.) >=20 > Therefore we (i.e. BoringSSL, and thus Google) are proposing to give > up on this and implement our parser such that the SNI extension is > only allowed to contain a single host name value. (This is compatible > with all known clients.) We're assuming that since this is already the > de-facto reality that there will be little objection. I'm sending this > mostly to record the fact so that, if someone tries to define a new > name type in the future, they won't waste their time. >=20 > If the community wishes to indicate a different type of name in the > future, a new extension can be defined. This is already effectively > the case because we wouldn't fight this level of incompatibility when > there's any other option. >=20 > (I think the lesson here is that protocols should have a single joint, > and that it should be kept well oiled. For TLS, that means that > extensions should have minimal extensionality in themselves and that > we should generally rely on the main extensions mechanism for these > sorts of things.) >=20 > [1] https://tools.ietf.org/html/rfc6066#section-3 > [2] https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1= _lib.c#L1066 > =E2=80=93 note that the data pointer is not updated. > [3] https://tools.ietf.org/html/rfc4366#section-3.1 >=20 >=20 > Cheers >=20 > AGL >=20 --nplMOoTlACQcWbDfAKpeGmRQLwJsG1Js1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW4C2sAAoJEGhJURNOOiAtJhQH/j4xlvnJ/eJJYm/FCmbqUq2k 7eBIv4bgpLbRdCAW1B5eHD6i2u/Ny2zdieLsXgIxNoYf2gs2/lK0tacqqCboKq9a nR/l8qnpciwbElmUWA6DNsxaeG2SE7oG9eSLAcPpwJJ6ExtuEB3zgwwKgzA4ghiP BvAe3P+VzszDnExa2ctizmVfj0BOxGp1EnSj6UxpAxuAMmOz5Q9FztFY1CZH+Dge YB0D8hU0AlEkvGL6AcKxtwEUo0G8ftQIxHK7S/DIAw2PdMhodO3P2n0yZIn3GbqP D0nkFh2FIxFi0LPRIct+upNOErnndVxZFm2aDR/yZjHJUtPLfVbMjO1BOo1yXvU= =TOm2 -----END PGP SIGNATURE----- --nplMOoTlACQcWbDfAKpeGmRQLwJsG1Js1-- From nobody Wed Mar 9 06:16:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADC112D6D9 for ; Wed, 9 Mar 2016 06:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zJqo1flGnvR for ; Wed, 9 Mar 2016 06:16:24 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E3312D65A for ; Wed, 9 Mar 2016 06:16:23 -0800 (PST) Received: from [192.168.10.140] ([195.149.223.22]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M2Glc-1ZoAoU2Zwy-00s7wH; Wed, 09 Mar 2016 15:16:07 +0100 To: Sean Turner , "" References: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56E03023.1090703@gmx.net> Date: Wed, 9 Mar 2016 15:16:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HNTAjd6swdqNwFu4dFxqGbHtCQc3gb1Oh" X-Provags-ID: V03:K0:yy6hMDyTDlL9fRUe/LPLY4GLa+J6Go3Ggm3JMGS+ExLkGTikd0Z iOoR7fjbNRDmGatw61kYOd6rf/CeVTRvfeVyX+Simg8mkrw0PT6XELDhCTtZJ6CjMW8q6Ga ezhYtGg7NiVpmQtikPHVwTlEsWnnkUoJuMwZ/WyEJTM+bhltW6PVpsgdBVfY9TKNdPfrm4b 8G7VhZ+igjG025iHZr33A== X-UI-Out-Filterresults: notjunk:1;V01:K0:FL3jFy48lgg=:tj6ktHv8R3u0YKvGlrVwZq s9GWI5ySoHws07fgIqAxJ88MHUl6+io5h/YB78oiUpMN7OYknCY6fkhoAjITIHR0qxjJc/c6i fW25oaMi4aai0lnlnYc0WbMBVNa3faXmJ8C/wLQlrVy5t0rcrjZ3g7jMPBTvrnib5uedR89iR x86TYuecgQ7Jqrzv3lZ9KO0pCWnVzy93I6GBH0GRG8K05YYB98vhnmbFr3jBKkWK+2Y6ls7Bm TZbP6yuP6gCIEcfWyj+PwFpuf7v3bU9LtxY60PC9OhCCf1kfql17cJQDF8qtMG/mlECjtcWRZ nCPoJyiff8vvOkSVUo+7x3CWgWefYFrKbwvOgeDWhZJMv2AlK6M/QqNuEkLCNrGJHfco3q1NM I4gHPoYkcR2hI+X9u7a5CWf5Q3WvssXncvdGDUHgwWXhv+fhh3GT5XqJMVaynVOFarT6IRght 5bCS/uexpL1WtVa0uBTxnDG5RMAauLVOmEreVXjxciRQqV174IpWO1HXrp+KojGCybM/zX/UJ HU1kp6jgBXf0EntVrhXh4f4rbCTyhC/fCJ0TitF49/C0ROZFEYLpMmVXXFW/qkEBaWjtU53cM BIiHTRaajdIFiprzECmEMkOpGaJWlQ8sMTf2Na15pBL+g6k+FczMZyjQu2Ro50wr7ikx+TD4f x7EB97VKCiB1wnQota06sP9AMcD6e78fSkTU4lVWseMEeQy/3RO9qE9wNXO4X3dlKlgosZqKe yulg3LMZO6H4DlgnTwhvxtWVNtsHBCKOJ29F1c3h0lM+RQxMVxu4P2qaMUs= Archived-At: Subject: Re: [TLS] Fwd: Cached Info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 14:16:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HNTAjd6swdqNwFu4dFxqGbHtCQc3gb1Oh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, in the off-list conversation I have also provided my remarks on the raised issues. Here is what I said: ----------------- Thanks for spending the time to look at the document. There were indeed concerns about the length of the hash in the working group and, as you said, there was specific attack raised. It is true that an attacker (or someone else) can create a certificate that matches the hash of the certificate used by some other site, particularly when the hash size is very small (4 bytes in our case). It appears to me that the vulnerability described below assumes that the client is somehow tricked into accepting the wrong certificate. The client stores the hash of the obtained certificate locally after completing a full handshake with the server. As such, it has to store the server identity together with the hash. This cache then has to be populated with the certificate provided by the adversary. The client then has to pick the wrong certificate, which matches the fingerprint. Such a scenario can indeed happen if the client TLS implementation does a lookup of the certificate based on the hash alone rather than taking the server identity into account. In the other attack that Karthik described the client has to connect to the malicious server and then that server would relay the messages to an honest server and the signatures from the client would have to correctly verify. I am missing a few assumptions about what else needs to go wrong for this attack to work. Getting the honest server to just accept relayed client certificate and a signature requires more than the TLS Cached Info extension Regardless of the details I understand the concerns. There is indeed an additional level of brittleness with the introduction of the shortened hashes. While they consume less bandwidth over the wire (which is nice) they require a careful implementation. ----------------- In a nutshell, while I do not believe that the attack described is realistic I am sensitive to the problem of creating brittle code. If it is OK for the working group then I would like to revert back to the previous version of the draft where we use the longer hash. Ciao Hannes On 03/08/2016 02:19 AM, Sean Turner wrote: > All, >=20 > The cached-info draft got all the way to the IESG and then we receive a= > couple of comments that require we bring the draft back to the WG to > discuss. >=20 > spt >=20 >> Begin forwarded message: >> >> *From: *Karthikeyan Bhargavan > > >> *Subject: **Re: Cached Info* >> *Date: *February 23, 2016 at 12:34:31 GMT+9 >> *To: *Sean Turner >, Eric >> Rescorla >, Martin Thomson >> >, "Stephen= >> ie>" > >> *Cc: *Antoine Delignat-Lavaud > > >> >> Some corrections: >> >> Dear All, >> >> I took a quick look at cached-info at Ekr=92 prodding, who was worried= >> about key synchronization-style attacks (Ekr=92s original email is a t= he >> bottom of this email.) >> My conclusion is that the use of a 4-byte hash is unnecessarily fragil= e. >> The attacks are not super-serious, but the following scenario looks ba= d. >> Maybe I got something wrong about the spec, so do tell me if I did. >> >> Suppose that the client uses client certificates (or channelID/token >> binding) to login to all websites. >> The client=92s authentication credential is bound to the current >> handshake transcript. >> If the transcript does not contain the server certificate, then a >> malicious server may be able >> to forward a credential sent by the client to the malicious server to >> a different server. >> This kind of credential forwarding attack enables certain kinds of >> impersonation (see Triple Handshake) >> >> In Cached-Info, the transcript includes a 32-bit hash of the >> certificate and some signature or RSA encryption that uses the >> certificate signing/encryption key. >> To mount the attack described above, the attacker would first need to >> find a certificate that collides with the honest server certificate ha= sh. >> You can imagine the attacker generating 2^32 self-signed certificates >> until the collision is found, this is not hard. >> Next, the attacker still has to match the parts of the transcript that= >> use the server=92s public key (if any). >> The client could maybe choose the public key to match that of the >> server, or carefully choose the RSA signing key to create a signature >> value that matches that of the real server etc. >> There may be other attacks where the attacker uses a static ECDH >> ciphersuite, and so does not need to sign anything. >> >> So now, the honest client C connects to malicious server M that has a >> self-signed cert (for M). >> C accepts the cert (for M) and agrees to use certificate/token-bound >> authentication at M. >> M can then forward the credential and signature to S, which will >> accept it. >> M would not control the keys between M and S (since it used S=92s publ= ic >> key.) >> But if C is using a browser, then C=92s window is at M=92s origin, so = M >> can inject=20 >> data into the connection which will then be forwarded to S, as if the >> authenticated user C intended to send it to M. >> >> Perhaps the above attack is not very worrisome to some people, but the= >> silly >> bit is that accepting this risk is completely unnecessary. The client = and=20 >> server could simply use the full SHA-256 hash for the certificate and = the >> client would have a hard time creating a colliding certificate. >> >> Best, >> Karthik >=20 >=20 >> =97=97=97=97=97 >> Ekr=92s original email >> =97=97=97=97=97=97=97=97 >> >> Folks, >> >> I've been thinking over the cached-info draft, and I'm not convinced >> that the security analysis is right. >> >> In the current design, the client sends a truncated 32-bit hash >> of what it believes the server's certificate is. If that matches >> the server's certificate, then the server echoes that truncated >> hash (if I'm reading it correctly). >> >> The security considerations section claims: >> >> The use of the cached info extension allows the server to send >> significantly smaller TLS messages. Consequently, these omitted >> parts of the messages are not included in the transcript of the >> handshake in the TLS Finish message. However, since the client and= >> the server communicate the hash values of the cached data in the >> initial handshake messages the fingerprints are included in the TLS= >> Finish message. >> >> But this isn't correct with a short hash, since you're not strongly >> binding the hash into the handshake. And elsewhere the text claims >> that the hash isn't relevant: >> >> If an attacker >> injects an incorrect fingerprint then two outcomes are possible: (1= ) >> The fingerprint does not relate to any cached state and the server >> has to fall back to a full exchange. (2) If the attacker manages to= >> inject a fingerprint that refers to data the client has not cached >> then the exchange will fail later when the client continues with th= e >> handshake and aims to verify the digital signature. The signature >> verification will fail since the public key cached by the client wi= ll >> not correspond to the private key that was used by server to sign t= he >> message. >> >> I think this is closer to the truth. But consider the case where >> an attacker convinces the client to accept a certificate for >> attacker.com but with victim.com >> 's public key that *also* >> hash the same fingerprint as victim.com 's >> certificate. In that case, >> you could end up with a UKS between the client and victim.com >> >> (where the client thinks he's talking to attacker.com >> ). What prevents >> this (I believe) is the text in Security Considerations: >> >> Clients MUST ensure that they only cache information from legitimat= e >> sources. For example, when the client populates the cache from a T= LS >> exchange then it must only cache information after the successful >> completion of a TLS exchange to ensure that an attacker does not >> inject incorrect information into the cache. Failure to do so allo= ws >> for man-in-the-middle attacks. >> >> If followed, this will stop the client from accepting attacker.com >> 's >> bogus cert (because he doesn't have the private key). Note, however, t= hat >> you have to follow it strictly. For instance, if you cache after >> False Start, then you are vulnerable to this attack. Also, these >> instructions seem really counterintuitive, because naively you >> would expect to just be able to validate the server's cert and >> store the hash once it had been validated. I also note that this >> advice was in the draft in -19 when the full hash was used. >> >> To be honest, I'm not entirely convinced that this advice is sufficien= t, >> but I don't have a complete analysis either way. However, I do think i= t's >> clear that the text in the draft is confusing. >> >> Thoughts? >> -Ekr >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --HNTAjd6swdqNwFu4dFxqGbHtCQc3gb1Oh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW4DAkAAoJEGhJURNOOiAtmOoH+wUJqCAYc5mcvqIuuqDYtha7 20mgLojf4IeGuOxrX3fmRFUcIRLBout1C0KsWJ+/QkIkBYbVhS5elIW5blmL/f8o jQohCYW1xfmhMZK8iIpp403VpTQ7Q8eEYyqDISmxEaEEEtVSl35fopoSAne7JOQu FuzKmn8cXWTRvT6CRA5gPoKDLXqqXbibYVF1cVp52hkgRoLTFbZPRRidWQnFdu9N fXjLMSRfVqtHEgTHEKFgD0d7oFBSzeWkiXhDni8KqaMP4cebUhx94gC4J1Tt0tMD C/uWvEvZ0VoaUSgiULJHbzjLMUE5dhCjLjNSfk2cfck81Il+R0BOHwMtuwH8Uco= =tVzV -----END PGP SIGNATURE----- --HNTAjd6swdqNwFu4dFxqGbHtCQc3gb1Oh-- From nobody Wed Mar 9 07:12:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFC812DFE7 for ; Wed, 9 Mar 2016 06:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=bblfish-net.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNS2y9EX5V54 for ; Wed, 9 Mar 2016 06:39:11 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A2E912D974 for ; Wed, 9 Mar 2016 06:36:00 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id l68so73682695wml.1 for ; Wed, 09 Mar 2016 06:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=QaRRNEIMDqq153fkUEKsgACk3npKXnCyVTgBpwChnKI=; b=Uh9tJJujZq1Pn41ItYZbwqaqsJfI8aW8YEfnZiTbku0BjlkZ4WKrTMEnoBe0N/c9H7 qkIKhE3zWhsNBpbmxZrRvsvdzqqT2zGNRB4F4Ncq8Bk+4HeKCAyqkdJhf5UxPpAf0LTh DG5JRsouMCWhXNjmOyRBNEwHaQ9ze3BzQJuhYCFzbobK97TRPC8bn0/iP2M4Iv5+Q4XA kb4S7MpnU0eGG3+7bL9GfRTnSCkRF7GNIU1ddJ4+hqFEBrOW6tEXYobys5VRzNSVwuRI W5nz/KhXidshJg0sUr97zEFEM8zlc7ewbE4KmPs0/KShqn6U/XVNH0aadkEDAjeXvieT D3gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=QaRRNEIMDqq153fkUEKsgACk3npKXnCyVTgBpwChnKI=; b=M/OppqmUpDAfwwBqLtqCwiMNFmFsFsamd4M45PTBzm2bQ1IIDdq3hsGm0EmGhQdWR5 JVUJiQ+bdsyHQuwzL64+7tuQkB+jArJS8F8DnbpXrdVqKsUH29ZVHcWaVWs/eUp8ntE6 EgK7CQ5bzIMVfBO5BkSGRq78XppLCGUb1vLmEbEy1velb5hufJflJtZhIXUO2RGDQX4J 3HMAqH0JYkplb5ORz5lOvNyR57HjcZ+BQG61d48Sqp99EYiutKOYMPmKJO3mtxbLWCdg uFBfN6YJxjs9Nu/HGd0o1NMYB8uQ5zXdv4OAnss/LOvnCi/RUz+r6872sQvQ5pfvcYxA TbCw== X-Gm-Message-State: AD7BkJIsCJBcOALIRlkYb/1zcgPSW9mpRTnLV+sgNcg9hbB6lxv8AdCaPWGct5RHDczenw== X-Received: by 10.28.134.137 with SMTP id i131mr27723213wmd.62.1457534158867; Wed, 09 Mar 2016 06:35:58 -0800 (PST) Received: from [192.168.0.6] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net. [86.21.242.52]) by smtp.gmail.com with ESMTPSA id b1sm8221566wjy.0.2016.03.09.06.35.57 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Mar 2016 06:35:57 -0800 (PST) From: Henry Story Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 9 Mar 2016 14:36:20 +0000 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] X509 extension to specify use for only one origin? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 14:39:31 -0000 Hi, The W3C TAG is working on a finding for Client Certificates that=20 people here should find very interesting [1].=20 One issue that comes up a lot in discussions is the use of certificates across origins [2], which some folks find problematic, even though it=20 clearly has its uses [3]. It seems that this could be solved neatly with an X509 extension limiting usage to a certain origin or set of origins. I would not be surprised if this already exists. With browser chrome support this would allow the full range of uses from FIDO to cross origin ones whilst putting the user in control. Henry [1] https://github.com/w3ctag/client-certificates [2] https://github.com/w3ctag/client-certificates/issues/1 [3] = https://github.com/w3ctag/client-certificates/issues/1#issuecomment-194318= 303= From nobody Wed Mar 9 07:51:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E37112E20B for ; Wed, 9 Mar 2016 07:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFILHCYwyr1L for ; Wed, 9 Mar 2016 07:50:46 -0800 (PST) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id CFEE112E0EE for ; Wed, 9 Mar 2016 07:37:05 -0800 (PST) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u29FaEQj014284; Wed, 9 Mar 2016 10:36:14 -0500 From: "Blumenthal, Uri - 0553 - MITLL" To: Hannes Tschofenig , Adam Langley , "tls@ietf.org" Thread-Topic: [TLS] Accepting that other SNI name types will never work. Thread-Index: AQHRdX1zySMZN2Ujv0qqy5Lc2MGYjJ9RglKA///FsQA= Date: Wed, 9 Mar 2016 15:37:00 +0000 Message-ID: References: <56E02DAB.1030104@gmx.net> In-Reply-To: <56E02DAB.1030104@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3540364610_3986939" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-09_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1601100000 definitions=main-1603090263 Archived-At: Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 15:50:48 -0000 --B_3540364610_3986939 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Based on your explanation, the best solution architecture would be based on *attribute* certificates (individual attributes signed independently by their corresponding Attribute Authorities), rather than the current =E2=80=9Call-crammed-in=E2=80=9D certificates. The downside of the above is that this approach isn=E2=80=99t wide-spread, and would be computationally more expensive (the need to potentially verify at least two attributes, possibly more - instead of just dealing with one signature that covers everything). --=20 Regards, Uri Blumenthal On 3/9/16, 9:05 , "TLS on behalf of Hannes Tschofenig" wrote: >Hi Adam, > >as Thomas mentioned in his email we are looking into extending the SNI >functionality. > >Let me explain why we are doing it. > >We are focused on Internet of Things deployments and we want to use >TLS/DTLS there to provide communication security. The use of TLS/DTLS >would solve some of the problems we see in deployments today where >either no communication security is used (such as in the BMW Connected >Drive example) or where custom security solutions are used. We want to >make it easy for developers to add commonly used security services to >their applications. > >Everything fine so far. > >In many deployments the IoT device acts as a client and initiates the >connection to some cloud-based infrastructure (or to some gateway). In >other deployments the IoT device needs to act as a server. In fact, in >many home network/small enterprise deployments this seems to be the >envisioned model. > >Assuming that every IoT device has a domain name is not desired or >useful. Instead, the CORE working group has developed the so-called >Resource Directory, which acts as a rendezvous point, and may even have >more capabilities -- with extensions, like caching of data, while the >IoT devices sleeps. ("Sleeping devices" consume less energy.) > >Now, we had to come up with another story of what information to put >into certificates or, alternatively, forget the use of certificates. > >I know that the timing isn't necessarily in our favor. You guys are >trying to move the TLS 1.3 spec along and our contribution is still >subject to (longer) discussion at the CORE working group. I also >understand that you may not necessarily be super interested in IoT usage >either. > >I still hope that this can be taken into consideration. I saw the >proposal from Martin about defining another extension. This may be an >option and maybe the answer is as simple as "don't use certificates for >such scenarios". > >I believe other organizations who are also looking into these types of >IoT scenarios will sooner or later also figure out that there is a >problem. > >Ciao >Hannes > > >On 03/03/2016 07:49 PM, Adam Langley wrote: >> The Server Name Indication (SNI) extension in TLS has a provision to >> provide names other than host names[1]. None have even been defined to >> my knowledge, but it's there. >>=20 >> OpenSSL (and possibly others) have had a long-standing bug[2] (fixed >> in master) that means that different types of names will cause an >> error. To be clear: I live in a glass house and am not throwing >> stones; these things happen. However, it means that a huge fraction of >> the TLS deployment will not be able to accept a different name type >> should one ever be defined. (This issue might have been caused by the >> fact that the original[3] spec didn't define the extension in such a >> way that unknown name types could be skipped over.) >>=20 >> Therefore we (i.e. BoringSSL, and thus Google) are proposing to give >> up on this and implement our parser such that the SNI extension is >> only allowed to contain a single host name value. (This is compatible >> with all known clients.) We're assuming that since this is already the >> de-facto reality that there will be little objection. I'm sending this >> mostly to record the fact so that, if someone tries to define a new >> name type in the future, they won't waste their time. >>=20 >> If the community wishes to indicate a different type of name in the >> future, a new extension can be defined. This is already effectively >> the case because we wouldn't fight this level of incompatibility when >> there's any other option. >>=20 >> (I think the lesson here is that protocols should have a single joint, >> and that it should be kept well oiled. For TLS, that means that >> extensions should have minimal extensionality in themselves and that >> we should generally rely on the main extensions mechanism for these >> sorts of things.) >>=20 >> [1] https://tools.ietf.org/html/rfc6066#section-3 >> [2]=20 >>https://github.com/openssl/openssl/blob/OpenSSL_1_0_1-stable/ssl/t1_lib.c >>#L1066 >> =E2=80=93 note that the data pointer is not updated. >> [3] https://tools.ietf.org/html/rfc4366#section-3.1 >>=20 >>=20 >> Cheers >>=20 >> AGL >>=20 > --B_3540364610_3986939 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQw05HNA3f9KPwsEjBnzYAmsltMEEmYElffc54z0Xogw/LcgoDoGc0rq2Kcjk99VIEEMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDMwOTE1MzY1MFow DQYJKoZIhvcNAQEBBQAEggEAuV0bCGYhjFM2qLCWkzrJO6aE/eZUPP7vRaXFt2E9VkoIRmUZ hqugFEq3APcBnX5mQgYvvnE1r9fb87ue+yjSvFk1Bb0B55zTNW2OBtosyPsxsXzkHnbyZqdc 0SGJjXPPVPmKqKSr/3SLPnozDfRvD9griaoLtbQnMVO1rXeGoRulH674DcawyRLyVJM2Ka8j 768K99b/MSc0HAeDxlWGKIGWV5KLbNBVtDjYKHZLkIRyRtijNf6+5jucpESzN4MsPv+EJunR Mo6WKHPF7nRZIxDjWV1D5PPri+YJllY/5Na5S9wohreS/LYnyzO/lNS/13VBViAE4I16nuI4 fTYJZQ== --B_3540364610_3986939-- From nobody Wed Mar 9 08:08:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9502612E126 for ; Wed, 9 Mar 2016 08:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57BwDKfBhVSg for ; Wed, 9 Mar 2016 08:07:24 -0800 (PST) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 09F6312DFB4 for ; Wed, 9 Mar 2016 07:58:42 -0800 (PST) Received: by mail-qg0-x22f.google.com with SMTP id t4so45113634qge.0 for ; Wed, 09 Mar 2016 07:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=0UqMIpGZbIBB0w2RDbCWqsOcjFbM5BSmv/o0dH6yb5o=; b=Y7eCSEPcRqiTxL6U4LF6+4yw/wrQ1SBY9XNDm0EjFoli78FQ+pXaXaenSWIklFx/jJ TEBMiX3hLsEFhLXAoIEHVXKfoWudW7eknsw3SSx9vGfw+5Ojd6iy1TVXJyiIx9IMLTjJ SNqp0vdXGzbLEd4UyWz/Qww87etBO20LCp0owFe4zeLyaURst7r9nQT7P3ILhF0rJC5M upMPWs/wXqLDD3tv1VfB/hEPOzFR14D3mg3kHCsl2ZayzJdCWcHHyxF67QxVFCLapdNd 3zqCviB7TTRC9vHpoiI2G9rbGWGl77qGzPN23Pa4vUqwohdlgMGbX6EHvBTJ9UwnyGVW D1MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0UqMIpGZbIBB0w2RDbCWqsOcjFbM5BSmv/o0dH6yb5o=; b=g5RUVizG0c1cmyRCtkts/fYpkfSJzBTuErZnytjZuWgzQARPmWHGHk4NTiqEx9zts7 PQrIxcbapUA5KOVcFpilqyBrJ9wSSBPmjomorF81O+/lpun/YwRfRdLXk2Gfx+vzcdBo zxKi/OgIo2oy2yPrro6Y+TcmDqbuu0IwDIS80Y8iWs7B6i5ObIwpwF7CVfwE5FMqy+Ni NmGyE/tWuL3IwG9OS7opxCe40o7AkwDy/ukyHfop6HgPXUi2On7boEhA9AV/82/Nvbkw +jnH/O2uGIau8FZ+6XGSSEUTv2WvdgxzkaDGtwa2dnpMtybbXGVMR+17Myu/dwBl0dsy Lb0A== X-Gm-Message-State: AD7BkJJMq3y9PTjWYMQOiQ4kvOHmGnwNFSqnp8UzQzCJrc2m2uyYe4k7BzgX0ZcN8JzemvpiKOngWlNeFuX7TA== MIME-Version: 1.0 X-Received: by 10.140.93.84 with SMTP id c78mr43552478qge.101.1457539119744; Wed, 09 Mar 2016 07:58:39 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.50 with HTTP; Wed, 9 Mar 2016 07:58:39 -0800 (PST) In-Reply-To: <56E02DAB.1030104@gmx.net> References: <56E02DAB.1030104@gmx.net> Date: Wed, 9 Mar 2016 07:58:39 -0800 X-Google-Sender-Auth: 4vPZvWDziQPOeaUcZz7MZtnUbV4 Message-ID: From: Adam Langley To: Hannes Tschofenig Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Accepting that other SNI name types will never work. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 16:07:25 -0000 On Wed, Mar 9, 2016 at 6:05 AM, Hannes Tschofenig wrote: > I still hope that this can be taken into consideration. I saw the > proposal from Martin about defining another extension. This may be an > option and maybe the answer is as simple as "don't use certificates for > such scenarios". I'm not sure that I understand your use-case enough to say anything intelligent about it I'm afraid. I'm just noting here that adding new SNI types is pretty bug-rusted. Now, if you have a completely separate ecosystem you can solve the deployment issues, of course. But I worry that if new SNI types are added then, sooner or later, people will start to run into problems with the current implementation ecosystem and a bunch of effort will be wasted which could have been avoided by defining a new extension. Therefore I recommend defining a new extension rather than a new SNI type. Additionally, I'm suggesting that, in general, it's a good idea to avoid nesting extension-like structures inside an extension in favour of adding top-level extensions as needed. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Mar 9 08:11:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63512E155 for ; Wed, 9 Mar 2016 08:10:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoHdHT_E5RPr for ; Wed, 9 Mar 2016 08:09:51 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0004A12DEA0 for ; Wed, 9 Mar 2016 08:01:45 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id g3so43295425ywa.3 for ; Wed, 09 Mar 2016 08:01:45 -0800 (PST) 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=3zYGtHt44Ty2UodG0eIcwf+W/MOp19nxNPFTm0gsqoY=; b=p+Ob0ioWt7lUCHX2lBH5MTy9vNNSdM9kGyrVrfVyRKygZ7QAI3lk80zWbakkuSazZU dTR8MikepdQpTpbKZb86zXjWdoqA1rhJgMY4JBubH0WbCzJqSGkh0EqyTLNf0YQw7H5O UyljcdZjO4SYZWSrXoHHEYXTGDm+HcTzhR92m8GoNNlYLXaPl3Gi31z3pVEdX6sCmTE9 8Fj4VZnEapF2mVNj8n/IVBNFcbTBOG1JLrPA/IJ0jK/RaXpowRecLeKDrBsTuwC0+Ouy wZ8bC15tSGpBMC/BQqZk1Zyl8u3cYV8ZAQs6zPKXOGGuPf0g6Y9++ZKRodCqECdg6Tz+ bybg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3zYGtHt44Ty2UodG0eIcwf+W/MOp19nxNPFTm0gsqoY=; b=fNonuXuPgi8Z4xO/yoEvcgx5cqeDIqGXXIOqs9q6vAyV78j8t2wEqwEFP6g3MjQR2N oW8FXn2PVjpiFFDl0y4fPnSI9K3h6p4HL2Sdi+/darqskVFUd/ZZS4w+M1Df+YhUt0rH LY1w3/TPsuiNFQv1LTwUmbMbbZfgKcGtrPnq4Y+yqhsuuwJ9JpeCbfeO5N0j59FJs+Zw eyNNeS82FozgU7ksi+c03sLZh0KzsTuzAMG/1ePQGFV6RdnLxMRX8ECZ8r21ftDg3mDp rmYPjEb7BK3g+Q8qPJc92JvfK4QllP6rTwj15zlGf5qushc7j/hChanvahFEzoBN/zEE NF9A== X-Gm-Message-State: AD7BkJKncflZ82TEJ4aH2Zo+xLtJSPTJfpYHXecRiyT7XuJyUZ2/SWz58MwKWZJ4C1K0ALSW2suLG89JpTo+3g== X-Received: by 10.129.79.209 with SMTP id d200mr17730715ywb.115.1457539305255; Wed, 09 Mar 2016 08:01:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 9 Mar 2016 08:01:05 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 9 Mar 2016 08:01:05 -0800 Message-ID: To: Henry Story Content-Type: multipart/alternative; boundary=001a114bbc96896a79052d9fd0a1 Archived-At: Cc: "" Subject: Re: [TLS] X509 extension to specify use for only one origin? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 16:10:05 -0000 --001a114bbc96896a79052d9fd0a1 Content-Type: text/plain; charset=UTF-8 This is not a TLS WG issue. -Ekr On Wed, Mar 9, 2016 at 6:36 AM, Henry Story wrote: > Hi, > > The W3C TAG is working on a finding for Client Certificates that > people here should find very interesting [1]. > > One issue that comes up a lot in discussions is the use of certificates > across origins [2], which some folks find problematic, even though it > clearly has its uses [3]. > > It seems that this could be solved neatly with an X509 extension > limiting usage to a certain origin or set of origins. I would not > be surprised if this already exists. With browser chrome support this > would allow the full range of uses from FIDO to cross origin ones > whilst putting the user in control. > > Henry > > > [1] https://github.com/w3ctag/client-certificates > [2] https://github.com/w3ctag/client-certificates/issues/1 > [3] > https://github.com/w3ctag/client-certificates/issues/1#issuecomment-194318303 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114bbc96896a79052d9fd0a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is not a TLS WG issue.

= -Ekr


On Wed, Mar 9, 2016 at 6:36 AM, Henry Story <henry.sto= ry@bblfish.net> wrote:
Hi,<= br>
=C2=A0 The W3C TAG is working on a finding for Client Certificates that
people here should find very interesting [1].

One issue that comes up a lot in discussions is the use of certificates
across origins [2], which some folks find problematic, even though it
clearly has its uses [3].

=C2=A0It seems that this could be solved neatly with an X509 extension
limiting usage to a certain origin or set of origins. I would not
be surprised if this already exists. With browser chrome support this
would allow the full range of uses from FIDO to cross origin ones
whilst putting the user in control.

Henry


[1] https://github.com/w3ctag/client-certificates [2] https://github.com/w3ctag/client-certific= ates/issues/1
[3] https://github.com/= w3ctag/client-certificates/issues/1#issuecomment-194318303
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114bbc96896a79052d9fd0a1-- From nobody Wed Mar 9 08:16:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEB612D6B9 for ; Wed, 9 Mar 2016 08:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=bblfish-net.20150623.gappssmtp.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RkzDMYHkwB5M for ; Wed, 9 Mar 2016 08:14:24 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAFD612E0DC for ; Wed, 9 Mar 2016 08:08:08 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id p65so77720420wmp.0 for ; Wed, 09 Mar 2016 08:08:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=BR0y9OxcX1SJLX/qiJ/k8mDDJ6hxlkDU9N5oi9EpcMM=; b=2E/sUDjduxt9vOUETtHyrLigBG1P8LQD5q9yf/vsikZW7MPcrSozkB6M5LMcOZHvdr pNNK1FspmgZf5q8XounrSktr6xhOFwBj4LbANhLJ4yLJJJUrcn/qljz0eRHmkHiJgh/b /JDBF7Y3GpaMY/dC7v5+i87CSrjkcgwGImL55RVpKvZH4Pea2Zyq6wv08LTe3RJAZLE2 y5u7GWxZLdRK9u26+oWtrZ2ZR9jLsPK/uIX5sOSw1ZS+JtDreCZNgW/RX5aMBe46HwEd OJD0YJaBsdCTb4Syjqb0Lseqi53AbZ22PUPk9NQjJGQtYHkTosMFqdOJYSTha4UqAMjl FmEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=BR0y9OxcX1SJLX/qiJ/k8mDDJ6hxlkDU9N5oi9EpcMM=; b=mSrt9Mp/yvXonweCYprOEh4p3/16xZO9JeIgpEHqg1wFmPbneN82a5yJeVMONbhSUu 5T1RFkVqRHmqRQCYIofiKWjz5LhnAeL42l4PEoDKDNRRvPyDaDkbgI5qg9b92SX0hWnv KuDGq19wx5bgyBNJN4pPKXc6r1aeBeYTlqsGkShodExekrSZXyaV2V3EqkZM2UE6LgVx 64b1k1hp4SQEDDcY4zO5/eMEBhMvSSB9GfEPpisX0yVlCp+TdUvGJKnTNImy3Tb3qGlC 18phnXyu5YG+IMKV+yHp5wSsJ8uwIkL3QB8vhGRodtvTxxmr4Lj9qBB88sWvlcvqpa4A HtYQ== X-Gm-Message-State: AD7BkJLpbdNMwtn3GnDuduo1zpum0yzkwZE7WsB1npSSKsaFush+Ca+w3A1qV/0ZJUH/zA== X-Received: by 10.194.76.161 with SMTP id l1mr35845019wjw.108.1457539687448; Wed, 09 Mar 2016 08:08:07 -0800 (PST) Received: from [192.168.0.6] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net. [86.21.242.52]) by smtp.gmail.com with ESMTPSA id i5sm8564400wja.23.2016.03.09.08.08.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Mar 2016 08:08:05 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_4536DA63-4436-4DBB-A764-DEB58B3C0F7D" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Henry Story In-Reply-To: Date: Wed, 9 Mar 2016 16:08:28 +0000 Message-Id: <7656CF21-B80B-4378-8248-80F4A596151E@bblfish.net> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] X509 extension to specify use for only one origin? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 16:14:26 -0000 --Apple-Mail=_4536DA63-4436-4DBB-A764-DEB58B3C0F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 9 Mar 2016, at 16:01, Eric Rescorla wrote: >=20 > This is not a TLS WG issue. Where should I go to post this question? Sorry I don't know the full = ecosystem. Henry >=20 > -Ekr >=20 >=20 > On Wed, Mar 9, 2016 at 6:36 AM, Henry Story > wrote: > Hi, >=20 > The W3C TAG is working on a finding for Client Certificates that > people here should find very interesting [1]. >=20 > One issue that comes up a lot in discussions is the use of = certificates > across origins [2], which some folks find problematic, even though it > clearly has its uses [3]. >=20 > It seems that this could be solved neatly with an X509 extension > limiting usage to a certain origin or set of origins. I would not > be surprised if this already exists. With browser chrome support this > would allow the full range of uses from FIDO to cross origin ones > whilst putting the user in control. >=20 > Henry >=20 >=20 > [1] https://github.com/w3ctag/client-certificates = > [2] https://github.com/w3ctag/client-certificates/issues/1 = > [3] = https://github.com/w3ctag/client-certificates/issues/1#issuecomment-194318= 303 = > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_4536DA63-4436-4DBB-A764-DEB58B3C0F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 9 Mar 2016, at 16:01, Eric Rescorla <ekr@rtfm.com> = wrote:

This is not a TLS WG = issue.

Where = should I go to post this question? Sorry I don't know the full = ecosystem.

Henry


-Ekr


On Wed, = Mar 9, 2016 at 6:36 AM, Henry Story <henry.story@bblfish.net> wrote:
Hi,

  The W3C TAG is working on a finding for Client Certificates = that
people here should find very interesting [1].

One issue that comes up a lot in discussions is the use of = certificates
across origins [2], which some folks find problematic, even though it
clearly has its uses [3].

 It seems that this could be solved neatly with an X509 = extension
limiting usage to a certain origin or set of origins. I would not
be surprised if this already exists. With browser chrome support this
would allow the full range of uses from FIDO to cross origin ones
whilst putting the user in control.

Henry


[1] https://github.com/w3ctag/client-certificates
[2] https://github.com/w3ctag/client-certificates/issues/1
[3] https://github.com/w3ctag/client-certificates/issues/1#issuecom= ment-194318303
_______________________________________________
TLS mailing list
TLS@ietf.org
= https://www.ietf.org/mailman/listinfo/tls


= --Apple-Mail=_4536DA63-4436-4DBB-A764-DEB58B3C0F7D-- From nobody Wed Mar 9 08:17:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03FB12D61E for ; Wed, 9 Mar 2016 08:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVd4cwocClJs for ; Wed, 9 Mar 2016 08:15:46 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CB312DE4D for ; Wed, 9 Mar 2016 08:10:25 -0800 (PST) Received: by mail-yk0-x22b.google.com with SMTP id z7so22641218yka.0 for ; Wed, 09 Mar 2016 08:10:25 -0800 (PST) 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=Cqb3AnR2q4bdLNUvCB9diPWHUF7r8wnpxzft3+xpAS0=; b=B6BtI97eQKGD040hZCv2WfSw/qPVfX53vjPw2EJ+86fooidweECKP4kaaU6mvh7YVd rxgyEfgtEOtmJwb4ON7WYYoPaw0gIaCtWrds5lJ2rpa9BQMNp3rlVeESiCBr1TtQgo+1 tgEvmK5E7kolxTME0vxlvSd1b8VZ4JJGQDm57diZdzdSVFspw/RM0YQzODCZIIOXVR5o CUTq9C3DXwrfkXwXw3qHv8lqY3W6xqUvbhGJmjZbe1/OulaeG5Nd8FlwFwjKoeTnpqb+ SXAWwEWrwCLYushoj+SOp0x8Fht8/MFgIvRyyB9hcTQahw9ygFKoYqO5UdQVtz3dEmhX 7HPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cqb3AnR2q4bdLNUvCB9diPWHUF7r8wnpxzft3+xpAS0=; b=l/AXkOt2MxXD9PkTEd217NbQzyQGauAFn28Aub578Yg5g61BhmqES4INY33i76y/7z SDC+MIB9WX6OuQsTUx49Ov6c/mZ5nCDGFkPolbg7AJOlYBa3R/OtqXX82xzPV54MDTCK VYq0tF5vQyTnSboxC4T4RH5PDRBQ2/l60u7fRTC8Q1UGDUSJaQ3ANOXmYklisKGmXh4E PiPqrNSaOO6nd5GPpQ53JAwVKdseYEOPsf8hvCSUAI2cblGPNMImJHSbbw8zW/ruIqZh CtJIO+SOEk7x18mZhulyefmyns2yBYZsnrHdAjMuo0oggfpSF3codn6Gzhl2fY0WPCxE 42dg== X-Gm-Message-State: AD7BkJJ9p+w0KK4UHCt9NUayBPrUESlNmAUCEGkUH3BCMC/a295SLlkMrc9Yp6JAb9wBSDJw7bjXOsuiv3MUug== X-Received: by 10.37.89.134 with SMTP id n128mr11416863ybb.162.1457539821878; Wed, 09 Mar 2016 08:10:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 9 Mar 2016 08:09:42 -0800 (PST) In-Reply-To: <7656CF21-B80B-4378-8248-80F4A596151E@bblfish.net> References: <7656CF21-B80B-4378-8248-80F4A596151E@bblfish.net> From: Eric Rescorla Date: Wed, 9 Mar 2016 08:09:42 -0800 Message-ID: To: Henry Story Content-Type: multipart/alternative; boundary=001a1140f0e2547b47052d9fef96 Archived-At: Cc: "" Subject: Re: [TLS] X509 extension to specify use for only one origin? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 16:15:49 -0000 --001a1140f0e2547b47052d9fef96 Content-Type: text/plain; charset=UTF-8 Not sure who is managing certs now that PKIX is closed. Try SAAG. -Ekr On Wed, Mar 9, 2016 at 8:08 AM, Henry Story wrote: > > On 9 Mar 2016, at 16:01, Eric Rescorla wrote: > > This is not a TLS WG issue. > > > Where should I go to post this question? Sorry I don't know the full > ecosystem. > > Henry > > > -Ekr > > > On Wed, Mar 9, 2016 at 6:36 AM, Henry Story > wrote: > >> Hi, >> >> The W3C TAG is working on a finding for Client Certificates that >> people here should find very interesting [1]. >> >> One issue that comes up a lot in discussions is the use of certificates >> across origins [2], which some folks find problematic, even though it >> clearly has its uses [3]. >> >> It seems that this could be solved neatly with an X509 extension >> limiting usage to a certain origin or set of origins. I would not >> be surprised if this already exists. With browser chrome support this >> would allow the full range of uses from FIDO to cross origin ones >> whilst putting the user in control. >> >> Henry >> >> >> [1] https://github.com/w3ctag/client-certificates >> [2] https://github.com/w3ctag/client-certificates/issues/1 >> [3] >> https://github.com/w3ctag/client-certificates/issues/1#issuecomment-194318303 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > --001a1140f0e2547b47052d9fef96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not sure who is managing certs now that PKIX is close= d. Try SAAG.

-Ekr


On Wed, Mar 9, 2016 at = 8:08 AM, Henry Story <henry.story@bblfish.net> wrote:<= br>

<= div>
On 9 Mar 2016, at 16:01= , Eric Rescorla <ekr@r= tfm.com> wrote:

This is not a TL= S WG issue.

Where = should I go to post this question? Sorry I don't know the full ecosyste= m.

= Henry


-Ekr


On Wed, Mar 9, 2016 at= 6:36 AM, Henry Story <henry.story@bblfish.net> wrote:=
Hi,

=C2=A0 The W3C TAG is working on a finding for Client Certificates that
people here should find very interesting [1].

One issue that comes up a lot in discussions is the use of certificates
across origins [2], which some folks find problematic, even though it
clearly has its uses [3].

=C2=A0It seems that this could be solved neatly with an X509 extension
limiting usage to a certain origin or set of origins. I would not
be surprised if this already exists. With browser chrome support this
would allow the full range of uses from FIDO to cross origin ones
whilst putting the user in control.

Henry


[1] https://github.com/w3ctag/client-certificates [2] https://github.com/w3ctag/client-certific= ates/issues/1
[3] https://github.com/= w3ctag/client-certificates/issues/1#issuecomment-194318303
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--001a1140f0e2547b47052d9fef96-- From nobody Wed Mar 9 08:43:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A41812D769 for ; Wed, 9 Mar 2016 08:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_aquoOGfgAe for ; Wed, 9 Mar 2016 08:41:29 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 72D9A12D717 for ; Wed, 9 Mar 2016 08:41:29 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9BEEA433415; Wed, 9 Mar 2016 16:41:28 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 864BF433402; Wed, 9 Mar 2016 16:41:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457541688; bh=mfbeJdY+QBiktrZnarZKHav1L9/d+Ue5xUOn+oUk9+U=; l=4106; h=From:To:CC:Date:References:In-Reply-To:From; b=siaEmVw64joxY3HTMX5O8A5U4ctLH3ujZazYqBXPv/HDILLUMfRK6NddEK1e8MPxY rldcyUp1g8eaWKOxn3zU1NlFjKlpiYrrHdZVA4I1Kr6TnNgzmUHH2paqs+vxh+ce++ 5S3TgmJ6TetIhJbGw6NrIalerrfqhAGFw5rSj1uA= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 79EC71FC95; Wed, 9 Mar 2016 16:41:28 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 9 Mar 2016 11:41:28 -0500 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.1130.005; Wed, 9 Mar 2016 11:41:28 -0500 From: "Salz, Rich" To: Eric Rescorla , Henry Story Thread-Topic: [TLS] X509 extension to specify use for only one origin? Thread-Index: AQHRehXkJRwLRRgoA0qQpZd81ZIfM59RmWuAgAACEACAAABYAP//tPFA Date: Wed, 9 Mar 2016 16:41:27 +0000 Message-ID: <5dd98cb1073c46dd9a69f7ecd6450126@usma1ex-dag1mb1.msg.corp.akamai.com> References: <7656CF21-B80B-4378-8248-80F4A596151E@bblfish.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.44.86] Content-Type: multipart/alternative; boundary="_000_5dd98cb1073c46dd9a69f7ecd6450126usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] X509 extension to specify use for only one origin? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 09 Mar 2016 16:41:31 -0000 --_000_5dd98cb1073c46dd9a69f7ecd6450126usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gdGhlIG90aGVyIGhhbmQsIHdoaWxlIGl04oCZcyBub3QgYSBUTFMgaXNzdWUgcGVyLXNlLCB0 aGlzIGlzIHRoZSBwbGFjZSBtb3N0IGxpa2VseSB0byBoYXZlIGZvbGtzIHdobyBjYXJlIGFuZCBh cmUgaW50ZXJlc3RlZC4NCg0KLS0NClNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dp ZXMNCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNhbHoNCg== --_000_5dd98cb1073c46dd9a69f7ecd6450126usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpi O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPk9uIHRoZSBvdGhlciBoYW5kLCB3aGlsZSBpdOKAmXMgbm90IGEgVExTIGlz c3VlIHBlci1zZSwgdGhpcyBpcyB0aGUgcGxhY2UgbW9zdCBsaWtlbHkgdG8gaGF2ZSBmb2xrcyB3 aG8gY2FyZSBhbmQgYXJlIGludGVyZXN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tLSZuYnNwOw0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dp ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SU06IHJpY2hzYWx6QGphYmJlci5hdCBU d2l0dGVyOiBSaWNoU2FsejxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_5dd98cb1073c46dd9a69f7ecd6450126usma1exdag1mb1msgcorpak_-- From nobody Thu Mar 10 00:10:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D038212D58E for ; Thu, 10 Mar 2016 00:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 a5x4HDZ77zDa for ; Thu, 10 Mar 2016 00:10:36 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::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 5B7A612D524 for ; Thu, 10 Mar 2016 00:10:36 -0800 (PST) Received: by mail-pa0-x231.google.com with SMTP id fe3so45535075pab.1 for ; Thu, 10 Mar 2016 00:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=DRFAXi1KTRjNWTjNDODWFgJrGHhZbyZ81pk4V3ah9wo=; b=K1Tb05zOHgcCbcV021hMdlT5d5wf+3HK116j2eVFDchVj7ugMZ+ZE34feEO91QPskJ jDpnlEEBoBqZ3MpEJqvUrkq89HWAUgN64Eyht4oJeeIcxnTl+RLDh98Sekbkv39Bb5Q4 XLeX9RvyDNX7BEMEhsJ2wJw+HzUDvYLWOJ1mw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=DRFAXi1KTRjNWTjNDODWFgJrGHhZbyZ81pk4V3ah9wo=; b=jqkb+3Y/SxFugpmMjCtjD0+RTxjgci9pFeV1pPkfFx+UDR2ibDdj3IUIMHeZbRJNfr Qlmrj+v2xmxRJVt/kH+IwyJjQ92Wmo0NtfZN50eLcilZ2QMHDw3qcbmT1rAxMa1MFvlW 7xbzkL/hm73P6MyFiYlJQFfIJadBo+YVBZf+2K7occHCPeR4qP2HdfynHuYo+EPHtX9b YAB6S/rhWZuixyxarOTvXIt6jh91sX6kpvNIr4dMxKaR5NHsy2/HSZTfrMRHigcAl3MJ l+fcxSYM8XIOHsNi9Zf7+1FuAQiw6A/nsw2tMMtwU0imunh9Vo/lk9baTIfMndeT/8pU h8Qg== X-Gm-Message-State: AD7BkJJL6iE0fXjts8ISOlb4NDtA1ZzslZJ+hGenkShhpOAm6kWM+gZd4EcGsDmAzPfQzQ== X-Received: by 10.66.102.70 with SMTP id fm6mr3053768pab.98.1457597435960; Thu, 10 Mar 2016 00:10:35 -0800 (PST) Received: from [172.16.14.5] (p1026-ipbf310kyoto.kyoto.ocn.ne.jp. [122.22.5.26]) by smtp.gmail.com with ESMTPSA id xs10sm3406995pab.4.2016.03.10.00.10.34 for (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Mar 2016 00:10:35 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2016 17:10:33 +0900 References: <20160310080827.16522.87804.idtracker@ietfa.amsl.com> To: "" Message-Id: <7B4E8439-7938-4088-A4AE-562AAA1E9500@sn3rd.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] Fwd: Publication has been requested for draft-ietf-tls-chacha20-poly1305-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:10:37 -0000 FYI =E2=80=A6 > Begin forwarded message: >=20 > From: "Sean Turner" > Subject: Publication has been requested for = draft-ietf-tls-chacha20-poly1305-04 > Date: March 10, 2016 at 17:08:27 GMT+9 > To: > Cc: "Sean Turner" , iesg-secretary@ietf.org, = tls-chairs@ietf.org, sean@sn3rd.com >=20 > spt has requested publication of draft-ietf-tls-chacha20-poly1305-04 = as Proposed Standard on behalf of the TLS working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ >=20 From nobody Thu Mar 10 11:42:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87E712DC4E for ; Thu, 10 Mar 2016 11:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nl4UwH6m9CmM for ; Thu, 10 Mar 2016 11:42:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07DC12DC46 for ; Thu, 10 Mar 2016 11:42:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6847BBE51 for ; Thu, 10 Mar 2016 19:42:00 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq0IkMcvH0Qu for ; Thu, 10 Mar 2016 19:41:59 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 99158BE50 for ; Thu, 10 Mar 2016 19:41:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457638919; bh=k1deJXRF5edFjiarnMXGvrLxEKUfVdCbBXoOyu6nJAg=; h=To:From:Subject:Date:From; b=bdrW9spjOibUs10u1eeqLaIkPH+jr0foNTHIe4JuOtzkX2wfalcVa6lcnyEid1pKv gvk98fx+MERn2TTLTW6G+PtGOAJXBkUUbvqK818duFJDSRfoB9/jvlXWPdvWd4J+bT 5TCYhfru91UBJ9O35WnmsA5vLRt8EabVW0KgRyfs= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E1CE06.3020705@cs.tcd.ie> Date: Thu, 10 Mar 2016 19:41:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070401040009050904070609" Archived-At: Subject: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:42:38 -0000 This is a cryptographically signed message in MIME format. --------------ms070401040009050904070609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, This is ready to go but I've one question. Sorry I don't recall if this was discussed previously, if it was, then just say and I'll move this along to IETF LC. My question is: Should the WG take the opportunity to more tightly define the key exchange parameters for these ciphersuites? For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could REQUIRE RSA keys with >=3D2048 bit moduli and one could go further and say that this also REQUIRES use of specific integer DH groups. Etc etc. Getting all that agreed might take a wee while, so if the answer is "nah, no thanks, we don't want to do that here," that's fine and I'll just start IETF LC. I guess another way to handle that might be to say that these ciphersuites REQUIRE that all relevant restrictions from BCP195 be enforced. That'd maybe ensure the public key stuff is all at good strength, but doing so might not be so effective, in terms of trying to ensure these ciphersuites aren't used with e.g. short RSA keys. Whatchacha think? Cheers, S. --------------ms070401040009050904070609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTAx OTQxNThaMC8GCSqGSIb3DQEJBDEiBCC1Qng1J0IG/aJemCbxLDeyyVIWE0s1dv4ubzwjRyX5 JDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQC05whjOfZyp/bGjb4/V5i14w3f5JnXf0AUiyiFgJbOHkjLtzYAaqTV mR6oMQc/pBNwPlYW+0H2KFjVM3S1JZmadp+q9dY5xqczl3aHVfjgS+kzETS0as0B93od0Wb4 SoAuaCKB4qVyCYq2ssYMoqLVGTMmzKbZFf0urzhPlG4uAfgLCllbCt9Dn8mrZ8XwmeS4uiOz RbFPJxxWzlW1/T0Px/Wo1BO63u4X+q50rAVYgVEjbBuj6W99DKwnMfZhoHjBI40OWD6A3qqE zUwcVnnKztyCDeWvW9nQ5ApXxAKFmfxnTJykr4op52WZytSen9QG/aWZO25hcx1dS1ZII1DQ AAAAAAAA --------------ms070401040009050904070609-- From nobody Thu Mar 10 12:11:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA3212DC92 for ; Thu, 10 Mar 2016 12:11:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 eEaRNGqsfALv for ; Thu, 10 Mar 2016 12:11:28 -0800 (PST) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001: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 5981912DC87 for ; Thu, 10 Mar 2016 12:11:28 -0800 (PST) Received: by mail-ig0-x229.google.com with SMTP id av4so1896415igc.1 for ; Thu, 10 Mar 2016 12:11:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qIWvcpUkvDozbyXUe5t9eQKISbHoak1/X4MLu8lgwuQ=; b=ra3iT3UBIDRhCU6zMABxOINES0xqvUmvEhFXDz2vJbEBAVvu8ZSimqnFwbkpe3Hv+f NghPAAnxjkanaijBEJAFOkZ5riMX0HvqaoE9OzSrjohchdC9BJAQuQG6//ND6vTMVp1r q2N+m5omP3sOmUOkJbMTXwSPrqvRs5bReQSswpLfZUDxrgY1neNNbjOLBeT+LgjOOYQU dTjbYsp/77bsKIw88ihufIRDSgeNndVJbUjxDbTAxIMYwqVvmzTN73Zy6iGd1uFQ51KA zVsPkyphhG6kBhB4q7oZ4b0eU9E2vuuEixDahUcX/rn/EFz/6zM+GYspoVLBGeWVDSx3 jtAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qIWvcpUkvDozbyXUe5t9eQKISbHoak1/X4MLu8lgwuQ=; b=V3QjQMISSU/IUUb47fqSLnhl6WIac0jKqx0G5Eeivm76zCKS9cNYmlSudUv2bf0x3w 9t43kMtqWtld/9gWRiDdBAH+dOZhZZEJ1gfqoTPJS7x7Yz1gRr7eAvhEREhwmfWdKx/A nAMsnvO78ZmXcfjtcBR5foQTK7heQ7P4et91OxOEZM/WqiLr0oVxb8xtBVfouBJPGZ9H u88k56R2kTuMmrGuc1tjlYfJB78e36+tnr0jsZvc6KMOzN/mpqwjlvGN47+c/NMOMg6S U6yIFalAGX2GYn94e3fyB7TCyMNw8Tyid0Nl8fh9nyPyN0Y29rVGLuY8x0X2qobx/xgJ DrXg== X-Gm-Message-State: AD7BkJIlo0ZRX1Ot5iDsaub4+3PJzYjWXrKYQPj6ddgV+k4ySM2dJwMQMJPOBYv7+2uQP7/gTdDLAbCTilDwFA== X-Received: by 10.50.65.35 with SMTP id u3mr216949igs.3.1457640687550; Thu, 10 Mar 2016 12:11:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.64.213 with HTTP; Thu, 10 Mar 2016 12:11:08 -0800 (PST) In-Reply-To: <56E03023.1090703@gmx.net> References: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> <56E03023.1090703@gmx.net> From: Anirudh Ramachandran Date: Thu, 10 Mar 2016 12:11:08 -0800 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=047d7b3a93d2644a05052db76bcc Archived-At: Cc: Sean Turner , "" Subject: Re: [TLS] Fwd: Cached Info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:11:32 -0000 --047d7b3a93d2644a05052db76bcc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Since this is being discussed, I had an unrelated comment about the following wording: The draft says in Section 4: By returning the "cached_info" extension the server indicates that it supports the cached info types. For each indicated cached info type the server MUST alter the transmission of respective payloads, according to the rules outlined with each type The 'MUST' is likely to indicate to the client that a match has been found, which is useful. However, most SSL implementations (e.g,. OpenSSL) create and process messages one state at a time. The same buffer is reused for each handshake message, which means that only after the ServerHello message is constructed and sent is the Certificate message be constructed. If one were to follow the draft, there are two options =E2=80=93 either hold back = the ServerHello until the Certificate message is constructed and hashed, or early-construct the Certificate message while assembling the ServerHello. Both options introduce complications in implementation because the draft is asking to hash data from a later state during ServerHello. An alternative might be to use the ServerHello cached_info extension merely to indicate support of the extension, and indicate the cached info hit/miss during the Certificate message. This can already be done implicitly =E2=80= =94 If the Certificate message is of length exactly 4 bytes, the client looks up its CachedInformation store using the tuple to retrieve the correct cached Certificate message (a miss indicates a protocol error). We believe this lookup is needed anyway since a client might have multiple certificates stored per servername (e.g., both EC and RSA certs) and will anyways need to a lookup to figure out which Certificate should be picked. Was this issue discussed, or perhaps my read of the draft is wrong? Thanks, Anirudh On Wed, Mar 9, 2016 at 6:16 AM, Hannes Tschofenig wrote: > Hi all, > > in the off-list conversation I have also provided my remarks on the > raised issues. > > Here is what I said: > > ----------------- > > Thanks for spending the time to look at the document. > > There were indeed concerns about the length of the hash in the working > group and, as you said, there was specific attack raised. > > It is true that an attacker (or someone else) can create a certificate > that matches the hash of the certificate used by some other site, > particularly when the hash size is very small (4 bytes in our case). > > It appears to me that the vulnerability described below assumes that the > client is somehow tricked into accepting the wrong certificate. > > The client stores the hash of the obtained certificate locally after > completing a full handshake with the server. As such, it has to store > the server identity together with the hash. > > This cache then has to be populated with the certificate provided by the > adversary. > > The client then has to pick the wrong certificate, which matches the > fingerprint. > > Such a scenario can indeed happen if the client TLS implementation does > a lookup of the certificate based on the hash alone rather than taking > the server identity into account. > > In the other attack that Karthik described the client has to connect to > the malicious server and then that server would relay the messages to an > honest server and the signatures from the client would have to correctly > verify. I am missing a few assumptions about what else needs to go wrong > for this attack to work. Getting the honest server to just accept > relayed client certificate and a signature requires more than the TLS > Cached Info extension > > Regardless of the details I understand the concerns. There is indeed an > additional level of brittleness with the introduction of the shortened > hashes. While they consume less bandwidth over the wire (which is nice) > they require a careful implementation. > > ----------------- > > In a nutshell, while I do not believe that the attack described is > realistic I am sensitive to the problem of creating brittle code. > > If it is OK for the working group then I would like to revert back to > the previous version of the draft where we use the longer hash. > > Ciao > Hannes > > > On 03/08/2016 02:19 AM, Sean Turner wrote: > > All, > > > > The cached-info draft got all the way to the IESG and then we receive a > > couple of comments that require we bring the draft back to the WG to > > discuss. > > > > spt > > > >> Begin forwarded message: > >> > >> *From: *Karthikeyan Bhargavan >> > > >> *Subject: **Re: Cached Info* > >> *Date: *February 23, 2016 at 12:34:31 GMT+9 > >> *To: *Sean Turner >, Eric > >> Rescorla >, Martin Thomson > >> >, "Stephen > >> ie>" > > >> *Cc: *Antoine Delignat-Lavaud >> > > >> > >> Some corrections: > >> > >> Dear All, > >> > >> I took a quick look at cached-info at Ekr=E2=80=99 prodding, who was w= orried > >> about key synchronization-style attacks (Ekr=E2=80=99s original email = is a the > >> bottom of this email.) > >> My conclusion is that the use of a 4-byte hash is unnecessarily fragil= e. > >> The attacks are not super-serious, but the following scenario looks ba= d. > >> Maybe I got something wrong about the spec, so do tell me if I did. > >> > >> Suppose that the client uses client certificates (or channelID/token > >> binding) to login to all websites. > >> The client=E2=80=99s authentication credential is bound to the current > >> handshake transcript. > >> If the transcript does not contain the server certificate, then a > >> malicious server may be able > >> to forward a credential sent by the client to the malicious server to > >> a different server. > >> This kind of credential forwarding attack enables certain kinds of > >> impersonation (see Triple Handshake) > >> > >> In Cached-Info, the transcript includes a 32-bit hash of the > >> certificate and some signature or RSA encryption that uses the > >> certificate signing/encryption key. > >> To mount the attack described above, the attacker would first need to > >> find a certificate that collides with the honest server certificate > hash. > >> You can imagine the attacker generating 2^32 self-signed certificates > >> until the collision is found, this is not hard. > >> Next, the attacker still has to match the parts of the transcript that > >> use the server=E2=80=99s public key (if any). > >> The client could maybe choose the public key to match that of the > >> server, or carefully choose the RSA signing key to create a signature > >> value that matches that of the real server etc. > >> There may be other attacks where the attacker uses a static ECDH > >> ciphersuite, and so does not need to sign anything. > >> > >> So now, the honest client C connects to malicious server M that has a > >> self-signed cert (for M). > >> C accepts the cert (for M) and agrees to use certificate/token-bound > >> authentication at M. > >> M can then forward the credential and signature to S, which will > >> accept it. > >> M would not control the keys between M and S (since it used S=E2=80=99= s public > >> key.) > >> But if C is using a browser, then C=E2=80=99s window is at M=E2=80=99s= origin, so M > >> can inject > >> data into the connection which will then be forwarded to S, as if the > >> authenticated user C intended to send it to M. > >> > >> Perhaps the above attack is not very worrisome to some people, but the > >> silly > >> bit is that accepting this risk is completely unnecessary. The client > and > >> server could simply use the full SHA-256 hash for the certificate and > the > >> client would have a hard time creating a colliding certificate. > >> > >> Best, > >> Karthik > > > > > >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94 > >> Ekr=E2=80=99s original email > >> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94 > >> > >> Folks, > >> > >> I've been thinking over the cached-info draft, and I'm not convinced > >> that the security analysis is right. > >> > >> In the current design, the client sends a truncated 32-bit hash > >> of what it believes the server's certificate is. If that matches > >> the server's certificate, then the server echoes that truncated > >> hash (if I'm reading it correctly). > >> > >> The security considerations section claims: > >> > >> The use of the cached info extension allows the server to send > >> significantly smaller TLS messages. Consequently, these omitted > >> parts of the messages are not included in the transcript of the > >> handshake in the TLS Finish message. However, since the client and > >> the server communicate the hash values of the cached data in the > >> initial handshake messages the fingerprints are included in the TLS > >> Finish message. > >> > >> But this isn't correct with a short hash, since you're not strongly > >> binding the hash into the handshake. And elsewhere the text claims > >> that the hash isn't relevant: > >> > >> If an attacker > >> injects an incorrect fingerprint then two outcomes are possible: (1= ) > >> The fingerprint does not relate to any cached state and the server > >> has to fall back to a full exchange. (2) If the attacker manages to > >> inject a fingerprint that refers to data the client has not cached > >> then the exchange will fail later when the client continues with th= e > >> handshake and aims to verify the digital signature. The signature > >> verification will fail since the public key cached by the client wi= ll > >> not correspond to the private key that was used by server to sign t= he > >> message. > >> > >> I think this is closer to the truth. But consider the case where > >> an attacker convinces the client to accept a certificate for > >> attacker.com but with victim.com > >> 's public key that *also* > >> hash the same fingerprint as victim.com 's > >> certificate. In that case, > >> you could end up with a UKS between the client and victim.com > >> > >> (where the client thinks he's talking to attacker.com > >> ). What prevents > >> this (I believe) is the text in Security Considerations: > >> > >> Clients MUST ensure that they only cache information from legitimat= e > >> sources. For example, when the client populates the cache from a T= LS > >> exchange then it must only cache information after the successful > >> completion of a TLS exchange to ensure that an attacker does not > >> inject incorrect information into the cache. Failure to do so allo= ws > >> for man-in-the-middle attacks. > >> > >> If followed, this will stop the client from accepting attacker.com > >> 's > >> bogus cert (because he doesn't have the private key). Note, however, > that > >> you have to follow it strictly. For instance, if you cache after > >> False Start, then you are vulnerable to this attack. Also, these > >> instructions seem really counterintuitive, because naively you > >> would expect to just be able to validate the server's cert and > >> store the hash once it had been validated. I also note that this > >> advice was in the draft in -19 when the full hash was used. > >> > >> To be honest, I'm not entirely convinced that this advice is sufficien= t, > >> but I don't have a complete analysis either way. However, I do think > it's > >> clear that the text in the draft is confusing. > >> > >> Thoughts? > >> -Ekr > >> > > > > > > > > _______________________________________________ > > 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 > > --047d7b3a93d2644a05052db76bcc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since this is being discussed, I had an unrelated com= ment about the following wording:

The draft says i= n Section 4:

=C2=A0 =C2=A0By returning the "c= ached_info" extension the server indicates that it supports the
<= div>=C2=A0 =C2=A0cached info types.=C2=A0 For each indicated cached info ty= pe the server
=C2=A0 =C2=A0MUST alter the transmission of respect= ive payloads, according to the
=C2=A0 =C2=A0rules outlined with e= ach type

The 'MUST' is likely to indicate = to the client that a match has been found, which is useful. However, most S= SL implementations (e.g,. OpenSSL) create and process messages one state at= a time. The same buffer is reused for each handshake message, which means = that only after the ServerHello message is constructed and sent is the Cert= ificate message be constructed. If one were to follow the draft, there are = two options =E2=80=93 either hold back the ServerHello until the Certificat= e message is constructed and hashed, or early-construct the Certificate mes= sage while assembling the ServerHello. Both options introduce complications= in implementation because the draft is asking to hash data from a later st= ate during ServerHello.

An alternative might be to= use the ServerHello cached_info extension merely to indicate support of th= e extension, and indicate the cached info hit/miss during the Certificate m= essage. This can already be done implicitly =E2=80=94 If the Certificate me= ssage is of length exactly 4 bytes, the client looks up its CachedInformati= on store using the tuple <servername, server-supplied hash> to retrie= ve the correct cached Certificate message (a miss indicates a protocol erro= r). We believe this lookup is needed anyway since a client might have multi= ple certificates stored per servername (e.g., both EC and RSA certs) and wi= ll anyways need to a lookup to figure out which Certificate should be picke= d.

Was this issue discussed, or perhaps my read of= the draft is wrong?

Thanks,
Anirudh


On Wed, Mar 9, 2016 at 6:16 AM, Hannes Tschofenig &= lt;hannes.ts= chofenig@gmx.net> wrote:
Hi= all,

in the off-list conversation I have also provided my remarks on the
raised issues.

Here is what I said:

-----------------

Thanks for spending the time to look at the document.

There were indeed concerns about the length of the hash in the working
group and, as you said, there was specific attack raised.

It is true that an attacker (or someone else) can create a certificate
that matches the hash of the certificate used by some other site,
particularly when the hash size is very small (4 bytes in our case).

It appears to me that the vulnerability described below assumes that the client is somehow tricked into accepting the wrong certificate.

The client stores the hash of the obtained certificate locally after
completing a full handshake with the server. As such, it has to store
the server identity together with the hash.

This cache then has to be populated with the certificate provided by the adversary.

The client then has to pick the wrong certificate, which matches the
fingerprint.

Such a scenario can indeed happen if the client TLS implementation does
a lookup of the certificate based on the hash alone rather than taking
the server identity into account.

In the other attack that Karthik described the client has to connect to
the malicious server and then that server would relay the messages to an honest server and the signatures from the client would have to correctly verify. I am missing a few assumptions about what else needs to go wrong for this attack to work. Getting the honest server to just accept
relayed client certificate and a signature requires more than the TLS
Cached Info extension

Regardless of the details I understand the concerns. There is indeed an
additional level of brittleness with the introduction of the shortened
hashes. While they consume less bandwidth over the wire (which is nice)
they require a careful implementation.

-----------------

In a nutshell, while I do not believe that the attack described is
realistic I am sensitive to the problem of creating brittle code.

If it is OK for the working group then I would like to revert back to
the previous version of the draft where we use the longer hash.

Ciao
Hannes


On 03/08/2016 02:19 AM, Sean Turner wrote:
> All,
>
> The cached-info draft got all the way to the IESG and then we receive = a
> couple of comments that require we bring the draft back to the WG to > discuss.
>
> spt
>
>> Begin forwarded message:
>>
>> *From: *Karthikeyan Bhargavan <karthik.bhargavan@gmail.com
>> <mailto:karthik.= bhargavan@gmail.com>>
>> *Subject: **Re: Cached Info*
>> *Date: *February 23, 2016 at 12:34:31 GMT+9
>> *To: *Sean Turner <TurnerS@= ieca.com <mailto:TurnerS@ieca.co= m>>, Eric
>> Rescorla <ekr@rtfm.com <= mailto:ekr@rtfm.com>>, Martin Tho= mson
>> <martin.thomson@gma= il.com <mailto:martin.th= omson@gmail.com>>, "Stephen
>> ie>" <step= hen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie>>
>> *Cc: *Antoine Delignat-Lavaud <antdl@microsoft.com
>> <mailto:antdl@microsoft.= com>>
>>
>> Some corrections:
>>
>> Dear All,
>>
>> I took a quick look at cached-info at Ekr=E2=80=99 prodding, who w= as worried
>> about key synchronization-style attacks (Ekr=E2=80=99s original em= ail is a the
>> bottom of this email.)
>> My conclusion is that the use of a 4-byte hash is unnecessarily fr= agile.
>> The attacks are not super-serious, but the following scenario look= s bad.
>> Maybe I got something wrong about the spec, so do tell me if I did= .
>>
>> Suppose that the client uses client certificates (or channelID/tok= en
>> binding) to login to all websites.
>> The client=E2=80=99s authentication credential is bound to the cur= rent
>> handshake transcript.
>> If the transcript does not contain the server certificate, then a<= br> >> malicious server may be able
>> to forward a credential sent by the client to the malicious server= to
>> a different server.
>> This kind of credential forwarding attack enables certain kinds of=
>> impersonation (see Triple Handshake)
>>
>> In Cached-Info, the transcript includes a 32-bit hash of the
>> certificate and some signature or RSA encryption that uses the
>> certificate signing/encryption key.
>> To mount the attack described above, the attacker would first need= to
>> find a certificate that collides with the honest server certificat= e hash.
>> You can imagine the attacker generating 2^32 self-signed certifica= tes
>> until the collision is found, this is not hard.
>> Next, the attacker still has to match the parts of the transcript = that
>> use the server=E2=80=99s public key (if any).
>> The client could maybe choose the public key to match that of the<= br> >> server, or carefully choose the RSA signing key to create a signat= ure
>> value that matches that of the real server etc.
>> There may be other attacks where the attacker uses a static ECDH >> ciphersuite, and so does not need to sign anything.
>>
>> So now, the honest client C connects to malicious server M that ha= s a
>> self-signed cert (for M).
>> C accepts the cert (for M) and agrees to use certificate/token-bou= nd
>> authentication at M.
>> M can then forward the credential and signature to S, which will >> accept it.
>> M would not control the keys between M and S (since it used S=E2= =80=99s public
>> key.)
>> But if C is using a browser, then C=E2=80=99s window is at M=E2=80= =99s origin, so M
>> can inject
>> data into the connection which will then be forwarded to S, as if = the
>> authenticated user C intended to send it to M.
>>
>> Perhaps the above attack is not very worrisome to some people, but= the
>> silly
>> bit is that accepting this risk is completely unnecessary. The cli= ent and
>> server could simply use the full SHA-256 hash for the certificate = and the
>> client would have a hard time creating a colliding certificate. >>
>> Best,
>> Karthik
>
>
>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94
>> Ekr=E2=80=99s original email
>> =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94
>>
>> Folks,
>>
>> I've been thinking over the cached-info draft, and I'm not= convinced
>> that the security analysis is right.
>>
>> In the current design, the client sends a truncated 32-bit hash >> of what it believes the server's certificate is. If that match= es
>> the server's certificate, then the server echoes that truncate= d
>> hash (if I'm reading it correctly).
>>
>> The security considerations section claims:
>>
>>=C2=A0 =C2=A0 The use of the cached info extension allows the serve= r to send
>>=C2=A0 =C2=A0 significantly smaller TLS messages.=C2=A0 Consequentl= y, these omitted
>>=C2=A0 =C2=A0 parts of the messages are not included in the transcr= ipt of the
>>=C2=A0 =C2=A0 handshake in the TLS Finish message.=C2=A0 However, s= ince the client and
>>=C2=A0 =C2=A0 the server communicate the hash values of the cached = data in the
>>=C2=A0 =C2=A0 initial handshake messages the fingerprints are inclu= ded in the TLS
>>=C2=A0 =C2=A0 Finish message.
>>
>> But this isn't correct with a short hash, since you're not= strongly
>> binding the hash into the handshake. And elsewhere the text claims=
>> that the hash isn't relevant:
>>
>>=C2=A0 =C2=A0 If an attacker
>>=C2=A0 =C2=A0 injects an incorrect fingerprint then two outcomes ar= e possible: (1)
>>=C2=A0 =C2=A0 The fingerprint does not relate to any cached state a= nd the server
>>=C2=A0 =C2=A0 has to fall back to a full exchange. (2) If the attac= ker manages to
>>=C2=A0 =C2=A0 inject a fingerprint that refers to data the client h= as not cached
>>=C2=A0 =C2=A0 then the exchange will fail later when the client con= tinues with the
>>=C2=A0 =C2=A0 handshake and aims to verify the digital signature.= =C2=A0 The signature
>>=C2=A0 =C2=A0 verification will fail since the public key cached by= the client will
>>=C2=A0 =C2=A0 not correspond to the private key that was used by se= rver to sign the
>>=C2=A0 =C2=A0 message.
>>
>> I think this is closer to the truth. But consider the case where >> an attacker convinces the client to accept a certificate for
>> attacker.com <http://attacker.com/&= gt; but with victim.com
>> <http://victim.com/>'s public key that *also*
>> hash the same fingerprint as victim.com <http://victim.com/>'s<= br> >> certificate. In that case,
>> you could end up with a UKS between the client and victim.com
>> <http://victim.com/>
>> (where the client thinks he's talking to attacker.c= om
>> <http://attacker.com/>). What prevents
>> this (I believe) is the text in Security Consider= ations:
>>
>>=C2=A0 =C2=A0 Clients MUST ensure that they only cache information = from legitimate
>>=C2=A0 =C2=A0 sources.=C2=A0 For example, when the client populates= the cache from a TLS
>>=C2=A0 =C2=A0 exchange then it must only cache information after th= e successful
>>=C2=A0 =C2=A0 completion of a TLS exchange to ensure that an attack= er does not
>>=C2=A0 =C2=A0 inject incorrect information into the cache.=C2=A0 Fa= ilure to do so allows
>>=C2=A0 =C2=A0 for man-in-the-middle attacks.
>>
>> If followed, this will stop the client from accepting attacker.com >> <http://attacker.com/>'s
>> bogus cert (because he doesn't have = the private key). Note, however, that
>> you have to follow it strictly. For instance, if you cache after >> False Start, then you are vulnerable to this attack. Also, these >> instructions seem really counterintuitive, because naively you
>> would expect to just be able to validate the server's cert and=
>> store the hash once it had been validated. I also note that this >> advice was in the draft in -19 when the full hash was used.
>>
>> To be honest, I'm not entirely convinced that this advice is s= ufficient,
>> but I don't have a complete analysis either way. However, I do= think it's
>> clear that the text in the draft is confusing.
>>
>> Thoughts?
>> -Ekr
>>
>
>
>
> _______________________= ________________________
> 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


--047d7b3a93d2644a05052db76bcc-- From nobody Thu Mar 10 12:18:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793D012DCC6 for ; Thu, 10 Mar 2016 12:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goq2HZB-pCly for ; Thu, 10 Mar 2016 12:18:50 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1241C12DC87 for ; Thu, 10 Mar 2016 12:12:35 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4E2F0284F26; Thu, 10 Mar 2016 20:12:29 +0000 (UTC) Date: Thu, 10 Mar 2016 20:12:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160310201229.GG10917@mournblade.imrryr.org> References: <56E1CE06.3020705@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56E1CE06.3020705@cs.tcd.ie> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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 Mar 2016 20:18:51 -0000 On Thu, Mar 10, 2016 at 07:41:58PM +0000, Stephen Farrell wrote: > My question is: Should the WG take the opportunity to more > tightly define the key exchange parameters for these > ciphersuites? > > For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could > REQUIRE RSA keys with >=2048 bit moduli and one could go > further and say that this also REQUIRES use of specific > integer DH groups. I think that enforcing such a requirement for just new cipher-suites would be counterproductive. If a server has a 1024-bit RSA certificate or is configured with 1024-bit DH parameters, should it not offer CHACHA20, and restrict the client to AES or 3DES which don't have that contraint? What does that achieve? Or should the server go ahead with CHACHA20 and then the client refuse? I think it makes more sense to set such floors on a per-protocol basis (TLS 1.3, ...) than a per-cipher-suite basis. -- Viktor. From nobody Thu Mar 10 13:03:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6EF12DD88 for ; Thu, 10 Mar 2016 13:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 p6jeENJ1uriP for ; Thu, 10 Mar 2016 13:03:12 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9369812DD90 for ; Thu, 10 Mar 2016 13:02:57 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s5so39835065qkd.0 for ; Thu, 10 Mar 2016 13:02:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=HG3mrmVCrMElBCv45KW7eXXJGhjcBJzjNIrhDOub6HQ=; b=FIEFwhiX51vr7ow80o8zbAQMZMMldaIZG7ABFPIfuM1hLCeJ2QNHgJgobQAbzIP40J bZKhWG3V4tZIWbhSNEB/jrJuJbPmwYmJ445FZqAuiXZmendm8yrSU+1UFOeLMea5fTWX 0pxWystqthC+jj7gIOhIX+jMtQprJMmiuI+W6hnis8dJADZW388+MTk/iWLLC/4XrgCq v/XVMHCBbJWif5L1NGVxxg//Y82uWN4pPMv2GTfPHmTJc8Xk8B6Day1Ww0VCaEj2Fwc1 Gl3Qo6N00C0KSb+tZDmghZE9KOahNIeYWZ5VTeJwpq+l75jPhj4F1ggYVG+bjjRHbSd9 065Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=HG3mrmVCrMElBCv45KW7eXXJGhjcBJzjNIrhDOub6HQ=; b=D9mw/Jo/e00/c1CS0TGL1scI3Fm9q61kGHro5E0FVXOwsCFcVKVAhy5pEhI0c9U3Mv DxkSeOIfIJi6omekpc8y4G/a7/qQKxaEL2XOSdgRAWP4oMznpfgTG8z7efg5ZH3B8K6y N5cH+Yt2gR6/N5HbU1xtBfra0jy9+fayCUXExORPfjDCbL6p161B1OcpAza8zOLKzzyE E9EyuCAboY2VPvg4/tDnyAAZ5BQXkLg7E5jCkB/ABP7SgCr4ooceheVC4R+7N7Ba7hku 2qSd+9YEbXr3GlVUVUkbg7Np0yUEAIlSv7cEKI9BE68ePXH9LDk+NmMNzl/DWyc1yB2q 9zGw== X-Gm-Message-State: AD7BkJJJDoD7HQGxSNLRRbh88+rGRO7rlOzlneBHYfeP94lvHvXkvjIGJDSDRbl7+RGqMA== X-Received: by 10.55.74.9 with SMTP id x9mr6974863qka.81.1457643776254; Thu, 10 Mar 2016 13:02:56 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id 76sm2478736qhs.21.2016.03.10.13.02.55 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 10 Mar 2016 13:02:55 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Thu, 10 Mar 2016 16:02:53 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56E1CE06.3020705@cs.tcd.ie> In-Reply-To: <56E1CE06.3020705@cs.tcd.ie> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603101602.53898.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:03:16 -0000 On Thursday, March 10, 2016 02:41:58 pm Stephen Farrell wrote: > My question is: Should the WG take the opportunity to more > tightly define the key exchange parameters for these > ciphersuites? > > For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could > REQUIRE RSA keys with >=2048 bit moduli and one could go > further and say that this also REQUIRES use of specific > integer DH groups. Etc etc. This is a good idea that I think is likely to be impractical and could greatly hurt adoption, at least with regard to RSA. Requiring only secure (EC)DHE groups, however, I think is probably worth consideration. Both could be dealt with in a single TLS stack update, but requiring better certs is still a pain for entirely too many (hopefully this won't be true for that much longer). Dave From nobody Thu Mar 10 14:19:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB5312DC63 for ; Thu, 10 Mar 2016 14:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 2uBArTpeTdIt for ; Thu, 10 Mar 2016 14:19:47 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE7DB12D93B for ; Thu, 10 Mar 2016 14:19:46 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id n186so6025075wmn.1 for ; Thu, 10 Mar 2016 14:19:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=BHrBD4B4PIoiYM22d5vi3/krNHfAzOAoFrhZlMJZqR4=; b=IsuPsekZ1mTg3yi86FgF/34LfVcLWbWtLAMmsilp5VW0IFKLSasxtW9XyUbYtCSyJK d+vUNSaC2ybIAKa6vlKtqsqEbxDCPrPIw3MsMfqUzeCAxSRzNxJPADFJXeoSOWR4Ho19 76y1IBHi40jhxIBbfFrxbudXcLQ00MkHXhMAKgcbomzqA8YIlP9zeEPA7iDLOuLCqZdg extQ6U3YH6hMhNkQfRjJCIBbo+uGCoCUAJu9LV+GTjBHmBZvzJkBtWnixKtlaHXuJdVK j1QvnV2z5zWWO5Rs7lIiZbaC1C3Y13gnN/MY91J6OhQd/SUYpDdwBqkVewhWsrrrq7di NzgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=BHrBD4B4PIoiYM22d5vi3/krNHfAzOAoFrhZlMJZqR4=; b=hlSohoUARDJjUPMNgUv7r8xMIUKELgs1FEsk7QiuNG/6cK6hnztL4XMHdMKPbAPrjy /Ui2cDSJ+UyKC74vvQN1tliHe/i0HxdirVR3AtWscg/kI9dNhfJyoLSiFUfPy/POUFys w9aVpqIbQa9qQzjquMJnMezuHUCsKVdXBwfssj1D/fW5Y01L18Lt2I9tb8g/HIOV3QN0 E5Ps0t577uQIl+Yx9dMXtKHKDwOyM0gZKz/XvLptJ2VW0SbH5C0tdkQZ0wY8Wzql/jP7 oG+7mwPyaoPL32Z1zHfQEl+0uNdHLwgfsG+GLTcIDNz+2/hhg5zKKXh2aL/iXP6pYyls /w7A== X-Gm-Message-State: AD7BkJLPLcnFCzrxY0lS9YC9REWXotMF/IXBTOj7Iv+cZeQUMGC6/cBwtd+2LyV3ZAwnhg== X-Received: by 10.194.63.75 with SMTP id e11mr6281135wjs.79.1457648385127; Thu, 10 Mar 2016 14:19:45 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id vw2sm5463849wjc.43.2016.03.10.14.19.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 10 Mar 2016 14:19:44 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_79622F30-E65C-42C7-9006-E5EC5A4BC389"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <56E1CE06.3020705@cs.tcd.ie> Date: Fri, 11 Mar 2016 00:19:41 +0200 Message-Id: References: <56E1CE06.3020705@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:19:49 -0000 --Apple-Mail=_79622F30-E65C-42C7-9006-E5EC5A4BC389 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I agree with Viktor and Dave. RSA with keys greater at least 2048 bit is a good requirement that can = be made of old and new implementations. Even if for some reason you=E2=80=99= re stuck with OpenSSL 0.9.6 and thus with TLS 1.0 and 3DES, you can = conform to this requirement. I think it would be a shame to make that = requirement only of implementations while they=E2=80=99re using ChaCha. And yes, there=E2=80=99s nothing more wrong with using ChaCha with = 1024-bit RSA then there is with using AES with it. Yoav > On 10 Mar 2016, at 9:41 PM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > This is ready to go but I've one question. Sorry I don't > recall if this was discussed previously, if it was, then > just say and I'll move this along to IETF LC. >=20 > My question is: Should the WG take the opportunity to more > tightly define the key exchange parameters for these > ciphersuites? >=20 > For example, TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 could > REQUIRE RSA keys with >=3D2048 bit moduli and one could go > further and say that this also REQUIRES use of specific > integer DH groups. Etc etc. Getting all that agreed might > take a wee while, so if the answer is "nah, no thanks, we don't > want to do that here," that's fine and I'll just start IETF > LC. I guess another way to handle that might be to say that > these ciphersuites REQUIRE that all relevant restrictions > from BCP195 be enforced. That'd maybe ensure the public key > stuff is all at good strength, but doing so might not be so > effective, in terms of trying to ensure these ciphersuites > aren't used with e.g. short RSA keys. >=20 > Whatchacha think? >=20 > Cheers, > S. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_79622F30-E65C-42C7-9006-E5EC5A4BC389 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW4fL+AAoJECXR4BOacZZUHGsIAN6UVbrgLNwHieX8Ux03a9dG 6MEO20ir9w0na0fhh5Z7Jcas/Jy7F89AiDMy0Ob+lFVWlHOmUkX691KDxhCwrvPI w1hrH50afK72SmwaKnpxnLh65KqXaXU0rC+A+3oubQytkf68znu/ssrEbwkOT8QK 3vnuKLoiYnYT5/obxfE3uww0yZH4FW85ix0JUaygwDamLO5wKz9Gfk3XSsr4s626 imk1Of7KkKGT2r+4n07Et9AG2gvZsikL4cZIk9tJPrBcTN7/5wgpjCHaQbT9mKZ1 2dFTRLY10AYA5ngDurYcm9u5QnaF9OZWsQQwq6kn9jvUKwoGe2ZYxmeiVpZUgE0= =7KUL -----END PGP SIGNATURE----- --Apple-Mail=_79622F30-E65C-42C7-9006-E5EC5A4BC389-- From nobody Thu Mar 10 18:06:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C600A12DFB2 for ; Thu, 10 Mar 2016 18:06:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_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 nU-QoK3J1EUy for ; Thu, 10 Mar 2016 18:06:43 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 5062912DFB0 for ; Thu, 10 Mar 2016 18:06:43 -0800 (PST) Received: from [192.168.123.7] (unknown [75.83.2.34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 55CF1509B5 for ; Thu, 10 Mar 2016 21:06:42 -0500 (EST) To: tls@ietf.org References: <7656CF21-B80B-4378-8248-80F4A596151E@bblfish.net> <5dd98cb1073c46dd9a69f7ecd6450126@usma1ex-dag1mb1.msg.corp.akamai.com> From: Sean Leonard Message-ID: <56E227A7.7010300@seantek.com> Date: Thu, 10 Mar 2016 18:04:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <5dd98cb1073c46dd9a69f7ecd6450126@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------040604070604070906050108" Archived-At: Subject: Re: [TLS] X509 extension to specify use for only one origin? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 02:06:45 -0000 This is a multi-part message in MIME format. --------------040604070604070906050108 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I think it is interesting. A good place to take it up is the pkix mailing list anyway. See what people say. As far as experimenting, it is not difficult to create a new X.509/PKIX extension. Just create an OID for your experimental use in whatever arc you have at your disposal, and go. Sean On 3/9/2016 8:41 AM, Salz, Rich wrote: > > On the other hand, while its not a TLS issue per-se, this is the > place most likely to have folks who care and are interested. > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > --------------040604070604070906050108 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I think it is interesting. A good place to take it up is the pkix mailing list anyway. See what people say.

As far as experimenting, it is not difficult to create a new X.509/PKIX extension. Just create an OID for your experimental use in whatever arc you have at your disposal, and go.

Sean

On 3/9/2016 8:41 AM, Salz, Rich wrote:

On the other hand, while its not a TLS issue per-se, this is the place most likely to have folks who care and are interested.

--

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz



--------------040604070604070906050108-- From nobody Fri Mar 11 05:48:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3E712D6CB for ; Fri, 11 Mar 2016 05:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 GDlFHH1hX_R0 for ; Fri, 11 Mar 2016 05:48:00 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF49612D6C7 for ; Fri, 11 Mar 2016 05:47:55 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Udnq1s00m10HQrX01dnrfZ; Fri, 11 Mar 2016 14:47:52 +0100 Message-ID: <56E2CC85.1000209@openfortress.nl> Date: Fri, 11 Mar 2016 14:47:49 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] Kerberos + ECDHE in TLS (v02) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:48:06 -0000 Hello, I revised my TLS-KDH draft to include comments from this group. Thanks! The changes can be summarised as: * Integration with "normal" X.509 certificates; client may use krb5 certificate * Kerberos Ticket as X.509 pubkeyinfo; Authenticator as signature mechanism * Define TLS-standardised hashes as ChecksumTypes for use in an Authenticator * Moved TicketRequestFlags to a TLS Extension; negotiation with min/max flags * Taken out protocol-bound DH; this saves about 75% of the complexity * Pre-master secret now incorporates Kerberos session key and DH shared secret * Added descriptions of how to support backend servers in Ticket AuthData I am aware that embedding Kerberos in an X.509 certificate is uncommon; but it simplifies the rest incredibly, and suddenly everything "clicks" smoothly into the rest of TLS. I therefore think this form of "tunneling" certifying information is worth considering. Is this something that could be discussed at IETF 95? Cheers, -Rick > A new version of I-D, draft-vanrein-tls-kdh-02.txt > has been successfully submitted by Rick van Rein and posted to the > IETF repository. > > Name: draft-vanrein-tls-kdh > Revision: 02 > Title: TLS-KDH: Kerberos + Diffie-Hellman in TLS > Document date: 2016-03-11 > Group: Individual Submission > Pages: 23 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-tls-kdh-02.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-kdh-02 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-kdh-02 > > Abstract: > This specification defines a TLS message flow with Kerberos-based > (mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to > achieve Forward Secrecy for the session. From nobody Fri Mar 11 06:36:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A9712D7C8 for ; Fri, 11 Mar 2016 06:36:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 CscUr0muQlzT for ; Fri, 11 Mar 2016 06:36:25 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A638E12D767 for ; Fri, 11 Mar 2016 06:35:09 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id Ueb71s02010HQrX01eb8v6; Fri, 11 Mar 2016 15:35:08 +0100 Message-ID: <56E2D799.4030102@openfortress.nl> Date: Fri, 11 Mar 2016 15:35:05 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [TLS] New Draft: Symmetric TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:36:27 -0000 Hello, I wrote a straightforward I-D to permit Symmetric TLS, by which I mean letting go of predefined client/server roles. This is useful if the layers on top and/or below TLS are neutral in this respect. The approach is through a TLS Extension that holds a tie-breaker; both ends send a ClientHello containing such a random value. > Name: draft-vanrein-tls-symmetry > Revision: 01 > Title: Symmetry for Transport Layer Security > Document date: 2016-03-11 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet-drafts/draft-vanrein-tls-symmetry-01.txt > Status: https://datatracker.ietf.org/doc/draft-vanrein-tls-symmetry/ > Htmlized: https://tools.ietf.org/html/draft-vanrein-tls-symmetry-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-vanrein-tls-symmetry-01 > > Abstract: > TLS connections can be run over various transports, and can in turn > carry many application protocols. All current transports and at > least some application protocols are capable of running between > symmetric end points, in what could be called peer-to-peer mode, but > the use of TLS introduces a requirement to always assign a client and > server role. This specification defines a TLS Extension to remedy > that stringency of TLS. Cheers, -Rick From nobody Fri Mar 11 12:21:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C8612DB38 for ; Fri, 11 Mar 2016 12:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JksWMjoQBLd5 for ; Fri, 11 Mar 2016 12:21:14 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9936912DB3D for ; Fri, 11 Mar 2016 12:21:14 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.15.0.59/8.15.0.59) with SMTP id u2BKIUMp017271 for ; Fri, 11 Mar 2016 12:21:09 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=cWjnPF7zRlmmTNJlYX4tLNc6lUKwnsqqW4TGK/NN8Bw=; b=BWNhWInEt6sPsqMXaZj5VlNNsGETAfDgWwXDWVuOFbWxXoaPM7EHFmiBnCC2wz617Rl6 OIHOl1hPadm4pwMl6nduXh7dxrpEk5RrZc2CZHxCq3ia7yj+jolgIvRz5CxT4X9VcNiw lUCg1sOAJWwNZnDQEYjOBibQvhINrNsE9W4= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 21kg4mn0vr-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Fri, 11 Mar 2016 12:21:09 -0800 Received: from PRN-MBX02-1.TheFacebook.com ([169.254.2.203]) by PRN-CHUB14.TheFacebook.com ([fe80::5977:3d0b:700b:8bb%12]) with mapi id 14.03.0248.002; Fri, 11 Mar 2016 12:21:08 -0800 From: Kyle Nekritz To: "tls@ietf.org" Thread-Topic: [TLS] Limiting replay time frame of 0-RTT data Thread-Index: AdF70pHzy4ySAXIcRV+Hke2bem/g9A== Date: Fri, 11 Mar 2016 20:21:07 +0000 Message-ID: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D64EA3FPRNMBX021TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-11_10:, , signatures=0 Archived-At: Subject: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:21:17 -0000 --_000_8A79BFEDF6986C46996566F91BB63C860D64EA3FPRNMBX021TheFac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Similar to the earlier discussion on 0.5-RTT data, I'm concerned with the l= ong term ability to replay captured 0-RTT early data, and the attack vector= s that it opens up. For example, take a GET request for an image to a CDN. = This is a request that seems completely idempotent, and that applications w= ill surely want to send as 0-RTT data. However, this request can result in = a few things happening: 1) Resource unavailable 2) Resource cached locally at edge cluster 3) Cache miss, resource must be fetched from origin data center #1 can easily be differentiated by the length of the 0.5-RTT response data,= allowing an attacker to determine when a resource has been deleted/modifie= d. #2 and #3 can also be easily differentiated by the timing of the respons= e. This opens up the following attack: if an attacker knows a client has re= quested a resource X_i in the attacker-known set {X_1, X_2, ..., X_n}, an a= ttacker can do the following: 1) wait for the CDN cache to be evicted 2) request {X_1, X_2, ..., X_(n/2)} to warm the cache 3) replay the captured client early data (the request for X_i) 4) determine, based on the timing of the response, whether it resulted = in a cache hit or miss 5) repeat with set {X_1, X_2, ..., X_(n/2)} or {X_(n/2 + 1), X_(n/2 + 2= ), ..., X_n} depending on the result This particular binary search example is a little contrived and requires th= at no-one else is requesting any resource in the set, however I think it is= representative of a significant new attack vector that allowing long-term = replay of captured early data will open up, even if 0-RTT is only used for = seemingly simple requests without TLS client authentication. This is a much= different threat than very short-term replay, which is already somewhat po= ssible on any TLS protocol if clients retry failed requests. Given this, I think it is worth attempting to limit the time frame that cap= tured early data is useful to an attacker. This obviously doesn't prevent r= eplay, but it can mitigate a lot of attacks that long-term replay would ope= n up. This can be done by including a client time stamp along with early da= ta, so that servers can choose to either ignore the early data, or to delay= the 0.5-RTT response to 1.5-RTT if the time stamp is far off. This cuts do= wn the time from days (until the server config/session ticket key is rotate= d) to minutes or seconds. Including the client time also makes a client random strike register possib= le without requiring an unreasonably large amount of server-side state. I am aware that client time had previously been removed from the client ran= dom, primarily due to fingerprinting concerns, however these concerns can b= e mitigated by 1) clients can choose to not include their time (or to include a random tim= e), with only the risk of their .5-RTT data being delayed 2) placing the time stamp in an encrypted extension, so that it is not visi= ble to eavesdroppers Note: it's also useful for the server to know which edge cluster the early = data was intended for, however this is already possible in the current draf= t. In ECDHE 0-RTT server configs can be segmented by cluster, and with tick= ets, the server can store cluster information in the opaque ticket. --_000_8A79BFEDF6986C46996566F91BB63C860D64EA3FPRNMBX021TheFac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Similar to the earlier discussion on 0.5-RTT data, I= ’m concerned with the long term ability to replay captured 0-RTT earl= y data, and the attack vectors that it opens up. For example, take a GET re= quest for an image to a CDN. This is a request that seems completely idempotent, and that applications will surely want t= o send as 0-RTT data. However, this request can result in a few things happ= ening:
    1) Resource unavailable
    2) Resource cached locally at edge cluster
    3) Cache miss, resource must be fetched from origin data= center
#1 can easily be differentiated by the length of the 0.5-RTT response data,= allowing an attacker to determine when a resource has been deleted/modifie= d. #2 and #3 can also be easily differentiated by the timing of the respons= e. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the attacker= -known set {X_1, X_2, ..., X_n}, an attacker can do the following:
    1) wait for the CDN cache to be evicted
    2) request {X_1, X_2, …, X_(n/2)} to warm the cach= e
    3) replay the captured client early data (the request fo= r X_i)
    4) determine, based on the timing of the response, wheth= er it resulted in a cache hit or miss
    5) repeat with set {X_1, X_2, …, X_(n/2)} or {X_(n= /2 + 1), X_(n/2 + 2), …, X_n} depending on the result
This particular binary search example is a little contrived and requires th= at no-one else is requesting any resource in the set, however I think it is= representative of a significant new attack vector that allowing long-term = replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests without = TLS client authentication. This is a much different threat than very short-= term replay, which is already somewhat possible on any TLS protocol if clie= nts retry failed requests.

Given this, I think it is worth attempting to limit the time frame that cap= tured early data is useful to an attacker. This obviously doesn’t pre= vent replay, but it can mitigate a lot of attacks that long-term replay wou= ld open up. This can be done by including a client time stamp along with early data, so that servers can choose to e= ither ignore the early data, or to delay the 0.5-RTT response to 1.5-RTT if= the time stamp is far off. This cuts down the time from days (until the se= rver config/session ticket key is rotated) to minutes or seconds.

Including the client time also makes a client random strike register possib= le without requiring an unreasonably large amount of server-side state.

I am aware that client time had previously been removed from the client ran= dom, primarily due to fingerprinting concerns, however these concerns can b= e mitigated by
1) clients can choose to not include their time (or to include a random tim= e), with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not visi= ble to eavesdroppers


Note: it’s also useful for the server to know which edge cluster the = early data was intended for, however this is already possible in the curren= t draft. In ECDHE 0-RTT server configs can be segmented by cluster, and wit= h tickets, the server can store cluster information in the opaque ticket.

--_000_8A79BFEDF6986C46996566F91BB63C860D64EA3FPRNMBX021TheFac_-- From nobody Sat Mar 12 04:57:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A3F12D636 for ; Sat, 12 Mar 2016 04:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kjQ19YXJg5mi for ; Sat, 12 Mar 2016 04:57:09 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5189012D631 for ; Sat, 12 Mar 2016 04:57:09 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id g127so120195468ywf.2 for ; Sat, 12 Mar 2016 04:57:09 -0800 (PST) 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=RCAhmqVnG//gXOUxSl7vbnBALPtT6p3sOmVFUJTpQWc=; b=s0YaLIm2ecISuUteC1ugt+MjQ19um9FSQlOkdHtDtY89mm4sfyOaO5BJYmvC8jeAPe 5aFD+r2Xji3FhCn5MU5xAXwU2V48PPcp6J2zcn2CdIzrTEAnz3aMet1r1FJcgmO1U7K5 Dy8f6GomfjsvUlrhBZPapI54ymAxg+/evQIxQS2qhf2wiQ7CdVi/0MEPp8M2epOO1L2o fFeTxrGNGAldhqfIVyDMF7noZbg2KowSz0GQAQ+WiofXZ7tr1Bo4gTeIPNu9nlSKw/Bi UQKkeuuxhPv1ZjJLvRdlQB/k0z6jQSoHgr/2JGbszNHb31ypDtKF/TA6V93CiHz74Ket bw0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RCAhmqVnG//gXOUxSl7vbnBALPtT6p3sOmVFUJTpQWc=; b=JQv0E0vlfx/PnEtqk5R0e1BSbmyd7CxnpgH2a3mk7ydPbqlP2PUGwep6U9Wk4ddXSR idOfTN3i7nGO9+ORF/gTbkIxy29hTbn2qRKAQLOHrB8+a+EnOliOMH82wgm+0/VbTaWK x2pSNvZ8orO+O59aAjCcvzU6jDOGRF/RiR7/k8V9eF5V5upUrtdlAdQ/IETtC4VDPNT7 Iqdwmu/QpdlPZLRPe4wQRTM3TAJ48ICSviHFURacSHFsl+X9MyWewaWCcSByUNUGb/uF 4nxe/vOXY4a9dd+jZZNTYwSn9R+bkaWMRyYuAzkr8DLSlveRAbxRdG9WrNlQ9y/BpYNG 77BQ== X-Gm-Message-State: AD7BkJItOrV5XpXovXo54Z6My/q8VqANuDnSLfxKDLt0NKy/DzulgtfatC79PEZcCNn+gRzLczBIoU+tdKQzYQ== X-Received: by 10.13.218.198 with SMTP id c189mr8399226ywe.165.1457787428523; Sat, 12 Mar 2016 04:57:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sat, 12 Mar 2016 04:56:29 -0800 (PST) In-Reply-To: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> From: Eric Rescorla Date: Sat, 12 Mar 2016 13:56:29 +0100 Message-ID: To: Kyle Nekritz Content-Type: multipart/alternative; boundary=94eb2c08192ad60502052dd99532 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2016 12:57:11 -0000 --94eb2c08192ad60502052dd99532 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Kyle, Clever attack. I don't think it would be unreasonable to put a low granularity time stamp in the ClientHello (and as you observe, if we just define it it can be done backward compatibly) or as you suggest, in an encrypted block. With that said, though couldn't you also just include the information in the HTTP header for HTTP? Do you think this is a sufficiently general issue that it merits a change to TLS. -Ekr On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz wrote: > Similar to the earlier discussion on 0.5-RTT data, I=E2=80=99m concerned = with the > long term ability to replay captured 0-RTT early data, and the attack > vectors that it opens up. For example, take a GET request for an image to= a > CDN. This is a request that seems completely idempotent, and that > applications will surely want to send as 0-RTT data. However, this reques= t > can result in a few things happening: > 1) Resource unavailable > 2) Resource cached locally at edge cluster > 3) Cache miss, resource must be fetched from origin data center > #1 can easily be differentiated by the length of the 0.5-RTT response > data, allowing an attacker to determine when a resource has been > deleted/modified. #2 and #3 can also be easily differentiated by the timi= ng > of the response. This opens up the following attack: if an attacker knows= a > client has requested a resource X_i in the attacker-known set {X_1, X_2, > ..., X_n}, an attacker can do the following: > 1) wait for the CDN cache to be evicted > 2) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the cache > 3) replay the captured client early data (the request for X_i) > 4) determine, based on the timing of the response, whether it resulte= d > in a cache hit or miss > 5) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_(n/2 + 1), X_= (n/2 + > 2), =E2=80=A6, X_n} depending on the result > This particular binary search example is a little contrived and requires > that no-one else is requesting any resource in the set, however I think i= t > is representative of a significant new attack vector that allowing > long-term replay of captured early data will open up, even if 0-RTT is on= ly > used for seemingly simple requests without TLS client authentication. Thi= s > is a much different threat than very short-term replay, which is already > somewhat possible on any TLS protocol if clients retry failed requests. > > Given this, I think it is worth attempting to limit the time frame that > captured early data is useful to an attacker. This obviously doesn=E2=80= =99t > prevent replay, but it can mitigate a lot of attacks that long-term repla= y > would open up. This can be done by including a client time stamp along wi= th > early data, so that servers can choose to either ignore the early data, o= r > to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. Th= is > cuts down the time from days (until the server config/session ticket key = is > rotated) to minutes or seconds. > > Including the client time also makes a client random strike register > possible without requiring an unreasonably large amount of server-side > state. > > I am aware that client time had previously been removed from the client > random, primarily due to fingerprinting concerns, however these concerns > can be mitigated by > 1) clients can choose to not include their time (or to include a random > time), with only the risk of their .5-RTT data being delayed > 2) placing the time stamp in an encrypted extension, so that it is not > visible to eavesdroppers > > > Note: it=E2=80=99s also useful for the server to know which edge cluster = the early > data was intended for, however this is already possible in the current > draft. In ECDHE 0-RTT server configs can be segmented by cluster, and wit= h > tickets, the server can store cluster information in the opaque ticket. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c08192ad60502052dd99532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kyle,

Clever attack. I don't thi= nk it would be unreasonable to put a low granularity time stamp in the
ClientHello (and as you observe, if we just define it it can be done = backward compatibly)
or as you suggest, in an encrypted block. Wi= th that said, though couldn't you
also just include the infor= mation in the HTTP header for HTTP? Do you think this is a sufficiently
general issue that it merits a change to TLS.

-Ekr


On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz <knekritz@fb.= com> wrote:

Similar to the earlier discussion on 0.5-RTT data, I= =E2=80=99m concerned with the long term ability to replay captured 0-RTT ea= rly data, and the attack vectors that it opens up. For example, take a GET = request for an image to a CDN. This is a request that seems completely idempotent, and that applications will surely want t= o send as 0-RTT data. However, this request can result in a few things happ= ening:
=C2=A0 =C2=A0=C2=A01) Resource unavailable
=C2=A0 =C2=A0=C2=A02) Resource cached locally at edge cluster
=C2=A0 =C2=A0=C2=A03) Cache miss, resource must be fetched from origin data= center
#1 can easily be differentiated by the length of the 0.5-RTT response data,= allowing an attacker to determine when a resource has been deleted/modifie= d. #2 and #3 can also be easily differentiated by the timing of the respons= e. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the attacker= -known set {X_1, X_2, ..., X_n}, an attacker can do the following:
=C2=A0 =C2=A0=C2=A01) wait for the CDN cache to be evicted
=C2=A0 =C2=A0=C2=A02) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the ca= che
=C2=A0 =C2=A0=C2=A03) replay the captured client early data (the request fo= r X_i)
=C2=A0 =C2=A0=C2=A04) determine, based on the timing of the response, wheth= er it resulted in a cache hit or miss
=C2=A0 =C2=A0=C2=A05) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_= (n/2 + 1), X_(n/2 + 2), =E2=80=A6, X_n} depending on the result
This particular binary search example is a little contrived and requires th= at no-one else is requesting any resource in the set, however I think it is= representative of a significant new attack vector that allowing long-term = replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests without = TLS client authentication. This is a much different threat than very short-= term replay, which is already somewhat possible on any TLS protocol if clie= nts retry failed requests.

Given this, I think it is worth attempting to limit the time frame that cap= tured early data is useful to an attacker. This obviously doesn=E2=80=99t p= revent replay, but it can mitigate a lot of attacks that long-term replay w= ould open up. This can be done by including a client time stamp along with early data, so that servers can choose to e= ither ignore the early data, or to delay the 0.5-RTT response to 1.5-RTT if= the time stamp is far off. This cuts down the time from days (until the se= rver config/session ticket key is rotated) to minutes or seconds.

Including the client time also makes a client random strike register possib= le without requiring an unreasonably large amount of server-side state.

I am aware that client time had previously been removed from the client ran= dom, primarily due to fingerprinting concerns, however these concerns can b= e mitigated by
1) clients can choose to not include their time (or to include a random tim= e), with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not visi= ble to eavesdroppers


Note: it=E2=80=99s also useful for the server to know which edge cluster th= e early data was intended for, however this is already possible in the curr= ent draft. In ECDHE 0-RTT server configs can be segmented by cluster, and w= ith tickets, the server can store cluster information in the opaque ticket.


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


--94eb2c08192ad60502052dd99532-- From nobody Sat Mar 12 09:46:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1102A12D62C for ; Sat, 12 Mar 2016 09:46:12 -0800 (PST) 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 hLVdCk9EEjnI for ; Sat, 12 Mar 2016 09:46:09 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F1912D62B for ; Sat, 12 Mar 2016 09:46:09 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id l68so54231104wml.1 for ; Sat, 12 Mar 2016 09:46:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=s7GtUimwlnCygB0ZIHW28YJ+aoygo07/YlaPfSCLnvk=; b=QXb0pCJT97Plk6B5YuvMlmB/upU7GxXHGMw3BiF+3zrWtfL+tMHGyUG6mwRO266Cm9 P7apI+Bmx5fq0+VKfUrT1kYYeGfuRuRJva+20tKOevJ/C+uZd+Q6m4Q5X2uTUGlTMYs+ kyEy8fqjLKhFiw19bC7X64+KYmNanLID74DyyvfA9DyNvtrHQz84Wpo+2hUa2LZYRXIc /kAH+MIhr7QRXdKVT+uyCyavQQR1mutlrsvemjpXrWvGmob2rbQGPCoWrD4d6dt5ObyX ugQPlKKGl1WIt/nEbGWvV69IPr0xX8Vq4Tdz+T2b49l/Q/8Y5CBjrYDQDfuwPKz3WQsm dqqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=s7GtUimwlnCygB0ZIHW28YJ+aoygo07/YlaPfSCLnvk=; b=SyrN6+JsOlsExDEE/mFysxkNo5Si2/2GjZNox4N5iA4hjgya3cSg9U5KtWU8RPN/QS 52h0+p/B6vm/dBgRf29oVmLQlHhSI9TVds7b9BHPeVue4ykAt+IKIw7wx+GPlPC12HdH exETxWnjCfT8LQOsXCMRqYVAXyuXsLNU25KmiqmFJPOTcIPfaVlXrPDXIsxktq38qKeq XYrE0/Pm95+Kd+hsBDt1Mm5cSkX+vtHSnIK7CJCBGEEK5p+iXg7CJMaC7RgIdJfyKKRU BplUcTLpeb1re/3LALaFIsecEJPYQAKrMOIhw2KYqGqwBS+rL1Ddz73RGFiR3Sv7+buV ZGiw== X-Gm-Message-State: AD7BkJLCtOEoUHKh8sXqc6T+A2EJ3NVsTL/uXVwSo0ZZ2Byh5aGpA3TN4svZz4Nne5qDcw== X-Received: by 10.28.35.16 with SMTP id j16mr9096069wmj.78.1457804767558; Sat, 12 Mar 2016 09:46:07 -0800 (PST) Received: from [192.168.0.16] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id ka4sm14061864wjc.47.2016.03.12.09.46.06 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 12 Mar 2016 09:46:06 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3A8AAD93-D6BA-4138-AE06-1BFB09EE5886" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sat, 12 Mar 2016 18:45:48 +0100 Message-Id: <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2016 17:46:12 -0000 --Apple-Mail=_3A8AAD93-D6BA-4138-AE06-1BFB09EE5886 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Kyle, In my talk at TRON, I was also concerned by potential attacks from = allowing=20 unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers = should implement replay protection using a cache, but requiring clients to = provide a timestamp in the client random is a great idea. Perhaps this would = also allow TLS 1.3 servers to detect clients whose clocks are too out-of-sync = with the server (and hence vulnerable to expired certificates)? Best, Karthik > On 12 Mar 2016, at 13:56, Eric Rescorla wrote: >=20 > Hi Kyle, >=20 > Clever attack. I don't think it would be unreasonable to put a low = granularity time stamp in the > ClientHello (and as you observe, if we just define it it can be done = backward compatibly) > or as you suggest, in an encrypted block. With that said, though = couldn't you > also just include the information in the HTTP header for HTTP? Do you = think this is a sufficiently > general issue that it merits a change to TLS. >=20 > -Ekr >=20 >=20 > On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz > wrote: > Similar to the earlier discussion on 0.5-RTT data, I=E2=80=99m = concerned with the long term ability to replay captured 0-RTT early = data, and the attack vectors that it opens up. For example, take a GET = request for an image to a CDN. This is a request that seems completely = idempotent, and that applications will surely want to send as 0-RTT = data. However, this request can result in a few things happening: > 1) Resource unavailable > 2) Resource cached locally at edge cluster > 3) Cache miss, resource must be fetched from origin data center > #1 can easily be differentiated by the length of the 0.5-RTT response = data, allowing an attacker to determine when a resource has been = deleted/modified. #2 and #3 can also be easily differentiated by the = timing of the response. This opens up the following attack: if an = attacker knows a client has requested a resource X_i in the = attacker-known set {X_1, X_2, ..., X_n}, an attacker can do the = following: > 1) wait for the CDN cache to be evicted > 2) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the cache > 3) replay the captured client early data (the request for X_i) > 4) determine, based on the timing of the response, whether it = resulted in a cache hit or miss > 5) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_(n/2 + 1), = X_(n/2 + 2), =E2=80=A6, X_n} depending on the result > This particular binary search example is a little contrived and = requires that no-one else is requesting any resource in the set, however = I think it is representative of a significant new attack vector that = allowing long-term replay of captured early data will open up, even if = 0-RTT is only used for seemingly simple requests without TLS client = authentication. This is a much different threat than very short-term = replay, which is already somewhat possible on any TLS protocol if = clients retry failed requests. >=20 > Given this, I think it is worth attempting to limit the time frame = that captured early data is useful to an attacker. This obviously = doesn=E2=80=99t prevent replay, but it can mitigate a lot of attacks = that long-term replay would open up. This can be done by including a = client time stamp along with early data, so that servers can choose to = either ignore the early data, or to delay the 0.5-RTT response to = 1.5-RTT if the time stamp is far off. This cuts down the time from days = (until the server config/session ticket key is rotated) to minutes or = seconds. >=20 > Including the client time also makes a client random strike register = possible without requiring an unreasonably large amount of server-side = state. >=20 > I am aware that client time had previously been removed from the = client random, primarily due to fingerprinting concerns, however these = concerns can be mitigated by > 1) clients can choose to not include their time (or to include a = random time), with only the risk of their .5-RTT data being delayed > 2) placing the time stamp in an encrypted extension, so that it is not = visible to eavesdroppers >=20 >=20 > Note: it=E2=80=99s also useful for the server to know which edge = cluster the early data was intended for, however this is already = possible in the current draft. In ECDHE 0-RTT server configs can be = segmented by cluster, and with tickets, the server can store cluster = information in the opaque ticket. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_3A8AAD93-D6BA-4138-AE06-1BFB09EE5886 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Kyle,

In= my talk at TRON, I was also concerned by potential attacks from = allowing 
unlimited replay of 0-RTT data. I = recommended that TLS 1.3 servers should
implement = replay protection using a cache, but requiring clients to = provide
a timestamp in the client random is a great = idea. Perhaps this would also
allow TLS 1.3 servers = to detect clients whose clocks are too out-of-sync with
the server (and hence vulnerable to expired = certificates)?

Best,
Karthik

On = 12 Mar 2016, at 13:56, Eric Rescorla <ekr@rtfm.com> wrote:

Hi Kyle,

Clever attack. I don't think it would be unreasonable to put = a low granularity time stamp in the
ClientHello = (and as you observe, if we just define it it can be done backward = compatibly)
or as you suggest, in an encrypted = block. With that said, though couldn't you
also = just include the information in the HTTP header for HTTP? Do you think = this is a sufficiently
general issue that it merits = a change to TLS.

-Ekr


On Fri, = Mar 11, 2016 at 9:21 PM, Kyle Nekritz <knekritz@fb.com> wrote:

Similar to the earlier discussion = on 0.5-RTT data, I=E2=80=99m concerned with the long term ability to = replay captured 0-RTT early data, and the attack vectors that it opens = up. For example, take a GET request for an image to a CDN. This is a = request that seems completely idempotent, and that applications will surely = want to send as 0-RTT data. However, this request can result in a few = things happening:
    1) Resource unavailable
    2) Resource cached locally at edge cluster
    3) Cache miss, resource must be fetched from origin = data center
#1 can easily be differentiated by the length of the 0.5-RTT response = data, allowing an attacker to determine when a resource has been = deleted/modified. #2 and #3 can also be easily differentiated by the = timing of the response. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the = attacker-known set {X_1, X_2, ..., X_n}, an attacker can do the = following:
    1) wait for the CDN cache to be evicted
    2) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the = cache
    3) replay the captured client early data (the request = for X_i)
    4) determine, based on the timing of the response, = whether it resulted in a cache hit or miss
    5) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or = {X_(n/2 + 1), X_(n/2 + 2), =E2=80=A6, X_n} depending on the result
This particular binary search example is a little contrived and requires = that no-one else is requesting any resource in the set, however I think = it is representative of a significant new attack vector that allowing = long-term replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests = without TLS client authentication. This is a much different threat than = very short-term replay, which is already somewhat possible on any TLS = protocol if clients retry failed requests.

Given this, I think it is worth attempting to limit the time frame that = captured early data is useful to an attacker. This obviously doesn=E2=80=99= t prevent replay, but it can mitigate a lot of attacks that long-term = replay would open up. This can be done by including a client time stamp along with early data, so that servers can choose = to either ignore the early data, or to delay the 0.5-RTT response to = 1.5-RTT if the time stamp is far off. This cuts down the time from days = (until the server config/session ticket key is rotated) to minutes or seconds.

Including the client time also makes a client random strike register = possible without requiring an unreasonably large amount of server-side = state.

I am aware that client time had previously been removed from the client = random, primarily due to fingerprinting concerns, however these concerns = can be mitigated by
1) clients can choose to not include their time (or to include a random = time), with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not = visible to eavesdroppers


Note: it=E2=80=99s also useful for the server to know which edge cluster = the early data was intended for, however this is already possible in the = current draft. In ECDHE 0-RTT server configs can be segmented by = cluster, and with tickets, the server can store cluster information in the opaque ticket.

=

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


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

= --Apple-Mail=_3A8AAD93-D6BA-4138-AE06-1BFB09EE5886-- From nobody Sat Mar 12 11:33:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA6412D804 for ; Sat, 12 Mar 2016 11:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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=briansmith-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 OZj_x9XFDmra for ; Sat, 12 Mar 2016 11:33:39 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::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 244E812D801 for ; Sat, 12 Mar 2016 11:33:29 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id ts10so143036374obc.1 for ; Sat, 12 Mar 2016 11:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wO7Rut2jb0Ea8iRZ1cipxjXYkJoJ6p9Ix5boUOdICqY=; b=O3/yT68wcO7qL49DQTfTfYdmG2TamLLBd+6QsfQqZYSmpr+1JhQM9KSPjQwkCxQPBZ 2t/9YzemRIAVim4TDa7w2fQw03W5G474VoC5YHzlgaAqnJ/6g70oPPllaUNQW1krKOre pzsZO5EEeT7kmguoWKxNISgWqlj2mArzATvjaOaXtwfCzMJT7nEDiHKXqmda55NCZy35 j6eqwLdBqHXk+VVOt5sUO/6DRePRpHHePJP3qua5ZQwHp7/CkSpPCE6wwo9qq6eq2GYL F1Q/IctEqRa9AgKMkqL5iwM2r/vFU3OtJrO0it7y24rfOxlfHHxp/8xdUJ36ye7cPNlr ofPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wO7Rut2jb0Ea8iRZ1cipxjXYkJoJ6p9Ix5boUOdICqY=; b=kY9iKm1djlTQxTpvgLgMje+QRgN0c4YmrcTJvZMcgMdn5LTB4aaazMdoPLwNYqi7AE rAwUMBTrwDryl3iA99TcnUmSCbK5GGBYfY0d8MgshDEULYymPdYFSy066O4Trp4B5LIp wlxc7LmSFc1k0ogxzcMYn/m5R3+HjpImQthhg581cuWx2GI5up/4x/Rrw9xQ+sE3SYTG pqElsh4XBaCaiKiKg/QsV0KrLDpkQSzOrGSyxmIm4IcNq+Gkk3eQtTfuqkUljYefxB1z TkWvFsLBs9ulqz3YHLDUckGSn6SiXzp3CnTMM2Gd/PsEjU9FxnZ2b8YgY/C1909+pSq0 H4cw== X-Gm-Message-State: AD7BkJJ87i500RzwqMicA9UnVoZyw8CGmBbhI6+AkdWzt1jaeE5tHlP+41t8MQCXC9QzhXXGo86wYFSB3rCV5w== MIME-Version: 1.0 X-Received: by 10.60.128.163 with SMTP id np3mr9962369oeb.16.1457811208510; Sat, 12 Mar 2016 11:33:28 -0800 (PST) Received: by 10.76.37.231 with HTTP; Sat, 12 Mar 2016 11:33:28 -0800 (PST) In-Reply-To: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> Date: Sat, 12 Mar 2016 09:33:28 -1000 Message-ID: From: Brian Smith To: Kyle Nekritz Content-Type: multipart/alternative; boundary=047d7b417dc73bbbad052ddf1ff9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 12 Mar 2016 19:33:43 -0000 --047d7b417dc73bbbad052ddf1ff9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 11, 2016 at 10:21 AM, Kyle Nekritz wrote: > Note: it=E2=80=99s also useful for the server to know which edge cluster = the early > data was intended for, however this is already possible in the current > draft. In ECDHE 0-RTT server configs can be segmented by cluster, and wit= h > tickets, the server can store cluster information in the opaque ticket. Shouldn't the server also put a 0-RTT timestamp in the opaque ticket and then implement the same time limiting you suggest using that timestamp? That way, the timestamp would be authenticated and would not leak the client's system time information. Note that this would be better than relying on HTTP timestamps because it would work for any protocol, not just HTTP. Cheers, Brian --=20 https://briansmith.org/ --047d7b417dc73bbbad052ddf1ff9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Mar 11, 2016 at 10:21 AM, Kyle Nekritz <knekritz@fb.com> wrote:
Note: it=E2=80=99s also useful = for the server to know which edge cluster the early data was intended for, = however this is already possible in the current draft. In ECDHE 0-RTT serve= r configs can be segmented by cluster, and with tickets, the server can sto= re cluster information in the opaque ticket.

Shouldn't the = server also put a 0-RTT timestamp in the opaque ticket and then implement t= he same time limiting you suggest using that timestamp? That way, the times= tamp would be authenticated and would not leak the client's system time= information.

Note that this would be better than relying on HTTP timestamps beca= use it would work for any protocol, not just HTTP.

Cheers,
Brian
--
--047d7b417dc73bbbad052ddf1ff9-- From nobody Sat Mar 12 18:49:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E7C12D952 for ; Sat, 12 Mar 2016 18:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 b-hYbfeBtUEi for ; Sat, 12 Mar 2016 18:49:41 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::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 6000512D8AE for ; Sat, 12 Mar 2016 18:49:41 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id fz5so147523457obc.0 for ; Sat, 12 Mar 2016 18:49:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=vVYEoWI2ALhJvHG5EO64To2iTiXR1+anMruJx8gDVMs=; b=x3Fk3NpufTpvtoe7ZADoNg4+19o492yBy0oGMv8QZewWrh28oHagTTpZRmmspACpw3 q2pVnqb9WL6X9GEsdcc7HpNBfdOVaGcoutoaAalpnG4arDWwDNlGf66uNaiLeUYRaSju 5zDJG6mCof2gt/UQTdoaZRsQCpK58BpcdamBwSYeDMNY4kf0aVUyKvEQWK17I3mxJBYT tfM2XGfCXm79XDWBnZNvIxjytnENCnOzjw6Me8YkI7c5Jlm+NzCdzRw5J2FcdR9/3GvC /Mb5frJEuMvrOV+Ukg6aTWerZcze+jGZzLIZC7wChU68eNGYZfBMhQPx0793jHbe2P5+ yTdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vVYEoWI2ALhJvHG5EO64To2iTiXR1+anMruJx8gDVMs=; b=JO6n4Br9eJlXuvZLGmDKz+8n6o5PgCCNhTN5iX+llzOtWC8fM6Rq+fTsA5cJ+xzGiw bacfeHsbKGvAJGUTPPMgyFEq0LFlAHjwVr7ERAKqC7hM2DxNbfPXV9HYoIAvUIHOxbAC YS032l6xd/gdY/9Z+uSptP80ONvtiRxzvwdmzIh8XmD6bHP3IrNqo39pmZXcxAmj/vHF Q0C2e8P3/JrecesgEL89SX415bPVzlqlfqmql49obu86rHxy3IpAENtB/9nG22rcvqhK lEWxPpp32btV4hUjLJJyntn/eH79EaCGByIXTj/8UALKno+m2CzLu40Z8ZecZLaicQCX Nvvw== X-Gm-Message-State: AD7BkJIClyg2q/3jfRYX4hG3P8DyLmB1mW00bt15d8q6dfsWcyj2UPj1mcRZHYfnRd8LP00wJlcd5Be9pBrhZA== MIME-Version: 1.0 X-Received: by 10.182.24.8 with SMTP id q8mr9976329obf.67.1457837380751; Sat, 12 Mar 2016 18:49:40 -0800 (PST) Sender: nygren@gmail.com Received: by 10.76.90.36 with HTTP; Sat, 12 Mar 2016 18:49:40 -0800 (PST) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> Date: Sat, 12 Mar 2016 21:49:40 -0500 X-Google-Sender-Auth: 8CxVWqnnAkrGD7_f1OqHnLcH-IY Message-ID: From: Erik Nygren To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c24b3838594e052de537a6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 02:49:43 -0000 --001a11c24b3838594e052de537a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That does seem like a good idea to include a client time stamp in the 0RTT flow to let the server force 1RTT in the case where this is too far off as this bounds the duration of the replay window. (I suspect we'll find a whole range of other similar attacks using 0RTT.) An encrypted client timestamp could presumably be probed by the server. (ie, if the server response is a different size for timestamp-expired vs timestamp-not-expired an attacker could keep probing until they change?) That does seem like more effort, however. Erik On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla wrote: > Hi Kyle, > > Clever attack. I don't think it would be unreasonable to put a low > granularity time stamp in the > ClientHello (and as you observe, if we just define it it can be done > backward compatibly) > or as you suggest, in an encrypted block. With that said, though couldn't > you > also just include the information in the HTTP header for HTTP? Do you > think this is a sufficiently > general issue that it merits a change to TLS. > > -Ekr > > > On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz wrote: > >> Similar to the earlier discussion on 0.5-RTT data, I=E2=80=99m concerned= with the >> long term ability to replay captured 0-RTT early data, and the attack >> vectors that it opens up. For example, take a GET request for an image t= o a >> CDN. This is a request that seems completely idempotent, and that >> applications will surely want to send as 0-RTT data. However, this reque= st >> can result in a few things happening: >> 1) Resource unavailable >> 2) Resource cached locally at edge cluster >> 3) Cache miss, resource must be fetched from origin data center >> #1 can easily be differentiated by the length of the 0.5-RTT response >> data, allowing an attacker to determine when a resource has been >> deleted/modified. #2 and #3 can also be easily differentiated by the tim= ing >> of the response. This opens up the following attack: if an attacker know= s a >> client has requested a resource X_i in the attacker-known set {X_1, X_2, >> ..., X_n}, an attacker can do the following: >> 1) wait for the CDN cache to be evicted >> 2) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the cache >> 3) replay the captured client early data (the request for X_i) >> 4) determine, based on the timing of the response, whether it >> resulted in a cache hit or miss >> 5) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_(n/2 + 1), X= _(n/2 + >> 2), =E2=80=A6, X_n} depending on the result >> This particular binary search example is a little contrived and requires >> that no-one else is requesting any resource in the set, however I think = it >> is representative of a significant new attack vector that allowing >> long-term replay of captured early data will open up, even if 0-RTT is o= nly >> used for seemingly simple requests without TLS client authentication. Th= is >> is a much different threat than very short-term replay, which is already >> somewhat possible on any TLS protocol if clients retry failed requests. >> >> Given this, I think it is worth attempting to limit the time frame that >> captured early data is useful to an attacker. This obviously doesn=E2=80= =99t >> prevent replay, but it can mitigate a lot of attacks that long-term repl= ay >> would open up. This can be done by including a client time stamp along w= ith >> early data, so that servers can choose to either ignore the early data, = or >> to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. T= his >> cuts down the time from days (until the server config/session ticket key= is >> rotated) to minutes or seconds. >> >> Including the client time also makes a client random strike register >> possible without requiring an unreasonably large amount of server-side >> state. >> >> I am aware that client time had previously been removed from the client >> random, primarily due to fingerprinting concerns, however these concerns >> can be mitigated by >> 1) clients can choose to not include their time (or to include a random >> time), with only the risk of their .5-RTT data being delayed >> 2) placing the time stamp in an encrypted extension, so that it is not >> visible to eavesdroppers >> >> >> Note: it=E2=80=99s also useful for the server to know which edge cluster= the >> early data was intended for, however this is already possible in the >> current draft. In ECDHE 0-RTT server configs can be segmented by cluster= , >> and with tickets, the server can store cluster information in the opaque >> ticket. >> >> _______________________________________________ >> 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 > > --001a11c24b3838594e052de537a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That does seem like a good idea to include a client t= ime stamp in the 0RTT flow to let the server force 1RTT in the case where t= his is too far off as this bounds the duration of the replay window.=C2=A0 = (I suspect we'll find a whole range of other similar attacks using 0RTT= .)=C2=A0 An encrypted client timestamp could presumably be probed by the se= rver.=C2=A0 (ie, if the server response is a different size for timestamp-e= xpired vs timestamp-not-expired an attacker could keep probing until they c= hange?)=C2=A0 That does seem like more effort, however.

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


On Sat, Mar 12, 201= 6 at 7:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi Kyle,

Clever atta= ck. I don't think it would be unreasonable to put a low granularity tim= e stamp in the
ClientHello (and as you observe, if we just define= it it can be done backward compatibly)
or as you suggest, in an = encrypted block. With that said, though couldn't you
also jus= t include the information in the HTTP header for HTTP? Do you think this is= a sufficiently
general issue that it merits a change to TLS.

-Ekr


On Fri, Mar 11, = 2016 at 9:21 PM, Kyle Nekritz <knekritz@fb.com> wrote:

Similar to the earlier discussion on 0.5-RTT data, I= =E2=80=99m concerned with the long term ability to replay captured 0-RTT ea= rly data, and the attack vectors that it opens up. For example, take a GET = request for an image to a CDN. This is a request that seems completely idempotent, and that applications will surely want t= o send as 0-RTT data. However, this request can result in a few things happ= ening:
=C2=A0 =C2=A0=C2=A01) Resource unavailable
=C2=A0 =C2=A0=C2=A02) Resource cached locally at edge cluster
=C2=A0 =C2=A0=C2=A03) Cache miss, resource must be fetched from origin data= center
#1 can easily be differentiated by the length of the 0.5-RTT response data,= allowing an attacker to determine when a resource has been deleted/modifie= d. #2 and #3 can also be easily differentiated by the timing of the respons= e. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the attacker= -known set {X_1, X_2, ..., X_n}, an attacker can do the following:
=C2=A0 =C2=A0=C2=A01) wait for the CDN cache to be evicted
=C2=A0 =C2=A0=C2=A02) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the ca= che
=C2=A0 =C2=A0=C2=A03) replay the captured client early data (the request fo= r X_i)
=C2=A0 =C2=A0=C2=A04) determine, based on the timing of the response, wheth= er it resulted in a cache hit or miss
=C2=A0 =C2=A0=C2=A05) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_= (n/2 + 1), X_(n/2 + 2), =E2=80=A6, X_n} depending on the result
This particular binary search example is a little contrived and requires th= at no-one else is requesting any resource in the set, however I think it is= representative of a significant new attack vector that allowing long-term = replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests without = TLS client authentication. This is a much different threat than very short-= term replay, which is already somewhat possible on any TLS protocol if clie= nts retry failed requests.

Given this, I think it is worth attempting to limit the time frame that cap= tured early data is useful to an attacker. This obviously doesn=E2=80=99t p= revent replay, but it can mitigate a lot of attacks that long-term replay w= ould open up. This can be done by including a client time stamp along with early data, so that servers can choose to e= ither ignore the early data, or to delay the 0.5-RTT response to 1.5-RTT if= the time stamp is far off. This cuts down the time from days (until the se= rver config/session ticket key is rotated) to minutes or seconds.

Including the client time also makes a client random strike register possib= le without requiring an unreasonably large amount of server-side state.

I am aware that client time had previously been removed from the client ran= dom, primarily due to fingerprinting concerns, however these concerns can b= e mitigated by
1) clients can choose to not include their time (or to include a random tim= e), with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not visi= ble to eavesdroppers


Note: it=E2=80=99s also useful for the server to know which edge cluster th= e early data was intended for, however this is already possible in the curr= ent draft. In ECDHE 0-RTT server configs can be segmented by cluster, and w= ith tickets, the server can store cluster information in the opaque ticket.


_______________________________________________
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


--001a11c24b3838594e052de537a6-- From nobody Sun Mar 13 01:36:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7001412D560 for ; Sun, 13 Mar 2016 01:36:29 -0800 (PST) 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 eYNFiYrR6l4t for ; Sun, 13 Mar 2016 01:36:26 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 9C25E12D527 for ; Sun, 13 Mar 2016 01:36:26 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id nk17so19025598igb.1 for ; Sun, 13 Mar 2016 01:36:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AtFKyo8OaD/H+zrU1Q63QeKvpPfFiTiOql8O2EOQx4M=; b=n9sLUdb48fZ79AcAA64QZFOamUpj/Mfa65L5hchG33cIgJlvdkeupJosPBj+ic+KEH 97jByBJu3roMlhSMr/zIQF0W7ntGWAhAMOGPEYGrxy6zTUlo66AgLZ57kbNUMhZt8WU2 UUo/oigMPOA/kS9IE1vJ/PpeG0tuwBVBKRWgHNyjIaSyhsCqZoFWvTVypzRlANndpuwn +XWqnR2V+8fZ1qQzQQ2gxpsydJDyK0sevQ6kMiZGU9A1MV9Qw2PaQyK7IO15wU+LUx4j lZCggqhmBV8iL/GYKQxKmw6EDWoX2LfKXr2Gyb29ZiosLgYc+2A7ZEyK83irho9U6fRf /nvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AtFKyo8OaD/H+zrU1Q63QeKvpPfFiTiOql8O2EOQx4M=; b=djf1KYUXAWrcvvQyCoAJKfAOqtzVbgyj7dp0ibX0fIrDEMOPkO6hyjzzVjLVzahTrx iw8u7jv5RuV85TMT+3tz/qxtqY8JRXYoxC9VlLqOhcNqHQQwu+psmVCfFpzrhd/qHOsW gu0DTbqIUOPXvH46Pt6ZSk2JHUnLE0twZ0htLMk4I7XkqwW2nWkLeCwFfE8pHjHUrYh7 v2E25ceD+vhiJResu4bLbHqw92IhU0esN8zsqWW8Ew5V6xM7r+AKKhAN9UtSTqS7CRLE yyFDWbrCfRUQVzpOyctZeM2oDNLeag/W7d8+JTNTwnoBbxHnBJZ2u1ikZnVNVSMDp7rw qLBw== X-Gm-Message-State: AD7BkJITugLgV3nyFKWr+kI4U1hpIOhbl5uwxFONgGZLHIxizRO+aSZCdm+B/tvxPT61yzm76rETGpF55/J+WA== MIME-Version: 1.0 X-Received: by 10.50.60.34 with SMTP id e2mr12648455igr.77.1457861785809; Sun, 13 Mar 2016 01:36:25 -0800 (PST) Received: by 10.36.43.5 with HTTP; Sun, 13 Mar 2016 01:36:25 -0800 (PST) Received: by 10.36.43.5 with HTTP; Sun, 13 Mar 2016 01:36:25 -0800 (PST) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> Date: Sun, 13 Mar 2016 20:36:25 +1100 Message-ID: From: Martin Thomson To: Erik Nygren Content-Type: multipart/alternative; boundary=047d7b10ce3bdffb5e052deae58c Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 09:36:29 -0000 --047d7b10ce3bdffb5e052deae58c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I assume that you would run a tight tolerance on the 0RTT resumption by saving the client's clock error in the ticket. That a way only clients with bad drift get no 0RTT. To do that all sessions need time. I do not see how the server can do this in general without client help. But the solution also addresses Brian's concern. The client doesn't need absolute time, just relative time: How long since the ticket was issued. Then it's an addition to the psk_identity only. On 13 Mar 2016 1:49 PM, "Erik Nygren" wrote: > That does seem like a good idea to include a client time stamp in the 0RT= T > flow to let the server force 1RTT in the case where this is too far off a= s > this bounds the duration of the replay window. (I suspect we'll find a > whole range of other similar attacks using 0RTT.) An encrypted client > timestamp could presumably be probed by the server. (ie, if the server > response is a different size for timestamp-expired vs timestamp-not-expir= ed > an attacker could keep probing until they change?) That does seem like > more effort, however. > > Erik > > > On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla wrote: > >> Hi Kyle, >> >> Clever attack. I don't think it would be unreasonable to put a low >> granularity time stamp in the >> ClientHello (and as you observe, if we just define it it can be done >> backward compatibly) >> or as you suggest, in an encrypted block. With that said, though couldn'= t >> you >> also just include the information in the HTTP header for HTTP? Do you >> think this is a sufficiently >> general issue that it merits a change to TLS. >> >> -Ekr >> >> >> On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz wrote: >> >>> Similar to the earlier discussion on 0.5-RTT data, I=E2=80=99m concerne= d with >>> the long term ability to replay captured 0-RTT early data, and the atta= ck >>> vectors that it opens up. For example, take a GET request for an image = to a >>> CDN. This is a request that seems completely idempotent, and that >>> applications will surely want to send as 0-RTT data. However, this requ= est >>> can result in a few things happening: >>> 1) Resource unavailable >>> 2) Resource cached locally at edge cluster >>> 3) Cache miss, resource must be fetched from origin data center >>> #1 can easily be differentiated by the length of the 0.5-RTT response >>> data, allowing an attacker to determine when a resource has been >>> deleted/modified. #2 and #3 can also be easily differentiated by the ti= ming >>> of the response. This opens up the following attack: if an attacker kno= ws a >>> client has requested a resource X_i in the attacker-known set {X_1, X_2= , >>> ..., X_n}, an attacker can do the following: >>> 1) wait for the CDN cache to be evicted >>> 2) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the cache >>> 3) replay the captured client early data (the request for X_i) >>> 4) determine, based on the timing of the response, whether it >>> resulted in a cache hit or miss >>> 5) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_(n/2 + 1), = X_(n/2 + >>> 2), =E2=80=A6, X_n} depending on the result >>> This particular binary search example is a little contrived and require= s >>> that no-one else is requesting any resource in the set, however I think= it >>> is representative of a significant new attack vector that allowing >>> long-term replay of captured early data will open up, even if 0-RTT is = only >>> used for seemingly simple requests without TLS client authentication. T= his >>> is a much different threat than very short-term replay, which is alread= y >>> somewhat possible on any TLS protocol if clients retry failed requests. >>> >>> Given this, I think it is worth attempting to limit the time frame that >>> captured early data is useful to an attacker. This obviously doesn=E2= =80=99t >>> prevent replay, but it can mitigate a lot of attacks that long-term rep= lay >>> would open up. This can be done by including a client time stamp along = with >>> early data, so that servers can choose to either ignore the early data,= or >>> to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. = This >>> cuts down the time from days (until the server config/session ticket ke= y is >>> rotated) to minutes or seconds. >>> >>> Including the client time also makes a client random strike register >>> possible without requiring an unreasonably large amount of server-side >>> state. >>> >>> I am aware that client time had previously been removed from the client >>> random, primarily due to fingerprinting concerns, however these concern= s >>> can be mitigated by >>> 1) clients can choose to not include their time (or to include a random >>> time), with only the risk of their .5-RTT data being delayed >>> 2) placing the time stamp in an encrypted extension, so that it is not >>> visible to eavesdroppers >>> >>> >>> Note: it=E2=80=99s also useful for the server to know which edge cluste= r the >>> early data was intended for, however this is already possible in the >>> current draft. In ECDHE 0-RTT server configs can be segmented by cluste= r, >>> and with tickets, the server can store cluster information in the opaqu= e >>> ticket. >>> >>> _______________________________________________ >>> 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 > > --047d7b10ce3bdffb5e052deae58c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I assume that you would run a tight tolerance on the 0RTT re= sumption by saving the client's clock error in the ticket.=C2=A0 That a= way only clients with bad drift get no 0RTT. To do that all sessions need = time.

I do not see how the server can do this in general without c= lient help. But the solution also addresses Brian's concern. The client= doesn't need absolute time, just relative time: How long since the tic= ket was issued. Then it's an addition to the psk_identity only.

On 13 Mar 2016 1:49 PM, "Erik Nygren" = <erik+ietf@nygren.org> = wrote:
That does seem like a good idea to include a client time stamp in = the 0RTT flow to let the server force 1RTT in the case where this is too fa= r off as this bounds the duration of the replay window.=C2=A0 (I suspect we= 'll find a whole range of other similar attacks using 0RTT.)=C2=A0 An e= ncrypted client timestamp could presumably be probed by the server.=C2=A0 (= ie, if the server response is a different size for timestamp-expired vs tim= estamp-not-expired an attacker could keep probing until they change?)=C2=A0= That does seem like more effort, however.

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik


On Sat, Mar 12, 2016 at 7:56 AM= , Eric Rescorla <ekr@rtfm.com> wrote:
Hi Kyle,

Clever attack. I don= 9;t think it would be unreasonable to put a low granularity time stamp in t= he
ClientHello (and as you observe, if we just define it it can b= e done backward compatibly)
or as you suggest, in an encrypted bl= ock. With that said, though couldn't you
also just include th= e information in the HTTP header for HTTP? Do you think this is a sufficien= tly
general issue that it merits a change to TLS.

<= /div>
-Ekr


On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nek= ritz <knekritz@fb.com> wrote:

Similar to the earlier discussion on 0.5-RTT data, I= =E2=80=99m concerned with the long term ability to replay captured 0-RTT ea= rly data, and the attack vectors that it opens up. For example, take a GET = request for an image to a CDN. This is a request that seems completely idempotent, and that applications will surely want t= o send as 0-RTT data. However, this request can result in a few things happ= ening:
=C2=A0 =C2=A0=C2=A01) Resource unavailable
=C2=A0 =C2=A0=C2=A02) Resource cached locally at edge cluster
=C2=A0 =C2=A0=C2=A03) Cache miss, resource must be fetched from origin data= center
#1 can easily be differentiated by the length of the 0.5-RTT response data,= allowing an attacker to determine when a resource has been deleted/modifie= d. #2 and #3 can also be easily differentiated by the timing of the respons= e. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the attacker= -known set {X_1, X_2, ..., X_n}, an attacker can do the following:
=C2=A0 =C2=A0=C2=A01) wait for the CDN cache to be evicted
=C2=A0 =C2=A0=C2=A02) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the ca= che
=C2=A0 =C2=A0=C2=A03) replay the captured client early data (the request fo= r X_i)
=C2=A0 =C2=A0=C2=A04) determine, based on the timing of the response, wheth= er it resulted in a cache hit or miss
=C2=A0 =C2=A0=C2=A05) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_= (n/2 + 1), X_(n/2 + 2), =E2=80=A6, X_n} depending on the result
This particular binary search example is a little contrived and requires th= at no-one else is requesting any resource in the set, however I think it is= representative of a significant new attack vector that allowing long-term = replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests without = TLS client authentication. This is a much different threat than very short-= term replay, which is already somewhat possible on any TLS protocol if clie= nts retry failed requests.

Given this, I think it is worth attempting to limit the time frame that cap= tured early data is useful to an attacker. This obviously doesn=E2=80=99t p= revent replay, but it can mitigate a lot of attacks that long-term replay w= ould open up. This can be done by including a client time stamp along with early data, so that servers can choose to e= ither ignore the early data, or to delay the 0.5-RTT response to 1.5-RTT if= the time stamp is far off. This cuts down the time from days (until the se= rver config/session ticket key is rotated) to minutes or seconds.

Including the client time also makes a client random strike register possib= le without requiring an unreasonably large amount of server-side state.

I am aware that client time had previously been removed from the client ran= dom, primarily due to fingerprinting concerns, however these concerns can b= e mitigated by
1) clients can choose to not include their time (or to include a random tim= e), with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not visi= ble to eavesdroppers


Note: it=E2=80=99s also useful for the server to know which edge cluster th= e early data was intended for, however this is already possible in the curr= ent draft. In ECDHE 0-RTT server configs can be segmented by cluster, and w= ith tickets, the server can store cluster information in the opaque ticket.


_______________________________________________
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

--047d7b10ce3bdffb5e052deae58c-- From nobody Sun Mar 13 04:14:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F37B12D586 for ; Sun, 13 Mar 2016 04:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDPEAZCQ-f20 for ; Sun, 13 Mar 2016 04:14:20 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E346412D574 for ; Sun, 13 Mar 2016 04:14:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45EE0BE35 for ; Sun, 13 Mar 2016 11:14:16 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbq5UtSOmr6T for ; Sun, 13 Mar 2016 11:14:14 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C5D61BE32 for ; Sun, 13 Mar 2016 11:14:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457867654; bh=49GVHUGQjFZyzDFdnIFDytQnTWTK+iT9Hdx9druON+Y=; h=To:From:Subject:Date:From; b=Aid5BxKEZWwcsHHHIha3GUZq46r50MBd9eRv1B5JyNn9/475/bc6akK3W4SNfZ3HU 3a+qcGDU/LpcaWvAknh5sQAqmMeO2QXxxsBzDrWuKvJoCl6cR4wYPHxhQKLimrhOq3 TtECJayordwmBY2FMjwrEvhCXn3spb0mMzRm7RbY= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E54B85.4050204@cs.tcd.ie> Date: Sun, 13 Mar 2016 11:14:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050803060709070003030602" Archived-At: Subject: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 11:14:22 -0000 This is a cryptographically signed message in MIME format. --------------ms050803060709070003030602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, First, with no hats, if the WG were to have a poll on whether or not to include 0rtt in TLS1.3, then as a participant in the work here, I'd be firmly arguing to leave it out entirely. I really think an over-emphasis on reducing latency for browsers is going to bite us (and the Internet) in the ass in the same ways that emphasising interop over security has in the past with fallbacks to older, worse versions of TLS/SSL, with all their inherent flaws and bits of e.g. crappy "export" crypto support. Absent 0rtt, TLS1.3 seems to me to be an excellent step forward in security. With 0rtt, I think it also becomes a dangerous implement. So, that's my personal opinion, while not wearing an AD hat. However, if I'm in the rough about the above, (which seems to me to be the case now) then my job as AD when I get a publication request that includes 0rtt, will include figuring out if that's safe or not. And I've no clue how I'll do that unless the WG have already done some analysis of the many, many protocols that use TLS. Note that I do not consider "use a different API" to be a sufficient answer here (it is necessary, but not sufficient). Given that there are 263 RFCs that reference RFC5246 [1] and google scholar counts 2738 documents that cite RFC5246 [2] I'm puzzled as to how we can know the consequences of adding that dangerous implement to TLS1.3. I've been worried about this for a while now, but the recant thread started by Kyle Nekritz [3] prompted me to send this as I think that's likely just the tip of an iceberg. E.g., I'd be worried about cross-protocol attacks one might be able to try with JS in a browser if the JS can create arbitrary HTTP header fields which I think is the case. I'm also worried about things like EAP-TLS and RADIUS/Diameter if used via TLS etc where we don't necessarily have the right people active on this list. While I don't have any concrete attacks, the ability to create replayable data smells really really bad to me and I've no idea how we can honestly be confident we've done a good job on TLS1.3 while such smells linger. I'd also note that my overall impression of the TRON w/s was that researchers thought 1rtt was mostly ready, but that there was no similar confidence in 0rtt. I also don't think "another TRON" is the answer here, as we'd not have the right people in the room who'd know the consequences of replay for all instances of /TLS. Lastly, just in case: Note that I am not saying that I'll block a publication request for TLS1.3 that includes 0rtt based on my own technical opinion if I'm in the rough. I'm saying that I have no idea how I'll do an AD evaluation of such a thing so I need help from the WG in analysing the broader impact of 0rtt, and if that's not done before the publication request, we'll have to figure it out then. And that could be messy, if we make a bunch of late discoveries that 0rtt creates issues for a bunch of instances of /TLS1.3. So, can people suggest ways in which we can figure out the impact of replayable data across all the many uses of TLS? Thanks, S. [1] http://www.arkko.com/tools/allstats/citations-rfc5246.html [2] https://scholar.google.com/scholar?q=3Dhttp%3A%2F%2Fwww.hjp.at%2Fdoc%2Frf= c%2Frfc5246.html&btnG=3D&hl=3Den&as_sdt=3D0%2C5 [3] https://mailarchive.ietf.org/arch/msg/tls/K-PmKrP6Df_qIVq_BTielgtQwUY= --------------ms050803060709070003030602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTMx MTE0MTNaMC8GCSqGSIb3DQEJBDEiBCBbPt9g6FUMKBAFsNKFfH0xphtkSy7dhMfdMOkULSN5 STBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAR2ULwMrgb+5IPQlaXPULIlbMPMX0Q0U/cO4kiyBei3BNts7DqGJoK kzwjgGuYbPvTNIUYsMEUxMU4DyciYJ52iR4WDDs09UUsO4CX8EyRd3ibZYujD312hiITpk+6 4VbAR+1bUmRYPGou92TUcvqAqqZvVAtjVq81zwnc6VXKLDnsKyhT0f6WR/YU86KHbNlxEpVP 0KKMVGzGtXZbBazGM/1gs8w4BNquimO9NR1gQRN48Ybflxda/93dgeFOPJUX4ut/Tp9kbYTA 4fGT1ASzDRsbJA+nsJTtG6bmveU5IIzMRUjqBNMXdA3wRWhH4ov4IlAgHL/kDnVC0PjWEJZi AAAAAAAA --------------ms050803060709070003030602-- From nobody Sun Mar 13 05:38:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB3512D59A for ; Sun, 13 Mar 2016 05:38:46 -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 EB_yy-LG85Sa for ; Sun, 13 Mar 2016 05:38:44 -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 7AFE212D598 for ; Sun, 13 Mar 2016 05:38:43 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g3so138952524ywa.3 for ; Sun, 13 Mar 2016 05:38:43 -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=WxoRnlrCr4rsg7sVa6R11fBs3kxgAWzFB3U+Gjdu+fk=; b=jYemGoVQBvAV1VGTqsnzlXNl6OZrCaXqsdzc7omaFu5C4sIgKaMAJVftTQESDA5EjQ zBn3McpqfLx5esKOVPkQKu/m0l3S2OdBujHfCeFQbFsUSvzdMRy/YrC5jFlXeaaYk3q+ y0AdwrU/copHiN8Uw2AbL2Rp5j+iGJpo3wbStgLcDJ2/Ds0N150/wbY8ytt8pKd2NnWh r1A3Uem2K9favS2nCLQhIsbjj3dtgpm/v+ueaWLKGqtyDiB36TgZpEObqODngiTSycE0 ZLU5HCcJHW16DgBB7HcP9Nzeh/C+XOdaqyMTLTVjtGlGibQ9rFenzWsuu/KCTVPG8Dof 09JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WxoRnlrCr4rsg7sVa6R11fBs3kxgAWzFB3U+Gjdu+fk=; b=ac9NemU/fVMshOKQaJ8YOCmLc5KXiibZoniXDm7XiHOJAXFeBmbS0zM90JZvR1skMW vR9MUA3BzJtqYdzUJBTZnDxaAYPUxhoIH15UdBSAS1VNMtPHS+7Cufydoo5eG3BCzRTO ehJNsCiETOZOH6cHNKSV7T18uNhIVgSzC3wPiCBC9uB/RVzaWLwpUFTBADjFaQCZbhRN a8p96MTSjPF5kGqlkFjRSXhmJl3BiQ4bp/8rdnM7CDV9viBD8F02DgiPgjoe8iQVpjOu 5NfGdtu8z4QtTCbolRBi/6SSM3j4+wFVuDMbMs8C8UHa/wqZzAAcau0zsEFYjhcPpaiD 0t1Q== X-Gm-Message-State: AD7BkJL8sw9BbZRlX1zaiBcPxccO6ybmc7+u1Ib8zl3RkGY6vJjC3xZIV3RMKn3ImuZTd1ZSIerl4SicI5Bi3A== X-Received: by 10.129.46.87 with SMTP id u84mr9511370ywu.129.1457872723249; Sun, 13 Mar 2016 05:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 13 Mar 2016 05:38:03 -0700 (PDT) In-Reply-To: <56E54B85.4050204@cs.tcd.ie> References: <56E54B85.4050204@cs.tcd.ie> From: Eric Rescorla Date: Sun, 13 Mar 2016 13:38:03 +0100 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114140bacc6c0b052ded7139 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 12:38:46 -0000 --001a114140bacc6c0b052ded7139 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 12:14 PM, Stephen Farrell wrote: > > > However, if I'm in the rough about the above, (which seems > to me to be the case now) then my job as AD when I get a publication > request that includes 0rtt, will include figuring out if that's > safe or not. And I've no clue how I'll do that unless the WG > have already done some analysis of the many, many protocols > that use TLS. Note that I do not consider "use a different API" > to be a sufficient answer here (it is necessary, but not > sufficient). It seem to me that there are several important mitigating factors here. 1. Nothing requires applications to use this feature at all. First, servers need to advertise it and are free to (a) not offer clients the ability to send 0-RTT data and (b) refuse to accept it if clients send it. Moreover, everyone I know of who is considering building a 1.3 library intends to provide that data to the server via a separate API, so the server will have to work to get it. 2. The replay issues are mostly problematic in cases that trouble maintaining consistent state (primarily distributed machines). Non-distributed systems can maintain a replay cache and refuse to accept traffic which appears to be a replay. This does not reduce the risk to zero but it significantly reduces it to state loss issues, which are easier to control for. So it would probably be useful to document some anti-replay mechanism based on the ClientHello fo such protocols. I've been worried about this for a while now, but the recant > thread started by Kyle Nekritz [3] prompted me to send this > as I think that's likely just the tip of an iceberg. E.g., I'd > be worried about cross-protocol attacks one might be able to > try with JS in a browser if the JS can create arbitrary HTTP > header fields which I think is the case. It's not generally the case without server consent. CORS prohibits the use of any non-simple headers in CORS requests without preflight. See: https://fetch.spec.whatwg.org/#concept-main-fetch and https://fetch.spec.whatwg.org/#simple-header > I'm also worried about > things like EAP-TLS and RADIUS/Diameter if used via TLS etc > where we don't necessarily have the right people active on this > list. Yes, this might be the case, though as above, I note that nothing is making those protocols use this feature, and the specification is quite clear about the risks involved here. Rather than requiring some open-ended exploration of the impact on every protocol of this feature, I think it would be far more sensible to require that protocols not use 0-RTT absent some specific application layer profile describing when and why it is safe. That allows the experts in those protocols to do their own analysis, rather than somehow making it the responsibility of the TLS WG. I agree that this is a sharp object and I'd certainly be happy to have such a requirement in 1.3. -Ekr --001a114140bacc6c0b052ded7139 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 13, 2016 at 12:14 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:

However, if I'm in the rough about the above, (which seems
to me to be the case now) then my job as AD when I get a publication
request that includes 0rtt, will include figuring out if that's
safe or not. And I've no clue how I'll do that unless the WG
have already done some analysis of the many, many protocols
that use TLS. Note that I do not consider "use a different API" to be a sufficient answer here (it is necessary, but not
sufficient).

It seem to me that there are = several important mitigating factors here.

1. Noth= ing requires applications to use this feature at all. First, servers
<= div>need to advertise it and are free to (a) not offer clients the ability = to send
0-RTT data and (b) refuse to accept it if clients send it= . Moreover, everyone
I know of who is considering building a 1.3 = library intends to provide
that data to the server via a separate= API, so the server will have to work
to get it.

2. The replay issues are mostly problematic in cases that trouble<= /div>
maintaining consistent state (primarily distributed machines). No= n-distributed
systems can maintain a replay cache and refuse to a= ccept traffic which
appears to be a replay. This does not reduce = the risk to zero but it significantly
reduces it to state loss is= sues, which are easier to control for. So it would
probably be us= eful to document some anti-replay mechanism based on the
ClientHe= llo fo such protocols.


I've been worried about this for a while now, but the recant
thread started by Kyle Nekritz [3] prompted me to send this
as I think that's likely just the tip of an iceberg. E.g., I'd
be worried about cross-protocol attacks one might be able to
try with JS in a browser if the JS can create arbitrary HTTP
header fields which I think is the case.

It= 's not generally the case without server consent. CORS prohibits the us= e of any
non-simple headers in CORS requests without preflight. S= ee:

https://fetch.spec.whatwg.org/#concept-main-fetch
and


=C2=A0
I'm also worri= ed about
things like EAP-TLS and RADIUS/Diameter if used via TLS etc
where we don't necessarily have the right people active on this
list.

Yes, this might be the case, though a= s above, I note that nothing is making
those protocols use this f= eature, and the specification is quite clear about
the risks invo= lved here. Rather than requiring some open-ended exploration
of t= he impact on every protocol of this feature, I think it would be far more
sensible to require that protocols not use 0-RTT absent some speci= fic
application layer profile describing when and why it is safe.= That allows the
experts in those protocols to do their own analy= sis, rather than somehow
making it the responsibility of the TLS = WG. I agree that this is a sharp object
and I'd certainly be = happy to have such a requirement in 1.3.

-Ekr
<= /div>

--001a114140bacc6c0b052ded7139-- From nobody Sun Mar 13 06:51:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D38A12D61A for ; Sun, 13 Mar 2016 06:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpmbBYnCx4pJ for ; Sun, 13 Mar 2016 06:51:49 -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 7106D12D620 for ; Sun, 13 Mar 2016 06:51:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 47564BE32; Sun, 13 Mar 2016 13:51:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO0QszcHV3O0; Sun, 13 Mar 2016 13:51:46 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 220E5BE33; Sun, 13 Mar 2016 13:51:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457877106; bh=POQHJ+UWGK1/Gx4VN1x0tVbumTGY7sI7uQ2qClDbXfc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=UrCCP2tDd3OI5eSsXISlPqlNIXBLdzIvRLNZ50HWaYTmhiSF/KPstrBU3xmVrHu2m phz3qXzMSjnUdAzY6s53zFwAhfGl1uBQGvpTDWZHVOe7y7M3p8jE/lgNurOkbdy3NO 1+w66KIKQbgTIQpttieA6iYlJS6/ppfVApXBOOGA= To: Eric Rescorla References: <56E54B85.4050204@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E5706C.4020804@cs.tcd.ie> Date: Sun, 13 Mar 2016 13:51:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060105000005020407000804" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 13:51:51 -0000 This is a cryptographically signed message in MIME format. --------------ms060105000005020407000804 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I mostly agree with what you wrote about specific mitigating factors for specific potential threats. For this thread though, maybe we're better talking about how we might get to where we can be confident that replayable data in TLS1.3 won't cause significant harm. I'm happy to talk more about the specifics as well but maybe better to try figure out what are a good set of goals first (or in parallel). I think this bit maybe captures where you and I might most come from different perspectives: On 13/03/16 12:38, Eric Rescorla wrote: >=20 > Yes, this might be the case, though as above, I note that nothing is ma= king > those protocols use this feature,=20 Sure. Except we *know* that people will see a new API and will use that to go faster, even if they ought not. TBH, I really don't think the API approach is sufficient by itself. > and the specification is quite clear about > the risks involved here. Rather than requiring some open-ended explorat= ion "requiring open-ended" doesn't match what I'm asking for. I can understand your concern though. I'm trying to figure out how we (the IETF) get to where we are confident that we understand the important impacts of introducing this dangerous implement. As I said, I am puzzled as to how we get there and am asking that the WG help figuring that out before we get to when tackling issues we find gets harder. > of the impact on every protocol of this feature, I think it would be fa= r > more > sensible to require that protocols not use 0-RTT absent some specific > application layer profile describing when and why it is safe.=20 I think some such statement would help for sure. I'm not sure though if it's really sufficient. Even if 0rtt was to be in a separate RFC (I forget if the WG considered that) the issue is that libraries will all include it (as it'll make the web go faster) so implementers are liable to turn it on anywhere really. > That allows > the > experts in those protocols to do their own analysis, rather than someho= w > making it the responsibility of the TLS WG. I agree that this is a shar= p > object > and I'd certainly be happy to have such a requirement in 1.3. So again, I totally understand the reluctance to consider all of the foo/TLS options within the TLS WG. And I don't even know how one might get that done if one wanted. (Hence my asking the WG.) However, it is the TLS WG that is introducing the dangerous implement and as part of a protocol revision that is mainly intended to improve security. It seems fair to say that that may be a surprise for folks who just want to use TLS. My guess would be that if we say to all the WG's doing foo/TLS that they need to write a new document before they safely can move from TLS1.2 to TLS1.3, they'll answer back that the TLS WG should have done some or all of that before introducing the dangerous implement. There are at least two bad approaches here I think. One is "higher layers need to do all the work to figure out if moving from TLS1.2 to TLS1.3 is safe." Another is "the TLS WG needs to figure out and say if foo/TLS1.3 is safe for all ." My issue is that I don't know what middle-ground here is reasonable and gives us sufficient confidence that TLS1.3 with the dangerous implement is safe enough. Cheers, S. --------------ms060105000005020407000804 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTMx MzUxNDBaMC8GCSqGSIb3DQEJBDEiBCDIS4DKZn8zDtazjg6MWid8/Gz+84zg1JFgnmkY+oe0 fjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAtLkmpHVe3TtlNpEpF8bHGpEIXsmbOgJ6+drtQS4XnVPIVAeNbIWNv i3NB5P1//MKGwPkQf16HuDGd4thBeobsgEilL/Fh72erCMoork3PBdR+hNdHxgRm9CWxOM37 fSzBdtUo/tqzRCW3wdwDe49j26xDjrXd+0wZpIW8/49aF9GK6bK47aL81V6tQST3+nTp5GSA 8WimFryk4CLkFe288vVilzdWoMRkBSNo0sjoK29JnCkmnUMaaaKHoC7JEfyaaDoJKTRw9P+x lKvZcOkxaRb60yVH9o+aGrxo3oBtEwsyumr9M1zfZz8Iwe9qsoae4JCU83R8kgqJ0evqCDBc AAAAAAAA --------------ms060105000005020407000804-- From nobody Sun Mar 13 07:02:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E4012D545 for ; Sun, 13 Mar 2016 07:02:38 -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 CL27CvSVjSxG for ; Sun, 13 Mar 2016 07:02:37 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E9D12D506 for ; Sun, 13 Mar 2016 07:02:37 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g3so140114581ywa.3 for ; Sun, 13 Mar 2016 07:02:37 -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=aGS/QS2adQCqouL6VZrISm3X6ixTwgf3Y0OYuARjQww=; b=nfLIpFhKNzOAKlfeFoRrVkRp9tiZhatBFJOFl9rk3azszoOK6B+GHCJ33a88qV/d8c JYN7JYyWizgjrq2p8ulPPAJiQeLXnddpiQmy235riWIvw7ok7CQOnT/dOeDZ4l7ntJBe J6Za0rcoUhkmYeTul99vPaMQWOmRglQqbCRi0VHVKeYnCN5a2ax4Kwfdm9ZGjo0jdSVZ jETb3A9fF7rqLWH0JEoQTxNqRa4JyUEgJMVVv2g1zdzwY7FTrXBqLhO4QxzFFTau/mW4 xim4cu6H3rIgjWjIQmNxLCqpMfLz8TNRU22lD36dp3fLJpYUptyjtUSQnGc6RmRzH/Zf 2T5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aGS/QS2adQCqouL6VZrISm3X6ixTwgf3Y0OYuARjQww=; b=miq8vujI/FA/f/E5ZuxgE3FJaatpOsvtCWpjoNlzdyZmo/achaFD4FaVMmStsjhpOl apxKDp44/IWHGhMKGPNzos+8R9uiftZnvD1X15oTBHM8Akn7zReZZ+7SRZUiQBZQQf7J k9uJpRcmRdksWxi6nIE+ZT9LolTe4g/sU8UOGVw6QSyX56SjjhfIaT4VIIUAcOWRqNbr Ai4YejvLv27Kgr9nLqtiVOzkTbNM2GlAaoRKZvHl36c0TCvsGh/CotdrxHSCnJGdAeab RMmCE93uWrbTrIVjVU7VEniYUNwq9VuxKEhxfEfbqjj44SX60ELFH6Bf2URxKBg0qnpz uB9A== X-Gm-Message-State: AD7BkJKm7V3xOCIUAjcDq4hSDh9QVOhU/tflj8hxYFkJAEtbZPsMhuSj7pSzXfZiq9xRI8LX2brjm9LpIX0hug== X-Received: by 10.37.231.67 with SMTP id e64mr9596872ybh.146.1457877756232; Sun, 13 Mar 2016 07:02:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 13 Mar 2016 07:01:56 -0700 (PDT) In-Reply-To: <56E5706C.4020804@cs.tcd.ie> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> From: Eric Rescorla Date: Sun, 13 Mar 2016 15:01:56 +0100 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c0b0d9ec9955a052dee9df3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:02:39 -0000 --94eb2c0b0d9ec9955a052dee9df3 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell wrote: > > > That allows > > the > > experts in those protocols to do their own analysis, rather than somehow > > making it the responsibility of the TLS WG. I agree that this is a sharp > > object > > and I'd certainly be happy to have such a requirement in 1.3. > > So again, I totally understand the reluctance to consider all of the > foo/TLS options within the TLS WG. And I don't even know how one > might get that done if one wanted. (Hence my asking the WG.) > > However, it is the TLS WG that is introducing the dangerous implement > and as part of a protocol revision that is mainly intended to improve > security. It seems fair to say that that may be a surprise for folks > who just want to use TLS. > > My guess would be that if we say to all the WG's doing foo/TLS that > they need to write a new document before they safely can move from > TLS1.2 to TLS1.3, This is not an accurate way to represent the situation. Those WGs can safely move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*. -Ekr --94eb2c0b0d9ec9955a052dee9df3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 13, 2016 at 2:51 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:
> That allows
> the
> experts in those protocols to do their own analysis, rather than someh= ow
> making it the responsibility of the TLS WG. I agree that this is a sha= rp
> object
> and I'd certainly be happy to have such a requirement in 1.3.

So again, I totally understand the reluctance to consider all of the=
foo/TLS options within the TLS WG. And I don't even know how one
might get that done if one wanted. (Hence my asking the WG.)

However, it is the TLS WG that is introducing the dangerous implement
and as part of a protocol revision that is mainly intended to improve
security. It seems fair to say that that may be a surprise for folks
who just want to use TLS.

My guess would be that if we say to all the WG's doing foo/TLS that
they need to write a new document before they safely can move from
TLS1.2 to TLS1.3,

This is not an accurate = way to represent the situation. Those WGs can safely
move from TL= S 1.2 to 1.3 *as long as they don't use 0-RTT*.

-Ekr


--94eb2c0b0d9ec9955a052dee9df3-- From nobody Sun Mar 13 07:41:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAF112D544 for ; Sun, 13 Mar 2016 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElLR-givweu7 for ; Sun, 13 Mar 2016 07:41:22 -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 6E01B12D632 for ; Sun, 13 Mar 2016 07:41:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3D77BBE33; Sun, 13 Mar 2016 14:41:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00sXvzJlVJJ5; Sun, 13 Mar 2016 14:41:16 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 821FEBE32; Sun, 13 Mar 2016 14:41:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457880076; bh=Tm+d2XyU7xVI/nC6JlsMu10dlzgVDevEI3nia7SdJJw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=QNOhseRKG/0wSMep63FKSxLjeuYPQT+CeD00HZLVxuHpUkuK17jFii4T219vNTR2L lrq715I0GajkdYK7tDxLleLfXnn7fmKWK+RAhnqd0tLoEoN6uerVYlVCHbncUuJRz0 0M7juvD1Am2rwFFzj+ecainE4z/KHKgICRATcwiY= To: Eric Rescorla References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E57C0B.50802@cs.tcd.ie> Date: Sun, 13 Mar 2016 14:41:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010108060905050007080500" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:41:23 -0000 This is a cryptographically signed message in MIME format. --------------ms010108060905050007080500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/03/16 14:01, Eric Rescorla wrote: >=20 > This is not an accurate way to represent the situation. Those WGs can s= afely > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*. I agree your 2nd sentence but not your 1st. I also think it is prudent to assume that implementers will turn on replayable data even if nobody has figured out the consequences. Cheers, S. --------------ms010108060905050007080500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTMx NDQxMTVaMC8GCSqGSIb3DQEJBDEiBCBIUxoMrImsBvXnNmvvvKoeN7ZfVXQlPqmWzacsI9dl bTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBwNfIucFJyUwMN6/RchRpFNDGDC36sHHCWqlhOr1wy8VkOCj/Of7bJ SWJLa4hVG5wo/HOycWzxzwDfzn0bvX34HfrCwbsyinNOBw3UF+NzViEFA9oxKAduAp1Mdkab f27FhdUef3YS1Z3zGH9R3i81EmbN2xOOWLxMUZaYgpz0AT5DXNPRNsCCRRCyRzKB1cIbOXJ6 j3pCHWpbTMCS5lJFmAKxYkCWSWP4AU9h0AkqntGoA69+wSP0xTwz08nLM7w8FaiLzcFO5pCT +mi2XNEzVi9UeY38nWcWefp5DAwi5EON3Di++QxeQ4+AvOzD+U7bXrIa1X1BwFxMwFK17R5U AAAAAAAA --------------ms010108060905050007080500-- From nobody Sun Mar 13 07:45:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05CF12D5A4 for ; Sun, 13 Mar 2016 07:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JEYLaQMwnjwO for ; Sun, 13 Mar 2016 07:45:31 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id D3B8E12D544 for ; Sun, 13 Mar 2016 07:45:31 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 424FA423727; Sun, 13 Mar 2016 14:45:21 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 2BF06423705; Sun, 13 Mar 2016 14:45:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457880321; bh=KGr5MnmWcRwyyAt4De9byu7t23AAniIC5ZTEZ9YV4FI=; l=518; h=From:To:CC:Date:References:In-Reply-To:From; b=mqsUcWqQ95vTPiszEKKsA+TKUcGAaqkP8HWNO7f/mZb1W0mjkJanMnHSsxU7fVF3j Ar1VP2s784p/HbbCa8J+vHbaIcVluybm232h0H6+CJnRt+0SPlq8tYiPg9CFJ6Y0ZX sBx6BFCUchNKvGEyghaTcl1awwA2LP10MzcLtJb4= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 14ED21FC8B; Sun, 13 Mar 2016 14:45:21 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 13 Mar 2016 10:45:20 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Sun, 13 Mar 2016 10:45:20 -0400 From: "Salz, Rich" To: Stephen Farrell , Eric Rescorla Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmCOC9+j35tnUyBsRmmKhu5h59XkzmAgAAUkgCAAALeAIAACvyA//+9NBA= Date: Sun, 13 Mar 2016 14:45:19 +0000 Message-ID: <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> In-Reply-To: <56E57C0B.50802@cs.tcd.ie> 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.34.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:45:33 -0000 PiAgSSBhbHNvIHRoaW5rIGl0IGlzIHBydWRlbnQgdG8gYXNzdW1lIHRoYXQgaW1wbGVtZW50ZXJz IHdpbGwgdHVybiBvbiByZXBsYXlhYmxlDQo+IGRhdGEgZXZlbiBpZiBub2JvZHkgaGFzIGZpZ3Vy ZWQgb3V0IHRoZSBjb25zZXF1ZW5jZXMuDQoNCkkgdmVyeSBtdWNoIGFncmVlLiAgQ3VzdG9tZXJz LCBwYXJ0aWN1bGFybHkgdGhvc2UgaW4gdGhlIG1vYmlsZSBmaWVsZCwgd2lsbCBsb29rIGF0IHRo aXMgYW5kIHNheSAiSSBjYW4gYXZvaWQgYW4gZXh0cmEgUlRUPyAgKlRVUk4gSVQgT04qIiB3aXRo b3V0IGZ1bGx5IHVuZGVyc3RhbmRpbmcsIG9yIHBlcmhhcHMgZXZlbiByZWFsbHkgY2FyaW5nIGFi b3V0LCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zLiANCg== From nobody Sun Mar 13 07:50:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C240412D522 for ; Sun, 13 Mar 2016 07:50:27 -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 jhcaLewSsrVk for ; Sun, 13 Mar 2016 07:50:26 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAEA12D5B2 for ; Sun, 13 Mar 2016 07:50:26 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id d65so140842746ywb.0 for ; Sun, 13 Mar 2016 07:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HOnEjPXjqRvF7gaDsEP2xN4FII0wntEFXF3DTLKULzE=; b=tF+tMrqpyLtaq3poP5saKw+TYwpa7VASCjhVcwYF3ueQ/OYHz5y21u2hHSLjb6GkFf mhH3q5xYARAx9QZ2KI1z0HIXGywi8ynDcN/rRbQKsx4Hc0RD2XZ8ABaLAbNbBky1db4n jqV1Ez7nXqN476F1dMG9Qr979V676j3vP00rVmcy9Emch2EKbMMWOUHNl4Pif9kkZAXw FqMGbSfKESVKLS+Ok/Ja0Ryl6RgzTr6YN7ABzILOx8MDWsM/7udGbEvLBrvrRwsa/+64 uDSqZZzbBhcwf/lcZJHGRGthSmsWlBRtAQTRwNTd5HjNVl+F3aryHaD8LiU1Y6XaAe/b sxTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HOnEjPXjqRvF7gaDsEP2xN4FII0wntEFXF3DTLKULzE=; b=b0uAu2gsS61SK3dKmLrcSDf6FR99/txyWl4bX7/bv+5JmoS5POOwpwC96nYs4ZKU1t 8eOugcJ+hLsNhBojcMWwabBVePC6oYqZbP1iPG0HBIfnb8h5+fQKUG0RK92Lt7InJBuW BZGVeIiuzIxSj+zoz9Oyvss94dvwfuEzlCxoWhTuDvCcdBB29zbicNkWVrEnCAulDt7o WNzYL3mW8hJE7TqDZb3Y/5ZcdYezn6WlJhmciSDFD14NZ7VXvM1lEWIIPkZectJGMSQ0 lRfGBAqJIDM0ZBn3v8TF0DJRX5hiP5hCk31Kx7yx2pPDKAQAKDUq0LMggKmyRDyXcxOu Eubw== X-Gm-Message-State: AD7BkJJn7i22BncxtYVy9t3KOfJ2FkdRd5bmpwbEWTjFi8KtCy67AlbtaigGe8s80MKKc/H/XmssoC/XZHVldA== X-Received: by 10.129.49.8 with SMTP id x8mr10745771ywx.223.1457880625401; Sun, 13 Mar 2016 07:50:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 13 Mar 2016 07:49:45 -0700 (PDT) In-Reply-To: <56E57C0B.50802@cs.tcd.ie> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> From: Eric Rescorla Date: Sun, 13 Mar 2016 15:49:45 +0100 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114202f8cd8431052def484c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:50:27 -0000 --001a114202f8cd8431052def484c Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell wrote: > > Hiya, > > On 13/03/16 14:01, Eric Rescorla wrote: > > > > This is not an accurate way to represent the situation. Those WGs can > safely > > move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*. > > I agree your 2nd sentence but not your 1st. > > I also think it is prudent to assume that implementers will turn on > replayable data even if nobody has figured out the consequences. That may well be true, but I don't believe that it allows us to make progress. We already know that there are conditions in which 0-RTT is unsafe. That's why the specification has extensive caveats around its use. Therefore, either we (collectively) can: - Not specify it at all. - Specify it and provide warnings that people should only use it in certain circumstances and attempt to delineate these circumstances. In my original message, I proposed that we restrict the use of 0-RTT to settings where it has been explicitly profiled. Your response seems to be that people will turn it on even if we do so. But if that's your position then there's no point in doing any analysis because we already know that there are cases where it's not safe, which is why we are warning them against using it in those cases. In any case, I'm a little surprised by your assertion in a previous message that WGs expect us to do this analysis. That's not been the relationship we've have with WGs in the past; rather, we document the properties we are providing and they have to determine whether those properties are appropriate. Perhaps we could start by actually sponsoring some of those reviews. Given that HTTP is the primary customer for 0-RTT, perhaps Mark or Martin would be willing to start a review there? -Ekr --001a114202f8cd8431052def484c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 13, 2016 at 3:41 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 13/03/16 14:01, Eric Rescorla wrote:
>
> This is not an accurate way to represent the situation. Those WGs can = safely
> move from TLS 1.2 to 1.3 *as long as they don't use 0-RTT*.

I agree your 2nd sentence but not your 1st.

I also think it is prudent to assume that implementers will turn on
replayable data even if nobody has figured out the consequences.

That may well be true, but I don't believe that i= t allows us to make progress.
We already know that there are cond= itions in which 0-RTT is unsafe. That's why
the specification= has extensive caveats around its use. Therefore, either we
(coll= ectively) can:

- Not specify it at all.
= - Specify it and provide warnings that people should only use it in certain=
=C2=A0 circumstances and attempt to delineate these circumstance= s.

In my original message, I proposed that we rest= rict the use of 0-RTT to
settings where it has been explicitly pr= ofiled. Your response seems to be
that people will turn it on eve= n if we do so. But if that's your position then
there's n= o point in doing any analysis because we already know that there
= are cases where it's not safe, which is why we are warning them against=
using it in those cases.

In any case, I= 'm a little surprised by your assertion in a previous message
that WGs expect us to do this analysis. That's not been the relationsh= ip
we've have with WGs in the past; rather, we document the p= roperties we
are providing and they have to determine whether tho= se properties are
appropriate. Perhaps we could start by actually= sponsoring some of those
reviews. Given that HTTP is the primary= customer for 0-RTT, perhaps
Mark or Martin would be willing to s= tart a review there?

-Ekr

=


--001a114202f8cd8431052def484c-- From nobody Sun Mar 13 07:52:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4BE12D522 for ; Sun, 13 Mar 2016 07:51: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, 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 vCtp6w1932gL for ; Sun, 13 Mar 2016 07:51:58 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8341512D62A for ; Sun, 13 Mar 2016 07:51:57 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so75858764wml.0 for ; Sun, 13 Mar 2016 07:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EM4my+z9ShiG9vITIH545SH5WNy4bnlxi+mEYxzP6QU=; b=Ml2TPToL5igunrS+9PY+5ZAZFfbTTSMVV/yynCkJHsioKT5bq+Ml0GIgkwPobqXAgc NpTm//UBsdMD7MWNCvcHbgw7bvjX/zw6r0yJrnaitebG93dcLSWiETpVTyM6/WHQC4c6 mKb8FDkNWGrDJAwb5fH32eJVA13VcnYFCDuEw63JGSaznOIclOsGqulCnx/+gqRKhiCc GoAc6zRicSTcQvXiNZHdSZxnIdQAkZWq1pXvARlLyHceQPWWB/PgY3OZXH8nVi/jd1WB Z6dYRO37BuMpW04uZq3LU0fMv29qDR41QU3mHqnB5EH3OR5n7SiOXSAYWwmYua+ZOyqp xA6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EM4my+z9ShiG9vITIH545SH5WNy4bnlxi+mEYxzP6QU=; b=kLnAmK712ouBAFtSF3XZH2WHdLEAHZ9oZ/709fjGe9sK7Woes3u5ROvykRNe3wamL7 tDaHCdC122GH+LxdpOOQFD/V6DRmfSs9/jAjGnZfA5HG27PFs0ZZ0gtLPy/6UotqXpRR 2hKm0v7dZeU6vrnakVcWqkWD1FAtk1JBeP32SSbjHKykPehIqxvMtSF0poxew17qywVx wTjFMQFl5xdl1T1CZOZb3wKVyjTK+A4/L8n2Nrec3pXtJ1BmVQtoQhGHXmPTyHjxlGB9 WWMdnmkWwI3CDuxtkhi5AtdlSF6/BIC6dwu3kYZVXwL54V969NQrqoNiCeUprj51zkGf 0j4w== X-Gm-Message-State: AD7BkJJJzv1nZ+6uEwfY8e0IG8ZKjN/jRiNZocRZn3kIXuu/mtuaYiNwZgQBgI2wcFoNrA== X-Received: by 10.194.115.196 with SMTP id jq4mr19517964wjb.101.1457880716046; Sun, 13 Mar 2016 07:51:56 -0700 (PDT) Received: from [192.168.137.65] ([109.253.145.158]) by smtp.gmail.com with ESMTPSA id t7sm18004318wjf.39.2016.03.13.07.51.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Mar 2016 07:51:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Sun, 13 Mar 2016 16:51:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:51:59 -0000 > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: >=20 >> I also think it is prudent to assume that implementers will turn on = replayable >> data even if nobody has figured out the consequences. >=20 > I very much agree. Customers, particularly those in the mobile field, = will look at this and say "I can avoid an extra RTT? *TURN IT ON*" = without fully understanding, or perhaps even really caring about, the = security implications.=20 Perhaps, and I think IoT devices are likely to do so as well. Is OpenSSL going to implement this? Are all the browsers? (only the first one is directed specifically at you, Rich=E2=80=A6) Yoav From nobody Sun Mar 13 07:54:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39A612D561 for ; Sun, 13 Mar 2016 07:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 OfEe7DXMkE5r for ; Sun, 13 Mar 2016 07:54:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 4E75512D522 for ; Sun, 13 Mar 2016 07:54:26 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 81E5916CEC8; Sun, 13 Mar 2016 14:54:25 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 6BB6516CEB2; Sun, 13 Mar 2016 14:54:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457880865; bh=M1Vj+XdGdtAgTdo9OaMhivl9TVsRJoBqXScvw0GmSno=; l=568; h=From:To:CC:Date:References:In-Reply-To:From; b=NVmqA7O0b/ZJ6AHmdtUDh20Dkx77IlRJOMy2OnIJ5Ezw1sONl3LyzOrV8nu+muHCb CwncBLufmjjxoZ61aUD25c7O0m/dzlDYza2ZU6FRd6zeeUGCvzpXCyxX3g2L22u5Kv n/M12BN44XbSuGgXuV0crTT56n1RTsxchNDtbg6I= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 52FC898082; Sun, 13 Mar 2016 14:54:25 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 13 Mar 2016 10:54: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.1130.005; Sun, 13 Mar 2016 10:54:24 -0400 From: "Salz, Rich" To: Yoav Nir Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmCOC9+j35tnUyBsRmmKhu5h59XkzmAgAAUkgCAAALeAIAACvyA//+9NBCAAEXAgP//vTcw Date: Sun, 13 Mar 2016 14:54:23 +0000 Message-ID: <49c325ba3c7c4077b087411bceca7c66@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> In-Reply-To: <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> 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.34.46] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:54:28 -0000 DQo+IElzIE9wZW5TU0wgZ29pbmcgdG8gaW1wbGVtZW50IHRoaXM/IEFyZSBhbGwgdGhlIGJyb3dz ZXJzPw0KPiANCj4gKG9ubHkgdGhlIGZpcnN0IG9uZSBpcyBkaXJlY3RlZCBzcGVjaWZpY2FsbHkg YXQgeW91LCBSaWNo4oCmKQ0KDQpJIGNhbiBhbnN3ZXIgdGhlIHNlY29uZCBxdWVzdGlvbiBtb3Jl IGVhc2lseSA6KSAgWWVzIHRoZSBicm93c2VycyB3aWxsLg0KDQpPcGVuU1NMIGlzIHVubGlrZWx5 IHRvIGhhdmUgVExTIDEuMyBiZWZvcmUgZW5kIG9mIDIwMTYgYW5kIEkgZG9uJ3Qga25vdyB3aGF0 IHdlJ2xsIGRvLiAgUmlnaHQgbm93IHdlJ3JlIGZpbmlzaGluZyB1cCBvdXIgbWFqb3IgMS4xIHJl bGVhc2UsIGR1ZSBpbiBhIG1vbnRoIG9yIHNvLiAgQW5kIHRoZW4gd2UnbGwgZmlndXJlIG91dCBv dXIgMS4zIHN0b3J5Lg0K From nobody Sun Mar 13 07:55:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0878312D64C for ; Sun, 13 Mar 2016 07:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 bwo90OzJ0cOe for ; Sun, 13 Mar 2016 07:55:00 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABAB12D561 for ; Sun, 13 Mar 2016 07:54:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B9F37BE33; Sun, 13 Mar 2016 14:54:58 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMunibEOv2cO; Sun, 13 Mar 2016 14:54:57 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.23.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BE27EBE2F; Sun, 13 Mar 2016 14:54:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1457880897; bh=5l21OEcu6/MN4IRYpiOhrLMY5nkmgeNtx+k/QfEWPdw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=svzJGbkhDSW+tT06qYmG+RJS+Mv8bIdMm0AM7A8gaT0UMqgDgaUfZ8zPNa3d2k72T vD8X7M369yXPm2+wdqpniF/fweadjXM88m7PGtPcP93qxOXinOOaTu4+fedGLKlP/5 pE0+9J5W88LJWqXCAbTtBS90Kfg/dXhlHJv3BHO8= To: Eric Rescorla References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56E57F3F.5040405@cs.tcd.ie> Date: Sun, 13 Mar 2016 14:54:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000202000600060806070906" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 14:55:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000202000600060806070906 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/03/16 14:49, Eric Rescorla wrote: > Perhaps we could start by actually sponsoring some of those > reviews. Given that HTTP is the primary customer for 0-RTT, perhaps > Mark or Martin would be willing to start a review there? I think that'd really help esp. if we can get folks looking at a range of protocols that use TLS. For the web, I'm pretty confident that the analysis will be done and done well - that is the main use-case motivating this after all. But getting that started now would still be great. Getting a few non-web cases analysed would be great too if we can figure a way to help get that to happen. Cheers, S. --------------ms000202000600060806070906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMTMx NDU0NTVaMC8GCSqGSIb3DQEJBDEiBCDVIURrf7CBblyqSFdn/nUXx7ZeP9sk9nPfNUSsa1H5 sjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAxpE0W/FuoHKeRYTNx01GqjW2l6EXUjRCofrZzDWJEIwilEkBTqaX1 sIDNlx5Dd+xEglgcwOAKhV8M92R05OcUGyIysGqb7yi9vhzxTpdFEw+AH6qflzT3YKC6n5w8 gr4w2lndsiGW62oRZ7RRAP2ZC7jkBwRPumFbCP9RRoMYQaian96k06skZwSxo1JIP/D1BrY9 n/LmyX8xdgwuK5foOECFFMDktUS4c7ppo9ww2IYCFV/p+ArTEFXwHXltFUd3OQQ2jQZxGP+o b3w0TOthMnfXyl96RhMWXYWw4Ll+otqEUE9HI+vR63xeT8PKJFJgQzPuGuu8otidget/nkTa AAAAAAAA --------------ms000202000600060806070906-- From nobody Sun Mar 13 09:13:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF14F12D629 for ; Sun, 13 Mar 2016 09:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAos0zkNdPlP for ; Sun, 13 Mar 2016 09:13:00 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 63FBE12D64F for ; Sun, 13 Mar 2016 09:13:00 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 50E93A8A122F; Sun, 13 Mar 2016 16:12:58 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id B24831FE0262; Sun, 13 Mar 2016 17:12:57 +0100 (CET) Date: Sun, 13 Mar 2016 17:12:57 +0100 From: Kurt Roeckx To: Yoav Nir Message-ID: <20160313161256.GA4749@roeckx.be> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 16:13:02 -0000 On Sun, Mar 13, 2016 at 04:51:49PM +0200, Yoav Nir wrote: > > Is OpenSSL going to implement this? Personally, I think we should start without 0 RTT until we have a better understanding of what the consequences are. Kurt From nobody Sun Mar 13 09:22:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612CD12D58A for ; Sun, 13 Mar 2016 09:22:11 -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 b3bK9JA23st5 for ; Sun, 13 Mar 2016 09:22:09 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100C312D55D for ; Sun, 13 Mar 2016 09:22:09 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g127so142126140ywf.2 for ; Sun, 13 Mar 2016 09:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5UJz0Gg2tOx16EFQ11rcBextyIjcK9gEyjm709TgZ1I=; b=dIYeCp4lzwDT7eKSbJR43SV7/OvhyMpYChWY8Tpr/ddbM6S6Ser+x82tVt0KpFDm0u KHBq8XRFOgredO2IqCjdrXMqGHdL5pelvVM1M//vq8vpwYeQ41ttSIPttfdeeHl06JWi 7q9tFSZIlUvigWbK/HVNDkAuhXCAsH65c9HwT9LHFdY6chZlRMGEVzvLW0VMPU7Fd2nf rHcEovouA3hHjGVBhna0dBsCvObEa3VlkOxXGvCUytMeb5MajPdSO9RY6KryCZS9q3S4 r6uSJuGXaOTfoSsVVgaslkBtvsOnPomaZJpBG0jQ8mSillzHxBaNI17hrs31wNL1pTRV kOCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5UJz0Gg2tOx16EFQ11rcBextyIjcK9gEyjm709TgZ1I=; b=ivhXxK/NR5KCbs+Ljn7EVcvwUCuMgwkeYAtTBuyZItffub1ClCtthpMhcEooVZHDZ/ TN7npCqo4cOH4nxHJKo1rxSu2BgdZjBy7oZKSOQeY5JUT5KV+ojrqYbwmGXyf62uvn2d VVWG1Bt7pp8dW9+1nNy1/KCwk03NikjT6UXJtbNxo1SYBW3MvZRlh9ARBeMOh8E6I7C7 rndrc6rQwrApnoTnFuGrpha0eoZLLBgfVbWvdWeDvNalOoaaozwQ3GixErn/LA0BHdqt GhpSlES8SYWagURAaSLeMWIM1pvf9CM2jqQ7Mi/dUGUAtqn6b6a8zmHWjM39Pei/d1PS kJhQ== X-Gm-Message-State: AD7BkJKk+ir5m49Fxnrj0rqnPwiSVnXOPe8S8WwQGgUIZVmKOO3zc2A8aDDGDGRhIFlF93Gq/WpUpFS5sf9Zuw== X-Received: by 10.13.218.198 with SMTP id c189mr11047643ywe.165.1457886128260; Sun, 13 Mar 2016 09:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 13 Mar 2016 09:21:28 -0700 (PDT) In-Reply-To: <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> From: Eric Rescorla Date: Sun, 13 Mar 2016 17:21:28 +0100 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c08192acc8151052df09028 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 16:22:11 -0000 --94eb2c08192acc8151052df09028 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote: > > > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: > > > >> I also think it is prudent to assume that implementers will turn on > replayable > >> data even if nobody has figured out the consequences. > > > > I very much agree. Customers, particularly those in the mobile field, > will look at this and say "I can avoid an extra RTT? *TURN IT ON*" witho= ut > fully understanding, or perhaps even really caring about, the security > implications. > > Perhaps, and I think IoT devices are likely to do so as well. > > Is OpenSSL going to implement this? Are all the browsers? > There are already patches in preparation for this for NSS and I expect Firefox to implement it, as long as we have any indication that a reasonable numbers o= f servers will accept it. -Ekr > (only the first one is directed specifically at you, Rich=E2=80=A6) > > Yoav > > > > --94eb2c08192acc8151052df09028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On 13 Mar 2016, at 4:45 PM, Salz, Rich <rsalz@akamai.com> wrote:
>
>> I also think it is prudent to assume that implementers will turn o= n replayable
>> data even if nobody has figured out the consequences.
>
> I very much agree.=C2=A0 Customers, particularly those in the mobile f= ield, will look at this and say "I can avoid an extra RTT?=C2=A0 *TURN= IT ON*" without fully understanding, or perhaps even really caring ab= out, the security implications.

Perhaps, and I think IoT devices are likely to do so as well.
Is OpenSSL going to implement this? Are all the browsers?
<= div>
There are already patches in preparation for this for NS= S and I expect Firefox to
implement it, as long as we have any in= dication that a reasonable numbers of
servers will accept it.

-Ekr


(only the first one is directed specifically at you, Rich=E2=80=A6)

Yoav




--94eb2c08192acc8151052df09028-- From nobody Sun Mar 13 09:45:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA912D673 for ; Sun, 13 Mar 2016 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 aIReo7FDYuRN for ; Sun, 13 Mar 2016 09:45:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2E44812D670 for ; Sun, 13 Mar 2016 09:45:42 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 390B4433408; Sun, 13 Mar 2016 16:45:41 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 09DC1433406; Sun, 13 Mar 2016 16:45:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457887541; bh=0Y77GQ28PISTe52yiTm1xXAd7dyyqZrnqxbiKWup6Oo=; l=253; h=From:To:CC:Date:References:In-Reply-To:From; b=UjC1HYrAPb2oAsts8eSU5hbfCtOrHRFEevTDdjxr+mQs0jBYoeD9q1ry2bjF8MtoX q9ksAfXWRfgncAY/ivL3TzFegdTSzZuzOwyCxz5fLOflO7DJ0KGHZ18kYKjjJAlUI4 vHUk/DyYKIk3tJ8bKeeVZtWeESqGL0W8yDSStJQk= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E73B01FC8B; Sun, 13 Mar 2016 16:45:40 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 13 Mar 2016 12:45:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Sun, 13 Mar 2016 12:45:40 -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.1130.005; Sun, 13 Mar 2016 12:45:40 -0400 From: "Salz, Rich" To: Kurt Roeckx , Yoav Nir Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmCOC9+j35tnUyBsRmmKhu5h59XkzmAgAAUkgCAAALeAIAACvyA//+9NBCAAEXAgIAAFquA///F9vA= Date: Sun, 13 Mar 2016 16:45:39 +0000 Message-ID: <61084b20f9e747fc9bae646a75370933@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> <20160313161256.GA4749@roeckx.be> In-Reply-To: <20160313161256.GA4749@roeckx.be> 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.42.163] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 16:45:44 -0000 > Personally, I think we should start without 0 RTT until we have a better > understanding of what the consequences are. For those who don't know, Kurt is on the openssl-dev team (longer than me),= but is just more quiet and modest about it :) From nobody Sun Mar 13 11:23:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E7612D745 for ; Sun, 13 Mar 2016 11:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyWCz051SYO3 for ; Sun, 13 Mar 2016 11:23:40 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59612D740 for ; Sun, 13 Mar 2016 11:23:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id DD9AB25D9; Sun, 13 Mar 2016 20:23:37 +0200 (EET) 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 eR2yYIL9Tok3; Sun, 13 Mar 2016 20:23:37 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 97C7421C; Sun, 13 Mar 2016 20:23:37 +0200 (EET) Date: Sun, 13 Mar 2016 20:23:36 +0200 From: Ilari Liusvaara To: Stephen Farrell Message-ID: <20160313182336.GA13172@LK-Perkele-V2.elisa-laajakaista.fi> References: <56E54B85.4050204@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56E54B85.4050204@cs.tcd.ie> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 18:23:43 -0000 On Sun, Mar 13, 2016 at 11:14:13AM +0000, Stephen Farrell wrote: > > I've been worried about this for a while now, but the recant > thread started by Kyle Nekritz [3] prompted me to send this > as I think that's likely just the tip of an iceberg. E.g., I'd > be worried about cross-protocol attacks one might be able to > try with JS in a browser if the JS can create arbitrary HTTP > header fields which I think is the case. I'm also worried about > things like EAP-TLS and RADIUS/Diameter if used via TLS etc > where we don't necessarily have the right people active on this > list. While I don't have any concrete attacks, the ability to > create replayable data smells really really bad to me and I've > no idea how we can honestly be confident we've done a good job > on TLS1.3 while such smells linger. Also, it occurs to me that problems can arise if one tries to combine 0-RTT data with ALPN. The 0-RTT datablock is probably only appropriate for one of the protocols... If it is HTTP/2 vs. HTTP/1.1, if you get it wrong, the connection will break (the HTTP/2 prelude). Wonder if one is so fortunate with some other protocol pairs... Hmm... That got me some ideas... > I'd also note that my overall impression of the TRON w/s was that > researchers thought 1rtt was mostly ready, but that there was > no similar confidence in 0rtt. I also don't think "another TRON" is > the answer here, as we'd not have the right people in the room > who'd know the consequences of replay for all instances of /TLS. TLS 1.3 1-RTT is just boring, unless you are trying to do something at least a bit screwy, like mix pure-PSK and client-auth. No such luck with 0-RTT. There is all sorts of cryptographic screwyness in there too (through getting rid of DH-0RTT should eliminate that). Also, it occurs to me that very few protocols are even nearly as vulernable to these kind of issues than HTTP, including cases where one end is speaking HTTP but the other is not... -Ilari From nobody Sun Mar 13 12:04:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CEE12D73C for ; Sun, 13 Mar 2016 12:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 SD2D3FSarPbo for ; Sun, 13 Mar 2016 12:04:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0107.outbound.protection.outlook.com [207.46.100.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9C012D733 for ; Sun, 13 Mar 2016 12:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zMbbh8uWx4NoHaCBHOhIOkp59GoaEmqMoo1q8l3Bcwk=; b=LQPi0mqmqLU9WqgRJxM8ATDRbbBM5ARN4a3zOvtZ8FaSTBzKQP+Kk5cKgcodaTqNygs5Of5V0EbnAPPiqQJetHDPtxi5JL7FrkFiRoGPO1bJ7MjBpSwqKAgc7HDHoE7kaxzgjzoK/vOP7TFFqF0nKQIohlSAB0hk25DcqZ52w5Q= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1393.namprd03.prod.outlook.com (10.163.81.14) with Microsoft SMTP Server (TLS) id 15.1.434.16; Sun, 13 Mar 2016 19:04:13 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.016; Sun, 13 Mar 2016 19:04:13 +0000 From: Andrei Popov To: Eric Rescorla , Yoav Nir Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmF6I9l7FxbpECwCZyuZfQ96J9XUCuAgAAUkQCAAALfAIAACvyAgAABI4CAAAHRgIAAGQwAgAAm7aA= Date: Sun, 13 Mar 2016 19:04:13 +0000 Message-ID: References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.46.246.208] x-ms-office365-filtering-correlation-id: 537f24db-521d-4a78-9972-08d34b72449d x-microsoft-exchange-diagnostics: 1; BLUPR03MB1393; 5:OpAwNlfjcx664GCvhtjjEukSXvXv2MlvNBcDq7iJ35SwZzSD+gaLd0K7+6HFalhetkzw7gu66r3tpC/qTu/hXmiBxX7R3ebA1X8RsbfgnOP3oeLKFfLWtWK+32mO/dmsKG5M71+b3iEw7PWZC0XMig==; 24:qyTKyEH94nS/cIUR7NuLEnMI2P48QO3TkDnODsmxeup664799y1ZVagjHQEAxtjs02L62JNHo1U/YSBJMqN9VCxqwM7E6YqLacADrVOGfUY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1393; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1393; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1393; x-forefront-prvs: 0880FB6EC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(790700001)(10400500002)(586003)(122556002)(16236675004)(50986999)(3846002)(92566002)(19580395003)(6116002)(1096002)(5002640100001)(1220700001)(76176999)(106116001)(15975445007)(10290500002)(5005710100001)(5004730100002)(74316001)(77096005)(87936001)(3280700002)(66066001)(54356999)(189998001)(10090500001)(5001770100001)(2950100001)(19300405004)(11100500001)(2900100001)(2906002)(19609705001)(4326007)(102836003)(5003600100002)(86362001)(19580405001)(5008740100001)(8990500004)(81166005)(33656002)(76576001)(19625215002)(99286002)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1393; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396B2F9A91C677F70FA3D358CB70BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Mar 2016 19:04:13.7812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1393 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 19:04:18 -0000 --_000_BLUPR03MB1396B2F9A91C677F70FA3D358CB70BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBTdGVwaGVuIHNhaWQgYWJvdXQgMC1SVFQgbWFrZXMgYSBsb3Qgb2Ygc2Vuc2UgdG8gbWUu IEhvd2V2ZXIsIGlmIG9uZSBtYWpvciBicm93c2VyIGltcGxlbWVudHMgdGhpcyBsYXRlbmN5IHJl ZHVjdGlvbiBmZWF0dXJlLCB0aGUgcmVzdCB3aWxsIGZlZWwgY29tcGVsbGVkIHRvIGRvIHRoZSBz YW1lLiBBbmQgRUtS4oCZcyBtZXNzYWdlIGJlbG93IGluZGljYXRlcyB0aGF0IGF0IGxlYXN0IG9u ZSBtYWpvciBicm93c2VyIHdpbGwgc3VwcG9ydCAwLVJUVC4NCg0KRnJvbTogVExTIFttYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50OiBT dW5kYXksIE1hcmNoIDEzLCAyMDE2IDk6MjEgQU0NClRvOiBZb2F2IE5pciA8eW5pci5pZXRmQGdt YWlsLmNvbT4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBhbmFseXNpcyBv ZiB3aWRlciBpbXBhY3Qgb2YgVExTMS4zIHJlcGxheWFiZSBkYXRhDQoNCg0KDQpPbiBTdW4sIE1h ciAxMywgMjAxNiBhdCAzOjUxIFBNLCBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbTxtYWls dG86eW5pci5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQo+IE9uIDEzIE1hciAyMDE2LCBhdCA0 OjQ1IFBNLCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWku Y29tPj4gd3JvdGU6DQo+DQo+PiBJIGFsc28gdGhpbmsgaXQgaXMgcHJ1ZGVudCB0byBhc3N1bWUg dGhhdCBpbXBsZW1lbnRlcnMgd2lsbCB0dXJuIG9uIHJlcGxheWFibGUNCj4+IGRhdGEgZXZlbiBp ZiBub2JvZHkgaGFzIGZpZ3VyZWQgb3V0IHRoZSBjb25zZXF1ZW5jZXMuDQo+DQo+IEkgdmVyeSBt dWNoIGFncmVlLiAgQ3VzdG9tZXJzLCBwYXJ0aWN1bGFybHkgdGhvc2UgaW4gdGhlIG1vYmlsZSBm aWVsZCwgd2lsbCBsb29rIGF0IHRoaXMgYW5kIHNheSAiSSBjYW4gYXZvaWQgYW4gZXh0cmEgUlRU PyAgKlRVUk4gSVQgT04qIiB3aXRob3V0IGZ1bGx5IHVuZGVyc3RhbmRpbmcsIG9yIHBlcmhhcHMg ZXZlbiByZWFsbHkgY2FyaW5nIGFib3V0LCB0aGUgc2VjdXJpdHkgaW1wbGljYXRpb25zLg0KUGVy aGFwcywgYW5kIEkgdGhpbmsgSW9UIGRldmljZXMgYXJlIGxpa2VseSB0byBkbyBzbyBhcyB3ZWxs Lg0KDQpJcyBPcGVuU1NMIGdvaW5nIHRvIGltcGxlbWVudCB0aGlzPyBBcmUgYWxsIHRoZSBicm93 c2Vycz8NCg0KVGhlcmUgYXJlIGFscmVhZHkgcGF0Y2hlcyBpbiBwcmVwYXJhdGlvbiBmb3IgdGhp cyBmb3IgTlNTIGFuZCBJIGV4cGVjdCBGaXJlZm94IHRvDQppbXBsZW1lbnQgaXQsIGFzIGxvbmcg YXMgd2UgaGF2ZSBhbnkgaW5kaWNhdGlvbiB0aGF0IGEgcmVhc29uYWJsZSBudW1iZXJzIG9mDQpz ZXJ2ZXJzIHdpbGwgYWNjZXB0IGl0Lg0KDQotRWtyDQoNCg0KKG9ubHkgdGhlIGZpcnN0IG9uZSBp cyBkaXJlY3RlZCBzcGVjaWZpY2FsbHkgYXQgeW91LCBSaWNo4oCmKQ0KDQpZb2F2DQoNCg0KDQo= --_000_BLUPR03MB1396B2F9A91C677F70FA3D358CB70BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXQgU3RlcGhlbiBzYWlkIGFib3V0IDAtUlRUIG1h a2VzIGEgbG90IG9mIHNlbnNlIHRvIG1lLiBIb3dldmVyLCBpZiBvbmUgbWFqb3IgYnJvd3NlciBp bXBsZW1lbnRzIHRoaXMgbGF0ZW5jeSByZWR1Y3Rpb24gZmVhdHVyZSwgdGhlIHJlc3Qgd2lsbCBm ZWVsIGNvbXBlbGxlZA0KIHRvIGRvIHRoZSBzYW1lLjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+ IEFuZCBFS1LigJlzIG1lc3NhZ2UgYmVsb3cgaW5kaWNhdGVzIHRoYXQgYXQgbGVhc3Qgb25lIG1h am9yIGJyb3dzZXIgd2lsbCBzdXBwb3J0IDAtUlRULjxvOnA+PC9vOnA+PC9hPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5k Q29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29t cG9zZSI+PC9zcGFuPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50 OjwvYj4gU3VuZGF5LCBNYXJjaCAxMywgMjAxNiA5OjIxIEFNPGJyPg0KPGI+VG86PC9iPiBZb2F2 IE5pciAmbHQ7eW5pci5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gYW5hbHlzaXMgb2Ygd2lkZXIgaW1w YWN0IG9mIFRMUzEuMyByZXBsYXlhYmUgZGF0YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFN1biwgTWFyIDEzLCAyMDE2IGF0IDM6NTEgUE0sIFlvYXYgTmlyICZsdDs8YSBocmVmPSJtYWls dG86eW5pci5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnluaXIuaWV0ZkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJy Pg0KJmd0OyBPbiAxMyBNYXIgMjAxNiwgYXQgNDo0NSBQTSwgU2FseiwgUmljaCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWku Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEkgYWxzbyB0aGluayBp dCBpcyBwcnVkZW50IHRvIGFzc3VtZSB0aGF0IGltcGxlbWVudGVycyB3aWxsIHR1cm4gb24gcmVw bGF5YWJsZTxicj4NCiZndDsmZ3Q7IGRhdGEgZXZlbiBpZiBub2JvZHkgaGFzIGZpZ3VyZWQgb3V0 IHRoZSBjb25zZXF1ZW5jZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgSSB2ZXJ5IG11Y2ggYWdyZWUu Jm5ic3A7IEN1c3RvbWVycywgcGFydGljdWxhcmx5IHRob3NlIGluIHRoZSBtb2JpbGUgZmllbGQs IHdpbGwgbG9vayBhdCB0aGlzIGFuZCBzYXkgJnF1b3Q7SSBjYW4gYXZvaWQgYW4gZXh0cmEgUlRU PyZuYnNwOyAqVFVSTiBJVCBPTiomcXVvdDsgd2l0aG91dCBmdWxseSB1bmRlcnN0YW5kaW5nLCBv ciBwZXJoYXBzIGV2ZW4gcmVhbGx5IGNhcmluZyBhYm91dCwgdGhlIHNlY3VyaXR5IGltcGxpY2F0 aW9ucy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QZXJoYXBzLCBhbmQgSSB0aGluayBJb1QgZGV2aWNlcyBhcmUgbGlrZWx5IHRvIGRvIHNvIGFz IHdlbGwuPGJyPg0KPGJyPg0KSXMgT3BlblNTTCBnb2luZyB0byBpbXBsZW1lbnQgdGhpcz8gQXJl IGFsbCB0aGUgYnJvd3NlcnM/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgYWxyZWFkeSBwYXRjaGVzIGluIHByZXBh cmF0aW9uIGZvciB0aGlzIGZvciBOU1MgYW5kIEkgZXhwZWN0IEZpcmVmb3ggdG88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmltcGxlbWVudCBpdCwg YXMgbG9uZyBhcyB3ZSBoYXZlIGFueSBpbmRpY2F0aW9uIHRoYXQgYSByZWFzb25hYmxlIG51bWJl cnMgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnNlcnZlcnMgd2lsbCBhY2NlcHQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48YnI+DQoob25seSB0aGUgZmlyc3Qgb25lIGlzIGRpcmVjdGVkIHNwZWNpZmljYWxseSBhdCB5 b3UsIFJpY2jigKYpPGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCllvYXY8 YnI+DQo8YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BLUPR03MB1396B2F9A91C677F70FA3D358CB70BLUPR03MB1396namp_-- From nobody Sun Mar 13 12:04:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCAD12D71D for ; Sun, 13 Mar 2016 12:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLUFB_SEATLQ for ; Sun, 13 Mar 2016 12:04:44 -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 A564C12D55D for ; Sun, 13 Mar 2016 12:04:44 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id z76so200184633iof.3 for ; Sun, 13 Mar 2016 12:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=w8JdQo5kKmb+2RUe/AxkAzdS/Sr2FpUAFb5fT6UhDtI=; b=GTBG3LZoRmUzbV60Q2inoFo+hfeaxXew3rSGBawfgz9Ra28DaUSHhvtWTOJ56Aeffp ajsR2lF0oMOm2/QVfV+WZyEKYsHlZr/fUf+tA2OFCnksDh/YJw07/npWioqIEEr+HVOW FdmdicFLEqkQl1NU7aFD3o6ox6cs+qOZzJUBFS2mOUXY6qgOUn07RNCDyfhaehUdvC+F XNo0Hsa0QuSdBSw3otT9fx2SE28iFWw/IPoMBacuAhGQ0++hDVxnRKNhTdk35+sDEAxl AyOfH1vAAqto2a8sLai9IILf8lz6lbSoF5nFMVw8JZG+hbKddSYFBfNcme7cgIetZuGZ QgUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=w8JdQo5kKmb+2RUe/AxkAzdS/Sr2FpUAFb5fT6UhDtI=; b=IiF3PizXnfMiDKHb5vxhgXOWYozyWSTiHInmeiUMFWHvNXRXTf/Ao/ldU9csDytz5W H97ZCkgIGJSA6gP6pEBMPkHPPDFiPBZDIOGENjjZlP0ny9pVEmeEHwYuNu93U5lOSzcc 0s8EgXKniUO9UVdteaG32WfcvyzDbU9rIGU4twyP9WQ0JhnCkr1T5Bsk1gTk3i0Vgt8K 7r1DtidukgnlzhOXdoecIfu5772vqqCvHfZwKcLkhK0K7yXPjlMgXIZUhMV24eqtYC5/ FpM5sCm19q5VfS3oV15/kICz+/bTysURXSfeuqc2dCzGvHwSN3idHCFwCQMUiwj6SMbg oQKQ== X-Gm-Message-State: AD7BkJIYqu0BKSfAzBRSHDFgcUQSsbdTVoRjsD1NlVtpscdj6YgaHGgim9pwF6nJZb/RyEUEpP3XmdOsuD2HVFVj MIME-Version: 1.0 X-Received: by 10.107.138.35 with SMTP id m35mr21864417iod.127.1457895883893; Sun, 13 Mar 2016 12:04:43 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Sun, 13 Mar 2016 12:04:43 -0700 (PDT) In-Reply-To: <20160313182336.GA13172@LK-Perkele-V2.elisa-laajakaista.fi> References: <56E54B85.4050204@cs.tcd.ie> <20160313182336.GA13172@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 13 Mar 2016 12:04:43 -0700 Message-ID: From: Bill Cox To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a113f2da847cfbd052df2d64e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 19:04:46 -0000 --001a113f2da847cfbd052df2d64e Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 11:23 AM, Ilari Liusvaara wrote: > TLS 1.3 1-RTT is just boring, unless you are trying to do something > at least a bit screwy, like mix pure-PSK and client-auth. > > No such luck with 0-RTT. There is all sorts of cryptographic screwyness > in there too (through getting rid of DH-0RTT should eliminate that). > This is just my personal opinion: I second your opinion that as Ekr suggested, TLS 1.3 should drop DH-0RTT. Only 0-RTT resume should be supported. That way, we start off with the same security as 1-RTT, simplifying analysis and reducing vulnerabilities. IMO, 0-RTT is the most important new feature in TLS 1.3, though the current spec giving us two different ways to shoot ourselves in the foot with 0-RTT seems redundant. While this is in no way related to my job within Google, I do not see how a company like Google could justify switching from QUIC crypto to TLS 1.3 without a 0-RTT capability. Note that the job I actually do at Google, working on Token Binding, is significantly threatened by 0-RTT (just like client-certs), so I have plenty of reason to be against 0-RTT. I just feel the world needs 0-RTT. Speed really _is_ that important. Finally, I feel that while the TLS 1.3 spec does a good job of trying to scare away people from 0-RTT, it would be better if we also explained what is required to use 0-RTT in a secure mode. Perhaps this does not belong in the spec, but at least a link to read about it should be, IMO. It _can_ be done, if the client and server are willing to pay the high cost required. Bill --001a113f2da847cfbd052df2d64e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 13, 2016 at 11:23 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
TLS 1.3 1-RTT is just boring= , unless you are trying to do something
at least a bit screwy, like mix pure-PSK and client-auth.

No such luck with 0-RTT. There is all sorts of cryptographic screwyness
in there too (through getting rid of DH-0RTT should eliminate that).

This is just my personal opinion:
<= br>
I second your opinion that as Ekr suggested, TLS 1.3 sho= uld drop DH-0RTT.=C2=A0 Only 0-RTT resume should be supported.=C2=A0 That w= ay, we start off with the same security as 1-RTT, simplifying analysis and = reducing vulnerabilities.=C2=A0

IMO, 0-RTT i= s the most important new feature in TLS 1.3, though the current spec giving= us two different ways to shoot ourselves in the foot with 0-RTT seems redu= ndant.=C2=A0 While this is in no way related to my job within Google, I do = not see how a company like Google could justify switching from QUIC crypto = to TLS 1.3 without a 0-RTT capability.=C2=A0 Note that the job I actually d= o at Google, working on Token Binding, is significantly threatened by 0-RTT= (just like client-certs), so I have plenty of reason to be against 0-RTT.= =C2=A0 I just feel the world needs 0-RTT.=C2=A0 Speed really _is_ that impo= rtant.

Finally, I feel that while the TLS 1.3 spec= does a good job of trying to scare away people from 0-RTT, it would be bet= ter if we also explained what is required to use 0-RTT in a secure mode.=C2= =A0 Perhaps this does not belong in the spec, but at least a link to read a= bout it should be, IMO.=C2=A0 It _can_ be done, if the client and server ar= e willing to pay the high cost required.

Bill<= /div>
--001a113f2da847cfbd052df2d64e-- From nobody Sun Mar 13 14:23:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B35912D848 for ; Sun, 13 Mar 2016 14:23:58 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-EVPKdj9wBl for ; Sun, 13 Mar 2016 14:23:56 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E67F212D821 for ; Sun, 13 Mar 2016 14:23:55 -0700 (PDT) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-10v.sys.comcast.net with comcast id VZPd1s0024s37d401ZPvoF; Sun, 13 Mar 2016 21:23:55 +0000 Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-po-01v.sys.comcast.net with comcast id VZPj1s00H2Ekl4801ZPpGv; Sun, 13 Mar 2016 21:23:53 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id u2DLNhWJ032185 for ; Sun, 13 Mar 2016 17:23:43 -0400 Received: (from draco@localhost) by odin.ulthar.us (8.15.2/8.15.2/Submit) id u2DLNhMv032184 for tls@ietf.org; Sun, 13 Mar 2016 17:23:43 -0400 Date: Sun, 13 Mar 2016 17:23:42 -0400 From: Scott Schmit To: tls@ietf.org Message-ID: <20160313212342.GA27160@odin.ulthar.us> References: <56E54B85.4050204@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <56E54B85.4050204@cs.tcd.ie> User-Agent: Mutt/1.5.24 (2015-08-30) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457904235; bh=2KxL8rS+1vpKN6iHkkBmLefZqVw6j5FWTapFAwNewTA=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=Z56yd/Lvw5P4l4u/nUZTv83BYQbeMWShCDSxYqIgwCiXQV+uVDKuMfp10ButAvr3D 1kZcclzziKcBSjxV1YzqfRb+ipPsW/AQC53GSNvQUC2Cj8a6MPEpmqJg8KJZjetwaX c4yEwL7PfGsaGqcq67VbVpxpVAIJnrb8ynZl/406dxGTdqUFEyGgtkqbszB0YBRDg4 kH6GDiLE9gwveWYjjdtC7LvmB1KL5yAn2eY1Drtg0jq33doK5Wmil2w5grRCql8zbr 2uzenMxPVXetxbCki8AOdHhvKtyHOw5QaJm0t2qgynCdju7dY1/gHhLh2M1l/WTnCS UzjY8tiQlgbzw== Archived-At: Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 21:23:58 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 13, 2016 at 11:14:13AM +0000, Stephen Farrell wrote: > First, with no hats, if the WG were to have a poll on whether > or not to include 0rtt in TLS1.3, then as a participant in the > work here, I'd be firmly arguing to leave it out entirely. I > really think an over-emphasis on reducing latency for browsers > is going to bite us (and the Internet) in the ass in the same > ways that emphasising interop over security has in the past with > fallbacks to older, worse versions of TLS/SSL, with all their > inherent flaws and bits of e.g. crappy "export" crypto support. > Absent 0rtt, TLS1.3 seems to me to be an excellent step forward > in security. With 0rtt, I think it also becomes a dangerous > implement. So, that's my personal opinion, while not wearing an > AD hat. I think you're exactly right. Let's look at the vulnerabilities in TLS: - Renegotiation attack - Optimization to establish a new TLS session without reestablishing a TCP/IP connection. Broken repeatedly despite analysis, etc. - TLSv1.3's answer? Drop renegotiation. - BEAST - CBC chained off the last block sent so that an explicit IV need not be sent on the wire. Another optimization. - TLSv1.3's answer? Drop CBC. - CRIME / BREACH - Compression was supported to speed up connections (less data to process/transfer). Optimization, again. - TLSv1.3's answer? Drop compression. - Lucky Thirteen / Padding timing attacks / POODLE - Years later, servers are still vulnerable because insecure algorithms & versions remain enabled, even with the publicity around POODLE - TLSv1.3's answer? Drop the bad cipher suites and offering < 1.0. - RC4 - RC4 is known to be weak, but it continues to be widely used - SSL/TLS included it because analysis said it was secure as used. - TLSv1.3's answer? Drop RC4. - FREAK / Logjam (downgrade attacks) - This happened because TLS vendors left obsolete export algorithms implemented, and server admins left them enabled. - TLSv1.3's answer? Drop the insecure cipher suites. - DROWN - Why is this even an issue? Because people STILL haven't turned off SSLv2 *twenty* *years* after it was known to be insecure!! - TLSv1.3's answer? Drop compatibility with SSLv2. So why are we adding a protocol optimization known from the start to be insecure (or less secure than you'd expect from using a PFS cipher suite)? What percentage of servers that have a perceived need for 0-RTT will be able to securely use and benefit from this feature as their infrastructure is actually implemented? If almost everyone should turn it off, why are we including it? Most server admins won't be reading the TLSv1.3 spec. They're going to see "shiny feature added specifically in this version that makes it faster!" with *maybe* a warning that there are risks, which they'll dismiss because "if it was so insecure, they wouldn't have included it in the protocol in the first place." Unless 0-RTT can be fixed, it looks like an attractive nuisance. Let's leave it out. --=20 Scott Schmit --bg08WKrSYDhXBjb5 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIO1AYJKoZIhvcNAQcCoIIOxTCCDsECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC DAUwggXZMIIDwaADAgECAgcWZ1TjwnBRMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklM MRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTAeFw0wNzEwMTQyMTAxNTVaFw0yMjEwMTQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEW MBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlm aWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVy bWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPM zi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0t svVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpb fuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKk DiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggFMMIIBSDASBgNV HRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ ljVO8tS4UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwaQYIKwYBBQUHAQEE XTBbMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwMAYIKwYBBQUH MAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAyBgNVHR8EKzApMCeg JaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwQwYDVR0gBDwwOjA4BgRV HSAAMDAwLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYw DQYJKoZIhvcNAQELBQADggIBAHQKh/oy3viYt+qvMyyQhqWiIb9kP1KRhqWHGFMID7OAbofo UgDKVUJ7UsiBnPmleGa2pUwvf2B67qPqc2e9Ge9/kBvJtV8rSES3z+/KVrx6UwlX8VyWnkRN GV0PLvCD+34cIOqhF3Tjmt4jpfYSTjkXcOpa7F4RGZbmu0+j1HO46XAYypOisgXD3XWecqqX zEMimZVrF3DlsMYTYMmFtzRYAeaDh2BxczJlV4HeBs8gw7d4USUoDWHckMR4QK0zLVVmQ1F6 6irltWWsJ9CFKVyz9ZTBspi3FDJCT93XfR4OrOUHB+I5P18lTWHDD1p/9dX7Zh8bdwlOSKdE fsKvzaxVZbKkuXXo7FMG2v6LQ2Jmv6Gc4jJ8jSyjatpy86llJJT2R3tJFPRGlfPcZ1ge3Ad/ qXDZKPI4pN8D5so89WUPAJ7z9ZeDqSFdGTWaynTZaCRPAIC/e35VtTyNuIam+n6nuaZFgccp ACw51vkgFUij6AKxByq7CNgB1Zn/FRX15qZA9bu2ZI8QTHJT/8zM3njXAgV6AsFOf682t14q sYSBz0jpef8kU0q15uV9oZSGjy1ph/0ysQD+342MIh3PQlKp62dj3eWWP3MBF7gtQTbERX1P mMzfTIsyMbjq+pv9P4iKROw0+8MNp0PUNtilMG2fKLBRoczLiZ7hMLjyedCXMIIGJDCCBQyg AwIBAgIDDl5qMA0GCSqGSIb3DQEBCwUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmlu ZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGll bnQgQ0EwHhcNMTUwNjE0MDkzOTIzWhcNMTYwNjE0MDExMTU1WjBAMRswGQYDVQQDDBJpLmdy b2tAY29tY2FzdC5uZXQxITAfBgkqhkiG9w0BCQEWEmkuZ3Jva0Bjb21jYXN0Lm5ldDCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMIjn4wl8+qbVrQuvFdai6tCinDeN32epeHl 6TTZrVEkSnrwfbcw8+Ym0vnK504W9pcw1nMbmLEA+2u4VtQ2An/Riill57rqxnQXxCJI1MRX UYhwlJRDHlMgIWvJs/Eo+UuY8Pey3xMbZHNA2ZEy29eliAPyWo5PYp6FEBKJeGXbim5iNYtl 5Bxa7/e+lg+1OEKXtHkbdQVhIdPq0pg3qxrgPg+5DCj6Ftxprc5O5IC3H98aAZ1CVUmxwHND c1lhcUJAShVy8jXex/G7RcujkV3c/3FQnyWmKRqAYhJZZuDdgpNIu7eaUYcxmRjmzez9Znlz GpyP5w7rR2g2xHu94oUCAwEAAaOCAtgwggLUMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0G A1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQUA+UZJvC5M48j4hknTLlE TizD1rowHwYDVR0jBBgwFoAUU3Ltkpzg2ssBXHx+ljVO8tS4UYIwHQYDVR0RBBYwFIESaS5n cm9rQGNvbWNhc3QubmV0MIIBTAYDVR0gBIIBQzCCAT8wggE7BgsrBgEEAYG1NwECAzCCASow LgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwgfcGCCsG AQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5U aGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRoZSBDbGFzcyAxIFZh bGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3ksIHJlbGlh bmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ugb2YgdGhl IHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9j cmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBC BggrBgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5j bGllbnQuY2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkq hkiG9w0BAQsFAAOCAQEAuN6y26buqE5ITv9ta2IDW10kv0MMZ1HexkSZR1Qvn3rrwJbb5SJA lB8fgMuTVxCRS1c0shrfOQlbCyYfDis+Yzgjda1efaheMLnVcenZ1vtQQ/kotkqQEBWPxW/T 99R2DpCQCJbi4Yg2hiX48THcFq4Qvo0QGwiiyz3QzXbNWDIBPAPKneQzcHo+5x1+7qec0WK/ Lcjflz0I3lmvlxzGWHV/lkaERBjpbVUimTyrZUtzvUi56u/TVsARG2q3vuYpQvRTsiwMIxyD ZZTGvRDDwQ6OWJSFCJb0Wv+lApWH9sr/cG090AaouZRIC/D2Ru3W2NJDBdjyhjwg0Qd4jGVq ZzGCApcwggKTAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAw5e ajAJBgUrDgMCGgUAoIHYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF MQ8XDTE2MDMxMzIxMjM0MlowIwYJKoZIhvcNAQkEMRYEFG5Bg94K+PheBmhJTOXP/tQVzmZI MHkGCSqGSIb3DQEJDzFsMGowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQME AQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIH MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIIBAEznMdzp3Yz/6lGEMOb4iLl1rdph uU8gN9yCgSy+LuheToN+JqBhW6RnYM3HzsZjS01IkSlAIZ2bUKUbu6LsEX0hRs1IncXLEf9h 3kCCndEyy3p7Owr0Erm1FkI4NxarMIf5iy/kkqVDTzszy1h1CDqbuPcGfiWQYN2tUDn1M4Jf H4TlNImKI505FBC6pq5nS7Cmbb2137Ru56w8pU7K+gsi+AqrRjxJRp7XkJ11DpcWHEt65H+Y sEp4VYM0/kQ9e2z3b4jb0DyDocHkNYQvlYs6hkwHpjXXjgT9uGFl2zpgeGiUzaNzNcN5/Boy qw+m56KDhOC58zjMM5/25ImGCfE= --bg08WKrSYDhXBjb5-- From nobody Sun Mar 13 15:22:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E7212D869 for ; Sun, 13 Mar 2016 15:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnSmY4VjjPwB for ; Sun, 13 Mar 2016 15:22:48 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D92912D84B for ; Sun, 13 Mar 2016 15:22:48 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g203so203018180iof.2 for ; Sun, 13 Mar 2016 15:22:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7ZArWY+CXaLFIecYgyFHP1uC8mHjtFUBzmMcOTF/dgk=; b=MA8YioNXhG8VXh3bDe/8Ya6pgW8aFUcr8Dg/X6F8pvXysBG4eyGYcDqZPdpXghhs3m NzhJwdjLB+tTyibTfxBPqtYijCVqeXvr+b7lJT9TJeecX3r77UjYp7xRcEcHNqMtUiZ4 q2MbcuK73fsufZk8VXlRk6SEpE0noouQidWK+uimIlf2vEs8Kgfw10ViT6Ttxc5UhwJL qZaO33ggpstkBLSD7wt9Ru90Ipl1b2ArSbu5bBiwH3DcwPY2swhuXGRWc8IBpG7FJ7LC +Kt82qpbyXxMKsf2E1bM41JspCbemx5ARnmasBEgmJrHlow4591tegaFnf/h7vkE5lth TfaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7ZArWY+CXaLFIecYgyFHP1uC8mHjtFUBzmMcOTF/dgk=; b=jngCXHH+UOOS5AOIVnFRfTWmbbM39hUiQx2IRRSvQlpwd87ptDs7HZLx6b+2evr0TO 6amcguVSZUVA50IlTpA4pFfOu0n7Nhq72uZ1bCmwJJ4xAmh/z3CDnM+uW0hEieBnEqa9 oeoy9WUi+LZ6c6wsPJKt+E3gOshR+FZTneMCRD10K+yMvqD7dhIizZOhwBo/EjwmlGz7 r6vxnyVQyS4QyEqZ9qe3WwNjTw+YtGY4YQEgE5mXVfu+YKWH4pH17vfNZheCr78nQsOp HeF0yVrPhnaMe9iVnAj0023QvgVauDdyTMTioDsZNN/WxkLgIKQ9mgA0zZuMQ8Us6K3v sHcA== X-Gm-Message-State: AD7BkJJJu9a5qD44vdlvDO/utkTCHO9xk6NpiJdwtPxXYENoLmvy4H9+upmglTLkgSgzNTZWl+582a0u2SRz+8NP MIME-Version: 1.0 X-Received: by 10.107.138.35 with SMTP id m35mr22405915iod.127.1457907767429; Sun, 13 Mar 2016 15:22:47 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Sun, 13 Mar 2016 15:22:47 -0700 (PDT) In-Reply-To: <20160313212342.GA27160@odin.ulthar.us> References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> Date: Sun, 13 Mar 2016 15:22:47 -0700 Message-ID: From: Bill Cox To: Scott Schmit Content-Type: multipart/alternative; boundary=001a113f2da898170e052df59a52 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 22:22:50 -0000 --001a113f2da898170e052df59a52 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit wrote: > > So why are we adding a protocol optimization known from the start to be > insecure (or less secure than you'd expect from using a PFS cipher > suite)? > If you require PFS with resolution on the order of seconds to minutes rather than hours to days, you probably do not want to use tickets either. The ticket decryption key rotation schedule limits PFS. 0-RTT resumes do not make this worse. What percentage of servers that have a perceived need for 0-RTT will be > able to securely use and benefit from this feature as their > infrastructure is actually implemented? > Well, Google already sees a significant fraction. Going back to 1-RTT would be a significant downgrade. If almost everyone should turn it off, why are we including it? > Almost every small site on the Internet should turn it off, but the large sites that want to enable it could make up a large fraction of all traffic. Most server admins won't be reading the TLSv1.3 spec. They're going to > see "shiny feature added specifically in this version that makes it > faster!" with *maybe* a warning that there are risks, which they'll > dismiss because "if it was so insecure, they wouldn't have included it > in the protocol in the first place." Unless 0-RTT can be fixed, it > looks like an attractive nuisance. > I agree. Instead of dropping 0-RTT, I think we should make it easy for admins to learn about what is involved in using 0-RTT in ways we believe are secure. The two modes I am aware of that are potentially as secure as TLS 1.2 session resumption are: - Do 0-RTT session resumption using a session cache, using the ticket as the session ID. This should have the same security as TLS 1.2 resume, right? - At the HTTP app layer, make all requests that change state transaction based with unique transaction numbers, so replay attacks fail to change server state. Done successfully, this should be more secure than TLS 1.2 resumption, shouldn't it? Are we aware of other secure ways to do 0-RTT? Bill --001a113f2da898170e052df59a52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 13, 2016 at 2:23 PM, Scott Schmit <i.grok@comcast.net> wrote:

So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?

If you require PFS with resolut= ion on the order of seconds to minutes rather than hours to days, you proba= bly do not want to use tickets either.=C2=A0 The ticket decryption key rota= tion schedule limits PFS. =C2=A00-RTT resumes do not make this worse.
=

What percentage of servers that have a perceived need for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

Well, Google already sees a significant fraction.=C2=A0 Going back to 1-RT= T would be a significant downgrade.

If almost everyone should turn it off, why are we including it?

Almost every small site on the Internet should tur= n it off, but the large sites that want to enable it could make up a large = fraction of all traffic.

Most server admins won't be reading the TLSv1.3 spec.=C2=A0 They're= going to
see "shiny feature added specifically in this version that makes it faster!" with *maybe* a warning that there are risks, which they'l= l
dismiss because "if it was so insecure, they wouldn't have include= d it
in the protocol in the first place."=C2=A0 Unless 0-RTT can be fixed, = it
looks like an attractive nuisance.

I ag= ree.=C2=A0 Instead of dropping 0-RTT, I think we should make it easy for ad= mins to learn about what is involved in using 0-RTT in ways we believe are = secure.=C2=A0 The two modes I am aware of that are potentially as secure as= TLS 1.2 session resumption are:

- Do 0-RTT sessio= n resumption using a session cache, using the ticket as the session ID.=C2= =A0 This should have the same security as TLS 1.2 resume, right?
= - At the HTTP app layer, make all requests that change state transaction ba= sed with unique transaction numbers, so replay attacks fail to change serve= r state.=C2=A0 Done successfully, this should be more secure than TLS 1.2 r= esumption, shouldn't it?

Are we aware of other= secure ways to do 0-RTT?

Bill
--001a113f2da898170e052df59a52-- From nobody Sun Mar 13 15:32:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC37012D858 for ; Sun, 13 Mar 2016 15:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjr-nbGO3I1T for ; Sun, 13 Mar 2016 15:32:19 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 21A6612D871 for ; Sun, 13 Mar 2016 15:32:19 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id av4so49515020igc.1 for ; Sun, 13 Mar 2016 15:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Pb3QntbFA8tx5YzmSZhPqR47aVGIBL4Hzwqv1hRgfhc=; b=EVHRf2vaACbYAYDt9eNimjNmVrxqtwgzlipepLp79xqiadXs55FnOgTdH7pKxBhO6G J0wQQwqP2RsKxNafGxJgiK4njHaO3NmHJce9oNx2SMfxZtDjnIl2fyDBmDkbzS7RHBKM fLOetUCDflL/mHFO/sxJahDKi2eP8sniMyEQRoHoDa2CtVeMIJju1DmAiO2NgQ20pkUi Ff3V87sGvbA3F3UN+QqxB6uZ1V6Jch6HBlAd9WNFUGq7fsO5+szA0P3155Qs81T2Qph7 tBIOH8TomKgzeM2i6NhLo9c789SpG8hdbJMfeCDJY+KuBmdnLKJFWkF2AAftjJP5fpNy yeAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Pb3QntbFA8tx5YzmSZhPqR47aVGIBL4Hzwqv1hRgfhc=; b=LbM34+8lzJKPvYhnUCbgicojPrtZvAnY8FC9fXIz1lAu5f7czSqnX0euL7mGsH5H3t E90swlvjJFm8owBcbLnvDDKgqYZ7/HW7awoYWML18bNul2ZUs8zZTMk8XtS8asn5/4vs LSzhPScmA3DMyqoIDP1g+qIbmVnPPEHcfq6m94egjUb1ecI1+pZaJURBEJaTeaTDBajm y/cv+K9Wx+bQ515zsBnZfUqZTDUYn7LhfwHSI+mwp++LgnstmHPDbiXtulNvM9UNS0A0 yT/iHH7v1x1knythJsNr3pL4mL/+qvH/uEu9FYp02Y1UMYSBszePsqfm2q2OH0QB03Qm GiIw== X-Gm-Message-State: AD7BkJKmtd8+dquM+CvMoCjffBMgoY5qTs5YFzG6Nd/cX1P4NivHhCuIrXe5t2XOJy3daVLFe63Q6pRHOEFhQbvt MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr14800065igr.4.1457908338297; Sun, 13 Mar 2016 15:32:18 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Sun, 13 Mar 2016 15:32:18 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> Date: Sun, 13 Mar 2016 15:32:18 -0700 Message-ID: From: Bill Cox To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7bea423e9ee37c052df5bcce Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 22:32:21 -0000 --047d7bea423e9ee37c052df5bcce Content-Type: text/plain; charset=UTF-8 +1 for supporting client timestamps. Various methods for mitigating 0-RTT security limitations (PFS, proofs of possession, replay), involve using a timestamp. It has use outside the attack described above. --047d7bea423e9ee37c052df5bcce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for supporting client timest= amps.=C2=A0 Various methods for mitigating 0-RTT security limitations (PFS,= proofs of possession, replay), =C2=A0involve using a timestamp.=C2=A0 It h= as use outside the attack described above.
--047d7bea423e9ee37c052df5bcce-- From nobody Sun Mar 13 15:33:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375F512D87E for ; Sun, 13 Mar 2016 15:33:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 ZgRfcsIURpRC for ; Sun, 13 Mar 2016 15:33:23 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 B4AD412D875 for ; Sun, 13 Mar 2016 15:33:22 -0700 (PDT) Received: by mail-ob0-x234.google.com with SMTP id fz5so159925606obc.0 for ; Sun, 13 Mar 2016 15:33:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=F5a7Ij3Akx55t+/qV6w82r7gAKAyom8JIjT2OXl3cbs=; b=ImsEISymqtJXyKqB6BFGaMs8khqn+cbK4xr4WsOWbWQn0OWi18eUVZEAPBLznLTyfO N0JqikKmYKSG9brwbl81F+rcNjdY/Dborn8RzkO1/jFmUfTm/Hw32270qIgRB4s2kgEs ICoE8Y7LXBmo/tk7W0ViN87qf2lYEyiscV97epuTx8o/bNfjwGIHTUkk8C5XQ6XI4b9N rRYITDK88epJHZ+sBSFNzXKye2G309MAMdKozFmPrWZ//oIQF28yb/TaS0qYmyn5Vzb4 cFdo9R0u+K/21hkvS9nDoW+XLKCwPmRPipHYlHggetG14ZEydWxlx2nv3u1r0UrnVyrm vW1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=F5a7Ij3Akx55t+/qV6w82r7gAKAyom8JIjT2OXl3cbs=; b=abVq5wduXlBzPtNRnSGDxxahffVjVJJfZVzs1xw9AN7y4vQh/hqilx5WYggIura6p4 t1FlB2G3X7KBs3f9AOqn5bftEvqD9jZnGj/LXWX8cbDsCljh17aye7x1RqZh4k2hPsDS ZozKbFf2bbOEGfCTje0RnKPu3PIDDibC7pz2wYzw724IALEyyEQ42ipib3qwQrdnxT2o 24J2cbzCMjpS4eQhWgzS+2TB9090JX/NwNil0XLiWDyxLi2JGQHnrcIlzwuXGN9gz+j+ W2JbB8PoJf92PHRbeBlH7EPkfdjbjxyghS6ajLGU9oK3gr0dGxyfPr8SmlTlFepVAUFz Eb0w== X-Gm-Message-State: AD7BkJLT7I50cHwzVBVkOwnFp1r5OKABQa+DZYUlauYYbp2DIner+H38f27mxVsjSqI1sCZJlkUEJsX17iyvEg== MIME-Version: 1.0 X-Received: by 10.182.247.67 with SMTP id yc3mr11624540obc.57.1457908402042; Sun, 13 Mar 2016 15:33:22 -0700 (PDT) Sender: nygren@gmail.com Received: by 10.76.90.36 with HTTP; Sun, 13 Mar 2016 15:33:21 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <56E5706C.4020804@cs.tcd.ie> <56E57C0B.50802@cs.tcd.ie> <161d625768e74a519b5d820c674d00d9@usma1ex-dag1mb1.msg.corp.akamai.com> <833DCAA1-5730-4EDD-AC17-1FEFD580B922@gmail.com> Date: Sun, 13 Mar 2016 18:33:21 -0400 X-Google-Sender-Auth: VQJH_udGQVXQ2-GkVLCZoiRln8E Message-ID: From: Erik Nygren To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0158b2546b44af052df5c096 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 13 Mar 2016 22:33:26 -0000 --089e0158b2546b44af052df5c096 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 12:21 PM, Eric Rescorla wrote: > > On Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir wrote: > >> >> > On 13 Mar 2016, at 4:45 PM, Salz, Rich wrote: >> > >> >> I also think it is prudent to assume that implementers will turn on >> replayable >> >> data even if nobody has figured out the consequences. >> > >> > I very much agree. Customers, particularly those in the mobile field, >> will look at this and say "I can avoid an extra RTT? *TURN IT ON*" without >> fully understanding, or perhaps even really caring about, the security >> implications. >> >> Perhaps, and I think IoT devices are likely to do so as well. >> >> Is OpenSSL going to implement this? Are all the browsers? >> > > There are already patches in preparation for this for NSS and I expect > Firefox to > implement it, as long as we have any indication that a reasonable numbers > of > servers will accept it. > I share some of the concerns expressed in this thread that 0RTT has the risk of becoming an attractive nuisance. Once browsers start supporting it, server operators will feel competitive pressure to support it. And this will then put additional pressure onto more browsers to support it, possibly pushing the edges where it is safe. For example, when is HTTP GET safe vs not safe and who makes this call? Especially if you have a browser that assumes that GET should be idempotent and can be sent via 0RTT early data, a web developer whose never heard of the word "idempotent" and builds an app with GET with side-effects but assumes its safe since it's over TLS, and a server operator who is just turning on a vendor provided feature which their users requested, not to mention perhaps having a CDN or load-balancing-tls-terminating-proxy that doesn't have a good way to convey the risks across two connections. One idea for HTTP that I'm increasingly in-favor of might be to define a new method ("GET0"?) and require that browsers use one of these new methods in the early data request to expose this as high in the stack as possible. It seems like there is a level of diminishing returns here if we compare some of the options (not meant to be strictly ordered below): 1) We have old-school cleartext over TCP which has 1RTT before client data (due to SYN/SYNACK) 2) We have TCP + TLS 1.[012] which has both the SYN/SYNACK plus the 2RTT behavior means 3RTT before client data. 3) We have TCP TFO + TLS 1.3 1RTT which yields 1RTT before client data (or back to the same as #1 for resumption) 4) We have TCP (no TFO) + TLS 1.3 0RTT which also yields 1RTT before client data for resumption 5) Then there's TCP TFO + TLS 1.3 0RTT which yields 0RTT before client data for resumption 6) And finally there's old-school cleartext TCP TFO which has 0RTT before client data, but which people are very hesitant to use for HTTP due to replay issues. Of these, #3 and #4 yield similar performance (with some limitations around #3, such as requiring the same server IP or server IP prefix in some newer drafts). >From this, a few thoughts jump to mind from this: * We get many of the same benefits 0RTT with using TCP TFO (TCP FastOpen) and TLS 1.3 1RTT mode together as we get when using TLS 1.3 0RTT and stock TCP. TFO seems much safer here since its replay risks are at a lower level that should be safe for TLS outside of the 0RTT context. Note that there are some issues with middleboxes sometimes breaking badly (blocking all connections from a client IP for 30 seconds) when it tries to use TFO as discussed recently in TCPM, but we may all want to focus some effort on getting those fixed. * We'll almost certainly want to make sure that any UDP-based protocol (DTLS 1.3 or QUIC-over-TLS-1.3) can do a true 1RTT handshake safely in a common case. (ie, in a way that mirrors TCP TFO + TLS 1.3 1RTT.) I suspect this will be the bare minimum for getting QUIC to switch to use TLS 1.3. * It seems like the risks around TLS 1.3 0RTT and TFO are similar (with TCP being a protocol not trying to provide security properties). If people have been very wary to enable TFO for cleartext HTTP due to risks from duplicated packets, shouldn't we be even more worried about TLS 1.3 0RTT since the next-layer-up semantic issues and risks are similar, but TLS 1.3 0RTT potentially even has fewer mitigators? (eg, we don't bind the server IP in cryptographically to the request the client is making --- although that might be an interesting addition to help make TLS 1.3 0RTT safer?) There may also be some hacks that make TLS 1.3 0RTT marginally safer, although I'm sure there are situations where they don't work and they may just provide a false sense of security: * Have the client include a time-delta-relative-to-PSK-issuance, as Martin suggested. (To allow the server to bound the duration of replay attacks.) * Include the server IP in the client_hello for 0RTT (to prevent replays against different clusters). There are a bunch of NAT-style scenarios where this breaks, but it might help in a few places. This also doesn't help for server clusters using anycast. * The anti-replay nonce (which helps in some places, but isn't possible to implement sanely in many other scenarios). At a minimum, I agree with the suggestion that we should require underlying protocols to specify where and how it is safe to use. (Although which of the browsers discussing implementing is willing to wait for this draft for HTTP to be mature enough? I'm actually quite curious here.) Erik [All opinions expressed here are my own.] --089e0158b2546b44af052df5c096 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 13, 2016 at 12:21 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
On= Sun, Mar 13, 2016 at 3:51 PM, Yoav Nir <ynir.ietf@gmail.com> wrote:
<= br> > On 13 Mar 2016, at 4:45 PM, Salz, Rich <rsalz@akamai.com> wrote:
>
>> I also think it is prudent to assume that implementers will turn o= n replayable
>> data even if nobody has figured out the consequences.
>
> I very much agree.=C2=A0 Customers, particularly those in the mobile f= ield, will look at this and say "I can avoid an extra RTT?=C2=A0 *TURN= IT ON*" without fully understanding, or perhaps even really caring ab= out, the security implications.

Perhaps, and I think IoT devices are likely to do so as well.
Is OpenSSL going to implement this? Are all the browsers?
<= div>
There are already patches in preparation for this= for NSS and I expect Firefox to
implement it, as long as we have= any indication that a reasonable numbers of
servers will accept = it.

I share some of= the concerns expressed in this thread that 0RTT has the risk of becoming a= n attractive nuisance.=C2=A0 Once browsers start supporting it, server oper= ators will feel competitive pressure to support it.=C2=A0 And this will the= n put additional pressure onto more browsers to support it, possibly pushin= g the edges where it is safe.=C2=A0

For example, when is HTTP GET s= afe vs not safe and who makes this call?=C2=A0 Especially if you have a bro= wser that assumes that GET should be idempotent and can be sent via 0RTT ea= rly data, a web developer whose never heard of the word "idempotent&qu= ot; and builds an app with GET with side-effects but assumes its safe since= it's over TLS, and a server operator who is just turning on a vendor p= rovided feature which their users requested, not to mention perhaps having = a CDN or load-balancing-tls-terminating-proxy that doesn't have a good = way to convey the risks across two connections.=C2=A0 One idea for HTTP tha= t I'm increasingly in-favor of might be to define a new method ("G= ET0"?)=C2=A0 and require that browsers use one of these new methods in= the early data request to expose this as high in the stack as possible.
It seems like there is a level of diminishing returns here = if we compare some of the options (not meant to be strictly ordered below):=

1) We have old-school cleartext over TCP which has 1RTT = before client data (due to SYN/SYNACK)
2) We have TCP + TLS 1= .[012] which has both the SYN/SYNACK plus the 2RTT behavior means 3RTT befo= re client data.
3) We have TCP TFO + TLS 1.3 1RTT which yield= s 1RTT before client data=C2=A0 (or back to the same as #1 for resumption)<= br>
4) We have TCP (no TFO) + TLS 1.3 0RTT which also yields 1RTT= before client data for resumption
5) Then there's TCP TF= O + TLS 1.3 0RTT which yields 0RTT before client data for resumption
6) And finally there's old-school cleartext TCP TFO which has 0= RTT before client data, but which people are very hesitant to use for HTTP = due to replay issues.

Of these, #3 and #4 yiel= d similar performance (with some limitations around #3, such as requiring t= he same server IP or server IP prefix in some newer drafts).=C2=A0

From this, a few thoughts jump to mind from this:
=
* We get many of the same benefits 0RTT with using TCP TFO (= TCP FastOpen) and TLS 1.3 1RTT mode together as we get when using TLS 1.3 0= RTT and stock TCP.=C2=A0 TFO seems much safer here since its replay risks a= re at a lower level that should be safe for TLS outside of the 0RTT context= .=C2=A0 Note that there are some issues with middleboxes sometimes breaking= badly (blocking all connections from a client IP for 30 seconds) when it t= ries to use TFO as discussed recently in TCPM, but we may all want to focus= some effort on getting those fixed.
* We'll almost certa= inly want to make sure that any UDP-based protocol (DTLS 1.3 or QUIC-over-T= LS-1.3) can do a true 1RTT handshake safely in a common case.=C2=A0 (ie, in= a way that mirrors TCP TFO + TLS 1.3 1RTT.)=C2=A0 I suspect this will be t= he bare minimum for getting QUIC to switch to use TLS 1.3.
* = It seems like the risks around TLS 1.3 0RTT and TFO are similar (with TCP b= eing a protocol not trying to provide security properties).=C2=A0 If people= have been very wary to enable TFO for cleartext HTTP due to risks from dup= licated packets, shouldn't we be even more worried about TLS 1.3 0RTT s= ince the next-layer-up semantic issues and risks are similar, but TLS 1.3 0= RTT potentially even has fewer mitigators?=C2=A0 (eg, we don't bind the= server IP in cryptographically to the request the client is making --- alt= hough that might be an interesting addition to help make TLS 1.3 0RTT safer= ?)


There may also be some hacks that make = TLS 1.3 0RTT marginally safer, although I'm sure there are situations w= here they don't work and they may just provide a false sense of securit= y:
* Have the client include a time-delta-relative-to-PSK-issuance, as M= artin suggested.=C2=A0 (To allow the server to bound the duration of replay= attacks.)
* Include the server IP in the client_hello for 0R= TT=C2=A0 (to prevent replays against different clusters).=C2=A0 There are a= bunch of NAT-style scenarios where this breaks, but it might help in a few= places.=C2=A0 This also doesn't help for server clusters using anycast= .
* The anti-replay nonce (which helps in some places, but is= n't possible to implement sanely in many other scenarios).

At a = minimum, I agree with the suggestion that we should require=20 underlying protocols to specify where and how it is safe to use.=C2=A0=20 (Although which of the browsers discussing implementing is willing to=20 wait for this draft for HTTP to be mature enough?=C2=A0 I'm actually qu= ite=20 curious here.)

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Erik

[All opinions expressed here are my own.]
=

--089e0158b2546b44af052df5c096-- From nobody Sun Mar 13 16:36:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF10F12D775 for ; Sun, 13 Mar 2016 16:36:41 -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 laHFs6SYFFXz for ; Sun, 13 Mar 2016 16:36:40 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 3B55912D6D4 for ; Sun, 13 Mar 2016 16:36:40 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id nk17so27034488igb.1 for ; Sun, 13 Mar 2016 16:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc; bh=kNYjzZxq+MJG63CtGEr+Q+apkBbyvlgo/IuKOc1b7Uk=; b=P9R4tFhET66ZVf8IZjmaO1QsGyfoEv4A0FQ60mSpjjztU0HNU4qWES3IKgxjGBWK7L 1kXrQXtjFEBRmgRUtrxKgsvinWMpwJMSp7Vt9447SJjt3mVElfGNrtjgtxRxWMIl3JeN WLArdUls96fT54GIN81ASOplyh/WL4jsmqOWSETQfvNbOghiX4n2X8V/s2hF7p8h4K9H 4GzuQrnVmuPFoZFt9a6SnOir+GlwhlF5CaGBPOvxBY10E5ziKiOqwfljh9kh5oVQcgel gvXjKV7gIJ0unwta7CzxaVcRsZGdCTmMM5mFuiRRaJnnvkeL18H9kx+32EY+wnIYdtuf 95OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc; bh=kNYjzZxq+MJG63CtGEr+Q+apkBbyvlgo/IuKOc1b7Uk=; b=lkniNfE59iodLK63deKyTfQ9xOcCLwDEq82ZcYDoQ6nX3KLnPZCIvIKVapKt+fW8qX cO5RDCkFe3WeWVZVjqmitZYK3H1ANotJHgJTlzon7AKCRufE/J7Tk2vliSJBmV9SjFWc FK7XvqE1BSMpwd9xwugHCCtCxFqtqjrVE2kbewq7Fqs+ux3idQ4kGPdAd9eE3dcl/8Rk irW7xIkIGk5d6y/8fUq6zcK2a2CC9WwkB1ECtlhUePOyaJ59QyuwzKPm9+nzhYfDYLxH QVVCMcvYhMMx/POLOPL+qg1eBAG9VriO2WXz6qXtEM/NUyzlurclLAlFoNwTilD6ScNV dRfg== X-Gm-Message-State: AD7BkJJwXhrBhDeFBCkSsOhtiob09VDUObelGacahKUA+XzX+k8om90rOhLhu/IIA2HaG3DWrHZ8LgdQN7E8FA== MIME-Version: 1.0 X-Received: by 10.50.40.36 with SMTP id u4mr14068369igk.23.1457912199262; Sun, 13 Mar 2016 16:36:39 -0700 (PDT) Received: by 10.36.195.133 with HTTP; Sun, 13 Mar 2016 16:36:39 -0700 (PDT) In-Reply-To: <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Sun, 13 Mar 2016 19:36:39 -0400 Message-ID: From: Jeffrey Walton To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list 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, 13 Mar 2016 23:36:42 -0000 On Sat, Mar 12, 2016 at 12:45 PM, Karthikeyan Bhargavan wrote: > Hi Kyle, > > In my talk at TRON, I was also concerned by potential attacks from allowing > unlimited replay of 0-RTT data. I recommended that TLS 1.3 servers should > implement replay protection using a cache, but requiring clients to provide > a timestamp in the client random is a great idea. Perhaps this would also > allow TLS 1.3 servers to detect clients whose clocks are too out-of-sync > with Be careful here. The whole point of 0-RTT is to start consuming data before its authenticated to save a few milliseconds in network time. All those parameters are controlled by the attacker. We never worried about the extra roundtrip using satellite comms with 0.5 to 1.0 second delays. Additionally, most of my delays in fetching web pages seems to be delays in Google APIs and servings third party ads. 0-RTT seems to be a solution looking for a problem. From nobody Sun Mar 13 18:26:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1239412D86D for ; Sun, 13 Mar 2016 18:26:18 -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 (1024-bit key) header.d=setec.io header.b=tDVIBbeD; dkim=pass (1024-bit key) header.d=setec.io header.b=omjYsTpX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YGkngowFV9K for ; Sun, 13 Mar 2016 18:26:16 -0700 (PDT) Received: from xmenrevolution.com (xmenrevolution.com [97.107.134.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F18B12D827 for ; Sun, 13 Mar 2016 18:26:15 -0700 (PDT) Received: by xmenrevolution.com (Postfix, from userid 113) id 2EBDB16AB3; Sun, 13 Mar 2016 21:26:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1457918775; bh=1lMt8YOF6J9XqHPeorga8i/sFxfhjTz6sPDko67rdMM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=tDVIBbeDk25OTceIY9gSrTVgmH65Aw3wV+R9U3spfWzhWjoljrTgcwkE79pHxqR7N 4baA1bd6IAJ96U1z73O93u0x6JNzoQuFPhYKm/uMlnBrWaYweWy51EXxnWoQT0gKwt 3UAExaeRYA4IMKkDkP3iIqCFjKVa0H3Gb8ntxFl8= Received: from agartha (static-155-212-141-65.mas.onecommunications.net [155.212.141.65]) by xmenrevolution.com (Postfix) with ESMTPSA id 6B27416991; Sun, 13 Mar 2016 21:26:14 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1457918774; bh=1lMt8YOF6J9XqHPeorga8i/sFxfhjTz6sPDko67rdMM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=omjYsTpXgtgr4b1RwIwesbxDe2s6ru/xi5Jv6jwPRsgxTlCg4XWyY/hgx/4kyaIQq wbPJ7JE1mG6vorERBJX0m5peA2WqdqfJRqIyKcFTt/ZIN1l4Th5PYAzAVnVLdHZj6i X/HMVXvOCWSX0cg4HrMPbk7NAZ1im42YGKHAT1no= From: Harlan Lieberman-Berg To: Bill Cox , Scott Schmit In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 13 Mar 2016 21:26:14 -0400 Message-ID: <874mc9g895.fsf@setec.io> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:26:18 -0000 Bill Cox writes: >> Most server admins won't be reading the TLSv1.3 spec. They're going to >> see "shiny feature added specifically in this version that makes it >> faster!" with *maybe* a warning that there are risks, which they'll >> dismiss because "if it was so insecure, they wouldn't have included it >> in the protocol in the first place." Unless 0-RTT can be fixed, it >> looks like an attractive nuisance. > > I agree. Instead of dropping 0-RTT, I think we should make it easy for > admins to learn about what is involved in using 0-RTT in ways we believe > are secure. [snip] I agree with a slight tweak in wording here, Bill. I think that we /should/ drop the parts of 0-RTT where we are not confident that an admin who blindly enables functionality in TLS 1.3 will not end up harming themselves. More generally, I strongly believe that TLS 1.3 should not provide options which we think should be restricted to "admins who know what they're doing". These end up hurting us down the line (cf EXPORT cipher suites.) I think we should ship the parts of 0-RTT that we believe are intrinsically safe for (the vast majority) of the internet to enable and use on day 1. Sincerely, -- Harlan Lieberman-Berg ~hlieberman From nobody Sun Mar 13 20:52:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5252312D94A for ; Sun, 13 Mar 2016 20:52:01 -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=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 xCmRavUrkW0v for ; Sun, 13 Mar 2016 20:51:59 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65D2212D946 for ; Sun, 13 Mar 2016 20:51:58 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id g127so153240666ywf.2 for ; Sun, 13 Mar 2016 20:51:58 -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:date:message-id:subject:from:to :cc; bh=rJRvNq1lSGRY2V9gRHRgiNKDnUuJQFXtS4XgB3LoExg=; b=J0xskfbfZGqlKn/7wPpJK9sDJ7nto+rbRFX6uCdUQMLXYqiNXULjBDlnepJl/nh3k0 buCrj4G+x+F1ky1c1LG8T+DT8BXQassT53JE7kifCCEAo/61278RoB56LGsYg9ohtK5m G+ieP87siiBUQQd47c9ks/QZ2eFNvq7YM2ILonSN4jL1LE0Yxni099xKOcBgTe2+bKzW WUAkwQ60vpOXp6cJPox4i6Z4Sd0+8nhV2vOKQyh96MEBL7vctreM1aQP+IwaMAZfwob/ /a4D6KVDunj+UXWhBT/yTsYLCvoPCUUEs8ZA97PfNxLG6mw+8sYh5wGwSmaPFhzdVJDb zXUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rJRvNq1lSGRY2V9gRHRgiNKDnUuJQFXtS4XgB3LoExg=; b=eYI2N75bOpZjqDpk1X0Iixg3ByYo9upDHBFPutz+zIvVvInkSy0/dlLlT78Qbn1XhU T890w1cf5SP6RK4IkzdQ/x722T4CoWk4TuS6aDvEk5YWqhy8q98lCRvFhPtG7mkpHmbH y7/obY7PlgMMV19Lon4732Ti42m/WlmaeZflY1077M2vJnl/Jn/Tw99xCJBQMFcooq3k kVhLHlhMr8C5hySoEeaRtXtJsIOhyvaOL97HiYB0f/bgMwRcfp26uM0tAM5yVG5hSVGG uwU2PvWd6Piq3mZ7Q+u2iT6TV2LTdK6mYHePxyjrKPz0XKKv84Utz7PEXk1gczmb7fHj jpuw== X-Gm-Message-State: AD7BkJK9ONRsnrp9o9tMoo91oI4cAm36BBD1UX7qmKPgmWvsDPy6LxKzNshn7qne/xUNa53N3FigakKSOu5r1Q== MIME-Version: 1.0 X-Received: by 10.129.72.78 with SMTP id v75mr12069801ywa.78.1457927517481; Sun, 13 Mar 2016 20:51:57 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Sun, 13 Mar 2016 20:51:57 -0700 (PDT) In-Reply-To: <56E54B85.4050204@cs.tcd.ie> References: <56E54B85.4050204@cs.tcd.ie> Date: Sun, 13 Mar 2016 20:51:57 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114dcb02c9e57d052dfa3323 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:52:01 -0000 --001a114dcb02c9e57d052dfa3323 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell wrote: > With 0rtt, I think it also becomes a dangerous > implement. So, that's my personal opinion, while not wearing an > AD hat. > +1 for this as 0RTT is outlined in the draft. But to expand a little: * Losing forward secrecy for "GET" requests and user cookies seems like a very bad privacy trade-off. Collection of wire data, combined with a bug or an attack that could disclose the ECDH parameters, does not seem so far fetched these days. * I imagine that 0RTT data may be intended for pre-fetching hints, e.g. "I'm request URL foo as user bar, so please get a start on fetching the resources I need". That suggests trivial application-level "is the cache warm" side channels, or "lets trash the whole cache" DOS attacks, would both be common. * A vast number of APIs build on top of TLS/HTTPS are not idempotent or replay safe. Even carefully designed APIs may have subtle side effects such as a user being charged for the request, or the request counting towards a throttle of some kind. Even ones as silly as there go your 10 free nytimes articles; or booting an opponent out of your less-than-friendly sudoku tournament. * The draft calls out that early data needs to be handled differently than regular TLS data. This reminds me of the problems with renegotiatable client authentication - similar to what Marsh Ray highlighted a long time ago. What if a request or action spans both the early and the regular data sections? what would a "safe" API look like, for an SSL/TLS library layer? It seems like the benefits of of 0-RTT boil down to two things; 1. Increased throughput 2. Give the recipient a chance to a get a head-start on servicing some kind of request. For 1. Raw data throughput could be improved by envelope encrypting the early data; and transferring the envelope key only once the session has been fully authenticated. Not that interesting to most people; but works. I can't think of a good way to achieve 2 without all of the problems that have been mentioned. At a minimum I'd suggest that the draft could not call it "data", but maybe instead "hint"; and make it so that early_data and application_data are not supposed to appear sequentially in a stream. E.g. someone calling TLSRead() or whatever should never expect to see the early_data; it's a deliberate and separate stream. -- Colm --001a114dcb02c9e57d052dfa3323 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
With 0rtt, I = think it also becomes a dangerous
implement. So, that's my personal opinion, while not wearing an
AD hat.

+1 for this as 0RTT is outlined= in the draft. But to expand a little:

* Losing fo= rward secrecy for "GET" requests and user cookies seems like a ve= ry bad privacy trade-off. Collection of wire data, combined with a bug or a= n attack that could disclose the ECDH parameters, does not seem so far fetc= hed these days.

* I imagine that 0RTT data may be = intended for pre-fetching hints, e.g. "I'm request URL foo as user= bar, so please get a start on fetching the resources I need". That su= ggests trivial application-level "is the cache warm" side channel= s, or "lets trash the whole cache" DOS attacks, would both be com= mon. =C2=A0

* A vast number of APIs build on top o= f TLS/HTTPS are not idempotent or replay safe. Even carefully designed APIs= may have subtle side effects such as a user being charged for the request,= or the request counting towards a throttle of some kind. Even ones as sill= y as there go your 10 free nytimes articles; or booting an opponent out of = your less-than-friendly sudoku tournament.=C2=A0

*= The draft calls out that early data needs to be handled differently than r= egular TLS data. This reminds me of the problems with renegotiatable client= authentication - similar to what Marsh Ray highlighted a long time ago. Wh= at if a request or action spans both the early and the regular data section= s? what would a "safe" API look like, for an SSL/TLS library laye= r?

It seems like the benefits of of 0-RTT boil down to two things;

1. Increased t= hroughput
2. Give the recipient a chance to= a get a head-start on servicing some kind of request.

For 1. Raw data throughput= could be improved by envelope encrypting the early data; and transferring = the envelope key only once the session has been fully authenticated. Not th= at interesting to most people; but works. I can't think of a good way t= o achieve 2 without all of the problems that have been mentioned.

At a minimum I&= #39;d suggest that the draft could not call it "data", but maybe = instead "hint"; and make it so that early_data and application_da= ta are not supposed to appear sequentially in a stream. E.g. someone callin= g TLSRead() or whatever should never expect to see the early_data; it's= a deliberate and separate stream.=C2=A0
--
Colm
--001a114dcb02c9e57d052dfa3323-- From nobody Sun Mar 13 21:11:33 2016 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 5766D12DDF6; Fri, 11 Mar 2016 15:05:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.16.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160311230532.15028.96411.idtracker@ietfa.amsl.com> Date: Fri, 11 Mar 2016 15:05:32 -0800 Archived-At: X-Mailman-Approved-At: Sun, 13 Mar 2016 21:11:33 -0700 Cc: tls@ietf.org Subject: [TLS] tls - Requested sessions have been scheduled for IETF 95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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 Mar 2016 23:05:34 -0000 Dear spt, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:30:00) Tuesday, Morning Session I 1000-1230 Room Name: Atlantico B size: 125 --------------------------------------------- tls Session 2 (2:30:00) Thursday, Morning Session I 1000-1230 Room Name: Atlantico C size: 225 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: spt Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb opsawg httpauth httpbis dane cfrg cose jose acme trans uta capport curdle Second Priority: sacm oauth sidr i2nsf Special Requests: Please avoid LURK BOF. --------------------------------------------------------- From nobody Sun Mar 13 21:15:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A0012D946 for ; Sun, 13 Mar 2016 21:15:40 -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=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 fuYR-p7azmAe for ; Sun, 13 Mar 2016 21:15:38 -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 6A90812D93E for ; Sun, 13 Mar 2016 21:15:38 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g3so153684450ywa.3 for ; Sun, 13 Mar 2016 21:15:38 -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:date:message-id:subject:from:to :cc; bh=ga8WtKZ7Z+afojdy5GAlhnXpWYp4mKpqJ+mYS2cgq/s=; b=E9OwZ2l0XfaVRnXU85lOkE6laGxyRzPyVFpQIRmdstIlyr9cTXM189BI8WrT0Tfx1r nPihyvlUUXmKD3ZWsTNT/0kywdeupFIMagZze4Ec7Mm9HJeFyTbthpZatxCQ5u9R0DVv o9bjGYy40pa/pNv5R1tO/5ct6UX+wauDk8o8QuWg4BDFTXRufaSY/M02l+CSU9hLRoA6 M68GSiEz9NoIW36q3hLT1yAu5AD5gRUd81aimweNSEUOpEFQc0E9s668vF9UlIz5WjKh U99qvP1FUv8aMNp0JJDGKUUBiFeQl7seHtuyCzRBQRkfDFahzoTNHoKrSJycTqkKl7WJ EQbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ga8WtKZ7Z+afojdy5GAlhnXpWYp4mKpqJ+mYS2cgq/s=; b=NueuaL+HGuj9du3QJqOyS8tfHXQQVSoGDeKoXfDAKMe6qeJZZkeGjvbw+R2JgR81NH AIJ7VwJNFKwxoc1+TITvaF0p0bDIESJZffSoivkkzWz/zoJbHogN/ASMUA8dQ0/mVFQL vCjmu+Hh1Hfx/0XQC3KYg+seMThNXAkOWj+Y2b7xT2L5UNIpeNX/Wjz0daz20ZLlxFPQ 7CfIeIcWF2Et10vlhDAPl0fjpP6jjPHZwVStTZoRnlJ42LwDu+ULM6z6q4ZLdbGQzkST ono0veG28t08J8T0cf+DBY9Qkm1WW9/X+Wp49doHWkuYJmoUd0SnE94Mzvu7ZSdtlIB3 paOQ== X-Gm-Message-State: AD7BkJI4/wbjsSDXefJYzulA50ve4r5dY8u1dQggbDEW6uuv82L8vX2vg+fnQQSWuKu5rFnj+0u3lP0xecFJ4Q== MIME-Version: 1.0 X-Received: by 10.13.252.197 with SMTP id m188mr12071006ywf.281.1457928937705; Sun, 13 Mar 2016 21:15:37 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Sun, 13 Mar 2016 21:15:37 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> Date: Sun, 13 Mar 2016 21:15:37 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c06c24070fcb9052dfa884d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:15:40 -0000 --94eb2c06c24070fcb9052dfa884d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ar D=C3=A9 Domhnaigh 13 M=C3=A1rta 2016, scr=C3=ADobh Eric Rescorla : > > > 1. Nothing requires applications to use this feature at all. First, serve= rs > need to advertise it and are free to (a) not offer clients the ability to > send > 0-RTT data and (b) refuse to accept it if clients send it. Moreover, > everyone > I know of who is considering building a 1.3 library intends to provide > that data to the server via a separate API, so the server will have to wo= rk > to get it. > security is very difficult to judge and measure - but speed is very easy. This sets up a sort of "race to the bottom" where providers may feel pressured to respond and enable an unsafe feature; because the speed benefit is more apparent than the loss of security. There's a real trade off; we should favor the s in tls :) - Colm --=20 Colm --94eb2c06c24070fcb9052dfa884d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Ar D=C3=A9 Domhnaigh 13 M=C3=A1rta 2016, scr=C3=ADobh Eric Rescorla= <ekr@rtfm.com>:

1. Nothing requires applications to use this = feature at all. First, servers
need to advertise it and are free = to (a) not offer clients the ability to send
0-RTT data and (b) r= efuse to accept it if clients send it. Moreover, everyone
I know = of who is considering building a 1.3 library intends to provide
t= hat data to the server via a separate API, so the server will have to work<= /div>
to get it.

security is very difficult to judge and measure - but speed is very easy.= This=C2=A0sets up a sort of "race to the bottom" where providers= may=C2=A0feel pressured to respond and enable an unsafe feature; because t= he speed benefit is more apparent than the loss of security.=C2=A0 There= 9;s a real trade off; we should favor the s in tls :)

-= =C2=A0
Colm


--
Colm
--94eb2c06c24070fcb9052dfa884d-- From nobody Sun Mar 13 21:29:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D0A12D957 for ; Sun, 13 Mar 2016 21:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SySa0GoNSKEF for ; Sun, 13 Mar 2016 21:29:15 -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 4ED6712D515 for ; Sun, 13 Mar 2016 21:29:14 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id z76so209227332iof.3 for ; Sun, 13 Mar 2016 21:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=NKdiCqqoShjnqULct7NKPPKJj2SARLj/yDPTSf7aYlU=; b=h7QnvG4dq7e4o8Ex8xqTBMbfGZ23epPKsEKGZCEINwsu88qDnaPOfWObsksNdPFMRk CzAdHN4gQCjg1A/GdiujttOXvDaur+5mZlIbpNqlxXt00JELt/Q9hlvqpCXYeXI9HtYY 6GEn5D8HpGBIw8dOUs9fPQs27v9xyb61+67k2/T+T3vdu9oc6dnj+xMsEzr72EWfRKFl 3/Wfk+tBNHOMVCaiy1FJII05XdOV+qcOe7Hrajqe/nsVc/JfrYNEpLl/4G7Ip2ek0ufV 8eHbjl03vwlKWu3+f3oAUheAso7TyzEY4DcV+6YTdQXIF0j3pm/eA8By/zpLKu7dl+vk lbVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NKdiCqqoShjnqULct7NKPPKJj2SARLj/yDPTSf7aYlU=; b=D9I1N8o1w3fUi7bOMWghzR7dPGFZXoqs1fexMcMo97KlRYFHTInd6F02EgC0i7MawS 5pywZJDHhfbrjpb95uHjHg2Z5MmhzZryF+QzZLVvzvxdnJVxyK56Jy8QZW4rVjtohHm3 lbDGw7vl+wfRW7N55BRHpD8Aj4evrk7nqc1lD0paBpM4yb+4z46zXJMGLdLdE74Ih9Cd A786auXW9xv44J0a26qXk50QrcNe1Jt/K5YA6r/Kfs8cgWkKP+xjpzDta7chpDV8Hv9/ 84YdKzxeW9Wi3GuPaDjgFti5Yw6r3wz5XHNkHHMC8nwiaJ9m71WnjKp8YcQHJMdg+wzD gIkQ== X-Gm-Message-State: AD7BkJIIpVIbzk05U07g/ly/9M1Q4B8t8KHnLKt8/pdwmowpJd4Yi11CI9dWvpDVJbpUedK8eUoSWQMXdI65JK7G MIME-Version: 1.0 X-Received: by 10.107.8.30 with SMTP id 30mr22598518ioi.60.1457929753328; Sun, 13 Mar 2016 21:29:13 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Sun, 13 Mar 2016 21:29:13 -0700 (PDT) In-Reply-To: <874mc9g895.fsf@setec.io> References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> Date: Sun, 13 Mar 2016 21:29:13 -0700 Message-ID: From: Bill Cox To: Harlan Lieberman-Berg Content-Type: multipart/alternative; boundary=001a113fb7160e4888052dfab935 Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:29:17 -0000 --001a113fb7160e4888052dfab935 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg wrote: > Bill Cox writes: > > More generally, I strongly believe that TLS 1.3 should not > provide options which we think should be restricted to "admins who know > what they're doing". These end up hurting us down the line (cf EXPORT > cipher suites.) > > I think we should ship the parts of 0-RTT that we believe are > intrinsically safe for (the vast majority) of the internet to enable and > use on day 1. > This is just my opinion, not Google's. Here is a dumb idea I just had: The current 0-RTT modes described in TLS 1.3 are clearly only for admins who really know what they are doing. If the current 0-RTT modes are deemed to dangerous, then how about going back to session IDs, and doing 0-RTT resumption from the session cache? This is not only fairly simple given the existing code base, but it fits well with my personal bias towards supporting strong client authentication, which basically got thrown under the bus in the current 0-RTT scheme. Frankly, my current job (working on token binding) is a lot less appealing in a world where servers cannot do proofs-of-possession with clients. With 0-RTT cached session resumption, the TLS sequence numbers remain intact, and we inherit the security parameters from the original connection. The new replay attacks go away, as do most of the "new and exciting" ways to PWN TLS 1.3 0-RTT. The new tickets could still be supported to enable advanced operators the flexibility they need to implement stateless 0-RTT, but from the TLS point of view, it would just be a 0-RTT resume using a session ID, with additional ticket data. If the admins at a particular company want to stuff all the session state into the ticket and accept the security consequences of stateless 0-RTT resumption, I think they should have the flexibility to do that. I _think_ the new tickets give them what they need. This would enable the standard 0-RTT resume to be as secure as keeping the connection alive the whole time. I think it would stop this "race to the bottom" problem people are worried about on this thread. So... how dumb is this idea? Bill --001a113fb7160e4888052dfab935 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg <hlieberman@setec.io<= /a>> wrote:
Bi= ll Cox <waywardgeek@google.com= > writes:

More generally, I strongly believe that TLS 1.3 should not
provide options which we think should be restricted to "admins who kno= w
what they're doing".=C2=A0 These end up hurting us down the line (= cf EXPORT
cipher suites.)

I think we should ship the parts of 0-RTT that we believe are
intrinsically safe for (the vast majority) of the internet to enable and use on day 1.

This is just my opinion, = not Google's.=C2=A0 Here is a dumb idea I just had:

The current 0-RTT modes described in TLS 1.3 are clearly only for adm= ins who really know what they are doing.=C2=A0 If the current 0-RTT modes a= re deemed to dangerous, then how about going back to session IDs, and doing= 0-RTT resumption from the session cache?

This is = not only fairly simple given the existing code base, but it fits well with = my personal bias towards supporting strong client authentication, which bas= ically got thrown under the bus in the current 0-RTT scheme.=C2=A0 Frankly,= my current job (working on token binding) is a lot less appealing in a wor= ld where servers cannot do proofs-of-possession with clients.=C2=A0 With 0-= RTT cached session resumption, the TLS sequence numbers remain intact, and = we inherit the security parameters from the original connection.=C2=A0 The = new replay attacks go away, as do most of the "new and exciting" = ways to PWN TLS 1.3 0-RTT.

The new tickets could s= till be supported to enable advanced operators the flexibility they need to= implement stateless 0-RTT, but from the TLS point of view, it would just b= e a 0-RTT resume using a session ID, with additional ticket data.=C2=A0 If = the admins at a particular company want to stuff all the session state into= the ticket and accept the security consequences of stateless 0-RTT resumpt= ion, I think they should have the flexibility to do that.=C2=A0 I _think_ t= he new tickets give them what they need.

This woul= d enable the standard 0-RTT resume to be as secure as keeping the connectio= n alive the whole time.=C2=A0 I think it would stop this "race to the = bottom" problem people are worried about on this thread.
So... how dumb is this idea?

Bill
<= /div>
--001a113fb7160e4888052dfab935-- From nobody Sun Mar 13 23:23:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6215812D51C for ; Sun, 13 Mar 2016 23:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4y9i9zsYVrS for ; Sun, 13 Mar 2016 23:23:12 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id E543212D1DC for ; Sun, 13 Mar 2016 23:23:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id BE8FD1C7C; Mon, 14 Mar 2016 08:23:09 +0200 (EET) 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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id opKUIihajS7N; Mon, 14 Mar 2016 08:23:09 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7827B27F; Mon, 14 Mar 2016 08:23:09 +0200 (EET) Date: Mon, 14 Mar 2016 08:23:08 +0200 From: Ilari Liusvaara To: Harlan Lieberman-Berg Message-ID: <20160314062308.GA13843@LK-Perkele-V2.elisa-laajakaista.fi> References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <874mc9g895.fsf@setec.io> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 06:23:14 -0000 On Sun, Mar 13, 2016 at 09:26:14PM -0400, Harlan Lieberman-Berg wrote: > > I agree with a slight tweak in wording here, Bill. I think that we > /should/ drop the parts of 0-RTT where we are not confident that an > admin who blindly enables functionality in TLS 1.3 will not end up > harming themselves. > > More generally, I strongly believe that TLS 1.3 should not > provide options which we think should be restricted to "admins who know > what they're doing". These end up hurting us down the line (cf EXPORT > cipher suites.) > > I think we should ship the parts of 0-RTT that we believe are > intrinsically safe for (the vast majority) of the internet to enable and > use on day 1. Here are what I think would be reasonable restrictions on 0-RTT: - Require labeling the application protocol 0RTT data is for. * To prevent cross-protocol attacks. - Require application protocol to profile the semantics of 0RTT data. * To at least get some idea of protocol-level security properties. * Some applications might need to handle 0RTT specially for security reasons (HTTP/2?) - Require application to specifically request 0RTT data. * To prevent unaware applications from thinking it has the same properties as main data. - Require 0RTT data to be kept separate from main application data. * To make more difficult for applications to mix it up. - Ensure that no 0RTT mode invokes screwy cryptographic behaviour. * Famous last words: "Not believed to be exploitable". And none of these should be subject to "admin configuration" (disabling entiere 0-RTT is). -Ilari From nobody Mon Mar 14 04:32:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172FC12D9CC for ; Mon, 14 Mar 2016 04:32:52 -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 Z7-DIH-FtK6X for ; Mon, 14 Mar 2016 04:32:50 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A4E312D975 for ; Mon, 14 Mar 2016 04:32:50 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h129so163020203ywb.1 for ; Mon, 14 Mar 2016 04:32:50 -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=7xeRrizyzPPSyawfrYB7cFvnZzuwwpkvyNQLY4a9ZS0=; b=FwvIQ+tFP0ynTljMArLxQovIG9+viyHenrbvVjWUTyP2XwI57ITO4bYxk7k3k3M+fz oakxnp/KdaGTuX3x2uF2s4pC3eyPT2oa3mfnZZYvtyfA7YtDLvBrOIEdc3bCPaZ+ikbg /Poeof4mLFYpybVAxyY45gBnI23IaMM2s7LRPAkhGIsq7w3T3uo8bpdhUeJGCjbiBzII CxK5A9znsZNF2U4iBkIfbFnDiIwSgx7sYMcX9+XuJSs4lHkBtkDXJgZztSmtjEHcyzGQ w7sa+y5Myl4azbOxipcTL2wzvArH0UneeRc/XcIfW9Sf9YdZFgVX0uMIbqci/i45GfNp XSFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7xeRrizyzPPSyawfrYB7cFvnZzuwwpkvyNQLY4a9ZS0=; b=cOi8Rma/VdmoDEE3B1VwnOsppVRk6acHf7frt+D5V4NVCn42LL4wk1oa9I1GIS3pGa 9oi7VMC1zKIHvgOpPuz/S/13vdPmM1QlDI2tMXeVPyFO1P5GSNEvOmQSgMOD2oF6pvSI qlR7wPSdD3snYMvh45Y+8UO/41MjxzEs8t6EmE4LGFbYSLZ80N9oeQCWGb15jQqazqqE vB8Htuq9gf8h3i6kX+jnm1Jk+PyUW2emzxEE/f6nnstW5wdIsls/NCY1L1Mt4n8etOrr SaN26+aoFLe7VdUAv8MISa8ivoj0yJSQDckyQJy1v245XnqTVpCswkaNCIIkyNZAGJaU QJPg== X-Gm-Message-State: AD7BkJLbaiWNypML9IP/3G59P4qoglb/TcCc9L1MNIQ0ob2Vy68+o7EMoQpwI8MdTmfI8G1JvjAdscvEd0VQng== X-Received: by 10.129.46.87 with SMTP id u84mr11602791ywu.129.1457955169325; Mon, 14 Mar 2016 04:32:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 04:32:09 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> From: Eric Rescorla Date: Mon, 14 Mar 2016 04:32:09 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=001a114140baf78507052e00a33c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:32:52 -0000 --001a114140baf78507052e00a33c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 13, 2016 at 8:51 PM, Colm MacC=C3=A1rthaigh wrote: > On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> With 0rtt, I think it also becomes a dangerous >> implement. So, that's my personal opinion, while not wearing an >> AD hat. >> > > +1 for this as 0RTT is outlined in the draft. But to expand a little: > > * Losing forward secrecy for "GET" requests and user cookies seems like a > very bad privacy trade-off. Collection of wire data, combined with a bug = or > an attack that could disclose the ECDH parameters, does not seem so far > fetched these days. > > * I imagine that 0RTT data may be intended for pre-fetching hints, e.g. > "I'm request URL foo as user bar, so please get a start on fetching the > resources I need". That suggests trivial application-level "is the cache > warm" side channels, or "lets trash the whole cache" DOS attacks, would > both be common. > > * A vast number of APIs build on top of TLS/HTTPS are not idempotent or > replay safe. Even carefully designed APIs may have subtle side effects su= ch > as a user being charged for the request, or the request counting towards = a > throttle of some kind. Even ones as silly as there go your 10 free nytime= s > articles; or booting an opponent out of your less-than-friendly sudoku > tournament. > > * The draft calls out that early data needs to be handled differently tha= n > regular TLS data. This reminds me of the problems with renegotiatable > client authentication - similar to what Marsh Ray highlighted a long time > ago. What if a request or action spans both the early and the regular dat= a > sections? what would a "safe" API look like, for an SSL/TLS library layer= ? > > It seems like the benefits of of 0-RTT boil down to two things; > > 1. Increased throughput > 2. Give the recipient a chance to a get a head-start on servicing some > kind of request. > > For 1. Raw data throughput could be improved by envelope encrypting the > early data; and transferring the envelope key only once the session has > been fully authenticated > Can you expand on this. Cryptographically, this is effectively how both the DHE and PSK modes work: you get a key in session N (which is authenticated) and you use it in session N+1. -Ekr . Not that interesting to most people; but works. I can't think of a good > way to achieve 2 without all of the problems that have been mentioned. > > At a minimum I'd suggest that the draft could not call it "data", but > maybe instead "hint"; and make it so that early_data and application_data > are not supposed to appear sequentially in a stream. E.g. someone calling > TLSRead() or whatever should never expect to see the early_data; it's a > deliberate and separate stream. > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114140baf78507052e00a33c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 13, 2016 at 8:51 PM, Colm MacC=C3=A1rthaigh <colm@allcosts= .net> wrote:
On Sun, Mar 13, 2016 at 4:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
With 0rtt, I think it also becomes a dangerous
implement. So, that's my personal opinion, while not wearing an
AD hat.

+1 for this as 0RTT is o= utlined in the draft. But to expand a little:

* Lo= sing forward secrecy for "GET" requests and user cookies seems li= ke a very bad privacy trade-off. Collection of wire data, combined with a b= ug or an attack that could disclose the ECDH parameters, does not seem so f= ar fetched these days.

* I imagine that 0RTT data = may be intended for pre-fetching hints, e.g. "I'm request URL foo = as user bar, so please get a start on fetching the resources I need". = That suggests trivial application-level "is the cache warm" side = channels, or "lets trash the whole cache" DOS attacks, would both= be common. =C2=A0

* A vast number of APIs build o= n top of TLS/HTTPS are not idempotent or replay safe. Even carefully design= ed APIs may have subtle side effects such as a user being charged for the r= equest, or the request counting towards a throttle of some kind. Even ones = as silly as there go your 10 free nytimes articles; or booting an opponent = out of your less-than-friendly sudoku tournament.=C2=A0

* The draft calls out that early data needs to be handled differently= than regular TLS data. This reminds me of the problems with renegotiatable= client authentication - similar to what Marsh Ray highlighted a long time = ago. What if a request or action spans both the early and the regular data = sections? what would a "safe" API look like, for an SSL/TLS libra= ry layer?

It seems like the benefits of of 0-RTT boil down to two things;

1. Incr= eased throughput
2. Give the recipient a ch= ance to a get a head-start on servicing some kind of request.

For 1. Raw data thr= oughput could be improved by envelope encrypting the early data; and transf= erring the envelope key only once the session has been fully authenticated<= /div>

Can you expand on this. C= ryptographically, this is effectively how both the DHE and PSK
mo= des work: you get a key in session N (which is authenticated) and you use i= t
in session N+1.


-Ekr

. Not that interesting to most= people; but works. I can't think of a good way to achieve 2 without al= l of the problems that have been mentioned.

At a minimum I'd suggest that the= draft could not call it "data", but maybe instead "hint&quo= t;; and make it so that early_data and application_data are not supposed to= appear sequentially in a stream. E.g. someone calling TLSRead() or whateve= r should never expect to see the early_data; it's a deliberate and sepa= rate stream.=C2=A0



--
Colm

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


--001a114140baf78507052e00a33c-- From nobody Mon Mar 14 04:39:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C18112DA30 for ; Mon, 14 Mar 2016 04:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hylGMX7MB18U for ; Mon, 14 Mar 2016 04:39:40 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 795C612DA5F for ; Mon, 14 Mar 2016 04:39:40 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id h129so163197521ywb.1 for ; Mon, 14 Mar 2016 04:39: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=26aIDx9xHDodJBV9YNiA3Q8p4ZebhNcBhrdGYUQGgmQ=; b=IrJcrZX5PWsJLnnLR4Ae6nJxODMNcjegV+zT8RSVJYhcwh+bPOBzrWei+NAgvcSCel k3QUWD92e/g4oIj0b1UO3SJLWZ403R5dj/txYGcTenuosLakeuWxXGfNH12CUgU4gEQq f78ig1lI+Ppl8C+fadUqyCB1LeA6cpsdw7yVJ//uIO18R/xV/Mog+IzJK0SOs9Y5QfQz b+uLzkFmnuNbgwwhzK+3snfWaZ0MjyppshDRxzp1acI/9LuR39hnBeFaCPPWxz0cAl1w uI/owxqAhbQnRSoSVG3Ymr0vv1mtuzC2cMshV9mksWx07lSWpNy0SQLUZYzVf7SUu4Hf pTPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=26aIDx9xHDodJBV9YNiA3Q8p4ZebhNcBhrdGYUQGgmQ=; b=S2AShm11TwCxSFeQBl6XPqNLtMZf3RxfZkuMq9A+85nU9I7UvbDYZBj09lQXUgsusf SgGUoH1Q4f+l7Y7N6rdnmtTxezgNVq+zkqEHDvwiKQ7RwsSAEmuiilAZRWkIKTdE2Z68 M9UGwWO2NYSsskZgYPxp/gWSvqu9ZwlgiU2Ql3XU9MsMufGfHrmp78te+Le7GoQiXy52 14lHVQ5/YSwUbaQ0Mbzz75nsJTjSo3/DCgrmV1sKAJbGw908vn+rK1T2GaR4bpBqQ7mU orobVxSCmFaDvqyDp/j9hbgu8qLp/47wp9pZLV7jO1AWF6qmsyEnQuoFSsOwgzd0waVg c4HQ== X-Gm-Message-State: AD7BkJIP2lL0KS9BBySqXH9WqQ9rZlA16QQGlv5Xpzgn8rm1F7ibPDgrC2ouCHVXNTnakjVbzL0uF0ZrdX7Tug== X-Received: by 10.37.230.202 with SMTP id d193mr12594746ybh.74.1457955579747; Mon, 14 Mar 2016 04:39:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 04:39:00 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> From: Eric Rescorla Date: Mon, 14 Mar 2016 04:39:00 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0afb0e6e0e53052e00bcd7 Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:39:42 -0000 --94eb2c0afb0e6e0e53052e00bcd7 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox wrote: > On Sun, Mar 13, 2016 at 6:26 PM, Harlan Lieberman-Berg < > hlieberman@setec.io> wrote: > >> Bill Cox writes: >> >> More generally, I strongly believe that TLS 1.3 should not >> provide options which we think should be restricted to "admins who know >> what they're doing". These end up hurting us down the line (cf EXPORT >> cipher suites.) >> >> I think we should ship the parts of 0-RTT that we believe are >> intrinsically safe for (the vast majority) of the internet to enable and >> use on day 1. >> > > This is just my opinion, not Google's. Here is a dumb idea I just had: > > The current 0-RTT modes described in TLS 1.3 are clearly only for admins > who really know what they are doing. If the current 0-RTT modes are deemed > to dangerous, then how about going back to session IDs, and doing 0-RTT > resumption from the session cache? > Isn't this more or less what we have been calling PSK-resumption? Can you explain the difference? -Ekr > This is not only fairly simple given the existing code base, but it fits > well with my personal bias towards supporting strong client authentication, > which basically got thrown under the bus in the current 0-RTT scheme. > Frankly, my current job (working on token binding) is a lot less appealing > in a world where servers cannot do proofs-of-possession with clients. With > 0-RTT cached session resumption, the TLS sequence numbers remain intact, > and we inherit the security parameters from the original connection. The > new replay attacks go away, as do most of the "new and exciting" ways to > PWN TLS 1.3 0-RTT. > > The new tickets could still be supported to enable advanced operators the > flexibility they need to implement stateless 0-RTT, but from the TLS point > of view, it would just be a 0-RTT resume using a session ID, with > additional ticket data. If the admins at a particular company want to > stuff all the session state into the ticket and accept the security > consequences of stateless 0-RTT resumption, I think they should have the > flexibility to do that. I _think_ the new tickets give them what they need. > > This would enable the standard 0-RTT resume to be as secure as keeping the > connection alive the whole time. I think it would stop this "race to the > bottom" problem people are worried about on this thread. > > So... how dumb is this idea? > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0afb0e6e0e53052e00bcd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 13, 2016 at 9:29 PM, Bill Cox <waywardgeek@google.com= > wrote:
<= div class=3D"gmail_extra">
On Sun, Mar 13, 2016 a= t 6:26 PM, Harlan Lieberman-Berg <hlieberman@setec.io> wro= te:
Bill Cox <<= a href=3D"mailto:waywardgeek@google.com" target=3D"_blank">waywardgeek@goog= le.com> writes:

More generally, I strongly believe that TLS 1.3 should not
provide options which we think should be restricted to "admins who kno= w
what they're doing".=C2=A0 These end up hurting us down the line (= cf EXPORT
cipher suites.)

I think we should ship the parts of 0-RTT that we believe are
intrinsically safe for (the vast majority) of the internet to enable and use on day 1.

This is just my op= inion, not Google's.=C2=A0 Here is a dumb idea I just had:
The current 0-RTT modes described in TLS 1.3 are clearly only = for admins who really know what they are doing.=C2=A0 If the current 0-RTT = modes are deemed to dangerous, then how about going back to session IDs, an= d doing 0-RTT resumption from the session cache?

Isn't this more or less what we have been= calling PSK-resumption? Can you explain
the difference?
-Ekr

=

T= his is not only fairly simple given the existing code base, but it fits wel= l with my personal bias towards supporting strong client authentication, wh= ich basically got thrown under the bus in the current 0-RTT scheme.=C2=A0 F= rankly, my current job (working on token binding) is a lot less appealing i= n a world where servers cannot do proofs-of-possession with clients.=C2=A0 = With 0-RTT cached session resumption, the TLS sequence numbers remain intac= t, and we inherit the security parameters from the original connection.=C2= =A0 The new replay attacks go away, as do most of the "new and excitin= g" ways to PWN TLS 1.3 0-RTT.

The new tickets= could still be supported to enable advanced operators the flexibility they= need to implement stateless 0-RTT, but from the TLS point of view, it woul= d just be a 0-RTT resume using a session ID, with additional ticket data.= =C2=A0 If the admins at a particular company want to stuff all the session = state into the ticket and accept the security consequences of stateless 0-R= TT resumption, I think they should have the flexibility to do that.=C2=A0 I= _think_ the new tickets give them what they need.

This would enable the standard 0-RTT resume to be as secure as keeping the= connection alive the whole time.=C2=A0 I think it would stop this "ra= ce to the bottom" problem people are worried about on this thread.

So... how dumb is this idea?

Bill

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


--94eb2c0afb0e6e0e53052e00bcd7-- From nobody Mon Mar 14 05:10:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB6E12D572 for ; Mon, 14 Mar 2016 05:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcZFU0XOHn4J for ; Mon, 14 Mar 2016 05:10:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D203612D55F for ; Mon, 14 Mar 2016 05:10:37 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id E3B0B6E78D; Mon, 14 Mar 2016 12:10:36 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2ECAWVQ007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Mar 2016 08:10:35 -0400 Message-ID: <1457957432.3053.47.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla , Stephen Farrell Date: Mon, 14 Mar 2016 13:10:32 +0100 In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:10:40 -0000 On Sun, 2016-03-13 at 13:38 +0100, Eric Rescorla wrote: > > > > However, if I'm in the rough about the above, (which seems > > to me to be the case now) then my job as AD when I get a > > publication > > request that includes 0rtt, will include figuring out if that's > > safe or not. And I've no clue how I'll do that unless the WG > > have already done some analysis of the many, many protocols > > that use TLS. Note that I do not consider "use a different API" > > to be a sufficient answer here (it is necessary, but not > > sufficient).  > It seem to me that there are several important mitigating factors > here. > > 1. Nothing requires applications to use this feature at all. First, > servers > need to advertise it and are free to (a) not offer clients the > ability to send > 0-RTT data and (b) refuse to accept it if clients send it. Moreover, > everyone > I know of who is considering building a 1.3 library intends to > provide > that data to the server via a separate API, so the server will have > to work > to get it. It is important to see how protocols are perceived. For many people TLS 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an attack against TLS 1.3 with rtt, will be perceived as an attack against TLS 1.3 protocol. Even if the published attack against TLS 1.3 with 0rtt was an expected one (i.e., replay of data), if the attack impact is high, that may not be sufficient to stop the avalanche of bad publicity. In turn that will lead several people losing confidence to TLS 1.3 as a protocol, even TLS and the IETF process overall.   My suggestion, if you need 0rtt, publish it as a different document, don't mix it with TLS 1.3. The security requirements from TLS are vastly different from the security requirements of a 0rtt protocol. regards, Nikos From nobody Mon Mar 14 07:59:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EE212DAEF for ; Mon, 14 Mar 2016 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsvtcPzm_ai3 for ; Mon, 14 Mar 2016 07:59:29 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C4512DC72 for ; Mon, 14 Mar 2016 07:52:51 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2EEqF5R031812; Mon, 14 Mar 2016 07:52:50 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=Klm43Emu6jTTKBA9KlM/nykAXT9MTr9akHLL/x9d55E=; b=mC6KWJyzfW0RNShH/Ezb7uFrfL6ZUsP49bVK0eXTE+vHr5/tkty1I6aRVS2ldUr7rPpV VCOYfg7QJybMZhtKenqAY7c3BFbOui6CZ+qTTZoaiU1kZU9fFeY1DM62kWoF/fO1H2nB ORuFaYkjMishq61RtM8qNGOESFTYOhdROAM= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21nycur111-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 07:52:50 -0700 Received: from PRN-CHUB18.TheFacebook.com (192.168.16.72) by PRN-CHUB16.TheFacebook.com (192.168.16.66) with Microsoft SMTP Server (TLS) id 14.3.248.2; Mon, 14 Mar 2016 07:52:49 -0700 Received: from PRN-MBX02-1.TheFacebook.com ([169.254.2.203]) by PRN-CHUB18.TheFacebook.com ([fe80::6964:6730:1d3b:b80c%13]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 07:52:48 -0700 From: Kyle Nekritz To: Bill Cox , Scott Schmit Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmI7Upjw+kKz0W8CBQxY0euOZ9YWGEAgAAQgoD//96AYA== Date: Mon, 14 Mar 2016 14:52:47 +0000 Message-ID: <8A79BFEDF6986C46996566F91BB63C860D652CCC@PRN-MBX02-1.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D652CCCPRNMBX021TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_05:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:59:32 -0000 --_000_8A79BFEDF6986C46996566F91BB63C860D652CCCPRNMBX021TheFac_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that idempotency is a relatively straightforward idea, it seems rea= sonable to trust that the application layer will only send 0-RTT data that = is idempotent in terms of server-side state. I also don't think it's that m= uch different than the current state of TLS. Providing strict replay protec= tion over an unreliable network link requires that requests are never retri= ed in the case of network failure - which is not practical in most applicat= ions. If the application doesn't already have some way to provide idempoten= cy to requests that change state, it's likely already in a bad place (see h= ttp://blog.valverde.me/2015/12/07/bad-life-advice/). However, to safely use 0-RTT (in the current draft), the 0-RTT data needs a= stricter property than idempotency, it needs to be completely replay-safe.= Unlike TLS now, where the opportunity for replay is linear in relation to = the number of times a client is willing to retry a request, an attacker can= replay a request an unlimited number of times. There's two capabilities a passive eavesdropper gains from this that concer= n me the most: 1) Changes to the response's length and timing can be observed over tim= e 2) The response's timing can be statistically analyzed (since the reque= st can be replayed an unlimited number of times) Mitigating these at the application layer seems much harder, if not impossi= ble, to get right. Adding a client time indicator (as I suggested in the other thread) makes t= his harder, but it certainly doesn't solve either problem. A server-side cl= ient nonce cache does solve these problems, which I think may be required t= o use 0-RTT safely. That said, I echo Bill's comments about the need for 0-= RTT in TLS 1.3. Speed is very important. Kyle From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Bill Cox Sent: Sunday, March 13, 2016 6:23 PM To: Scott Schmit Cc: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit > wrote: So why are we adding a protocol optimization known from the start to be insecure (or less secure than you'd expect from using a PFS cipher suite)? If you require PFS with resolution on the order of seconds to minutes rathe= r than hours to days, you probably do not want to use tickets either. The = ticket decryption key rotation schedule limits PFS. 0-RTT resumes do not m= ake this worse. What percentage of servers that have a perceived need for 0-RTT will be able to securely use and benefit from this feature as their infrastructure is actually implemented? Well, Google already sees a significant fraction. Going back to 1-RTT woul= d be a significant downgrade. If almost everyone should turn it off, why are we including it? Almost every small site on the Internet should turn it off, but the large s= ites that want to enable it could make up a large fraction of all traffic. Most server admins won't be reading the TLSv1.3 spec. They're going to see "shiny feature added specifically in this version that makes it faster!" with *maybe* a warning that there are risks, which they'll dismiss because "if it was so insecure, they wouldn't have included it in the protocol in the first place." Unless 0-RTT can be fixed, it looks like an attractive nuisance. I agree. Instead of dropping 0-RTT, I think we should make it easy for adm= ins to learn about what is involved in using 0-RTT in ways we believe are s= ecure. The two modes I am aware of that are potentially as secure as TLS 1= .2 session resumption are: - Do 0-RTT session resumption using a session cache, using the ticket as th= e session ID. This should have the same security as TLS 1.2 resume, right? - At the HTTP app layer, make all requests that change state transaction ba= sed with unique transaction numbers, so replay attacks fail to change serve= r state. Done successfully, this should be more secure than TLS 1.2 resump= tion, shouldn't it? Are we aware of other secure ways to do 0-RTT? Bill --_000_8A79BFEDF6986C46996566F91BB63C860D652CCCPRNMBX021TheFac_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that idempotency is a relatively straightfo= rward idea, it seems reasonable to trust that the application layer will on= ly send 0-RTT data that is idempotent in terms of server-side state. I also don’t think it’s that much differ= ent than the current state of TLS. Providing strict replay protection over = an unreliable network link requires that requests are never retried in the = case of network failure – which is not practical in most applications. If the application doesn’t already have some w= ay to provide idempotency to requests that change state, it’s likely = already in a bad place (see http://blog= .valverde.me/2015/12/07/bad-life-advice/).

 

However, to safely use 0-RTT (in the current draft)= , the 0-RTT data needs a stricter property than idempotency, it needs to be= completely replay-safe. Unlike TLS now, where the opportunity for replay is linear in relation to the number of times a = client is willing to retry a request, an attacker can replay a request an u= nlimited number of times.

 

There’s two capabilities a passive eavesdropp= er gains from this that concern me the most:

    1) Changes to the response’= ;s length and timing can be observed over time

    2) The response’s timing c= an be statistically analyzed (since the request can be replayed an unlimite= d number of times)

Mitigating these at the application layer seems muc= h harder, if not impossible, to get right.

 

Adding a client time indicator (as I suggested in t= he other thread) makes this harder, but it certainly doesn’t solve ei= ther problem. A server-side client nonce cache does solve these problems, which I think may be required to use 0-RTT safely. T= hat said, I echo Bill’s comments about the need for 0-RTT in TLS 1.3.= Speed is very important.

 

Kyle

&nbs= p;

From: TLS [mailto:tls-bounces@ietf.o= rg] On Behalf Of Bill Cox
Sent: Sunday, March 13, 2016 6:23 PM
To: Scott Schmit <i.grok@comcast.net>
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data=

 

On Sun, Mar 13, 2016 at 2:23 PM, Scott Schmit <i.grok@comcast.net> wrote:


So why are we adding a protocol optimization known from the start to be
insecure (or less secure than you'd expect from using a PFS cipher
suite)?

 

If you require PFS with resolution on the order of s= econds to minutes rather than hours to days, you probably do not want to us= e tickets either.  The ticket decryption key rotation schedule limits = PFS.  0-RTT resumes do not make this worse.

 

What percentage of servers that have a perceived nee= d for 0-RTT will be
able to securely use and benefit from this feature as their
infrastructure is actually implemented?

 

Well, Google already sees a significant fraction.&nb= sp; Going back to 1-RTT would be a significant downgrade.

 

If almost everyone should turn it off, why are we in= cluding it?

 

Almost every small site on the Internet should turn = it off, but the large sites that want to enable it could make up a large fr= action of all traffic.

 

Most server admins won't be reading the TLSv1.3 spec= .  They're going to
see "shiny feature added specifically in this version that makes it faster!" with *maybe* a warning that there are risks, which they'll dismiss because "if it was so insecure, they wouldn't have included it=
in the protocol in the first place."  Unless 0-RTT can be fixed, = it
looks like an attractive nuisance.

 

I agree.  Instead of dropping 0-RTT, I think we= should make it easy for admins to learn about what is involved in using 0-= RTT in ways we believe are secure.  The two modes I am aware of that a= re potentially as secure as TLS 1.2 session resumption are:

 

- Do 0-RTT session resumption using a session cache,= using the ticket as the session ID.  This should have the same securi= ty as TLS 1.2 resume, right?

- At the HTTP app layer, make all requests that chan= ge state transaction based with unique transaction numbers, so replay attac= ks fail to change server state.  Done successfully, this should be mor= e secure than TLS 1.2 resumption, shouldn't it?

 

Are we aware of other secure ways to do 0-RTT?<= /o:p>

 

Bill

--_000_8A79BFEDF6986C46996566F91BB63C860D652CCCPRNMBX021TheFac_-- From nobody Mon Mar 14 08:41:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D60D12DC6C for ; Mon, 14 Mar 2016 08:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNSJvz6bJQkh for ; Mon, 14 Mar 2016 08:41:31 -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 6BEAF12DC7E for ; Mon, 14 Mar 2016 08:35:26 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id m184so227064279iof.1 for ; Mon, 14 Mar 2016 08:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=6BGMRbJ7yimhgvZbmHDr/gixS+P/wszt83/9cF2eQmw=; b=TyH0r7JorbcZGmmdf9wnhP6ceSz33J73vWzWDLrm1yv80kThTrAotPte9W7Fmin2ZS WEgtz0G1NMkV9HqveszVg7pBCxLNG+Tv8l8vL03HIxKr2U5twE4jnNuflQYUSU51QvfL LPdH2BlEJRfikSNkdiIGkRY9M2RIYte2br+dt7N7GEThWAgX+szsW0Rlj7xjGNufk90S 0H2G3j/zuXmpNc1k7al5/P2f46xh8AmYhcTcckQrGBoK/rVnXr14fO/G3n9TcuR8ppem 22wKoGW12W3aISSrE2kh/Yzzv4HmZj7GaFQ1k0KUDge01E9zC4OxHpQkVgODIF2hkd+i TuEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6BGMRbJ7yimhgvZbmHDr/gixS+P/wszt83/9cF2eQmw=; b=mEGHcQvtrDW54W5QHGA3ZlKcelyACApumtHHzRtYv1zIepLbZ+4YK78hrxgQPVy1h5 jPLR6zJCiaFBmt+tF+YddbUwTerZV4zRYUemZgMfR1nhh9Zm4k8GJ42u1fdF9CuGvL9l ZFFoqDigFcPMowk107/oCXbpBW/BsUc4K1mhJiPkwTjRNcra7hoMB5u8RMYD75f83VT/ bs/c/wUcnSH03YSG8zG8jiuktLSUW7YnmalmFrbR/EPZnCoq85GQdvP/cqtG4pDi08aS bBp2i6cDhj9QUvKwVgTGMzHW92mSq8npmOFBOT7aSF+looDKhMhMfCgfpMzi/PiuACHC mdmA== X-Gm-Message-State: AD7BkJJBdtPcydH6eMzuhpaQPrs3gaWRb+1wtTXjtR2D+HCG0W+MjvEBwoOKCRbbypYLO5jEdO1tb8XtMGVmleSv MIME-Version: 1.0 X-Received: by 10.107.131.169 with SMTP id n41mr8297179ioi.132.1457969725610; Mon, 14 Mar 2016 08:35:25 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 08:35:25 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> Date: Mon, 14 Mar 2016 08:35:25 -0700 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113ebf8496ed08052e0407b6 Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:41:36 -0000 --001a113ebf8496ed08052e0407b6 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 4:39 AM, Eric Rescorla wrote: > This is just my opinion, not Google's. Here is a dumb idea I just had: >> >> The current 0-RTT modes described in TLS 1.3 are clearly only for admins >> who really know what they are doing. If the current 0-RTT modes are deemed >> to dangerous, then how about going back to session IDs, and doing 0-RTT >> resumption from the session cache? >> > > Isn't this more or less what we have been calling PSK-resumption? Can you > explain > the difference? > -Ekr > Sometimes all you need is to rename a thing to make it acceptable to everyone. What should we call stateful 0-RTT resumption vs stateless 0-RTT resumption to make the difference clear? We have all been calling "0-RTT resumption" the stateless version, whether DH-0RTT or PSK-resumption based 0-RTT. Stateless PSK-resumption has all the "new and exciting" security holes. Stateful PSK-resumption is boring, just like 1-RTT. Stateless DH-0RTT and PSK-resumption is well documented in the spec, but is dangerous. Stateful PSK-resumption is not documented in any way, and appears to have been depreciated. Users who want it will have to build it as a non-standard way to use tickets, by encoding the session-ID in the ticket. All I am suggesting is to change the documentation so that the standard 0-RTT resumption mode is the safe stateful version that puts the session-ID in the ticket (and of course, drop the DH-0RTT mode). As we all know, what matters most in security is the default mode. I am suggesting making the default 0-RTT resumption mode stateful, with a documented session-ID (and let's bring back the timestamp, too, since we'll need it). Bill --001a113ebf8496ed08052e0407b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 14, 2016 at 4:39 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
<= div>This is just my opinion, not Google's.=C2=A0 Here is a dumb idea I = just had:

The current 0-RTT modes described in TLS= 1.3 are clearly only for admins who really know what they are doing.=C2=A0= If the current 0-RTT modes are deemed to dangerous, then how about going b= ack to session IDs, and doing 0-RTT resumption from the session cache?

Isn't this m= ore or less what we have been calling PSK-resumption? Can you explain
=
the difference?
-Ekr

Sometimes all you need is to rename a thing to make it acc= eptable to everyone.=C2=A0 What should we call stateful 0-RTT resumption vs= stateless 0-RTT resumption to make the difference clear?=C2=A0 We have all= been calling "0-RTT resumption" the stateless version, whether D= H-0RTT or PSK-resumption based 0-RTT.

Stateless PS= K-resumption has all the "new and exciting" security holes.=C2=A0= Stateful PSK-resumption is boring, just like 1-RTT.=C2=A0 Stateless DH-0RT= T and PSK-resumption is well documented in the spec, but is dangerous.=C2= =A0 Stateful PSK-resumption is not documented in any way, and appears to ha= ve been depreciated.=C2=A0 Users who want it will have to build it as a non= -standard way to use tickets, by encoding the session-ID in the ticket.=C2= =A0 All I am suggesting is to change the documentation so that the standard= 0-RTT resumption mode is the safe stateful version that puts the session-I= D in the ticket (and of course, drop the DH-0RTT mode).

As we all know, what matters most in security is the default mode.=C2= =A0 I am suggesting making the default 0-RTT resumption mode stateful, with= a documented session-ID (and let's bring back the timestamp, too, sinc= e we'll need it).

Bill
--001a113ebf8496ed08052e0407b6-- From nobody Mon Mar 14 09:10:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C40C12D633 for ; Mon, 14 Mar 2016 09:10:09 -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=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 T_V8LgOSvun4 for ; Mon, 14 Mar 2016 09:10:06 -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 2648912D63B for ; Mon, 14 Mar 2016 09:10:06 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g3so173293716ywa.3 for ; Mon, 14 Mar 2016 09:10:06 -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:date:message-id:subject:from:to :cc; bh=7oHZ6+u/tCB1dOx28rFbuG1jiDRuDZT3oLUXt1+TtH4=; b=vf88d5csUPUOulYEKCJQwJI44YzQ0IcJfTavzm6N109YZ1HRIxRYRFol9jQrvpEztX I9mxO44Blvh73polgAikTqPgBOYMtLxHcck3kCog8DqWOcdhrIHu/N0/68ijZnxOjur/ nkwjda3rLFHy7pq4WyoKxSFnKnf61FeJClj5N6i91mMI/CtKRt2bTF2LRkNoIvBZzGdm 3GFVUaV/OJUdE5lYKRGOY9JsGKRSeWUxlLENMlqD4E25YDP2L+nQon4wJ1vDptN8XMLf wqN4d4v0o6GkqJzOiP66HB3gjlLdP+QzgmziNqbRjJB7xKd2L1HWXkMjb9wgBOlkKyMV nhfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=7oHZ6+u/tCB1dOx28rFbuG1jiDRuDZT3oLUXt1+TtH4=; b=iAtpdkfHmhsy0BgjejGur5+9oyNtpIl4BiZ1UXFBWKvvxENbW/odRjxmCk5rxx4kuu TFHJz0mI7h/UU7CPQMic1jfzkASv7Ox4trtIqJQ6sCs0RjBURcy4aGd+5g1f0vk1qPZa JHG0FN74ZNUfUS+voReMclIX/0W2JDtJ0aKzpoC7SZQjscaPD7yWQ2OL1oQiRYsjlPIg Q7r0C8htTCD9JxwZKbcVxhrv2pbBqiZzem+S3GRAGpmBtOgSSycpUnT/56WGYRSiIZDx aeYB+XCxPYXQiMMO+TCJsm+3WoyMBWO0QkfoOBdeSOBAUVuC5B8oPgAHCt80vX0kfvdl k8uw== X-Gm-Message-State: AD7BkJLtu19YYEjuT+WKb8KXPVxiOmbQo34A/OgtkRqG2Pjdkq6r0PWdOQzqgR9983QwwXv4bl/FWONi/yJ9Ng== MIME-Version: 1.0 X-Received: by 10.13.192.5 with SMTP id b5mr12691657ywd.114.1457971805429; Mon, 14 Mar 2016 09:10:05 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 09:10:05 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> Date: Mon, 14 Mar 2016 09:10:05 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Bill Cox Content-Type: multipart/alternative; boundary=001a114e3f988ec47b052e04838d Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:10:09 -0000 --001a114e3f988ec47b052e04838d Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote: > As we all know, what matters most in security is the default mode. I am > suggesting making the default 0-RTT resumption mode stateful, with a > documented session-ID (and let's bring back the timestamp, too, since we'll > need it). > Having state would make things much more robust; but rather than the state being around the channel itself (the TLS session), would it be more robust, and more flexible, for the state to be around the action? like some kind of hint cookie. One of the problems with session resumption is that in order to be replay safe; the sequence number has to restart where it left off. That requires some kind of transactional store, and if you're doing all of this for latency, you may end up eating all of the wins there. Another way to go would be a token that represents an action, e.g.: 1. As part of a regular TLS session, post handshake, client sends a hint_request request layer message type. This can be URL, or any arbitrary data, and it's encrypted just as normal application_data is. 2. Server responds with a hint_response token; it's just an opaque token. 3. For future TLS connections; client is free to include the hint token data in the 0RTT handshake data. Some interesting advantages: 1. The hint is very distinct from from the application_data stream. 2. The server can choose to use the token ticket-style; encrypt the URL or whatever directly in the hint. 3. The server could also choose to use the token session-ID style; store it in a lookup table. 4. Either way; the server has explicit control over what may constitute a hint and it can be checked and locked down; before the client can transmit something that may turn out not to be safe. 5. A server could also defer returning the token until the end of the application session. Hints could be used as application layer resumption or continuation tokens. Some downsides: 1. Transactional safety is very difficult; idempotence at the application layer is a very difficult to achieve property and this doesn't solve that. 2. Similar to TLS tickets/ids: the user's on-the-wire forward secrecy is at the mercy of the server. 3. Hints could be used as super cookies for user-tracking. 4. Complicated request-response semantics post-handshake (similar to Heartbeats). 5. Doesn't seem worth the complexity to me. -- Colm --001a114e3f988ec47b052e04838d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <waywardge= ek@google.com> wrote:
As we all know, what matters = most in security is the default mode.=C2=A0 I am suggesting making the defa= ult 0-RTT resumption mode stateful, with a documented session-ID (and let&#= 39;s bring back the timestamp, too, since we'll need it).

Having state would make things m= uch more robust; but rather than the state being around the channel itself = (the TLS session), would it be more robust, and more flexible, for the stat= e to be around the action? like some kind of hint cookie.=C2=A0
<= br>
One of the problems with session resumption is that in order = to be replay safe; the sequence number has to restart where it left off. Th= at requires some kind of transactional store, and if you're doing all o= f this for latency, you may end up eating all of the wins there.=C2=A0

Another way to go would be a token that represents an = action, e.g.:

1. As part of a regular TLS session,= post handshake, client sends a hint_request request layer message type. Th= is can be URL, or any arbitrary data, and it's encrypted just as normal= application_data is.
2. Server responds with a hint_response tok= en; it's just an opaque token.=C2=A0
3. For future TLS connec= tions; client is free to include the hint token data in the 0RTT handshake = data.

Some interesting advantages:

1. The hint is very distinct from from the app= lication_data stream.=C2=A0
2. The server c= an choose to use the token ticket-style; encrypt the URL or whatever direct= ly in the hint.
3. The server could also ch= oose to use the token session-ID style; store it in a lookup table.=C2=A0
4. Either way; the server has explicit contr= ol over what may constitute a hint and it can be checked and locked down; b= efore the client can transmit something that may turn out not to be safe.= =C2=A0
5. A server could also defer returni= ng the token until the end of the application session. Hints could be used = as application layer resumption or continuation tokens.=C2=A0

Some downsides:

1. Transa= ctional safety is very difficult; idempotence at the application layer is a= very difficult to achieve property and this doesn't solve that.
<= div class=3D"gmail_extra">2. Similar to TLS tickets/ids: the user's on-= the-wire forward secrecy is at the mercy of the server.=C2=A0
3. Hints could be used as super cookies for user-trackin= g. =C2=A0
4. Complicated request-response s= emantics post-handshake (similar to Heartbeats).=C2=A0
5. Doesn't seem worth the complexity to me.=C2=A0

--
Colm
--001a114e3f988ec47b052e04838d-- From nobody Mon Mar 14 09:15:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD0AF12DAE3 for ; Mon, 14 Mar 2016 09:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dkx3KkfpxNQi for ; Mon, 14 Mar 2016 09:15:19 -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 389A112DA88 for ; Mon, 14 Mar 2016 09:15:18 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id d65so173561333ywb.0 for ; Mon, 14 Mar 2016 09:15:18 -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:date:message-id:subject:from:to :cc; bh=KelSatOdjkt8sHCnKZRMAi1il8geuDNcrVhaMCHC6fM=; b=bxuhhlfnt8Kvk2Pac1ZrycvgaUwYBYj3jMeGLf2/Ydtl9AziuDTZYZ42SfVWso3c41 7O1yKLayBvwCgqSnTQgxEBveGw9KwDnwcvF66mcTQX9/5EFiKj8Hv/b52VkuW9Wu7iYg e3H8iTvtI3apjC+vy6unD16vJ+0yR8kHDFXHfQOf3hvd6pl1/J4xhXdNWGksPFdXJjVn O//auuhBywaRbqBxicKLrVRgdwVlaWJ+JBf9NOPx9uqsmjSeNQhvlYIljblR+nGiCg5g WZyDsQ3OpoPla4wV3E0hd1RWgXdJKvDeVNUJMe32/5Cmzk3m8Bulr9VNgynIIXpJP0aW 8OJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KelSatOdjkt8sHCnKZRMAi1il8geuDNcrVhaMCHC6fM=; b=a8/Eir4LznUNxGXDygozI9hHR9QMCzPw6xkHoDPBHzGar22ucvPds/LlF5QAFDYhWg BiVvDdwZDnds2+REd+z5tDex8KQJ/CMoVWtrgKwNllPghD7PKymPZ6RikdIFRUBcb9Pu ih6AQPCd/uv0boiAzsD775cCSOxDpJzvgUdQjD5CPbTeNhSqQDwi1av2x6QZmhJiOXnq xLlebo0gejw1+AiZsLZOQs2TEVfORy1BbBwOQG/LQ0bMHN4erjEOE/NLacVLwjBTicBu gpk+ZoDaeMuYanEwmSOJaSLeXdPitnMbXXUXdVvjzzrCeGS2wwb5FqRHlyl0IR2CSwny WqDw== X-Gm-Message-State: AD7BkJJq+kWaaxHX+pppXw0M2FpfqK+crmG+l+FH9ZSqAj3HorO5zKQ2vtSvzPE+RCFkREAY5SnGclv4sTcjLA== MIME-Version: 1.0 X-Received: by 10.129.155.151 with SMTP id s145mr12155788ywg.24.1457972117298; Mon, 14 Mar 2016 09:15:17 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 09:15:17 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> Date: Mon, 14 Mar 2016 09:15:17 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0b8da82546de052e0496ad Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:15:21 -0000 --94eb2c0b8da82546de052e0496ad Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla wrote: > For 1. Raw data throughput could be improved by envelope encrypting the > early data; and transferring the envelope key only once the session has > been fully authenticated > 1. Client generates a random secret and uses it to derive encryption and mac keys. 2. Client encrypts its early data using this key. Sends more-or-less per 0-RTT in the existing draft. 3. Post-handshake; the client sends a new message - encrypting using the regular session key - which has the early data encryption and mac keys in it. 4. Server uses those keys to decrypt the early data; which it buffered. 5. Client and server both erase and forget the ephemeral early data keys. Useful if you want to upload a software update to Mars; maybe not to useful to others; it just helps you make the most of the TCP window. So it improves throughput, but not latency so much. Can you expand on this. Cryptographically, this is effectively how both the > DHE and PSK > modes work: you get a key in session N (which is authenticated) and you > use it > in session N+1. > Makes sense! -- Colm --94eb2c0b8da82546de052e0496ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
For 1. Raw data = throughput could be improved by envelope encrypting the early data; and tra= nsferring the envelope key only once the session has been fully authenticat= ed

1. Client generates a random s= ecret and uses it to derive encryption and mac keys.
2. Client en= crypts its early data using this key. Sends more-or-less per 0-RTT in the e= xisting draft.
3. Post-handshake; the client sends a new message = - encrypting using the regular session key - which has the early data encry= ption and mac keys in it.
4. Server uses those keys to decrypt th= e early data; which it buffered.
5. Client and server both erase = and forget the ephemeral early data keys.

Useful i= f you want to upload a software update to Mars; maybe not to useful to othe= rs; it just helps you make the most of the TCP window. So it improves throu= ghput, but not latency so much.=C2=A0

Can you expand on this. Cryptographically, this is effective= ly how both the DHE and PSK
modes work: you get a key in session = N (which is authenticated) and you use it
in session N+1.


Makes sens= e!

--
Co= lm
--94eb2c0b8da82546de052e0496ad-- From nobody Mon Mar 14 09:34:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C11D12D5D3 for ; Mon, 14 Mar 2016 09:34:54 -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=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 F1NsXxq-6Lo7 for ; Mon, 14 Mar 2016 09:34:51 -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 37C7912D536 for ; Mon, 14 Mar 2016 09:34:49 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h129so174428187ywb.1 for ; Mon, 14 Mar 2016 09:34:49 -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:date:message-id:subject:from:to :cc; bh=q1/RHe9zUubRcm28eJ3+BddW2qql74/5o50fpjEmKn8=; b=jMfxGJHshces5KsQRwV/IKoSxH+wvWCf0Wqt/dIWcs7ENcl/EdsqAQK6d4Qt6DAqrN s/rQ+cnxUT6x6UlMVW4SrfzxmeFD6hVOv93bFa6eLm8K3SkhKoWhwBL/Ns8P37cQgpBo xOMdXq0rIHSCRvr9gu8p62p3vyqcAThyaP+EgbQAf59xSNGHA74JxtEzYRzy20Ld7BmP yGRrGJ0onpMHn/5aHg3i/zO+IvE/yQQeseI2zdcaWSoNsBW7xEOJ0Y3Bpw4DE0VPT3qW Y0FEbLRl6+3ZuOpUICx37jqvWP/vQtQ5mulbhSMXQlPDvp/VgiK+ZKWwOJSzNzNAmhp0 JEYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=q1/RHe9zUubRcm28eJ3+BddW2qql74/5o50fpjEmKn8=; b=H2Qt6uv493w1Y7SrWgUJyZl58hMDesyPKitD0KFevzY1NnbPpBeRlJTmMFLSY7ThVH qfuIlckU+bdJf3TILuElX1gMp0Ps53h6z7jGEmE8xef/Wht6JFROTL30PJBHJjt+OjtJ mTiFjzjvicTMjcV9uNrwOmk7VDDxxTCx1Ilq4JFJRWxSP3zjR4BMo8BBuuEFPSeL9ThF f2U4skNZ4GPtn9SY7mlbiiVbxVyn+0CRisM1NuOrMv2+ur2qVs4A9Pqlr1fC836jWP+2 ilBg7Qh/fvHmIe8WBuhWPVM/So/lVF5X9GIxXpeIn1RWrfFma8ZFlTguhGjxPYm0XpBN zgrw== X-Gm-Message-State: AD7BkJIFpUBBK1J7QL7EejG3wPByJFwfeD8F/id5REJtIwQOEEAgHh2Vj9vjwjHkri1IcSm1vKodbb59ZZ/vJw== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr12730134ywd.100.1457973288459; Mon, 14 Mar 2016 09:34:48 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 09:34:48 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313182336.GA13172@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 14 Mar 2016 09:34:48 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Bill Cox Content-Type: multipart/alternative; boundary=001a114e7e78f398b7052e04db9b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:34:54 -0000 --001a114e7e78f398b7052e04db9b Content-Type: text/plain; charset=UTF-8 On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox wrote: > > IMO, 0-RTT is the most important new feature in TLS 1.3 ... Speed really > _is_ that important. > I just want to be super explicit on this. There is a trade off to be made here between fast and loose Vs security and safety. My take is that speed absolutely is not so important that forward-secrecy for user requests, or replay safety for applications should be compromised. Even better speed benefits can be had by using persistent connections, which incidentally are also a little more robust against traffic analysis. -- Colm --001a114e7e78f398b7052e04db9b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox <waywardgeek@google.co= m> wrote:
IMO, 0-RTT is the mo= st important new feature in TLS 1.3 ...=C2=A0 Speed really _is_ that import= ant.

I just want to= be super explicit on this. There is a trade off to be made here between fa= st and loose Vs security and safety. My take is that speed absolutely is no= t so important that forward-secrecy for user requests, or replay safety for= applications should be compromised.=C2=A0

Even be= tter speed benefits can be had by using persistent connections, which incid= entally are also a little more robust against traffic analysis.=C2=A0
=

--
Colm
--001a114e7e78f398b7052e04db9b-- From nobody Mon Mar 14 10:36:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD5012D675 for ; Mon, 14 Mar 2016 10:36:31 -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 e7CZl4qof57P for ; Mon, 14 Mar 2016 10:36:29 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D873E12D68E for ; Mon, 14 Mar 2016 10:36:29 -0700 (PDT) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 97358282F4E for ; Mon, 14 Mar 2016 17:36:28 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Viktor Dukhovni In-Reply-To: <56E54B85.4050204@cs.tcd.ie> Date: Mon, 14 Mar 2016 13:36:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> References: <56E54B85.4050204@cs.tcd.ie> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "tls@ietf.org" List-Id: "This is the mailing list 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 Mar 2016 17:36:31 -0000 > On Mar 13, 2016, at 7:14 AM, Stephen Farrell = wrote: >=20 > So, can people suggest ways in which we can figure out the impact > of replayable data across all the many uses of TLS? For idempotent (more strongly side-effect free) lookup protocols, 0-RTT = makes good sense. There is no need for replay protection in the absence of side-effects. Web browsers are not the only use-case for TLS. Similarly, in SMTP with STARTTLS the client's first data payload is a = repeat of an EHLO command that was already sent in the clear! So one might for = example send the client's EHLO as 0-RTT replayable data. Of course SMTP servers = that support 0-RTT data don't exist yet, but they may once 0-RTT becomes = widely available in SSL/TLS toolkits. --=20 Viktor. From nobody Mon Mar 14 11:04:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F4112D5DA for ; Mon, 14 Mar 2016 11:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSmmQcGpoDV9 for ; Mon, 14 Mar 2016 11:04:16 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9298512D6AB for ; Mon, 14 Mar 2016 11:04:16 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u2EHsGnj025198 for ; Mon, 14 Mar 2016 11:04:11 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=MYco65bClqU7QH3fFfzbkejCJdKjvW/p3OwRP7OnRtg=; b=O42a/P1c7CXkr0t2laVEGi6R4OU+xM3F5tXbkQ+gTVG3h7RyUkHQ61x/i72nRNG8P2Y3 u7Yxthy1p7BDktZ9sI3BerDCCPw8PbUTndrYl0hAYNDVf4R3GGkS/6YcAYAqRrL+98hi MOyggORxKoPe08Si08BVWUhN4f19YnPACaM= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 21mfne3pyx-6 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 14 Mar 2016 11:04:11 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 11:04:09 -0700 From: Subodh Iyengar To: "tls@ietf.org" Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmFajTdv10Pjk6fDp6jA/HnJp9ZqziA//+MDMk= Date: Mon, 14 Mar 2016 18:04:07 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie>, <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> In-Reply-To: <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_06:, , signatures=0 Archived-At: Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:04:18 -0000 I think the discussion about not understanding the implications of replayab= ility is not correct. We are already in the situation where client data is = replayable. For example if a mobile app encounters an HTTP error, it will p= robably retry the request throwing caution to the wind about replayability.= Many popular HTTP libraries already do this very actively. In this scenari= o, even TLS1.2 replayability gurantees fall apart. At Facebook, we have sev= eral popular mobile applications and have plenty of experience dealing with= retries. =0A= =0A= Like Kyle mentioned the thing that 0-RTT adds to this is infinite replayabi= lity. As mentioned in the other thread we have ways to reduce the impact of= infinite replayable data for TLS, making it reasonably replay safe. =0A= =0A= Discussions of replayability in the void is impossible. There is no way TLS= 1.3 is going to know all the use cases for replayability. That is an applic= ation layer decision. Thus we should have proposals at the application laye= r as well to express these properties to the transport layer, and we have o= ne proposal for this which we're going to submit soon to HTTP WG. For examp= le in the case of http, an application should express to the lower layers t= hat the request that it is sending out is retry safe and that it is taking = care of it. =0A= =0A= Developers are adults too. We can prevent them from shooting themselves in = the foot by providing secure OFF by default option, but completely removing= the option from them expressing these application properties to the underl= ying transport layer seems like treating them like children. I would hate t= o see 0-RTT removed from the spec. This is something we at Facebook are loo= king forward to using and want to use immediately in browsers once it is av= ailable.=0A= =0A= Subodh=0A= =0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Viktor Dukhovni [ietf-dane@du= khovni.org]=0A= Sent: Monday, March 14, 2016 10:36 AM=0A= To: tls@ietf.org=0A= Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data=0A= =0A= > On Mar 13, 2016, at 7:14 AM, Stephen Farrell = wrote:=0A= >=0A= > So, can people suggest ways in which we can figure out the impact=0A= > of replayable data across all the many uses of TLS?=0A= =0A= For idempotent (more strongly side-effect free) lookup protocols, 0-RTT mak= es=0A= good sense. There is no need for replay protection in the absence of=0A= side-effects. Web browsers are not the only use-case for TLS.=0A= =0A= Similarly, in SMTP with STARTTLS the client's first data payload is a repea= t=0A= of an EHLO command that was already sent in the clear! So one might for ex= ample=0A= send the client's EHLO as 0-RTT replayable data. Of course SMTP servers th= at=0A= support 0-RTT data don't exist yet, but they may once 0-RTT becomes widely= =0A= available in SSL/TLS toolkits.=0A= =0A= --=0A= Viktor.=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DWfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=3DqKrC1QXmZHVEq84oPhj= uABuCzx4hwadP6c9TuTlMJx8&e=3D=0A= From nobody Mon Mar 14 11:19:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9383D12D553 for ; Mon, 14 Mar 2016 11:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 K2jUYZUOM8ne for ; Mon, 14 Mar 2016 11:19:05 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2057A12D58A for ; Mon, 14 Mar 2016 11:19:05 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c3so219565959vkb.3 for ; Mon, 14 Mar 2016 11:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=BWSR/axRsxt2a21/cjj7AmYH01399yv6XiFPp6aISJs=; b=NoeeLeAvkfd8hKJ67TPHijObwdV6VvmaGYtd5svmCBnKkyxJfI1cQgVwy8jGPjAb5C 300HxVj9WxjkgioaibtEA3+o2+pOy+kvXFwXKijAHKSMd2J79ui1oUfKnJpfEl381lRl 4pu/lpuGIiqLfuA4lAMfVyn4JmkkXyFxukdN41H/IMXVlayu5unsZiqFLuGIJmef8D2x F8+ouP3GkaZHMA5LQSfqwRj/EcqX6QYwdwWi5uoYOLPF1wc9qrO88JaCuOCtfKfQhYkF SY0HEF8/HwzqAnQTZa1sWqNBbVeMAfPXmLCfTcC+gisZCKfdRhRecvxn6NNNc2wPdXrg GGsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BWSR/axRsxt2a21/cjj7AmYH01399yv6XiFPp6aISJs=; b=gCFeLBrmXSOvAw2dXjlkkQNYpdJGHFb/CxTkzVwoMMosg1gQxr5PtWcYMf19dpD36i pHyXhmyuTUo768wFFPNlKsEYY4QkSIhiBsFcjHbEfdD1qLJdqnveNDoBKZL2Lfjfywgq 3PBa++wRKp7tQDfTAQ11hOX2U4TvXxZB0TcKmNillYLtGgkyeSK7FJFXFc+Cd9tD5Tx+ puDot/8z6qSoor+LuHrjJlMmrmYpd5xxhFaXF8AznIjn3jXjJzwV9SNveCaSiYj6ZI2B 1CkIDRoQFzlBoIO9EaOwFkdRUX1Q4BtD/D6Z9O3ZEZIoWDFOAAL8bdu5Huhu413QQMA5 Y3og== X-Gm-Message-State: AD7BkJLLldmq4za52WkRlzwBPYeeu3h1Bb8Q4+Q3Pe5twvTJg8Vcl1xHJAu8MKAsIzsbTh2Fu2QinFXGFIYVww== MIME-Version: 1.0 X-Received: by 10.31.10.199 with SMTP id 190mr27097824vkk.51.1457979544052; Mon, 14 Mar 2016 11:19:04 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Mon, 14 Mar 2016 11:19:03 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Mon, 14 Mar 2016 11:19:03 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> Date: Mon, 14 Mar 2016 11:19:03 -0700 Message-ID: From: Watson Ladd To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a11440176d029ca052e065044 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:19:07 -0000 --001a11440176d029ca052e065044 Content-Type: text/plain; charset=UTF-8 On Mar 14, 2016 11:04 AM, "Subodh Iyengar" wrote: > > I think the discussion about not understanding the implications of replayability is not correct. We are already in the situation where client data is replayable. For example if a mobile app encounters an HTTP error, it will probably retry the request throwing caution to the wind about replayability. Many popular HTTP libraries already do this very actively. In this scenario, even TLS1.2 replayability gurantees fall apart. At Facebook, we have several popular mobile applications and have plenty of experience dealing with retries. Do they in fact fall apart? Or do libraries providing HTTP services carefully document their replay and reordering protections, and application developers carefully consider how to deal with replays? Many websites still say do not hit refresh or you will be charged twice. 0RTT enables reordering replay data with interesting effects, and so is distinct from doing background updates while changing the UI immediately in that requests can happen again adversarially. > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite replayability. As mentioned in the other thread we have ways to reduce the impact of infinite replayable data for TLS, making it reasonably replay safe. > > Discussions of replayability in the void is impossible. There is no way TLS1.3 is going to know all the use cases for replayability. That is an application layer decision. Thus we should have proposals at the application layer as well to express these properties to the transport layer, and we have one proposal for this which we're going to submit soon to HTTP WG. For example in the case of http, an application should express to the lower layers that the request that it is sending out is retry safe and that it is taking care of it. > > Developers are adults too. We can prevent them from shooting themselves in the foot by providing secure OFF by default option, but completely removing the option from them expressing these application properties to the underlying transport layer seems like treating them like children. I would hate to see 0-RTT removed from the spec. This is something we at Facebook are looking forward to using and want to use immediately in browsers once it is available. Is the "application" HTTP or a website? Many websites got bitten by nginx changing how it treated certain retries due to ordering interactions. The canonical example is a DELETE and a POST. > > Subodh > > ________________________________________ > From: TLS [tls-bounces@ietf.org] on behalf of Viktor Dukhovni [ ietf-dane@dukhovni.org] > Sent: Monday, March 14, 2016 10:36 AM > To: tls@ietf.org > Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data > > > On Mar 13, 2016, at 7:14 AM, Stephen Farrell wrote: > > > > So, can people suggest ways in which we can figure out the impact > > of replayable data across all the many uses of TLS? > > For idempotent (more strongly side-effect free) lookup protocols, 0-RTT makes > good sense. There is no need for replay protection in the absence of > side-effects. Web browsers are not the only use-case for TLS. > > Similarly, in SMTP with STARTTLS the client's first data payload is a repeat > of an EHLO command that was already sent in the clear! So one might for example > send the client's EHLO as 0-RTT replayable data. Of course SMTP servers that > support 0-RTT data don't exist yet, but they may once 0-RTT becomes widely > available in SSL/TLS toolkits. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=WfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=qKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8&e= > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a11440176d029ca052e065044 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 14, 2016 11:04 AM, "Subodh Iyengar" <subodh@fb.com> wrote:
>
> I think the discussion about not understanding the implications of rep= layability is not correct. We are already in the situation where client dat= a is replayable. For example if a mobile app encounters an HTTP error, it w= ill probably retry the request throwing caution to the wind about replayabi= lity. Many popular HTTP libraries already do this very actively. In this sc= enario, even TLS1.2 replayability gurantees fall apart. At Facebook, we hav= e several popular mobile applications and have plenty of experience dealing= with retries.

Do they in fact fall apart? Or do libraries providing HTTP s= ervices carefully document their replay and reordering protections, and app= lication developers carefully consider how to deal with replays?

Many websites still say do not hit refresh or you will be ch= arged twice. 0RTT enables reordering replay data with interesting effects, = and so is distinct from doing background updates while changing the UI imme= diately in that requests can happen again adversarially.
>
> Like Kyle mentioned the thing that 0-RTT adds to this is infinite repl= ayability. As mentioned in the other thread we have ways to reduce the impa= ct of infinite replayable data for TLS, making it reasonably replay safe. >
> Discussions of replayability in the void is impossible. There is no wa= y TLS1.3 is going to know all the use cases for replayability. That is an a= pplication layer decision. Thus we should have proposals at the application= layer as well to express these properties to the transport layer, and we h= ave one proposal for this which we're going to submit soon to HTTP WG. = For example in the case of http, an application should express to the lower= layers that the request that it is sending out is retry safe and that it i= s taking care of it.
>
> Developers are adults too. We can prevent them from shooting themselve= s in the foot by providing secure OFF by default option, but completely rem= oving the option from them expressing these application properties to the u= nderlying transport layer seems like treating them like children. I would h= ate to see 0-RTT removed from the spec. This is something we at Facebook ar= e looking forward to using and want to use immediately in browsers once it = is available.

Is the "application" HTTP or a website? Many websi= tes got bitten by nginx changing how it treated certain retries due to orde= ring interactions. The canonical example is a DELETE and a POST.
>
> Subodh
>
> ________________________________________
> From: TLS [tls-bounces@ietf.or= g] on behalf of Viktor Dukhovni [ietf-dane@dukhovni.org]
> Sent: Monday, March 14, 2016 10:36 AM
> To: tls@ietf.org
> Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data >
> > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> >
> > So, can people suggest ways in which we can figure out the impact=
> > of replayable data across all the many uses of TLS?
>
> For idempotent (more strongly side-effect free) lookup protocols, 0-RT= T makes
> good sense.=C2=A0 There is no need for replay protection in the absenc= e of
> side-effects.=C2=A0 Web browsers are not the only use-case for TLS. >
> Similarly, in SMTP with STARTTLS the client's first data payload i= s a repeat
> of an EHLO command that was already sent in the clear!=C2=A0 So one mi= ght for example
> send the client's EHLO as 0-RTT replayable data.=C2=A0 Of course S= MTP servers that
> support 0-RTT data don't exist yet, but they may once 0-RTT become= s widely
> available in SSL/TLS toolkits.
>
> --
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_lis= tinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mH= twg-wAyN7fQ&m=3DWfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=3DqKr= C1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8&e=3D
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a11440176d029ca052e065044-- From nobody Mon Mar 14 11:28:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5FE812D5DE for ; Mon, 14 Mar 2016 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, 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=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsFDSn2CTkUl for ; Mon, 14 Mar 2016 11:28:16 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60F912D6C4 for ; Mon, 14 Mar 2016 11:28:16 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2EIOs5H028495; Mon, 14 Mar 2016 11:28:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=RIX7nzFd9rKtimMP2kMj/t/OmoXuVAQVZthQBhPFb6s=; b=B+Do7rpMf34WOeM7GguwlYuQ8BEoPhXc6JTKKgwj9gdXPl1wOybBSNQ8upyJ/So41cYX SHLIpaZHglEvu0xHTczGTCe53vPgf4OlhZz1IHKONZleV1TwpuaxOMRFrfydd8TZ6MHh Dr947sc1Jl9JIc9glM4K9UfjR2mvvPyT5e8= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 21mftasy3x-6 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 11:28:09 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB06.TheFacebook.com ([fe80::f073:2a60:c133:4d69%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 11:27:25 -0700 From: Subodh Iyengar To: Watson Ladd Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmFajTdv10Pjk6fDp6jA/HnJp9ZqziA//+MDMmAAH/bgP//iyO/ Date: Mon, 14 Mar 2016 18:27:24 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564F44DC@PRN-MBX01-4.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99564F44DCPRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_06:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:28:23 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99564F44DCPRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Is the "application" HTTP or a website? Many websites got bitten by nginx= changing how it treated certain retries due to ordering interactions. The = canonical example is a DELETE and a POST. By application here I mean website html / JS which creates the http request= and triggers the agent (browser) into making an http request or in the cas= e of a mobile app the application code that calls the http library. Currently the only way to express retry behavior in HTTP is by the method (= i.e. whether it is idempotent or not), which as you pointed out may have un= fortunate side effects, since it is not explicit. The proposal (at least on= e of them) is to add an explicit way to express retry safety in HTTP as an = additional request property similar to method. This can be used by the agen= t (browser or http library) to decide whether or not to use 0-RTT for the h= ttp data. I'll link to it in this thread once it's posted. Subodh ________________________________ From: Watson Ladd [watsonbladd@gmail.com] Sent: Monday, March 14, 2016 11:19 AM To: Subodh Iyengar Cc: tls@ietf.org Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data On Mar 14, 2016 11:04 AM, "Subodh Iyengar" > wrote: > > I think the discussion about not understanding the implications of replay= ability is not correct. We are already in the situation where client data i= s replayable. For example if a mobile app encounters an HTTP error, it will= probably retry the request throwing caution to the wind about replayabilit= y. Many popular HTTP libraries already do this very actively. In this scena= rio, even TLS1.2 replayability gurantees fall apart. At Facebook, we have s= everal popular mobile applications and have plenty of experience dealing wi= th retries. Do they in fact fall apart? Or do libraries providing HTTP services careful= ly document their replay and reordering protections, and application develo= pers carefully consider how to deal with replays? Many websites still say do not hit refresh or you will be charged twice. 0R= TT enables reordering replay data with interesting effects, and so is disti= nct from doing background updates while changing the UI immediately in that= requests can happen again adversarially. > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite replaya= bility. As mentioned in the other thread we have ways to reduce the impact = of infinite replayable data for TLS, making it reasonably replay safe. > > Discussions of replayability in the void is impossible. There is no way T= LS1.3 is going to know all the use cases for replayability. That is an appl= ication layer decision. Thus we should have proposals at the application la= yer as well to express these properties to the transport layer, and we have= one proposal for this which we're going to submit soon to HTTP WG. For exa= mple in the case of http, an application should express to the lower layers= that the request that it is sending out is retry safe and that it is takin= g care of it. > > Developers are adults too. We can prevent them from shooting themselves i= n the foot by providing secure OFF by default option, but completely removi= ng the option from them expressing these application properties to the unde= rlying transport layer seems like treating them like children. I would hate= to see 0-RTT removed from the spec. This is something we at Facebook are l= ooking forward to using and want to use immediately in browsers once it is = available. Is the "application" HTTP or a website? Many websites got bitten by nginx c= hanging how it treated certain retries due to ordering interactions. The ca= nonical example is a DELETE and a POST. > > Subodh > > ________________________________________ > From: TLS [tls-bounces@ietf.org] on behalf o= f Viktor Dukhovni [ietf-dane@dukhovni.org] > Sent: Monday, March 14, 2016 10:36 AM > To: tls@ietf.org > Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data > > > On Mar 13, 2016, at 7:14 AM, Stephen Farrell > wrote: > > > > So, can people suggest ways in which we can figure out the impact > > of replayable data across all the many uses of TLS? > > For idempotent (more strongly side-effect free) lookup protocols, 0-RTT m= akes > good sense. There is no need for replay protection in the absence of > side-effects. Web browsers are not the only use-case for TLS. > > Similarly, in SMTP with STARTTLS the client's first data payload is a rep= eat > of an EHLO command that was already sent in the clear! So one might for = example > send the client's EHLO as 0-RTT replayable data. Of course SMTP servers = that > support 0-RTT data don't exist yet, but they may once 0-RTT becomes widel= y > available in SSL/TLS toolkits. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wA= yN7fQ&m=3DWfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s=3DqKrC1QXmZHVEq84oP= hjuABuCzx4hwadP6c9TuTlMJx8&e=3D > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --_000_974CF78E8475CD4CA398B1FCA21C8E99564F44DCPRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
> = Is the "application" HTTP or a website? Many websites got bitten = by nginx changing how it treated certain retries due to ordering interactio= ns. The canonical example is a DELETE and a POST.

By application here I mean website html / JS which creates the http request= and triggers the agent (browser) into making an http request or in the cas= e of a mobile app the application code that calls the http library.

Currently the only way to express retry behavior in HTTP is by the method (= i.e. whether it is idempotent or not), which as you pointed out may have un= fortunate side effects, since it is not explicit. The proposal (at least on= e of them) is to add an explicit way to express retry safety in HTTP as an additional request property simi= lar to method. This can be used by the agent (browser or http library) to d= ecide whether or not to use 0-RTT for the http data. I'll link to it in thi= s thread once it's posted.

Subodh
 
From: Watson Ladd [watsonbladd@gmail.com]=
Sent: Monday, March 14, 2016 11:19 AM
To: Subodh Iyengar
Cc: tls@ietf.org
Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data=


On Mar 14, 2016 11:04 AM, "Subodh Iyengar" <subodh@fb.com> wrote:
>
> I think the discussion about not understanding the implications of rep= layability is not correct. We are already in the situation where client dat= a is replayable. For example if a mobile app encounters an HTTP error, it w= ill probably retry the request throwing caution to the wind about replayability. Many popular HTTP libraries alrea= dy do this very actively. In this scenario, even TLS1.2 replayability guran= tees fall apart. At Facebook, we have several popular mobile applications a= nd have plenty of experience dealing with retries.

Do they in fact fall apart? Or do libraries providing HTTP s= ervices carefully document their replay and reordering protections, and app= lication developers carefully consider how to deal with replays?

Many websites still say do not hit refresh or you will be ch= arged twice. 0RTT enables reordering replay data with interesting effects, = and so is distinct from doing background updates while changing the UI imme= diately in that requests can happen again adversarially.
>
> Like Kyle mentioned the thing that 0-RTT adds to this is infinite repl= ayability. As mentioned in the other thread we have ways to reduce the impa= ct of infinite replayable data for TLS, making it reasonably replay safe. >
> Discussions of replayability in the void is impossible. There is no wa= y TLS1.3 is going to know all the use cases for replayability. That is an a= pplication layer decision. Thus we should have proposals at the application= layer as well to express these properties to the transport layer, and we have one proposal for this which we're goin= g to submit soon to HTTP WG. For example in the case of http, an applicatio= n should express to the lower layers that the request that it is sending ou= t is retry safe and that it is taking care of it.
>
> Developers are adults too. We can prevent them from shooting themselve= s in the foot by providing secure OFF by default option, but completely rem= oving the option from them expressing these application properties to the u= nderlying transport layer seems like treating them like children. I would hate to see 0-RTT removed from the sp= ec. This is something we at Facebook are looking forward to using and want = to use immediately in browsers once it is available.

Is the "application" HTTP or a website? Many websi= tes got bitten by nginx changing how it treated certain retries due to orde= ring interactions. The canonical example is a DELETE and a POST.
>
> Subodh
>
> ________________________________________
> From: TLS [t= ls-bounces@ietf.org] on behalf of Viktor Dukhovni [ietf-dane@dukhovni.org]
> Sent: Monday, March 14, 2016 10:36 AM
> To: tls@ietf.org=
> Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data >
> > On Mar 13, 2016, at 7:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
> >
> > So, can people suggest ways in which we can figure out the impact=
> > of replayable data across all the many uses of TLS?
>
> For idempotent (more strongly side-effect free) lookup protocols, 0-RT= T makes
> good sense.  There is no need for replay protection in the absenc= e of
> side-effects.  Web browsers are not the only use-case for TLS. >
> Similarly, in SMTP with STARTTLS the client's first data payload is a = repeat
> of an EHLO command that was already sent in the clear!  So one mi= ght for example
> send the client's EHLO as 0-RTT replayable data.  Of course SMTP = servers that
> support 0-RTT data don't exist yet, but they may once 0-RTT becomes wi= dely
> available in SSL/TLS toolkits.
>
> --
>         Viktor.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EB= S7mHtwg-wAyN7fQ&m=3DWfBqzUVkz2aHPj_ZubNS486Z0f_mB52duCvuRK1GtSQ&s= =3DqKrC1QXmZHVEq84oPhjuABuCzx4hwadP6c9TuTlMJx8&e=3D
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--_000_974CF78E8475CD4CA398B1FCA21C8E99564F44DCPRNMBX014TheFac_-- From nobody Mon Mar 14 11:29:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633FD12D6D8 for ; Mon, 14 Mar 2016 11:29:22 -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=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 Xk2axOXqvlxR for ; Mon, 14 Mar 2016 11:29:20 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D8F812D698 for ; Mon, 14 Mar 2016 11:29:20 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id d65so178733061ywb.0 for ; Mon, 14 Mar 2016 11:29:20 -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:date:message-id:subject:from:to :cc; bh=U79XPV/5QeHAnR8PG/+lRz/7iZEVSYirQ6POL6eKUxI=; b=gMh4G9Fb5fdJ6Xzv5Uje0ZG0fJ5C/JwgmvJJSC6D2b2BZVXfCCtupYYxm0Xqy/Vyby q2Qgr7ECv4c8oJG9cXWPyk+1Zw5XWJtCuLpk0vRRwRuJ5EemfUFnMXEqTVQZjU3vvcRd accB9vBT/R+31VcBBC22u6xIYspaC9vZDjRJtM+651J/tlA6smKl/vxMTxSWb6ow/mBh KKTFcLcyrnb2nKftooLBN9rpxp4OBGsqvZBlKLMN/8Ff5RG7dpIIsCS35brJETie5jou ucLp7HukPN1VFMPf3fDQW0U21BCLrzBc5fR6XRlA2l1YN2g5Bhg5774CjnDK1FxgF+kF cJJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=U79XPV/5QeHAnR8PG/+lRz/7iZEVSYirQ6POL6eKUxI=; b=KWmdeGkkUGudYllWcaofbyGcsfO3iaBhB28rJ0etQ1cTgWOdmVT7S5wiOGMtLVrQdE U+JMfu+s5Ds9Kce4deHI0HWaU3O8zQWnCM6Qjjh9Rrj9WtCG+qx7TqYWcrT5VrZpjPXy Rz0CSz9P1n8nVn5yg9sk09gJf4kEq8UeRbRChyWFuR5g2Sxw8wUK7EyvF1eyf1HckTQ3 DL4YXTT+crr/gk6oASNqtnjZJoo38DEeh4luAiJ1hY5RjRJAMBmVLCTr+qc5gBjNfduw F3O4+tpAnPylDzoctUNXaEsGNNWQvCwTFgKFNJxGEeKrSf67WEXIb4JY8U0jiWzfvXu6 ueZw== X-Gm-Message-State: AD7BkJImgpPGj1myl8oaht5NEbYEtn2SeJmwl1l3skXKfPzIvDNZOgFro1mJTns+XgQ4JGzQK0qa61+iV5R52A== MIME-Version: 1.0 X-Received: by 10.13.214.1 with SMTP id y1mr12826070ywd.307.1457980159456; Mon, 14 Mar 2016 11:29:19 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 11:29:19 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> Date: Mon, 14 Mar 2016 11:29:19 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Subodh Iyengar Content-Type: multipart/alternative; boundary=94eb2c0770e47eaff3052e0675be Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:29:22 -0000 --94eb2c0770e47eaff3052e0675be Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar wrote: > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite > replayability. As mentioned in the other thread we have ways to reduce the > impact of infinite replayable data for TLS, making it reasonably replay > safe. > That too is a mis-understanding. The deeper problem is that a third party can do the replay, and that forward secrecy is gone for what likely is sensitive data. Neither is the case with ordinary retries. -- Colm --94eb2c0770e47eaff3052e0675be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar <= subodh@fb.com> wrote:
Like Kyle mentioned the thing that 0-RTT adds to this is infinite replayabi= lity. As mentioned in the other thread we have ways to reduce the impact of= infinite replayable data for TLS, making it reasonably replay safe.

That too is a mis-understanding. The deeper p= roblem is that a third party can do the replay, and that forward secrecy is= gone for what likely is sensitive data. Neither is the case with ordinary = retries.=C2=A0

--
Colm
--94eb2c0770e47eaff3052e0675be-- From nobody Mon Mar 14 11:38:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7FA12DC67 for ; Mon, 14 Mar 2016 11:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le5LsEbqDL2g for ; Mon, 14 Mar 2016 11:38:30 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 6AC9612DB71 for ; Mon, 14 Mar 2016 11:38:28 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id ig19so68808755igb.1 for ; Mon, 14 Mar 2016 11:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KwAf6jvh0oM8f1b8UAEHfB5dPKmjWWDmwNAeetKJ+nY=; b=B0cO5SleAN3wrYnNbJiEAe4uq13zrwd9ivZCiadnWfzdMAXe98F8/PrXaTG5uXK2eI xZFX1nYXRj8zk6S8KfHu3DlLP4OaDSCHKiIqQnY8otg3KwOyTPwO5CpmuBHV8DotKU8j 8YYs4kimBFfYbCzQW85X/z52wiLh7ayZwUAtKsVVPOBY0eFU8Ov6T0YlaF9Y3CDAhQIZ qJcesjFz3zXp+b1ZQSnDTz5BefX4Uk8uJqt3AaoWjqD5u8Zn0u4ahVcSpdzORge3Bv1l 20PFSxuuViWxLxZ6pq54Jz47Ju0uZWQM5iPfU4CzU7CymtvSnm2a7DKX2/4XKgI0kSr4 SSUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KwAf6jvh0oM8f1b8UAEHfB5dPKmjWWDmwNAeetKJ+nY=; b=CtyjKZ3WG65wuZRgxdh9JhTSGoLW6dzi7TKN98mbpwHQR4DyHeEeObdqhb2s2MrMe8 qAYIKJfejKPfOwZP1NAR/9rbyXtRKpPQmG5sVLGNNERCWyfwmPJH1yUJ3xM+ItzfusFq efSNV7dD0Ys1NV9YG99B2ELGb2+cW+2ptqf9m6crvqBy5JsnL2kE7gQsVCcb8a5Etpz3 eKrARdkrGRd0IpDJOQYHUFQK/F16lWsLor8juGRI3XlnoHdpG3wN3Jw7UnFi9SrtM+0N tmhPe/SLp7RuzKRqWq0usCCezLzhkBa17dY7Gs46uiWb4SHePnIhmzlha7z4vowaP21m eh/w== X-Gm-Message-State: AD7BkJJedFdWWmvEmF0RTsvHspCTJNXOvPbCPGfSNsMNcQ7Nt/+oQ1S9ciYSoUYfTrsF0ksbOAQk0NUews1zdSQ7 MIME-Version: 1.0 X-Received: by 10.50.70.39 with SMTP id j7mr19128375igu.40.1457980707487; Mon, 14 Mar 2016 11:38:27 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 11:38:27 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> Date: Mon, 14 Mar 2016 11:38:27 -0700 Message-ID: From: Bill Cox To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=047d7b3a93c629610d052e0696ef Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:38:32 -0000 --047d7b3a93c629610d052e0696ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh wrote: > On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote: > >> As we all know, what matters most in security is the default mode. I am >> suggesting making the default 0-RTT resumption mode stateful, with a >> documented session-ID (and let's bring back the timestamp, too, since we= 'll >> need it). >> > > Having state would make things much more robust; but rather than the stat= e > being around the channel itself (the TLS session), would it be more robus= t, > and more flexible, for the state to be around the action? like some kind = of > hint cookie. > It looks like server-side state is required to prevent replay. I don't think any kind of token, cookie, or server-config can fix this. > One of the problems with session resumption is that in order to be replay > safe; the sequence number has to restart where it left off. That requires > some kind of transactional store, and if you're doing all of this for > latency, you may end up eating all of the wins there. > The new tickets can in theory end the debate over session caching vs session tickets, since they can be used for database lookups or contain an encrypted session state. However, the spec does not document how to do session caching with tickets securely, which looks tricky. In reality, if I were trying to build a speed and security sensitive site using TLS 1.3 stateful 0-RTT resumption, I would probably do something like this: During the initial 1-RTT handshake: - create a ticket containing only the session ID, resumption count, and a session decryption key - encrypt the session cache entry with the session encryption key stored in the ticket - encrypt the ticket with a semi-static ticket encryption key, which I would rotate every few weeks - send the ticket to the client, which is after encryption is enabled on the connection During a 0-RTT resume handshake: - check for a cache hit, and drop to 1-RTT if not found - decrypt the ticket with ticket the semi-static ticket decryption key - decrypt the cached session state with the session key from the ticket - compare the resumption counts in the session state and ticket, and fall back to 1-RTT if they do not match - increment the resumption count - create a new session ticket with a new session encryption key and the updated resumption count - encrypt the session cache entry with the new session encryption key - send the client the new ticket I assume that it is legal to send a new ticket on a 0-RTT PSK resume, but it is not clear to me from the drawings in the spec. It is not shown as an option. This is required for secure stateful 0-RTT resumption. I think this scheme minimizes data sent over the wire (to reduce latency) and provides improved PFS vs using a non-encrypted session cache. Since tickets are sent after encryption has been enabled, leaking the semi-static ticket encryption key does not enable an eavesdropper to decrypt past sessions, as was the case in TLS 1.2. If the server is compromised, this scheme protects the session cache from being decrypted, so PFS is preserved, unlike the case with either TLS 1.2 session caches with no encryption or TLS 1.2 tickets with semi-static ticket keys. Leaking either the session cache or ticket encryption key would allow prior TLS 1.2 sessions to be decypted. Bill --047d7b3a93c629610d052e0696ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:
On= Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <waywardgeek@google.com&g= t; wrote:
As we all know, what matters most in s= ecurity is the default mode.=C2=A0 I am suggesting making the default 0-RTT= resumption mode stateful, with a documented session-ID (and let's brin= g back the timestamp, too, since we'll need it).

Having state would make things muc= h more robust; but rather than the state being around the channel itself (t= he TLS session), would it be more robust, and more flexible, for the state = to be around the action? like some kind of hint cookie.=C2=A0

It looks like server-side state = is required to prevent replay.=C2=A0 I don't think any kind of token, c= ookie, or server-config can fix this.
=C2=A0
One of the problems with session resumption is that in order to be repla= y safe; the sequence number has to restart where it left off. That requires= some kind of transactional store, and if you're doing all of this for = latency, you may end up eating all of the wins there.

The new tickets can in theory end the de= bate over session caching vs session tickets, since they can be used for da= tabase lookups or contain an encrypted session state.=C2=A0 However, the sp= ec does not document how to do session caching with tickets securely, which= looks tricky.=C2=A0 In reality, if I were trying to build a speed and secu= rity sensitive site using TLS 1.3 stateful 0-RTT resumption, I would probab= ly do something like this:

During the initial 1-RT= T handshake:
- create a ticket containing only the session ID, re= sumption count, and a session decryption key
- encrypt the sessio= n cache entry with the session encryption key stored in the ticket
- encrypt the ticket with a semi-static ticket encryption key, which = I would rotate every few weeks
- send the ticket to the client, w= hich is after encryption is enabled on the connection

<= div>During a 0-RTT resume handshake:
- check for a cache hit, and= drop to 1-RTT if not found
- decrypt the ticket with ticket the = semi-static ticket decryption key
- decrypt the cached sessio= n state with the session key from the ticket
- compare the re= sumption counts in the session state and ticket, and fall back to 1-RTT if = they do not match
- increment the resumption count
- cr= eate a new session ticket with a new session encryption key and the updated= resumption count
- encrypt the session cache entry with the new = session encryption key
- send the client the new ticket
=

I assume that it is legal to send a new ticket on a 0-R= TT PSK resume, but it is not clear to me from the drawings in the spec.=C2= =A0 It is not shown as an option.=C2=A0 This is required for secure statefu= l 0-RTT resumption.

I think this scheme minimizes = data sent over the wire (to reduce latency) and provides improved PFS vs us= ing a non-encrypted session cache.=C2=A0 Since tickets are sent after encry= ption has been enabled, leaking the semi-static ticket encryption key does = not enable an eavesdropper to decrypt past sessions, as was the case in TLS= 1.2.=C2=A0 If the server is compromised, this scheme protects the session = cache from being decrypted, so PFS is preserved, unlike the case with eithe= r TLS 1.2 session caches with no encryption or TLS 1.2 tickets with semi-st= atic ticket keys.=C2=A0 Leaking either the session cache or ticket encrypti= on key would allow prior TLS 1.2 sessions to be decypted.

Bill
--047d7b3a93c629610d052e0696ef-- From nobody Mon Mar 14 11:40:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CC512D71E for ; Mon, 14 Mar 2016 11:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RTSC6HeUBP1o for ; Mon, 14 Mar 2016 11:40:53 -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 721E412D6C9 for ; Mon, 14 Mar 2016 11:40:53 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g3so179097168ywa.3 for ; Mon, 14 Mar 2016 11:40:53 -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:date:message-id:subject:from:to :cc; bh=43j3Bz5FdnF2P9o++HMduYiwbgkbxGGYHk8ORMyK3UM=; b=m57ia8iKSqQ0B1xl4xptR3rpUEwMQge9NukjTGUmz1HD/VlGXpcRGBKnmcQRN0sB73 /uW5QfZ8l3dKlI86t8QvDdrCa21AhvF9/s93oxupnvbNSUTYomEnRb3ufrnIjKNWnwJE wcj9d5v4V452d0t3Eoq7kOUrmbM3fAHKlZFG2KHtYSV4s09xy3rRKjPQ3aNWStuucyTS 8+IbkjAvoUMNxrNmJYBdSQIDmCNWCMY7+yjKKiH+VUjMxGr07Mfd4oXyeeLc875qH6W3 Uj+swKN7BtruQZEF2na0JWK1bv4OsA3NPIvgJJ3bPbgoIQDZeKEinWDZmcMh9Ty2aYW4 keSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=43j3Bz5FdnF2P9o++HMduYiwbgkbxGGYHk8ORMyK3UM=; b=e1NfLP72osTbI0mnPfopNvzOA84SoED8FvOWDE+vi6cXpfa6jjc24WVCrwt9wCc+O0 et4T8qwvEyjlWNBKqzwot01+jsweHk/AAPckasiU8QZ8fzngu7BWUOmLLf7Ud3LnQeRS eOt5Md/tb8HiZ77x5KlGKygVrmhVQkFCZRJqOPo4uE87OO5dwI0msIJyX1MFHboxKKag 3duvfVEZ0Wa3MUi9FTos5LHQENqMiMYuKZGknlOp9/N7yGbyyZzS3Y6X7OnwTwIP5lqR BX8xFdUghnxFMGviQ1KL7xl2RoJFF5Bn873b61GdzG9dpKCsqMslnseejyJvNXlDB/sR ClXQ== X-Gm-Message-State: AD7BkJKymrzjs8JBhPh6aMF8nswZp8nbgYKX0l6H/A4Mt5aDV3e0xN+pFmoAkk8GVUsvcUHh1OI8QCQiQe5l4A== MIME-Version: 1.0 X-Received: by 10.37.78.193 with SMTP id c184mr13525840ybb.155.1457980852697; Mon, 14 Mar 2016 11:40:52 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 11:40:52 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99564F44DC@PRN-MBX01-4.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99564F44DC@PRN-MBX01-4.TheFacebook.com> Date: Mon, 14 Mar 2016 11:40:52 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a11467ba6d0bec6052e069e64 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:40:55 -0000 --001a11467ba6d0bec6052e069e64 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 11:27 AM, Subodh Iyengar wrote: > Currently the only way to express retry behavior in HTTP is by the method > (i.e. whether it is idempotent or not), which as you pointed out may have > unfortunate side effects, since it is not explicit. The proposal (at least > one of them) is to add an explicit way to express retry safety in HTTP as > an additional request property similar to method. This can be used by the > agent (browser or http library) to decide whether or not to use 0-RTT for > the http data. I'll link to it in this thread once it's posted. > Just on this; if you want to be sure of idempotency on the server side; the best answer to is might be to intentionally send the data 2+ times at the protocol level. If the action really is idempotent, then the repeat will be safe. Doing so as a matter of course builds up anti-bodies against any nascent idempotency bugs. Tackling it with new verbs and declarations is probably doomed to "I thought it /was/ idempotent". -- Colm --001a11467ba6d0bec6052e069e64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 14, 2016 at 11:27 AM, Subo= dh Iyengar <subodh@fb.com> wrote:
Currently the only way to express retry= behavior in HTTP is by the method (i.e. whether it is idempotent or not), = which as you pointed out may have unfortunate side effects, since it is not= explicit. The proposal (at least one of them) is to add an explicit way to express retry safety in HTTP as an additional request property simi= lar to method. This can be used by the agent (browser or http library) to d= ecide whether or not to use 0-RTT for the http data. I'll link to it in= this thread once it's posted.

Just on this; if you want to be sure of idempotency= on the server side; the best answer to is might be to intentionally send t= he data 2+ times at the protocol level.=C2=A0 If the action really is idemp= otent, then the repeat will be safe. Doing so as a matter of course builds = up anti-bodies against any nascent idempotency bugs.=C2=A0

Tackling it with new verbs and declarations is probably doomed to = "I thought it /was/ idempotent".=C2=A0

= --
Colm
--001a11467ba6d0bec6052e069e64-- From nobody Mon Mar 14 11:42:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E8712D726 for ; Mon, 14 Mar 2016 11:41:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BccROp8WNuib for ; Mon, 14 Mar 2016 11:41:56 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9F09B12D6F8 for ; Mon, 14 Mar 2016 11:41:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 2DC751EE3; Mon, 14 Mar 2016 20:41:55 +0200 (EET) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id eEsJJUz5CBik; Mon, 14 Mar 2016 20:41:54 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id AEC4AC4; Mon, 14 Mar 2016 20:41:54 +0200 (EET) Date: Mon, 14 Mar 2016 20:41:53 +0200 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Message-ID: <20160314184153.GA14692@LK-Perkele-V2.elisa-laajakaista.fi> References: <56E54B85.4050204@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:41:59 -0000 On Mon, Mar 14, 2016 at 09:15:17AM -0700, Colm MacCárthaigh wrote: > On Mon, Mar 14, 2016 at 4:32 AM, Eric Rescorla wrote: > > > For 1. Raw data throughput could be improved by envelope encrypting the > > early data; and transferring the envelope key only once the session has > > been fully authenticated > > Unfortunately, that doesn't work for things like protocol banners or other things that can be sent in 0-RTT and replied to in 0.5-RTT. (Also, with regards to my comment about cryptographic screwedness, such screwedness is not inherent in DH-0RTT, but is consequence of the current implementation). -Ilari From nobody Mon Mar 14 11:57:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541E612DC85 for ; Mon, 14 Mar 2016 11:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 otTAqS1HED-p for ; Mon, 14 Mar 2016 11:57:16 -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 7BE7512DC81 for ; Mon, 14 Mar 2016 11:57:10 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h129so179804866ywb.1 for ; Mon, 14 Mar 2016 11:57:10 -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:date:message-id:subject:from:to :cc; bh=BrC1LvuUDuWNk1ka1X7i4+buGEJIpqQOBmwKlIFs6EU=; b=xlnbrNgk9bJ11N74i9lupFE3DJfpSiy6DL6e7NR1YhNqqmxiMjtbCWIEGWMPZ3tRks mkDzuGoZigEN9d/yR88LGrVdRewUYc2Qjl/QtmKs5Kwm5McxrFhtH5VFqFc6IfjGp8ji 900w7Wox+29O9xxYLsjqPi2Xv2cN96yS46LPrGvQhNejPOZuG65KCI3EFvjbm/pw7+bt n+Y7wk6woQhJiKNpjFHnjFOhZ2t2P7x287w3cQE+mLgdJGnfBFzRqYcsp5MqJEZ96Ka4 SjvKdS2ueyPoFSedIpI1YVh9YMb4boMqYfKMgMGcrWEmGUVk/aU9dfZhLNspPpACJ3Mh aQug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=BrC1LvuUDuWNk1ka1X7i4+buGEJIpqQOBmwKlIFs6EU=; b=ZcyGEc/e9iZw4vUGqRGppZ5++lBnpv6oN2gKmmq2TGmzwfdzcfkS5KhwyBicyUcQGn G/0lnBVLm8SnVyp5VoaLtNiX/Vi64xRv1naruTn9RzGZ/+3MzMoyytF8mECwSoau2RQR yGnIIJQX1SRaqggZ2VBbrL39X4KvUYyhfHu8g9eUcKOJnw2i16rfT4d3OJDuf1Cz1okM tvge9Ll9EUh0t7xmpm9i4GmvKiNoQS/5KQN8FkUvSvvz+pm1ZE+0QMegW0ocI3RnY6jp jm93yyyOs7L2gPU/Fz7vEncf19SAygZKbS5wQVpOqx73U4hSd+IWDgAlVzoKXWd6katk 6qtw== X-Gm-Message-State: AD7BkJI7PvZeiHQ9KG20ZMx6w6hY39JjSDois0Q/Bb+Cx/9JiYj2OAAmvrkegKDBo3f8yOcpZRcCb7nWnncuiQ== MIME-Version: 1.0 X-Received: by 10.13.212.202 with SMTP id w193mr11649470ywd.175.1457981829725; Mon, 14 Mar 2016 11:57:09 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 11:57:09 -0700 (PDT) In-Reply-To: <20160314184153.GA14692@LK-Perkele-V2.elisa-laajakaista.fi> References: <56E54B85.4050204@cs.tcd.ie> <20160314184153.GA14692@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 14 Mar 2016 11:57:09 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114fa17c0cf4e4052e06d921 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:57:17 -0000 --001a114fa17c0cf4e4052e06d921 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara wrote: > > (Also, with regards to my comment about cryptographic screwedness, > such screwedness is not inherent in DH-0RTT, but is consequence of > the current implementation). > This is interesting ... is there a way to do it that would preserve forward secrecy? -- Colm --001a114fa17c0cf4e4052e06d921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
(Also, with regards to my comment about cryptographic screwedness,
such screwedness is not inherent in DH-0RTT, but is consequence of
the current implementation).

This is in= teresting ... is there a way to do it that would preserve forward secrecy?<= /div>
=C2=A0
--
Colm
--001a114fa17c0cf4e4052e06d921-- From nobody Mon Mar 14 12:12:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DF512D6D5 for ; Mon, 14 Mar 2016 12:12:55 -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, 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 hT4H87N8GLr9 for ; Mon, 14 Mar 2016 12:12:54 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190A612D50C for ; Mon, 14 Mar 2016 12:12:54 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 2267533D252; Mon, 14 Mar 2016 19:12:52 +0000 (UTC) Sender: geoffk@localhost.localdomain To: =?utf-8?b?Q29sbSBNYWNDw6FydGhhaQ==?= =?utf-8?b?Z2g=?= References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> From: Geoffrey Keating Date: 14 Mar 2016 12:12:51 -0700 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:12:55 -0000 Colm MacC=C3=A1rthaigh writes: > On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar wrote: > > > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite > > replayability. As mentioned in the other thread we have ways to reduce = the > > impact of infinite replayable data for TLS, making it reasonably replay > > safe. > > >=20 > That too is a mis-understanding. The deeper problem is that a third party > can do the replay, and that forward secrecy is gone for what likely is > sensitive data. Neither is the case with ordinary retries. Just to expand on this: HTTP GET is idempotent and so replayable, correct? That is, if you send two GET requests in a row, you should get the same results, no changes should be caused on the server side, and the attacker learns nothing new, even if the attacker could not have issued the original GET. However, just because this is true for two sequential GET requests, it may not be the case for a series of requests. For example, a GET followed by a PUT followed by another GET. If the second GET is performed by an attacker, it might reveal that the PUT has occurred and the new size of the result. Further issues can occur depending on the application. For example, if the result contains a timestamp, some sensitive numeric data, and is compressed, then repeated queries will leak information about the numeric data at a higher rate than if the attacker had to rely on passive monitoring. So, I don't think HTTP is generally safe against attacker-forced replay, and would suggest great caution in allowing it. Perhaps we could say, in the TLS RFC or a new RFC covering the topic, that it should only be allowed by servers and clients when serving/requesting immutable static data, that is for requests that will only ever return one result. From nobody Mon Mar 14 12:15:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682CC12D725 for ; Mon, 14 Mar 2016 12:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19p6hhM28dg2 for ; Mon, 14 Mar 2016 12:15:18 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F3812D712 for ; Mon, 14 Mar 2016 12:15:17 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id p65so115389867wmp.1 for ; Mon, 14 Mar 2016 12:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xuOuxFEiq58Ou346gywqTfda7hTQCU8E16SSVoU4xUY=; b=nXKkx9xWsok1MFIUb+aN/d2uJfAeoUUdS/xaoRBFq0aorvCCkpxtfnLwfDhlfBhivu JuDhuEUoivByxVeGOmMbjlZ8kaRCJkK4irSA2qVXadXd6sCwonp+TwaBe5ieqRGRunwt UzvQYdCK+fvJCJY60zNQPMBKpTYzRUXy2bqaxmlVe1TtsM9BFhEaW5yKZayMIHdx8Q+B 9ZD+tOp3k/84UBOAZfCNKm1olNqmEzWR5PLMf4lklMEgvIhneSwLeWVVzAFVhrXLcXLN sQ8vVjj2UDGl4j2R36a4INB+0BI6NP1WMbFzn1Ogbn/NMq4mj0/Tzlk54UyqGTh/Ti/Y UoMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xuOuxFEiq58Ou346gywqTfda7hTQCU8E16SSVoU4xUY=; b=U+KbasE7F2mH1d+IDWCp16Z5kpp/t5hixQGfWwm/1wggkH4P4VK2wkQyL/DXQKdzUA z62DFtLJiCXynkLYdXcwJ78+szLuAt2pnKNoldant44pjLZrKBPtvjVdhl0IEhOBH9lW VGEASbvp3ETqnMAxYFIZMr4PWVebIzPhHFTcL2uL+FK4XwzLNgTspe6oUdCHQpbct8jb ZxbYIBU/uZagQmk4P3f6y1lsPP6JERpixg50iE7mja2EKr68x1jzUUoYctxIs3HwWBOD e5aTrF+OPV4OJmQlCUo93GrT4gBus1zQUncOhHodw9By6pACzi3w4iSC7+nUdT9M414Z hz6w== X-Gm-Message-State: AD7BkJLeYCrm844GWVS6w6F2A+9xl2xHLRKKlguLf8D5c2zbasrrvclPinzVcMwfgCqSQayrJPbNfbAnt6k1zSw0 MIME-Version: 1.0 X-Received: by 10.28.179.7 with SMTP id c7mr20894284wmf.46.1457982916328; Mon, 14 Mar 2016 12:15:16 -0700 (PDT) Received: by 10.28.30.75 with HTTP; Mon, 14 Mar 2016 12:15:16 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Mon, 14 Mar 2016 12:15:16 -0700 Message-ID: From: Ryan Hamilton To: noloader@gmail.com Content-Type: multipart/alternative; boundary=001a11452e4cd14521052e0719c7 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:15:20 -0000 --001a11452e4cd14521052e0719c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton wrote: > 0-RTT seems to be a solution looking for a problem. > =E2=80=8BGoogle has been using 0-RTT as part of the QUIC transport for quit= e a while now. In April of last year, we posted about the performance benefits we're seeing from QUIC . Among other things, that post said: Even on a well-optimized site like Google Search, where connections are often pre-established, we still see a 3% improvement in mean page load time with QUIC. >From the browser side of things, 0-RTT is a solution to a very real problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT resumption) and converting QUIC to use the TLS 1.3 handshake as a result. Cheers, Ryan --001a11452e4cd14521052e0719c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton <noloade= r@gmail.com> wrote:
0-RTT seems to be a solution looking for a= problem.
=C2=A0
=E2=80=8BGoogl= e has been using 0-RTT as part of the QUIC transport for quite a while now.= In April of last year, we posted about the p= erformance benefits we're seeing from QUIC. Among other things, tha= t post said:

Even on a well-optimized site like Google Search= , where connections are often pre-established, we still see a 3% improvemen= t in mean page load time with QUIC. =C2=A0
<= div class=3D"gmail_extra">

From the browser si= de of things, 0-RTT is a solution to a very real problem. We are excited ab= out TLS 1.3 supporting 0-RTT (or 0-RTT resumption) and converting QUIC to u= se the TLS 1.3 handshake as a result.

= Cheers,

Ryan

--001a11452e4cd14521052e0719c7-- From nobody Mon Mar 14 12:16:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2C12D72A for ; Mon, 14 Mar 2016 12:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AHr6uh7HnxF for ; Mon, 14 Mar 2016 12:16:36 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E452C12D722 for ; Mon, 14 Mar 2016 12:16:35 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id ig19so70196994igb.0 for ; Mon, 14 Mar 2016 12:16:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=sORh9VLrOt+icdNShwwDCKvMGnus1rpfVfkhmLnaWk4=; b=pMgrk6kbeRVpANfUPO53ByFOa+vNyGjQA/phTPD/rgdI1/4LvpvOZy77sxTeTJKvZQ ALjfJQldWABKuM3ataJe9HdHB1n7LxpggH/oazjeFBe28yzBUjsgarZNJYp9mOX7BBa1 0zGrnZ7fhHEMN+GtSNh+Om+U0Y6Mca+ZG2yurIINe9hpmo7a/aQt+ynnvBxyNKGqy932 YJJJlQSPvlyxo6pNn/RZ28VZ/QyfhrWI2syTi/5x8KjScARnqdNXjCq1qfqy6s2Z70UW vkcGdYIqr6uQtOl+LWnWVutjEb5eXwXyVM9Ev2n1qy+1tOFyMp6yRBRHo1y1y/kcXsMk 4wtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=sORh9VLrOt+icdNShwwDCKvMGnus1rpfVfkhmLnaWk4=; b=UEASwMgdN6jKM9Lm/miOQPqcjCwF2+gJjdi7KhBCHjtkQ2zScQxZuxxD4rFXCyXa3C vOa25ItxTI4OWeClYRaL7zpSk1vK9ybZXZAbVXEfvinABxXzTLYXxrR7KAQXSa4hEzU0 prOXafdWXTV0IRsjdPVfnPU82jryE61P72AErA+xc/abX2QR/wJDSLVcT2iplBwmQoOd kPbtllx2eEqbi6ul1/wxCkzrj7zr/8a/JUmYVEQxRI+6fkwJN47nTvb3r/92rNrWv53S aDLKVF4r52B1Shj0/TYx1V5tLpsk0CoyjgFI0DjsshIxBbBU/oX1t4BjYgpw9qIb3FGq EuwQ== X-Gm-Message-State: AD7BkJJ/kaoYhy7jXXxoMCpu7kApj1Sr3eMotOGy1B2oOGCIpVJO39orYcpEQV6vU27+bXVeGXaiuDHhT9HLTzy3 MIME-Version: 1.0 X-Received: by 10.50.70.39 with SMTP id j7mr19294984igu.40.1457982995174; Mon, 14 Mar 2016 12:16:35 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 12:16:34 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160314184153.GA14692@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 14 Mar 2016 12:16:34 -0700 Message-ID: From: Bill Cox To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=047d7b3a93c68476d4052e071e9d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:16:38 -0000 --047d7b3a93c68476d4052e071e9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 11:57 AM, Colm MacC=C3=A1rthaigh wrote: > > > On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: >> >> (Also, with regards to my comment about cryptographic screwedness, >> such screwedness is not inherent in DH-0RTT, but is consequence of >> the current implementation). >> > > This is interesting ... is there a way to do it that would preserve > forward secrecy? > Replay resistance requires server-side state. If that state includes session decryption keys and we want PFS, then these keys need to be encrypted using keys held by the client, which is not possible in DH 0-RTT. Therefore the session keys cannot be saved on the server, and the 0-RTT data cannot be encrypted using anything but the server's static keyshare, which is not fully PFS. I see no way to implement real PFS in the existing DH 0-RTT scheme. However, I consider a few days of non-PFS to be good enough. Bill --047d7b3a93c68476d4052e071e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 14, 2016 at 11:57 AM, Colm MacC=C3=A1rthaigh <= colm@allcosts.net> wrote:

=

= On Mon, Mar 14, 2016 at 11:41 AM, Ilari Liusvaara <ilariliusvaara@w= elho.com> wrote:
(Also, with regards to my comment about cryptographic screwedness,
such screwedness is not inherent in DH-0RTT, but is consequence of
the current implementation).

Thi= s is interesting ... is there a way to do it that would preserve forward se= crecy?

Replay resis= tance requires server-side state.=C2=A0 If that state includes session decr= yption keys and we want PFS, then these keys need to be encrypted using key= s held by the client, which is not possible in DH 0-RTT.=C2=A0 Therefore th= e session keys cannot be saved on the server, and the 0-RTT data cannot be = encrypted using anything but the server's static keyshare, which is not= fully PFS.=C2=A0 I see no way to implement real PFS in the existing DH 0-R= TT scheme.=C2=A0 However, I consider a few days of non-PFS to be good enoug= h.

Bill
--047d7b3a93c68476d4052e071e9d-- From nobody Mon Mar 14 12:23:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB8E12D74D for ; Mon, 14 Mar 2016 12:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imvPuDraTzEC for ; Mon, 14 Mar 2016 12:23:28 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D04712D742 for ; Mon, 14 Mar 2016 12:23:27 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id l68so115901543wml.0 for ; Mon, 14 Mar 2016 12:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PLYZdariZz0S2H0qMP6JyNlfeehuHG3qTN2eBzTOjJM=; b=lsikwT/vFGsnwgQg5RR36XtUsqigh/7RYaxlz9lN6kFF7Hz0EvcMM4RHBMzALgI0qW d8sFvVVHhiLst75lDV6D27E5gXGoJMOJzmxwljQWI7PIChDjn8dfHCVBv1X36GcxVEGJ 0l8dPcWOEpIoYt3xu5A/UO/wMqOWMJyBcL6Mu/RCjviqNkvu5/IuCHMqDT0+d2Xu23Db orjjgfdqzg6BqkMo+JmAmrGnecjqwg8D5W1YiCk8wco8JzchgM/6TCuGbqujUhKni13j xnQcewDlyQYNB8dMUsIGw+S3Uucdg8xQjP+0u+cJ9PH7VN08mkMJdFpsoBd1izoCccds IEjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PLYZdariZz0S2H0qMP6JyNlfeehuHG3qTN2eBzTOjJM=; b=Xci0S0gN1gUQkqzoHazRQDfa+Sz6WYOyCRjiyVLo4XHj6B58PQrI9I5efgkA9O1c5L jri/mqk4FZEu0rB7mDXMyPq1RCp5s188pH6c2jWt4VyANqpFmahCvDAvHdAakOaFp//s PcGF2aIm7bOltUvWAt/13hOm7kufHHwmoeTKK7+NCMvJ3h34gCIx0vC1zyEy0+enoWAM Lbh7uN33pamNjGebvO9hbqvbKcDF01rNqxr+JcG5OV796ld3VMV955g6Kp3SetVVWQh9 ca3uJtWzDZ57ISnVWtDCTiIEcjqPX20/M+MbflJ0zvCmjoRlFyMm3HRRPOTjkU3SzZ1J diuw== X-Gm-Message-State: AD7BkJLFgY2h0dvony5OPtbOwVlUtm7k0R4u5sBb7C5up1/3GqO9lJhfTbYTyhIoX4AeP91x8J/rS4jEhIhYyjKm MIME-Version: 1.0 X-Received: by 10.194.116.9 with SMTP id js9mr30419298wjb.112.1457983405790; Mon, 14 Mar 2016 12:23:25 -0700 (PDT) Received: by 10.28.30.75 with HTTP; Mon, 14 Mar 2016 12:23:25 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> Date: Mon, 14 Mar 2016 12:23:25 -0700 Message-ID: From: Ryan Hamilton To: Geoffrey Keating Content-Type: multipart/alternative; boundary=001a1130d218fdfb10052e0736a9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:23:30 -0000 --001a1130d218fdfb10052e0736a9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating wrote: > So, I don't think HTTP is generally safe against attacker-forced > replay, and would suggest great caution in allowing it. > It's worth keeping in mind this recent paper about Replay attacks against HTTPS . TL;DR: Attackers can already force a browser to replay requests basically at will. =E2=80=8BAs a result, it's not clear that 0-RTT replay makes this situation worse. --001a1130d218fdfb10052e0736a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geoff= k@geoffk.org> wrote:
So, I don't think HT= TP is generally safe against attacker-forced
replay, and would suggest great caution in allowing it.
<= /div>
It's worth keeping in mind this recent paper about <= a href=3D"http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN"= class=3D"cremed">Replay attacks against HTTPS. TL;DR: Attackers can al= ready force a browser to replay requests basically at will. =E2=80=8BAs a r= esult, it's not clear that 0-RTT replay makes this situation worse.
--001a1130d218fdfb10052e0736a9-- From nobody Mon Mar 14 12:25:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104BC12D737 for ; Mon, 14 Mar 2016 12:25:41 -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 mfGQpM4mrtiK for ; Mon, 14 Mar 2016 12:25:31 -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 A19E412D717 for ; Mon, 14 Mar 2016 12:25:31 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g3so180699682ywa.3 for ; Mon, 14 Mar 2016 12:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=ZB0NlCovF74bTwUaN8+CkMtCY7YF4h/uDLhwSu64EII=; b=bZn1r7M8LjoHM9de8NhBiPNzuJWqBP3c1EPrRh3BWFMwmkJQ9fFLzR37b3WptYvT+2 OXoarhUBtkQf8jMN1Qneq2MQVQNegnlo18BdG/3Iv1uCEd24AK8BPmu2oWP15ce8Pai9 k8mq1rQjDor4k8/m+HglZZj113dnHAE1adLIJ2WHO2z4CVWEuLGKyA/AVWvaV4TG44VF f4yDEBPW+biU91zP6gIq3ZBWaRZrQAMu3u/RZSeQzPxw85HweK2sts3edoEjyDwvv+4Y 26ahq+jE5hXds/DcclBxrM4RIzrle5K8wdRBP1WHY+XiZJzuE9vVs80v7CU3ju9euZfR 5srQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=ZB0NlCovF74bTwUaN8+CkMtCY7YF4h/uDLhwSu64EII=; b=YrxGvjhBhCT1tj8Ns5twrcu3TmHzJR1MoCE7rEXit4/tHJB8Rp6m14DBeo3tYY2hDU e7hV+rC2EfogJ/1O+yrutDMFtvz1Lbz9Rk4qq19Hjm7jHzY26ezpEqrp1uHPSkjmZ+Bb 3Z+eyvHEH3UR+beCqFGfzr3o2QyxteHEheKwaKi2k+K7Li2x88cOanFYGeKTheEw7lY4 J77KKSLHQ5hJa/gAV5hnORJx1sYnK80V3vrj4tuaGy94/R68J26+qQ/7Ug4LO/+i/XmE k+msi9kFBQ0AgFbXcC5tJ5d0dCtSesS2EAR7SodJ05kfZGSmR4gOSdzhIZkYBRYV9K8p Gy/w== X-Gm-Message-State: AD7BkJJtLdRLY8NGiL3yO6Dgby5o6xPLgmsXSzCJIHeC6hL5LWLIP6IuG8ntnw3X8CdpsA== X-Received: by 10.37.4.129 with SMTP id 123mr2838976ybe.81.1457983530909; Mon, 14 Mar 2016 12:25:30 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id f81sm14925033ywb.38.2016.03.14.12.25.30 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 14 Mar 2016 12:25:30 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 14 Mar 2016 15:25:28 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56E54B85.4050204@cs.tcd.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201603141525.29198.davemgarrett@gmail.com> Archived-At: Cc: Scott Schmit Subject: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:25:41 -0000 (This thread has gotten long and winding, so I'm replying to these two port= ions bellow under a new subject. Reply after quotations.) On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote: > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh wrote: > > On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrot= e: > >> As we all know, what matters most in security is the default mode. I = am > >> suggesting making the default 0-RTT resumption mode stateful, with a > >> documented session-ID (and let's bring back the timestamp, too, since = we'll > >> need it). > > > > Having state would make things much more robust; but rather than the st= ate > > being around the channel itself (the TLS session), would it be more rob= ust, > > and more flexible, for the state to be around the action? like some kin= d of > > hint cookie. >=20 > It looks like server-side state is required to prevent replay. I don't > think any kind of token, cookie, or server-config can fix this. >=20 > > One of the problems with session resumption is that in order to be repl= ay > > safe; the sequence number has to restart where it left off. That requir= es > > some kind of transactional store, and if you're doing all of this for > > latency, you may end up eating all of the wins there. >=20 > The new tickets can in theory end the debate over session caching vs > session tickets, since they can be used for database lookups or contain an > encrypted session state. However, the spec does not document how to do > session caching with tickets securely, which looks tricky. In reality, if > I were trying to build a speed and security sensitive site using TLS 1.3 > stateful 0-RTT resumption, I would probably do something like this: >=20 > During the initial 1-RTT handshake: > - create a ticket containing only the session ID, resumption count, and a > session decryption key > - encrypt the session cache entry with the session encryption key stored = in > the ticket > - encrypt the ticket with a semi-static ticket encryption key, which I > would rotate every few weeks > - send the ticket to the client, which is after encryption is enabled on > the connection >=20 > During a 0-RTT resume handshake: > - check for a cache hit, and drop to 1-RTT if not found > - decrypt the ticket with ticket the semi-static ticket decryption key > - decrypt the cached session state with the session key from the ticket > - compare the resumption counts in the session state and ticket, and fall > back to 1-RTT if they do not match > - increment the resumption count > - create a new session ticket with a new session encryption key and the > updated resumption count > - encrypt the session cache entry with the new session encryption key > - send the client the new ticket On Monday, March 14, 2016 08:10:32 am Nikos Mavrogiannopoulos wrote: > It is important to see how protocols are perceived. For many people TLS > 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an > attack against TLS 1.3 with rtt, will be perceived as an attack against > TLS 1.3 protocol. Even if the published attack against TLS 1.3 with > 0rtt was an expected one (i.e., replay of data), if the attack impact > is high, that may not be sufficient to stop the avalanche of bad > publicity. In turn that will lead several people losing confidence to > TLS 1.3 as a protocol, even TLS and the IETF process overall. > =20 > My suggestion, if you need 0rtt, publish it as a different document, > don't mix it with TLS 1.3. The security requirements from TLS are > vastly different from the security requirements of a 0rtt protocol. Previous discussion seemed to land on the conclusion that semi-static DH 0R= TT should be defined in a separate document, and after this discussion I'm = beginning to agree that all stateless 0RTT should be defined as a separate = companion document to the main TLS 1.3 specification. We can likely agree o= n defining a stateful 0RTT PSK resumption system which is sufficiently safe= and mistake-resistant, and we could restrict the official TLS 1.3 spec to = only specify that, whilst referencing the other document as a more experime= ntal feature that could be available to certain applications (possibly a no= n-standards-track document). HTTPS could then, itself, have a separate docu= ment laying out the necessary practices to do stateless 0RTT safely, and ot= her applications should be warned that without a similar such document, thi= ngs are very risky. Is this in the ballpark of what the WG could agree on to help mitigate some= of the problems here? Dave From nobody Mon Mar 14 12:26:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C4612D70D for ; Mon, 14 Mar 2016 12:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 c-912P8E-apo for ; Mon, 14 Mar 2016 12:26:03 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 9C95C12D73E for ; Mon, 14 Mar 2016 12:25:59 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D762042373D; Mon, 14 Mar 2016 19:25:58 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C063D423728; Mon, 14 Mar 2016 19:25:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1457983558; bh=uYA5OApgcxDZXOXQHZNFI4P17ftG5POzZyvLS8EhJqM=; l=444; h=From:To:CC:Date:References:In-Reply-To:From; b=acP4GQofPSQSSn6T1tRPTXp5Yfo6f9mXUVBiwsEuLANvID+UOPoFvAahQPsTs0/b/ g69bVgnFqO6laHee/wl9oAImEDJQYTqRpcn4T337UV6j31iMyupwGYp7SII4MQnxdG 4BMa6SMRRMiMZQ2tjuTQwbSFhu2mA7anL22bPEig= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BA61B1FC93; Mon, 14 Mar 2016 19:25:58 +0000 (GMT) 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.1130.7; Mon, 14 Mar 2016 15:25:58 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 14 Mar 2016 15:25:58 -0400 From: "Salz, Rich" To: Ryan Hamilton , Geoffrey Keating Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmCOC9+j35tnUyBsRmmKhu5h59ZeO2AgAAHu4CAAAcKgIAADCqAgAAC9ID//72QMA== Date: Mon, 14 Mar 2016 19:25:57 +0000 Message-ID: <94ce05b82d47420b9acddb24b6bc2503@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.105] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:26:06 -0000 PiBJdCdzIHdvcnRoIGtlZXBpbmcgaW4gbWluZCB0aGlzIHJlY2VudCBwYXBlciBhYm91dCBSZXBs YXkgYXR0YWNrcyBhZ2FpbnN0IEhUVFBTLiBUTDtEUjogQXR0YWNrZXJzIGNhbiBhbHJlYWR5IGZv cmNlIGEgYnJvd3NlciB0byByZXBsYXkgcmVxdWVzdHMgYmFzaWNhbGx5IGF0IHdpbGwuIOKAi0Fz IGEgcmVzdWx0LCBpdCdzIG5vdCBjbGVhciB0aGF0IDAtUlRUIHJlcGxheSBtYWtlcyB0aGlzIHNp dHVhdGlvbiB3b3JzZS4NCg0KVExTIGlzIG1vcmUgdGhhbiBqdXN0IGJyb3dzZXJzLCB3aGljaCBp cyB3aGF0IHN0YXJ0ZWQgdGhpcyB0aHJlYWQgSSB0aGluayANCg== From nobody Mon Mar 14 12:32:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C2B12D767 for ; Mon, 14 Mar 2016 12:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcfN_XspPl3S for ; Mon, 14 Mar 2016 12:32:52 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 511EC12D751 for ; Mon, 14 Mar 2016 12:32:52 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id ig19so70547920igb.0 for ; Mon, 14 Mar 2016 12:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=1cm80fwmA+R+jlfkRosrVfYo4YyUCRX4eoe1ORDG9ZM=; b=XTn7ASPEOnazaNEt6SNPDBGws6s6EZEM/rU5c6YWC4BDp7RobtDaNK0HbXbPrt1TKZ OsqSEoVOhlkW7cjQgbfNtE/RomCnGeG5DwlYXO/g4WExBgzZkTCFuecHrkuUTn/ow6Kd 3efWAbsJ6V9WH+sIYGuNctlLXAZHE8onyonMX0kHdmDyVMJQrOrFztCW9RSKY8cVCpBQ esnkcYIO8jY8T7H9y0ktXM+jyYKrpFr+0tFAEK8+jwsnR1UXBzmda+D4187N+TV3hOhR /85f8veOlnbSN0kn03UVX7gjePuJK00nQMSLWO337sWVeZwZ/kB4GRgMDERottFuHPh+ gZfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=1cm80fwmA+R+jlfkRosrVfYo4YyUCRX4eoe1ORDG9ZM=; b=VUjYmzRyeXDuHFgBsYEx0eVmWgQAIIDhpMqoJBwnwmmmqsZ4LbSK6bw2nEliYnjB5D QYNLeUdWjghmYn5kk3HGiEc7Fh2fKirMttOo3pE6km9gyEbVtENbgtCu0eJmkSc8L1XJ wPAKg7Jf5iSI6c8iYhbzTFWYUI2Om/7wvkdiz7brVyQrDoNWr/e6GSq6XsGjaQDa2LSp TvAQEKQDbhlkQ+F7CZlaD8NaEdSwhBgrj5RmkSwBJ/KmB9QASXjNUrRZT09OfIZx6m0/ Y71G862F6750zAEeB6fE+AmQNCSzJArh6cOyNQn7WCHe9r0YgHpb8uvkPIZ8DJsD4k0P 1yfw== X-Gm-Message-State: AD7BkJK+HNLnb6P8rOXqgzLQ7YO1y3U9SX0uC+4l6xPafI6yYYufhfPkKsx4VSAspSEE5cymcT1bUuHJK9DUQEvT MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr19870424igr.4.1457983971189; Mon, 14 Mar 2016 12:32:51 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 12:32:50 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313182336.GA13172@LK-Perkele-V2.elisa-laajakaista.fi> Date: Mon, 14 Mar 2016 12:32:50 -0700 Message-ID: From: Bill Cox To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=047d7bea423eb22345052e0758fd Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:32:54 -0000 --047d7bea423eb22345052e0758fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 9:34 AM, Colm MacC=C3=A1rthaigh wrote: > > > On Sun, Mar 13, 2016 at 12:04 PM, Bill Cox wrote= : >> >> IMO, 0-RTT is the most important new feature in TLS 1.3 ... Speed reall= y >> _is_ that important. >> > > I just want to be super explicit on this. There is a trade off to be made > here between fast and loose Vs security and safety. My take is that speed > absolutely is not so important that forward-secrecy for user requests, or > replay safety for applications should be compromised. > I agree that the default mode of operation needs to be secure and safe. Since 0-RTT is so important for TLS 1.3, I would favor making the default 0-RTT mode secure. > Even better speed benefits can be had by using persistent connections, > which incidentally are also a little more robust against traffic analysis= . > Exactly. Stateful 0-RTT session resumption can get us there, I think. The simplest approach I can think of is to use session caches. If we don't mind some PFS loss (comparable to what we got in TLS 1.2), the straight-forward 0-RTT solution seems to work. Bill --047d7bea423eb22345052e0758fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 14, 2016 at 9:34 AM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:

<= div class=3D"gmail_extra">
On Sun, Mar 13, 20= 16 at 12:04 PM, Bill Cox <waywardgeek@google.com> wrote= :
IMO, 0-RTT is the most important new featu= re in TLS 1.3 ...=C2=A0 Speed really _is_ that important.
=

I just want to be super explicit on = this. There is a trade off to be made here between fast and loose Vs securi= ty and safety. My take is that speed absolutely is not so important that fo= rward-secrecy for user requests, or replay safety for applications should b= e compromised.=C2=A0

I agree that the default mode of operation needs to be secure and safe.= =C2=A0 Since 0-RTT is so important for TLS 1.3, I would favor making the de= fault 0-RTT mode secure.
=C2=A0
<= div>Even better speed benefits can be had by using persistent connections, = which incidentally are also a little more robust against traffic analysis.= =C2=A0

Exactly.=C2= =A0 Stateful 0-RTT session resumption can get us there, I think.=C2=A0 The = simplest approach I can think of is to use session caches.=C2=A0 If we don&= #39;t mind some PFS loss (comparable to what we got in TLS 1.2), the straig= ht-forward 0-RTT solution seems to work.

Bill

--047d7bea423eb22345052e0758fd-- From nobody Mon Mar 14 12:33:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4D312D76B for ; Mon, 14 Mar 2016 12:33:38 -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 oQEC0PK6ApOy for ; Mon, 14 Mar 2016 12:33:32 -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 D1A5F12D756 for ; Mon, 14 Mar 2016 12:33:31 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id g3so180978723ywa.3 for ; Mon, 14 Mar 2016 12:33:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pWLALy1LHA7l6U/QUVBFm+Ich6qfnlQLoBWXeQg/7+A=; b=Jslxm5V2Mak6Pk7+5H1JjovRxpFOyIBRYeaqIsl336e2L0OBzlK2UQo5Dg/sSts49t A73lbu86UhupbXp4fZtRkPDn0vI2MtGjTm+QB72kNr0zkpa2n3B0T9rjtR8DiDK1No17 FGaePAcK33v10K349Tvpbkz5KIoBCgYak1B0DKqbW6bRvCHgcE0eOrTkUyNWMcmusRIL nFz4FFwWQJVIXRte8RMnSw8LUFxfEcyr9la5Kw1n0usL4AyhDsBKlzBDkEMA3Ta5d1Ay g5Vt5lBNPzbcIvQezGqMZPwhyvPrgbAf1BejCFaPzMGEXHuwsy6gt8TzU5kmDmhoGIlh sICQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pWLALy1LHA7l6U/QUVBFm+Ich6qfnlQLoBWXeQg/7+A=; b=efYWEF4TnrbJm7ySt5q50nSm7mdKWfVJgdg0l58oUfpZ5CWddZxWvwJmLwBuGn+LYI HL2DJj9ttY1MyxyslktyUkqN5kj7HXaMLMNnyun+1IdCcVRl327EXCZPRwUOWySseVWp T8i8dm9fZ9T3dyHQsIxM/wGnAHgn0XReBmojo7aRQfKBBKyzISWSTN4L9lUbza1+1kGk +LMEDrKesFQ7so2Tjqs5cvRkRf0Dx7hccvPzSQd1TjVmxixp3M+blsUM/EpHALDB2dcB dmTzui/O79x/l3uBNoFjMqjdxPwyksaU0joTgkp+EbmaAduMti0cfPLq8JBvzxxpO7xZ MVpQ== X-Gm-Message-State: AD7BkJIf7JMiASLGenLTKoeu3ScC8VAnFPFNKIWHLoyAid8PEwPB+iFtyFlKa4l8LgTAfBuwgXPtTKPiEDdbTg== X-Received: by 10.129.46.87 with SMTP id u84mr12908403ywu.129.1457984010964; Mon, 14 Mar 2016 12:33:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 12:32:51 -0700 (PDT) In-Reply-To: <201603141525.29198.davemgarrett@gmail.com> References: <56E54B85.4050204@cs.tcd.ie> <201603141525.29198.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 14 Mar 2016 12:32:51 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114140ba1014aa052e075bcd Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:33:38 -0000 --001a114140ba1014aa052e075bcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett wrote: > (This thread has gotten long and winding, so I'm replying to these two > portions bellow under a new subject. Reply after quotations.) > > On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote: > > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh > wrote: > > > On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox > wrote: > > >> As we all know, what matters most in security is the default mode. = I > am > > >> suggesting making the default 0-RTT resumption mode stateful, with a > > >> documented session-ID (and let's bring back the timestamp, too, sinc= e > we'll > > >> need it). > > > > > > Having state would make things much more robust; but rather than the > state > > > being around the channel itself (the TLS session), would it be more > robust, > > > and more flexible, for the state to be around the action? like some > kind of > > > hint cookie. > > > > It looks like server-side state is required to prevent replay. I don't > > think any kind of token, cookie, or server-config can fix this. > > > > > One of the problems with session resumption is that in order to be > replay > > > safe; the sequence number has to restart where it left off. That > requires > > > some kind of transactional store, and if you're doing all of this for > > > latency, you may end up eating all of the wins there. > > > > The new tickets can in theory end the debate over session caching vs > > session tickets, since they can be used for database lookups or contain > an > > encrypted session state. However, the spec does not document how to do > > session caching with tickets securely, which looks tricky. In reality, > if > > I were trying to build a speed and security sensitive site using TLS 1.= 3 > > stateful 0-RTT resumption, I would probably do something like this: > > > > During the initial 1-RTT handshake: > > - create a ticket containing only the session ID, resumption count, and= a > > session decryption key > > - encrypt the session cache entry with the session encryption key store= d > in > > the ticket > > - encrypt the ticket with a semi-static ticket encryption key, which I > > would rotate every few weeks > > - send the ticket to the client, which is after encryption is enabled o= n > > the connection > > > > During a 0-RTT resume handshake: > > - check for a cache hit, and drop to 1-RTT if not found > > - decrypt the ticket with ticket the semi-static ticket decryption key > > - decrypt the cached session state with the session key from the ticket > > - compare the resumption counts in the session state and ticket, and fa= ll > > back to 1-RTT if they do not match > > - increment the resumption count > > - create a new session ticket with a new session encryption key and the > > updated resumption count > > - encrypt the session cache entry with the new session encryption key > > - send the client the new ticket > > On Monday, March 14, 2016 08:10:32 am Nikos Mavrogiannopoulos wrote: > > It is important to see how protocols are perceived. For many people TLS > > 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an > > attack against TLS 1.3 with rtt, will be perceived as an attack against > > TLS 1.3 protocol. Even if the published attack against TLS 1.3 with > > 0rtt was an expected one (i.e., replay of data), if the attack impact > > is high, that may not be sufficient to stop the avalanche of bad > > publicity. In turn that will lead several people losing confidence to > > TLS 1.3 as a protocol, even TLS and the IETF process overall. > > > > My suggestion, if you need 0rtt, publish it as a different document, > > don't mix it with TLS 1.3. The security requirements from TLS are > > vastly different from the security requirements of a 0rtt protocol. > > Previous discussion seemed to land on the conclusion that semi-static DH > 0RTT should be defined in a separate document, and after this discussion > I'm beginning to agree that all stateless 0RTT should be defined as a > separate companion document to the main TLS 1.3 specification. We can > likely agree on defining a stateful 0RTT PSK resumption system which is > sufficiently safe and mistake-resistant, and we could restrict the offici= al > TLS 1.3 spec to only specify that, whilst referencing the other document = as > a more experimental feature that could be available to certain applicatio= ns > (possibly a non-standards-track document). HTTPS could then, itself, have= a > separate document laying out the necessary practices to do stateless 0RTT > safely, and other applications should be warned that without a similar su= ch > document, things are very risky. > > Is this in the ballpark of what the WG could agree on to help mitigate > some of the problems here? > As far as I can tell, there's no protocol difference between "stateful" and "stateless" resumption. You use the same techniques (a replay cache) and the question is merely whether the server actually maintains one. -Ekr > > Dave > --001a114140ba1014aa052e075bcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 12:25 PM, Dave Garrett <davemgarrett@gmai= l.com> wrote:
(This thread = has gotten long and winding, so I'm replying to these two portions bell= ow under a new subject. Reply after quotations.)

On Monday, March 14, 2016 02:38:27 pm Bill Cox wrote:
> On Mon, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
> > On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox <waywardgeek@google.com> wrote:
> >> As we all know, what matters most in security is the default = mode.=C2=A0 I am
> >> suggesting making the default 0-RTT resumption mode stateful,= with a
> >> documented session-ID (and let's bring back the timestamp= , too, since we'll
> >> need it).
> >
> > Having state would make things much more robust; but rather than = the state
> > being around the channel itself (the TLS session), would it be mo= re robust,
> > and more flexible, for the state to be around the action? like so= me kind of
> > hint cookie.
>
> It looks like server-side state is required to prevent replay.=C2=A0 I= don't
> think any kind of token, cookie, or server-config can fix this.
>
> > One of the problems with session resumption is that in order to b= e replay
> > safe; the sequence number has to restart where it left off. That = requires
> > some kind of transactional store, and if you're doing all of = this for
> > latency, you may end up eating all of the wins there.
>
> The new tickets can in theory end the debate over session caching vs > session tickets, since they can be used for database lookups or contai= n an
> encrypted session state.=C2=A0 However, the spec does not document how= to do
> session caching with tickets securely, which looks tricky.=C2=A0 In re= ality, if
> I were trying to build a speed and security sensitive site using TLS 1= .3
> stateful 0-RTT resumption, I would probably do something like this: >
> During the initial 1-RTT handshake:
> - create a ticket containing only the session ID, resumption count, an= d a
> session decryption key
> - encrypt the session cache entry with the session encryption key stor= ed in
> the ticket
> - encrypt the ticket with a semi-static ticket encryption key, which I=
> would rotate every few weeks
> - send the ticket to the client, which is after encryption is enabled = on
> the connection
>
> During a 0-RTT resume handshake:
> - check for a cache hit, and drop to 1-RTT if not found
> - decrypt the ticket with ticket the semi-static ticket decryption key=
> - decrypt the cached session state with the session key from the ticke= t
> - compare the resumption counts in the session state and ticket, and f= all
> back to 1-RTT if they do not match
> - increment the resumption count
> - create a new session ticket with a new session encryption key and th= e
> updated resumption count
> - encrypt the session cache entry with the new session encryption key<= br> > - send the client the new ticket

On Monday, March 14, 2016 08:10:32 am Nikos Mavrogiannopoulos wrote:
> It is important to see how protocols are perceived. For many people TL= S
> 1.3 with 0rtt will be the same as TLS 1.3. The first publication of an=
> attack against TLS 1.3 with rtt, will be perceived as an attack agains= t
> TLS 1.3 protocol. Even if the published attack against TLS 1.3 with > 0rtt was an expected one (i.e., replay of data), if the attack impact<= br> > is high, that may not be sufficient to stop the avalanche of bad
> publicity. In turn that will lead several people losing confidence to<= br> > TLS 1.3 as a protocol, even TLS and the IETF process overall.
>
> My suggestion, if you need 0rtt, publish it as a different document, > don't mix it with TLS 1.3. The security requirements from TLS are<= br> > vastly different from the security requirements of a 0rtt protocol.
Previous discussion seemed to land on the conclusion that semi-static DH 0R= TT should be defined in a separate document, and after this discussion I= 9;m beginning to agree that all stateless 0RTT should be defined as a separ= ate companion document to the main TLS 1.3 specification. We can likely agr= ee on defining a stateful 0RTT PSK resumption system which is sufficiently = safe and mistake-resistant, and we could restrict the official TLS 1.3 spec= to only specify that, whilst referencing the other document as a more expe= rimental feature that could be available to certain applications (possibly = a non-standards-track document). HTTPS could then, itself, have a separate = document laying out the necessary practices to do stateless 0RTT safely, an= d other applications should be warned that without a similar such document,= things are very risky.

Is this in the ballpark of what the WG could agree on to help mitigate some= of the problems here?

As far as I can = tell, there's no protocol difference between "stateful" and &= quot;stateless" resumption.
You use the same techniques (a r= eplay cache) and the question is merely whether the server
actual= ly maintains one.

-Ekr



Dave

--001a114140ba1014aa052e075bcd-- From nobody Mon Mar 14 13:17:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00A612D5B5 for ; Mon, 14 Mar 2016 13:17:10 -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, 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 xoKloyhkKNah for ; Mon, 14 Mar 2016 13:17:08 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [198.0.208.83]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6AA112D54D for ; Mon, 14 Mar 2016 13:17:08 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id 240AF33D2A6; Mon, 14 Mar 2016 20:17:07 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Ryan Hamilton References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> From: Geoffrey Keating Date: 14 Mar 2016 13:17:07 -0700 In-Reply-To: Message-ID: Lines: 22 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:17:11 -0000 Ryan Hamilton writes: > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating > wrote: >=20 > > So, I don't think HTTP is generally safe against attacker-forced > > replay, and would suggest great caution in allowing it. > > >=20 > It's worth keeping in mind this recent paper about Replay attacks against > HTTPS . > TL;DR: Attackers can already force a browser to replay requests basically > at will. =E2=80=8BAs a result, it's not clear that 0-RTT replay makes this > situation worse. The blog indicates that it's possible to cause a browser to repeat a request exactly once, within a short timeframe (probably 60 seconds or so) before the browser times out; and the browser must not see the first request succeed. That's quite different from being able to let a client make and complete a request, and then being to repeat that request thousands of times over a period of hours or longer; even if the client is a browser, it might be hard to convince it to do that. From nobody Mon Mar 14 13:43:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3EC12D732 for ; Mon, 14 Mar 2016 13:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, 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=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzWGccHqD4a7 for ; Mon, 14 Mar 2016 13:43:14 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97B6512D6D2 for ; Mon, 14 Mar 2016 13:43:14 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2EKfBdg015834; Mon, 14 Mar 2016 13:43:13 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=p2TJ9K6r+FLRNWiLY/NsPP9SOysaNeK07bBkAFNg73s=; b=nAEXsgcwULx5us4v+QUwwVlHs7Rx8vRVidZ6PLgAJuBCMh2C03TJSEh73fdPFiZxsXLl zlU9nTyzTyJU1KXstEaQgKoMgMAdSxHe6S1Iri/2hFdu9l6+aPtw2Ccyq52md0ekJ5ne CntDjd47Ms4eRYGX9rJJSMmz4GBzTxBV7m8= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21p2m810hh-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 13:43:13 -0700 Received: from PRN-MBX02-1.TheFacebook.com ([169.254.2.203]) by PRN-CHUB10.TheFacebook.com ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 13:43:12 -0700 From: Kyle Nekritz To: Martin Thomson , Erik Nygren Thread-Topic: [TLS] Limiting replay time frame of 0-RTT data Thread-Index: AdF70pHzy4ySAXIcRV+Hke2bem/g9AAzxQ6AAB0ZPQAADBwwgAAu96JQ Date: Mon, 14 Mar 2016 20:43:11 +0000 Message-ID: <8A79BFEDF6986C46996566F91BB63C860D6536DA@PRN-MBX02-1.TheFacebook.com> References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D6536DAPRNMBX021TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_06:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:43:17 -0000 --_000_8A79BFEDF6986C46996566F91BB63C860D6536DAPRNMBX021TheFac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgb3RoZXJzIGhhdmUgc2FpZCBJIGRvIHRoaW5rIGFkZGluZyBjbGllbnQgdGltZSBzb2x2ZXMg bXVjaCBtb3JlIHRoYW4ganVzdCB0aGlzIHNwZWNpZmljIGlzc3VlLiBSdW5uaW5nIGEgY2xpZW50 IG5vbmNlIGNhY2hlIGF0IHNjYWxlIGFsc28gbGlrZWx5IHJlcXVpcmVzIGNsaWVudCB0aW1lIGlu IG9yZGVyIHRvIGxpbWl0IHRoZSBzdG9yYWdlIG5lZWRlZCB0byBhIHJlYXNvbmFibGUgYW1vdW50 Lg0KDQpJIGxpa2UgdGhlIGlkZWEgb2YgaW5jbHVkaW5nIHRpbWUgc2luY2UgcmVjZWl2aW5nIHRo ZSBzZXNzaW9uIHRpY2tldCBpbnN0ZWFkIG9mIGFic29sdXRlIHRpbWUuIFRoaXMgYWxsb3dzIGZv ciBjbGllbnRzIHdpdGggaGlnaCBjbG9jayBza2V3IGJ1dCBzdGlsbCBhbiBhY2N1cmF0ZSBzdGVh ZHkgY2xvY2sgdG8gdXNlIDAtUlRULCBhbmQgbGlrZWx5IGZvciB0aWdodGVyIGJvdW5kcyB0byBi ZSBwbGFjZWQgb24gdGhlIHRpbWUuICBUaGUgbmF0dXJhbCBwbGFjZSB0byBwdXQgdGhpcyB3b3Vs ZCBiZSB0aGUgY2xpZW50IGhlbGxvLCB3aGVyZSBpdCB3b3VsZCBiZSB1bmVuY3J5cHRlZCwgd2hp Y2ggd291bGQgbGVhayB0aGUgdGltZSBvZiB0aWNrZXQgaXNzdWFuY2UuIEhvdyBjb25jZXJuaW5n IGlzIHRoaXMsIGlzIGl0IHdvcnRoIGVuY3J5cHRpbmcgdGhpcyB0aW1lPw0KDQpLeWxlDQoNCkZy b206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGlu IFRob21zb24NClNlbnQ6IFN1bmRheSwgTWFyY2ggMTMsIDIwMTYgNTozNiBBTQ0KVG86IEVyaWsg TnlncmVuIDxlcmlrK2lldGZAbnlncmVuLm9yZz4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbVExTXSBMaW1pdGluZyByZXBsYXkgdGltZSBmcmFtZSBvZiAwLVJUVCBkYXRhDQoNCg0K SSBhc3N1bWUgdGhhdCB5b3Ugd291bGQgcnVuIGEgdGlnaHQgdG9sZXJhbmNlIG9uIHRoZSAwUlRU IHJlc3VtcHRpb24gYnkgc2F2aW5nIHRoZSBjbGllbnQncyBjbG9jayBlcnJvciBpbiB0aGUgdGlj a2V0LiAgVGhhdCBhIHdheSBvbmx5IGNsaWVudHMgd2l0aCBiYWQgZHJpZnQgZ2V0IG5vIDBSVFQu IFRvIGRvIHRoYXQgYWxsIHNlc3Npb25zIG5lZWQgdGltZS4NCg0KSSBkbyBub3Qgc2VlIGhvdyB0 aGUgc2VydmVyIGNhbiBkbyB0aGlzIGluIGdlbmVyYWwgd2l0aG91dCBjbGllbnQgaGVscC4gQnV0 IHRoZSBzb2x1dGlvbiBhbHNvIGFkZHJlc3NlcyBCcmlhbidzIGNvbmNlcm4uIFRoZSBjbGllbnQg ZG9lc24ndCBuZWVkIGFic29sdXRlIHRpbWUsIGp1c3QgcmVsYXRpdmUgdGltZTogSG93IGxvbmcg c2luY2UgdGhlIHRpY2tldCB3YXMgaXNzdWVkLiBUaGVuIGl0J3MgYW4gYWRkaXRpb24gdG8gdGhl IHBza19pZGVudGl0eSBvbmx5Lg0KT24gMTMgTWFyIDIwMTYgMTo0OSBQTSwgIkVyaWsgTnlncmVu IiA8ZXJpaytpZXRmQG55Z3Jlbi5vcmc8bWFpbHRvOmVyaWslMkJpZXRmQG55Z3Jlbi5vcmc+PiB3 cm90ZToNClRoYXQgZG9lcyBzZWVtIGxpa2UgYSBnb29kIGlkZWEgdG8gaW5jbHVkZSBhIGNsaWVu dCB0aW1lIHN0YW1wIGluIHRoZSAwUlRUIGZsb3cgdG8gbGV0IHRoZSBzZXJ2ZXIgZm9yY2UgMVJU VCBpbiB0aGUgY2FzZSB3aGVyZSB0aGlzIGlzIHRvbyBmYXIgb2ZmIGFzIHRoaXMgYm91bmRzIHRo ZSBkdXJhdGlvbiBvZiB0aGUgcmVwbGF5IHdpbmRvdy4gIChJIHN1c3BlY3Qgd2UnbGwgZmluZCBh IHdob2xlIHJhbmdlIG9mIG90aGVyIHNpbWlsYXIgYXR0YWNrcyB1c2luZyAwUlRULikgIEFuIGVu Y3J5cHRlZCBjbGllbnQgdGltZXN0YW1wIGNvdWxkIHByZXN1bWFibHkgYmUgcHJvYmVkIGJ5IHRo ZSBzZXJ2ZXIuICAoaWUsIGlmIHRoZSBzZXJ2ZXIgcmVzcG9uc2UgaXMgYSBkaWZmZXJlbnQgc2l6 ZSBmb3IgdGltZXN0YW1wLWV4cGlyZWQgdnMgdGltZXN0YW1wLW5vdC1leHBpcmVkIGFuIGF0dGFj a2VyIGNvdWxkIGtlZXAgcHJvYmluZyB1bnRpbCB0aGV5IGNoYW5nZT8pICBUaGF0IGRvZXMgc2Vl bSBsaWtlIG1vcmUgZWZmb3J0LCBob3dldmVyLg0KICAgICAgICAgICBFcmlrDQoNCk9uIFNhdCwg TWFyIDEyLCAyMDE2IGF0IDc6NTYgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWls dG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpIaSBLeWxlLA0KDQpDbGV2ZXIgYXR0YWNrLiBJIGRv bid0IHRoaW5rIGl0IHdvdWxkIGJlIHVucmVhc29uYWJsZSB0byBwdXQgYSBsb3cgZ3JhbnVsYXJp dHkgdGltZSBzdGFtcCBpbiB0aGUNCkNsaWVudEhlbGxvIChhbmQgYXMgeW91IG9ic2VydmUsIGlm IHdlIGp1c3QgZGVmaW5lIGl0IGl0IGNhbiBiZSBkb25lIGJhY2t3YXJkIGNvbXBhdGlibHkpDQpv ciBhcyB5b3Ugc3VnZ2VzdCwgaW4gYW4gZW5jcnlwdGVkIGJsb2NrLiBXaXRoIHRoYXQgc2FpZCwg dGhvdWdoIGNvdWxkbid0IHlvdQ0KYWxzbyBqdXN0IGluY2x1ZGUgdGhlIGluZm9ybWF0aW9uIGlu IHRoZSBIVFRQIGhlYWRlciBmb3IgSFRUUD8gRG8geW91IHRoaW5rIHRoaXMgaXMgYSBzdWZmaWNp ZW50bHkNCmdlbmVyYWwgaXNzdWUgdGhhdCBpdCBtZXJpdHMgYSBjaGFuZ2UgdG8gVExTLg0KDQot RWtyDQoNCg0KT24gRnJpLCBNYXIgMTEsIDIwMTYgYXQgOToyMSBQTSwgS3lsZSBOZWtyaXR6IDxr bmVrcml0ekBmYi5jb208bWFpbHRvOmtuZWtyaXR6QGZiLmNvbT4+IHdyb3RlOg0KU2ltaWxhciB0 byB0aGUgZWFybGllciBkaXNjdXNzaW9uIG9uIDAuNS1SVFQgZGF0YSwgSeKAmW0gY29uY2VybmVk IHdpdGggdGhlIGxvbmcgdGVybSBhYmlsaXR5IHRvIHJlcGxheSBjYXB0dXJlZCAwLVJUVCBlYXJs eSBkYXRhLCBhbmQgdGhlIGF0dGFjayB2ZWN0b3JzIHRoYXQgaXQgb3BlbnMgdXAuIEZvciBleGFt cGxlLCB0YWtlIGEgR0VUIHJlcXVlc3QgZm9yIGFuIGltYWdlIHRvIGEgQ0ROLiBUaGlzIGlzIGEg cmVxdWVzdCB0aGF0IHNlZW1zIGNvbXBsZXRlbHkgaWRlbXBvdGVudCwgYW5kIHRoYXQgYXBwbGlj YXRpb25zIHdpbGwgc3VyZWx5IHdhbnQgdG8gc2VuZCBhcyAwLVJUVCBkYXRhLiBIb3dldmVyLCB0 aGlzIHJlcXVlc3QgY2FuIHJlc3VsdCBpbiBhIGZldyB0aGluZ3MgaGFwcGVuaW5nOg0KICAgIDEp IFJlc291cmNlIHVuYXZhaWxhYmxlDQogICAgMikgUmVzb3VyY2UgY2FjaGVkIGxvY2FsbHkgYXQg ZWRnZSBjbHVzdGVyDQogICAgMykgQ2FjaGUgbWlzcywgcmVzb3VyY2UgbXVzdCBiZSBmZXRjaGVk IGZyb20gb3JpZ2luIGRhdGEgY2VudGVyDQojMSBjYW4gZWFzaWx5IGJlIGRpZmZlcmVudGlhdGVk IGJ5IHRoZSBsZW5ndGggb2YgdGhlIDAuNS1SVFQgcmVzcG9uc2UgZGF0YSwgYWxsb3dpbmcgYW4g YXR0YWNrZXIgdG8gZGV0ZXJtaW5lIHdoZW4gYSByZXNvdXJjZSBoYXMgYmVlbiBkZWxldGVkL21v ZGlmaWVkLiAjMiBhbmQgIzMgY2FuIGFsc28gYmUgZWFzaWx5IGRpZmZlcmVudGlhdGVkIGJ5IHRo ZSB0aW1pbmcgb2YgdGhlIHJlc3BvbnNlLiBUaGlzIG9wZW5zIHVwIHRoZSBmb2xsb3dpbmcgYXR0 YWNrOiBpZiBhbiBhdHRhY2tlciBrbm93cyBhIGNsaWVudCBoYXMgcmVxdWVzdGVkIGEgcmVzb3Vy Y2UgWF9pIGluIHRoZSBhdHRhY2tlci1rbm93biBzZXQge1hfMSwgWF8yLCAuLi4sIFhfbn0sIGFu IGF0dGFja2VyIGNhbiBkbyB0aGUgZm9sbG93aW5nOg0KICAgIDEpIHdhaXQgZm9yIHRoZSBDRE4g Y2FjaGUgdG8gYmUgZXZpY3RlZA0KICAgIDIpIHJlcXVlc3Qge1hfMSwgWF8yLCDigKYsIFhfKG4v Mil9IHRvIHdhcm0gdGhlIGNhY2hlDQogICAgMykgcmVwbGF5IHRoZSBjYXB0dXJlZCBjbGllbnQg ZWFybHkgZGF0YSAodGhlIHJlcXVlc3QgZm9yIFhfaSkNCiAgICA0KSBkZXRlcm1pbmUsIGJhc2Vk IG9uIHRoZSB0aW1pbmcgb2YgdGhlIHJlc3BvbnNlLCB3aGV0aGVyIGl0IHJlc3VsdGVkIGluIGEg Y2FjaGUgaGl0IG9yIG1pc3MNCiAgICA1KSByZXBlYXQgd2l0aCBzZXQge1hfMSwgWF8yLCDigKYs IFhfKG4vMil9IG9yIHtYXyhuLzIgKyAxKSwgWF8obi8yICsgMiksIOKApiwgWF9ufSBkZXBlbmRp bmcgb24gdGhlIHJlc3VsdA0KVGhpcyBwYXJ0aWN1bGFyIGJpbmFyeSBzZWFyY2ggZXhhbXBsZSBp cyBhIGxpdHRsZSBjb250cml2ZWQgYW5kIHJlcXVpcmVzIHRoYXQgbm8tb25lIGVsc2UgaXMgcmVx dWVzdGluZyBhbnkgcmVzb3VyY2UgaW4gdGhlIHNldCwgaG93ZXZlciBJIHRoaW5rIGl0IGlzIHJl cHJlc2VudGF0aXZlIG9mIGEgc2lnbmlmaWNhbnQgbmV3IGF0dGFjayB2ZWN0b3IgdGhhdCBhbGxv d2luZyBsb25nLXRlcm0gcmVwbGF5IG9mIGNhcHR1cmVkIGVhcmx5IGRhdGEgd2lsbCBvcGVuIHVw LCBldmVuIGlmIDAtUlRUIGlzIG9ubHkgdXNlZCBmb3Igc2VlbWluZ2x5IHNpbXBsZSByZXF1ZXN0 cyB3aXRob3V0IFRMUyBjbGllbnQgYXV0aGVudGljYXRpb24uIFRoaXMgaXMgYSBtdWNoIGRpZmZl cmVudCB0aHJlYXQgdGhhbiB2ZXJ5IHNob3J0LXRlcm0gcmVwbGF5LCB3aGljaCBpcyBhbHJlYWR5 IHNvbWV3aGF0IHBvc3NpYmxlIG9uIGFueSBUTFMgcHJvdG9jb2wgaWYgY2xpZW50cyByZXRyeSBm YWlsZWQgcmVxdWVzdHMuDQoNCkdpdmVuIHRoaXMsIEkgdGhpbmsgaXQgaXMgd29ydGggYXR0ZW1w dGluZyB0byBsaW1pdCB0aGUgdGltZSBmcmFtZSB0aGF0IGNhcHR1cmVkIGVhcmx5IGRhdGEgaXMg dXNlZnVsIHRvIGFuIGF0dGFja2VyLiBUaGlzIG9idmlvdXNseSBkb2VzbuKAmXQgcHJldmVudCBy ZXBsYXksIGJ1dCBpdCBjYW4gbWl0aWdhdGUgYSBsb3Qgb2YgYXR0YWNrcyB0aGF0IGxvbmctdGVy bSByZXBsYXkgd291bGQgb3BlbiB1cC4gVGhpcyBjYW4gYmUgZG9uZSBieSBpbmNsdWRpbmcgYSBj bGllbnQgdGltZSBzdGFtcCBhbG9uZyB3aXRoIGVhcmx5IGRhdGEsIHNvIHRoYXQgc2VydmVycyBj YW4gY2hvb3NlIHRvIGVpdGhlciBpZ25vcmUgdGhlIGVhcmx5IGRhdGEsIG9yIHRvIGRlbGF5IHRo ZSAwLjUtUlRUIHJlc3BvbnNlIHRvIDEuNS1SVFQgaWYgdGhlIHRpbWUgc3RhbXAgaXMgZmFyIG9m Zi4gVGhpcyBjdXRzIGRvd24gdGhlIHRpbWUgZnJvbSBkYXlzICh1bnRpbCB0aGUgc2VydmVyIGNv bmZpZy9zZXNzaW9uIHRpY2tldCBrZXkgaXMgcm90YXRlZCkgdG8gbWludXRlcyBvciBzZWNvbmRz Lg0KDQpJbmNsdWRpbmcgdGhlIGNsaWVudCB0aW1lIGFsc28gbWFrZXMgYSBjbGllbnQgcmFuZG9t IHN0cmlrZSByZWdpc3RlciBwb3NzaWJsZSB3aXRob3V0IHJlcXVpcmluZyBhbiB1bnJlYXNvbmFi bHkgbGFyZ2UgYW1vdW50IG9mIHNlcnZlci1zaWRlIHN0YXRlLg0KDQpJIGFtIGF3YXJlIHRoYXQg Y2xpZW50IHRpbWUgaGFkIHByZXZpb3VzbHkgYmVlbiByZW1vdmVkIGZyb20gdGhlIGNsaWVudCBy YW5kb20sIHByaW1hcmlseSBkdWUgdG8gZmluZ2VycHJpbnRpbmcgY29uY2VybnMsIGhvd2V2ZXIg dGhlc2UgY29uY2VybnMgY2FuIGJlIG1pdGlnYXRlZCBieQ0KMSkgY2xpZW50cyBjYW4gY2hvb3Nl IHRvIG5vdCBpbmNsdWRlIHRoZWlyIHRpbWUgKG9yIHRvIGluY2x1ZGUgYSByYW5kb20gdGltZSks IHdpdGggb25seSB0aGUgcmlzayBvZiB0aGVpciAuNS1SVFQgZGF0YSBiZWluZyBkZWxheWVkDQoy KSBwbGFjaW5nIHRoZSB0aW1lIHN0YW1wIGluIGFuIGVuY3J5cHRlZCBleHRlbnNpb24sIHNvIHRo YXQgaXQgaXMgbm90IHZpc2libGUgdG8gZWF2ZXNkcm9wcGVycw0KDQoNCk5vdGU6IGl04oCZcyBh bHNvIHVzZWZ1bCBmb3IgdGhlIHNlcnZlciB0byBrbm93IHdoaWNoIGVkZ2UgY2x1c3RlciB0aGUg ZWFybHkgZGF0YSB3YXMgaW50ZW5kZWQgZm9yLCBob3dldmVyIHRoaXMgaXMgYWxyZWFkeSBwb3Nz aWJsZSBpbiB0aGUgY3VycmVudCBkcmFmdC4gSW4gRUNESEUgMC1SVFQgc2VydmVyIGNvbmZpZ3Mg Y2FuIGJlIHNlZ21lbnRlZCBieSBjbHVzdGVyLCBhbmQgd2l0aCB0aWNrZXRzLCB0aGUgc2VydmVy IGNhbiBzdG9yZSBjbHVzdGVyIGluZm9ybWF0aW9uIGluIHRoZSBvcGFxdWUgdGlja2V0Lg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxp bmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3Rs cyZkPUN3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1sMmo0QmprTzBMYzN1NENIMno3 alB3Jm09aEtpUUtBVm5fR0ZRaUtOdHlQcE81U1c2QmpNVE5WMGpmNm5iN3FkSXF4QSZzPXcxa3lY NF82NkxlaGpXZnk1LTYyNVg4TVU4VFg5SlRTUkljZ1RsVTZpcUEmZT0+DQoNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QN ClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmZD1Dd01G YVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZtPWhL aVFLQVZuX0dGUWlLTnR5UHBPNVNXNkJqTVROVjBqZjZuYjdxZElxeEEmcz13MWt5WDRfNjZMZWhq V2Z5NS02MjVYOE1VOFRYOUpUU1JJY2dUbFU2aXFBJmU9Pg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0 Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGxzJmQ9Q3dNRmFRJmM9NVZE MFJUdE5sVGgzeWNkNDFiM01VdyZyPWwyajRCamtPMExjM3U0Q0gyejdqUHcmbT1oS2lRS0FWbl9H RlFpS050eVBwTzVTVzZCak1UTlYwamY2bmI3cWRJcXhBJnM9dzFreVg0XzY2TGVoaldmeTUtNjI1 WDhNVThUWDlKVFNSSWNnVGxVNmlxQSZlPT4NCg== --_000_8A79BFEDF6986C46996566F91BB63C860D6536DAPRNMBX021TheFac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgb3Ro ZXJzIGhhdmUgc2FpZCBJIGRvIHRoaW5rIGFkZGluZyBjbGllbnQgdGltZSBzb2x2ZXMgbXVjaCBt b3JlIHRoYW4ganVzdCB0aGlzIHNwZWNpZmljIGlzc3VlLiBSdW5uaW5nIGEgY2xpZW50IG5vbmNl IGNhY2hlIGF0IHNjYWxlIGFsc28gbGlrZWx5IHJlcXVpcmVzIGNsaWVudCB0aW1lIGluDQogb3Jk ZXIgdG8gbGltaXQgdGhlIHN0b3JhZ2UgbmVlZGVkIHRvIGEgcmVhc29uYWJsZSBhbW91bnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgbGlrZSB0aGUgaWRlYSBvZiBpbmNsdWRpbmcgdGltZSBzaW5jZSByZWNl aXZpbmcgdGhlIHNlc3Npb24gdGlja2V0IGluc3RlYWQgb2YgYWJzb2x1dGUgdGltZS4gVGhpcyBh bGxvd3MgZm9yIGNsaWVudHMgd2l0aCBoaWdoIGNsb2NrIHNrZXcgYnV0IHN0aWxsIGFuIGFjY3Vy YXRlIHN0ZWFkeSBjbG9jaw0KIHRvIHVzZSAwLVJUVCwgYW5kIGxpa2VseSBmb3IgdGlnaHRlciBi b3VuZHMgdG8gYmUgcGxhY2VkIG9uIHRoZSB0aW1lLiZuYnNwOyBUaGUgbmF0dXJhbCBwbGFjZSB0 byBwdXQgdGhpcyB3b3VsZCBiZSB0aGUgY2xpZW50IGhlbGxvLCB3aGVyZSBpdCB3b3VsZCBiZSB1 bmVuY3J5cHRlZCwgd2hpY2ggd291bGQgbGVhayB0aGUgdGltZSBvZiB0aWNrZXQgaXNzdWFuY2Uu IEhvdyBjb25jZXJuaW5nIGlzIHRoaXMsIGlzIGl0IHdvcnRoIGVuY3J5cHRpbmcgdGhpcw0KIHRp bWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkt5bGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPk1hcnRpbiBUaG9tc29uPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgTWFyY2ggMTMsIDIw MTYgNTozNiBBTTxicj4NCjxiPlRvOjwvYj4gRXJpayBOeWdyZW4gJmx0O2VyaWsmIzQzO2lldGZA bnlncmVuLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1RMU10gTGltaXRpbmcgcmVwbGF5IHRpbWUgZnJhbWUgb2YgMC1SVFQgZGF0 YTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHA+SSBhc3N1bWUgdGhhdCB5b3Ugd291bGQgcnVuIGEgdGlnaHQgdG9sZXJh bmNlIG9uIHRoZSAwUlRUIHJlc3VtcHRpb24gYnkgc2F2aW5nIHRoZSBjbGllbnQncyBjbG9jayBl cnJvciBpbiB0aGUgdGlja2V0LiZuYnNwOyBUaGF0IGEgd2F5IG9ubHkgY2xpZW50cyB3aXRoIGJh ZCBkcmlmdCBnZXQgbm8gMFJUVC4gVG8gZG8gdGhhdCBhbGwgc2Vzc2lvbnMgbmVlZCB0aW1lLg0K PG86cD48L286cD48L3A+DQo8cD5JIGRvIG5vdCBzZWUgaG93IHRoZSBzZXJ2ZXIgY2FuIGRvIHRo aXMgaW4gZ2VuZXJhbCB3aXRob3V0IGNsaWVudCBoZWxwLiBCdXQgdGhlIHNvbHV0aW9uIGFsc28g YWRkcmVzc2VzIEJyaWFuJ3MgY29uY2Vybi4gVGhlIGNsaWVudCBkb2Vzbid0IG5lZWQgYWJzb2x1 dGUgdGltZSwganVzdCByZWxhdGl2ZSB0aW1lOiBIb3cgbG9uZyBzaW5jZSB0aGUgdGlja2V0IHdh cyBpc3N1ZWQuIFRoZW4gaXQncyBhbiBhZGRpdGlvbiB0byB0aGUgcHNrX2lkZW50aXR5DQogb25s eS4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTMgTWFy IDIwMTYgMTo0OSBQTSwgJnF1b3Q7RXJpayBOeWdyZW4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzplcmlrJTJCaWV0ZkBueWdyZW4ub3JnIj5lcmlrJiM0MztpZXRmQG55Z3Jlbi5vcmc8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoYXQgZG9lcyBzZWVtIGxpa2UgYSBnb29kIGlkZWEg dG8gaW5jbHVkZSBhIGNsaWVudCB0aW1lIHN0YW1wIGluIHRoZSAwUlRUIGZsb3cgdG8gbGV0IHRo ZSBzZXJ2ZXIgZm9yY2UgMVJUVCBpbiB0aGUgY2FzZSB3aGVyZSB0aGlzIGlzIHRvbyBmYXIgb2Zm IGFzIHRoaXMgYm91bmRzIHRoZSBkdXJhdGlvbiBvZiB0aGUgcmVwbGF5IHdpbmRvdy4mbmJzcDsg KEkgc3VzcGVjdA0KIHdlJ2xsIGZpbmQgYSB3aG9sZSByYW5nZSBvZiBvdGhlciBzaW1pbGFyIGF0 dGFja3MgdXNpbmcgMFJUVC4pJm5ic3A7IEFuIGVuY3J5cHRlZCBjbGllbnQgdGltZXN0YW1wIGNv dWxkIHByZXN1bWFibHkgYmUgcHJvYmVkIGJ5IHRoZSBzZXJ2ZXIuJm5ic3A7IChpZSwgaWYgdGhl IHNlcnZlciByZXNwb25zZSBpcyBhIGRpZmZlcmVudCBzaXplIGZvciB0aW1lc3RhbXAtZXhwaXJl ZCB2cyB0aW1lc3RhbXAtbm90LWV4cGlyZWQgYW4gYXR0YWNrZXIgY291bGQga2VlcCBwcm9iaW5n DQogdW50aWwgdGhleSBjaGFuZ2U/KSZuYnNwOyBUaGF0IGRvZXMgc2VlbSBsaWtlIG1vcmUgZWZm b3J0LCBob3dldmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBFcmlrPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTYXQsIE1hciAxMiwgMjAxNiBhdCA3OjU2 IEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBLeWxlLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Q2xldmVyIGF0dGFjay4gSSBkb24ndCB0aGluayBpdCB3b3VsZCBi ZSB1bnJlYXNvbmFibGUgdG8gcHV0IGEgbG93IGdyYW51bGFyaXR5IHRpbWUgc3RhbXAgaW4gdGhl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DbGll bnRIZWxsbyAoYW5kIGFzIHlvdSBvYnNlcnZlLCBpZiB3ZSBqdXN0IGRlZmluZSBpdCBpdCBjYW4g YmUgZG9uZSBiYWNrd2FyZCBjb21wYXRpYmx5KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b3IgYXMgeW91IHN1Z2dlc3QsIGluIGFuIGVuY3J5cHRl ZCBibG9jay4gV2l0aCB0aGF0IHNhaWQsIHRob3VnaCBjb3VsZG4ndCB5b3U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFsc28ganVzdCBpbmNsdWRl IHRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgSFRUUCBoZWFkZXIgZm9yIEhUVFA/IERvIHlvdSB0aGlu ayB0aGlzIGlzIGEgc3VmZmljaWVudGx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5nZW5lcmFsIGlzc3VlIHRoYXQgaXQgbWVyaXRzIGEgY2hhbmdl IHRvIFRMUy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBNYXIgMTEsIDIwMTYgYXQgOToyMSBQTSwg S3lsZSBOZWtyaXR6ICZsdDs8YSBocmVmPSJtYWlsdG86a25la3JpdHpAZmIuY29tIiB0YXJnZXQ9 Il9ibGFuayI+a25la3JpdHpAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5TaW1pbGFyIHRvIHRoZSBlYXJsaWVyIGRpc2N1c3Npb24gb24gMC41LVJUVCBkYXRhLCBJ4oCZ bSBjb25jZXJuZWQgd2l0aCB0aGUgbG9uZyB0ZXJtIGFiaWxpdHkgdG8gcmVwbGF5IGNhcHR1cmVk IDAtUlRUIGVhcmx5IGRhdGEsIGFuZCB0aGUgYXR0YWNrIHZlY3RvcnMgdGhhdCBpdCBvcGVucyB1 cC4gRm9yIGV4YW1wbGUsDQogdGFrZSBhIEdFVCByZXF1ZXN0IGZvciBhbiBpbWFnZSB0byBhIENE Ti4gVGhpcyBpcyBhIHJlcXVlc3QgdGhhdCBzZWVtcyBjb21wbGV0ZWx5IGlkZW1wb3RlbnQsIGFu ZCB0aGF0IGFwcGxpY2F0aW9ucyB3aWxsIHN1cmVseSB3YW50IHRvIHNlbmQgYXMgMC1SVFQgZGF0 YS4gSG93ZXZlciwgdGhpcyByZXF1ZXN0IGNhbiByZXN1bHQgaW4gYSBmZXcgdGhpbmdzIGhhcHBl bmluZzo8YnI+DQombmJzcDsgJm5ic3A7Jm5ic3A7MSkgUmVzb3VyY2UgdW5hdmFpbGFibGU8YnI+ DQombmJzcDsgJm5ic3A7Jm5ic3A7MikgUmVzb3VyY2UgY2FjaGVkIGxvY2FsbHkgYXQgZWRnZSBj bHVzdGVyPGJyPg0KJm5ic3A7ICZuYnNwOyZuYnNwOzMpIENhY2hlIG1pc3MsIHJlc291cmNlIG11 c3QgYmUgZmV0Y2hlZCBmcm9tIG9yaWdpbiBkYXRhIGNlbnRlcjxicj4NCiMxIGNhbiBlYXNpbHkg YmUgZGlmZmVyZW50aWF0ZWQgYnkgdGhlIGxlbmd0aCBvZiB0aGUgMC41LVJUVCByZXNwb25zZSBk YXRhLCBhbGxvd2luZyBhbiBhdHRhY2tlciB0byBkZXRlcm1pbmUgd2hlbiBhIHJlc291cmNlIGhh cyBiZWVuIGRlbGV0ZWQvbW9kaWZpZWQuICMyIGFuZCAjMyBjYW4gYWxzbyBiZSBlYXNpbHkgZGlm ZmVyZW50aWF0ZWQgYnkgdGhlIHRpbWluZyBvZiB0aGUgcmVzcG9uc2UuIFRoaXMgb3BlbnMgdXAg dGhlIGZvbGxvd2luZyBhdHRhY2s6DQogaWYgYW4gYXR0YWNrZXIga25vd3MgYSBjbGllbnQgaGFz IHJlcXVlc3RlZCBhIHJlc291cmNlIFhfaSBpbiB0aGUgYXR0YWNrZXIta25vd24gc2V0IHtYXzEs IFhfMiwgLi4uLCBYX259LCBhbiBhdHRhY2tlciBjYW4gZG8gdGhlIGZvbGxvd2luZzo8YnI+DQom bmJzcDsgJm5ic3A7Jm5ic3A7MSkgd2FpdCBmb3IgdGhlIENETiBjYWNoZSB0byBiZSBldmljdGVk PGJyPg0KJm5ic3A7ICZuYnNwOyZuYnNwOzIpIHJlcXVlc3Qge1hfMSwgWF8yLCDigKYsIFhfKG4v Mil9IHRvIHdhcm0gdGhlIGNhY2hlPGJyPg0KJm5ic3A7ICZuYnNwOyZuYnNwOzMpIHJlcGxheSB0 aGUgY2FwdHVyZWQgY2xpZW50IGVhcmx5IGRhdGEgKHRoZSByZXF1ZXN0IGZvciBYX2kpPGJyPg0K Jm5ic3A7ICZuYnNwOyZuYnNwOzQpIGRldGVybWluZSwgYmFzZWQgb24gdGhlIHRpbWluZyBvZiB0 aGUgcmVzcG9uc2UsIHdoZXRoZXIgaXQgcmVzdWx0ZWQgaW4gYSBjYWNoZSBoaXQgb3IgbWlzczxi cj4NCiZuYnNwOyAmbmJzcDsmbmJzcDs1KSByZXBlYXQgd2l0aCBzZXQge1hfMSwgWF8yLCDigKYs IFhfKG4vMil9IG9yIHtYXyhuLzIgJiM0MzsgMSksIFhfKG4vMiAmIzQzOyAyKSwg4oCmLCBYX259 IGRlcGVuZGluZyBvbiB0aGUgcmVzdWx0PGJyPg0KVGhpcyBwYXJ0aWN1bGFyIGJpbmFyeSBzZWFy Y2ggZXhhbXBsZSBpcyBhIGxpdHRsZSBjb250cml2ZWQgYW5kIHJlcXVpcmVzIHRoYXQgbm8tb25l IGVsc2UgaXMgcmVxdWVzdGluZyBhbnkgcmVzb3VyY2UgaW4gdGhlIHNldCwgaG93ZXZlciBJIHRo aW5rIGl0IGlzIHJlcHJlc2VudGF0aXZlIG9mIGEgc2lnbmlmaWNhbnQgbmV3IGF0dGFjayB2ZWN0 b3IgdGhhdCBhbGxvd2luZyBsb25nLXRlcm0gcmVwbGF5IG9mIGNhcHR1cmVkIGVhcmx5IGRhdGEg d2lsbA0KIG9wZW4gdXAsIGV2ZW4gaWYgMC1SVFQgaXMgb25seSB1c2VkIGZvciBzZWVtaW5nbHkg c2ltcGxlIHJlcXVlc3RzIHdpdGhvdXQgVExTIGNsaWVudCBhdXRoZW50aWNhdGlvbi4gVGhpcyBp cyBhIG11Y2ggZGlmZmVyZW50IHRocmVhdCB0aGFuIHZlcnkgc2hvcnQtdGVybSByZXBsYXksIHdo aWNoIGlzIGFscmVhZHkgc29tZXdoYXQgcG9zc2libGUgb24gYW55IFRMUyBwcm90b2NvbCBpZiBj bGllbnRzIHJldHJ5IGZhaWxlZCByZXF1ZXN0cy48YnI+DQo8YnI+DQpHaXZlbiB0aGlzLCBJIHRo aW5rIGl0IGlzIHdvcnRoIGF0dGVtcHRpbmcgdG8gbGltaXQgdGhlIHRpbWUgZnJhbWUgdGhhdCBj YXB0dXJlZCBlYXJseSBkYXRhIGlzIHVzZWZ1bCB0byBhbiBhdHRhY2tlci4gVGhpcyBvYnZpb3Vz bHkgZG9lc27igJl0IHByZXZlbnQgcmVwbGF5LCBidXQgaXQgY2FuIG1pdGlnYXRlIGEgbG90IG9m IGF0dGFja3MgdGhhdCBsb25nLXRlcm0gcmVwbGF5IHdvdWxkIG9wZW4gdXAuIFRoaXMgY2FuIGJl IGRvbmUgYnkgaW5jbHVkaW5nDQogYSBjbGllbnQgdGltZSBzdGFtcCBhbG9uZyB3aXRoIGVhcmx5 IGRhdGEsIHNvIHRoYXQgc2VydmVycyBjYW4gY2hvb3NlIHRvIGVpdGhlciBpZ25vcmUgdGhlIGVh cmx5IGRhdGEsIG9yIHRvIGRlbGF5IHRoZSAwLjUtUlRUIHJlc3BvbnNlIHRvIDEuNS1SVFQgaWYg dGhlIHRpbWUgc3RhbXAgaXMgZmFyIG9mZi4gVGhpcyBjdXRzIGRvd24gdGhlIHRpbWUgZnJvbSBk YXlzICh1bnRpbCB0aGUgc2VydmVyIGNvbmZpZy9zZXNzaW9uIHRpY2tldCBrZXkgaXMNCiByb3Rh dGVkKSB0byBtaW51dGVzIG9yIHNlY29uZHMuPGJyPg0KPGJyPg0KSW5jbHVkaW5nIHRoZSBjbGll bnQgdGltZSBhbHNvIG1ha2VzIGEgY2xpZW50IHJhbmRvbSBzdHJpa2UgcmVnaXN0ZXIgcG9zc2li bGUgd2l0aG91dCByZXF1aXJpbmcgYW4gdW5yZWFzb25hYmx5IGxhcmdlIGFtb3VudCBvZiBzZXJ2 ZXItc2lkZSBzdGF0ZS48YnI+DQo8YnI+DQpJIGFtIGF3YXJlIHRoYXQgY2xpZW50IHRpbWUgaGFk IHByZXZpb3VzbHkgYmVlbiByZW1vdmVkIGZyb20gdGhlIGNsaWVudCByYW5kb20sIHByaW1hcmls eSBkdWUgdG8gZmluZ2VycHJpbnRpbmcgY29uY2VybnMsIGhvd2V2ZXIgdGhlc2UgY29uY2VybnMg Y2FuIGJlIG1pdGlnYXRlZCBieTxicj4NCjEpIGNsaWVudHMgY2FuIGNob29zZSB0byBub3QgaW5j bHVkZSB0aGVpciB0aW1lIChvciB0byBpbmNsdWRlIGEgcmFuZG9tIHRpbWUpLCB3aXRoIG9ubHkg dGhlIHJpc2sgb2YgdGhlaXIgLjUtUlRUIGRhdGEgYmVpbmcgZGVsYXllZDxicj4NCjIpIHBsYWNp bmcgdGhlIHRpbWUgc3RhbXAgaW4gYW4gZW5jcnlwdGVkIGV4dGVuc2lvbiwgc28gdGhhdCBpdCBp cyBub3QgdmlzaWJsZSB0byBlYXZlc2Ryb3BwZXJzPGJyPg0KPGJyPg0KPGJyPg0KTm90ZTogaXTi gJlzIGFsc28gdXNlZnVsIGZvciB0aGUgc2VydmVyIHRvIGtub3cgd2hpY2ggZWRnZSBjbHVzdGVy IHRoZSBlYXJseSBkYXRhIHdhcyBpbnRlbmRlZCBmb3IsIGhvd2V2ZXIgdGhpcyBpcyBhbHJlYWR5 IHBvc3NpYmxlIGluIHRoZSBjdXJyZW50IGRyYWZ0LiBJbiBFQ0RIRSAwLVJUVCBzZXJ2ZXIgY29u ZmlncyBjYW4gYmUgc2VnbWVudGVkIGJ5IGNsdXN0ZXIsIGFuZCB3aXRoIHRpY2tldHMsIHRoZSBz ZXJ2ZXIgY2FuIHN0b3JlIGNsdXN0ZXINCiBpbmZvcm1hdGlvbiBpbiB0aGUgb3BhcXVlIHRpY2tl dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmYW1wO2Q9Q3dNRmFRJmFt cDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZh bXA7bT1oS2lRS0FWbl9HRlFpS050eVBwTzVTVzZCak1UTlYwamY2bmI3cWRJcXhBJmFtcDtzPXcx a3lYNF82NkxlaGpXZnk1LTYyNVg4TVU4VFg5SlRTUkljZ1RsVTZpcUEmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpUTFNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5UTFNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmYW1wO2Q9Q3dNRmFRJmFt cDtjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmYW1wO3I9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZh bXA7bT1oS2lRS0FWbl9HRlFpS050eVBwTzVTVzZCak1UTlYwamY2bmI3cWRJcXhBJmFtcDtzPXcx a3lYNF82NkxlaGpXZnk1LTYyNVg4TVU4VFg5SlRTUkljZ1RsVTZpcUEmYW1wO2U9IiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRm Lm9yZ19tYWlsbWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1Dd01GYVEmYW1wO2M9NVZEMFJUdE5sVGgz eWNkNDFiM01VdyZhbXA7cj1sMmo0QmprTzBMYzN1NENIMno3alB3JmFtcDttPWhLaVFLQVZuX0dG UWlLTnR5UHBPNVNXNkJqTVROVjBqZjZuYjdxZElxeEEmYW1wO3M9dzFreVg0XzY2TGVoaldmeTUt NjI1WDhNVThUWDlKVFNSSWNnVGxVNmlxQSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48bzpwPjwvbzpwPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8A79BFEDF6986C46996566F91BB63C860D6536DAPRNMBX021TheFac_-- From nobody Mon Mar 14 13:47:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2262812D697 for ; Mon, 14 Mar 2016 13:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Er2watujkJj for ; Mon, 14 Mar 2016 13:47:45 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E87612D717 for ; Mon, 14 Mar 2016 13:47:45 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id p65so118219426wmp.1 for ; Mon, 14 Mar 2016 13:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Z/PF2pjVIyLPhJZryTXpwEF/su4cMMCv2omqAZoCyqY=; b=fQNTZid/ml8s/OWxxJVqxnYRtdNH3VzfBQHJV0ZsafAg0lLf7ZZKniYzGmNN2LpwJJ oLpLmE88r/5XnajpE85bl8A/7DZacoox/uvKtXj+zBAMiWKL7WlhyXgN1mA73C312y7f PM2bSeXQLsRMsVRiZi6CZ0QQrVWRGZa2noTagHx++ZdyuwRrQxAjl9fQsaAV1e3x8wdk BCVZEU5/fe6ZQYdx6e3oyEhLC7w9T9euPSzzrCCc+XR1e8BU1Fk7pOOXXpZtmT8sGY9i V5KT1m1CWqL+O4pctrUikhV1YxO00Rwfxp6OPQzyJ2abur5RUqPz5Ukc12gSwS2OrYoj POyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Z/PF2pjVIyLPhJZryTXpwEF/su4cMMCv2omqAZoCyqY=; b=GUL6rdgEP+QahYqdhv7IaNTgiGAtsbqDVywaA4zSsnfPOoov6GHneaFHoKRbW1jpBO 6UthUl40TFiSior4WsYgtAhTQ5mc9ZH0dh5EyizAbGV1nr8eLo3ESemgAZQP9Bs5j+dP Y3+LuNJee5CN4intbqKMDvvpLvmuqRgRskKSAInwufc5NVj8DFUuqHI6iJ937RqTzVIE 3tSODlHS1yL7+rj4BOL0VRrBLKdO51fYek6DJctcaTFTDfcZKchb9rHGJ6tFSqmhis9m XfAjWbR9Cv9IPl3fpA64mRJ/DJZL9/FrDY5jdheN5u4Zsa4e4gYDB6zmBHNY38BwXhrk 7O2Q== X-Gm-Message-State: AD7BkJKlnSG7NARD0uHIiPkmXbHktOxAxSiAs8Zmp4UxIMOt13LnAcmT8PsRdzgVPU+kv3370KQL4PmnbhGl7eHp MIME-Version: 1.0 X-Received: by 10.194.81.103 with SMTP id z7mr25878882wjx.25.1457988463624; Mon, 14 Mar 2016 13:47:43 -0700 (PDT) Received: by 10.28.30.75 with HTTP; Mon, 14 Mar 2016 13:47:43 -0700 (PDT) In-Reply-To: <94ce05b82d47420b9acddb24b6bc2503@usma1ex-dag1mb1.msg.corp.akamai.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> <94ce05b82d47420b9acddb24b6bc2503@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 14 Mar 2016 13:47:43 -0700 Message-ID: From: Ryan Hamilton To: "Salz, Rich" Content-Type: multipart/alternative; boundary=047d7bf0d1d6765fed052e086419 Archived-At: Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:47:47 -0000 --047d7bf0d1d6765fed052e086419 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich wrote: > > It's worth keeping in mind this recent paper about Replay attacks > against HTTPS. TL;DR: Attackers can already force a browser to replay > requests basically at will. =E2=80=8BAs a result, it's not clear that 0-R= TT replay > makes this situation worse. > > TLS is more than just browsers, which is what started this thread I think > I was responding to a comment about HTTP, though :> I agree that the implications of 0-RTT for other applications will be different.=E2=80=8B --047d7bf0d1d6765fed052e086419 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 1= 4, 2016 at 12:25 PM, Salz, Rich <rsalz@akamai.com> wrote:
&g= t; It's worth keeping in mind this recent paper about Replay attacks ag= ainst HTTPS. TL;DR: Attackers can already force a browser to replay request= s basically at will. =E2=80=8BAs a result, it's not clear that 0-RTT re= play makes this situation worse.

TLS is more than just browsers, which is what started this thread I = think

I was res= ponding to a comment about HTTP, though :> I agree that the implications= of 0-RTT for other applications will be different.=E2=80=8B

--047d7bf0d1d6765fed052e086419-- From nobody Mon Mar 14 13:47:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0616D12D763 for ; Mon, 14 Mar 2016 13:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3raBB8toRcq for ; Mon, 14 Mar 2016 13:47:54 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE71612D6F1 for ; Mon, 14 Mar 2016 13:47:53 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id l68so118465677wml.0 for ; Mon, 14 Mar 2016 13:47:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cSr2AuRGIQHZRwBtI6ENM6J/riZ8OJnh3puaSyNoGfw=; b=kc1UpoJ0un8s9dMD7gV7MUM7cLa2uFfmZ9cQ7H5R2ATWpVca9nvFw2n9LYh5p0HQUD myC5raOMv2eNS8s/u8zWB5kvWDpQo9mRWE1iwm8dXW6LIBnDQA7JATK5DYpmGHI4MBln yxJDLbKHwKjC/xEsHuuDppwPJ+jF8itIjSm7oPZquCMYvNAcTEQHpS0eqWCabKDEbw8c oqCgMta7SH8QgD/3nQsXI6k2gUENaSZenWcSeeM708v7pNG3JQnfT0U1RKRkgkgkVsSm dCYw2bKcTuSLNAflA/3KEXtUz5bB1N3fD+6ruINoc7rcZ41imox+KYuVpg7tNgN6ENSZ eOkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cSr2AuRGIQHZRwBtI6ENM6J/riZ8OJnh3puaSyNoGfw=; b=Jp3CyNZbEwHxlpfZKJosYZ7MyJX27DjDS8j8uLU/AvYfHgfWM3bsRXZHbAhjFPYVzO dCDJeyhT9lD7wkJ5t4L8r2uA0j9wj2UEqdNe4OxeDzMX56RRTeMMZlv4j+tmeU3gKk7R 49a0XQn5tytxNxDi1DptSoVKIDD1HMM7ue4aI5/6clwNT9qQS3Ksf3jNcldBt8XKCzb4 mXXc/uuRqMBy+fZYJAf2YZN1uAQLqs0USN3vAlOpxwOnsUNIz4FL+dCFZ/9Cwo9bnMod j2z47SptIOy1jovvGij/Mn7f86g///FPyvnxLhSBautkHqX06fzvL602C/ydQIsY47xB pgbg== X-Gm-Message-State: AD7BkJLBNAtO0BFqy587b5PzNALXeXSWxooltH0GHWqOrcyKeL30hCREly98bgv8iFpzajok73+6txcWAFUfUejb MIME-Version: 1.0 X-Received: by 10.194.223.104 with SMTP id qt8mr26388613wjc.11.1457988472282; Mon, 14 Mar 2016 13:47:52 -0700 (PDT) Received: by 10.28.30.75 with HTTP; Mon, 14 Mar 2016 13:47:51 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> Date: Mon, 14 Mar 2016 13:47:51 -0700 Message-ID: From: Ryan Hamilton To: Geoffrey Keating Content-Type: multipart/alternative; boundary=001a11c3b8a4fa637f052e0864db Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:47:56 -0000 --001a11c3b8a4fa637f052e0864db Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 1:17 PM, Geoffrey Keating wrote= : > Ryan Hamilton writes: > > > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating > > wrote: > > > > > So, I don't think HTTP is generally safe against attacker-forced > > > replay, and would suggest great caution in allowing it. > > > > > > > It's worth keeping in mind this recent paper about Replay attacks again= st > > HTTPS >. > > TL;DR: Attackers can already force a browser to replay requests basical= ly > > at will. =E2=80=8BAs a result, it's not clear that 0-RTT replay makes t= his > > situation worse. > > The blog indicates that it's possible to cause a browser to repeat a > request exactly once, within a short timeframe (probably 60 seconds or > so) before the browser times out; and the browser must not see the > first request succeed. That's quite different from being able to let > a client make and complete a request, and then being to repeat that > request thousands of times over a period of hours or longer; even if > the client is a browser, it might be hard to convince it to do that. > =E2=80=8BRight. I'm not trying to argue that these two things are the same.= I am trying to point out that HTTPS replay attacks are *already* possible. So from an HTTP developer perspective, developers already need to deal with this issue. There are surely things we can do constrain the replay-ability of 0-RTT=E2=80=8B data and I'm happy to see that happen. However, I don't w= ant to throw out 0-RTT completely for fear that it will expose HTTP to a new class of attacks, since HTTP is already exposed to those attacks. Cheers, Ryan --001a11c3b8a4fa637f052e0864db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 1= 4, 2016 at 1:17 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
Ryan Hamilton <rch@google.com> writes:

> On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating <geoffk@geoffk.org>
> wrote:
>
> > So, I don't think HTTP is generally safe against attacker-for= ced
> > replay, and would suggest great caution in allowing it.
> >
>
> It's worth keeping in mind this recent paper about Replay attacks = against
> HTTPS <http://blog.valverde.me/2015/12/07/bad-life-advice/#.VucOsJMrIxN>= .
> TL;DR: Attackers can already force a browser to repla= y requests basically
> at will. =E2=80=8BAs a result, it's not clear that 0-RTT replay ma= kes this
> situation worse.

The blog indicates that it's possible to cause a browser to repe= at a
request exactly once, within a short timeframe (probably 60 seconds or
so) before the browser times out; and the browser must not see the
first request succeed.=C2=A0 That's quite different from being able to = let
a client make and complete a request, and then being to repeat that
request thousands of times over a period of hours or longer; even if
the client is a browser, it might be hard to convince it to do that.

=E2=80=8B= Right. I'm not trying to argue that these two things are the same. I am= trying to point out that HTTPS replay attacks are *already* possible. So f= rom an HTTP developer perspective, developers already need to deal with thi= s issue. There are surely things we can do constrain the replay-ability of = 0-RTT=E2=80=8B data and I'm happy to see that happen. However, I don= 9;t want to throw out 0-RTT completely for fear that it will expose HTTP to= a new class of attacks, since HTTP is already exposed to those attacks.

Cheers,

Ryan

--001a11c3b8a4fa637f052e0864db-- From nobody Mon Mar 14 13:50:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F14112D4FF for ; Mon, 14 Mar 2016 13:49:59 -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=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 2w8yTwHWWiEw for ; Mon, 14 Mar 2016 13:49:57 -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 7799912D521 for ; Mon, 14 Mar 2016 13:49:57 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id d65so183606883ywb.0 for ; Mon, 14 Mar 2016 13:49:57 -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:date:message-id:subject:from:to :cc; bh=4sPYFyjbiWlyPIbVG9aOnZyTgToKJXm/UfmbwCVEEE0=; b=dsGPYftrGoj/Z+hU9zkpt1lsQ5GLnUdbhg4brpU9OR+ZMESgBOMQbT+pT8qBvQwunA icpgRyVJYre/D0Fg9DWqDx3pRr1M6trRYlyrWJ5dkwNSCtlggAX9Y9aH/hLIN/MsEwNC 82ufTAFGOWWPMz950PJeDYDcXEte6n98IGumUxdJIOrW8K4QXtti9Hi2GB7ZZ5WA8B9/ lVPAwoc+7ryR0LRSJDiFMHauIPLl0ItiOgFDJsuRONXivWm76kebOKv3k+6EM3BxEs7P b1Hidiknoy/Dovq7eXQa7gFIieWbbjVzCwNmaJc3PuDTIdoSPVvGVxhodJXwOP8e5UGF CMRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4sPYFyjbiWlyPIbVG9aOnZyTgToKJXm/UfmbwCVEEE0=; b=FxBvuueUrS8bJkivGsCVfzAOpbETlQMMVIJ9qg23962COad3BU8zq6qbLBHq9Pxdrt aU2kI59FTcfwqloC/5I0IWNGpg/tdm5boB9xKFlqY9nKz4tpm/7d1OztFXs09M1x9yXn upI8p415alR168vp1eyfRmP6i44odWf4ot6A4YbzvQgsdoxmSvPmC/GhA3oKc+MgUKvu bJxVqjDvaxyQk9v7PKt5nnJSjItunwJhkZ+sR1HgvO997VPGAF3zueFiHF/YiUKch1GK EZ6ETRxVeCFdWejXCzVm8eEl5pSD3cK6rXj68W5SYAlq+5M2siKTNOiQxdIl3J/r0VC0 QgGA== X-Gm-Message-State: AD7BkJJFoRUj5P/ln46+ctrLOzUD7r3Czp4mTAPLBS3EppwYY3DCf86EvJKMk4dPVSJwX/xsw/d91iqeJINCqw== MIME-Version: 1.0 X-Received: by 10.37.13.146 with SMTP id 140mr6216537ybn.159.1457988596652; Mon, 14 Mar 2016 13:49:56 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 13:49:56 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> <94ce05b82d47420b9acddb24b6bc2503@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 14 Mar 2016 13:49:56 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a11c0417c6414d8052e086cbc Archived-At: Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:49:59 -0000 --001a11c0417c6414d8052e086cbc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 1:47 PM, Ryan Hamilton wrote: > On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich wrote: > >> > It's worth keeping in mind this recent paper about Replay attacks >> against HTTPS. TL;DR: Attackers can already force a browser to replay >> requests basically at will. =E2=80=8BAs a result, it's not clear that 0-= RTT replay >> makes this situation worse. >> >> TLS is more than just browsers, which is what started this thread I thin= k >> > > I was responding to a comment about HTTP, though :> I agree that the > implications of 0-RTT for other applications will be different.=E2=80=8B > HTTP is much more than browsers; there's a lot of non-browser APIs built on top of it (aka web services and micro services). Across many vendors, these APIs are commonly not replay safe; or they are safe within the confines a small number of retries, but not a large unbounded number. --=20 Colm --001a11c0417c6414d8052e086cbc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 14, 2016 at 1:47 PM, Ryan Hamilton <rch@google= .com> wrote:
<= div style=3D"font-family:trebuchet ms,sans-serif">On Mon, Mar 14, 2016 at 12:25 PM, Salz, Rich <rsalz@akamai.com> wrote:
> It's worth keeping in mind this recent paper about Replay attac= ks against HTTPS. TL;DR: Attackers can already force a browser to replay re= quests basically at will. =E2=80=8BAs a result, it's not clear that 0-R= TT replay makes this situation worse.

TLS is more than just browsers, which is what started this thread I = think

I was responding to a co= mment about HTTP, though :> I agree that the implications of 0-RTT for o= ther applications will be different.=E2=80=8B

HTTP is much more than browsers; =C2=A0there's a l= ot of non-browser APIs built on top of it (aka web services and micro servi= ces). Across many vendors, these APIs are commonly not replay safe; or they= are safe within the confines a small number of retries, but not a large un= bounded number.=C2=A0

--
Colm
--001a11c0417c6414d8052e086cbc-- From nobody Mon Mar 14 14:04:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B10A12D661 for ; Mon, 14 Mar 2016 14:04:13 -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=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 sjWQvkQGgPzw for ; Mon, 14 Mar 2016 14:04:10 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8CD12D5AA for ; Mon, 14 Mar 2016 14:04:10 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h129so184151396ywb.1 for ; Mon, 14 Mar 2016 14:04:10 -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:date:message-id:subject:from:to :cc; bh=h3YLzoGSw4K7WF8wx8aSjGjtd67rF3E7qJwD770C8k0=; b=11+mJF7FP+hYbyKZpVAr7IsFexnX4WDEjOTy0L8gO8stH5oRZZyZDMTixoRIahlERR zlo8tztdixKcVYwz/ryryaxYYYMMMkVVjjCnvjmliWQcKO5bCqJ0X3e15Eetxq5fg/gA Lt5hDmQ0SEa8mxjThy/Ldf9EeyUukGK3KLfRERcMX5gb/iBHf8bTbDsZI9MYklffiWts 3uD3GQNSGScqd1a52TpxBpKopppgkgbaldF1ZaA5S3ddpC5C8hXN/vXRnYWKvHcoIyyD 3vYjCX26Fo+Sl5Za6fo5H3DtZNWAFndFhytiyi+FHdbGkIDR+53mbzJ5tjQZO+UHHg0B m21g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=h3YLzoGSw4K7WF8wx8aSjGjtd67rF3E7qJwD770C8k0=; b=eDJOM0REEdYTNY9ssSqCsOzCZ0nb7aBMFXMS5TO8LN1Xd6bNCk/fWqRKs0HUDpArfu ThfscAvzgpOMeqxUmHvYs2nL0dNNn2cruO/5byHf87hHBovrb5I77HIhHrnFDoUb6glJ jslk+yhbGrwma22Wip7RuVQTq0WXTaXE4UDONegeFYHl5eAVF3GdtDaIb8Ka+I9tVPaH tiCqKN6kpac+AHAi+ZvvzqBhWzu11WXsNnvm2sAuMoOFvttTKBEgc3xTMWUCmS9GnviG 55sktbtYxVN6NDqZZ9yEVcX7erYYGBHNMA9oMVswWt8XimZv/eE7Xism2p2RAlhIUe4S 7dKg== X-Gm-Message-State: AD7BkJIq+FPw3jTRfEv0RiDydSdk8L2y5i/0/yLJRR3Q2I6/XWQFx7PMJ1apocjqWP4ZZSUZqqGckGAtMDcUhw== MIME-Version: 1.0 X-Received: by 10.37.88.215 with SMTP id m206mr14188472ybb.168.1457989449610; Mon, 14 Mar 2016 14:04:09 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Mon, 14 Mar 2016 14:04:09 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Mon, 14 Mar 2016 17:04:09 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a113fcb7a3b31ba052e089f7c Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:04:13 -0000 --001a113fcb7a3b31ba052e089f7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton wrote: > > On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton > wrote: > >> 0-RTT seems to be a solution looking for a problem. >> > > =E2=80=8BGoogle has been using 0-RTT as part of the QUIC transport for qu= ite a > while now. In April of last year, we posted about the performance > benefits we're seeing from QUIC > . > Among other things, that post said: > > Even on a well-optimized site like Google Search, where connections are > often pre-established, we still see a 3% improvement in mean page load ti= me > with QUIC. > > > From the browser side of things, 0-RTT is a solution to a very real > problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT > resumption) and converting QUIC to use the TLS 1.3 handshake as a result. > Are you sacrificing forward secrecy in this case? For a concrete example: suppose $oppressive_government is collecting all traffic as a routine matter of course, and then later a remote-ex, memory-disclosure, or decrypt-oracle (like the recent DROWN) came along on the server side: could it be used to decrypt all of $worthy_dissident's requests? how long for, how do you manage that trade-off? On the "3% speed up" - we're not going to see that for TLS 1.3 though - right? there's still the TCP handshake to perform; or is some kind of custom TCP in the works? (does TCPCT work on the client side?). Do you have any human perception data; to people even notice the 3% at this point? (loading google seems remarkably fast!). There's a very strong temptation to bias for what's easy to measure here. --=20 Colm --001a113fcb7a3b31ba052e089f7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton <rch@google.com> wrote:
On Sun, Mar 13, 2016= at 4:36 PM, Jeffrey Walton <noloader@gmail.com> wrote:
=
0-RTT seems to be a solutio= n looking for a problem.
=C2=A0
=E2=80=8BGoogle = has been using 0-RTT as part of the QUIC transport for quite a while now. I= n April of last year, we posted about the pe= rformance benefits we're seeing from QUIC. Among other things, that= post said:

Even on a well-optimiz= ed site like Google Search, where connections are often pre-established, we= still see a 3% improvement in mean page load time with QUIC. =C2=A0=

From the browser side of things, 0-RTT is= a solution to a very real problem. We are excited about TLS 1.3 supporting= 0-RTT (or 0-RTT resumption) and converting QUIC to use the TLS 1.3 handsha= ke as a result.

Are you s= acrificing forward secrecy in this case? For a concrete example: suppose $o= ppressive_government is collecting all traffic as a routine matter of cours= e, and then later a remote-ex, memory-disclosure, or decrypt-oracle =C2=A0(= like the recent DROWN) came along on the server side: could it be used to d= ecrypt all of $worthy_dissident's requests? how long for, how do you ma= nage that trade-off?=C2=A0

On the "3% speed u= p" - we're not going to see that for TLS 1.3 though - right? there= 's still the TCP handshake to perform; or is some kind of custom TCP in= the works? (does TCPCT work on the client side?). Do you have any human pe= rception data; to people even notice the 3% at this point? (loading google = seems remarkably fast!).=C2=A0 There's a very strong temptation to bias= for what's easy to measure here.=C2=A0
=C2=A0
-- =
Colm
--001a113fcb7a3b31ba052e089f7c-- From nobody Mon Mar 14 14:14:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71C12D79B for ; Mon, 14 Mar 2016 14:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxyq3B0BEvt7 for ; Mon, 14 Mar 2016 14:14:50 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F48A12D78E for ; Mon, 14 Mar 2016 14:14:50 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u2ELBIHi015797; Mon, 14 Mar 2016 14:14:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=FrtZJvazL6ALLhvvf36IHO/mnKDPSaldKAEvkDeXPw0=; b=gwHQy5U1BvWfSMZ4SKj+C+9rbJfYhc0kk/tmcb/2yVuqD/iqPA3DkvVvwJz+V0JZrdq7 A0MxNaudSoxZ4rGK2W1gng7GaQhaGjHNB50BgXMhdckPEBOFw3oWGNGakkJL/swni2ZT aJzpWesC6WcVXWG4BmbUx+U01qmxcaIyCZg= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 21p4rtr31q-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 14 Mar 2016 14:14:48 -0700 Received: from PRN-MBX02-1.TheFacebook.com ([169.254.2.203]) by PRN-CHUB05.TheFacebook.com ([fe80::9886:b2c2:db18:5ba7%12]) with mapi id 14.03.0248.002; Mon, 14 Mar 2016 14:14:46 -0700 From: Kyle Nekritz To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Subodh Iyengar Thread-Topic: [TLS] analysis of wider impact of TLS1.3 replayabe data Thread-Index: AQHRfRmI7Upjw+kKz0W8CBQxY0euOZ9ZqziAgAAHu4CAAAcKgP//k0AQ Date: Mon, 14 Mar 2016 21:14:46 +0000 Message-ID: <8A79BFEDF6986C46996566F91BB63C860D653797@PRN-MBX02-1.TheFacebook.com> References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_8A79BFEDF6986C46996566F91BB63C860D653797PRNMBX021TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-14_06:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:14:52 -0000 --_000_8A79BFEDF6986C46996566F91BB63C860D653797PRNMBX021TheFac_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgYSBjbGllbnQgbm9uY2UgY2FjaGUgaXMgdXNlZCB0aGVuIHRoZSB0aHJlYXQgaXMgZXNzZW50 aWFsbHkgdGhlIHNhbWUgYXMgd2l0aCBvcmRpbmFyeSByZXRyaWVzLg0KDQpBcyBmYXIgYXMgZm9y d2FyZCBzZWNyZWN5LCB5ZXMsIHRoZSAwLVJUVCBkYXRhIGxvc2VzIHNvbWUgZm9yd2FyZCBzZWNy ZWN5LiBJIHRoaW5rIHRoaXMgaXMgYSByZWFzb25hYmxlIHRyYWRlIG9mZiBmb3IgYSBsb3Qgb2Yg dXNlIGNhc2VzLiBDdXJyZW50bHksIFRMUyAxLjIgaW1wbGVtZW50YXRpb25zIGNvbW1vbmx5IHVz ZSBzZXNzaW9uIHRpY2tldHMgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZS4gVGhpcyBhY3R1YWxseSBz YWNyaWZpY2VzIG1vcmUgZm9yd2FyZCBzZWNyZWN5ICh0aGUgd2hvbGUgY29ubmVjdGlvbiwgaW5z dGVhZCBvZiBqdXN0IHRoZSBpbml0aWFsIGNsaWVudC0+c2VydmVyIDAtUlRUIGZsaWdodCksIGZv ciBhIHNtYWxsZXIgcGVyZm9ybWFuY2UgZ2FpbiAoaXQgZG9lc27igJl0IGV2ZW4gc2F2ZSBhIHJv dW5kdHJpcCBjb21wYXJlZCB3aXRoIFRMUyBmYWxzZSBzdGFydCkuIDAtUlRUIGhhcyBhIHNtYWxs ZXIgZm9yd2FyZCBzZWNyZWN5IGNvc3QgYW5kIGxhcmdlciBiZW5lZml0IGNvbXBhcmVkIHRvIHNl c3Npb24gdGlja2V0cyBpbiB1c2UgdG9kYXkuDQoNCkt5bGUNCg0KRnJvbTogVExTIFttYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDb2xtIE1hY0PDoXJ0aGFpZ2gNClNl bnQ6IE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgMjoyOSBQTQ0KVG86IFN1Ym9kaCBJeWVuZ2FyIDxz dWJvZGhAZmIuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIGFuYWx5 c2lzIG9mIHdpZGVyIGltcGFjdCBvZiBUTFMxLjMgcmVwbGF5YWJlIGRhdGENCg0KDQoNCk9uIE1v biwgTWFyIDE0LCAyMDE2IGF0IDExOjA0IEFNLCBTdWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNv bTxtYWlsdG86c3Vib2RoQGZiLmNvbT4+IHdyb3RlOg0KTGlrZSBLeWxlIG1lbnRpb25lZCB0aGUg dGhpbmcgdGhhdCAwLVJUVCBhZGRzIHRvIHRoaXMgaXMgaW5maW5pdGUgcmVwbGF5YWJpbGl0eS4g QXMgbWVudGlvbmVkIGluIHRoZSBvdGhlciB0aHJlYWQgd2UgaGF2ZSB3YXlzIHRvIHJlZHVjZSB0 aGUgaW1wYWN0IG9mIGluZmluaXRlIHJlcGxheWFibGUgZGF0YSBmb3IgVExTLCBtYWtpbmcgaXQg cmVhc29uYWJseSByZXBsYXkgc2FmZS4NCg0KVGhhdCB0b28gaXMgYSBtaXMtdW5kZXJzdGFuZGlu Zy4gVGhlIGRlZXBlciBwcm9ibGVtIGlzIHRoYXQgYSB0aGlyZCBwYXJ0eSBjYW4gZG8gdGhlIHJl cGxheSwgYW5kIHRoYXQgZm9yd2FyZCBzZWNyZWN5IGlzIGdvbmUgZm9yIHdoYXQgbGlrZWx5IGlz IHNlbnNpdGl2ZSBkYXRhLiBOZWl0aGVyIGlzIHRoZSBjYXNlIHdpdGggb3JkaW5hcnkgcmV0cmll cy4NCg0KLS0NCkNvbG0NCg== --_000_8A79BFEDF6986C46996566F91BB63C860D653797PRNMBX021TheFac_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGEgY2xpZW50IG5vbmNlIGNh Y2hlIGlzIHVzZWQgdGhlbiB0aGUgdGhyZWF0IGlzIGVzc2VudGlhbGx5IHRoZSBzYW1lIGFzIHdp dGggb3JkaW5hcnkgcmV0cmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QXMgZmFyIGFzIGZvcndhcmQgc2Vj cmVjeSwgeWVzLCB0aGUgMC1SVFQgZGF0YSBsb3NlcyBzb21lIGZvcndhcmQgc2VjcmVjeS4gSSB0 aGluayB0aGlzIGlzIGEgcmVhc29uYWJsZSB0cmFkZSBvZmYgZm9yIGEgbG90IG9mIHVzZSBjYXNl cy4gQ3VycmVudGx5LCBUTFMgMS4yIGltcGxlbWVudGF0aW9ucw0KIGNvbW1vbmx5IHVzZSBzZXNz aW9uIHRpY2tldHMgdG8gaW1wcm92ZSBwZXJmb3JtYW5jZS4gVGhpcyBhY3R1YWxseSBzYWNyaWZp Y2VzIG1vcmUgZm9yd2FyZCBzZWNyZWN5ICh0aGUgd2hvbGUgY29ubmVjdGlvbiwgaW5zdGVhZCBv ZiBqdXN0IHRoZSBpbml0aWFsIGNsaWVudC0mZ3Q7c2VydmVyIDAtUlRUIGZsaWdodCksIGZvciBh IHNtYWxsZXIgcGVyZm9ybWFuY2UgZ2FpbiAoaXQgZG9lc27igJl0IGV2ZW4gc2F2ZSBhIHJvdW5k dHJpcCBjb21wYXJlZCB3aXRoDQogVExTIGZhbHNlIHN0YXJ0KS4gMC1SVFQgaGFzIGEgc21hbGxl ciBmb3J3YXJkIHNlY3JlY3kgY29zdCBhbmQgbGFyZ2VyIGJlbmVmaXQgY29tcGFyZWQgdG8gc2Vz c2lvbiB0aWNrZXRzIGluIHVzZSB0b2RheS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+S3lsZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9z ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q29sbSBNYWNDw6FydGhhaWdoPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgTWFyY2ggMTQsIDIwMTYgMjoyOSBQTTxicj4NCjxiPlRvOjwvYj4gU3Vi b2RoIEl5ZW5nYXIgJmx0O3N1Ym9kaEBmYi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIGFuYWx5c2lzIG9mIHdpZGVyIGlt cGFjdCBvZiBUTFMxLjMgcmVwbGF5YWJlIGRhdGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIE1hciAxNCwgMjAxNiBhdCAxMTowNCBBTSwgU3Vib2RoIEl5ZW5nYXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpzdWJvZGhAZmIuY29tIiB0YXJnZXQ9Il9ibGFuayI+c3Vib2RoQGZiLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaWtlIEt5bGUgbWVu dGlvbmVkIHRoZSB0aGluZyB0aGF0IDAtUlRUIGFkZHMgdG8gdGhpcyBpcyBpbmZpbml0ZSByZXBs YXlhYmlsaXR5LiBBcyBtZW50aW9uZWQgaW4gdGhlIG90aGVyIHRocmVhZCB3ZSBoYXZlIHdheXMg dG8gcmVkdWNlIHRoZSBpbXBhY3Qgb2YgaW5maW5pdGUgcmVwbGF5YWJsZSBkYXRhIGZvciBUTFMs IG1ha2luZyBpdCByZWFzb25hYmx5IHJlcGxheSBzYWZlLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCB0b28gaXMgYSBtaXMt dW5kZXJzdGFuZGluZy4gVGhlIGRlZXBlciBwcm9ibGVtIGlzIHRoYXQgYSB0aGlyZCBwYXJ0eSBj YW4gZG8gdGhlIHJlcGxheSwgYW5kIHRoYXQgZm9yd2FyZCBzZWNyZWN5IGlzIGdvbmUgZm9yIHdo YXQgbGlrZWx5IGlzIHNlbnNpdGl2ZSBkYXRhLiBOZWl0aGVyIGlzIHRoZSBjYXNlIHdpdGggb3Jk aW5hcnkgcmV0cmllcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNvbG08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_8A79BFEDF6986C46996566F91BB63C860D653797PRNMBX021TheFac_-- From nobody Mon Mar 14 14:17:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B5ED12D781 for ; Mon, 14 Mar 2016 14:16: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, 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 FM022dnAcJfM for ; Mon, 14 Mar 2016 14:16:57 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC6612D714 for ; Mon, 14 Mar 2016 14:16:57 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id vf5so72076526igb.0 for ; Mon, 14 Mar 2016 14:16:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to; bh=WKUJCBKWwpEH9tjxyBVzbG7oiRxgkA9wTK7vWN8jdRI=; b=Wzci4njbpS4cl0fZ3HfLkUCFTv1hC+SFt5CSaaNUnC4RjWvrHaEIiDBkzHbFEXlVV+ +gM4DvyOOGnP0yXuautFNScAStaoSzCmytI2dDTeTZuPzFipHFyjlWZD+Ru6SElYSpmd HhwgPQoHF3pqDwaSlRV1aRsgLCI/kOuyQRrROdYruASzhWAF/Spo73QM5L4jFnrrVi10 cjtc7H74zslM8SUIEaGm63GGyqucIY+cZj43WMFZfHVaR1Z1/pvUg6Gtt08pwusCJ3R/ L89vv+Aj51FE/u/JGWS74nS/EVFVKOtg9QuQ9oJ+Tsq57JjDb0pBZcu4BXgy5QE4Ut/Q 6rAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to; bh=WKUJCBKWwpEH9tjxyBVzbG7oiRxgkA9wTK7vWN8jdRI=; b=CuM38P3uYFZ5KaTt2d7gxOFyRfMdPgfX2kF9OVDX5TQA3dpeIsxKJCGbSBH6CO30Nx UQJBqGNn9Cp4d7On5Di9XoVd8YE1NLgT9JdWvwNI8kZiCagrZrLWL65lNjLiIkuUpYov wc2mQzcqqzwrbAnfPpZYX4qHwB8OrCaJrqSJ5mlhtOcp9SIiasS02iOat15kXryPbr5l VfhL/AVt9RrJI9ksN5mqUGplhnTImVuX8gbKxvT/BMJachh4jzkHIREbGSWcGpRBOhxY 8XgUMqVyHsJUFG+EvnMqZ6vSumlnHzdRLWu3P3kFZcI5VoK0njDCEDjq2pz6awWU4f/+ 6gNw== X-Gm-Message-State: AD7BkJJ+yIla9iP7su3m+0RxfHdLyHFHKmXekSHG8O7pbYf99gC40tH3qkEG1MrjM9DI8XaGh2UlHPjmPWvj1A== MIME-Version: 1.0 X-Received: by 10.50.142.103 with SMTP id rv7mr20404127igb.35.1457990217041; Mon, 14 Mar 2016 14:16:57 -0700 (PDT) Received: by 10.36.195.133 with HTTP; Mon, 14 Mar 2016 14:16:56 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Mon, 14 Mar 2016 17:16:56 -0400 Message-ID: From: Jeffrey Walton To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com List-Id: "This is the mailing list 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 Mar 2016 21:16:59 -0000 >> From the browser side of things, 0-RTT is a solution to a very real >> problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT resumption) >> and converting QUIC to use the TLS 1.3 handshake as a result. > > ... > TCP in the works? (does TCPCT work on the client side?). Do you have any > human perception data; to people even notice the 3% at this point? (loading > google seems remarkably fast!). There's a very strong temptation to bias > for what's easy to measure here. We also lack statistics on the other costs associated with security failures. The best I can tell, we have no idea of the impact if its not in US Financial. I wrote to the United Nations and Human Rights Watch a while back, and they don't appear to collect statistics on human rights violations after incidents like Diginotar. I can't help but wonder how many folks would agree to controls like Public Key Pinning with Overrides or 0-RTT if their well being and their family's well being were at stake. Jeff From nobody Mon Mar 14 14:33:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68E712D71F for ; Mon, 14 Mar 2016 14:33:21 -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 hjJn9nIr6a1B for ; Mon, 14 Mar 2016 14:33:19 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C861612D697 for ; Mon, 14 Mar 2016 14:33:18 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g127so184851185ywf.2 for ; Mon, 14 Mar 2016 14:33:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CUEgU8lUPfqHLkxEP7PXeNrcLD30x8GXIGjT4/+X3Ko=; b=tCgV8N2lMjMCMhtsw0p9qLbTN6WK+/5i9VVd7r5sonMd1qO73kO/6R6JxICZHz79dN OnyVjPRhbHaOz1+waWx3Ufki8fAbBw/aK5Jq5qVZc/ZQ3fUOuzy1WJkbpeniAsXpDnrK 0lqfaPRslsDLLVNxwvumxUByCzafGuaV1m3N9wDMgyF670ACBUB+d0fuGeN6XtR1C/gw bu3/KXj7A/kfp4PnbmrUovdsZ3vDSHHg3eYUqzm4o0lBtSjNz4bgc2XGh20vQFfKOU9h MmwYogor8i/D8E4gjSi6K/OO47iynqXxd1wCEOvMXalmS7IoQ91A/NS5/QH/8J3uD8rm iE4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CUEgU8lUPfqHLkxEP7PXeNrcLD30x8GXIGjT4/+X3Ko=; b=k9eIZMGBunv1XIjy2TbR2RXpFAclr+iqS4NHv8AQK/BYqwRaoR1UHzHVW+NSDNVATi fmj+CLTBBdx5Co6OjCDZK4w8OrVB1xUzsRU4gWZxZ+5ZwkIo5Xt5pclKBnv1Uo/+WhV8 J4Ck0+SE3FdEasd1HRoV6hjcvDgVBKM4oBYrrBT8t+9amkm4S0Oh5DDR5IQKDcD/ziIw T8jBSn67V7QnT1cuaO/2lRD3NmH47nwusET+LMoh777QTZ6LE2WRRAGAZcWlHHvMWlQ7 C+t0l1pmSue8NahayMy5jtR8aHoT/OOjotu1uO4KjE4LF9yDIqbQsWkRQze0Mc0XbBrD 29yg== X-Gm-Message-State: AD7BkJIz0uF+CVIKWoLUaUwvea4U39z+72ebe2V8duomdnvFIZSE48guEmYdVpKpFUu7CcVYFGovi1LLn5Cc6Q== X-Received: by 10.37.230.202 with SMTP id d193mr14248201ybh.74.1457991198005; Mon, 14 Mar 2016 14:33:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 14:32:38 -0700 (PDT) In-Reply-To: <8A79BFEDF6986C46996566F91BB63C860D6536DA@PRN-MBX02-1.TheFacebook.com> References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <8A79BFEDF6986C46996566F91BB63C860D6536DA@PRN-MBX02-1.TheFacebook.com> From: Eric Rescorla Date: Mon, 14 Mar 2016 14:32:38 -0700 Message-ID: To: Kyle Nekritz Content-Type: multipart/alternative; boundary=94eb2c0afb0e719b33052e090715 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:33:22 -0000 --94eb2c0afb0e719b33052e090715 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 1:43 PM, Kyle Nekritz wrote: > As others have said I do think adding client time solves much more than > just this specific issue. Running a client nonce cache at scale also like= ly > requires client time in order to limit the storage needed to a reasonable > amount. > > > > I like the idea of including time since receiving the session ticket > instead of absolute time. This allows for clients with high clock skew bu= t > still an accurate steady clock to use 0-RTT, and likely for tighter bound= s > to be placed on the time. The natural place to put this would be the > client hello, where it would be unencrypted, which would leak the time of > ticket issuance. How concerning is this, is it worth encrypting this time= ? > My view of this is that we probably are going to eventually want client EncryptedExtensions (perhaps for ALPN as Ilari suggests). So, we might as well just add it and stuff time there. -Ekr > > Kyle > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Martin Thomson > *Sent:* Sunday, March 13, 2016 5:36 AM > *To:* Erik Nygren > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Limiting replay time frame of 0-RTT data > > > > I assume that you would run a tight tolerance on the 0RTT resumption by > saving the client's clock error in the ticket. That a way only clients > with bad drift get no 0RTT. To do that all sessions need time. > > I do not see how the server can do this in general without client help. > But the solution also addresses Brian's concern. The client doesn't need > absolute time, just relative time: How long since the ticket was issued. > Then it's an addition to the psk_identity only. > > On 13 Mar 2016 1:49 PM, "Erik Nygren" wrote: > > That does seem like a good idea to include a client time stamp in the 0RT= T > flow to let the server force 1RTT in the case where this is too far off a= s > this bounds the duration of the replay window. (I suspect we'll find a > whole range of other similar attacks using 0RTT.) An encrypted client > timestamp could presumably be probed by the server. (ie, if the server > response is a different size for timestamp-expired vs timestamp-not-expir= ed > an attacker could keep probing until they change?) That does seem like > more effort, however. > > Erik > > > > On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla wrote: > > Hi Kyle, > > > > Clever attack. I don't think it would be unreasonable to put a low > granularity time stamp in the > > ClientHello (and as you observe, if we just define it it can be done > backward compatibly) > > or as you suggest, in an encrypted block. With that said, though couldn't > you > > also just include the information in the HTTP header for HTTP? Do you > think this is a sufficiently > > general issue that it merits a change to TLS. > > > > -Ekr > > > > > > On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz wrote: > > Similar to the earlier discussion on 0.5-RTT data, I=E2=80=99m concerned = with the > long term ability to replay captured 0-RTT early data, and the attack > vectors that it opens up. For example, take a GET request for an image to= a > CDN. This is a request that seems completely idempotent, and that > applications will surely want to send as 0-RTT data. However, this reques= t > can result in a few things happening: > 1) Resource unavailable > 2) Resource cached locally at edge cluster > 3) Cache miss, resource must be fetched from origin data center > #1 can easily be differentiated by the length of the 0.5-RTT response > data, allowing an attacker to determine when a resource has been > deleted/modified. #2 and #3 can also be easily differentiated by the timi= ng > of the response. This opens up the following attack: if an attacker knows= a > client has requested a resource X_i in the attacker-known set {X_1, X_2, > ..., X_n}, an attacker can do the following: > 1) wait for the CDN cache to be evicted > 2) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the cache > 3) replay the captured client early data (the request for X_i) > 4) determine, based on the timing of the response, whether it resulte= d > in a cache hit or miss > 5) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_(n/2 + 1), X_= (n/2 + > 2), =E2=80=A6, X_n} depending on the result > This particular binary search example is a little contrived and requires > that no-one else is requesting any resource in the set, however I think i= t > is representative of a significant new attack vector that allowing > long-term replay of captured early data will open up, even if 0-RTT is on= ly > used for seemingly simple requests without TLS client authentication. Thi= s > is a much different threat than very short-term replay, which is already > somewhat possible on any TLS protocol if clients retry failed requests. > > Given this, I think it is worth attempting to limit the time frame that > captured early data is useful to an attacker. This obviously doesn=E2=80= =99t > prevent replay, but it can mitigate a lot of attacks that long-term repla= y > would open up. This can be done by including a client time stamp along wi= th > early data, so that servers can choose to either ignore the early data, o= r > to delay the 0.5-RTT response to 1.5-RTT if the time stamp is far off. Th= is > cuts down the time from days (until the server config/session ticket key = is > rotated) to minutes or seconds. > > Including the client time also makes a client random strike register > possible without requiring an unreasonably large amount of server-side > state. > > I am aware that client time had previously been removed from the client > random, primarily due to fingerprinting concerns, however these concerns > can be mitigated by > 1) clients can choose to not include their time (or to include a random > time), with only the risk of their .5-RTT data being delayed > 2) placing the time stamp in an encrypted extension, so that it is not > visible to eavesdroppers > > > Note: it=E2=80=99s also useful for the server to know which edge cluster = the early > data was intended for, however this is already possible in the current > draft. In ECDHE 0-RTT server configs can be segmented by cluster, and wit= h > tickets, the server can store cluster information in the opaque ticket. > > > > _______________________________________________ > 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 > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0afb0e719b33052e090715 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 1:43 PM, Kyle Nekritz <knekritz@fb.com> wrote:

As others have said I do think adding client time s= olves much more than just this specific issue. Running a client nonce cache= at scale also likely requires client time in order to limit the storage needed to a reasonable amount.

=C2=A0

I like the idea of including time since receiving t= he session ticket instead of absolute time. This allows for clients with hi= gh clock skew but still an accurate steady clock to use 0-RTT, and likely for tighter bounds to be placed on the time.=C2= =A0 The natural place to put this would be the client hello, where it would= be unencrypted, which would leak the time of ticket issuance. How concerni= ng is this, is it worth encrypting this time?


My view of th= is is that we probably are going to eventually want client EncryptedExtensi= ons
(perhaps for ALPN as Ilari suggests). So, we might as well ju= st add it and stuff time
there.

-Ekr

<= /p>

=C2=A0

Kyle

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Sunday, March 13, 2016 5:36 AM
To: Erik Nygren <erik+ietf@nygren.org>
Cc: tls@ietf.org
Subject: Re: [TLS] Limiting replay time frame of 0-RTT data

=C2=A0

I assume that you would run a tight tolerance on the 0RTT resumption by = saving the client's clock error in the ticket.=C2=A0 That a way only cl= ients with bad drift get no 0RTT. To do that all sessions need time.

I do not see how the server can do this in general without client help. = But the solution also addresses Brian's concern. The client doesn't= need absolute time, just relative time: How long since the ticket was issu= ed. Then it's an addition to the psk_identity only.

On 13 Mar 2016 1:49 PM, "Erik Nygren" <= erik+ietf@nygre= n.org> wrote:

That does seem like a= good idea to include a client time stamp in the 0RTT flow to let the serve= r force 1RTT in the case where this is too far off as this bounds the durat= ion of the replay window.=C2=A0 (I suspect we'll find a whole range of other similar attacks using 0RTT.)=C2=A0 A= n encrypted client timestamp could presumably be probed by the server.=C2= =A0 (ie, if the server response is a different size for timestamp-expired v= s timestamp-not-expired an attacker could keep probing until they change?)=C2=A0 That does seem like more effort, however.=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik

=C2=A0

On Sat, Mar 12, 2016 at 7:56 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :

Hi Kyle,

=C2=A0

Clever attack. I don't think it would be unreaso= nable to put a low granularity time stamp in the

ClientHello (and as you observe, if we just define i= t it can be done backward compatibly)

or as you suggest, in an encrypted block. With that = said, though couldn't you

also just include the information in the HTTP header= for HTTP? Do you think this is a sufficiently

general issue that it merits a change to TLS.=

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Fri, Mar 11, 2016 at 9:21 PM, Kyle Nekritz <knekritz@fb.com> = wrote:

Similar to the earlier discussion on 0.5-RTT data, I= =E2=80=99m concerned with the long term ability to replay captured 0-RTT ea= rly data, and the attack vectors that it opens up. For example, take a GET request for an image to a CDN. This is a request that seems com= pletely idempotent, and that applications will surely want to send as 0-RTT= data. However, this request can result in a few things happening:
=C2=A0 =C2=A0=C2=A01) Resource unavailable
=C2=A0 =C2=A0=C2=A02) Resource cached locally at edge cluster
=C2=A0 =C2=A0=C2=A03) Cache miss, resource must be fetched from origin data= center
#1 can easily be differentiated by the length of the 0.5-RTT response data,= allowing an attacker to determine when a resource has been deleted/modifie= d. #2 and #3 can also be easily differentiated by the timing of the respons= e. This opens up the following attack: if an attacker knows a client has requested a resource X_i in the attacker= -known set {X_1, X_2, ..., X_n}, an attacker can do the following:
=C2=A0 =C2=A0=C2=A01) wait for the CDN cache to be evicted
=C2=A0 =C2=A0=C2=A02) request {X_1, X_2, =E2=80=A6, X_(n/2)} to warm the ca= che
=C2=A0 =C2=A0=C2=A03) replay the captured client early data (the request fo= r X_i)
=C2=A0 =C2=A0=C2=A04) determine, based on the timing of the response, wheth= er it resulted in a cache hit or miss
=C2=A0 =C2=A0=C2=A05) repeat with set {X_1, X_2, =E2=80=A6, X_(n/2)} or {X_= (n/2 + 1), X_(n/2 + 2), =E2=80=A6, X_n} depending on the result
This particular binary search example is a little contrived and requires th= at no-one else is requesting any resource in the set, however I think it is= representative of a significant new attack vector that allowing long-term = replay of captured early data will open up, even if 0-RTT is only used for seemingly simple requests without = TLS client authentication. This is a much different threat than very short-= term replay, which is already somewhat possible on any TLS protocol if clie= nts retry failed requests.

Given this, I think it is worth attempting to limit the time frame that cap= tured early data is useful to an attacker. This obviously doesn=E2=80=99t p= revent replay, but it can mitigate a lot of attacks that long-term replay w= ould open up. This can be done by including a client time stamp along with early data, so that servers can choose to e= ither ignore the early data, or to delay the 0.5-RTT response to 1.5-RTT if= the time stamp is far off. This cuts down the time from days (until the se= rver config/session ticket key is rotated) to minutes or seconds.

Including the client time also makes a client random strike register possib= le without requiring an unreasonably large amount of server-side state.

I am aware that client time had previously been removed from the client ran= dom, primarily due to fingerprinting concerns, however these concerns can b= e mitigated by
1) clients can choose to not include their time (or to include a random tim= e), with only the risk of their .5-RTT data being delayed
2) placing the time stamp in an encrypted extension, so that it is not visi= ble to eavesdroppers


Note: it=E2=80=99s also useful for the server to know which edge cluster th= e early data was intended for, however this is already possible in the curr= ent draft. In ECDHE 0-RTT server configs can be segmented by cluster, and w= ith tickets, the server can store cluster information in the opaque ticket.

=C2=A0

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

=C2=A0


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

=C2=A0


_______________________________________________
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


--94eb2c0afb0e719b33052e090715-- From nobody Mon Mar 14 15:03:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9745C12D7AA for ; Mon, 14 Mar 2016 15:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EmpLh5FMLQ2c for ; Mon, 14 Mar 2016 15:03:25 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C1B712D7A4 for ; Mon, 14 Mar 2016 15:03:25 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id ig19so1316685igb.1 for ; Mon, 14 Mar 2016 15:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=wGcrA9FuyzOng8vwDM49Wlk7VpGq30WaqihICp4fqS4=; b=mImv2A56xjtkONpoIDMOxD1V4g2jtFywu7I+ncu05Qg8RzYGFR9Bkvu19C4OH0zx+e mRK1ctl5fun6mFUjZ4U+Y6MIaEOTMfgIT96wrkDwvV3t4E9sRHX1KaEI5h6Dm/iiATjW riUwWAhWfWFt09lE/u39HSbjJxV4AHQkNFXSFB8TJXBtjFqo2sMOiICSSiTzM0MfiKck MkwGZRmdS0r+hQ+a0VVfxRRpfcalNPWOGJ00YIbjqrtpmNVYStBxLeC7yz3g7x5b0Xci OTT1IR02ZHRGoov8oCP0KMkxbspCL3X0Q86wwDHJyXbO4jbUwlhvonGh8tMWDPJkJJBU WGfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wGcrA9FuyzOng8vwDM49Wlk7VpGq30WaqihICp4fqS4=; b=jjGFxOkOPOg648DCZhh938c/OFZ42OOjJ7v+1z1Gm+v/qu7qei6ENpMTKD2EUSx11h rXiO6T+yFjvXOo/caFe5WGkcjHOX+IPEO3kIG/gvzDvWs738q5YWw/Rv0TZ/7EbNLTW1 G6nlajPFhute/aSZUQj3JeBUhMARldoH3mqVuo2+wyCGZ+jojPtcDFQOMUmkM5yhIOef +dAYr6mn2XDKByPaM1NothQE0NZS4kFJC206vEC8nyU6uQEzB3MbjXnZvdlft7g9Dd5k 6ZxTLlsxSVcFLFZdi4lkfdXH3ChmehO1Idq0FamQsYJ/yzClEw8nk0GQG3wHB4t7NctL 188w== X-Gm-Message-State: AD7BkJL+8zM7ps8Z1V29T7YhXA0tx305x0iLmqI61EHrsQrv1acDGhlNZ+BMU/1K2rRJdM2OEzfBriZxHPNRK8OJ MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr20444571igt.4.1457993004258; Mon, 14 Mar 2016 15:03:24 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 15:03:23 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <8D7A1B2B-643E-46E6-A586-83ACDA8927EA@dukhovni.org> <974CF78E8475CD4CA398B1FCA21C8E99564F44A9@PRN-MBX01-4.TheFacebook.com> Date: Mon, 14 Mar 2016 15:03:23 -0700 Message-ID: From: Bill Cox To: Ryan Hamilton Content-Type: multipart/alternative; boundary=047d7bdc15b21af075052e09736c Archived-At: Cc: Geoffrey Keating , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:03:27 -0000 --047d7bdc15b21af075052e09736c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 12:23 PM, Ryan Hamilton wrote: > > On Mon, Mar 14, 2016 at 12:12 PM, Geoffrey Keating > wrote: > >> So, I don't think HTTP is generally safe against attacker-forced >> replay, and would suggest great caution in allowing it. >> > > It's worth keeping in mind this recent paper about Replay attacks against > HTTPS . > TL;DR: Attackers can already force a browser to replay requests basically > at will. =E2=80=8BAs a result, it's not clear that 0-RTT replay makes thi= s > situation worse. > Yay, this attack is finally published. Now I can argue that stateful 0-RTT resumption is secure enough to be the default 0-RTT connection mode in TLS 1.3. Summary: The stateless 0-RTT modes currently described in the TLS 1.3 spec are somewhat dangerous and should be used with caution and only by admins who know what they are doing. In contrast, 0-RTT resumption from session caches has almost the same security as session resumption in TLS 1.2. This should be the default 0-RTT mode in TLS 1.3, IMO, though stateless PSK 0-RTT should also be supported to allow advanced users to achieve even higher performance. The attack in the paper is important because it explains why I do not care about the following attack, at least for HTTPS. Suppose a company has properly implemented 0-RTT resumption using session caches. They support strong client auth, full PFS, and would like to think they prevent replay attacks. This is a large company with non-synchronized session caches in data centers around the world. The has the following steps: - The attacker captures 0-RTT packets intended for a local data center, and holds onto them without letting them through (yet). - The attacker also sends a copy of these packets to a remote data center. - The remote data center, since it does not have the session cached, drops to a 1-RTT handshake. - The TLS layer in the client completes the 1-RTT handshake, and then resends the 0-RTT data, as required by the TLS 1.3 spec. This is accepted by the remote data center. - The attacker simultaneously sends the local data center the initial 0-RTT packets, which are accepted by the local data center because the session is in the cache. If this were HTTPS traffic, this attack would work against TLS 1.2, because the browser would resend the packets rather than the TLS layer. In any case attackers can replay _any_ HTTPS packet using the attack from the paper. This attack gains the attacker nothing new against HTTPS. Because of this, I recommend that POST requests be allowed as 0-RTT data over session-cache based stateful 0-RTT resumption, but not over stateless 0-RTT resumption. The ability for an eavesdropper to infinitely replay 0-RTT data is specific to stateless 0-RTT resumption. So, is there any application that cares about this attack? Consider ssh using TLS 1.3, with 0-RTT to accelerate how fast a user's command is executed. Clearly, we cannot allow the user's command to be executed twice. Even if the destination machine is a VM in the cloud, eventually the connection is routed to the same virtual machine for both connections. The session cache on that machine would get a hit on the first connection, and execute the user's command. The second set of packets would be rejected because the session resume count would be wrong. I see no way for an attacker to succeed in a replay attack. In general, I expect applications that are inherently sensitive to replay (such as ssh) to terminate all TLS connections in the same place, where the session cache is shared and synchronized. Otherwise, random network errors would be a huge problem. Distributed applications such as HTTP that terminate all over the place have had to deal with random replay issues from the beginning, which is why no one is seems to be terribly upset by the attack described in the paper. Stateful 0-RTT resumed sessions can provide significant security guarantees not offered by stateless 0-RTT: - Effective, although imperfect, reply defense, which is good enough for real-world deployment in most cases (are there any counter-examples?) - Strong client auth works: even a replay attack will fail to forge a proof of possession or cause a server to accept a signature twice. - PFS is possible, unlike with DH 0-RTT, although it also can be done with stateless PSK 0-RTT (a good reason to prefer PSK 0-RTT over DH 0-RTT) The only new security concern I see compared to TLS 1.2 session resumption is that the TLS layer sometimes will replay packets on its own without involving the application layer. This appears not to be a problem for HTTPS and other protocols that already replay packets when there are network errors. For other applications, it should be carefully considered before choosing to use session-ID based 0-RTT resumption, but I expect it to be safe for protocols that already have to deal with noisy network connections. Bill --047d7bdc15b21af075052e09736c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 14, 2016 at 12:23 PM, Ryan Hamilton <rch@google.com> = wrote:

On Mon, Mar 14, 2016 at 12:12 P= M, Geoffrey Keating <geoffk@geoffk.org> wrote:
So, I don't think HTTP is general= ly safe against attacker-forced
replay, and would suggest great caution in allowing it.
<= /div>
Replay attacks against HTTPS. TL;DR: Attackers can already force a br= owser to replay requests basically at will. =E2=80=8BAs a result, it's = not clear that 0-RTT replay makes this situation worse.

Yay, this attack is f= inally published.=C2=A0 Now I can argue that stateful 0-RTT resumption is s= ecure enough to be the default 0-RTT connection mode in TLS 1.3.

Summary: The stateless 0-RTT modes currently described in the TL= S 1.3 spec are somewhat dangerous and should be used with caution and only = by admins who know what they are doing.=C2=A0 In contrast, 0-RTT resumption= from session caches has almost the same security as session resumption in = TLS 1.2. =C2=A0 This should be the default 0-RTT mode in TLS 1.3, IMO, thou= gh stateless PSK 0-RTT should also be supported to allow advanced users to = achieve even higher performance.

=
The attack in the paper is important becau= se it explains why I do not care about the following attack, at least for H= TTPS.=C2=A0 Suppose a company has properly implemented 0-RTT resumption usi= ng session caches.=C2=A0 They support strong client auth, full PFS, and wou= ld like to think they prevent replay attacks.=C2=A0 This is a large company= with non-synchronized session caches in data centers around the world.=C2= =A0 The has the following steps:

=
- The attacker captures 0-RTT packets intended f= or a local data center, and holds onto them without letting them through (y= et).
- The attacker also sends a copy of th= ese packets to a remote data center.
- The = remote data center, since it does not have the session cached, drops to a 1= -RTT handshake.
- The TLS layer in the clie= nt completes the 1-RTT handshake, and then resends the 0-RTT data, as requi= red by the TLS 1.3 spec.=C2=A0 This is accepted by the remote data center.<= /div>
- The attacker simultaneously sends the loc= al data center the initial 0-RTT packets, which are accepted by the local d= ata center because the session is in the cache.

If this were HTTPS traffic, this = attack would work against TLS 1.2, because the browser would resend the pac= kets rather than the TLS layer.=C2=A0 In any case attackers can replay _any= _ HTTPS packet using the attack from the paper.=C2=A0 This attack gains the= attacker nothing new against HTTPS.

Because of this, I recommend that POST reque= sts be allowed as 0-RTT data over session-cache based stateful 0-RTT resump= tion, but not over stateless 0-RTT resumption.=C2=A0 The ability for an eav= esdropper to infinitely replay 0-RTT data is specific to stateless 0-RTT re= sumption.

So, is there any application that cares about this attack?=C2=A0 Consid= er ssh using TLS 1.3, with 0-RTT to accelerate how fast a user's comman= d is executed.=C2=A0 Clearly, we cannot allow the user's command to be = executed twice.=C2=A0 Even if the destination machine is a VM in the cloud,= eventually the connection is routed to the same virtual machine for both c= onnections.=C2=A0 The session cache on that machine would get a hit on the = first connection, and execute the user's command.=C2=A0 The second set = of packets would be rejected because the session resume count would be wron= g.=C2=A0 I see no way for an attacker to succeed in a replay attack.
<= div class=3D"gmail_extra">
In general, = I expect applications that are inherently sensitive to replay (such as ssh)= to terminate all TLS connections in the same place, where the session cach= e is shared and synchronized.=C2=A0 Otherwise, random network errors would = be a huge problem.=C2=A0 Distributed applications such as HTTP that termina= te all over the place have had to deal with random replay issues from the b= eginning, which is why no one is seems to be terribly upset by the attack d= escribed in the paper.

Stateful 0-RTT resumed sessions can provide significant se= curity guarantees not offered by stateless 0-RTT:

- Effective, although imperfect= , reply defense, which is good enough for real-world deployment in most cas= es (are there any counter-examples?)
- Stro= ng client auth works: even a replay attack will fail to forge a proof of po= ssession or cause a server to accept a signature twice.
- PFS is possible, unlike with DH 0-RTT, although it also can = be done with stateless PSK 0-RTT (a good reason to prefer PSK 0-RTT over DH= 0-RTT)

The only new security concern I see compared to TLS 1.2 session resumptio= n is that the TLS layer sometimes will replay packets on its own without in= volving the application layer.=C2=A0 This appears not to be a problem for H= TTPS and other protocols that already replay packets when there are network= errors.=C2=A0 For other applications, it should be carefully considered be= fore choosing to use session-ID based 0-RTT resumption, but I expect it to = be safe for protocols that already have to deal with noisy network connecti= ons.

B= ill
--047d7bdc15b21af075052e09736c-- From nobody Mon Mar 14 17:22:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406612D70F for ; Mon, 14 Mar 2016 17:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLMwH0gOFR0b for ; Mon, 14 Mar 2016 17:22:40 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C4F12D53B for ; Mon, 14 Mar 2016 17:22:39 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id g127so1787104ywf.2 for ; Mon, 14 Mar 2016 17:22: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=i1AvZJUe/s9Ei8UbXmvqIEmKMvjTmnfHIMcxmr70zGQ=; b=MIcum8U1SBNhQEPnRX6gx97B/7aqZ0H1gBQgRRADPvGGDikKzqBxBBcIi900EVtCm8 PZLClffyFAOrDkJLck8gZrdiuPwbeOI4/7rOltrfUFVnDbqt81Fy+jUCpZHTC0g7BFNS P2UNlmxWXMRiUGMH+sAUbRAW4En38FaZJqPSxpKNSZJ/rSr4tG5grnxgFbtFkYUaAH7H yiZZE1CvbCePaIwk/yHT7u6tkFBVcAyv7QcCSj3q4uN3fm6ndPsvO9Bxr97XXFX4AbGm udiWPvJFulpI+qmaXmr+LrgKp14ZXUguPuadfwWlf8OL7xahZUMujh/7IV+SGlQDIiFT Z0VQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i1AvZJUe/s9Ei8UbXmvqIEmKMvjTmnfHIMcxmr70zGQ=; b=kIFwn3U8l0GDqn4cj+9V9irrTAdZ1yKwupKZ9XyFC6gUzOhkrzLj5Ngare5qoa+UeY j195uTvOzkGYVIAmtRpKcRMi7t9NBwqDSC2c/gvAG/9GQG0gh0fuBEO3PGCBchD+aeDv oZjcPYKQ22OWqAhVFMnpxGCJ2bCjR65/7i4ESp6cAx17v64/Fpy0hygqNg9Ht/lU9nVa rAWx2m2vKPvvYdwATiF4aXykeGokwMlLNRIodX40g375e6lvsvy7Apf8vCUP9A/ErwbA Z2z9bPOAPacStmpIljaFGr6sa+7nexQ/iSzsEoFqTH6P9ivd9lnBBOBL+FAICJ13xd5S eD/w== X-Gm-Message-State: AD7BkJIOrS6yDSKlLaYwc2sT7EE/i+1jPxseCdnlOBcZnQsvOhMzpk4jYc/q0r/kW/TEZhqBHD6b0nNaO2OKlw== X-Received: by 10.37.13.146 with SMTP id 140mr6609945ybn.159.1458001358939; Mon, 14 Mar 2016 17:22:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 17:21:59 -0700 (PDT) In-Reply-To: References: <201601152007.12464.davemgarrett@gmail.com> From: Eric Rescorla Date: Mon, 14 Mar 2016 17:21:59 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11c0417c1525ad052e0b65d8 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 00:22:42 -0000 --001a11c0417c1525ad052e0b65d8 Content-Type: text/plain; charset=UTF-8 David, Thanks for being patient with me here. Sorry it took so long As usual, this seems like a question of whether we're going to want a lot of flexibility (thus motivating orthogonal negotiation) versus whether we're going to want little flexibility (thus motivating suites). I think that with the historical practice, the arguments for orthogonal negotiation were a lot stronger, but now that we seem to be leaning towards (a) fewer algorithms and (b) having algorithms which are themselves suites, I do agree that the pendulum is swinging more towards suites. On balance, I guess, I'm neutral-to-supportive of this change in general, if others in the WG want to make it. On the details: - It seems like we could let measurements tell us what code points we need. If we never see P256-SHA512 in the wild, then we don't need it (and can add it later if needed). - I took a quick look at the PR and I'm not sure that some of the code points assignments are right. I made comments. - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll probably want to define code points for 1.5 in both in-protocol (CertificateVerify) and certificates to distinguish these. As far as process, it seemed like people were generally positive about this in this discussion, but I'll rely on the chairs to determine consensus. -Ekr On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin wrote: > On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: > >> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin >> wrote: >> >>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett >>> wrote: >>> >>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In >>>> TLS >>>> > 1.2, signature algorithms are spread across the handshake. >>>> [...] >>>> > I propose we fold the negotiable parameters under one name. >>>> [...] >>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>> SignatureAndHashAlgorithm as >>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>>> that >>>> > instead. >>>> >>>> I previously proposed this here: >>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>> >>>> ekr was against it, though it hasn't been discussed that throughly. >>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>> >>> >>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and >>> forgot. >>> >>> ekr, are you still against this sort of thing? I think the new CFRG >>> signature algorithms tying decisions together is a good argument for why >>> we'd want this. If we believe this trend is to continue (and I hope it >>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>> seems poor. >>> >> >> I'm not sure. I agree that the CFRG thing seems to be a new development. >> I'll >> try to confirm my previous opinion or develop a new one over the weekend >> :) >> > > ekr, did you have confirmed or new thoughts on this change? > > From elsewhere in the thread, I put together a draft PR if you wanted > something to look at in that form. > https://github.com/tlswg/tls13-spec/pull/404 > It incorporated some of the suggestions in the thread (not mentioning the > really legacy values, pairing NIST curves with hashes, etc.), but that's > not the important part. The meat of the proposal is unifying signature > algorithms under one number and a shared interface, which I think is a > valuable simplification. > > David > --001a11c0417c1525ad052e0b65d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
David,

Thanks for being pati= ent with me here. Sorry it took so long

As usual, = this seems like a question of whether we're going to want a lot of flex= ibility
(thus motivating orthogonal negotiation) versus whether w= e're going to want little flexibility
(thus motivating suites= ). I think that with the historical practice, the arguments for orthogonal<= /div>
negotiation were a lot stronger, but now that we seem to be leani= ng towards (a) fewer algorithms
and (b) having algorithms which a= re themselves suites, I do agree that the pendulum is swinging
mo= re towards suites.

On balance, I guess, I'm ne= utral-to-supportive of this change in general, if others in the WG want
to make it. On the details:

- It seems like= we could let measurements tell us what code points we need. If we never se= e
=C2=A0 P256-SHA512 in the wild, then we don't need it (and = can add it later if needed).

- I took a quick look= at the PR and I'm not sure that some of the code points assignments ar= e
=C2=A0 right. I made comments.

- If we= decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll pro= bably want to define
=C2=A0 code points for 1.5 in both in-protoc= ol (CertificateVerify) and certificates to distinguish these.
As far as process, it seemed like people were generally positiv= e about this in this discussion,
but I'll rely on the chairs = to determine consensus.

-Ekr

<= div>




<= div>




<= div>

On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <davidben@chromium.= org> wrote:
On Fri, Jan = 15, 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <davidben@chromium.o= rg> wrote:
On Fri, Jan 15, 2016 at = 8:07 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote= :
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG = thing seems to be a new development. I'll
try to confirm = my previous opinion or develop a new one over the weekend :)

ekr, did you have confirmed or new thoughts on this= change?

From elsewhere in the thread, I put together a draft PR if = you wanted something to look at in that form.
https://github.com/tlswg/t= ls13-spec/pull/404
It incorporated some of the suggestion= s in the thread (not mentioning the really legacy values, pairing NIST curv= es with hashes, etc.), but that's not the important part. The meat of t= he proposal is unifying signature algorithms under one number and a shared = interface, which I think is a valuable simplification.

David

--001a11c0417c1525ad052e0b65d8-- From nobody Mon Mar 14 17:44:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B550912D523 for ; Mon, 14 Mar 2016 17:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkRnRYI0r8Fq for ; Mon, 14 Mar 2016 17:44:21 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8FF12D501 for ; Mon, 14 Mar 2016 17:44:20 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id l68so130970775wml.0 for ; Mon, 14 Mar 2016 17:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=5ELOFPuOsBlUA2ay+FCu8W42dCdZeVcDnEV+H74eUk0=; b=bVJqqxYV18qLXGEGSuF0EkOrnk3J9CTMLdcB6m0aranZnDN1Ufhnk52EMawyIM5Qvx +/q4SzX15OdvdDsWg7irdD+qch0L7Ugo0geLRn6haZ4DYJnrsYyXF2LjJKDuPFSJ73mV hNIOaz7/PgCvOeHtKJTgSzuDZpyczwTsPZ/OPhKnLvDSxiNEQ7K34Vc/j2EXThAWSFwj 69OwE1ZpdcCIIbFqoDPSBaxFuxgEquAj/QY/Kt4rpJ/bcMRLjeRt7y5WidIGdpKhviqf WaezLA1Qdgo86xyaHMINwS8XGxvn+zVTpB4L4AWeWYm8pNa3Q8U7H0PERZYk4itHOihi 4YkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=5ELOFPuOsBlUA2ay+FCu8W42dCdZeVcDnEV+H74eUk0=; b=WAinXVHtJaAqcmS1C8T2YwTqEajZ6MS0L1DlwjvS4MZafyzRrCcjG1onURxgvyKOXZ /L0wTNBaXnPW/MYhZl+7sJj2pKxLnjE19L/SG2XwRnCF0m7AatTsBABeR2rzyPdV8fRB Tu196K08npDdZm7kgGSHYupJOOgV7W4uomPVWd8HqU4PryTs7E73beuJrIA+zCbTZsaU ZHQcHpIFouJAM9tFpkvp2ZX73Y9jd49ftsUbdzfEi9pfTD4Y+JtYzSWsld2TOl/gH57l LrPL8eUQX5kvylfFex9vPSVvJLln1frk2f4P7ZCTqigkrZsW9OXY55s2lsr+txrhECo6 NLYg== X-Gm-Message-State: AD7BkJIl4IcQQk3pdR0Bi2BJWMXP5CL+zZF+6lvje+P2C5Newj/fhQI7z8/r3ajvCeYbGTNr7JUa+rNTRr848sLp MIME-Version: 1.0 X-Received: by 10.194.81.103 with SMTP id z7mr26544703wjx.25.1458002659322; Mon, 14 Mar 2016 17:44:19 -0700 (PDT) Received: by 10.28.30.75 with HTTP; Mon, 14 Mar 2016 17:44:19 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Mon, 14 Mar 2016 17:44:19 -0700 Message-ID: From: Ryan Hamilton To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=047d7bf0d1d697726a052e0bb2ae Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 00:44:23 -0000 --047d7bf0d1d697726a052e0bb2ae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8BOn Mon, Mar 14, 2016 at 2:04 PM, Colm MacC=C3=A1rthaigh wrote: > On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton wrote: >> >> On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton >> wrote: >> >>> 0-RTT seems to be a solution looking for a problem. >>> >> >> =E2=80=8BGoogle has been using 0-RTT as part of the QUIC transport for q= uite a >> while now. In April of last year, we posted about the performance >> benefits we're seeing from QUIC >> . >> Among other things, that post said: >> >> Even on a well-optimized site like Google Search, where connections are >> often pre-established, we still see a 3% improvement in mean page load t= ime >> with QUIC. >> >> >> From the browser side of things, 0-RTT is a solution to a very real >> problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT >> resumption) and converting QUIC to use the TLS 1.3 handshake as a result= . >> > > Are you sacrificing forward secrecy in this case? For a concrete example: > suppose $oppressive_government is collecting all traffic as a routine > matter of course, and then later a remote-ex, memory-disclosure, or > decrypt-oracle (like the recent DROWN) came along on the server side: > could it be used to decrypt all of $worthy_dissident's requests? how long > for, how do you manage that trade-off? > =E2=80=8BMy understanding is that QUIC's current 0-RTT scheme provides effe= ctively the same protection as TLS with perfect forward security, at least assuming that session resumption is enabled. This is because, as I understand it, even with PFS connections, and attacker who is able to compromise the server and access the session resumption key can do bad things. In our QUIC deployments, we limit the lifetime of the QUIC 0-RTT static secret to roughly the lifetime of our session resumption key. I confess, I am not an expert in this area and am relaying conversations I've had in the past. I hope I'm not making a mess of them. > On the "3% speed up" - we're not going to see that for TLS 1.3 though - > right? there's still the TCP handshake to perform; or is some kind of > custom TCP in the works? (does TCPCT work on the client side?). Do you ha= ve > any human perception data; to people even notice the 3% at this point? > (loading google seems remarkably fast!). There's a very strong temptatio= n > to bias for what's easy to measure here. > =E2=80=8BWe have other data (which I don't think we've published, at least = not in that post) which shows that this improvement is definitely perceptible to users. The improvements in response time are correlated with other metrics showing that users notice the improvements and behave accordingly. When we have screwed up 0-RTT (whoops, bug!) these metrics declined. Then when we fixed it again, they recovered. =E2=80=8BI could go on for a long time abou= t the various A/B experiments we have run, but suffice to say we're very confident that 0-RTT is a significant win. Keep in mind that 3% for search represents *all* page views, not just those that are the first on a connection, for which 0-RTT can be used. Many of those page views are on long lived questions for which 0-RTT did not come into plays, so the effect of 0-RTT on the page views which it sped up is amortized across all views. Hope that helps, Ryan --047d7bf0d1d697726a052e0bb2ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8BOn Mon, Mar 14, 2016 at 2:04 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net&g= t; wrote:
<= div class=3D"gmail_extra">
On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton <rch@google.com> wrote:
On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton <= ;n= oloader@gmail.com> wrote:
0-RTT seems to be a solution looking for a problem.
=C2=A0
=E2=80=8BGoogle has been using 0-RTT as part of = the QUIC transport for quite a while now. In April of last year, we posted about the performance benef= its we're seeing from QUIC. Among other things, that post said:

Even on a well-optimized site like Go= ogle Search, where connections are often pre-established, we still see a 3%= improvement in mean page load time with QUIC. =C2=A0

From the browser side of things, 0-RTT is a solution to = a very real problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RT= T resumption) and converting QUIC to use the TLS 1.3 handshake as a result.=

Are you sacrifici= ng forward secrecy in this case? For a concrete example: suppose $oppressiv= e_government is collecting all traffic as a routine matter of course, and t= hen later a remote-ex, memory-disclosure, or decrypt-oracle =C2=A0(like the= recent DROWN) came along on the server side: could it be used to decrypt a= ll of $worthy_dissident's requests? how long for, how do you manage tha= t trade-off?=C2=A0

=
=E2=80=8BMy understanding is that QUIC's current 0-RTT scheme= provides effectively the same protection as TLS with perfect forward secur= ity, at least assuming that session resumption is enabled. This is because,= as I understand it, even with PFS connections, and attacker who is able to= compromise the server and access the session resumption key can do bad thi= ngs. In our QUIC deployments, we limit the lifetime of the QUIC 0-RTT stati= c secret to roughly the lifetime of our session resumption key.
=

I confess, I am not an expert in this area an= d am relaying conversations I've had in the past. I hope I'm not ma= king a mess of them.
=C2=A0
<= div dir=3D"ltr">
= On the "3% speed up" - we're not going to see that for TLS 1.= 3 though - right? there's still the TCP handshake to perform; or is som= e kind of custom TCP in the works? (does TCPCT work on the client side?). D= o you have any human perception data; to people even notice the 3% at this = point? (loading google seems remarkably fast!).=C2=A0 There's a very st= rong temptation to bias for what's easy to measure here.=C2=A0

=E2=80=8BWe have = other data (which I don't think we've published, at least not in th= at post) which shows that this improvement is definitely perceptible to use= rs. The improvements in response time are correlated with other metrics sho= wing that users notice the improvements and behave accordingly. When we hav= e screwed up 0-RTT (whoops, bug!) these metrics declined. Then when we fixe= d it again, they recovered. =E2=80=8BI could go on for a long time about th= e various A/B experiments we have run, but suffice to say we're very co= nfident that 0-RTT is a significant win.

Keep in mind that 3% for search represents *all* page views, not just thos= e that are the first on a connection, for which 0-RTT can be used. Many of = those page views are on long lived questions for which 0-RTT did not come i= nto plays, so the effect of 0-RTT on the page views which it sped up is amo= rtized across all views.

Hope that helps= ,

Ryan

--047d7bf0d1d697726a052e0bb2ae-- From nobody Mon Mar 14 18:44:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36BE12D53E for ; Mon, 14 Mar 2016 18:44:36 -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 bf1clfHWCMdS for ; Mon, 14 Mar 2016 18:44:33 -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 81B2212D857 for ; Mon, 14 Mar 2016 18:44:26 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id d65so3717253ywb.0 for ; Mon, 14 Mar 2016 18:44: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=tMoAunR9O7vu92U/Cy6eaAODrk0YPD+CiSiBZ7ulgS0=; b=L/cyZ22d5MCxDmAg3BhafW8FC06tc29wIIv453ZzNHgySC7RnPOOBp866o3PVLIr+s S59RbyB61bimfhbQjJH9g2qEe7+Ej/oMdNwPkK8o1ENbM6b/4XiuMoaFpSaRotPZ2gLU X4Myw39u3U1ikiiHZ4R4PAKHR4COTrCslY4zI3YMuUT+cZ3ZcgTZc6ddBVnC6R7hrDHR S39BNjui3PRrPi0+Uw7Sl+cku56P7GBe2XcLoV13LBZvYnTKIU/8Q8YZmGtAVDhoUlo2 cjzGuZWTxojb2YGhky76+6DEFKpSja+8ujn5vEDI/M+oN7n4ag6HkqHgf0G7eKJ2S53K M11Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tMoAunR9O7vu92U/Cy6eaAODrk0YPD+CiSiBZ7ulgS0=; b=QblTXmXGNTn3eQRdSAJla8w5OzrwPCpeFCiJ0UATKY/YWG2GNcuJWFkVagT4pmkbBO VCDGp7KDLjwGUa70VLU4jorZrWK/adopHJhukmC1GbcjpE/+Ed+80VM3u420jmpWj1se KRu6p9XO0FfHu3okoyeqU/Y/FDcteomIlI5j+rxzlr8kHwbqZCvC8nBh88Avtt/jbtZ4 XuYrbdHy77rVHnE7fgoWYe23jud10oq3VeGZ1d3mx9LbJB5+KiZLdGk14/IggSSMzHsP v8OMI/EWzWS24ftbHZyH7d7n6EgLhswGQqgZSeFJERJSZyWqDALSDDHFmjauNRwrHrck ldBA== X-Gm-Message-State: AD7BkJIn2F4KRr8Q59tTPd3rLtfm6a0p5BT6mQuzF0zPyD2m0NibXqlHylx7d8uU+lJ6Siwx5moHPiScD00zYA== X-Received: by 10.129.80.69 with SMTP id e66mr15826863ywb.231.1458006265804; Mon, 14 Mar 2016 18:44:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 18:43:46 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> From: Eric Rescorla Date: Mon, 14 Mar 2016 18:43:46 -0700 Message-ID: To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a1147f0788debe2052e0c89ce Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:44:37 -0000 --001a1147f0788debe2052e0c89ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 5:44 PM, Ryan Hamilton wrote: > =E2=80=8BOn Mon, Mar 14, 2016 at 2:04 PM, Colm MacC=C3=A1rthaigh > wrote: > >> On Mon, Mar 14, 2016 at 3:15 PM, Ryan Hamilton wrote: >>> >>> On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton >>> wrote: >>> >>>> 0-RTT seems to be a solution looking for a problem. >>>> >>> >>> =E2=80=8BGoogle has been using 0-RTT as part of the QUIC transport for = quite a >>> while now. In April of last year, we posted about the performance >>> benefits we're seeing from QUIC >>> . >>> Among other things, that post said: >>> >>> Even on a well-optimized site like Google Search, where connections are >>> often pre-established, we still see a 3% improvement in mean page load = time >>> with QUIC. >>> >>> >>> From the browser side of things, 0-RTT is a solution to a very real >>> problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT >>> resumption) and converting QUIC to use the TLS 1.3 handshake as a resul= t. >>> >> >> Are you sacrificing forward secrecy in this case? For a concrete example= : >> suppose $oppressive_government is collecting all traffic as a routine >> matter of course, and then later a remote-ex, memory-disclosure, or >> decrypt-oracle (like the recent DROWN) came along on the server side: >> could it be used to decrypt all of $worthy_dissident's requests? how lon= g >> for, how do you manage that trade-off? >> > > =E2=80=8BMy understanding is that QUIC's current 0-RTT scheme provides ef= fectively > the same protection as TLS with perfect forward security, at least assumi= ng > that session resumption is enabled. This is because, as I understand it, > even with PFS connections, and attacker who is able to compromise the > server and access the session resumption key can do bad things. In our QU= IC > deployments, we limit the lifetime of the QUIC 0-RTT static secret to > roughly the lifetime of our session resumption key. > This is, I think, more or less true. In general, against complete compromise of the server at time X, the security is limited to whatever long-term key was used to protect that data. Generally, this means that tickets and static DHE are comparable against server key compromise [0], so for this kind of attack tickets and semi-static DH are roughly comparable (indeed, you could imagine having the configuration ID be an encryption of the semi-static DH key under the ticket key making them strictly comparable) [1]. The situation is obviously more complicated with attacks where you don't have control of the server (e.g., oracle-type stuff) and I suspect depends on the details of the attack. -Ekr [0] As AGL points out, client key compromise is somewhat different. [1] If you decide to instead store keying material on the server rather than use tickets, then TLS 1.3 PSK 0-RTT actually has somewhat better properties because you can negotiate a new key with each connection and establish a new "ticket", so the result is that compromise of the server is a future secrecy threat but not a threat to past connections. --001a1147f0788debe2052e0c89ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 5:44 PM, Ryan Hamilton <rch@google.com> wrote:
=E2=80= =8BOn Mon, Mar 14, 2016 at 2:0= 4 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
=
On Mon, Mar 14,= 2016 at 3:15 PM, Ryan Hamilton <rch@google.com> wrote:
On Sun, Mar 13, 2016 at 4:36 PM, Jeffrey Walton <noloader@gmail.com> wrote:
0-RTT seems to be a solution looking for a problem.
=
=C2=A0
=E2=80=8BGoogle has been using 0-RTT as part o= f the QUIC transport for quite a while now. In April of last year, we posted about the performance benefits we're = seeing from QUIC. Among other things, that post said:

Even on a well-optimized site like Google Search,= where connections are often pre-established, we still see a 3% improvement= in mean page load time with QUIC. =C2=A0

From the browser side of things, 0-RTT is a solution to a very real = problem. We are excited about TLS 1.3 supporting 0-RTT (or 0-RTT resumption= ) and converting QUIC to use the TLS 1.3 handshake as a result.
=

Are you sacrificing forward s= ecrecy in this case? For a concrete example: suppose $oppressive_government= is collecting all traffic as a routine matter of course, and then later a = remote-ex, memory-disclosure, or decrypt-oracle =C2=A0(like the recent DROW= N) came along on the server side: could it be used to decrypt all of $worth= y_dissident's requests? how long for, how do you manage that trade-off?= =C2=A0

=E2=80=8BMy underst= anding is that QUIC's current 0-RTT scheme provides effectively the sam= e protection as TLS with perfect forward security, at least assuming that s= ession resumption is enabled. This is because, as I understand it, even wit= h PFS connections, and attacker who is able to compromise the server and ac= cess the session resumption key can do bad things. In our QUIC deployments,= we limit the lifetime of the QUIC 0-RTT static secret to roughly the lifet= ime of our session resumption key.

This is, I think, more or less true.

In general, against complete compromise of the server at time X, t= he security is limited to whatever
long-term key was used to prot= ect that data. Generally, this means that tickets and static DHE
= are comparable against server key compromise [0], so for this kind of attac= k tickets and semi-static
DH are roughly comparable (indeed, you = could imagine having the configuration ID be an
encryption of the= semi-static DH key under the ticket key making them strictly comparable) [= 1].
The situation is obviously more complicated with attacks wher= e you don't have control of
the server (e.g., oracle-type stu= ff) and I suspect depends on the details of the attack.

-Ekr


[0] As AGL points out, c= lient key compromise is somewhat different.
[1] If you decide to = instead store keying material on the server rather than use tickets,
then TLS 1.3 PSK 0-RTT actually has somewhat better properties beca= use you can negotiate
a new key with each connection and establis= h a new "ticket", so the result is that compromise
of t= he server is a future secrecy threat but not a threat to past connections.<= /div>


--001a1147f0788debe2052e0c89ce-- From nobody Mon Mar 14 18:47:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35C12D6D6 for ; Mon, 14 Mar 2016 18:47:03 -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 IS_7hkYHVvCT for ; Mon, 14 Mar 2016 18:46:58 -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 5DA8F12D53E for ; Mon, 14 Mar 2016 18:46:52 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id d65so3771008ywb.0 for ; Mon, 14 Mar 2016 18:46: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=ZrrnLkjaIJMLgbRI+tVjW5wVe1Vwk70C4yIIedwDotc=; b=vbJrhrSa2zpSiFfZiACm1e5mR8X3ETI1YGmpPt3o7SIr6d8zXOfjCY2T6GHVB+/S7y KAWz2gmqex4UQDj0G8STiKX5ovfqlimhZetq3K6NfpcYqInkjsZmcH/MTzfKsKUMi/fB 9+FrJn6z6vN1srWnhUuHQMgtE2oLWNzRxrGf82Kh60r55FTsmFI0oZNUeEMCavByL2St 5aEgbHz0RT+b9mrNWNCWFANwdP8LITQJeUN6uepS8cQTh1qH81YzTTajtZri607Psbnt tnN6+HIvqz7jZi6OaJzOJQ3MTwIJNHbHcsX5pJa6yi6daCQPVNKkeTKwRCQGtjCgL/tj LbuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZrrnLkjaIJMLgbRI+tVjW5wVe1Vwk70C4yIIedwDotc=; b=JbpNEJzjhMzoM4VWSREvagXAnKRMwl6AdSAqk2KLrM+WoL9y0t75K0iL5EC15No894 A/5H56TbKjEb0bJGhP3O7LFvxyn4nSlVsq49rd+XIBokj5ko9deOQDfNJRGTVoFnn/ts JoeiXRpz5WZw7SrnfLWQeTkzdHHKAkkt/2NckfG8TxBbvwSywPhJZyd76y+iL6p0V6US W/Svzx+34OtzRhTVFHbkRpoLyEO4cQV5Mx4C2qbSkbEOEpgWP2qSyp/4lscY52ruH/UN 91iZDCwh9Tf2x4Yb0QeVegPzzPK5Er8rRINbome4vJN1d3aIleHZOHQmrLh+8GvDKWdR fF7g== X-Gm-Message-State: AD7BkJLXI+0OCJwYY15sF/o7dSKSnzgpqxrAZ2XwhV2iH/0hSMhDuMYOzTO3QaiH3isFI68Unv1Z3TAw8T+E6Q== X-Received: by 10.129.79.19 with SMTP id d19mr13380796ywb.115.1458006411645; Mon, 14 Mar 2016 18:46:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 18:46:11 -0700 (PDT) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <20160313212342.GA27160@odin.ulthar.us> <874mc9g895.fsf@setec.io> From: Eric Rescorla Date: Mon, 14 Mar 2016 18:46:11 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a114dad0e3f480a052e0c92f3 Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:47:03 -0000 --001a114dad0e3f480a052e0c92f3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox wrote: > On Mon, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh > wrote: > >> On Mon, Mar 14, 2016 at 8:35 AM, Bill Cox wrote= : >> >>> As we all know, what matters most in security is the default mode. I a= m >>> suggesting making the default 0-RTT resumption mode stateful, with a >>> documented session-ID (and let's bring back the timestamp, too, since w= e'll >>> need it). >>> >> >> Having state would make things much more robust; but rather than the >> state being around the channel itself (the TLS session), would it be mor= e >> robust, and more flexible, for the state to be around the action? like s= ome >> kind of hint cookie. >> > > It looks like server-side state is required to prevent replay. I don't > think any kind of token, cookie, or server-config can fix this. > > >> One of the problems with session resumption is that in order to be repla= y >> safe; the sequence number has to restart where it left off. That require= s >> some kind of transactional store, and if you're doing all of this for >> latency, you may end up eating all of the wins there. >> > > The new tickets can in theory end the debate over session caching vs > session tickets, since they can be used for database lookups or contain a= n > encrypted session state. However, the spec does not document how to do > session caching with tickets securely, which looks tricky. In reality, i= f > I were trying to build a speed and security sensitive site using TLS 1.3 > stateful 0-RTT resumption, I would probably do something like this: > > During the initial 1-RTT handshake: > - create a ticket containing only the session ID, resumption count, and a > session decryption key > - encrypt the session cache entry with the session encryption key stored > in the ticket > - encrypt the ticket with a semi-static ticket encryption key, which I > would rotate every few weeks > - send the ticket to the client, which is after encryption is enabled on > the connection > > During a 0-RTT resume handshake: > - check for a cache hit, and drop to 1-RTT if not found > - decrypt the ticket with ticket the semi-static ticket decryption key > - decrypt the cached session state with the session key from the ticket > - compare the resumption counts in the session state and ticket, and fall > back to 1-RTT if they do not match > - increment the resumption count > - create a new session ticket with a new session encryption key and the > updated resumption count > - encrypt the session cache entry with the new session encryption key > - send the client the new ticket > > I assume that it is legal to send a new ticket on a 0-RTT PSK resume, but > it is not clear to me from the drawings in the spec. It is not shown as = an > option. This is required for secure stateful 0-RTT resumption. > Yes, this is legal. I'll see if I can clarify this in the text. -Ekr I think this scheme minimizes data sent over the wire (to reduce latency) > and provides improved PFS vs using a non-encrypted session cache. Since > tickets are sent after encryption has been enabled, leaking the semi-stat= ic > ticket encryption key does not enable an eavesdropper to decrypt past > sessions, as was the case in TLS 1.2. If the server is compromised, this > scheme protects the session cache from being decrypted, so PFS is > preserved, unlike the case with either TLS 1.2 session caches with no > encryption or TLS 1.2 tickets with semi-static ticket keys. Leaking eith= er > the session cache or ticket encryption key would allow prior TLS 1.2 > sessions to be decypted. > > Bill > --001a114dad0e3f480a052e0c92f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 14, 2016 at 11:38 AM, Bill Cox <waywardgeek@google.co= m> wrote:
=
On M= on, Mar 14, 2016 at 9:10 AM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:
On Mon, Mar 1= 4, 2016 at 8:35 AM, Bill Cox <waywardgeek@google.com> w= rote:
As we all know, what matters most in security is the default= mode.=C2=A0 I am suggesting making the default 0-RTT resumption mode state= ful, with a documented session-ID (and let's bring back the timestamp, = too, since we'll need it).
Having state would make things much more robust; but rat= her than the state being around the channel itself (the TLS session), would= it be more robust, and more flexible, for the state to be around the actio= n? like some kind of hint cookie.=C2=A0

It looks like server-side state is required to = prevent replay.=C2=A0 I don't think any kind of token, cookie, or serve= r-config can fix this.
=C2=A0
=
One of the problems with session resumption is that in order to be rep= lay safe; the sequence number has to restart where it left off. That requir= es some kind of transactional store, and if you're doing all of this fo= r latency, you may end up eating all of the wins there.

The new tickets can in theory e= nd the debate over session caching vs session tickets, since they can be us= ed for database lookups or contain an encrypted session state.=C2=A0 Howeve= r, the spec does not document how to do session caching with tickets secure= ly, which looks tricky.=C2=A0 In reality, if I were trying to build a speed= and security sensitive site using TLS 1.3 stateful 0-RTT resumption, I wou= ld probably do something like this:

During the ini= tial 1-RTT handshake:
- create a ticket containing only the sessi= on ID, resumption count, and a session decryption key
- encrypt t= he session cache entry with the session encryption key stored in the ticket=
- encrypt the ticket with a semi-static ticket encryption ke= y, which I would rotate every few weeks
- send the ticket to the = client, which is after encryption is enabled on the connection
During a 0-RTT resume handshake:
- check for a cache= hit, and drop to 1-RTT if not found
- decrypt the ticket with ti= cket the semi-static ticket decryption key
- decrypt the cach= ed session state with the session key from the ticket
- compa= re the resumption counts in the session state and ticket, and fall back to = 1-RTT if they do not match
- increment the resumption count
=
- create a new session ticket with a new session encryption key and th= e updated resumption count
- encrypt the session cache entry with= the new session encryption key
- send the client the new tic= ket

I assume that it is legal to send a new ticket= on a 0-RTT PSK resume, but it is not clear to me from the drawings in the = spec.=C2=A0 It is not shown as an option.=C2=A0 This is required for secure= stateful 0-RTT resumption.

Yes, this is legal. I'll see if I can clarify this in the text= .

-Ekr

I think this scheme minimizes data sent over the wire (to re= duce latency) and provides improved PFS vs using a non-encrypted session ca= che.=C2=A0 Since tickets are sent after encryption has been enabled, leakin= g the semi-static ticket encryption key does not enable an eavesdropper to = decrypt past sessions, as was the case in TLS 1.2.=C2=A0 If the server is c= ompromised, this scheme protects the session cache from being decrypted, so= PFS is preserved, unlike the case with either TLS 1.2 session caches with = no encryption or TLS 1.2 tickets with semi-static ticket keys.=C2=A0 Leakin= g either the session cache or ticket encryption key would allow prior TLS 1= .2 sessions to be decypted.

Bill

--001a114dad0e3f480a052e0c92f3-- From nobody Mon Mar 14 19:22:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918E912D860 for ; Mon, 14 Mar 2016 19:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dRDJrTyIFldy for ; Mon, 14 Mar 2016 19:22:34 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F364712D859 for ; Mon, 14 Mar 2016 19:22:33 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id av4so77159495igc.1 for ; Mon, 14 Mar 2016 19:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=dR7/RZDJWCr1XAqibZ+qdL3/H6vUgdzzT14ETYK2Nis=; b=LAj18QuUde8YF4agXVRDdkyxOEoNA3zuVDyxC4v3s4f2lpitc806hsgw8CVi3sYPe/ btT+OzBfQzKF7oRpH5T+i9hnce1lTuUPM+bmJew4gMpwLzRC26ZR6Z+wae4YsQ46yjaW IiiW959p7GndZRgsXCosQyQcFid8FYysX9Af97rhaAx3PzpkTAEtCIWTzeElveTtXaeP 5qAjxFizoZU1uNE3ghTnRyYS5AtsUnd8rxLHUFEsEiXVqHrztmj4VqxkXWwACb3hRomH C33WrGY/kILjIvuzJe3Ww7o3tbxF5wbtBHpFMGihqQJb8xBOIQVWOQyNtK0RQd0JtTsz gu8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dR7/RZDJWCr1XAqibZ+qdL3/H6vUgdzzT14ETYK2Nis=; b=kxGu8Vjz2QUaaXgVD37r53epII9wQGQTDXMbV9jJ1aX9zdA7exbgebjIA01iXOIF2o /HSmJWWR/cuMnSfHYF4OeKvDZrseNI2MsyxJ4SM2OSXzGevXpfz1S9nwlAH88xgnOWgw ZDEmpGENcGbP8GaSCkNLz8jJWE0j8hbtsQ7OPJhJSuXF/Vyjsx5gtpi6Y4H41jMCDj6u eGilEoMpB5OuaXNitWQs6jncgBuZLKNNQqvcJFkQW+6WFdFIOsk57lJlwy7EAXav9Fvn Weo3rCf6T1J3OlcztknoFoLCpZTRNcbpc+VMyG76raySqNuGBsNgQw5K+1r0Kof/WEYu b4/A== X-Gm-Message-State: AD7BkJKRRMqQElwRockDGqn4Mc7MGtqcRwvSvAbZHeEOTvMo1id0NTCzXQrkOJF0rSeyimGWSzBgPgF12Ja58coL MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr21391562igr.4.1458008553056; Mon, 14 Mar 2016 19:22:33 -0700 (PDT) Received: by 10.107.183.141 with HTTP; Mon, 14 Mar 2016 19:22:32 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Mon, 14 Mar 2016 19:22:32 -0700 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7bea423ee2ce59052e0d115a Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 02:22:35 -0000 --047d7bea423ee2ce59052e0d115a Content-Type: text/plain; charset=UTF-8 I am probably reading this wrong, but isn't the PFS problem with tickets fixed in TLS 1.3? In TLS 1.2, they were sent to clients before ChangeCipherSpec, so given the server-side ticket encryption key, an attacker could decrypt past tickets, and then use that data to decrypt past sessions. In TLS 1.3, tickets are sent after the full handshake completes, after encryption is enabled for the connection. Now, if an attacker has the ticket encryption key, it is not possible to decrypt old connections. Is that right? It looks to me like tickets have real PFS in TLS 1.3. Bill --047d7bea423ee2ce59052e0d115a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am probably reading this wrong, but isn't the PFS pr= oblem with tickets fixed in TLS 1.3?=C2=A0 In TLS 1.2, they were sent to cl= ients before ChangeCipherSpec, so given the server-side ticket encryption k= ey, an attacker could decrypt past tickets, and then use that data to decry= pt past sessions.

In TLS 1.3, tickets are sent after the= full handshake completes, after encryption is enabled for the connection.= =C2=A0 Now, if an attacker has the ticket encryption key, it is not possibl= e to decrypt old connections.=C2=A0 Is that right?=C2=A0 It looks to me lik= e tickets have real PFS in TLS 1.3.

Bill
--047d7bea423ee2ce59052e0d115a-- From nobody Mon Mar 14 19:26:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0052112D55B for ; Mon, 14 Mar 2016 19:26:01 -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 2ibbbUEQZjFJ for ; Mon, 14 Mar 2016 19:25:59 -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 34F8912D53E for ; Mon, 14 Mar 2016 19:25:59 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id n190so8023978iof.0 for ; Mon, 14 Mar 2016 19:25:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MKTGgUKaHO/BEFiGImdb1kL0hFOYs+BEtxJBEa60NAU=; b=BTLVpf1Em/XG6X0W6QsWqkT3kPO3zFCS8qCKBSSRZNglpvMNwklwXL+4qYP+rzrF2+ qcFDr8uf6sdchodZ0zQDQyC4qPnlAUBNXKITXb8cUtvY+/kswdoAf2JCjUArjoQqUsSt 7vGGxu8WG0cHP3g5BvCTMH89t07jzQZ3p29AYs/VMaqYA6Dj7u9bLSh5X+JqGiOnjt4i oDvme+TdlCl9vQdncpQGCSW8YxEahPpCp/v9Fsvw2lyObrgY194vdtZyoZx2MbtnLtU4 MPcLUS0Kg/32n5C9fRXXKFYIGeK8tKX4hGNJt4T1Y258ptBYWRAkGdMZ97ql9PvxRR1y OMTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=MKTGgUKaHO/BEFiGImdb1kL0hFOYs+BEtxJBEa60NAU=; b=kzNRZP5eLd0PRZakF00Xd2b+DVe/P0MgLaVhxNzoS5hsIc7UzrMTDQod+8S83lu/NY YvVemEuvWfZ9cSKCC98olALty7fv6q6gBQzGQG41Bs5h0VNxbpDrJtzqO11pnzhyc39X VtUgBLT9EC1UGJSvgAGlzBJBs6ITsvBewGNuWsZl7GvcACCHlzQpz/f2cr9QyqlKFkIy 7IQzUKSAYdPz6OU3qmHVm73pEtvbeAxhVsTLqHLtBTjQCj8np9tNzq+6u/a4hLjk+bW+ +jAKo9/jzWyZAFsx7s/bsKxXj5mr9TG8BKbjBitKEP6oYj2FKfIcETuLftijCy9eleA8 E8/A== X-Gm-Message-State: AD7BkJJBWK6+7brCllMtwAYCSTOCW+z6psIFg79ljiwHfqzo6UHca57rgx55FHRaxNY/gG7pz1WevZlqmZJk5w== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr27720387iop.100.1458008758456; Mon, 14 Mar 2016 19:25:58 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Mon, 14 Mar 2016 19:25:58 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> Date: Tue, 15 Mar 2016 13:25:58 +1100 Message-ID: From: Martin Thomson To: Bill Cox Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 02:26:01 -0000 On 15 March 2016 at 13:22, Bill Cox wrote: > In TLS 1.3, tickets are sent after the full handshake completes, after > encryption is enabled for the connection. Now, if an attacker has the > ticket encryption key, it is not possible to decrypt old connections. Is > that right? It looks to me like tickets have real PFS in TLS 1.3. It's the properties of the session that matter here, not the tickets. The tickets are sent in the clear in the resumed handshake. From nobody Mon Mar 14 20:00:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1CF12D855 for ; Mon, 14 Mar 2016 20:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MUioNNix5C-G for ; Mon, 14 Mar 2016 20:00:30 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCF912D848 for ; Mon, 14 Mar 2016 20:00:30 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g3so5199305ywa.3 for ; Mon, 14 Mar 2016 20:00:30 -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=nnHYQlOYHnexlxHlp21KmbjQxyArf6M1bpH48pwiS58=; b=E6vxUrWqsNbQu4ZQu5mSXI+G36T2+oBLUyDlm96adOqAwVk39Odg3Q4kmhM4ZnMcSJ tGPHxICri0rKLkCEcTDZkOls4UXlRi2EINKUc8U8Bfe1lR521JmoDAsEVn8C5kBV6jQk HiCTEFL1xRlf2I55f/twgBvZR94Ysp2pw+7eQj4sO8BPxVXScbfj1uK9vi+jpgDFsZyh J2J8Rn2Hfy/I0Ybg9b27xlIz9PXWAmhRW6xGuvxjIkcKlVpgUvsktrPgPHJKxLqmy1wA 6Gb4GhfZdcRRKWvy80hO/SKUy8xcIJ0MCyVMQxcd4iHUYF1nIJfcHunSzOXkz1Bl/1dO SvrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nnHYQlOYHnexlxHlp21KmbjQxyArf6M1bpH48pwiS58=; b=VqT+J/TeDJ1JHPJLX5Dl5HlQUSHe80mEx3q0MDXPQWEyv3u4YpZqICBtfdhnbj0H9f DT+r/GGjX9GL5dcw+ZcKOqK4Xc7SMo4koSIPFLbnu1RYizADJINzOoyONW2AdzuM/Waz 7/S8HAzuxf+ls0HZOuGdqNU8EtIeucbxWZHno2zJj4VpdQonN69Fmxd6QEHvgAh7xbLf XdmJw+0DUgM8UPC4TccuYfqRcGBiamrOT/tdN4KA3JTIXUJeO8dUDzUlO4NtLazPbD3Y 9HHTAkKFNHk61SsHNOmBxxjcYCRlY7GsL5FN5Sj28xvwfkbUs2zaeZL1X3UwI1oBGU6Y HXnA== X-Gm-Message-State: AD7BkJLsOIoxunR6VfoYMzB7UGvmQhP3bG4PRYfQC9PWv4DW3xmi9l6Op1aaqULEr0GCGdxuf2MAbLRAoiqZpg== X-Received: by 10.37.230.202 with SMTP id d193mr14781096ybh.74.1458010829917; Mon, 14 Mar 2016 20:00:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 14 Mar 2016 19:59:50 -0700 (PDT) In-Reply-To: References: <8A79BFEDF6986C46996566F91BB63C860D64EA3F@PRN-MBX02-1.TheFacebook.com> <911B10A5-12F5-4094-A832-3FA06834862B@gmail.com> From: Eric Rescorla Date: Mon, 14 Mar 2016 19:59:50 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0afb0e98f307052e0d9950 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Limiting replay time frame of 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:00:32 -0000 --94eb2c0afb0e98f307052e0d9950 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 7:25 PM, Martin Thomson wrote: > On 15 March 2016 at 13:22, Bill Cox wrote: > > In TLS 1.3, tickets are sent after the full handshake completes, after > > encryption is enabled for the connection. Now, if an attacker has the > > ticket encryption key, it is not possible to decrypt old connections. Is > > that right? It looks to me like tickets have real PFS in TLS 1.3. > > > It's the properties of the session that matter here, not the tickets. > > The tickets are sent in the clear in the resumed handshake. > Right. As far as I can tell, that's required. TLS 1.3 PFS *is* much better with respect to tickets because the ticket established in connection N cannot be used to decrypt that connection. In addition, because you can do PSK-ECDHE, you can confine the PFS risk to the 0-RTT data. -Ekr --94eb2c0afb0e98f307052e0d9950 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 14, 2016 at 7:25 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 15 March 2016 at 13:22, Bill Cox <waywardgeek@google.com> wrote:
> In TLS 1.3, tickets are sent after the full handshake completes, after=
> encryption is enabled for the connection.=C2=A0 Now, if an attacker ha= s the
> ticket encryption key, it is not possible to decrypt old connections.= =C2=A0 Is
> that right?=C2=A0 It looks to me like tickets have real PFS in TLS 1.3= .


It's the properties of the session that matter here, not the tic= kets.

The tickets are sent in the clear in the resumed handshake.

Right. As far as I can tell, that's required. TLS = 1.3 PFS *is* much better with
respect to tickets because the tick= et established in connection N cannot
be used to decrypt that con= nection. In addition, because you can do PSK-ECDHE,
you can confi= ne the PFS risk to the 0-RTT data.

-Ekr
= =C2=A0

--94eb2c0afb0e98f307052e0d9950-- From nobody Tue Mar 15 00:50:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B8C12D919 for ; Tue, 15 Mar 2016 00:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qet8D4qIa2iG for ; Tue, 15 Mar 2016 00:50:44 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5B30B12D83D for ; Tue, 15 Mar 2016 00:50:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 37C4E15A7; Tue, 15 Mar 2016 09:50:42 +0200 (EET) 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 qd7luXMFoX2E; Tue, 15 Mar 2016 09:50:42 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 0FFB72310; Tue, 15 Mar 2016 09:50:42 +0200 (EET) Date: Tue, 15 Mar 2016 09:50:40 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160315075040.GA18864@LK-Perkele-V2.elisa-laajakaista.fi> References: <56E54B85.4050204@cs.tcd.ie> <201603141525.29198.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Scott Schmit , "tls@ietf.org" Subject: Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 07:50:46 -0000 On Mon, Mar 14, 2016 at 12:32:51PM -0700, Eric Rescorla wrote: > > As far as I can tell, there's no protocol difference between "stateful" and > "stateless" resumption. > You use the same techniques (a replay cache) and the question is merely > whether the server > actually maintains one. Agreed. If the server maintains replay cache, one gets replay limited to one per 0RTT connection even with DH-0RTT. And without server replay cache, one gets near-infinite replay per 0RTT connection, no matter what client does (other than 0*$VERYLARGE=0). -Ilari From nobody Tue Mar 15 00:55:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DE112D940 for ; Tue, 15 Mar 2016 00:55:09 -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 E0is4QVk68yj for ; Tue, 15 Mar 2016 00:55:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D8812D7FC for ; Tue, 15 Mar 2016 00:55:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B7BC7284D9C; Tue, 15 Mar 2016 07:55:06 +0000 (UTC) Date: Tue, 15 Mar 2016 07:55:06 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160315075506.GG6602@mournblade.imrryr.org> References: <56E54B85.4050204@cs.tcd.ie> <201603141525.29198.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Splitting all stateless 0RTT into its own document (was Re: analysis of wider impact of TLS1.3 replayabe data) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list 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 Mar 2016 07:55:09 -0000 On Mon, Mar 14, 2016 at 12:32:51PM -0700, Eric Rescorla wrote: > As far as I can tell, there's no protocol difference between "stateful" and > "stateless" resumption. > You use the same techniques (a replay cache) and the question is merely > whether the server > actually maintains one. Experience with "replay caches" in Kerberos shows that they don't work in the vast majority of cases. Protocols need to be safe without replay caches. -- Viktor. From nobody Tue Mar 15 10:37:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0B912DBA6 for ; Tue, 15 Mar 2016 10:37:33 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6THbgD8YIza for ; Tue, 15 Mar 2016 10:37:30 -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 B38CC12DBA2 for ; Tue, 15 Mar 2016 10:37:30 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g203so32976470iof.2 for ; Tue, 15 Mar 2016 10:37:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7lHYj9stey376+wMwembdj+ka8bPdueydQiJVj4Mjps=; b=RPNDP9xc1NejRfxcUVg7lqqpAt4g6I+/AA4b/X5pBxTO1We/cMxLpNoFAN6eQuAmXg +IumGuSoKAv8tYKdgw5uawgnGIGmhLzXjN16s4txw//sKSE5982mWTcXbhc3xrM7TTeJ iKd6Xs5+yHkMAQs/AvwVKEVqMYyu05GGnEcN0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7lHYj9stey376+wMwembdj+ka8bPdueydQiJVj4Mjps=; b=DXG3PehY2EDGKdt4+/1RZByZ8cnTJsmdYBB/Ej574dcMBm1VJ1EV3d0WQLQK0eslaK rx+b5TrYRGR1U9E/lZUDJ5+TyMUIl/CadHIMtJ4vniNzYEk5/8I0oncvd/IsVWv5WvuY hkQdtkI+Jcx5pXJV03MDSyRlS8g2fhvZMnwX2ZUtGNzy9hD6jHZli5wKHwX2zbSdLUiv 8149t3z8rjEb2MOSTbll8Qiw7XLL6t+Uyhg+dF32kcuxgS+oBlLyo7OAoA/SsPGTn0bh fCSBTyzUxA1d0ppAm4b/7Ptf72GeqfE7fEaAIT9Npca6ufVbyIYRFXR1e2stBCRfOOCQ fM2Q== X-Gm-Message-State: AD7BkJJzLzFn/Q0mtZyaB65SFYRpUnOTetFJM6WeVe3QZ2mH3JlrtOcHhpHn5kAwohJ5xQyNW186snTwuDa88jYH X-Received: by 10.107.165.140 with SMTP id o134mr36840179ioe.62.1458063449483; Tue, 15 Mar 2016 10:37:29 -0700 (PDT) MIME-Version: 1.0 References: <201601152007.12464.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Tue, 15 Mar 2016 17:37:20 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1141fb90f7ca83052e19d9ba Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:37:33 -0000 --001a1141fb90f7ca83052e19d9ba Content-Type: text/plain; charset=UTF-8 On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > David, > > Thanks for being patient with me here. Sorry it took so long > > As usual, this seems like a question of whether we're going to want a lot > of flexibility > (thus motivating orthogonal negotiation) versus whether we're going to > want little flexibility > (thus motivating suites). I think that with the historical practice, the > arguments for orthogonal > negotiation were a lot stronger, but now that we seem to be leaning > towards (a) fewer algorithms > and (b) having algorithms which are themselves suites, I do agree that the > pendulum is swinging > more towards suites. > I would probably characterize it less as suites vs orthogonality, but as wanting to keep divisions in meaningful and universal places and not splitting up tightly-coupled decisions. The flexibility from orthogonality can be handy, but going too far---as I believe TLS 1.2 did with signature, prehash, and curve---complicates everything. Imagine if negotiating AES_128_GCM required separately negotiating block cipher AES-128, mode CTR, and MAC GHASH. On balance, I guess, I'm neutral-to-supportive of this change in general, > if others in the WG want > to make it. On the details: > > - It seems like we could let measurements tell us what code points we > need. If we never see > P256-SHA512 in the wild, then we don't need it (and can add it later if > needed). > I guess this relates to the fun issue of how TLS sigalgs interacts with X.509. If we believe they are at most a hint for X.509, then I think we can freely declare that TLS 1.3+ requires curve/hash matching for NIST curves. Unlike PKCS#1 v1.5, I doubt anyone has smartcards that can only sign P384-SHA256. If we believe that non-matching certificates are forbidden in TLS, then, yeah, it's a concern. I searched CT logs some time ago and found some cases of P384-SHA256, but that was it. https://www.ietf.org/mail-archive/web/tls/current/msg19089.html I went with the small set for the draft text since it's a little cleaner and seemed to be what most preferred, but I would be fine with allocating P384-SHA256 too. Or maybe all 6 non-truncating values. (Or even the full 9 from my original proposal but, as others pointed out to me, P256-SHA384, P256-SHA512, and P384-SHA512 are kinda silly.) - I took a quick look at the PR and I'm not sure that some of the code > points assignments are > right. I made comments. > Fixed those. Apparently I shifted most of the hashes by one. Sorry about that! > - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll > probably want to define > code points for 1.5 in both in-protocol (CertificateVerify) and > certificates to distinguish these. > Oh? Why would they need to be separate? The others defined for both aren't. David > As far as process, it seemed like people were generally positive about > this in this discussion, > but I'll rely on the chairs to determine consensus. > > -Ekr > > > > > > > > > > > > > > On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin > wrote: > >> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: >> >>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin >>> wrote: >>> >>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett >>>> wrote: >>>> >>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In >>>>> TLS >>>>> > 1.2, signature algorithms are spread across the handshake. >>>>> [...] >>>>> > I propose we fold the negotiable parameters under one name. >>>>> [...] >>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>>> SignatureAndHashAlgorithm as >>>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>>>> that >>>>> > instead. >>>>> >>>>> I previously proposed this here: >>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>>> >>>>> ekr was against it, though it hasn't been discussed that throughly. >>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>>> >>>> >>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and >>>> forgot. >>>> >>>> ekr, are you still against this sort of thing? I think the new CFRG >>>> signature algorithms tying decisions together is a good argument for why >>>> we'd want this. If we believe this trend is to continue (and I hope it >>>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>>> seems poor. >>>> >>> >>> I'm not sure. I agree that the CFRG thing seems to be a new development. >>> I'll >>> try to confirm my previous opinion or develop a new one over the weekend >>> :) >>> >> >> ekr, did you have confirmed or new thoughts on this change? >> >> From elsewhere in the thread, I put together a draft PR if you wanted >> something to look at in that form. >> https://github.com/tlswg/tls13-spec/pull/404 >> It incorporated some of the suggestions in the thread (not mentioning the >> really legacy values, pairing NIST curves with hashes, etc.), but that's >> not the important part. The meat of the proposal is unifying signature >> algorithms under one number and a shared interface, which I think is a >> valuable simplification. >> >> David >> > > --001a1141fb90f7ca83052e19d9ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Mar 14= , 2016 at 8:22 PM Eric Rescorla <ekr@rtf= m.com> wrote:
David,

Thanks for being patient with me he= re. Sorry it took so long

As usual, this seems lik= e a question of whether we're going to want a lot of flexibility
<= div>(thus motivating orthogonal negotiation) versus whether we're going= to want little flexibility
(thus motivating suites). I think tha= t with the historical practice, the arguments for orthogonal
nego= tiation were a lot stronger, but now that we seem to be leaning towards (a)= fewer algorithms
and (b) having algorithms which are themselves = suites, I do agree that the pendulum is swinging
more towards sui= tes.

I would probably character= ize it less as suites vs orthogonality, but as wanting to keep divisions in= meaningful and universal places and not splitting up tightly-coupled decis= ions. The flexibility from orthogonality can be handy, but going too far---= as I believe TLS 1.2 did with signature, prehash, and curve---complicates e= verything. Imagine if negotiating AES_128_GCM required separately negotiati= ng block cipher AES-128, mode CTR, and MAC GHASH.

On balance, I guess, I'= m neutral-to-supportive of this change in general, if others in the WG want=
to make it. On the details:

- It seems = like we could let measurements tell us what code points we need. If we neve= r see
=C2=A0 P256-SHA512 in the wild, then we don't need it (= and can add it later if needed).

I guess this relates to the fun issue of how TLS sigalgs interacts with X= .509. If we believe they are at most a hint for X.509, then I think we can = freely declare that TLS 1.3+ requires curve/hash matching for NIST curves. = Unlike PKCS#1 v1.5, I doubt anyone has smartcards that can only sign P384-S= HA256.

If we believe that non-matching certificate= s are forbidden in TLS, then, yeah, it's a concern. I searched CT logs = some time ago and found some cases of P384-SHA256, but that was it.

I went with the small set for the draft text = since it's a little cleaner and seemed to be what most preferred, but I= would be fine with allocating P384-SHA256 too. Or maybe all 6 non-truncati= ng values. (Or even the full 9 from my original proposal but, as others poi= nted out to me, P256-SHA384, P256-SHA512, and P384-SHA512 are kinda silly.)=

-= I took a quick look at the PR and I'm not sure that some of the code p= oints assignments are
=C2=A0 right. I made comments.
<= /blockquote>

Fixed those. Apparently I shifted most of t= he hashes by one. Sorry about that!
=C2=A0
- If we decide to allow PKCS#1 v1.5 for= in-protocol signatures, then we'll probably want to define
= =C2=A0 code points for 1.5 in both in-protocol (CertificateVerify) and cert= ificates to distinguish these.

= Oh? Why would they need to be separate? The others defined for both aren= 9;t.

David
=C2=A0
As far as process, it seemed like peopl= e were generally positive about this in this discussion,
but I= 9;ll rely on the chairs to determine consensus.

-E= kr











=
On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin = <davidben@chromium.org> wrote:
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <dav= idben@chromium.org> wrote:
=
On Fri, = Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm David = Benjamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG = thing seems to be a new development. I'll
try to confirm = my previous opinion or develop a new one over the weekend :)

ekr, did you have confirmed or new thoughts on this= change?

From elsewhere in the thread, I put together a draft PR if = you wanted something to look at in that form.
https://github.com/tlswg/t= ls13-spec/pull/404
It incorporated some of the suggestion= s in the thread (not mentioning the really legacy values, pairing NIST curv= es with hashes, etc.), but that's not the important part. The meat of t= he proposal is unifying signature algorithms under one number and a shared = interface, which I think is a valuable simplification.

David

--001a1141fb90f7ca83052e19d9ba-- From nobody Tue Mar 15 12:40:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEF512DD29; Tue, 15 Mar 2016 12:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qK2M0eiRWur; Tue, 15 Mar 2016 12:40:43 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC6A12DB90; Tue, 15 Mar 2016 12:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2644; q=dns/txt; s=iport; t=1458070835; x=1459280435; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mQvn7qTCqdb12Dk7ZjTgqpKH8Cq8e6xItSzV6wi2lVA=; b=Pvb/XauI7X6FV6Wq2+7YB/cXHXcqTy0dePQp0iyN7/Z6WJ4jrfW6ZRZJ y62H8WDUEwUcQCqz7IGYv0/LxCPjjX0vFI6ME52Ut9PPzQtrMFSkofAQ5 Cvz0Adfrqg4V632j8Qjs4MEL9eehf+nmHqRTdsANnmSil5hau0jfupNEZ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgDgZOhW/4UNJK1eg0ZUbgaCb7daA?= =?us-ascii?q?Q2BbhcKhWwCHIEgOBQBAQEBAQEBZCeEQQEBAQMBAQEBCRcROgsFCQICAQYCDgo?= =?us-ascii?q?CAiMDAgICGQwLFAEQAgQOBYgfCA6RfJ0Xj0MBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QERBAR4hxEIgkeECwsGARwYgmorgQ8Fh2CPbwGFbogSjwWOfgEeAQFCg2VqiSk?= =?us-ascii?q?IFx1+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,340,1454976000"; d="scan'208";a="247881983" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 15 Mar 2016 19:40:20 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u2FJeKGr031512 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 19:40:20 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 15:40:19 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 15:40:19 -0400 From: "Cullen Jennings (fluffy)" To: Joseph Salowey Thread-Topic: [AVTCORE] [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 Thread-Index: AQHRfvKBLcIaICd8nUqceCru2fPCvA== Date: Tue, 15 Mar 2016 19:40:19 +0000 Message-ID: References: <56A8904D.10307@ericsson.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: [10.20.249.165] Content-Type: text/plain; charset="utf-8" Content-ID: <2EFA4F1A55336D489651D275F88706D3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" , "avt@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:40:45 -0000 DQpJIHRoaW5rIHRoaXMgZHJhZnQgbmVlZHMgV0dMQyBpbiBhbGwgdGhlIFdHcyB3aGVyZSBpdCBs aW1pdHMgdGhlIGV4aXN0aW5nIGNvZGUgc3BhY2UuIA0KDQoNCj4gT24gRmViIDcsIDIwMTYsIGF0 IDEwOjIxIFBNLCBKb3NlcGggU2Fsb3dleSA8am9lQHNhbG93ZXkubmV0PiB3cm90ZToNCj4gDQo+ IFRoaXMgZG9jdW1lbnQgaXMgcmVsZXZhbnQgdG8gdGhlIFRMUyB3b3JraW5nIGJlY2F1c2UgaXQg cmVzZXJ2ZXMgYSBsYXJnZSBwb3J0aW9uIG9mIHRoZSBUTFMgY29udGVudCB0eXBlIHNwYWNlLiAg VGhlIHZhbHVlcyAwLTE5IGFuZCA2NC0yNTUgY2Fubm90IGJlIHVzZWQgd2l0aG91dCBjaGVja2lu ZyBmb3IgY29uZmxpY3RzIHdpdGggU1JUUC1EVExTJ3Mgd2Fja3kgZGVtdWx0aXBsZXhpbmcgc2No ZW1lLiAgIEluIFRMUyAxLjMgd2Ugd2lsbCBtb3ZlIG1vcmUgZW5jcnlwdGVkIGNvbnRlbnQgdHlw ZXMgd2hpY2ggc2hvdWxkIGxpbWl0IHRoZSBpbXBhY3QgdGhpcyB1bmZvcnR1bmF0ZSBkZXNpZ24g b24gVExTIGV2b2x1dGlvbiwgYnV0IHRoZSB3b3JraW5nIGdyb3VwIHNob3VsZCBiZSBhd2FyZSBv ZiB0aGlzLiAgDQo+IA0KPiBDaGVlcnMsDQo+IA0KPiBKb2UNCj4gDQo+IE9uIFdlZCwgSmFuIDI3 LCAyMDE2IGF0IDE6MzkgQU0sIE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20+IHdyb3RlOg0KPiBBVlRDT1JFIGFuZCBUTFMsDQo+IA0KPiBUTFMgV0csIHlv dSBhcmUgaW5jbHVkZWQgaW4gdGhpcyBXRyBsYXN0IGNhbGwsIGFzIHRoaXMgZG9jdW1lbnQgYWZm ZWN0cyB0aGUgVExTIENvbnRlbnRUeXBlIElBTkEgcmVnaXN0cnkuDQo+IA0KPiBUaGlzIGVtYWls IHN0YXJ0cyBhIHR3byB3ZWVrIFdHIGxhc3QgY2FsbCwgdGhhdCBlbmRzIG9uIHRoZSAxMHRoIG9m IEZlYnJ1YXJ5LiBUaGUgaW50ZW5kZWQgc3RhdHVzIG9mIHRoaXMgZG9jdW1lbnQgaXMgc3RhbmRh cmRzIHRyYWNrIChQcm9wb3NlZCBTdGFuZGFyZCkuDQo+IA0KPiBUaGUgZG9jdW1lbnQgY2FuIGJl IHJldHJpZXZlZCBoZXJlOg0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1pZXRmLWF2dGNvcmUtcmZjNTc2NC1tdXgtZml4ZXMvDQo+IA0KPiBDaGVlcnMNCj4gDQo+IE1h Z251cyBXZXN0ZXJsdW5kDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IFNlcnZpY2VzLCBNZWRpYSBh bmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0 ODI4Nw0KPiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0 OTA3OQ0KPiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW4gfCBtYWlsdG86IG1hZ251cy53ZXN0 ZXJsdW5kQGVyaWNzc29uLmNvbQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+ IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs cw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQoNCg== From nobody Tue Mar 15 12:44:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEECD12D667; Tue, 15 Mar 2016 12:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.522 X-Spam-Level: X-Spam-Status: No, score=-114.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNpe59VzJ3vt; Tue, 15 Mar 2016 12:44:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2126A12D555; Tue, 15 Mar 2016 12:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3466; q=dns/txt; s=iport; t=1458071054; x=1459280654; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/oKey/IYpujjZijpQQyOsvVl8q3vxiJX67VTDV6YkfM=; b=SjwqXMla0ygy9rQMHf0BejbrHyMgteR75Dvx1T9pgKGUec05kQMiglXL PVegF7ggenRmCY4dMGU2WU15CJvFP0t9obPIqb6TCnwmHtg+2MgwVmhrQ qlvSqqFZ7Wt9GUTlDjQILoJ8KdC0azBW80Dmn5ZPzJ3FPPvUSvJ5/Hrkf Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAgCrZOhW/5RdJa1eg0ZUXwEBDQaCb?= =?us-ascii?q?7daAQ2BbhcKhWwCHIEgOBQBAQEBAQEBZCeEQQEBAQMBAQEBCRcROgsFCQICAQY?= =?us-ascii?q?CGAICIwMCAgIZDAsUARACBA4FiB8IDpF8nRePQwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAREEBHiHEQiCR4QLCwYBHBiCaiuBDwWHYI9vAYVuiBKPBY5+AR4BAUKCAxm?= =?us-ascii?q?BSWqJKQgXHX4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,340,1454976000"; d="scan'208";a="83141734" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2016 19:44:13 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u2FJiCxQ010485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 15 Mar 2016 19:44:13 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 15 Mar 2016 15:44:12 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Tue, 15 Mar 2016 15:44:11 -0400 From: "Cullen Jennings (fluffy)" To: "Cullen Jennings (fluffy)" Thread-Topic: [AVTCORE] [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 Thread-Index: AQHRfvMMhTOxAg48ZE64PHALbG96DA== Date: Tue, 15 Mar 2016 19:44:11 +0000 Message-ID: <4CA82554-6060-4B66-8B29-7D12E65EAA00@cisco.com> References: <56A8904D.10307@ericsson.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: [10.20.249.165] Content-Type: text/plain; charset="utf-8" Content-ID: <19AAEF1F85BB5B458D6955E770B3C475@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" , "avt@ietf.org" Subject: Re: [TLS] [AVTCORE] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:44:19 -0000 DQoNCj4gT24gTWFyIDE1LCAyMDE2LCBhdCAxOjQwIFBNLCBDdWxsZW4gSmVubmluZ3MgKGZsdWZm eSkgPGZsdWZmeUBjaXNjby5jb20+IHdyb3RlOg0KPiANCj4gDQo+IEkgdGhpbmsgdGhpcyBkcmFm dCBuZWVkcyBXR0xDIGluIGFsbCB0aGUgV0dzIHdoZXJlIGl0IGxpbWl0cyB0aGUgZXhpc3Rpbmcg Y29kZSBzcGFjZS4gDQoNClNvbWVob3cgaGl0IHNlbmQgdHJ5aW5nIHRvIG1vdmUgdGhpcyBmcm9t IG9uZSBjb21wdXRlciB0byBhbm90aGVyIGJlZm9yZSBmaW5pc2hpbmcgaXQuIEJ1dCB3aGF0IEkg d2FzIGdvaW5nIG9uIHRvIHNheSB3YXMgLi4uDQoNCmJ1dCB0aGF0IHdhcyBoYXBwZW5pbmcgYW5k IGdpdmVuIHRoZSBjdXJyZW50IHJhdGUgb2YgdXNhZ2Ugb2YgVExTLCB0aGlzIGRpZCBub3Qgc2Vl bSBsaWtlIGEgcmVzdHJpY3Rpb24gdGhhdCB3YXMgbGlrZWx5IHRvIHNpZ25pZmljYW50bHkgbGlt aXQgVExTIGZ1dHVyZSBleHRlbnNpb25zLg0KDQoNCg0KPiANCj4gDQo+PiBPbiBGZWIgNywgMjAx NiwgYXQgMTA6MjEgUE0sIEpvc2VwaCBTYWxvd2V5IDxqb2VAc2Fsb3dleS5uZXQ+IHdyb3RlOg0K Pj4gDQo+PiBUaGlzIGRvY3VtZW50IGlzIHJlbGV2YW50IHRvIHRoZSBUTFMgd29ya2luZyBiZWNh dXNlIGl0IHJlc2VydmVzIGEgbGFyZ2UgcG9ydGlvbiBvZiB0aGUgVExTIGNvbnRlbnQgdHlwZSBz cGFjZS4gIFRoZSB2YWx1ZXMgMC0xOSBhbmQgNjQtMjU1IGNhbm5vdCBiZSB1c2VkIHdpdGhvdXQg Y2hlY2tpbmcgZm9yIGNvbmZsaWN0cyB3aXRoIFNSVFAtRFRMUydzIHdhY2t5IGRlbXVsdGlwbGV4 aW5nIHNjaGVtZS4gICBJbiBUTFMgMS4zIHdlIHdpbGwgbW92ZSBtb3JlIGVuY3J5cHRlZCBjb250 ZW50IHR5cGVzIHdoaWNoIHNob3VsZCBsaW1pdCB0aGUgaW1wYWN0IHRoaXMgdW5mb3J0dW5hdGUg ZGVzaWduIG9uIFRMUyBldm9sdXRpb24sIGJ1dCB0aGUgd29ya2luZyBncm91cCBzaG91bGQgYmUg YXdhcmUgb2YgdGhpcy4gIA0KPj4gDQo+PiBDaGVlcnMsDQo+PiANCj4+IEpvZQ0KPj4gDQo+PiBP biBXZWQsIEphbiAyNywgMjAxNiBhdCAxOjM5IEFNLCBNYWdudXMgV2VzdGVybHVuZCA8bWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4+IEFWVENPUkUgYW5kIFRMUywNCj4+ IA0KPj4gVExTIFdHLCB5b3UgYXJlIGluY2x1ZGVkIGluIHRoaXMgV0cgbGFzdCBjYWxsLCBhcyB0 aGlzIGRvY3VtZW50IGFmZmVjdHMgdGhlIFRMUyBDb250ZW50VHlwZSBJQU5BIHJlZ2lzdHJ5Lg0K Pj4gDQo+PiBUaGlzIGVtYWlsIHN0YXJ0cyBhIHR3byB3ZWVrIFdHIGxhc3QgY2FsbCwgdGhhdCBl bmRzIG9uIHRoZSAxMHRoIG9mIEZlYnJ1YXJ5LiBUaGUgaW50ZW5kZWQgc3RhdHVzIG9mIHRoaXMg ZG9jdW1lbnQgaXMgc3RhbmRhcmRzIHRyYWNrIChQcm9wb3NlZCBTdGFuZGFyZCkuDQo+PiANCj4+ IFRoZSBkb2N1bWVudCBjYW4gYmUgcmV0cmlldmVkIGhlcmU6DQo+PiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWF2dGNvcmUtcmZjNTc2NC1tdXgtZml4ZXMvDQo+ PiANCj4+IENoZWVycw0KPj4gDQo+PiBNYWdudXMgV2VzdGVybHVuZA0KPj4gDQo+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+PiBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVhdHVyZXMsIEVyaWNzc29u IFJlc2VhcmNoIEVBQi9UWE0NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IEVyaWNzc29uIEFCICAgICAg ICAgICAgICAgICB8IFBob25lICArNDYgMTAgNzE0ODI4Nw0KPj4gRsOkcsO2Z2F0YW4gNiAgICAg ICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4+IFNFLTE2NCA4MCBTdG9ja2hv bG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+PiAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNAaWV0Zi5vcmcNCj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+PiANCj4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBBdWRpby9WaWRlbyBU cmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4gYXZ0QGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENv cmUgTWFpbnRlbmFuY2UNCj4gYXZ0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vYXZ0DQoNCg== From nobody Tue Mar 15 12:51:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0218412DD66 for ; Tue, 15 Mar 2016 12:51:47 -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_RED=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 P_96QgazOZFM for ; Tue, 15 Mar 2016 12:51:44 -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 E092212DD52 for ; Tue, 15 Mar 2016 12:51:40 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id z76so37520429iof.3 for ; Tue, 15 Mar 2016 12:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=lEY2xCgV50FiWqLKKUu36UZg0U83rdUPL/EYzG9KIAo=; b=cD/jyO5tMfdMnZj/h8DB5y83MjalbirKbWIg0FHKtLPj3nGkY6VkPCc8uCa3xhPxa5 +0VD+dtahuQjgcMjm/f/bZZHACOKEax7clvjfWnVCan9YvdIBk6U58rokurmOyWOq09U sPJDP81KAgWFcEulr0auGWupxlHAeIOxxKRrW98fwQBdbynU31PHxTm7dhEdFtBNrpaj U0jB3hds4pX4LQUcxtku0Gau3gZ+RbDvB8Z+p8rLh9hjOdlMh6UMQ2WPf3Ddr1kG6a7O Gm4Rw3fqnnNI1lxNMmNmh/o3qDFXgb7XPURoyqgR9/0Sfsb2czKTnJuPYmGrFUxUUFsL c96Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=lEY2xCgV50FiWqLKKUu36UZg0U83rdUPL/EYzG9KIAo=; b=cWUL06jG2lRE6eNP/Op6/wDZXSMwJsFwxi+mSiNPpsIsyn6T9WZnIYLXkR6myXfRYX bcY3xnfdyOzI0AvCVcybHfwpgy7P+vDhcIe9C9ks2MICBsf/TJDN5kmptu4vgjFwb1Jk uag9UFqCbn/ODmCTIZh2Rc7/lQhOqLcyxB4kzRdqH4DiR/1IB/7x3Gaodgzalyj8BtnQ STbzdCd4CLO4n5UdCCnmIpwfPqXW1mQth2GeFUCXPAR4O0JP3rTT+7XVLhs1nuXcwsDs U2ynzc+pEcUI+GAMCjg+APXIfPwAgCKeOsLrSiyCO8thHOCLzHiMZZnhH0KJyQy1Utso 5MJw== X-Gm-Message-State: AD7BkJKZIpFhqT+4qDa6yx/4En54AJySNj3U/1Na69dneTM1Y2XTMc9CUi+9b9BekrNfvn6QHY1/kgwiWkklmPyD MIME-Version: 1.0 X-Received: by 10.107.131.169 with SMTP id n41mr525405ioi.132.1458071500088; Tue, 15 Mar 2016 12:51:40 -0700 (PDT) Received: by 10.107.137.80 with HTTP; Tue, 15 Mar 2016 12:51:39 -0700 (PDT) Date: Tue, 15 Mar 2016 12:51:39 -0700 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ebf84d23c8f052e1bb9c6 Archived-At: Subject: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:51:47 -0000 --001a113ebf84d23c8f052e1bb9c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it is worth documenting what we feel would be the simplest secure 0-RTT mode that is safe for any company to use. I think we owe the users a link to such a document in the TLS 1.3 spec. Here is my attempt at creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme. It uses a traditional server-side session-cache. The protocol looks like this= : During the initial 1-RTT handshake: - create an unencrypted ticket containing only the session ID and a "resumption count" set to 0 - send the ticket to the client During a 0-RTT resumption handshake: - Get the session ID from the ticket, check for a cache hit, and drop to 1-RTT if not found - compare the resumption counts in the session state and ticket, and fall back to 1-RTT if they do not match - increment the resumption count in the ticket and session state - send the updated ticket to the client With this protocol, POST requests are allowed in 0-RTT application data, just like TLS 1.2. Client certs are allowed only on the initial 1-RTT handshake, since the 0-RTT connection cannot complete proofs of possession before the 0-RTT application requests are executed by the server. To see that this provides roughly TLS 1.2 security, note that so long as the protocol never has to drop to 1-RTT, it is basically equivalent to TLS 1.2 session-ID based resumption. When we do drop down to 1-RTT, we will replay 0-RTT application data, opening up new replay attacks. However, after this paper , I do not believe there are any significant new replay attacks against HTTPS, ssh, or any real protocol I can think of. There may be weaknesses in TLS 1.3 resumption caused by the client forgetting the original connection's security parameters, but if any are found, a client-side cache can be added= . Can this protocol be simplified by dropping the server cache? No. While we can play with various server-side stateful schemes, such as strike registers, it turns out that state on the server is _required_ for TLS 1.2 levels of security when using 0-RTT resumption. Without server-side state, 0-RTT application data can be infinitely replayed, strong client authentication stops working, and full PFS becomes impossible. Note that the above protocol does not deliver full PFS, but I claim that the modified version described below does. That's all I have for my attempt at "Simple, secure 0-RTT for the masses". Below I just talk about extending the protocol to provide full PFS, which AFAIK, the world has never implemented. . . . It turns out that providing full PFS over 0-RTT resumptions requires server-side state. Proof: Assume a server Sam has no server-side remembered session state, and uses the same ticket decryption key to decrypt session tickets from both Alice and Bob. Different decryption keys are not possible because that would require remembering which session ticket used which key. Eve records Alice=E2=80=99s resumed session, and later when Bob resumes, a server compr= omise reveals Sam=E2=80=99s ticket decryption key to Eve. Now Eve can decrypt Al= ice=E2=80=99s previous resumed session since the ticket is sent from Alice to Bob before encryption is enabled. Clearly, the ticket contains all the information needed to resume the encrypted session, since Sam does so without access to any other server-side state. Also, Alice is sending 0-RTT application data before any new ephemeral keys can be established. Eve simply simulates resuming Alice's session and decrypts the 0-RTT application data, proving that Alice's original session lacked forward secrecy. So, stateless ticket resumption does not, and never will provide full PFS. On the other hand, AFAIK, no one has ever provided full PFS using session caching either. Is there a solution? Yes, there are multiple solutions. For example, if TLS 1.3 were enhanced to allow the session secrets to be re-keyed before saving the session state to the cache, that would stop a server compromise from leaking session secrets from past connections. Given the current TLS 1.3 protocol as I understand it, this is not possible, so my next-best solution is to have the clients hold the server's session-cache decryption keys, which are generated uniquely for each 0-RTT resumption. In this scheme, the server stores a session-cache decryption key in the ticket, and the ticket is not encrypted. The protocol looks like this: During the initial 1-RTT handshake: - create a ticket containing the session ID, "resumption count" set to 0, and a new session encryption key - encrypt the session state in the cache with the session encryption key - send the ticket to the client, and delete the session encryption key. Note that the ticket is sent after encryption is enabled on the connection. During a 0-RTT resumption handshake: - check for a cache hit, and drop to 1-RTT if not found - decrypt the cached session state with the encryption key from the ticket - compare the resumption counts in the session-cache entry and ticket, and fall back to 1-RTT if they do not match - increment the resumption count - create a new session encryption key in the ticket - encrypt the updated session cache entry with the new session encryption key - send the updated ticket to the client Did I miss anything? Can it be simplified? This time, when Sam's server is compromised, Eve cannot decrypt the 0-RTT application data from Alice's previous session, because the session state in the cache is encrypted with keys held only by the clients. These 0-RTT connections enjoy full PFS. Bill --001a113ebf84d23c8f052e1bb9c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it is worth documenting what we feel would be the = simplest secure 0-RTT mode that is safe for any company to use.=C2=A0 I thi= nk we owe the users a link to such a document in the TLS 1.3 spec.=C2=A0 He= re is my attempt at creating the simplest possible TLS 1.3 compatible safe = 0-RTT scheme.=C2=A0 It uses a traditional server-side session-cache.=C2=A0 = The protocol looks like this:

During the initi= al 1-RTT handshake:
- create an unencrypted ticket containing onl= y the session ID and a "resumption count" set to 0
= - send the ticket to the client

During a 0-RTT= resumption handshake:
- Get the session ID from the ticket, = check for a cache hit, and drop to 1-RTT if not found
- compare t= he resumption counts in the session state and ticket, and fall back to 1-RT= T if they do not match
- increment the resumption count in th= e ticket and session state
- send the updated ticket to the clien= t

With this protocol, POST request= s are allowed in 0-RTT application data, just like TLS 1.2.=C2=A0 Client ce= rts are allowed only on the initial 1-RTT handshake, since the 0-RTT connec= tion cannot complete proofs of possession before the 0-RTT application requ= ests are executed by the server.

To see that this = provides roughly TLS 1.2 security, note that so long as the protocol never = has to drop to 1-RTT, it is basically equivalent to TLS 1.2 session-ID base= d resumption.=C2=A0 When we do drop down to 1-RTT, we will replay 0-RTT app= lication data, opening up new replay attacks.=C2=A0 However, after this = paper, I do not believe there are any significant new replay attacks ag= ainst HTTPS, ssh, or any real protocol I can think of.=C2=A0 There may be w= eaknesses in TLS 1.3 resumption caused by the client forgetting the origina= l connection's security parameters, but if any are found, a client-side= cache can be added.

Can this protocol be simplifi= ed by dropping the server cache?=C2=A0 No.=C2=A0 While we can play with var= ious server-side stateful schemes, such as strike registers, it turns out t= hat state on the server is _required_ for TLS 1.2 levels of security when u= sing 0-RTT resumption.=C2=A0 Without server-side state, 0-RTT application d= ata can be infinitely replayed, strong client authentication stops working,= and full PFS becomes impossible.=C2=A0 Note that the above protocol does n= ot deliver full PFS, but I claim that the modified version described below = does.

That's all I have for my = attempt at "Simple, secure 0-RTT for the masses".=C2=A0 Below I j= ust talk about extending the protocol to provide full PFS, which AFAIK, the= world has never implemented.

. . .
=
It turns out that providing full PFS over 0-RTT resumptions = requires server-side state.

Proof: Assume a server= Sam has no server-side remembered session state, and uses the same ticket = decryption key to decrypt session tickets from both Alice and Bob.=C2=A0 Di= fferent decryption keys are not possible because that would require remembe= ring which session ticket used which key.=C2=A0 Eve records Alice=E2=80=99s= resumed session, and later when Bob resumes, a server compromise reveals S= am=E2=80=99s ticket decryption key to Eve.=C2=A0 Now Eve can decrypt Alice= =E2=80=99s previous resumed session since the ticket is sent from Alice to = Bob before encryption is enabled.=C2=A0 Clearly, the ticket contains all th= e information needed to resume the encrypted session, since Sam does so wit= hout access to any other server-side state.=C2=A0 Also, Alice is sending 0-= RTT application data before any new ephemeral keys can be established.=C2= =A0 Eve simply simulates resuming Alice's session and decrypts the 0-RT= T application data, proving that Alice's original session lacked forwar= d secrecy.

So, stateless ticket resumption does no= t, and never will provide full PFS.=C2=A0 On the other hand, AFAIK, no one = has ever provided full PFS using session caching either.=C2=A0 Is there a s= olution?

Yes, there are multiple solutions.=C2=A0 = For example, if TLS 1.3 were enhanced to allow the session secrets to be re= -keyed before saving the session state to the cache, that would stop a serv= er compromise from leaking session secrets from past connections.=C2=A0 Giv= en the current TLS 1.3 protocol as I understand it, this is not possible, s= o my next-best solution is to have the clients hold the server's sessio= n-cache decryption keys, which are generated uniquely for each 0-RTT resump= tion.

In this scheme, the server stores a session-= cache decryption key in the ticket, and the ticket is not encrypted.=C2=A0 = The protocol looks like this:

During the init= ial 1-RTT handshake:
- create a ticket containing the session ID,= "resumption count" set to 0, and a new session encryption key
- encrypt the session state in the cache with the session encryptio= n key
- send the ticket to the client, and delete the session enc= ryption key.=C2=A0 Note that the ticket is sent after encryption is enabled= on the connection.

During a 0-RTT resumption = handshake:
- check for a cache hit, and drop to 1-RTT if not foun= d
- decrypt the cached session state with the encryption key from= the ticket
- compare the resumption counts in the session-ca= che entry and ticket, and fall back to 1-RTT if they do not match
=
- increment the resumption count
- create a new ses= sion encryption key in the ticket
- encrypt the updated sess= ion cache entry with the new session encryption key
- send the up= dated ticket to the client

D= id I miss anything?=C2=A0 Can it be simplified?

Th= is time, when Sam's server is compromised, Eve cannot decrypt the 0-RTT= application data from Alice's previous session, because the session st= ate in the cache is encrypted with keys held only by the clients.=C2=A0 The= se 0-RTT connections enjoy full PFS.

Bill
--001a113ebf84d23c8f052e1bb9c6-- From nobody Tue Mar 15 13:18:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A230E12D759 for ; Tue, 15 Mar 2016 13:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m26kkbV3GXDA for ; Tue, 15 Mar 2016 13:18:14 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 32BC712D682 for ; Tue, 15 Mar 2016 13:18:14 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id n190so38606150iof.0 for ; Tue, 15 Mar 2016 13:18:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=CidcAe+qQ7+yjynbakBsw9/jjJeCIYnlw66/rhSPc4U=; b=SVmOJ8p6Z1VQbFPPIRQ1qMdRtGlSYwUy8TH/1GfEaLErGqCgyxI8RcfNz6/y+YB0/k jjGEsi6S9FujtbWfRWhqy9E6UsRxs7e4fytBPqqjA060WpnuNUMartwSoOMWgi+9iTng gKPG7pXUOrqriyr3eir25ku4FL6cAfEiyB2yTi1gpOxrE7JOM7osNGV12E+zLJICn9i4 Z9JBd7YV4eyats0miJ6J1LVfULsBVvBwsQPGJSwve94OcfMhy7/S8qpAFn4V24u20B3e pLNy3IKCF6c6RR8fPeHogXILhxCAkMOpZGZ0z2sS/lDI1XxOihExLDzDbEtpzX/OMoCi Bbbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=CidcAe+qQ7+yjynbakBsw9/jjJeCIYnlw66/rhSPc4U=; b=MieTwW69+qZlbo7Qd6zCSFF8CX6u3b/f260rzTWYplAiChCXjQ5J44AOS5XvVA0c1Z KQOM3K03jKAVgnRebulpvUIbhI8rI4mboCyD9SCuExvWH545bBfupbVaxhGxd46LOGOG J4WhXR1lZ6qpSa3qEEOZLZf7oAvT0+7UM/YOqvf6YvwJvKdjXGdM0g8QrP3yRQIQBS3+ OSFJBW8108xTKvI5EVC1nvmwMV+1MRg1LCq6OlfgSH+N3IBREKIoeVWEL7WAlyyFVQIk 7HSKmZiWpxLR7gjd4KU4uv/Ad608iYtDF752Q1vzHSbZynveVQzoInPYX6G/ibC+aui/ Butg== X-Gm-Message-State: AD7BkJKeVBpA2GbgEdYFTkNK309PzUciFhyoBBrEDpMwIi4XE15r7t3OrZ4If1XZ/OtgJkUhuoRar2sgwix7mLY+ MIME-Version: 1.0 X-Received: by 10.107.131.169 with SMTP id n41mr646264ioi.132.1458073093325; Tue, 15 Mar 2016 13:18:13 -0700 (PDT) Received: by 10.107.137.80 with HTTP; Tue, 15 Mar 2016 13:18:13 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2016 13:18:13 -0700 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113ebf84c911d4052e1c18e2 Archived-At: Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:18:15 -0000 --001a113ebf84c911d4052e1c18e2 Content-Type: text/plain; charset=UTF-8 Correction: TLS 1.3 PSK resumption already requires a client-side session-cache, in order for the client to load the previous session state and send 0-RTT data encrypted with the previous session secrets. So, using session caches on both sides seems to be the simplest safe 0-RTT mode compatible with TLS 1.3. Bill --001a113ebf84c911d4052e1c18e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Correction: =C2=A0TLS 1.3 PSK resumption already requires = a client-side session-cache, in order for the client to load the previous s= ession state and send 0-RTT data encrypted with the previous session secret= s.=C2=A0 So, using session caches on both sides seems to be the simplest sa= fe 0-RTT mode compatible with TLS 1.3.

Bill
--001a113ebf84c911d4052e1c18e2-- From nobody Tue Mar 15 13:22:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D1212D774 for ; Tue, 15 Mar 2016 13:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_RED=0.001] 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 rxQDj26XPnUS for ; Tue, 15 Mar 2016 13:22:00 -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 76DC312D76C for ; Tue, 15 Mar 2016 13:22:00 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g127so36078342ywf.2 for ; Tue, 15 Mar 2016 13:22:00 -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:date:message-id:subject:from:to :cc; bh=VhNYqyzzdZSz+xYNeNW3AXrHvPnsU1DzO0FzScaavLs=; b=myuVIWyG68hhjilLhDql/7BJEn3fOkmOhsJszAFNq4h7B1wkPk7B6/lsYgZlATYXzJ VzWy+YmNjljaKn2dyttldvanH0qdLOYM/B3d2QnQ1ikF6mmRrXqLglQOGxJNhg6R1QvB SYZov2JImxSSnBfWackCAhxte9JnEzDpQJLXedLwd/oktwH8D750fdhh+F2dzcjnZICU wa1X1CYPoUqew4llYyB5yApvaTXHLirI883JhWIXPNLHodwSq+WAmxnAZNnvrUfEFtAy mIewX8MMGfVYMny6F+h9WZqoFwaqBhHxKti2t8EdH0oHxPJ/QJSFktl+4zJdYeTFx7kO JtXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=VhNYqyzzdZSz+xYNeNW3AXrHvPnsU1DzO0FzScaavLs=; b=muvQ19th+VxQGjiWlnurax5xPiGArIsFLAw1Ie76kYGIq14yUjtx4NWYabxFc7b6FB k1sq4IVG8nrijGkPonCQ4cUelAHZLmt2e2s7YPS+zaGO1mmvhH6lw4tbW0Lyh3FyW5F8 uxiN7/v4TER1+Bp21E49uZJY8hRIImTg6HPwAdnjM1r4rYYlnNCeG1KvjR2zWRk7wGaE 6ZHvY1KCqwtFwUd/bzUXEdV4rEsxNF3FmXkbxPcS15OBtmNDKNLESlpDg7TlrltwTp2K zL/yD6iUKyReUJeVrYM8/+eXxQV7dchYNeNQSkZLyPWktLBkEa9wqtB460tL9eeZwYt0 +Mhw== X-Gm-Message-State: AD7BkJLbldkymjnP0lXLX4TS8jF2cswjB0NYn4QdmguSqHA7od1pJH/y4GqTeayFoE740ZVX2LZI2nSg5uabLA== MIME-Version: 1.0 X-Received: by 10.13.214.1 with SMTP id y1mr16181405ywd.307.1458073319645; Tue, 15 Mar 2016 13:21:59 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Tue, 15 Mar 2016 13:21:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2016 16:21:59 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0770e4468a25052e1c2615 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:22:02 -0000 --94eb2c0770e4468a25052e1c2615 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 3:51 PM, Bill Cox wrote: > I think it is worth documenting what we feel would be the simplest secure > 0-RTT mode that is safe for any company to use. I think we owe the users a > link to such a document in the TLS 1.3 spec. Here is my attempt at > creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme. It > uses a traditional server-side session-cache. > Thanks for the awesome write up! This helped me clear my thinking a lot, especially the proof. > During a 0-RTT resumption handshake: > - Get the session ID from the ticket, check for a cache hit, and drop to > 1-RTT if not found > - compare the resumption counts in the session state and ticket, and fall > back to 1-RTT if they do not match > - increment the resumption count in the ticket and session state > - send the updated ticket to the client > Here the resumption counts have to be synchronized between the client and server, but is the count cryptographically authenticated? can can attacker can take 0RTT data from session N, increment the resumption count, and replay that 0RTT data? Since synchronization and authenticity are both required here, would it be simpler to use the sequence number and PRF state from the session? it can be saved by the client and server on session close, and they take off where they left things on any subsequent connection. That also gives clients and their users additional confidence in the protocol: the server can't just ignore things like resumption counts. Another sort of warm and fuzzy reason I like this is that the whole thing resembles a single-long-running regular TLS connection over a single TCP socket. That makes things easier to verify, and some things easier to implement. To see that this provides roughly TLS 1.2 security, note that so long as > the protocol never has to drop to 1-RTT, it is basically equivalent to TLS > 1.2 session-ID based resumption. When we do drop down to 1-RTT, we will > replay 0-RTT application data, opening up new replay attacks. However, > after this paper > , I do > not believe there are any significant new replay attacks against HTTPS, > ssh, or any real protocol I can think of. > Unfortunately I don't think that's a safe assumption. The paper is about browser behavior, but there are API clients and SDKs that do not retry as a matter of design, they rely on TLS for non-replayability. In any event, there might be no problem: wouldn't it be a TLS library bug if the library somehow fell back to 1-RTT mode while also decrypting and passing on the 0RTT data? the client and the server need to agree on whether it was received. -- Colm --94eb2c0770e4468a25052e1c2615 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 15, 2016 at 3:51 PM, Bill Cox <waywardgeek@google.com= > wrote:
I= think it is worth documenting what we feel would be the simplest secure 0-= RTT mode that is safe for any company to use.=C2=A0 I think we owe the user= s a link to such a document in the TLS 1.3 spec.=C2=A0 Here is my attempt a= t creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme.=C2= =A0 It uses a traditional server-side session-cache.=C2=A0

Thanks for the awesome write up! This helped me clea= r my thinking a lot, especially the proof.=C2=A0
=C2=A0
During a 0-RTT r= esumption handshake:
- Get the session ID from the ticket, ch= eck for a cache hit, and drop to 1-RTT if not found
- compare the= resumption counts in the session state and ticket, and fall back to 1-RTT = if they do not match
- increment the resumption count in the = ticket and session state
- send the updated ticket to the client<= br>

Here the resump= tion counts have to be synchronized between the client and server, but is t= he count cryptographically authenticated? can can attacker can take 0RTT da= ta from session N, increment the resumption count, and replay that 0RTT dat= a?

Since synchronization and authenticity are both= required here, would it be simpler to use the sequence number and PRF stat= e from the session? it can be saved by the client and server on session clo= se, and they take off where they left things on any subsequent connection. = That also gives clients and their users additional confidence in the protoc= ol: the server can't just ignore things like resumption counts.=C2=A0

Another sort of warm and fuzzy reason I like this i= s that the whole thing resembles a single-long-running regular TLS connecti= on over a single TCP socket. That makes things easier to verify, and some t= hings easier to implement.=C2=A0

To see that this provides roughly TLS 1.2 se= curity, note that so long as the protocol never has to drop to 1-RTT, it is= basically equivalent to TLS 1.2 session-ID based resumption.=C2=A0 When we= do drop down to 1-RTT, we will replay 0-RTT application data, opening up n= ew replay attacks.=C2=A0 However, after this paper,= I do not believe there are any significant new replay attacks against HTTP= S, ssh, or any real protocol I can think of.=C2=A0
=

Unfortunately I don't think that's a safe assum= ption. The paper is about browser behavior, but there are API clients and S= DKs that do not retry as a matter of design, they rely on TLS for non-repla= yability. In any event, there might be no problem: wouldn't it be a TLS= library bug if the library somehow fell back to 1-RTT mode while also decr= ypting and passing on the 0RTT data? the client and the server need to agre= e on whether it was received.=C2=A0
--
Colm
--94eb2c0770e4468a25052e1c2615-- From nobody Tue Mar 15 13:22:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6188C12D76C for ; Tue, 15 Mar 2016 13:22:25 -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_RED=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 BKYLhJqrU1sJ for ; Tue, 15 Mar 2016 13:22:22 -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 88F3B12D765 for ; Tue, 15 Mar 2016 13:22:22 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h129so36160004ywb.1 for ; Tue, 15 Mar 2016 13:22:22 -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=779XtabjWceF0oU2XDfFX9sRSutgEd7l4pxziwjhF3k=; b=w99ExBO3SZoVJKrkxLIhtoGKkymjVZePW4NOIHsb6L5+XlIieexQg5CJ4035kAROfP 0uo8j5jNDpDESs+GieD6QE++08w9c8D2Qx3Au9nTWuaCsLEIZUsUJ6HVWYgp4nDPkpkO QAmDGLnR4VAVP89ivkHOc7gNK8L8H+0u0kQtUMKozOX7LLTPjcM4lef0tq96TxxQ3XVE ItnG2sY1nZ3fxXw3WJbUkAcjEXUwz+/kXMpqnsnx23lMc5Pp3X3+I0m+3P8n/vGI7HfI k9OaAxgNTI2DtRYqir0HdYPxLsOuS1e9JHYrKthmEetVN8cJ8UXXyftKlBszvxsE/wiX A5LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=779XtabjWceF0oU2XDfFX9sRSutgEd7l4pxziwjhF3k=; b=NJAlM3Ddh5Io27ZHRRHKgUziN+Lk/+5bZ5IF3chuuwOCMvmMOlwBIqdU5CpTzDSQaE 2mYRVN9lWNa19oNJDV610QsDKUxRzCNpAujwu6zw11TJDsb/JJ+mC6KAi2c0VaQhYuug x0MKyY3XUVlpjARHXLyW3vBpUqZFKAYHyOnzM7aQ51Vzu1+qtK8S0d7kH1y7fcW/CkwN seSa6Q3REF/6aaOEAZ4i62nFkMmYkl9Aj3OT/rfk6WlF+qihcFvDyCb8rkMgZMH/on6m Q544+udcGYEjnsk+ldvLKlk7XBZUBviYhIPRQ4IE4PxQh7XbjuIRQEoy4hXVxUPwzYZs kqhg== X-Gm-Message-State: AD7BkJKMJwkkCyIOeFSZkZuxXrW0txZE+HFvcVXvX2WhdOboLp+lW+leBjdwcV4nz4cDbZKHIwAfmUp2st9L7A== X-Received: by 10.37.38.197 with SMTP id m188mr6081638ybm.162.1458073341747; Tue, 15 Mar 2016 13:22:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 15 Mar 2016 13:21:42 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Mar 2016 13:21:42 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a1143b77e979a75052e1c275c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:22:25 -0000 --001a1143b77e979a75052e1c275c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2016 at 12:51 PM, Bill Cox wrote: > I think it is worth documenting what we feel would be the simplest secure > 0-RTT mode that is safe for any company to use. I think we owe the users= a > link to such a document in the TLS 1.3 spec. Here is my attempt at > creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme. It > uses a traditional server-side session-cache. The protocol looks like th= is: > > During the initial 1-RTT handshake: > - create an unencrypted ticket containing only the session ID and a > "resumption count" set to 0 > - send the ticket to the client > > During a 0-RTT resumption handshake: > - Get the session ID from the ticket, check for a cache hit, and drop to > 1-RTT if not found > - compare the resumption counts in the session state and ticket, and fall > back to 1-RTT if they do not match > - increment the resumption count in the ticket and session state > - send the updated ticket to the client > > With this protocol, POST requests are allowed in 0-RTT application data, > just like TLS 1.2. Client certs are allowed only on the initial 1-RTT > handshake, since the 0-RTT connection cannot complete proofs of possessio= n > before the 0-RTT application requests are executed by the server. > > To see that this provides roughly TLS 1.2 security, note that so long as > the protocol never has to drop to 1-RTT, it is basically equivalent to TL= S > 1.2 session-ID based resumption. When we do drop down to 1-RTT, we will > replay 0-RTT application data, opening up new replay attacks. However, > after this paper > , I do > not believe there are any significant new replay attacks against HTTPS, > ssh, or any real protocol I can think of. There may be weaknesses in TLS > 1.3 resumption caused by the client forgetting the original connection's > security parameters, but if any are found, a client-side cache can be add= ed. > > Can this protocol be simplified by dropping the server cache? No. While > we can play with various server-side stateful schemes, such as strike > registers, it turns out that state on the server is _required_ for TLS 1.= 2 > levels of security when using 0-RTT resumption. Without server-side stat= e, > 0-RTT application data can be infinitely replayed, strong client > authentication stops working, and full PFS becomes impossible. Note that > the above protocol does not deliver full PFS, but I claim that the modifi= ed > version described below does. > > That's all I have for my attempt at "Simple, secure 0-RTT for the > masses". Below I just talk about extending the protocol to provide full > PFS, which AFAIK, the world has never implemented. > > . . . > > It turns out that providing full PFS over 0-RTT resumptions requires > server-side state. > > Proof: Assume a server Sam has no server-side remembered session state, > and uses the same ticket decryption key to decrypt session tickets from > both Alice and Bob. Different decryption keys are not possible because > that would require remembering which session ticket used which key. Eve > records Alice=E2=80=99s resumed session, and later when Bob resumes, a se= rver > compromise reveals Sam=E2=80=99s ticket decryption key to Eve. Now Eve c= an decrypt > Alice=E2=80=99s previous resumed session since the ticket is sent from Al= ice to Bob > before encryption is enabled. Clearly, the ticket contains all the > information needed to resume the encrypted session, since Sam does so > without access to any other server-side state. Also, Alice is sending > 0-RTT application data before any new ephemeral keys can be established. > Eve simply simulates resuming Alice's session and decrypts the 0-RTT > application data, proving that Alice's original session lacked forward > secrecy. > > So, stateless ticket resumption does not, and never will provide full > PFS. On the other hand, AFAIK, no one has ever provided full PFS using > session caching either. Is there a solution? > > Yes, there are multiple solutions. For example, if TLS 1.3 were enhanced > to allow the session secrets to be re-keyed before saving the session sta= te > to the cache, that would stop a server compromise from leaking session > secrets from past connections. > Can you expand on this point? The session secret that is derived from connection N (the RMS) cannot be used to compute the traffic keys for connection N. Is that not the property you are looking for? -Ekr Given the current TLS 1.3 protocol as I understand it, this is not > possible, so my next-best solution is to have the clients hold the server= 's > session-cache decryption keys, which are generated uniquely for each 0-RT= T > resumption. > > In this scheme, the server stores a session-cache decryption key in the > ticket, and the ticket is not encrypted. The protocol looks like this: > > During the initial 1-RTT handshake: > - create a ticket containing the session ID, "resumption count" set to 0, > and a new session encryption key > - encrypt the session state in the cache with the session encryption key > - send the ticket to the client, and delete the session encryption key. > Note that the ticket is sent after encryption is enabled on the connectio= n. > > During a 0-RTT resumption handshake: > - check for a cache hit, and drop to 1-RTT if not found > - decrypt the cached session state with the encryption key from the ticke= t > - compare the resumption counts in the session-cache entry and ticket, an= d > fall back to 1-RTT if they do not match > - increment the resumption count > - create a new session encryption key in the ticket > - encrypt the updated session cache entry with the new session encryption > key > - send the updated ticket to the client > > Did I miss anything? Can it be simplified? > > This time, when Sam's server is compromised, Eve cannot decrypt the 0-RTT > application data from Alice's previous session, because the session state > in the cache is encrypted with keys held only by the clients. These 0-RT= T > connections enjoy full PFS. > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1143b77e979a75052e1c275c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 15, 2016 at 12:51 PM, Bill Cox <waywardgeek@google.co= m> wrote:
= I think it is worth documenting what we feel would be the simplest secure 0= -RTT mode that is safe for any company to use.=C2=A0 I think we owe the use= rs a link to such a document in the TLS 1.3 spec.=C2=A0 Here is my attempt = at creating the simplest possible TLS 1.3 compatible safe 0-RTT scheme.=C2= =A0 It uses a traditional server-side session-cache.=C2=A0 The protocol loo= ks like this:

During the initial 1-RTT handsha= ke:
- create an unencrypted ticket containing only the session ID= and a "resumption count" set to 0
- send the ticke= t to the client

During a 0-RTT resumption hand= shake:
- Get the session ID from the ticket, check for a cach= e hit, and drop to 1-RTT if not found
- compare the resumption co= unts in the session state and ticket, and fall back to 1-RTT if they do not= match
- increment the resumption count in the ticket and ses= sion state
- send the updated ticket to the client

With this protocol, POST requests are allowed in= 0-RTT application data, just like TLS 1.2.=C2=A0 Client certs are allowed = only on the initial 1-RTT handshake, since the 0-RTT connection cannot comp= lete proofs of possession before the 0-RTT application requests are execute= d by the server.

To see that this provides roughly= TLS 1.2 security, note that so long as the protocol never has to drop to 1= -RTT, it is basically equivalent to TLS 1.2 session-ID based resumption.=C2= =A0 When we do drop down to 1-RTT, we will replay 0-RTT application data, o= pening up new replay attacks.=C2=A0 However, after this= paper, I do not believe there are any significant new replay attacks a= gainst HTTPS, ssh, or any real protocol I can think of.=C2=A0 There may be = weaknesses in TLS 1.3 resumption caused by the client forgetting the origin= al connection's security parameters, but if any are found, a client-sid= e cache can be added.

Can this protocol be simplif= ied by dropping the server cache?=C2=A0 No.=C2=A0 While we can play with va= rious server-side stateful schemes, such as strike registers, it turns out = that state on the server is _required_ for TLS 1.2 levels of security when = using 0-RTT resumption.=C2=A0 Without server-side state, 0-RTT application = data can be infinitely replayed, strong client authentication stops working= , and full PFS becomes impossible.=C2=A0 Note that the above protocol does = not deliver full PFS, but I claim that the modified version described below= does.

That's all I have for my= attempt at "Simple, secure 0-RTT for the masses".=C2=A0 Below I = just talk about extending the protocol to provide full PFS, which AFAIK, th= e world has never implemented.

. . .

It turns out that providing full PFS over 0-RTT resumptions= requires server-side state.

Proof: Assume a serve= r Sam has no server-side remembered session state, and uses the same ticket= decryption key to decrypt session tickets from both Alice and Bob.=C2=A0 D= ifferent decryption keys are not possible because that would require rememb= ering which session ticket used which key.=C2=A0 Eve records Alice=E2=80=99= s resumed session, and later when Bob resumes, a server compromise reveals = Sam=E2=80=99s ticket decryption key to Eve.=C2=A0 Now Eve can decrypt Alice= =E2=80=99s previous resumed session since the ticket is sent from Alice to = Bob before encryption is enabled.=C2=A0 Clearly, the ticket contains all th= e information needed to resume the encrypted session, since Sam does so wit= hout access to any other server-side state.=C2=A0 Also, Alice is sending 0-= RTT application data before any new ephemeral keys can be established.=C2= =A0 Eve simply simulates resuming Alice's session and decrypts the 0-RT= T application data, proving that Alice's original session lacked forwar= d secrecy.

So, stateless ticket resumption does no= t, and never will provide full PFS.=C2=A0 On the other hand, AFAIK, no one = has ever provided full PFS using session caching either.=C2=A0 Is there a s= olution?

Yes, there are multiple solutions.=C2=A0 = For example, if TLS 1.3 were enhanced to allow the session secrets to be re= -keyed before saving the session state to the cache, that would stop a serv= er compromise from leaking session secrets from past connections.

Can you expand on this point?
The session secret that is derived from connection N (the RMS) cannot be u= sed to
compute the traffic keys for connection N. Is that not the= property you are looking
for?

-Ekr

Given = the current TLS 1.3 protocol as I understand it, this is not possible, so m= y next-best solution is to have the clients hold the server's session-c= ache decryption keys, which are generated uniquely for each 0-RTT resumptio= n.

In this scheme, the server stores a session-cac= he decryption key in the ticket, and the ticket is not encrypted.=C2=A0 The= protocol looks like this:

During the initial= 1-RTT handshake:
- create a ticket containing the session ID, &q= uot;resumption count" set to 0, and a new session encryption key
=
- encrypt the session state in the cache with the session encryption k= ey
- send the ticket to the client, and delete the session encryp= tion key.=C2=A0 Note that the ticket is sent after encryption is enabled on= the connection.

During a 0-RTT resumption han= dshake:
- check for a cache hit, and drop to 1-RTT if not found
- decrypt the cached session state with the encryption key from th= e ticket
- compare the resumption counts in the session-cache= entry and ticket, and fall back to 1-RTT if they do not match
- increment the resumption count
- create a new sessio= n encryption key in the ticket
- encrypt the updated session= cache entry with the new session encryption key
- send the updat= ed ticket to the client

Did = I miss anything?=C2=A0 Can it be simplified?

This = time, when Sam's server is compromised, Eve cannot decrypt the 0-RTT ap= plication data from Alice's previous session, because the session state= in the cache is encrypted with keys held only by the clients.=C2=A0 These = 0-RTT connections enjoy full PFS.

Bill

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


--001a1143b77e979a75052e1c275c-- From nobody Tue Mar 15 13:46:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80E12DD7E for ; Tue, 15 Mar 2016 13:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFhHx7mvghbt for ; Tue, 15 Mar 2016 13:46:36 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 744B212DD86 for ; Tue, 15 Mar 2016 13:46:35 -0700 (PDT) Received: from [192.168.10.140] ([129.192.176.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MdoR7-1aRpOG07ob-00PeLR for ; Tue, 15 Mar 2016 21:46:33 +0100 To: "" From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56E874A4.3030506@gmx.net> Date: Tue, 15 Mar 2016 21:46:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aBwxRtRx19NJRbvDnOVrMQrdIKkvXtmF1" X-Provags-ID: V03:K0:YQdJcGHhORzHG7X6AI+jzD9qSbUCQPQeCrVV3/1G6TvRqne1xGA GuyefLUg3Nd/NZR/p9uQcW9kcuDvhDQqM2mBKyZCzhgPISYV/Rd1vdCJ+WZD/bvXJ5syc9j Vj5NqtdXXyqxPwp2izAtLhusthBktH7n4Gew3Oon4BzjAyYhGq2UPltCb8DKazmksL9YcMN aOEbz29ml6NiWwwEgiKHQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:oVScp0cp0ns=:PYaaFz6GMp2U5778iP+qaO 2Of0PCcfJKKzgA+++bZhbmRLUdEYljb8LV6/ZrG83L1CuQo8QDpuc+GA0AFboh8ACk4KK1R/w hohIhS+IH562vccqThlz4+UlV5iWAm7+vHNAy+p0xgAJ3eIA0tKIsWkC2u+pPEQZvVCZ30+Og 8mnTcliV3ZKwH3zAUGZD5SY5TVEnXP9RhoJeq3WP3feQ0XqJX5eLbbYMZxIlEVY/5OANZJYnH VIBczHdcRhQWNu30ZnuI6jfGdO0XR/Tucffqb/JY2PGPsp27dTDKVV7ytkDoIrKdlnykIinRZ VWFxnYT0W8Jt3S2IdWuRXn+XQnpJxeGg0aBrMhRo9ECPQe53bnTMi2SN4cpnxUx+1m5mW8B/Y lE++qikm2OjZ9UMU5LhqFgSLWt4GRQVRUCKlmcE82d8VTlcKZ6tBEfNV2b+HhoS8BgAJEBojP EgIvcZj4Bw/9Men7PSVHWkgFqnLx8hDdfA15mh4W23OUyx3NIt/c0X8bNXAvs5mqUKGCW4eet GLoSF5FFyOgi/yL0Bt0VvCMrs6QNSeqAaBecG4xr9i5mLbBNcAMhE8Ld9gz2pcuCAQRcSkYUu 1/0P2JYyHhlbGlc+41G/w9W9f7TrPGBvmyGGVYZ4ZKO4Z4rp1e9hxnG/mkQrXpiXq1O63avYD yyzypd8GRbUXqjYpp+RJ08wt6mtRrgcRE3wSmFMb5+keZDM4kUU9jiwjnX8u6gIkA7koiA65j 5uvb/pnD4jjaOR5ds506Mwyw37pU8fqBZczWLia1GT6GDC8rtcR+eXahtfE= Archived-At: Subject: [TLS] PSK in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:46:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aBwxRtRx19NJRbvDnOVrMQrdIKkvXtmF1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, Hi all, I am not entirely sure about the PSK story in TLS 1.3. In Section 6.2.3 I read that the PSK approach has been combined with resumption. Appendix A4 lists the defined ciphersuites but there is no PSK-based ciphersuite in that list. Section 6.3.1.2 explains that the ServerHello message handling: " The server will send this message in response to a ClientHello message when it was able to find an acceptable set of algorithms and the client=E2=80=99s =E2=80=9Ckey_share=E2=80=9D extension was acceptable. If= the client proposed groups are not acceptable by the server, it will respond with a =E2=80=9Chandshake_failure=E2=80=9D fatal ale " What this text should be saying is that the response from the server depends on the selected ciphersuite. Implicitly you are saying that in another part of the document, namely in Section 8.2 "MTI Extensions". Ciao Hannes --aBwxRtRx19NJRbvDnOVrMQrdIKkvXtmF1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW6HSkAAoJEGhJURNOOiAtMLYH/ihhYEtlFbJvhjI944+saXQ2 SUCmnE3b4Izs6T2/DBnNrGwdvA3rt0OhwShBb/s5AY57aC4vza1U7znNju95G/tN K7WXFBgaPEUKw6x3lrQiz5/FqShv3vnBCxhyxRsEwhd+zit3dyp9DO190OyFyhLY lXuleRTccOVZnMHY2P31MVWXWoUcDY6b3sW4gY7RJhyKnYc3bSFMv4w3JiXabfo7 kcT0Sf3sl83gCTn94kYaHY/ygfXg8mJiJPkzo/e9MqbqbdneiC/9NU3S+TVEejMr HqjCIqKcx3CiOgusWVyoC4f547BL3MOAs/evmt9PcOJXcOkQG+XBN9EIQqKfxjs= =F95K -----END PGP SIGNATURE----- --aBwxRtRx19NJRbvDnOVrMQrdIKkvXtmF1-- From nobody Tue Mar 15 13:59:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74AE612D9E8 for ; Tue, 15 Mar 2016 13:59: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_RED=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 7sWMof6s-wRV for ; Tue, 15 Mar 2016 13:59:52 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 BC64012D784 for ; Tue, 15 Mar 2016 13:59:52 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id mh10so25931848igb.0 for ; Tue, 15 Mar 2016 13:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=aubnXyGXITRTHV6LelblEGqPKVxklwbBCAwJfjuD3y4=; b=fWh9MDNM4mR+4II4uZOezjMPVSjKzrE9bZ4M9hoYwDNhawngy5yrTCs/jXWBu4TYGr 6LNj55A2BEJAdyWtUNXCF2+3/kBbNl7JONagalp8PfH/KH5b3wZ6+idmQ/RWAMbnahED snaQCBaEDkl6Ze75ZtyBWgpXa0yvIdTgCalbdSnG0detf13FIQ4dGEnZvF6ahAZP//0G OPg9I2bcAFRMs4ycJC7acQegB8YYDe5J1HtyWq+aADOOqqEjjk4eC1K2aQRcC4E2tf1Z Pf2jglwg5nb/8wl5EGfNQ3PbnKEFLrmttAZ2QLn8NjBtPliCLhldHRzNKaqkkLCT89RN 54wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aubnXyGXITRTHV6LelblEGqPKVxklwbBCAwJfjuD3y4=; b=K8MdoRBeoSNQBCCBIEtyk06VHUrdu/rYmhUiJQBJvHXMMEnqMQQsvMESz1YLxwCQAX 8l5Ac+XrUuG54E1M+eAdcU6bSdebv4kvv25bAmtm90ABeWfigESk6AfG7UXTUyKkm9oN 5Ii2xH1pe12YaBCHGfL7OGrYSUEJk7Snaa6P9H5v/CrHG5ZUMURHyd0MgmHsa+4SVKdM Obh47yGwjdWnZ2NpZx9pIB4myVMS5JGrlr7P7zuOsRfauID7bOOkGisfUPDeqbeYqjo8 0pE6BOLCBi3iVKpHTIWH8q4L+O9keofQhOeyHhLTEOiZh2qmApabclP/gkr6qdbdrwC9 q63w== X-Gm-Message-State: AD7BkJJbmlSSmzxxZa6BDgPNcymZT3u4O7rxhQfsBCj7HOccB8YawLcs0jMQlqoGMdPdSorFWhUJAL42q28z/3bt MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr873634igt.4.1458075591817; Tue, 15 Mar 2016 13:59:51 -0700 (PDT) Received: by 10.107.137.80 with HTTP; Tue, 15 Mar 2016 13:59:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2016 13:59:51 -0700 Message-ID: From: Bill Cox To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=047d7bdc15b2b4fa86052e1cad71 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:59:55 -0000 --047d7bdc15b2b4fa86052e1cad71 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2016 at 1:21 PM, Colm MacC=C3=A1rthaigh wrote: > > Here the resumption counts have to be synchronized between the client and > server, but is the count cryptographically authenticated? can can attacke= r > can take 0RTT data from session N, increment the resumption count, and > replay that 0RTT data? > Crud, your right. You broke that protocol in record time! To make this work with the existing TLS 1.3 spec, I think the server will have to encrypt the ticket, which involves the whole ticket encryption key management overhead. Yuk. > Since synchronization and authenticity are both required here, would it b= e > simpler to use the sequence number and PRF state from the session? it can > be saved by the client and server on session close, and they take off whe= re > they left things on any subsequent connection. That also gives clients an= d > their users additional confidence in the protocol: the server can't just > ignore things like resumption counts. > I prefer your solution, but it would require getting the TLS 1.3 protocol changed. TLS 1.3 seems to be geared towards making stateless resumption with reusable tickets. The issue seems to be that in TLS 1.3, tickets are reusable multiple times to resume sessions, so we can't store the TLS sequence number in the ticket. If this were being used for an actual pre-shared key resumption, it would probably be OK, but it seems to break security in multiple ways when using tickets for TLS 1.2-style resumption, leaving us with no choice but to emulate the continuation of the TLS sequence numbers (and PRF state? Is that needed?). Another sort of warm and fuzzy reason I like this is that the whole thing > resembles a single-long-running regular TLS connection over a single TCP > socket. That makes things easier to verify, and some things easier to > implement. > That's the idea... but hard to implement, and not at all documented. > To see that this provides roughly TLS 1.2 security, note that so long as >> the protocol never has to drop to 1-RTT, it is basically equivalent to T= LS >> 1.2 session-ID based resumption. When we do drop down to 1-RTT, we will >> replay 0-RTT application data, opening up new replay attacks. However, >> after this paper >> , I do >> not believe there are any significant new replay attacks against HTTPS, >> ssh, or any real protocol I can think of. >> > > Unfortunately I don't think that's a safe assumption. The paper is about > browser behavior, but there are API clients and SDKs that do not retry as= a > matter of design, they rely on TLS for non-replayability. In any event, > there might be no problem: wouldn't it be a TLS library bug if the librar= y > somehow fell back to 1-RTT mode while also decrypting and passing on the > 0RTT data? the client and the server need to agree on whether it was > received. > This is worth more careful examination. Each new protocol should be analyzed for compatibility with session-cache based 0-RTT. However, I have not found any protocols that would have a problem. Can you? Protocols seem to fall into two camps. The ones that require replay resistance from the TLS layer all seem to terminate TLS connections in the same place so that the session cache can be safely and efficiently synchronized, avoiding replay attacks even when using 0-RTT. For example, when ssh-ing into a machine, that one machine terminates the connections, and can have a shared cache. None of the 0-RTT TLS-layer replay attacks I've read seem to work against a single server-side session cache. The other camp is HTTP-like protocols that terminate all over the place. These all seem to be replay-tolerant because random network errors will cause random replays, and there is no efficient way to synchronize the session cache globally. Bill > > --047d7bdc15b2b4fa86052e1cad71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 15, 2016 at 1:21 PM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:

<= div>Here the resumption counts have to be synchronized between the client a= nd server, but is the count cryptographically authenticated? can can attack= er can take 0RTT data from session N, increment the resumption count, and r= eplay that 0RTT data?

Crud, your right.=C2=A0 You broke that protocol in record time!=C2=A0 To= make this work with the existing TLS 1.3 spec, I think the server will hav= e to encrypt the ticket, which involves the whole ticket encryption key man= agement overhead.=C2=A0 Yuk.
=C2=A0
Since = synchronization and authenticity are both required here, would it be simple= r to use the sequence number and PRF state from the session? it can be save= d by the client and server on session close, and they take off where they l= eft things on any subsequent connection. That also gives clients and their = users additional confidence in the protocol: the server can't just igno= re things like resumption counts.=C2=A0

I prefer your solution, but it would require getting t= he TLS 1.3 protocol changed.=C2=A0 TLS 1.3 seems to be geared towards makin= g stateless resumption with reusable tickets.

The = issue seems to be that in TLS 1.3, tickets are reusable multiple times to r= esume sessions, so we can't store the TLS sequence number in the ticket= .=C2=A0 If this were being used for an actual pre-shared key resumption, it= would probably be OK, but it seems to break security in multiple ways when= using tickets for TLS 1.2-style resumption, leaving us with no choice but = to emulate the continuation of the TLS sequence numbers (and PRF state?=C2= =A0 Is that needed?).

Another sort of= warm and fuzzy reason I like this is that the whole thing resembles a sing= le-long-running regular TLS connection over a single TCP socket. That makes= things easier to verify, and some things easier to implement.=C2=A0
<= /div>

That's the idea... bu= t hard to implement, and not at all documented.
=C2=A0
To see that= this provides roughly TLS 1.2 security, note that so long as the protocol = never has to drop to 1-RTT, it is basically equivalent to TLS 1.2 session-I= D based resumption.=C2=A0 When we do drop down to 1-RTT, we will replay 0-R= TT application data, opening up new replay attacks.=C2=A0 However, after this paper, I do not believe there are any significan= t new replay attacks against HTTPS, ssh, or any real protocol I can think o= f.=C2=A0

Unfortunately I= don't think that's a safe assumption. The paper is about browser b= ehavior, but there are API clients and SDKs that do not retry as a matter o= f design, they rely on TLS for non-replayability. In any event, there might= be no problem: wouldn't it be a TLS library bug if the library somehow= fell back to 1-RTT mode while also decrypting and passing on the 0RTT data= ? the client and the server need to agree on whether it was received.

This is worth more care= ful examination.=C2=A0 Each new protocol should be analyzed for compatibili= ty with session-cache based 0-RTT.=C2=A0 However, I have not found any prot= ocols that would have a problem.=C2=A0 Can you?

Pr= otocols seem to fall into two camps.=C2=A0 The ones that require replay res= istance from the TLS layer all seem to terminate TLS connections in the sam= e place so that the session cache can be safely and efficiently synchronize= d, avoiding replay attacks even when using 0-RTT.=C2=A0 For example, when s= sh-ing into a machine, that one machine terminates the connections, and can= have a shared cache.=C2=A0 None of the 0-RTT TLS-layer replay attacks I= 9;ve read seem to work against a single server-side session cache.

The other camp is HTTP-like protocols that terminate all o= ver the place.=C2=A0 These all seem to be replay-tolerant because random ne= twork errors will cause random replays, and there is no efficient way to sy= nchronize the session cache globally.

Bill
=C2=A0

=
--047d7bdc15b2b4fa86052e1cad71-- From nobody Tue Mar 15 14:13:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B466C12DD90 for ; Tue, 15 Mar 2016 14:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLZAt_lr5Pir for ; Tue, 15 Mar 2016 14:13:10 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 5E08312DAFD for ; Tue, 15 Mar 2016 14:13:10 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m184so40233205iof.1 for ; Tue, 15 Mar 2016 14:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=EgIUTGQEgzL9/roL0RNTkLycyIZLU5iPWY256RcBhEk=; b=HlGZWf3IbS7UNyYwH5r/2YHqztqHJ0rDNjGFXll4AhcnA4n9NzL25QfX/7Zvwq5bh1 +V/UHr7EDDaO3I7DqXkCHoLwQAkl0NpOQBfjSe/j9jb2IpMqG0Z0ianI1gNkgkTGDLb/ ZkYa/2u++HoL+A0uAf7obaesxF9wy18PTD+Ozwd5PDpypPYqLUT/Cu++mZmkJyHrFYp6 I29nxMEH7lZs9upFX5GRiguAzjl/X/tXREz4DV4HUyjyiKHrtxqyi8WTTXeTdCDLdhy1 q/I/hWoelhqJ5pbTx5N7I1OAQlTZdjVDmB0TjyutdYZ5V1DRrkUo92ICk216AImGSkGK ZqSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=EgIUTGQEgzL9/roL0RNTkLycyIZLU5iPWY256RcBhEk=; b=KhsE1wBe08ue5gbw/A2dwm6Q2mVIXvR6aiqOvDcBl/Glq4U05kLHN3XWM31Z9ZhPy6 Zu2vl9iH58pF44sea81Kop69V68/F+3XR91ih4TawgoXYn98nEl9K+AJ2IgPI/KNImb6 enqQBRCshUuRn01cbM5crCEJx11sDNuVxALd72bS2JYNR6cU6CSc1arOi1JTLJE6bs5U deDznNs2grahuEiWAv1amdLxx4sD9fXsRVn+27eknAicpAuQDSrUlD4KilnWA4YIJdbQ H27ef/L0CspeRDcGDl8FS5Z6SeA/9l9QlSBdDnz+P+95RN1HE4IcfcGaHKNUojELdztf RN0w== X-Gm-Message-State: AD7BkJKY3MA0T+yH/H9671hrl1jD/cOgqzKmowFHwwJXPNINOnbIMuL5VvF7laKE2B1hPxpyI6qfBSoJHFpEYryB MIME-Version: 1.0 X-Received: by 10.107.8.30 with SMTP id 30mr910614ioi.60.1458076389623; Tue, 15 Mar 2016 14:13:09 -0700 (PDT) Received: by 10.107.137.80 with HTTP; Tue, 15 Mar 2016 14:13:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2016 14:13:09 -0700 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a113fb716428621052e1cdd52 Archived-At: Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:13:11 -0000 --001a113fb716428621052e1cdd52 Content-Type: text/plain; charset=UTF-8 Second attempt, since Colm already broke my first attempt: It uses a traditional server-side session-cache in addition to the current client-side session-cache in TLS 1.3, and also a server-side ticket encryption key. The protocol looks like this: During the initial 1-RTT handshake: - create an encrypted ticket containing only the session ID and a "resumption count" set to 0 - send the ticket to the client During a 0-RTT resumption handshake: - Decrypt the tikcet and get the session ID from the ticket, check for a cache hit, and drop to 1-RTT if not found - compare the resumption counts in the session state and ticket, and fall back to 1-RTT if they do not match - increment the resumption count in the ticket and session state - send the updated ticket to the client There is little PFS here. Some can be had by flushing stale cache entries and rotating the ticket encryption key often. Are there any holes in this scheme? Bill --001a113fb716428621052e1cdd52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Second attempt, since Colm alre= ady broke my first attempt:

It uses a traditional serv= er-side session-cache in addition to the current client-side session-cache = in TLS 1.3, and also a server-side ticket encryption key.=C2=A0 The protoco= l looks like this:

During the initial 1-RTT handshake:
- create an encrypted ticket containing only the session ID and a &qu= ot;resumption count" set to 0
- send t= he ticket to the client

During a 0-RTT resumption handshake:
- Decrypt the tikcet and get the session ID from the ticket, ch= eck for a cache hit, and drop to 1-RTT if not found
- compare the resumption counts in the session state and ticket, a= nd fall back to 1-RTT if they do not match
= - increment the resumption count in the ticket and session state
- send the updated ticket to the client

There is little PFS= here.=C2=A0 Some can be had by flushing stale cache entries and rotating t= he ticket encryption key often.

<= div class=3D"gmail_extra">Are there any holes in this scheme?

Bill
 --001a113fb716428621052e1cdd52-- From nobody Tue Mar 15 14:29:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7D512DDBD for ; Tue, 15 Mar 2016 14:29:25 -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 BxAp6gkPBm9x for ; Tue, 15 Mar 2016 14:29:08 -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 6040612DDAF for ; Tue, 15 Mar 2016 14:29:08 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id m126so14329309ywd.0 for ; Tue, 15 Mar 2016 14:29:08 -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=hNz3FaAOdgv48/G0ZVvRrQcvLt35jYKfjp4lgLJtX9E=; b=GlGoUayfNtDGAtRkPOljZU2WSxw6jPm1ZcaawYlv7Az+g7eYwAggJK1y82kXo8RoX/ 2v3kGCie4tZFRmrbbyAEHqdHgTL5zNe3ws3ALUj3OTNShmzwJ/ikVwvUHDfNFuGFi22f yE0FO3g4Q8yZycaPhzVIgcmGmESTHi7QlETCEexaCyQu9miME4xRhEc89QIxgijMwU44 Dqk0I3IEOx371hDe47FwT1fHHSxWaZPxxmv3y1BMsmKY+u7CNeKlqISg4jUaEBHtOJyX MCbAEDvwrjZpy2NyPb3LwO0nabF4PT1OqUj3qMoEQXMfXiHJg4/PlgCnN6z+UzsofBer iDRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hNz3FaAOdgv48/G0ZVvRrQcvLt35jYKfjp4lgLJtX9E=; b=XXZUQeOsLKi8i5KU9D5oVWuiIF45CQHbiQnu/+dYJ3pm5QazEcEh6ghxrIJwagjFo4 Uepu91vhEGZF12mvNiRgTIdQTMts9gwCSV4Bhioc32cXHy5E/n1ECnffd21IQeJ5CPLy oQfbOnT67WZdv8uw6zWKVdg2lRYmzQ+WjwCEN9b4W7ZiThBmnGpMi6N44SCkT3lrv+cZ AuT948KgSgGX0tXqsJIxgYL214w4NvrMvsOzHzPVrSmYlnMONcMKKgFTJCjHmCKxKmHq wWgX49iSZLpN9/KU3ZBqgk7d8AQmXISy61NWQifltZddc21pQxNtKBjYkrZmlmzPfTtB 28Wg== X-Gm-Message-State: AD7BkJL1wyv/Ej2qf6PXdjkOqFvRauI3980idqdqo7zqUF9LTtp6PwH4yyvAjTADEqoOLpMzyUYtGIYgEFtcUw== X-Received: by 10.129.80.69 with SMTP id e66mr111942ywb.231.1458077347521; Tue, 15 Mar 2016 14:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 15 Mar 2016 14:28:28 -0700 (PDT) In-Reply-To: <56E874A4.3030506@gmx.net> References: <56E874A4.3030506@gmx.net> From: Eric Rescorla Date: Tue, 15 Mar 2016 14:28:28 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a1147f0785b047d052e1d1671 Archived-At: Cc: "" Subject: Re: [TLS] PSK in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:29:25 -0000 --001a1147f0785b047d052e1d1671 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2016 at 1:46 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Ekr, Hi all, > > I am not entirely sure about the PSK story in TLS 1.3. > > In Section 6.2.3 I read that the PSK approach has been combined with > resumption. > > Appendix A4 lists the defined ciphersuites but there is no PSK-based > ciphersuite in that list. > This is editorial skew. I'll be adding them shortly. Section 6.3.1.2 explains that the ServerHello message handling: > > " > The server will send this message in response to a ClientHello message > when it was able to find an acceptable set of algorithms and the > client=E2=80=99s =E2=80=9Ckey_share=E2=80=9D extension was acceptable. If= the client proposed > groups are not acceptable by the server, it will respond with a > =E2=80=9Chandshake_failure=E2=80=9D fatal ale > " > > What this text should be saying is that the response from the server > depends on the selected ciphersuite. Implicitly you are saying that in > another part of the document, namely in Section 8.2 "MTI Extensions". > Sorry, I'm not following your question here. Can you say more? -Ekr > Ciao > Hannes > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1147f0785b047d052e1d1671 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 15, 2016 at 1:46 PM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:
Hi = Ekr, Hi all,

I am not entirely sure about the PSK story in TLS 1.3.

In Section 6.2.3 I read that the PSK approach has been combined with
resumption.

Appendix A4 lists the defined ciphersuites but there is no PSK-based
ciphersuite in that list.

This is edito= rial skew. I'll be adding them shortly.


Section 6.3.1.2 explains that the ServerHello message handling:

"
The server will send this message in response to a ClientHello message
when it was able to find an acceptable set of algorithms and the
client=E2=80=99s =E2=80=9Ckey_share=E2=80=9D extension was acceptable. If t= he client proposed
groups are not acceptable by the server, it will respond with a
=E2=80=9Chandshake_failure=E2=80=9D fatal ale
"

What this text should be saying is that the response from the server
depends on the selected ciphersuite. Implicitly you are saying that in
another part of the document, namely in Section 8.2 "MTI Extensions&qu= ot;.

Sorry, I'm not following your = question here. Can you say more?

-Ekr
= =C2=A0

=C2=A0
Ciao
Hannes


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


--001a1147f0785b047d052e1d1671-- From nobody Tue Mar 15 14:45:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4C312D661 for ; Tue, 15 Mar 2016 14:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 z_a1e47O3rRc for ; Tue, 15 Mar 2016 14:45:04 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE8012D568 for ; Tue, 15 Mar 2016 14:45:03 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id m126so14797922ywd.0 for ; Tue, 15 Mar 2016 14:45:03 -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:date:message-id:subject:from:to :cc; bh=AFXRBdorqy2kCcCpXTZwtURZC93EYRojNvhpGSmQzQo=; b=eS8eTWasi08B6DH04KUUun3bVfxWzzH6+ub7h8aeVEBC34Dg8UiQe8pvxnnLuQ/u5D 9VsJ97NG8OFm+2DTqfuChpnYiIrksQrfP7r8cqfEyp9QKZz92rk24sxx/l0JtonVkP2i y3d2wybC1qXG0C/wvXfkEnnKquuQ0BFZYBhygq33a6nQIh6hchXPGiXrcKx5bsaiAbmX lEiughm72qjToqC3f0a+t/Kv/VLrSeiHuSzIzUnnmAPQaGoWlP8YQAHuR5kNfcMrXCAz mizhPtfWwNYynaONTSnbcgJDdEi8hzj1El6ZwolX1yB0bPzCTmfBnp40fHAUMWu+a0H3 xUmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AFXRBdorqy2kCcCpXTZwtURZC93EYRojNvhpGSmQzQo=; b=Q8JbU7gALc6U/ApHQtWLtmZN6qh6TtCZM3OSEAYE+aDyUVX2RcOZRe+fSROWwT5Ofo WSouMAOCsVyZBi6Ybc7XzR6rQFnbrmDAGNXgIRVTb/rLAlNHDYOcB1duAM+hiYWf0mfy mVPJCQKaS3H9wvOKmrn3bv5zeb3w4T7hhh5FgQlztzlOcPpxfliAVKEgt+MKpnMgcjS6 l5AatJlUrF48XgGthdMgv9CR/irVXI9Gwy8onYitth+RB+79RWdorhm6uW0uKHpfKScd RBihWUKsg4wNFpOn0DxDPCmiOaHnnqdht8QhazJ+QL9zDfBJUhX7Yt+xpZ6fYK7xZqee it1A== X-Gm-Message-State: AD7BkJL6BozWe6lhCFnNL0NAhYwAfXRET/1hz24khTAY9JSfvb28U6h8evUNvoPrme9sdtQwASssUzoB9itdrg== MIME-Version: 1.0 X-Received: by 10.129.155.81 with SMTP id s78mr163309ywg.24.1458078302934; Tue, 15 Mar 2016 14:45:02 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Tue, 15 Mar 2016 14:45:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2016 17:45:02 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Bill Cox Content-Type: multipart/alternative; boundary=94eb2c0b8e7c4d55f6052e1d4f96 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:45:06 -0000 --94eb2c0b8e7c4d55f6052e1d4f96 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 4:59 PM, Bill Cox wrote: > I prefer your solution, but it would require getting the TLS 1.3 protocol > changed. TLS 1.3 seems to be geared towards making stateless resumption > with reusable tickets. > We keep circling that alright, and it doesn't work without sacrificing FS and/or replay-protection :( > The issue seems to be that in TLS 1.3, tickets are reusable multiple times > to resume sessions, so we can't store the TLS sequence number in the > ticket. If this were being used for an actual pre-shared key resumption, > it would probably be OK, but it seems to break security in multiple ways > when using tickets for TLS 1.2-style resumption, leaving us with no choice > but to emulate the continuation of the TLS sequence numbers (and PRF > state? Is that needed?). > Sorry; I confused things by saying with PRF-state, but what I had in mind there was turning the crank on the PRF to derive new encryption and mac keys for the resumed session. If you do it that way; and if the PRF provides anti-backtracking, then compromising the session cache can only be used to decrypt future resumed connections, rather than anything previously collected or currently active. If you're going to increment state for each resumption; might as well provide forward secrecy too. Protocols seem to fall into two camps. The ones that require replay > resistance from the TLS layer all seem to terminate TLS connections in the > same place so that the session cache can be safely and efficiently > synchronized, avoiding replay attacks even when using 0-RTT. For example, > when ssh-ing into a machine, that one machine terminates the connections, > and can have a shared cache. None of the 0-RTT TLS-layer replay attacks > I've read seem to work against a single server-side session cache. > I think I agree with that; but maybe would state it as: we can preserve forward secrecy and replay mitigation for 0RTT data, but at the cost of read-after-write consistency from a server-side data-store. The store needn't be transactional, an eventually consistent store could be used: but the miss-rate would be elevated over what we see today. So it would work better in the single server case than the many distributed servers case - but could work for both. > The other camp is HTTP-like protocols that terminate all over the place. > These all seem to be replay-tolerant because random network errors will > cause random replays, and there is no efficient way to synchronize the > session cache globally. > I think that's a dangerous position too. Triggering browser retries requires a certain level of difficulty and has a certain amplification factor. Sniffing wifi and sending a TCP message is far easier. An attacker could exhaust things like server-side request throttling limits far more quickly with the latter than the former. Besides: lowering our own levels of security because other tools have already done the same is just another race to the bottom. -- Colm --94eb2c0b8e7c4d55f6052e1d4f96 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 15, 2016 at 4:59 PM, Bill Cox <waywardge= ek@google.com> wrote:
I prefer your solution, but i= t would require getting the TLS 1.3 protocol changed.=C2=A0 TLS 1.3 seems t= o be geared towards making stateless resumption with reusable tickets.

We keep circling that a= lright, and it doesn't work without sacrificing FS and/or replay-protec= tion :(=C2=A0
=C2=A0
The iss= ue seems to be that in TLS 1.3, tickets are reusable multiple times to resu= me sessions, so we can't store the TLS sequence number in the ticket.= =C2=A0 If this were being used for an actual pre-shared key resumption, it = would probably be OK, but it seems to break security in multiple ways when = using tickets for TLS 1.2-style resumption, leaving us with no choice but t= o emulate the continuation of the TLS sequence numbers (and PRF state?=C2= =A0 Is that needed?).

Sorry; I confused things by saying with PRF-state, but what I had in min= d there was turning the crank on the PRF to derive new encryption and mac k= eys for the resumed session. If you do it that way; and if the PRF provides= anti-backtracking, then compromising the session cache can only be used to= decrypt future resumed connections, rather than anything previously collec= ted or currently active. If you're going to increment state for each re= sumption; might as well provide forward secrecy too.

Protocols seem to fall into two camps.=C2=A0 = The ones that require replay resistance from the TLS layer all seem to term= inate TLS connections in the same place so that the session cache can be sa= fely and efficiently synchronized, avoiding replay attacks even when using = 0-RTT.=C2=A0 For example, when ssh-ing into a machine, that one machine ter= minates the connections, and can have a shared cache.=C2=A0 None of the 0-R= TT TLS-layer replay attacks I've read seem to work against a single ser= ver-side session cache.

=
I think I agree with that; but maybe would state it as: we can preserv= e forward secrecy and replay mitigation for 0RTT data, but at the cost of r= ead-after-write consistency from a server-side data-store. The store needn&= #39;t be transactional, an eventually consistent store could be used: but t= he miss-rate would be elevated over what we see today. So it would work bet= ter in the single server case than the many distributed servers case - but = could work for both.
=C2=A0
<= div dir=3D"ltr">
= The other camp is HTTP-like protocols that terminate all over the place.=C2= =A0 These all seem to be replay-tolerant because random network errors will= cause random replays, and there is no efficient way to synchronize the ses= sion cache globally.

I think that's = a dangerous position too. Triggering browser retries requires a certain lev= el of difficulty and has a certain amplification factor. Sniffing wifi and = sending a TCP message is far easier. An attacker could exhaust things like = server-side request throttling limits far more quickly with the latter than= the former. Besides: lowering our own levels of security because other too= ls have already done the same is just another race to the bottom.=C2=A0
=
--
Colm
--94eb2c0b8e7c4d55f6052e1d4f96-- From nobody Tue Mar 15 16:06:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209AE12DE4A for ; Tue, 15 Mar 2016 16:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RI2i2pjGdvyK for ; Tue, 15 Mar 2016 16:06:52 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A61B12DE56 for ; Tue, 15 Mar 2016 16:06:45 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h129so40996098ywb.1 for ; Tue, 15 Mar 2016 16:06:45 -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=309xqfWdGx7UJ+bQGYFfIv2T+HS3OOateZLLpY1cYRM=; b=NOCYx5nHE0d1isAncFn1u7IVCvxnnCwLtP/xV7fLIgeQ8LHzhmj/G2qb15KwSKvNII r4vR8Ny0ujnholIxA+CKuGYokM66fB8+fnX/a5XQQxqmDVswEb1WZStj74P8LYehGYvR kekluQrP92HmExSpqO3NHqlDBVjp+S95JFdSEdXYUJEIjJhmM5QjfCv4BBQiKjyGvYef TvqpTvGB1dudTvcH764onO82oUQYJ8WnxMevngageUgDSaqI5nh4mcVNt5Xw7RBZCTcn 4keQcmDdq1c6wU/y64VFkIyCpOLc/nl36DUU4/c2+ygxV8o1ovqYHG4dTZzvo/BirNnY yulA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=309xqfWdGx7UJ+bQGYFfIv2T+HS3OOateZLLpY1cYRM=; b=auh9lMoL/3bpgiD3uzyKzw87qnepuHJf7XsQV+ubKs5xaRgNY9PmAfaYbGchRDlZYn Hiaez2hjfe+MFTbFxDCXdgV5OIUw3bDyvdCwgt0EUBvOEAfaHGRwHgB5SYflt6ZuoABB ycIV+X9amXclIPFB0O0A+eO31l9v1ABLjrmBlPpiZOkKwDuGNepAZ4GOvMDbwIdsp9Bl JM0hT6kQnf6+NaKGgm7FzZIfXGNIKUu/rbNNWd0L1N8XazscJlYvgXgAkAheTiWiO0en zuK4862ocNbqroj+U6FqNQIqxq6FFFdZr9c8JLqIfGmrMJITO4l/cEqkZqciwg9MuKqu HtWA== X-Gm-Message-State: AD7BkJJ1iq7ggJB327qMbcW2GaRwsAHD1YE9DDCVVmMdDHmIAutheaoSxGxwXYSjR/m4YZ3UHrpEsui91f0PCg== X-Received: by 10.37.230.202 with SMTP id d193mr332377ybh.74.1458083204350; Tue, 15 Mar 2016 16:06:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 15 Mar 2016 16:06:04 -0700 (PDT) In-Reply-To: References: <201601152007.12464.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 15 Mar 2016 16:06:04 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=94eb2c0afb0e732850052e1e7348 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:06:55 -0000 --94eb2c0afb0e732850052e1e7348 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin wrote: > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > >> David, >> >> Thanks for being patient with me here. Sorry it took so long >> >> As usual, this seems like a question of whether we're going to want a lot >> of flexibility >> (thus motivating orthogonal negotiation) versus whether we're going to >> want little flexibility >> (thus motivating suites). I think that with the historical practice, the >> arguments for orthogonal >> negotiation were a lot stronger, but now that we seem to be leaning >> towards (a) fewer algorithms >> and (b) having algorithms which are themselves suites, I do agree that >> the pendulum is swinging >> more towards suites. >> > > I would probably characterize it less as suites vs orthogonality, but as > wanting to keep divisions in meaningful and universal places and not > splitting up tightly-coupled decisions. The flexibility from orthogonality > can be handy, but going too far---as I believe TLS 1.2 did with signature, > prehash, and curve---complicates everything. Imagine if negotiating > AES_128_GCM required separately negotiating block cipher AES-128, mode CTR, > and MAC GHASH. > Like I said, it's a balance :) On balance, I guess, I'm neutral-to-supportive of this change in general, >> if others in the WG want >> to make it. On the details: >> >> - It seems like we could let measurements tell us what code points we >> need. If we never see >> P256-SHA512 in the wild, then we don't need it (and can add it later if >> needed). >> > > I guess this relates to the fun issue of how TLS sigalgs interacts with > X.509. If we believe they are at most a hint for X.509, then I think we can > freely declare that TLS 1.3+ requires curve/hash matching for NIST curves. > Unlike PKCS#1 v1.5, I doubt anyone has smartcards that can only sign > P384-SHA256. > > If we believe that non-matching certificates are forbidden in TLS, then, > yeah, it's a concern. > I think we concluded that they weren't forbidden, but I believe it would be best if they generally matched. - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll >> probably want to define >> code points for 1.5 in both in-protocol (CertificateVerify) and >> certificates to distinguish these. >> > > Oh? Why would they need to be separate? The others defined for both aren't. > The idea here would be that we want to be able to deprecate the use of v1.5 in CertificateVerify before its us in certs (which we can't deprecate for quite some time). -Ekr > > David > > >> As far as process, it seemed like people were generally positive about >> this in this discussion, >> but I'll rely on the chairs to determine consensus. >> >> -Ekr >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin >> wrote: >> >>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: >>> >>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin >>>> wrote: >>>> >>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett >>>>> wrote: >>>>> >>>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. >>>>>> In TLS >>>>>> > 1.2, signature algorithms are spread across the handshake. >>>>>> [...] >>>>>> > I propose we fold the negotiable parameters under one name. >>>>>> [...] >>>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>>>> SignatureAndHashAlgorithm as >>>>>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>>>>> that >>>>>> > instead. >>>>>> >>>>>> I previously proposed this here: >>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>>>> >>>>>> ekr was against it, though it hasn't been discussed that throughly. >>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>>>> >>>>> >>>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it >>>>> and forgot. >>>>> >>>>> ekr, are you still against this sort of thing? I think the new CFRG >>>>> signature algorithms tying decisions together is a good argument for why >>>>> we'd want this. If we believe this trend is to continue (and I hope it >>>>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>>>> seems poor. >>>>> >>>> >>>> I'm not sure. I agree that the CFRG thing seems to be a new >>>> development. I'll >>>> try to confirm my previous opinion or develop a new one over the >>>> weekend :) >>>> >>> >>> ekr, did you have confirmed or new thoughts on this change? >>> >>> From elsewhere in the thread, I put together a draft PR if you wanted >>> something to look at in that form. >>> https://github.com/tlswg/tls13-spec/pull/404 >>> It incorporated some of the suggestions in the thread (not mentioning >>> the really legacy values, pairing NIST curves with hashes, etc.), but >>> that's not the important part. The meat of the proposal is unifying >>> signature algorithms under one number and a shared interface, which I think >>> is a valuable simplification. >>> >>> David >>> >> >> --94eb2c0afb0e732850052e1e7348 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin <= davidben@chromiu= m.org> wrote:
On Mon, Ma= r 14, 2016 at 8:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
David,

Thanks for be= ing patient with me here. Sorry it took so long

As= usual, this seems like a question of whether we're going to want a lot= of flexibility
(thus motivating orthogonal negotiation) versus w= hether we're going to want little flexibility
(thus motivatin= g suites). I think that with the historical practice, the arguments for ort= hogonal
negotiation were a lot stronger, but now that we seem to = be leaning towards (a) fewer algorithms
and (b) having algorithms= which are themselves suites, I do agree that the pendulum is swinging
more towards suites.

I would probably characterize it less as suites vs orthogonality, but as= wanting to keep divisions in meaningful and universal places and not split= ting up tightly-coupled decisions. The flexibility from orthogonality can b= e handy, but going too far---as I believe TLS 1.2 did with signature, preha= sh, and curve---complicates everything. Imagine if negotiating AES_128_GCM = required separately negotiating block cipher AES-128, mode CTR, and MAC GHA= SH.

Like I said, it's= a balance :)



On balance, I gu= ess, I'm neutral-to-supportive of this change in general, if others in = the WG want
to make it. On the details:

= - It seems like we could let measurements tell us what code points we need.= If we never see
=C2=A0 P256-SHA512 in the wild, then we don'= t need it (and can add it later if needed).
I guess this relates to the fun issue of how TLS sigalg= s interacts with X.509. If we believe they are at most a hint for X.509, th= en I think we can freely declare that TLS 1.3+ requires curve/hash matching= for NIST curves. Unlike PKCS#1 v1.5, I doubt anyone has smartcards that ca= n only sign P384-SHA256.

If we believe that non-ma= tching certificates are forbidden in TLS, then, yeah, it's a concern. <= /div>

I think we concluded that= they weren't forbidden, but I believe it would be best if
th= ey generally matched.


=
- If we decide to allo= w PKCS#1 v1.5 for in-protocol signatures, then we'll probably want to d= efine
=C2=A0 code points for 1.5 in both in-protocol (Certificate= Verify) and certificates to distinguish these.

Oh? Why would they need to be separate? The others d= efined for both aren't.

The idea here would be that we want to be able to deprecate the use of v= 1.5 in
CertificateVerify before its us in certs (which we can'= ;t deprecate for quite some
time).

-Ekr<= /div>
=C2=A0
<= br>
David
=C2=A0
As far as process,= it seemed like people were generally positive about this in this discussio= n,
but I'll rely on the chairs to determine consensus.
<= div>
-Ekr



<= div>




<= div>




On Mon, Feb 29, 2016 at 9:1= 6 AM, David Benjamin <davidben@chromium.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote:<= br>
On Fri, Jan 15, 2016 at 5:19 PM, David = Benjamin <davidben@chromium.org> wrote:
On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com> = wrote:
On Friday, January 15, 2016 = 03:45:34 pm David Benjamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG = thing seems to be a new development. I'll
try to confirm = my previous opinion or develop a new one over the weekend :)

ekr, did you have confirmed or new thoughts on this= change?

From elsewhere in the thread, I put together a draft PR if = you wanted something to look at in that form.
https://github.com/tlswg/t= ls13-spec/pull/404
It incorporated some of the suggestion= s in the thread (not mentioning the really legacy values, pairing NIST curv= es with hashes, etc.), but that's not the important part. The meat of t= he proposal is unifying signature algorithms under one number and a shared = interface, which I think is a valuable simplification.

David


--94eb2c0afb0e732850052e1e7348-- From nobody Tue Mar 15 18:38:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EC912D6B1 for ; Tue, 15 Mar 2016 18:38: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x_E5sKMaf2Xy for ; Tue, 15 Mar 2016 18:38:43 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 CE10D12D84A for ; Tue, 15 Mar 2016 18:38:42 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g203so46341441iof.2 for ; Tue, 15 Mar 2016 18:38:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=WVU1UHOoTV8wO3zHCO5tN/+ndUb+SG3x3hwha8If2/A=; b=HprMrsMMWSPKFvU/7uo+bpAQzutIcAPvutUmP/ssLRv7zSELBBZ84ZwwZPp1Z7HpGV bsR3yfrUf8lAQgY9dhm1Cr4MHTO5q3mXqEyVEZmHaYAC2xy/DLasZmpbSzwPLpKP69GN Q3kt7djO9pepYhra3ge/sappYT5ZzskTvQoTqnFwkOYKIR6sgnjNY+D4t7w5yyNLhxfJ qaMKIrWhMs7o5Q2DbHtA4tIes0kFlF5NzZcXv38fdJ1Fue4AcqUsqJSRPY3Rkj909WVQ ye0myYJv+W/KS4gV7EB2GUhs+bAHYqiDdgci8hTS4+vmPNIVlT5MN+6EwybIXW9000GJ nLbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=WVU1UHOoTV8wO3zHCO5tN/+ndUb+SG3x3hwha8If2/A=; b=OIy2Q8Rl3bcB5hUg73HyT9A/g1b/ybPEx6BUCzCXmb0tU+TR58CDo/RnDBMRwwQn1D yFZFNeQJYQ4ffKCxNO+BKEoM2u4OCw9qthQYsmyzAtLo10ZW5Al4Se5Crv42yR7/Sh53 FkYxapymADdlThFwwDPNb1z+3HCjPm5qP5Awfc26dq/UW0PgQ7Wawy1PaK+ZXSn7Ys8E 15WT7WHqQVZ7caSJL5yMRvsmVWQozyRJsc0KPLvBwe/0QKijLUUzKQYujKNn799T+lGY 312JFXDeFsiRDP8JbabfNkBr/0QgrEdlwOK7M3XqcBfasZSvPd2PeJoAwUUGYRXk7MKD iKpg== X-Gm-Message-State: AD7BkJLqAi7CbijqOD1TgUwd9HR19iM63CpLMWK1ylYiUx/KkhMPnqSnKUNHWtm1RtQH0ALqVHOva3QSSw0gn/4j MIME-Version: 1.0 X-Received: by 10.107.8.30 with SMTP id 30mr1875813ioi.60.1458092321928; Tue, 15 Mar 2016 18:38:41 -0700 (PDT) Received: by 10.107.137.80 with HTTP; Tue, 15 Mar 2016 18:38:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Mar 2016 18:38:41 -0700 Message-ID: From: Bill Cox To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=001a113fb716e64bb4052e209265 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:38:44 -0000 --001a113fb716e64bb4052e209265 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 15, 2016 at 2:45 PM, Colm MacC=C3=A1rthaigh wrote: > I think I agree with that; but maybe would state it as: we can preserve > forward secrecy and replay mitigation for 0RTT data, but at the cost of > read-after-write consistency from a server-side data-store. The store > needn't be transactional, an eventually consistent store could be used: b= ut > the miss-rate would be elevated over what we see today. So it would work > better in the single server case than the many distributed servers case - > but could work for both. > Hmm... my first thought is we can't say all that in a "simple secure 0-RTT" description :) I do think it would help if all that and more were in a more comprehensive document somewhere. > >> The other camp is HTTP-like protocols that terminate all over the place. >> These all seem to be replay-tolerant because random network errors will >> cause random replays, and there is no efficient way to synchronize the >> session cache globally. >> > > I think that's a dangerous position too. Triggering browser retries > requires a certain level of difficulty and has a certain amplification > factor. Sniffing wifi and sending a TCP message is far easier. An attacke= r > could exhaust things like server-side request throttling limits far more > quickly with the latter than the former. Besides: lowering our own levels > of security because other tools have already done the same is just anothe= r > race to the bottom. > I would be happy if we could recommend at least one reasonably secure method for 0-RTT for HTTPS that has a reasonable chance of satisfying the skeptics, and then state that 0-RTT for other protocols, and stateless 0-RTT, needs to be carefully considered for the application. --001a113fb716e64bb4052e209265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 15, 2016 at 2:45 PM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:
I think I agree with = that; but maybe would state it as: we can preserve forward secrecy and repl= ay mitigation for 0RTT data, but at the cost of read-after-write consistenc= y from a server-side data-store. The store needn't be transactional, an= eventually consistent store could be used: but the miss-rate would be elev= ated over what we see today. So it would work better in the single server c= ase than the many distributed servers case - but could work for both.
=

Hmm... my first thought = is we can't say all that in a "simple secure 0-RTT" descripti= on :) =C2=A0I do think it would help if all that and more were in a more co= mprehensive document somewhere.

=C2=A0
The o= ther camp is HTTP-like protocols that terminate all over the place.=C2=A0 T= hese all seem to be replay-tolerant because random network errors will caus= e random replays, and there is no efficient way to synchronize the session = cache globally.

I think that= 's a dangerous position too. Triggering browser retries requires a cert= ain level of difficulty and has a certain amplification factor. Sniffing wi= fi and sending a TCP message is far easier. An attacker could exhaust thing= s like server-side request throttling limits far more quickly with the latt= er than the former. Besides: lowering our own levels of security because ot= her tools have already done the same is just another race to the bottom.=C2= =A0

I would be happy if we coul= d recommend at least one reasonably secure method for 0-RTT for HTTPS that = has a reasonable chance of satisfying the skeptics, and then state that 0-R= TT for other protocols, and stateless 0-RTT, needs to be carefully consider= ed for the application.
--001a113fb716e64bb4052e209265-- From nobody Tue Mar 15 21:33:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2812D7CB for ; Tue, 15 Mar 2016 21:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 o40DhkYMaBId for ; Tue, 15 Mar 2016 21:33:41 -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 A977212D56B for ; Tue, 15 Mar 2016 21:33:41 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id m126so24150527ywd.0 for ; Tue, 15 Mar 2016 21:33:41 -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:date:message-id:subject:from:to :cc; bh=X4LI0jATIQstW5oLXuZRYRyo/PBvqmkay8SgcVgHjyM=; b=z09IzjPZqfsc+2d6AHWLv6qxSHCGe9qMnxcMlxWea+hqoEbnTI6/QfPi4rQhzg8QxW G3GnRWIAHQmUm5qDbXHLLtPfvYW6YxbO5j5Xj6SNSF2xjogRRcZj42tuRuAwlqOE2zRy p1WGfnED82FstBAy7biXBW2Ats1QQH6i7KA/CrYrQf18QPxlEUmaNyg4J6E08exTnPuO h4V7Qwk18vulqQ3RvQaQUFTgb4WcW1lyUwB1XV5F/AvGU/KXU4xxPafiWSBtC1pvVq5C KF1GOQ9paB4edKUtafKEs/Nzo1WsmBAG3okAwGO29uu0emTeQH3K7Yew/U5LgeLwxzjS fmOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=X4LI0jATIQstW5oLXuZRYRyo/PBvqmkay8SgcVgHjyM=; b=M+Cs8vV9k5kvxxsvX2229bz5CuVuGHGA+B+uXeypEuUzkZM/3tT+52Cpu95QCY/+Nj VKof/kGSfQwljiCp6q19Ch0NnH9TygdFTWoz2cF9gDIMcaXqWKMR8Wm5oiGgEz0B6VKd jSUPlsGM2rGah4IrbC780ZiRjaDsM02g+v49nscvM6PfcRxIBXcj4dt7vUBQehBzBRZI ZF3VyAQ0Xk1ljz45mKlP6A6xmglbahxe0JNX+sPZIIFlo4zTsMEejs1mPIqkx7tTAjDh V9qVERTXWu6A1z7tqqpTHKMo6ZDKQ2oJBg99iTPOHLNkPrTmq+UVKD87ccPGJijC0qX9 03Rw== X-Gm-Message-State: AD7BkJKNUZU7/yIf1sILUw4OcdMlW4/fA0HPbkPxTCrcVTvU7VCr7WBwAXcEs8EBbwvdouCCi7lo4W8Tk0jxvA== MIME-Version: 1.0 X-Received: by 10.13.210.7 with SMTP id u7mr739650ywd.100.1458102820861; Tue, 15 Mar 2016 21:33:40 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Tue, 15 Mar 2016 21:33:40 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 00:33:40 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Bill Cox Content-Type: multipart/alternative; boundary=001a114e7e78af2cab052e23043f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:33:43 -0000 --001a114e7e78af2cab052e23043f Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox wrote: > I would be happy if we could recommend at least one reasonably secure > method for 0-RTT for HTTPS that has a reasonable chance of satisfying the > skeptics, and then state that 0-RTT for other protocols, and stateless > 0-RTT, needs to be carefully considered for the application. > After meditating on this a little, how about something like this: Benefits Forward secrecy: * Clients SHOULD use a resumption ticket only once, and get a new resumption ticket when using an existing one. Benefits Forward Secrecy and Idempotence: * Client and server should erase the existing ticket upon use. (a captured early data section is mooted for replay quite quickly in the default "good" case) Benefits Idempotence; * Make early data and application data separate record layer content types. Make it clear that they do not form a continuous stream; you can't simply concatenate them at the application level and bolt on to existing protocols such as HTTP, SMTP, etc. * Advise that clients using 0RTT SHOULD occasionally send duplicate early data handshakes. As a normal part of the protocol, a well behaved client should intentionally do what an attacker might do and send the whole section twice, causing the server to resolve the duplication. Keep the anti-bodies strong. -- Colm --001a114e7e78af2cab052e23043f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox <wayward= geek@google.com> wrote:
=
I would be happy= if we could recommend at least one reasonably secure method for 0-RTT for = HTTPS that has a reasonable chance of satisfying the skeptics, and then sta= te that 0-RTT for other protocols, and stateless 0-RTT, needs to be careful= ly considered for the application.

After meditating on this a little, how about something like= this:

Benefits Forward secrecy:

* Clients SHOULD use a resumption ticket only once, and get a new r= esumption ticket when using an existing one.=C2=A0

Benefits Forward Secrecy and Idempotence:

* Clien= t and server should erase the existing ticket upon use.=C2=A0
(a captured early data section is mooted for replay quite quick= ly in the default "good" case)

Benefits = Idempotence;

* Make early data and application dat= a separate record layer content types. Make it clear that they do not form = a continuous stream; you can't simply concatenate them at the applicati= on level and bolt on to existing protocols such as HTTP, SMTP, etc.

* Advise that clients using 0RTT SHOULD occasionally send= duplicate early data handshakes. As a normal part of the protocol, a well = behaved client should intentionally do what an attacker might do and send t= he whole section twice, causing the server to resolve the duplication. Keep= the anti-bodies strong.

--
Colm
--001a114e7e78af2cab052e23043f-- From nobody Wed Mar 16 01:17:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5112D7D3 for ; Wed, 16 Mar 2016 01:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQJbYrSKuCn4 for ; Wed, 16 Mar 2016 01:17:31 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 75AA212D7D4 for ; Wed, 16 Mar 2016 01:17:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 77D6A3116; Wed, 16 Mar 2016 10:17:19 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 2ZI7IFBWhE6K; Wed, 16 Mar 2016 10:17:19 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3342821C; Wed, 16 Mar 2016 10:17:19 +0200 (EET) Date: Wed, 16 Mar 2016 10:17:17 +0200 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Message-ID: <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:17:34 -0000 On Wed, Mar 16, 2016 at 12:33:40AM -0400, Colm MacCárthaigh wrote: > On Tue, Mar 15, 2016 at 9:38 PM, Bill Cox wrote: > > > I would be happy if we could recommend at least one reasonably secure > > method for 0-RTT for HTTPS that has a reasonable chance of satisfying the > > skeptics, and then state that 0-RTT for other protocols, and stateless > > 0-RTT, needs to be carefully considered for the application. > > > > After meditating on this a little, how about something like this: > > Benefits Forward secrecy: > > * Clients SHOULD use a resumption ticket only once, and get a new > resumption ticket when using an existing one. > > Benefits Forward Secrecy and Idempotence: > > * Client and server should erase the existing ticket upon use. > > (a captured early data section is mooted for replay quite quickly in the > default "good" case) The best that can be done w.r.t. "forward secrecy" is to erase the decryption-capable key used for 0-RTT on both sides, and never sending it on the wire, even encrypted. > * Make early data and application data separate record layer content types. > Make it clear that they do not form a continuous stream; you can't simply > concatenate them at the application level and bolt on to existing protocols > such as HTTP, SMTP, etc. You mean inner (encrypted) content type, right (outer content type would still be 23[TLS PROTECTED DATA]? > * Advise that clients using 0RTT SHOULD occasionally send duplicate early > data handshakes. As a normal part of the protocol, a well behaved client > should intentionally do what an attacker might do and send the whole > section twice, causing the server to resolve the duplication. Keep the > anti-bodies strong. Such duplication does not occur in attack conditions. The duplication from attack conditions takes two forms: - Duplication of 0-RTT data into 1-RTT data of _different_ connection. - Duplication of 0-RTT data into 0-RTT data of _different_ connection. In both cases, the connections are different, not the same. And this makes a difference if e.g. protocol banners are sent as 0-RTT (and such may very well be critical for latency). -Ilari From nobody Wed Mar 16 05:00:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4543D12D801 for ; Wed, 16 Mar 2016 05:00:31 -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=bblfish-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 PJ2N1ugBTZ33 for ; Wed, 16 Mar 2016 05:00:28 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E2A212D906 for ; Wed, 16 Mar 2016 05:00:19 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id l68so186705032wml.0 for ; Wed, 16 Mar 2016 05:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bblfish-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=zHHzd+DSATEhb4PgJWwwF7Dh/ZzSta7hcs+F9xBbJvc=; b=TGxuOWsgvUnr7V8m2plm7r+MEEPGA1oEyr8wU+503BdXYYRYDwQaEICuL3FoYlAzQb TfXQ67cj/UqtauoSuS50c8KEVoHO0YF48AsurnWleaz5Z1xa3RXCw4wPp14t2J7WZUs8 rOJX5J5FA1QbqNonrDsCbSubLEa3S+aw8GV43HMxGbkPcI+I59rTQtWN+Q2HlsWiZmae FJpgopKzCJqOBdqdzpckxf8UUlxoDGeO6Wo+JjKR4wlBG15S+l5tuf8yNxq44jSDGzxM NWOgqyxTYyxFviYmISi2XOFs4ZPJ41EKvmimfz7+/AB1DdM2+5tfbghIsoeAz3/2NuRH Pp8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=zHHzd+DSATEhb4PgJWwwF7Dh/ZzSta7hcs+F9xBbJvc=; b=ieJcqnnOSD7gVHZpqWsXYeNF5GEaCwSKSi8rLOMqaQDuCbJqvmPgvqfGuk8R0Rw2T3 XmCvWozyi+DAdchabgHthS8yXhW7RiUIOZgf4xvUKgOAUA0GGy8DWN9TStNuygD7Mbw7 petXpm9B0R1348AMFlGgSgAFK0nBZoarPhs6JnL2DAB64YKSyaqvE6FmBrnvXNtvEkq2 x0e+JS5UBUOj4LrvVUtMUAGHxgxAcm6XVKqkAaT5vIC7lXaOtH8akymieIdb7yq6v4Qw MyMwwOq5cZAngydytlKgKPKR5b/eJ7+cM0k3rN5OvtK024ipO2MO+Gu7+JKn7+h4dMrG /rlg== X-Gm-Message-State: AD7BkJJh8ys7xksm0v6vZ4WmS4c9RSwcRuap0gKG4vQKNDPkAG9+8RIIo7bsY6qKBHY5hg== X-Received: by 10.194.62.179 with SMTP id z19mr3576337wjr.96.1458129617557; Wed, 16 Mar 2016 05:00:17 -0700 (PDT) Received: from [192.168.1.11] (AAubervilliers-653-1-41-174.w83-114.abo.wanadoo.fr. [83.114.232.174]) by smtp.gmail.com with ESMTPSA id a10sm2719342wjb.38.2016.03.16.05.00.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Mar 2016 05:00:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7F22FED7-4EC4-4C7E-9EF9-11135CFF303C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Henry Story In-Reply-To: Date: Wed, 16 Mar 2016 13:00:44 +0100 Message-Id: <3E4912F8-55D6-45E9-AD52-7081ADC3306C@bblfish.net> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:00:31 -0000 --Apple-Mail=_7F22FED7-4EC4-4C7E-9EF9-11135CFF303C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 8 Mar 2016, at 09:30, Eric Rescorla wrote: >=20 > CertificateRequest already allows you to pass an arbitrary number of > extensions by OID. >=20 > http://tlswg.github.io/tls13-spec/#certificate-request = >=20 > What more do you think you need? Perhaps what would be needed in addition would be wildcard support. Eg, it would be useful to say: Give me certificates that contain an = extension without specifying the value of the extension. Eg: give me a certificate that = contains a=20 SAN or IAN, I don't care what value of those are. Is that allowed? I don't see anything regarding it when reading that = section. But I may be missing something. >=20 > -Ekr >=20 >=20 > On Tue, Mar 8, 2016 at 12:22 AM, Henry Story > wrote: > Hi, >=20 >=20 > I was reading with interest M. Thomson and M. Bishop's > "Reactive Certificate-Based Client Authentication" draft RFC [1]. > In the section 2.3 "The CERTIFICATE_REQUEST Frame" >=20 > [[ > CA-Count and Certificate-Authorities: "Certificate-Authorities" = is a > series of distinguished names of acceptable certificate > authorities, represented in DER-encoded [X690] format. These > distinguished names may specify a desired distinguished name for = a > root CA or for a subordinate CA; thus, this message can be used = to > describe known roots as well as a desired authorization space. > The number of such structures is given by the 16-bit "CA-Count" > field, which MAY be zero. If the "CA-Count" field is zero, then > the client MAY send any certificate that meets the rest of the > selection criteria in the "CERTIFICATE_REQUEST", unless there is > some external arrangement to the contrary. > ]] >=20 > Would it not be possible to extend that so that one could also pass > issuer Alternative Names, and not just DNs? >=20 > Using DNs made sense when it was thought that LDAP and X500 would > end up being the protocols for global directories. This turned out > not to be the case. It turned out that DNs were a special case of > what could be termed a URI (even though DNs are not in URI format). > And many (most?) URIs can refer to agents, least but not last > http(s) URLs (See the WebID spec [2] for a nice diagram of how this > works conceptually and the WebID-TLS spec for one way this can be tied > to TLS [3]). >=20 > If TLS1.3 could start moving away from sole reliance on DNs this > would open quite a lot of possibilities, including the ability to > build institutional Webs of trust for CAs (ie trust anchors could > list CAs by reference at one or more levels of indirection), and CAs > could also describe themselves at their URI. >=20 > Those last two paragraphs are just hints of some possibilities that > could emerge from moving away from DNs that I can think of. Others > members of this group will certainly find other possibilities. >=20 > In any case it seems that the time for DNs is passed, and that > one should perhaps move away from reliance on those and generalise > this part of TLS. >=20 > Henry >=20 >=20 >=20 > [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 = > [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview = > [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ = >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_7F22FED7-4EC4-4C7E-9EF9-11135CFF303C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 8 Mar 2016, at 09:30, Eric Rescorla <ekr@rtfm.com> = wrote:

CertificateRequest already allows you to pass an = arbitrary number of
extensions by OID.

http://tlswg.github.io/tls13-spec/#certificate-request

What= more do you think you need?

Perhaps what would be needed in addition would be = wildcard support.

Eg, it would be = useful to say: Give me certificates that contain an extension = without
specifying the value of the extension. Eg: give me a = certificate that contains a 
SAN or IAN, I don't care = what value of those are.

Is that = allowed? I don't see anything regarding it when reading that section. = But
I may be missing something.


-Ekr


On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <henry.story@bblfish.net> = wrote:
Hi,


  I was reading with interest M. Thomson and M. Bishop's
"Reactive Certificate-Based Client Authentication" draft RFC [1].
In the section 2.3 "The CERTIFICATE_REQUEST Frame"

[[
      CA-Count and Certificate-Authorities:  = "Certificate-Authorities" is a
      series of distinguished names of acceptable = certificate
      authorities, represented in DER-encoded [X690] = format.  These
      distinguished names may specify a desired = distinguished name for a
      root CA or for a subordinate CA; thus, this message = can be used to
      describe known roots as well as a desired = authorization space.
      The number of such structures is given by the = 16-bit "CA-Count"
      field, which MAY be zero.  If the "CA-Count" = field is zero, then
      the client MAY send any certificate that meets the = rest of the
      selection criteria in the "CERTIFICATE_REQUEST", = unless there is
      some external arrangement to the contrary.
]]

Would it not be possible to extend that so that one could also pass
issuer Alternative Names, and not just DNs?

Using DNs made sense when it was thought that LDAP and X500 would
end up being the protocols for global directories. This turned out
not to be the case. It turned out that DNs were a special case of
what could be termed a URI (even though DNs are not in URI format).
And many (most?) URIs can refer to agents, least but not last
http(s) URLs (See the WebID spec [2] for a nice diagram of how this
works conceptually and the WebID-TLS spec for one way this can be = tied
to TLS [3]).

If TLS1.3 could start moving away from sole reliance on DNs this
would open quite a lot of possibilities, including the ability to
build institutional Webs of trust for CAs (ie trust anchors could
list CAs by reference at one or more levels of indirection), and CAs
could also describe themselves at their URI.

Those last two paragraphs are just hints of some possibilities that
could emerge from moving away from DNs that I can think of. Others
members of this group will certainly find other possibilities.

In any case it seems that the time for DNs is passed, and that
one should perhaps move away from reliance on those and generalise
this part of TLS.

Henry



[1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01=
[2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview=
[3] https://www.w3.org/2005/Incubator/webid/spec/tls/

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


= --Apple-Mail=_7F22FED7-4EC4-4C7E-9EF9-11135CFF303C-- From nobody Wed Mar 16 05:13:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE49312D928 for ; Wed, 16 Mar 2016 05:13: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=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 ZKRXS0JZOl9Z for ; Wed, 16 Mar 2016 05:13:37 -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 0BABB12D942 for ; Wed, 16 Mar 2016 05:12:49 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id h129so58930799ywb.1 for ; Wed, 16 Mar 2016 05:12:49 -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:date:message-id:subject:from:to :cc; bh=kiQITQAKm6ZNG1Os4e3E+rNfBgsCXhAiHoiThOnqMUw=; b=s3uGzCrY1aj78eeBdfxtrL0DEInOOvdCUkA2NLwGrnonojV4DJNHEkQwX+S6QohD4i ZRHeJxiLBTHBPG/WX8Gavm6JCQLVfrydCSNZmMIfeLS5g2HL60slawzetkaLPczjG1V9 8DQjBco2XoMO4m9dkT+WuWTCdTR9mTj3gSUqDlMTUbXaRJpz4ToAfEMRYrWPJcZD6QMP ucVnPb9hmVOdFpnaOaqNZP3LQbSWf5MGjRPdbmhJ9s9VQ0XYexRkzuykldkeJHXGnVLO 6vFljgyRgyLpbucoWT78GusuqYk5p02devRQwRH8YSVzbm062ln/Z/KXcLmiaY+STv2P t29w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kiQITQAKm6ZNG1Os4e3E+rNfBgsCXhAiHoiThOnqMUw=; b=Q295Ha3AQ6mmXO7yObSCAQ3s+k0JykaGwKejAy5yKk7jCo7Ap/lApF1B+qgMKkZf6x 2QkHyKeOrqK5JMDvqbXNqxwoJn2AJuTgwCdE2kN2MmQcW8Syn4twQkIHV8KXJahslR9B 1Zbh3aiXfpBmJdD9iyeNewtnmozxPAoGew1XlVAtZo1DtKw/a2ST/BhjNwSr0UgHzGuD N5ZTx34VHk6o4hk7azTJWuuTFbmK3fTVlewSl9973XRDRNfc/PRuVJv5YimNweVeDN76 H1mOHBis1Z+RYExjSO+/tJSpjx6BDGKNSWTqOcI6Ti61q0qhAG5DpTP/XVkbxKNLwgeu wt9w== X-Gm-Message-State: AD7BkJLn+iwxzpMSEdU8whjm5clOvGfoTm3+6wTXPuHfdvYXXvqNYOzfW9qx2NgeulsNWMtLFUg3vaXifrNWzg== MIME-Version: 1.0 X-Received: by 10.13.192.5 with SMTP id b5mr1578508ywd.114.1458130368186; Wed, 16 Mar 2016 05:12:48 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 05:12:48 -0700 (PDT) In-Reply-To: <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 16 Mar 2016 08:12:48 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114e3f98a1fddb052e296ec5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:13:42 -0000 --001a114e3f98a1fddb052e296ec5 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara wrote: > > Benefits Forward Secrecy and Idempotence: > > > > * Client and server should erase the existing ticket upon use. > > > > (a captured early data section is mooted for replay quite quickly in the > > default "good" case) > > The best that can be done w.r.t. "forward secrecy" is to erase the > decryption-capable key used for 0-RTT on both sides, and never sending > it on the wire, even encrypted. > That's why I favor resuming connections where they left off, and cranking a PRF to generate new keys; but it's not compatible with tickets at all - works only with some kind of session store. > > * Make early data and application data separate record layer content > types. > > Make it clear that they do not form a continuous stream; you can't simply > > concatenate them at the application level and bolt on to existing > protocols > > such as HTTP, SMTP, etc. > > You mean inner (encrypted) content type, right (outer content type would > still be 23[TLS PROTECTED DATA]? > Yep, sorry. > > * Advise that clients using 0RTT SHOULD occasionally send duplicate early > > data handshakes. As a normal part of the protocol, a well behaved client > > should intentionally do what an attacker might do and send the whole > > section twice, causing the server to resolve the duplication. Keep the > > anti-bodies strong. > > Such duplication does not occur in attack conditions. The duplication > from attack conditions takes two forms: > > - Duplication of 0-RTT data into 1-RTT data of _different_ connection. > I think using a different content type solves this; the early data is illegal in the 1-RTT phase and the content type would distinguish it. > - Duplication of 0-RTT data into 0-RTT data of _different_ connection. > > In both cases, the connections are different, not the same. And this > makes a difference if e.g. protocol banners are sent as 0-RTT (and > such may very well be critical for latency). > The client would do what an attacker would; occasionally duplicate the handshake including early data, so it would use a different connection for it. The purpose here is to force a kind of "continuous testing in production" that means the protocol really really does have to have idempodence solved. As an aside: an application protocol where latency is so sensitive that 0RTT is attractive would hardly have its own back-and-forth with banners in the first place. -- Colm --001a114e3f98a1fddb052e296ec5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
> Benefits Forward Secrecy and Idempotence:
>
> * Client and server should erase the existing ticket upon use.
>
> (a captured early data section is mooted for replay quite quickly in t= he
> default "good" case)

The best that can be done w.r.t. "forward secrecy" is to e= rase the
decryption-capable key used for 0-RTT on both sides, and never sending
it on the wire, even encrypted.

That= 9;s why I favor resuming connections where they left off, and cranking a PR= F to generate new keys; but it's not compatible with tickets at all - w= orks only with some kind of session store.
=C2=A0
> * Make early data and application data separate record layer content t= ypes.
> Make it clear that they do not form a continuous stream; you can't= simply
> concatenate them at the application level and bolt on to existing prot= ocols
> such as HTTP, SMTP, etc.

You mean inner (encrypted) content type, right (outer content type w= ould
still be 23[TLS PROTECTED DATA]?

Yep, s= orry.
=C2=A0
> * Advise that clients using 0RTT SHOULD occasionally send duplicate ea= rly
> data handshakes. As a normal part of the protocol, a well behaved clie= nt
> should intentionally do what an attacker might do and send the whole > section twice, causing the server to resolve the duplication. Keep the=
> anti-bodies strong.

Such duplication does not occur in attack conditions. The duplicatio= n
from attack conditions takes two forms:

- Duplication of 0-RTT data into 1-RTT data of _different_ connection.
<= /blockquote>

I think using a different content type solv= es this; the early data is illegal in the 1-RTT phase and the content type = would distinguish it.
=C2=A0
- Duplication of 0-RTT data into 0-RTT data of _different_ connection.

In both cases, the connections are different, not the same. And this
makes a difference if e.g. protocol banners are sent as 0-RTT (and
such may very well be critical for latency).

The client would do what an attacker would; occasionally duplicate th= e handshake including early data, so it would use a different connection fo= r it. The purpose here is to force a kind of "continuous testing in pr= oduction" that means the protocol really really does have to have idem= podence solved.=C2=A0

As an aside: an application = protocol where latency is so sensitive that 0RTT is attractive would hardly= have its own back-and-forth with banners in the first place.
--
Colm
--001a114e3f98a1fddb052e296ec5-- From nobody Wed Mar 16 05:36:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A57712D52B for ; Wed, 16 Mar 2016 05:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scyKGtQbFgs2 for ; Wed, 16 Mar 2016 05:36:32 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54DD712D5DB for ; Wed, 16 Mar 2016 05:36:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458131792; x=1489667792; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bjaTq1gvz4fzLwjwudHVArWl5IzujZq8p94dEUbJqps=; b=da9Df1KECLhqwUEkfd2kZnF3kXgjqkVnJ166NmPp7Pi8+hpf7Hc0UwkQ lILMHQwj4whRlbV8N3PlKIFMkAfRf0GbqzgIBKkheaLffvxSWVUWwVdqs sMuNPUu7hwsFy0muL5Law4+XOPdg/YYsBRVeY2vKFFQtwLKz+5Kn8xbyw TkCyp0pkNBs/pDE3QGNZXUC4p/iYyNAsm5knXEdWt4ltmkfgfNiqQMpLN lAz8N6lC/ho0jSLpDhzS5WgS5SzvqrGoORj8ucFzpDWOEbvduPswQO+8u 0pc9GdHIuheGuSun42BhXK2RsnPmOuVrTCvZe6/jrKK6/EgpDsX7ueJwZ g==; X-IronPort-AV: E=Sophos;i="5.24,344,1454929200"; d="scan'208";a="74593851" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 17 Mar 2016 01:36:07 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Thu, 17 Mar 2016 01:36:05 +1300 From: Peter Gutmann To: "" Thread-Topic: TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2eg== Date: Wed, 16 Mar 2016 12:36:05 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:36:37 -0000 After a number of, uh, gentle reminders from people who have been waiting f= or=0A= this, I've finally got around to posting the TLS-LTS draft I mentioned a wh= ile=0A= back. It's now available as:=0A= =0A= http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt=0A= =0A= Abstract:=0A= =0A= This document specifies a profile of TLS 1.2 for long-term support,=0A= one that represents what's already deployed for TLS 1.2 but with the=0A= security holes and bugs fixed. This represents a stable, known-good=0A= profile that can be deployed now to systems that can't can't roll out=0A= patches every month or two when the next attack on TLS is published.=0A= =0A= Several people have already commented on it off-list while it was being=0A= written, it's now open for general comments...=0A= =0A= Peter.= From nobody Wed Mar 16 07:52:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6309D12D989 for ; Wed, 16 Mar 2016 07:52:51 -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=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 AOcRigVaFob3 for ; Wed, 16 Mar 2016 07:52:49 -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 8A42612D994 for ; Wed, 16 Mar 2016 07:52:49 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g3so64687456ywa.3 for ; Wed, 16 Mar 2016 07:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=GXXOunv/dRHyEkPK06mjMw9v/U4GDpNbI2WwscBxbfI=; b=D46+YK04/SkUqUgnVAaqAq87RC1yA/tCheJ1cZBX4GjsgVJl7Nm6Mdy1+KSbURZ0Ub 7Kc+w+hGUsRo163ATDL8h94ZAk+R+REUCji5oG+cOj+OfWDFkd5vPUQB7hgI53DJbqGA hKao8Dxx8LrMBdgTdJKgjtsN1cL7QgQElZwmp5AfDMw5SjgK/IX9D5m27BO/6xQX+Ecr 8frTXesegRRwiRRi70H1SdRZyVvyZS82Hcp63u8V/gqlcgB+VpHWy8ooqFUaw6RrwyBm RgOkNnVacClsJMzhv7CsVENH0ixr6tS/d9TPGZvIBo2hf7kMig3xExcfy5EVqdqfCCBw 3g6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=GXXOunv/dRHyEkPK06mjMw9v/U4GDpNbI2WwscBxbfI=; b=IWZH1j/YCPyPr3L4lXlC9tmxlVgzdORLvVQre+WrjdyjGMStxXa4Vb2/U0VarEbuXm rFH2UDF9v6IReElwexvx8H736KPfgPfUg2IMUsRMman83XXa3Kgz4lppFRABdHiVCal4 o0gQoR3vNITx0qQbY8BBqKKQrdowkqZQ8p+5secQDJBXFJCyt0YpgF67Q7WX+cAlp/b9 U4/YGGE6omWSiKtr2E1G7LYHiGNOxZASISHommbJMZyACMiI1n5j8BbBP9DG6uUBgtB9 1Nr+yiDaU4OyELjh1/j3dJRS4cnJK20Uh8GB4y5UHU6l36IGMSU7WGpV5FkQyY1VHuHE rYQg== X-Gm-Message-State: AD7BkJI9moghbi2kza0KcxOxOGkmX8VUy5gZ7mdbmr6DI9C5Y1I1tsg5kHeTjMLnfLF6Tz7fnaXFZi98fCGAgg== MIME-Version: 1.0 X-Received: by 10.129.72.78 with SMTP id v75mr2221797ywa.78.1458139968727; Wed, 16 Mar 2016 07:52:48 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 07:52:48 -0700 (PDT) Date: Wed, 16 Mar 2016 10:52:48 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114dcb02df1983052e2baa5f Archived-At: Subject: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:52:51 -0000 --001a114dcb02df1983052e2baa5f Content-Type: text/plain; charset=UTF-8 This has been bugging me for a long time and I've talked to some here about it in person, but this report; https://www.teamupturn.com/static/reports/2016/what-isps-can-see/files/Upturn%20-%20What%20ISPs%20Can%20See%20v.1.0.pdf provokes me to bring it up. Here's the crux of it; is it really a security win to recommend the AEAD cipher suites for TLS 1.2 users? The AEAD cipher suites as-implemented are byte-for-byte mappable to response sizes, with no padding for any kind of length hiding. This makes passive size analysis attacks quite a lot easier than they could be (a quick sample of wikipedia page sizes suggests that even 16 byte blocks raise the difficulty by orders of magnitude). The search hints attack outline in the paper may not even work with 16-byte padding. I want to emphasize that the attack here is passive, undetectable to servers or clients, and realistic - it's likely happening today. On the other side of the trade-off is that the AEAD mode ciphers are not susceptible to mac-then-encrypt issues, such as Lucky13. Some time ago I wrote up some detail on the Lucky13 attack: https://blogs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13 , and my take here is that the scenario is so unrealistic that the attack is simply impractical against TLS - even unmitigated. In any event, TLS CBC implementations have been mitigated and patched. Here I also want to emphasize that the attack is active - it generates lots of noisy signals - and may never have happened. Is it wise to make the real-world attack cost less, to mitigate the theoretical one? I also think AEAD mode is awesome: it's how crypto should be used, and want to give it a strong endorsement, but not at the cost of making on-the-wire data meaningfully less secure. At a minimum: could we agree that if a service/site is sensitive to privacy - it's reasonable for them to prefer AES-CBC; should they be penalized in SSL health analysis tools/reports for that configuration? it's not as flexible or useful as the padding in TLS1.3, but it's what we have. -- Colm --001a114dcb02df1983052e2baa5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

This has been bugging me for a long ti= me and I've talked to some here about it in person, but this report;


provokes me to bring it up. Here's the crux of it; is it really= a security win to recommend the AEAD cipher suites for TLS 1.2 users?=C2= =A0

The AEAD cipher suites as-implemented are byte= -for-byte mappable to response sizes, with no padding for any kind of lengt= h hiding. This makes passive size analysis attacks quite a lot easier than = they could be (a quick sample of wikipedia page sizes suggests that even 16= byte blocks raise the difficulty by orders of magnitude). The search hints= attack outline in the paper may not even work with 16-byte padding. I want= to emphasize that the attack here is passive, undetectable to servers or c= lients, and realistic - it's likely happening today.

On the other side of the trade-off is that the AEAD mode ciphers are= not susceptible to mac-then-encrypt issues, such as Lucky13. Some time ago= I wrote up some detail on the Lucky13 attack:=C2=A0https://blo= gs.aws.amazon.com/security/post/TxLZP6HNAYWBQ6/s2n-and-Lucky-13 , and m= y take here is that the scenario is so unrealistic that the attack is simpl= y impractical against TLS - even unmitigated. In any event, TLS CBC impleme= ntations have been mitigated and patched. Here I also want to emphasize tha= t the attack is active - it generates lots of noisy signals - and may never= have happened.=C2=A0

Is it wise to make the real-= world attack cost less, to mitigate the theoretical one? I also think AEAD = mode is awesome: it's how crypto should be used, and want to give it a = strong endorsement, but not at the cost of making on-the-wire data meaningf= ully less secure.=C2=A0

At a minimum: could we agr= ee that if a service/site is sensitive to privacy - it's reasonable for= them to prefer AES-CBC; should they be penalized in SSL health analysis to= ols/reports for that configuration? it's not as flexible or useful as t= he padding in TLS1.3, but it's what we have.=C2=A0

= --
Colm
--001a114dcb02df1983052e2baa5f-- From nobody Wed Mar 16 08:03:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261F212D9E2 for ; Wed, 16 Mar 2016 08:03:41 -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 8Zoxhh-aOm2Y for ; Wed, 16 Mar 2016 08:03:38 -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 5357312D9BD for ; Wed, 16 Mar 2016 08:02:43 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id c3so65044182vkb.3 for ; Wed, 16 Mar 2016 08:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=bk8AgswCsn09juTCLwB1t9oeg9cHrH3JJFZPSahIpZ0=; b=yWn5K8kUJHjphkZ7nXw3mUOUz46fedieB+x9L19+TFa5yyDniRpySN0H/HbUS5lFru v6PYUB8SpVCb+rqveWNOhu6xFfFaY1/rgBA5dJ0vMAfCB2HS+XF+bktO7CMJshs2EykT tsFpfeeiDO3xzQc7MbyhQzqxwNjO48tB7XC9QL9jp7nRTIicvB2LAUgmxqnaZZlo1BGY 5nA0vNGIgUdzEr80a2TzyZBKlb5pbRzLFSodSS+OgA8dPZJ6W1QQXtDDacgL1vzhr3py wAW+2I0cOxEJ9U2K4r+bvqarx9g6E1mff8Icf50BsI31vJW+Qm3UgFROdq885FJVpJdP jdZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bk8AgswCsn09juTCLwB1t9oeg9cHrH3JJFZPSahIpZ0=; b=EQvRkOzlpzLTmmRKqt6xRm1dHd2cseC3Ww6aNtu8U15i3p0mOEpIfmkizGA2FbUvX+ 7fDGph3O1jEN1l7OkIeatHnYcQV+hTKrnfvIZ2T6bwb/Dd4qFdlsKBfTZ09fGdvweWPO HV32xr6kM0XX3bGNKr48F85YjAybpOUeL2iKRszLCTA5fwnkswPvdmnOUyd+lbxG6oNS 2Fxoj0fqjyqE45sDKWLr5phxWGb11Chmw4F/ej7Xv01x1NLBjlWP1ZcnF2bx6Y+3Ee+w ZVXfrhye5/83j78b0suhYA3oXjyaMiirzo44zu4ArQ1A5axuWCHFHU2oOh/9CHQ5+5xP q5Ww== X-Gm-Message-State: AD7BkJKHIHpjJcdoInTOv5SL8nmSZ7AzAMsxhygTJgDQtZr5GTw9z6sk9x9f8iYCuX1wNV7Lc9hyXNxy96OP2w== MIME-Version: 1.0 X-Received: by 10.31.173.18 with SMTP id w18mr4531567vke.31.1458140562341; Wed, 16 Mar 2016 08:02:42 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Wed, 16 Mar 2016 08:02:42 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 16 Mar 2016 08:02:42 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:03:41 -0000 On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been waiting for > this, I've finally got around to posting the TLS-LTS draft I mentioned a while > back. It's now available as: > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt > > Abstract: > > This document specifies a profile of TLS 1.2 for long-term support, > one that represents what's already deployed for TLS 1.2 but with the > security holes and bugs fixed. This represents a stable, known-good > profile that can be deployed now to systems that can't can't roll out > patches every month or two when the next attack on TLS is published. > > Several people have already commented on it off-list while it was being > written, it's now open for general comments... Several comments: As written supporting this draft requires adopting the encrypt-then-MAC extension. But there already is a widely implemented secure way to use MACs in TLS: AES-GCM. Likewise, this draft modifies the way the master secret is computed, despite a widely implemented different solution to the problem, namely the EMS triple handshake fix. I don't see why these other solutions should be adopted over the ones that already are there. The use of uncompressed points makes off-curve attacks much easier than with compressed points. Recommendations to not reuse randoms for ECDH and to use Curve25519 would actually solve the problems, instead of what the draft has right now. The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively analyzed then TLS 1.2. It's almost like you don't believe cryptography exists: that is a body of knowledge that can demonstrate that protocols are secure, and which has been applied to the draft. The ladder diagram/state machine discussion ignores the real problem, which is not having either represented in the code. It doesn't direct readers to do anything that helps solve the problem, such as testing for the correct state transitions. > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Mar 16 08:31:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4E12D9FC for ; Wed, 16 Mar 2016 08:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqI0wkn2VyoG for ; Wed, 16 Mar 2016 08:31:49 -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 3B30312D9F5 for ; Wed, 16 Mar 2016 08:31:07 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h129so66225247ywb.1 for ; Wed, 16 Mar 2016 08:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PgdWL+paBRvDUWk/fxD9OX9e1kmI6bTjr+tjHwgqGPg=; b=c4ebKaeGCx/4AxHZVBky4SL9FHLEvEAGBPhsooh5b2jdM6UCevs9yOxJrbl3ZuSJYG 65Vgyf0Thgh3pQmJrpRjbCwnnSa0X2W9vsQvqZMTLDw/F25X3QgJEmN/ppuhveTb3o9I ejtWbJfx+Xc6bdmuky4hBZLXeNP19aes3Sh1ZlAbOKFs8LtdB2LWxderLJvO7+7Ym9zk bX1AkAlCNfVFS0EunXrqbi6n5VI4xumMv7DoV9S/Kozf01k02XoI6RRk8sp2ZUXYJnyY lyXT1SKdg44oqmU6TAGqGgxUKlIOuwke4pSx8xJfaZ7ElAOdgIEP1Cuj7SAObBsaylpB SXWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PgdWL+paBRvDUWk/fxD9OX9e1kmI6bTjr+tjHwgqGPg=; b=a7un6L4FrXxzrF7nu7sOSUf5Y3GaUvqxzvfIWPldtjM7A7+BiwItEkwk7sn28RKnKL G1g/7xj3lLckZgAbgXUeKQyjlPqULFbTFISIiHNPcSgfhmosN+QyIDkkwyVvpoJeXh5s ewgyMUt9zkuOnNfLQiTxflWbVpEmDdh/quhsWS2DxXCkze4pwk3jIG0niPQbJZxuPIfR /n7iR/C12wSbZJ49T3ZEWvh1B8f32tFN1MddUTd40ptpOkeOMfLIcy9bOkYpP605n9Lh o9QxIb28f3PVOlyvZS7S6WkSAddayCmLU3QIoyuOVzSgfA4gQcws+9lZahlJs3CIiTGE ehZg== X-Gm-Message-State: AD7BkJJzmmvl12YMZQEGV8V6iLu+1HEnzgs9fBrpYwJRspOMcvJsBLes9vvyGLOnv+6LexHfxPbBS2aARuf+O6Dc MIME-Version: 1.0 X-Received: by 10.13.231.132 with SMTP id q126mr2054691ywe.203.1458142266340; Wed, 16 Mar 2016 08:31:06 -0700 (PDT) Received: by 10.37.113.67 with HTTP; Wed, 16 Mar 2016 08:31:06 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 16 Mar 2016 08:31:06 -0700 Message-ID: From: Wan-Teh Chang To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:31:52 -0000 On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been waiting for > this, I've finally got around to posting the TLS-LTS draft I mentioned a while > back. It's now available as: > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt Section 3.4. "Implementation Issues" says: TLS-LTS requires that RSA signature verification be done as encode- then-compare, which fixes all known padding-manipulation issues: o TLS-LTS implementations MUST verify RSA signatures by using encode-then-compare, meaning that they encode the expected signature result and perform a constant-time compare against the recovered signature data. This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2, with the additional requirement that the comparison in Step 4 be constant-time, right? https://tools.ietf.org/html/rfc3447#section-8.2.2 and the alternative procedure outlined in the Note at the end of that section shall not be used? Note. Another way to implement the signature verification operation is to apply a "decoding" operation (not specified in this document) to the encoded message to recover the underlying hash value, and then to compare it to a newly computed hash value. This has the advantage that it requires less intermediate storage (two hash values rather than two encoded messages), but the disadvantage that it requires additional code. Thanks, Wan-Teh Chang From nobody Wed Mar 16 09:12:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96CB12D75D for ; Wed, 16 Mar 2016 09:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id suAuecHo1eXv for ; Wed, 16 Mar 2016 09:12:51 -0700 (PDT) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 CAC9912D626 for ; Wed, 16 Mar 2016 09:12:51 -0700 (PDT) Received: by mail-ig0-x232.google.com with SMTP id ig19so48360886igb.1 for ; Wed, 16 Mar 2016 09:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=9+Qrk3MKkXuCRJkWkTnc1RmnOBSrm9Fqx8R7Ozuo7ko=; b=aj5BZAsHqUoyjyxn4Wh8W/sUBuXvGUgAs+dVBZY+2W4m85ivU2BqxKx4M+VhFUMj5K nysB+VMdCezYKfkg8b9rhyR4rIlWKLqFlIRWdxUqKh+TUZT9M72qBI5QMtHldZEaLazz ZLtBJ0Rzn6PrGEvWLSFbcGlkpCLbWbsYTKXVwsqv2Xufpt7/rHKJmap+Ulxi2zyHfUBl MBTkylkq+P2R2z0S/l6IhBvzz7NlObsObznBkQYQomkiPOT52nX82L/Fxb/vPWqpR6ZR s9gey2IrNcN2pljYQC8xPiUOn0tCDq1DUq3CDgNbBeTaav30MRr8efncrSk/n4+5qQ9M yZDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9+Qrk3MKkXuCRJkWkTnc1RmnOBSrm9Fqx8R7Ozuo7ko=; b=APpD4WVuWEL2bZ6LNmexRoYb6L4Yle9IQcAUzxhpAwGVD1eatBcwUx68fvVtyhQweM nWatEFEUXxr65NjXCOX8fAeRd2eICxcTInezO7l4+EuZWagXimhJQDHY2AyElV/mnxxD 4/CM6KUZdLyudFJaYuiCr51kW4nkDESvFb5I3pFdWRBCuylH1LbmAO93JRpFHdmYIZFp esjXm9lAnz984rgvgATpsZTdAxMu3uiCUGyNzIpveUeTkmI9qWVov/sBlrTFVzKeSW8W /SFaVxHLI6KP0Z567+cy71/5W0acbq53+0CHb7NMXsEFes23cAXXkH9GFyB8O72zlIUr lJMQ== X-Gm-Message-State: AD7BkJLpVV2kSW5vT4U1BOOIj8NyFDGA8GcOEzX1SlnI7mFmTvb7oAOrW+sp+wWlSMl5bj7sEwLGzevpdCNrFUk/ MIME-Version: 1.0 X-Received: by 10.50.59.242 with SMTP id c18mr32408074igr.4.1458144771004; Wed, 16 Mar 2016 09:12:51 -0700 (PDT) Received: by 10.107.137.80 with HTTP; Wed, 16 Mar 2016 09:12:50 -0700 (PDT) In-Reply-To: References: <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 16 Mar 2016 09:12:50 -0700 Message-ID: From: Bill Cox To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=047d7bea423e1bccf1052e2cc9f4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:12:53 -0000 --047d7bea423e1bccf1052e2cc9f4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 16, 2016 at 5:12 AM, Colm MacC=C3=A1rthaigh wrote: > On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara > wrote: > >> > Benefits Forward Secrecy and Idempotence: >> > >> > * Client and server should erase the existing ticket upon use. >> > >> > (a captured early data section is mooted for replay quite quickly in t= he >> > default "good" case) >> >> The best that can be done w.r.t. "forward secrecy" is to erase the >> decryption-capable key used for 0-RTT on both sides, and never sending >> it on the wire, even encrypted. >> > > That's why I favor resuming connections where they left off, and cranking > a PRF to generate new keys; but it's not compatible with tickets at all - > works only with some kind of session store. > We can emulate resumption where we left off with the new ticket extension, as I try to do above in my "second attempt". Clearly this requires very careful implementation, or you would not have so easily broken my first attempt on this thread. This is why I think we should document it, and encourage people to analyze its security properties very carefully. If emulation of 0-RTT resumption from where we left off is found to be as secure as 0-RTT resumption from a cache with all the prior connection state, then I prefer the new ticket scheme because it also supports the riskier stateless forms of 0-RTT, which can improve speed, resumption success rates, and lower costs (QUIC does all three). I would love to see careful cryptanalysis of what we feel is the simplest secure 0-RTT mode we can offer with TLS 1.3 as it is today. One thing that helps me with analysis that I do not think is clear from the spec: the client MUST save the entire session state to do PSK resumption, other than: - the previous session secrets which should be erased and replaced with the resumption master secret - the TLS sequence numbers since the keys changed. Is this accurate? I think it is important for security analysis. Bill --047d7bea423e1bccf1052e2cc9f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 16, 2016 at 5:12 AM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:




--047d7bea423e1bccf1052e2cc9f4-- From nobody Wed Mar 16 09:45:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33F3312D54F for ; Wed, 16 Mar 2016 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJKsZnztB8WC for ; Wed, 16 Mar 2016 09:45:42 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0512D518 for ; Wed, 16 Mar 2016 09:45:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3A1431E56; Wed, 16 Mar 2016 18:45:40 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id fHv4aDoN619j; Wed, 16 Mar 2016 18:45:40 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 011312310; Wed, 16 Mar 2016 18:45:40 +0200 (EET) Date: Wed, 16 Mar 2016 18:45:39 +0200 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Message-ID: <20160316164539.GB21439@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:45:44 -0000 On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacCárthaigh wrote: > On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara > wrote: > > > > - Duplication of 0-RTT data into 1-RTT data of _different_ connection. > > > > I think using a different content type solves this; the early data is > illegal in the 1-RTT phase and the content type would distinguish it. Nope, this can not be realistically solved, _even_ with server state (the 0-RTT to 0-RTT duplication is unsolveable without state, but can be solved with server state). > As an aside: an application protocol where latency is so sensitive that > 0RTT is attractive would hardly have its own back-and-forth with banners in > the first place. The problem is that such banners would not be bound to the TLS connection in any way, which causes problems (TLS has no facility to transport data from application inside extension). -Ilari From nobody Wed Mar 16 09:46:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4035712D5A2 for ; Wed, 16 Mar 2016 09:46:18 -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=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 vR3v0UQ1MEH2 for ; Wed, 16 Mar 2016 09:46:16 -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 541D312D5C5 for ; Wed, 16 Mar 2016 09:46:16 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g3so69002656ywa.3 for ; Wed, 16 Mar 2016 09:46:16 -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:content-transfer-encoding; bh=N2hBDDBXFu/QgnKdPaIJg5Bgw73tzpCUwGJw6O4Go4Q=; b=dNO7f4GqzljV2w+isSq1OC1/xHplah4buY528LFx7U20YnrsieHKcF3PUnsx54uXBH V5cQtCMcnNcr4cRpzaWqj8O3H1H43db1wVaKgGUMgOqMMIsYn58Rl+NH11a3zQ0AH/tj tOYEYZ6sqLCGFJaqVK6rqHQeilw1Dhz+O95Vk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=N2hBDDBXFu/QgnKdPaIJg5Bgw73tzpCUwGJw6O4Go4Q=; b=AM3HHH2by6HPdOS3IIaolRFVWCENgF98Wld+XuDryo5mwkrJdAPuJUV0GMAnwHFOn+ 3cUH5xb44ZWljkVVyTOrmqZtZX27u4Nk7IrWtPrb9VySr71gnAgmZCUj8sbDdXZ3dGze ZxH5Kr75m4fHoRCo4g+GT4p/jzD1mjGf52rkJaJa00FdMTiwZwQsr6kpfNpbAXxVnuCR CaP4l9GvBuSt70RrfTPI62SXK6h6izyM5y8OalnkyqCWoecgqZnaq+btGVQOQuzJ7wgf yOg8K5wdhW1iLlraND8WEtHnw39UHQlQasLh4i+aPsQ1LdXwHYR92lE3KkACrahhXe3x ELOQ== X-Gm-Message-State: AD7BkJJSKM8eB0lGlu+BlF48N4h9HZ1vor31Ew+kG2XtwyQ/pxUWXVfdBFiOc3PpcHrMtOF68Rogw5QMlTlViRbs X-Received: by 10.37.230.139 with SMTP id d133mr2240363ybh.149.1458146775603; Wed, 16 Mar 2016 09:46:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.126.197 with HTTP; Wed, 16 Mar 2016 09:45:55 -0700 (PDT) In-Reply-To: References: From: Tom Ritter Date: Wed, 16 Mar 2016 11:45:55 -0500 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:46:18 -0000 On 16 March 2016 at 09:52, Colm MacC=C3=A1rthaigh wrote= : > At a minimum: could we agree that if a service/site is sensitive to priva= cy > - it's reasonable for them to prefer AES-CBC; should they be penalized in > SSL health analysis tools/reports for that configuration? it's not as > flexible or useful as the padding in TLS1.3, but it's what we have. If a site wants to actively do something to make length-hiding harder - to the point where they're go in and prefer CBC ciphersuites - why not just add 5 lines of code to a header template, to insert some random data in a HTML comment? I'm one of the biggest proponents for padding in TLS 1.3... and hope to see it used to make deployments of length-hiding and traffic analysis harder, so the HTML comment or similar tricks would be easier, more robust, and not require site modifications. But I don't think going back to CBC mode is a good idea. -tom From nobody Wed Mar 16 09:54:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1B12D62E for ; Wed, 16 Mar 2016 09:54:08 -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=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 LJ5HCR3U59uN for ; Wed, 16 Mar 2016 09:54:06 -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 5FED012D569 for ; Wed, 16 Mar 2016 09:54:06 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g3so69277737ywa.3 for ; Wed, 16 Mar 2016 09:54:06 -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:date:message-id:subject:from:to :cc; bh=SRN5wbPZdTFyXiztkgmnWU7uQjQ47GzxI9rK85Dkcww=; b=CBgiLCKDQdMQJdr0ftqdpfy+oBpaoWj79/4WHESjEgSB46VC8lLWdyBEEiw4jREG1k 1dkV3FfO/T/ULBegyD8Ex+bIWnrbNBBiqlsPs1QubM4SDHH8lG364sfS8U0vv7nOI72n q+7Fi37w2pc/4i8/Kap9X5JJift/Eb/910YAZVgTgMGSVlcPIVe73PjCi8G114zvJkev 1YTl7U043L5OvOfQKTuu6lspLl+IhAjPxqCgCFSgYPmIM3GylY2zf9g6E5trWr5FP4h7 /VhmCM6JXS/FLBImWkNka4lMp2URkR95/g7ODgPzPgat/syzWdKvGc4rlh50sgSXOO0j OjPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=SRN5wbPZdTFyXiztkgmnWU7uQjQ47GzxI9rK85Dkcww=; b=SSgHNG+ybB2FugsIrChEF4oI9oKL1VKRoUBxyd0vHmnkzjIC3QTi6VWP2E7mbILyXm kWb95VhKtRW1eYmbgk2KPvMBY71zKInp3okHhCtlaWsyKaSJtasuk2rCA4NpMQ+Bo7JH 6aN3CUgOVXs90EfcdKmQygzLJX0OR8LwSuXV1HRU59ejVohotdUvyOXJGP2oG9tz6lqV iueWGr7iVz/ZVbA5bZo2rzjOx5xG1BiLikc0wSz8EEOmBaA8WyfX+LYTvdbCrTrHO0up tYZFtmmoJtMZTVkYsaBWpjT/B0GVH+HU7WVgZFE25YcBGbEMtCom2eAAyLYKrFu041Ee xbbA== X-Gm-Message-State: AD7BkJJT4bmILP893HQOXUQ2/FIqAnp8Zc3h+7f2tD8ODuE2r20B1WCtAW3RaErW05j1VkkY8OwDqL0O01qlBw== MIME-Version: 1.0 X-Received: by 10.13.192.5 with SMTP id b5mr2354332ywd.114.1458147245645; Wed, 16 Mar 2016 09:54:05 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 09:54:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 12:54:05 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Tom Ritter Content-Type: multipart/alternative; boundary=001a114e3f989b99b7052e2d5c7e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:54:08 -0000 --001a114e3f989b99b7052e2d5c7e Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 12:45 PM, Tom Ritter wrote: > If a site wants to actively do something to make length-hiding harder > - to the point where they're go in and prefer CBC ciphersuites - why > not just add 5 lines of code to a header template, to insert some > random data in a HTML comment? > Length hiding is a game of costs, doing more can always help. But one of the benefits of being able to do it at the TLS layer is that it also helps you hide the length of the request. I'm one of the biggest proponents for padding in TLS 1.3... and hope > to see it used to make deployments of length-hiding and traffic > analysis harder, so the HTML comment or similar tricks would be > easier, more robust, and not require site modifications. But I don't > think going back to CBC mode is a good idea. > Why? -- Colm --001a114e3f989b99b7052e2d5c7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 16, 2016 at 12:45 PM, Tom Ritter <tom@ritter.vg> wrote:
If a site wants to actively do something = to make length-hiding harder
- to the point where they're go in and prefer CBC ciphersuites - why not just add 5 lines of code to a header template, to insert some
random data in a HTML comment?

Length h= iding is a game of costs, doing more can always help. But one of the benefi= ts of being able to do it at the TLS layer =C2=A0is that it also helps you = hide the length of the request.=C2=A0

I'm one of the biggest proponents for padding in TLS 1.3... and hope to see it used to make deployments of length-hiding and traffic
analysis harder, so the HTML comment or similar tricks would be
easier, more robust, and not require site modifications.=C2=A0 But I don= 9;t
think going back to CBC mode is a good idea.

Why?=C2=A0

--
Colm
--001a114e3f989b99b7052e2d5c7e-- From nobody Wed Mar 16 09:59:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE50612D52E for ; Wed, 16 Mar 2016 09:59:33 -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 a1e_C78_gB8q for ; Wed, 16 Mar 2016 09:59:32 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D82112D513 for ; Wed, 16 Mar 2016 09:59:32 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id l68so196680254wml.0 for ; Wed, 16 Mar 2016 09:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IysNwp1LbeExvVNdoAqSq0ID03Cg5EJP5g/2wzP+C7U=; b=lU3utKJuRlV6ZpzOcUD2t/+mtmRPLTD2PO4pHe8Nsvgn1wPYKOAhp1pmdkg2OdaJJZ feehoL4SgEplESFVkbyHHEUutjP4vlajzWQ7gH0U1zuAxTLtYuxJE/np8spCCgoTNJIP yyhgU9mHTygz89XX1jbyFmhmmQa/e81oUKLKAUqsISjGpNVkHh8AyPkicgRFzt7xIgjH EbmCh0W39hYL/0Pb9qGwRksQMzCeLIf6yqAyEYQ+/Vr7EiBHBq6Xs9B4eNGTbpQBl2Tv LBw+UZjJURAR883Xj6937HAncYCfqHTl0KVr7BKr60/uPq4RrDQJXa0lomdfoiWh9/WU JUIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IysNwp1LbeExvVNdoAqSq0ID03Cg5EJP5g/2wzP+C7U=; b=C7UtYFZptc+joMMb6ahI2dmbvzXWF2g4e4ynWrwxRbZO4/pEt61ipJla+rymxAghc2 CXMgCfL7UIxLd5VJ1z8S9soEn0d4t438HngPQyIwPwTnULzd/w6cKGK55jCKqZqXpGtK kabQhEbDfs5AgN+sdOcL6GHCLxkehVCRq5kfZmHz+uavBqIgR4lTLXK8PHL1gidOuR4G T8EG17nzFeBCCiP9Q1m8DFXYb4fXubvyvarXQbDGn8Q7hDkhXjHZqcMH7xndv4urmLav 0dkYzwSWXV/ilNQArN4YXKie0DTKiO9C9adDbtfL4/5//b/Gw0pNyKxEyIScALSUi45p YSIQ== X-Gm-Message-State: AD7BkJJVh6zUg0ffS+dmgOzvVm6qfZpuf8V5UHUjy1tyqvZ69yc8XaswwsrMNsMxtcI0VYey3eSuqKVtMRCoiw== X-Received: by 10.28.88.15 with SMTP id m15mr29882287wmb.60.1458147570592; Wed, 16 Mar 2016 09:59:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.28.140 with HTTP; Wed, 16 Mar 2016 09:58:51 -0700 (PDT) In-Reply-To: References: From: Alexandre Anzala-Yamajako Date: Wed, 16 Mar 2016 17:58:51 +0100 Message-ID: To: Tom Ritter Content-Type: multipart/alternative; boundary=001a1144294cf9b183052e2d6f62 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:59:34 -0000 --001a1144294cf9b183052e2d6f62 Content-Type: text/plain; charset=UTF-8 IMO, the layer creating the plaintext shouldn't have to pad it for security that's the job of the TLS layer. the TLS library should be parameterized by a size range and any plaintext larger than the range would get chunked up to smaller pieces while anything smaller would be padded. The actual value of the range could then be left to be chosen by the caller since this has an impact not only in security but also in performance. IIRC this how things are done in MiTLS (https://mitls.org/) -- Alexandre Anzala-Yamajako --001a1144294cf9b183052e2d6f62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
--001a1144294cf9b183052e2d6f62-- From nobody Wed Mar 16 10:02:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7733A12DA1A for ; Wed, 16 Mar 2016 10:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 2cSdQxoAmY8A for ; Wed, 16 Mar 2016 10:02:19 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336AF12DA00 for ; Wed, 16 Mar 2016 10:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EdnHURPv1xLlZx7/mwX6sevup5H3AzFCiY3jcgrkUDU=; b=h3ZH9dr+887jdvgC/BthFn7yO6mrMiDfOI2BsF+Sc51QHbPmOFPr9aiwz5toHedjU72Lk5M9bYvDvUNqPBdC3omPeCIwu4PuUjs2Xa+BSoLFD5JqiqaGTL7//MbrK1INws81JKitjL2BFMFS55iqSrdfQ/VCbBUm5apJMMbTgH4= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 17:02:15 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 17:02:16 +0000 From: Andrei Popov To: Henry Story , Eric Rescorla Thread-Topic: [TLS] Generalising DN's to SAN and IAN in TLS1.3? Thread-Index: AQHReRPpyna+fmf6VEO5ENmKma0iPJ9PN0iAgAzNgACAAFFmUA== Date: Wed, 16 Mar 2016 17:02:15 +0000 Message-ID: References: <3E4912F8-55D6-45E9-AD52-7081ADC3306C@bblfish.net> In-Reply-To: <3E4912F8-55D6-45E9-AD52-7081ADC3306C@bblfish.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: bblfish.net; dkim=none (message not signed) header.d=none;bblfish.net; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 666dc3da-847c-4e20-1183-08d34dbcba17 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:ma0jP9HBxB2w2YQrfY4mrR4GXhsY8mK8RkTXEPGDrgtJ4HTVTfgJkxTMg0/+7aJMWCO8cY1k37GYf2C4Qn743Fmx+9uDwqQ+VSEc+zaSN1YwCPO+PU9Th4qm2XENeQHSsRtat03+2Zbjw58NOiAruQ==; 24:io7XWZY1hqJ+vAgf6m1owCkUqMV98eT3MoQfltx/roNWqTt3O+o/pe1Q/89jszc5pB8+WqrC5uCaaMUMI0yY8N8yDrzKGrOG2ZojOXLDzRw= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19625215002)(2950100001)(106116001)(2906002)(50986999)(790700001)(54356999)(5001770100001)(76176999)(5008740100001)(102836003)(586003)(33656002)(6116002)(2900100001)(122556002)(92566002)(76576001)(16236675004)(1220700001)(10090500001)(189998001)(19609705001)(19617315012)(3280700002)(1096002)(86362001)(5004730100002)(77096005)(87936001)(5002640100001)(5005710100001)(19580405001)(10400500002)(19300405004)(15975445007)(3660700001)(81166005)(99286002)(74316001)(5003600100002)(10290500002)(4326007)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396523ABE524DE9528EAB318C8A0BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 17:02:15.8024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: "" Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:02:23 -0000 --_000_BLUPR03MB1396523ABE524DE9528EAB318C8A0BLUPR03MB1396namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Henry, Extension_data field can be zero-length: opaque extension_data<0..2^16-1>; The TLS 1.3 draft specifies matching rules for two extensions: KU and EKU a= nd then says: "Separate specifications may define matching rules for other certificate ex= tensions." Which means that you should be able to specify matching rules e.g. for SAN = or IAN where zero-length extension_data is interpreted as a wildcard. Getti= ng TLS/PKI implementations to implement this new specification is a differe= nt matter, of course. Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Henry Story Sent: Wednesday, March 16, 2016 5:01 AM To: Eric Rescorla Cc: Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3? On 8 Mar 2016, at 09:30, Eric Rescorla > = wrote: CertificateRequest already allows you to pass an arbitrary number of extensions by OID. http://tlswg.github.io/tls13-spec/#certificate-request What more do you think you need? Perhaps what would be needed in addition would be wildcard support. Eg, it would be useful to say: Give me certificates that contain an extensi= on without specifying the value of the extension. Eg: give me a certificate that conta= ins a SAN or IAN, I don't care what value of those are. Is that allowed? I don't see anything regarding it when reading that sectio= n. But I may be missing something. -Ekr On Tue, Mar 8, 2016 at 12:22 AM, Henry Story > wrote: Hi, I was reading with interest M. Thomson and M. Bishop's "Reactive Certificate-Based Client Authentication" draft RFC [1]. In the section 2.3 "The CERTIFICATE_REQUEST Frame" [[ CA-Count and Certificate-Authorities: "Certificate-Authorities" is a series of distinguished names of acceptable certificate authorities, represented in DER-encoded [X690] format. These distinguished names may specify a desired distinguished name for a root CA or for a subordinate CA; thus, this message can be used to describe known roots as well as a desired authorization space. The number of such structures is given by the 16-bit "CA-Count" field, which MAY be zero. If the "CA-Count" field is zero, then the client MAY send any certificate that meets the rest of the selection criteria in the "CERTIFICATE_REQUEST", unless there is some external arrangement to the contrary. ]] Would it not be possible to extend that so that one could also pass issuer Alternative Names, and not just DNs? Using DNs made sense when it was thought that LDAP and X500 would end up being the protocols for global directories. This turned out not to be the case. It turned out that DNs were a special case of what could be termed a URI (even though DNs are not in URI format). And many (most?) URIs can refer to agents, least but not last http(s) URLs (See the WebID spec [2] for a nice diagram of how this works conceptually and the WebID-TLS spec for one way this can be tied to TLS [3]). If TLS1.3 could start moving away from sole reliance on DNs this would open quite a lot of possibilities, including the ability to build institutional Webs of trust for CAs (ie trust anchors could list CAs by reference at one or more levels of indirection), and CAs could also describe themselves at their URI. Those last two paragraphs are just hints of some possibilities that could emerge from moving away from DNs that I can think of. Others members of this group will certainly find other possibilities. In any case it seems that the time for DNs is passed, and that one should perhaps move away from reliance on those and generalise this part of TLS. Henry [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01 [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview [3] https://www.w3.org/2005/Incubator/webid/spec/tls/ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_BLUPR03MB1396523ABE524DE9528EAB318C8A0BLUPR03MB1396namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Henry,

 

Extension_data field can be zero-leng= th:

opaque ext= ension_data<0..2^16-1>;

 

The TLS 1.3 draft specifies matching = rules for two extensions: KU and EKU and then says:

“Separate specifications may define matching rules for other certificate extensions.”

 

Which means that you should be able t= o specify matching rules e.g. for SAN or IAN where zero-length extension_da= ta is interpreted as a wildcard. Getting TLS/PKI implementations to implement this new specification is a different matter,= of course.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.o= rg] On Behalf Of Henry Story
Sent: Wednesday, March 16, 2016 5:01 AM
To: Eric Rescorla <ekr@rtfm.com>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?<= /o:p>

 

 

On 8 Mar 2016, at 09:30, Eric Rescorla <ekr@rtfm.com> wrote:

 

CertificateRequest already allows you to pass an arb= itrary number of

extensions by OID.

 

 

What more do you think you need?

 

Perhaps what would be needed in addition would be wi= ldcard support.

 

Eg, it would be useful to say: Give me certificates = that contain an extension without

specifying the value of the extension. Eg: give me a= certificate that contains a 

SAN or IAN, I don't care what value of those are.

 

Is that allowed? I don't see anything regarding it w= hen reading that section. But

I may be missing something.



 

-Ekr

 

 

On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <henry.story@bblfi= sh.net> wrote:

Hi,


  I was reading with interest M. Thomson and M. Bishop's
"Reactive Certificate-Based Client Authentication" draft RFC [1].=
In the section 2.3 "The CERTIFICATE_REQUEST Frame"

[[
      CA-Count and Certificate-Authorities:  "Cert= ificate-Authorities" is a
      series of distinguished names of acceptable certificat= e
      authorities, represented in DER-encoded [X690] format.=   These
      distinguished names may specify a desired distinguishe= d name for a
      root CA or for a subordinate CA; thus, this message ca= n be used to
      describe known roots as well as a desired authorizatio= n space.
      The number of such structures is given by the 16-bit &= quot;CA-Count"
      field, which MAY be zero.  If the "CA-Count&= quot; field is zero, then
      the client MAY send any certificate that meets the res= t of the
      selection criteria in the "CERTIFICATE_REQUEST&qu= ot;, unless there is
      some external arrangement to the contrary.
]]

Would it not be possible to extend that so that one could also pass
issuer Alternative Names, and not just DNs?

Using DNs made sense when it was thought that LDAP and X500 would
end up being the protocols for global directories. This turned out
not to be the case. It turned out that DNs were a special case of
what could be termed a URI (even though DNs are not in URI format).
And many (most?) URIs can refer to agents, least but not last
http(s) URLs (See the WebID spec [2] for a nice diagram of how this
works conceptually and the WebID-TLS spec for one way this can be tied
to TLS [3]).

If TLS1.3 could start moving away from sole reliance on DNs this
would open quite a lot of possibilities, including the ability to
build institutional Webs of trust for CAs (ie trust anchors could
list CAs by reference at one or more levels of indirection), and CAs
could also describe themselves at their URI.

Those last two paragraphs are just hints of some possibilities that
could emerge from moving away from DNs that I can think of. Others
members of this group will certainly find other possibilities.

In any case it seems that the time for DNs is passed, and that
one should perhaps move away from reliance on those and generalise
this part of TLS.

Henry



[1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01
[2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview
[3] https://www.w3.org/2005/Incubator/webid/spec/tls/

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

 

 

--_000_BLUPR03MB1396523ABE524DE9528EAB318C8A0BLUPR03MB1396namp_-- From nobody Wed Mar 16 11:14:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D92212D616 for ; Wed, 16 Mar 2016 11:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 7BX4zjKIwcyr for ; Wed, 16 Mar 2016 11:14:43 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0042.outbound.protection.outlook.com [104.47.2.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A08FA12DA4C for ; Wed, 16 Mar 2016 11:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1d/sdT6MtTCTNO1DSSBxmy3qXqdc7hjeiXIqL0nPWs4=; b=EcL5Hg4wtSqd3H5CWwnjKY43ds2+puaP2D9/aNHhfz634uVFwZEszUX11rRsIWXx+dkufwzOj5wE5MGyq7fcpPs6m4aDGTLiJ7XEZ0FeCwhi3dd9p6T6j4cELVpyisJU9zDT8h8s8PDhdfZKqlTpNnBZdcWDlSyevhPV1ztRwVU= Received: from DB5PR03MB1813.eurprd03.prod.outlook.com (10.166.171.146) by DB5PR03MB1816.eurprd03.prod.outlook.com (10.166.171.149) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:14:38 +0000 Received: from DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) by DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 18:14:38 +0000 From: "Paterson, Kenny" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "tls@ietf.org" Thread-Topic: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? Thread-Index: AQHRf6+zYJzUjAAwo0ueTshDRg0uoQ== Date: Wed, 16 Mar 2016 18:14:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: allcosts.net; dkim=none (message not signed) header.d=none;allcosts.net; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.3.218.210] x-ms-office365-filtering-correlation-id: fbb74fc8-d1e9-4220-3cad-08d34dc6d631 x-microsoft-exchange-diagnostics: 1; DB5PR03MB1816; 5:2Dpx9DYQCCJIS4Gqd2MAxx2se+x115A17pW7hJz21h8cYdj48tPuK/p5zzN5I/iFSkW8r12teg+SKOVjl9aQ3TbIj002LEdWNsGNlWAKtmixAYGvwNMNKmTKgKd9E6kg7c+Lxls3muJbb1HDbSh6aA==; 24:znbn3EKSO9XxKHfSPPPhi9/dAWmE/8c74clnuWZWZaSuhPwo4gR0RfRHI8w1wex4HlIEKhQwBBzotb74l2fANJNbdfbxipuJzFqFvboSroQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB1816; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR03MB1816; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB1816; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(92566002)(87936001)(86362001)(2420400007)(74482002)(122556002)(3846002)(6116002)(102836003)(19580405001)(19580395003)(83506001)(1096002)(1220700001)(54356999)(2906002)(76176999)(5004730100002)(11100500001)(10710500007)(50986999)(4001350100001)(66066001)(2900100001)(1720100001)(15975445007)(10400500002)(2501003)(106116001)(5008740100001)(81166005)(3280700002)(15650500001)(77096005)(586003)(107886002)(5001770100001)(5002640100001)(189998001)(3660700001)(36756003)(7110500001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB1816; H:DB5PR03MB1813.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <2D465DAF93D4724998A77D9E98EFDCFF@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:14:38.0223 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB1816 Archived-At: Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:14:53 -0000 SGkgQ29sbSwNCg0KT24gMTYvMDMvMjAxNiAxNDo1MiwgIlRMUyBvbiBiZWhhbGYgb2YgQ29sbSBN YWNDw6FydGhhaWdoIg0KPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjb2xtQGFs bGNvc3RzLm5ldD4gd3JvdGU6DQo+DQo+VGhpcyBoYXMgYmVlbiBidWdnaW5nIG1lIGZvciBhIGxv bmcgdGltZSBhbmQgSSd2ZSB0YWxrZWQgdG8gc29tZSBoZXJlDQo+YWJvdXQgaXQgaW4gcGVyc29u LCBidXQgdGhpcyByZXBvcnQ7DQo+DQo+aHR0cHM6Ly93d3cudGVhbXVwdHVybi5jb20vc3RhdGlj L3JlcG9ydHMvMjAxNi93aGF0LWlzcHMtY2FuLXNlZS9maWxlcy9VcHQNCj51cm4lMjAtJTIwV2hh dCUyMElTUHMlMjBDYW4lMjBTZWUlMjB2LjEuMC5wZGYNCj4NCj5wcm92b2tlcyBtZSB0byBicmlu ZyBpdCB1cC4gSGVyZSdzIHRoZSBjcnV4IG9mIGl0OyBpcyBpdCByZWFsbHkgYQ0KPnNlY3VyaXR5 IHdpbiB0byByZWNvbW1lbmQgdGhlIEFFQUQgY2lwaGVyIHN1aXRlcyBmb3IgVExTIDEuMiB1c2Vy cz8NCj4NCj4NCj5UaGUgQUVBRCBjaXBoZXIgc3VpdGVzIGFzLWltcGxlbWVudGVkIGFyZSBieXRl LWZvci1ieXRlIG1hcHBhYmxlIHRvDQo+cmVzcG9uc2Ugc2l6ZXMsIHdpdGggbm8gcGFkZGluZyBm b3IgYW55IGtpbmQgb2YgbGVuZ3RoIGhpZGluZy4gVGhpcyBtYWtlcw0KPnBhc3NpdmUgc2l6ZSBh bmFseXNpcyBhdHRhY2tzIHF1aXRlIGEgbG90IGVhc2llciB0aGFuIHRoZXkgY291bGQgYmUgKGEN Cj5xdWljayBzYW1wbGUgb2Ygd2lraXBlZGlhIHBhZ2Ugc2l6ZXMgc3VnZ2VzdHMNCj4gdGhhdCBl dmVuIDE2IGJ5dGUgYmxvY2tzIHJhaXNlIHRoZSBkaWZmaWN1bHR5IGJ5IG9yZGVycyBvZiBtYWdu aXR1ZGUpLg0KPlRoZSBzZWFyY2ggaGludHMgYXR0YWNrIG91dGxpbmUgaW4gdGhlIHBhcGVyIG1h eSBub3QgZXZlbiB3b3JrIHdpdGgNCj4xNi1ieXRlIHBhZGRpbmcuIEkgd2FudCB0byBlbXBoYXNp emUgdGhhdCB0aGUgYXR0YWNrIGhlcmUgaXMgcGFzc2l2ZSwNCj51bmRldGVjdGFibGUgdG8gc2Vy dmVycyBvciBjbGllbnRzLCBhbmQgcmVhbGlzdGljDQo+IC0gaXQncyBsaWtlbHkgaGFwcGVuaW5n IHRvZGF5Lg0KPg0KPk9uIHRoZSBvdGhlciBzaWRlIG9mIHRoZSB0cmFkZS1vZmYgaXMgdGhhdCB0 aGUgQUVBRCBtb2RlIGNpcGhlcnMgYXJlIG5vdA0KPnN1c2NlcHRpYmxlIHRvIG1hYy10aGVuLWVu Y3J5cHQgaXNzdWVzLCBzdWNoIGFzIEx1Y2t5MTMuIFNvbWUgdGltZSBhZ28gSQ0KPndyb3RlIHVw IHNvbWUgZGV0YWlsIG9uIHRoZSBMdWNreTEzIGF0dGFjazoNCj5odHRwczovL2Jsb2dzLmF3cy5h bWF6b24uY29tL3NlY3VyaXR5L3Bvc3QvVHhMWlA2SE5BWVdCUTYvczJuLWFuZC1MdWNreS0xMw0K PiAsIGFuZCBteSB0YWtlIGhlcmUgaXMgdGhhdCB0aGUgc2NlbmFyaW8gaXMgc28gdW5yZWFsaXN0 aWMgdGhhdCB0aGUNCj5hdHRhY2sgaXMgc2ltcGx5IGltcHJhY3RpY2FsIGFnYWluc3QgVExTIC0g ZXZlbiB1bm1pdGlnYXRlZC4gSW4gYW55DQo+ZXZlbnQsIFRMUyBDQkMgaW1wbGVtZW50YXRpb25z IGhhdmUgYmVlbiBtaXRpZ2F0ZWQgYW5kIHBhdGNoZWQuIEhlcmUgSQ0KPmFsc28gd2FudCB0byBl bXBoYXNpemUgdGhhdCB0aGUgYXR0YWNrIGlzIGFjdGl2ZSAtDQo+IGl0IGdlbmVyYXRlcyBsb3Rz IG9mIG5vaXN5IHNpZ25hbHMgLSBhbmQgbWF5IG5ldmVyIGhhdmUgaGFwcGVuZWQuDQoNCldlbGws IHlvdSBrbm93IGFscmVhZHkgdGhhdCB3ZSBkaXNhZ3JlZSBvbiB0aGlzIDotKQ0KDQpGb3IgZXZl cnlvbmUgZWxzZSdzIGJlbmVmaXQsIGxldCBtZSBzYXkgdGhlIGZvbGxvd2luZzoNCg0KLSBBdHRh Y2tzIG9ubHkgZXZlciBnZXQgYmV0dGVyLg0KDQotIFRoZSBMdWNreSAxMyB0aW1pbmcgc2lnbmFs IGNhbiBiZSBhbXBsaWZpZWQgZm9yIERUTFMgdXNpbmcgcGFja2V0IHRyYWlucw0KKHNlZSB0aGlz IE5EU1MgMjAxMiBwYXBlciBmb3IgdGhlIHRlY2huaXF1ZXM6DQpodHRwOi8vd3d3LmludGVybmV0 c29jaWV0eS5vcmcvcGxhaW4tdGV4dC1yZWNvdmVyeS1hdHRhY2tzLWFnYWluc3QtZGF0YWdyYW0N Ci10bHMpLg0KDQotIEFzIHlvdXIgYmxvZyBuaWNlbHkgZXhwbGFpbnMsIEFXUydzIHMybiBpbXBs ZW1lbnRhdGlvbiBjaG9zZSB0byBtaXRpZ2F0ZQ0KTHVja3kgMTMgdXNpbmcgYSBiZXNwb2tlIHNv bHV0aW9uLiBUaGlzIGNvZGUgd2FzIGZvdW5kIHRvIGJlIHZ1bG5lcmFibGUgdG8NCmF0dGFjayBz aG9ydGx5IGFmdGVyIHRoZSBjb2RlIHdhcyByZWxlYXNlZA0KKGh0dHBzOi8vZXByaW50LmlhY3Iu b3JnLzIwMTUvMTEyOSkuIFRoZSBpbml0aWFsIHBhdGNoIHRvIHRoZSBjb2RlIHdhcw0KYWxzbyBp bnNlY3VyZSAoaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNS8xMjQxKS4gUmVhZGVycyBjYW4g ZHJhdyB0aGVpcg0Kb3duIGNvbmNsdXNpb25zIGZyb20gdGhpcy4gTWluZSBpcyB0aGF0IGV2ZW4g Z2lmdGVkIHByb2dyYW1tZXJzIGdldCBUTFMncw0KTXRFIGNvbnN0cnVjdGlvbiB3cm9uZy4NCg0K SSBmZWVsIHN0cm9uZ2x5IHRoYXQgZ29pbmcgYmFjayB0byBNdEUgd291bGQgYmUgYSByZXRyb2dy YWRlIHN0ZXAuDQoNCk11Y2ggYmV0dGVyIHdvdWxkIGJlIGltcGxlbWVudGluZyBhbiBvcHRpb25h bCBwYWRkaW5nIGZlYXR1cmUgZm9yIHRoZSBBRUFEDQptb2Rlcy4gU29tZXRoaW5nIGxpa2UgdGhp cyBkcmFmdCBwcm9wb3NlczoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXBp cm9udGktdGxzLWxlbmd0aC1oaWRpbmctMDINCg0KDQpDaGVlcnMNCg0KS2VubnkgDQoNCj4gDQo+ DQo+DQo+SXMgaXQgd2lzZSB0byBtYWtlIHRoZSByZWFsLXdvcmxkIGF0dGFjayBjb3N0IGxlc3Ms IHRvIG1pdGlnYXRlIHRoZQ0KPnRoZW9yZXRpY2FsIG9uZT8gSSBhbHNvIHRoaW5rIEFFQUQgbW9k ZSBpcyBhd2Vzb21lOiBpdCdzIGhvdyBjcnlwdG8NCj5zaG91bGQgYmUgdXNlZCwgYW5kIHdhbnQg dG8gZ2l2ZSBpdCBhIHN0cm9uZyBlbmRvcnNlbWVudCwgYnV0IG5vdCBhdCB0aGUNCj5jb3N0IG9m IG1ha2luZyBvbi10aGUtd2lyZSBkYXRhIG1lYW5pbmdmdWxseQ0KPiBsZXNzIHNlY3VyZS4gDQo+ DQo+DQo+QXQgYSBtaW5pbXVtOiBjb3VsZCB3ZSBhZ3JlZSB0aGF0IGlmIGEgc2VydmljZS9zaXRl IGlzIHNlbnNpdGl2ZSB0bw0KPnByaXZhY3kgLSBpdCdzIHJlYXNvbmFibGUgZm9yIHRoZW0gdG8g cHJlZmVyIEFFUy1DQkM7IHNob3VsZCB0aGV5IGJlDQo+cGVuYWxpemVkIGluIFNTTCBoZWFsdGgg YW5hbHlzaXMgdG9vbHMvcmVwb3J0cyBmb3IgdGhhdCBjb25maWd1cmF0aW9uPw0KPml0J3Mgbm90 IGFzIGZsZXhpYmxlIG9yIHVzZWZ1bCBhcyB0aGUgcGFkZGluZw0KPiBpbiBUTFMxLjMsIGJ1dCBp dCdzIHdoYXQgd2UgaGF2ZS4NCj4NCj4NCj4tLSANCj5Db2xtDQo+DQoNCg== From nobody Wed Mar 16 11:22:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281E812DA6F for ; Wed, 16 Mar 2016 11:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 X4w6fMMxwbxP for ; Wed, 16 Mar 2016 11:22:41 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0055.outbound.protection.outlook.com [104.47.0.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 837D812D748 for ; Wed, 16 Mar 2016 11:22:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LXIufl+rlFpUOCG3lYOnDgHqY842xskgabzh8eJr4ms=; b=C9TwKHsrOFT8MA0M6BL/xV+XLvFsP82oNoNqWm8DMh+rigspnwnE/m+ztgIEIWi33htnIt3jXEpzEp+rF3a4/6reduZnvPIFss8ZtIlb+GW/J4upCk+VcV0LghkKXnKiuCiN9J3T8phN2CO/7s/Zs+1jDh9gKSua1vVtwmodAHQ= Received: from DB5PR03MB1813.eurprd03.prod.outlook.com (10.166.171.146) by DB5PR03MB1815.eurprd03.prod.outlook.com (10.166.171.148) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 18:22:37 +0000 Received: from DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) by DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 18:22:37 +0000 From: "Paterson, Kenny" To: Watson Ladd , Peter Gutmann Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egAFHsAAAAb9CQA= Date: Wed, 16 Mar 2016 18:22:37 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.3.218.210] x-ms-office365-filtering-correlation-id: 0b0b4331-fc9d-42a6-f1e3-08d34dc7f429 x-microsoft-exchange-diagnostics: 1; DB5PR03MB1815; 5:WvhAQeuop417IT4kxMlvKKyznWiyBi7zfwew0eyQe54ECyGu2WySZW0Hv9fljY6vYzUUNqzCofs5Ngb+BR2IyGTJk36aK1UyFkZGD1Urs2gyHudSW4obvGa1NQ61jP5XTKE/0MvC3L8axSfEpY0kTw==; 24:O7b/oeoWqN3iJuGL3CJEFj2Kc2A52Xz7yyUok8gevaFOsEt6tBZqF2rSTyvgdQcPbVcV/usT2up+9p1HqwWhzGoO63ojpbB1985P6YcG5so= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB1815; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR03MB1815; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB1815; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174004)(24454002)(4001350100001)(54356999)(5001770100001)(19580405001)(19580395003)(92566002)(74482002)(5004730100002)(87936001)(83506001)(4326007)(3280700002)(1220700001)(1096002)(2906002)(86362001)(586003)(66066001)(6116002)(76176999)(102836003)(3660700001)(36756003)(15975445007)(77096005)(81166005)(5002640100001)(11100500001)(2950100001)(2900100001)(5008740100001)(189998001)(50986999)(10400500002)(122556002)(1720100001)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB1815; H:DB5PR03MB1813.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <45BAB328C17B1F4190EF83CC00216236@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 18:22:37.9123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB1815 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:22:43 -0000 SGkNCg0KT24gMTYvMDMvMjAxNiAxNTowMiwgIlRMUyBvbiBiZWhhbGYgb2YgV2F0c29uIExhZGQi IDx0bHMtYm91bmNlc0BpZXRmLm9yZw0Kb24gYmVoYWxmIG9mIHdhdHNvbmJsYWRkQGdtYWlsLmNv bT4gd3JvdGU6DQoNCj5PbiBXZWQsIE1hciAxNiwgMjAxNiBhdCA1OjM2IEFNLCBQZXRlciBHdXRt YW5uDQo+PHBndXQwMDFAY3MuYXVja2xhbmQuYWMubno+IHdyb3RlOg0KPj4gQWZ0ZXIgYSBudW1i ZXIgb2YsIHVoLCBnZW50bGUgcmVtaW5kZXJzIGZyb20gcGVvcGxlIHdobyBoYXZlIGJlZW4NCj4+ d2FpdGluZyBmb3INCj4+IHRoaXMsIEkndmUgZmluYWxseSBnb3QgYXJvdW5kIHRvIHBvc3Rpbmcg dGhlIFRMUy1MVFMgZHJhZnQgSSBtZW50aW9uZWQNCj4+YSB3aGlsZQ0KPj4gYmFjay4gIEl0J3Mg bm93IGF2YWlsYWJsZSBhczoNCj4+DQo+PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWd1 dG1hbm4tdGxzLWx0cy0wMC50eHQNCj4+DQo+PiBBYnN0cmFjdDoNCj4+DQo+PiAgICBUaGlzIGRv Y3VtZW50IHNwZWNpZmllcyBhIHByb2ZpbGUgb2YgVExTIDEuMiBmb3IgbG9uZy10ZXJtIHN1cHBv cnQsDQo+PiAgICBvbmUgdGhhdCByZXByZXNlbnRzIHdoYXQncyBhbHJlYWR5IGRlcGxveWVkIGZv ciBUTFMgMS4yIGJ1dCB3aXRoIHRoZQ0KPj4gICAgc2VjdXJpdHkgaG9sZXMgYW5kIGJ1Z3MgZml4 ZWQuICBUaGlzIHJlcHJlc2VudHMgYSBzdGFibGUsIGtub3duLWdvb2QNCj4+ICAgIHByb2ZpbGUg dGhhdCBjYW4gYmUgZGVwbG95ZWQgbm93IHRvIHN5c3RlbXMgdGhhdCBjYW4ndCBjYW4ndCByb2xs IG91dA0KPj4gICAgcGF0Y2hlcyBldmVyeSBtb250aCBvciB0d28gd2hlbiB0aGUgbmV4dCBhdHRh Y2sgb24gVExTIGlzIHB1Ymxpc2hlZC4NCj4+DQo+PiBTZXZlcmFsIHBlb3BsZSBoYXZlIGFscmVh ZHkgY29tbWVudGVkIG9uIGl0IG9mZi1saXN0IHdoaWxlIGl0IHdhcyBiZWluZw0KPj4gd3JpdHRl biwgaXQncyBub3cgb3BlbiBmb3IgZ2VuZXJhbCBjb21tZW50cy4uLg0KPg0KPlNldmVyYWwgY29t bWVudHM6DQoNCjxzbmlwPg0KDQo+VGhlIGFuYWx5c2lzIG9mIFRMUyAxLjMgaXMganVzdCB3cm9u Zy4gVExTIDEuMyBoYXMgYmVlbiBmYXIgbW9yZQ0KPmV4dGVuc2l2ZWx5IGFuYWx5emVkIHRoZW4g VExTIDEuMi4gSXQncyBhbG1vc3QgbGlrZSB5b3UgZG9uJ3QgYmVsaWV2ZQ0KPmNyeXB0b2dyYXBo eSBleGlzdHM6IHRoYXQgaXMgYSBib2R5IG9mIGtub3dsZWRnZSB0aGF0IGNhbiBkZW1vbnN0cmF0 ZQ0KPnRoYXQgcHJvdG9jb2xzIGFyZSBzZWN1cmUsIGFuZCB3aGljaCBoYXMgYmVlbiBhcHBsaWVk IHRvIHRoZSBkcmFmdC4NCg0KVGhpcyBpcyBwYXRlbnRseSB1bnRydWUuIFRoZXJlIGlzIGEgdmFz dCBib2R5IG9mIHJlc2VhcmNoIGFuYWx5c2luZyBUTFMNCjEuMiBhbmQgZWFybGllci4gQSBnb29k IHN1cnZleSBhcnRpY2xlIGlzIGhlcmU6DQoNCmh0dHBzOi8vZXByaW50LmlhY3Iub3JnLzIwMTMv MDQ5DQoNCg0KKGJ1dCBldmVuIHRoaXMgaXMgcXVpdGUgb3V0IG9mIGRhdGUgaW4gc2V2ZXJhbCBy ZXNwZWN0cykuIFRoZSBsaXRlcmF0dXJlDQpmb3IgVExTIDEuMyBpcyBncm93aW5nLCBidXQgaXMg YW4gb3JkZXIgb2YgbWFnbml0dWRlIHNtYWxsZXIgaW4gc2l6ZS4gSXQNCmlzIHByZXR0eSBtdWNo IHJlcHJlc2VudGVkIGluIGl0cyBlbnRpcmV0eSBieSB0aGUgbGlzdCBvZiBwcmVzZW50YXRpb25z IGF0DQp0aGUgcmVjZW50IFRST04gd29ya3Nob3A6DQoNCmh0dHA6Ly93d3cuaW50ZXJuZXRzb2Np ZXR5Lm9yZy9ldmVudHMvbmRzcy1zeW1wb3NpdW0tMjAxNi90bHMtMTMtcmVhZHktb3Itbg0Kb3Qt dHJvbi13b3Jrc2hvcC1wcm9ncmFtbWUNCg0KDQpBcyBmYXIgYXMgSSBrbm93LCB0aGUgb25seSBj b21wbGV0ZSBhbmFseXNpcyBzbyBmYXIgaXMgdGhpcyBvbmU6DQoNCmh0dHA6Ly90bHMxM3RhbWFy aW4uZ2l0aHViLmlvL1RMUzEzVGFtYXJpbi8NCg0KDQooZnVsbCBkaXNjbG9zdXJlOiB0d28gb2Yg bXkgUGhEIHN0dWRlbnRzIGFyZSBpbnZvbHZlZCkuIEhvd2V2ZXIsIGV2ZW4NCnRoZXJlLCB0aGUg YW5hbHlzaXMgaXMgc3ltYm9saWMgYW5kIGRvZXMgbm90IGluY2x1ZGUgMC1SVFQgKElJUkMpLg0K DQpNYXliZSB5b3UnZCBjYXJlIHRvIHJldmlzZSB5b3VyIGJvbGQgc3RhdGVtZW50IGFib3ZlPw0K DQpDaGVlcnMNCg0KS2VubnkgDQoNCg== From nobody Wed Mar 16 11:30:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE9D412DA78 for ; Wed, 16 Mar 2016 11:30:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 6D7uW7CZfave for ; Wed, 16 Mar 2016 11:30:04 -0700 (PDT) Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::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 9901612DA08 for ; Wed, 16 Mar 2016 11:30:04 -0700 (PDT) Received: by mail-qg0-x231.google.com with SMTP id w104so50815080qge.1 for ; Wed, 16 Mar 2016 11:30:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=IZCPiWJ8N9auZKxFI7Qiih3Lo3ULMeNxBsEV6sTLE7k=; b=qnUv2KvUOSU6Sro/1+AFAQECUBuuXaS+x/5RNcI9EB7TnG5vcexcV2JB5RLTYrnjSF ek7Sy4k6wFd6tNG+VacmhkOe3BPO/JFCqzvujomdRauAGFQZ8s9HpnX/E4SU4rdKYrT7 fr40aA8rlMLoC0z7WS2qZAHeNkppTs5qASVZyuE6vC2Vbq0zsCHVR3dvhHv/9QpQfjBB WfUljkdKotty9+Rg3VxAtkO4g6wAnV7w8u13acDclrB2K6xywLrwTJcp0cMP1ipmTazf vMFXtItdSGI63zOaiWdD6Is8cbGCfcc5CPo5xoUkRKyzSIVMQG76q0KVSCentA4KQaxS Yajw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IZCPiWJ8N9auZKxFI7Qiih3Lo3ULMeNxBsEV6sTLE7k=; b=Gu1RBhcy95jvPfGeigHKLBWE9BmeahUJWcTcxEeDgMGn7pQZQBV/lPaPe6TAV/uURT kDilJunZ3X/Lg+yZ5B1KMHq/nReww8nvTLqy6J7mmo0cRMNtythhyjfVf/+VDRV0XRhX Ch7HFUAa74zwW9qJj1lCYadt0CaeIqtLFPYHKlzX856J39DPS7BiGgu3jKvmI5gpMyX1 AjGDMaGLIvyBAuvH+D4+8USvaF/khXJFaWA+ATSPf65OFvnk1zbNWqiBv1IXBGxcBaSd J9H2H/h7ZkKTsMRHPvspAye9YjEyP83rVXJCBDd9qpcymUNIKiGqjipA5s5FBcJV31DT Rilw== X-Gm-Message-State: AD7BkJL6IrS3UQ7uTjbuAuHmOLTnN+UgWCKNYye5yJBJqros43IAbRkfIX1yyBvQFMFPRXx2ZgGx7Hk7W2Knaw== MIME-Version: 1.0 X-Received: by 10.140.196.85 with SMTP id r82mr7892087qha.60.1458153003643; Wed, 16 Mar 2016 11:30:03 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.140.93.50 with HTTP; Wed, 16 Mar 2016 11:30:03 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 18:30:03 +0000 X-Google-Sender-Auth: OT3aMyOedaoK2FFUb_tYiAe9cJU Message-ID: From: Adam Langley To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:30:07 -0000 On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny wrote: >>provokes me to bring it up. Here's the crux of it; is it really a >>security win to recommend the AEAD cipher suites for TLS 1.2 users? I'm skeptical about the benefit of padding to 16 bytes. While it does increase the size classes in your Wikipedia example, Wikipedia pages trigger subresource loads, which also have a size and page-to-page navigation leaks more information. My takeaway from reading traffic-analysis papers over the years is that countermeasures are surprisingly difficult. On the other hand, the CBC cipher suites are fundamentally broken, rather slow and, in an attempt to fix them, are now very complex. So I don't believe that the benefits of padding to 16 bytes comes close to justifying the use of the CBC modes. Over the coming years I hope that CBC modes are killed off in the same fashion that RC4 now has been in several browsers. Padding at the application-level (e.g. HTTP) is probably the easiest, reasonable place to add padding (if there's a scheme with solid justification). Sure, one doesn't get "automatic" padding that using CBC modes might (somewhat) get you, but I still don't think CBC is a good tradeoff. Cheers AGL From nobody Wed Mar 16 11:32:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5212DA70 for ; Wed, 16 Mar 2016 11:32:38 -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=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 ebsh91thpxSm for ; Wed, 16 Mar 2016 11:32:36 -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 BD98112DA08 for ; Wed, 16 Mar 2016 11:32:35 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id g3so72655160ywa.3 for ; Wed, 16 Mar 2016 11:32:35 -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:date:message-id:subject:from:to :cc; bh=4uYGbZjFJkERYu+5rWSXYkte2Q36+WJZGJ4oANDYkpU=; b=Wjue0ZpVGUdpvS2/COWAwR65rTfxjvilLaGzvmKkoa1ig1dFud7eBOoZPP/XZ4uku3 klXzMn+Hj6uApkvWWAUIoHb9DeMfe7sFh/0M3oSCNh+IBB35n6P6nUsPYx/VTNM2OCdf wJ6zcvxADOF8qRXmN9tyjaAKGQbE+bNFU0BTsgYL9mE509bGxBNX7R+Y4+t27FbCPC3q pKBVxJiymHM7xaz4H0BKlZPX2ax+qo71cuOIZ3puxgucILGcNVxWil/TSBGXo+XR2Aa6 Pzed04aTcjndbHyU6IAgC8I9frY8xk5lUEYjpKqeKP4fpy9qMPBcCxX+WvPVxfrwUl1u xg1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4uYGbZjFJkERYu+5rWSXYkte2Q36+WJZGJ4oANDYkpU=; b=d8k7OBEjEwIWah67uTErZIH/WSziW9UWa02gaXbaTXTlqpN33C/zV9TRk2BYfEua9h YsV7as2QdKTDMXQMQvD6R29UQTWuODcWuRH+I4Mp5JbKFqvte+IG9g50n6ipZBU1UO6O XnXdtrbjczAvdjWPL0/9+hmp5uX0qLwaqkiXnCOTZ8O/9vEi/fP1+Wh2IaIk4/YHbeVc HkFqqO7yTNmIdVof0pv3bzb376f2gx6bccIZPAJ19S/faY8qqSalVT90sUitbdmY5CMm Dn5l0oYDA+C4UYZzV5WUYIysaBILNyXvz0kpXm3NrvktCkZmT0zvSVhewObKrMro6saE LFXQ== X-Gm-Message-State: AD7BkJIzRMwG6zhbIaJc1jKJgaex8BTNZYHAH7tL+Iowgn3IstFi3L0vVrl5fToGoryJmBzeWn1wfxPswpvmmw== MIME-Version: 1.0 X-Received: by 10.13.252.197 with SMTP id m188mr2752547ywf.281.1458153154849; Wed, 16 Mar 2016 11:32:34 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 11:32:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 14:32:34 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=94eb2c06c240d31d71052e2ebc6d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:32:38 -0000 --94eb2c06c240d31d71052e2ebc6d Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny wrote: > > Well, you know already that we disagree on this :-) > > For everyone else's benefit, let me say the following: > > - Attacks only ever get better. > This applies to the passive size side-channel ones too though; and we're seeing credible evidence that they're already happening today. I think anything we can do here to raise costs for the attackers is worthwhile. > > - The Lucky 13 timing signal can be amplified for DTLS using packet trains > (see this NDSS 2012 paper for the techniques: > http://www.internetsociety.org/plain-text-recovery-attacks-against-datagram > -tls). > That's true, but I don't think it's all that relevant to the security of TLS as used. In general DTLS has been more vulnerable to all sorts of active protocol level attacks because of the weaker guarantees it can provide. - As your blog nicely explains, AWS's s2n implementation chose to mitigate > Lucky 13 using a bespoke solution. This code was found to be vulnerable to > attack shortly after the code was released > (https://eprint.iacr.org/2015/1129). The initial patch to the code was > also insecure (https://eprint.iacr.org/2015/1241). Readers can draw their > own conclusions from this. Mine is that even gifted programmers get TLS's > MtE construction wrong. > Well as the blog also explains, at no time was s2n succeptible to a Lucky13 vulnerability. In fact; as-it-was s2n did considerably better than alternatives widely used in production. And that's my point here; we may be over-indexing on the issue itself. Programmers certainly get things wrong - though in this case the decision to use the hmac() construction as it is specified (so that it can be formally verified against the specification) was intentional. But I take the point that AEAD modes are harder for programmers to screw up; and that does have value. But my experience is that folks are pretty good about keeping software up-to-date with patches and so on, and less good about keeping configuration settings and protocol choices safe. As we broaden the use of AEAD, more traffic becomes more susceptible to the very real-world attacks above, and it's a "stickier" problem that will stay in place. I feel strongly that going back to MtE would be a retrograde step. > I don't like MtE one bit, but I also don't like zero length hiding one bit. So it's a complicated nuanced trade-off. -- Colm --94eb2c06c240d31d71052e2ebc6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <= Kenny.Paters= on@rhul.ac.uk> wrote:
Well, yo= u know already that we disagree on this :-)

For everyone else's benefit, let me say the following:

- Attacks only ever get better.

This ap= plies to the passive size side-channel ones too though; and we're seein= g credible evidence that they're already happening today. I think anyth= ing we can do here to raise costs for the attackers is worthwhile.=C2=A0
=C2=A0

- The Lucky 13 timing signal can be amplified for DTLS using packet trains<= br> (see this NDSS 2012 paper for the techniques:
http://www.internetsociety.org/p= lain-text-recovery-attacks-against-datagram
-tls).

That's true, but I don&#= 39;t think it's all that relevant to the security of TLS as used. In ge= neral DTLS has been more vulnerable to all sorts of active protocol level a= ttacks because of the weaker guarantees it can provide.=C2=A0
- As your blog nicely explains, AWS's s2n implementation chose to mitig= ate
Lucky 13 using a bespoke solution. This code was found to be vulnerable to<= br> attack shortly after the code was released
(https://eprint.iacr.org/2015/1129). The initial patch to the c= ode was
also insecure (https://eprint.iacr.org/2015/1241). Readers can = draw their
own conclusions from this. Mine is that even gifted programmers get TLS'= ;s
MtE construction wrong.

Well as the blo= g also explains, at no time was s2n succeptible to a Lucky13 vulnerability.= In fact; as-it-was s2n did considerably better than alternatives widely us= ed in production. And that's my point here; we may be over-indexing on = the issue itself. Programmers certainly get things wrong - though in this c= ase the decision to use the hmac() construction as it is specified (so that= it can be formally verified against the specification) was intentional.=C2= =A0

But I take the point that AEAD modes are harde= r for programmers to screw up; and that does have value. But my experience = is that folks are pretty good about keeping software up-to-date with patche= s and so on, and less good about keeping configuration settings and protoco= l choices safe. As we broaden the use of AEAD, more traffic becomes more su= sceptible to the very real-world attacks above, and it's a "sticki= er" problem that will stay in place.=C2=A0

I feel strongly that going back to MtE would be a retrograde step.

I don't like MtE one bit, but I also don= 9;t like zero length hiding one bit. So it's a complicated nuanced trad= e-off.=C2=A0

--
Colm
--94eb2c06c240d31d71052e2ebc6d-- From nobody Wed Mar 16 11:43:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D69712DA8B for ; Wed, 16 Mar 2016 11:43:00 -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=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 GW5MkMD_YAdZ for ; Wed, 16 Mar 2016 11:42:58 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B9312DA8A for ; Wed, 16 Mar 2016 11:42:58 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id h129so72987283ywb.1 for ; Wed, 16 Mar 2016 11:42:58 -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:date:message-id:subject:from:to :cc; bh=tJ59OtOgedRDbkj/db0UqpoB2fymvQwXHZNhA3cWEi4=; b=Pg51P7vF9B4wkfICWSr/906SIP1HIIK+KqzEvKvgaJ3RBSEr0JhsfW56qqNwg3b5Ty TK/uTPPyIWcRfUKRbBgnDoExHIN+pn6bCxYa0wcqcPoV5VlEzgYfynOL+v9wVBQ8trdo 6i77gfhE0BQ73FezQBgJ9v0eX7FsMwgFutCpL+bZyhj49hlgA/ItrINGM3tHF2Hq32Ng tj81xiTIb/IVBk8uAM17sdGhcJVyV+TuI3WkN/EEocJ1+QfvCs+Mk0lbjZNRsIk7F2qs oR9qL9AhTZO3KSg9dImmZSX4SNM0YtVxnAUb+oZ2bhd0iODUn2HQZNfMNchIw//lZI5d aAQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tJ59OtOgedRDbkj/db0UqpoB2fymvQwXHZNhA3cWEi4=; b=BDcBZrOrmB9PQ/BgQZQe9Be91K/qVxustOSScOPvX1cRnw2+oTlYIjK9AiT718qS8t yKovwAPo2Xf2v4XzzqPrIQrFqXnWNs/K2hJcTsMqd3GkYyYsZKCkMDAUZJZbdHEeM8EE 492fpCPBR5vwDoy8fDmrKZtjYBYXLCmpRjU0S774RsDvqqaXU0iTFX6TyNZJxcieV/mm IuZXUZiUKS64hFf5wqnZvgGCooh4//I8juFlQgXnE9wukLozBozmytC0Lv30SI3LTYIX LrVSTHblrBBGfG7/ZLH/7Fm6cjy+vXmMStetVdS5rF7HdzNP03ilCBLvF9Wdtfspn10k +02A== X-Gm-Message-State: AD7BkJKsPdEWPSOxYWfXqu+1q0lpCnSqiF7dD0cbJSA6f+D+jrK6g3KXfBYqX0chgf6qdoxxBzkL5IxVY+pTRg== MIME-Version: 1.0 X-Received: by 10.13.212.202 with SMTP id w193mr2465863ywd.175.1458153777315; Wed, 16 Mar 2016 11:42:57 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 11:42:57 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 14:42:57 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Adam Langley Content-Type: multipart/alternative; boundary=001a114fa17cecf81a052e2ee178 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:43:00 -0000 --001a114fa17cecf81a052e2ee178 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 2:30 PM, Adam Langley wrote: > On Wed, Mar 16, 2016 at 6:14 PM, Paterson, Kenny > wrote: > >>provokes me to bring it up. Here's the crux of it; is it really a > >>security win to recommend the AEAD cipher suites for TLS 1.2 users? > > I'm skeptical about the benefit of padding to 16 bytes. While it does > increase the size classes in your Wikipedia example, Wikipedia pages > trigger subresource loads, which also have a size and page-to-page > navigation leaks more information. My takeaway from reading > traffic-analysis papers over the years is that countermeasures are > surprisingly difficult. > 16-bytes is small, I wish it were much bigger, but it may elevate things to where you even need to form a sub resource attack and increases the size of the graph/fingerprint that you need to maintain to form the sub-resource attack. I doubt it would thwart a large actor for very long, but it would help against smaller ones and I'm guessing that it might block some specific attacks like the autocompletion one mentioned in the paper. -- Colm --001a114fa17cecf81a052e2ee178 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 16, 2016 at 2:30 PM, Adam Langley <agl@i= mperialviolet.org> wrote:
On We= d, Mar 16, 2016 at 6:14 PM, Paterson, Kenny
<Kenny.Paterson@rhul.ac.uk<= /a>> wrote:
>>provokes me to bring it up. Here's the crux of it; is it really= a
>>security win to recommend the AEAD cipher suites for TLS 1.2 users?=

I'm skeptical about the benefit of padding to 16 bytes. While it= does
increase the size classes in your Wikipedia example, Wikipedia pages
trigger subresource loads, which also have a size and page-to-page
navigation leaks more information. My takeaway from reading
traffic-analysis papers over the years is that countermeasures are
surprisingly difficult.



--
Colm
--001a114fa17cecf81a052e2ee178-- From nobody Wed Mar 16 11:50:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D68B12DA94 for ; Wed, 16 Mar 2016 11:50: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=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 yATVCtngDS4a for ; Wed, 16 Mar 2016 11:50:05 -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 3A62F12D586 for ; Wed, 16 Mar 2016 11:49:48 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id m126so49223199ywd.0 for ; Wed, 16 Mar 2016 11:49:48 -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:date:message-id:subject:from:to :cc; bh=JUxmxlrGbNjB42bV8WAlmNHHt2Um4HBqMql1AreCMVk=; b=GZixXDfzKU7oFU1q9fdMJIHEyL2fIYifCnWbjOlDasWrcB0SHdtRnCwcJOTtQw37pD gF/PLmkfK3gC9xN8DhGe0omts7WevW2TOMnBIMyd2GAAUq87i2tU6zAOIuZ/WpXxWKtb u+1GH3FOawPhoiDa/n+cNB9xEkJx+A8uNTPIKz1Uo345g1W1RUhMHRFqoX3k3wtNWo2T GPH2OwzPjMTenzeFCp5hOcSltOaJkyyKGlrJGDeh3CbDFqdppNlL1IR3DoLK7t6e4G13 U7zB3ijYN8V3MqkYKW92csRzEkn5K5m3aT9VbXiF5T2A+4bA+35lrKDZ05TRx0Z7LgPj t1FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JUxmxlrGbNjB42bV8WAlmNHHt2Um4HBqMql1AreCMVk=; b=VUpSh3vQdRGg3/+8TMYw9QkV2TaouRz3K6LAHisoHiLeZYptY7A7pr37fMpQcequsc b7N1RgTr0LBOjx4UeLHvxTewY7BYHIvuCN+W9THoXdLA5UtW/U0iZjDDWhKHbjlQ/uNx BzOMTZEKS1Lki2JC2UzDOqZQuxgFTHmvwyjBeCaxS+Mr1jnyKJeAEI3XLqNB8g4IlDTW sAzvWnYb0BKjph92y0cS0LraFyz+jF/9ioiwY+TU2kPjoiZT1c/IjRkAdf9MM9+7IEdc J0OHxuVFtdBMYsCaVfefJIcWoYkP7R7c1G7aPIJtwTudsAurHrw+/nge7h+LNXUvWk2e k9cg== X-Gm-Message-State: AD7BkJJ4y1wCtd/BIsHFwM7asimudkRS+ExmUbjYUSAohxfmRuw00uf8MSs5093BBWtachIMKUpCyntURiJWTA== MIME-Version: 1.0 X-Received: by 10.37.56.142 with SMTP id f136mr2679304yba.103.1458154187437; Wed, 16 Mar 2016 11:49:47 -0700 (PDT) Received: by 10.129.32.196 with HTTP; Wed, 16 Mar 2016 11:49:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2016 14:49:47 -0400 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=94eb2c0915445f0c57052e2efa98 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:50:07 -0000 --94eb2c0915445f0c57052e2efa98 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny wrote: > Much better would be implementing an optional padding feature for the AEAD > modes. Something like this draft proposes: > > https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 I hadn't seen that! I wonder is there an appetite here for including more robust LH in TLS1.2 in some form? I mean a real one; as in - let's it get it into servers and browsers sooner than TLS1.3. -- Colm --94eb2c0915445f0c57052e2efa98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
Much better w= ould be implementing an optional padding feature for the AEAD
modes. Something like this draft proposes:

https://tools.ietf.org/html/draft-piro= nti-tls-length-hiding-02

I hadn't s= een that! I wonder is there an appetite here for including more robust LH i= n TLS1.2 in some form? I mean a real one; as in - let's it get it into = servers and browsers sooner than TLS1.3.=C2=A0

--=
Colm
--94eb2c0915445f0c57052e2efa98-- From nobody Wed Mar 16 11:54:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E312DA02 for ; Wed, 16 Mar 2016 11:53: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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypTon9oAi1QO for ; Wed, 16 Mar 2016 11:53:45 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 1154112D561 for ; Wed, 16 Mar 2016 11:44:03 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id e185so73496731vkb.1 for ; Wed, 16 Mar 2016 11:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=xxX+WOYz/P9n2wn8NwzM+h6GzsrCHDNBgw0Gk9OrDCY=; b=J85xL54qvKa5Hn9AW1lrfAcdm1NeBVM/lb+/kzAJF289lAioXqreCdx+b4q+XFLy0q giTDt7cj7P4kGoRy1nepkRSKyHw6k3f9bTBmTJaM2KOw5+wjPdBxUzkgigtDcXtdInuE OjfFr/Wm3vVZj9NqMZ0hmBVHprBmUoZKwbAhWRcKy9cEVwRXtgR2oP8VkfgbFvvsDXFX OGZyxb1lMsLGDh+dEKvKcSfcRK8Wmsk9EEpL6p5l/GM+FYHb+pR9+jhiYPFCM6qWTID/ q4gyT1cCbpw0ZuLFoFUm5iWqd4MyxKv8Z+vP5x6Ju9rqW4ikk6JmaUmbkSUIRuzlov27 3BEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xxX+WOYz/P9n2wn8NwzM+h6GzsrCHDNBgw0Gk9OrDCY=; b=LvcuHL8JTYyTHJJg9lqqiiJKoX/ai7k3hXn9Y7kxU93Pxzoce+tJ2r3+889NEmmoIu lZmzjo4jmDY/PBOW8wkoyA9J1YoOvr8nABVaksImUO4OW2PZPmYN32JXQhboKy5uFwLv BocUDmEEvBCuyZ/K+VDQEJoJEUwp9j/jiXAeqqCsAyfMRz4X99LwKXag6qNvu4NaESoB RLtjK1IMAarrziCnfkO+ens+4qD+QOQymTT1TC6tTYkJ/nMw8xyLJx1NtaB8WEdSb0JA xdbGPkzQpMLDyWtR6JpUkjJq9wErzkbngrqgHy26RE7X9IM4vd5wnSb4tzwNIwWNcbwr g2GA== X-Gm-Message-State: AD7BkJI4y3DeShD9OVuRsUUROiu7RxIyjQA6F9PJm2XdHRPL++AoTVqTeTzaANQkYM65UHSHHOJDc65ffujAXQ== MIME-Version: 1.0 X-Received: by 10.31.54.134 with SMTP id d128mr5997747vka.26.1458153842101; Wed, 16 Mar 2016 11:44:02 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Wed, 16 Mar 2016 11:44:02 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Wed, 16 Mar 2016 11:44:02 -0700 Message-ID: From: Watson Ladd To: "Paterson, Kenny" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:53:53 -0000 On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny wrote: > Hi > > On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" on behalf of watsonbladd@gmail.com> wrote: > >>On Wed, Mar 16, 2016 at 5:36 AM, Peter Gutmann >> wrote: >>> After a number of, uh, gentle reminders from people who have been >>>waiting for >>> this, I've finally got around to posting the TLS-LTS draft I mentioned >>>a while >>> back. It's now available as: >>> >>> http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt >>> >>> Abstract: >>> >>> This document specifies a profile of TLS 1.2 for long-term support, >>> one that represents what's already deployed for TLS 1.2 but with the >>> security holes and bugs fixed. This represents a stable, known-good >>> profile that can be deployed now to systems that can't can't roll out >>> patches every month or two when the next attack on TLS is published. >>> >>> Several people have already commented on it off-list while it was being >>> written, it's now open for general comments... >> >>Several comments: > > > >>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more >>extensively analyzed then TLS 1.2. It's almost like you don't believe >>cryptography exists: that is a body of knowledge that can demonstrate >>that protocols are secure, and which has been applied to the draft. > > This is patently untrue. There is a vast body of research analysing TLS > 1.2 and earlier. A good survey article is here: > > https://eprint.iacr.org/2013/049 There's a vast literature, but much of it makes simplifying assumptions or doesn't address the complete protocol. The first really complete analysis was miTLS AFAIK. Furthermore, a lot of the barriers to analysis in TLS 1.2 got removed in TLS 1.3. The question is not how many papers are written, but how much the papers can say about the protocol as implemented. And from that perspective TLS 1.3's Tamarin model is a fairly important step, where the equivalent steps in TLS 1.2 got reached only much later. It's true 0-RTT isn't included: so don't do it. But I think if we subset (not add additional implementation requirements) TLS 1.3 appropriately we end up with a long-term profile that's more useable than if we subset TLS 1.2, and definitely more than adding to the set of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely to have crypto weaknesses due to newness are vastly overstated. > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Mar 16 12:01:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0244612DAAF for ; Wed, 16 Mar 2016 12:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 1ya4o0tVtnT3 for ; Wed, 16 Mar 2016 12:01:45 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id DE99112DAB6 for ; Wed, 16 Mar 2016 12:01:29 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0338243341C; Wed, 16 Mar 2016 19:01:29 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E0E7B433405; Wed, 16 Mar 2016 19:01:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458154888; bh=xg0MK6pCHMus/zJmoQqzVkFD3eCWskLudXXTRI+I+Ko=; l=518; h=From:To:CC:Date:References:In-Reply-To:From; b=oDCKGjHHC/PLpZXd4RiG8ILYSwOQlX4PPBUijDCYt4gi0QVDlYsHs0REqB0nFQpuH J0M4qTO8sJgSDlaEOkqMOB7VBUU1nluwi3AKRLjjpuyPsYIUBpSCnGvwXgkeYF0XDF mQSyhHcc8VAe8pUz6bJbbhE0t3GGiSE1qJnU3s5k= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id DE7DF1FC94; Wed, 16 Mar 2016 19:01:28 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Wed, 16 Mar 2016 12:01:28 -0700 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.1130.005; Wed, 16 Mar 2016 15:01:28 -0400 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , "Paterson, Kenny" Thread-Topic: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? Thread-Index: AQHRf6+/YfKfm9H/YE2R6nAF6KGmqZ9crOiA//+/9yA= Date: Wed, 16 Mar 2016 19:01:27 +0000 Message-ID: <79499355185043e9806a46db886cd5ba@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.100] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:01:47 -0000 PiBJIGhhZG4ndCBzZWVuIHRoYXQhIEkgd29uZGVyIGlzIHRoZXJlIGFuIGFwcGV0aXRlIGhlcmUg Zm9yIGluY2x1ZGluZyBtb3JlIHJvYnVzdCBMSCBpbiBUTFMxLjIgaW4gc29tZSBmb3JtPyBJIG1l YW4gYSByZWFsIG9uZTsgYXMgaW4gLSBsZXQncyBpdCBnZXQgaXQgaW50byBzZXJ2ZXJzIGFuZCBi cm93c2VycyBzb29uZXIgdGhhbiBUTFMxLjMuwqANCg0KSDIgaGFzIHBhZGRpbmc7IHB1dCBpdCB0 aGVyZS4NCg0KVGhlcmUgaXMgcHJvYmFibHkgemVybyBpbnRlcmVzdCBpbiBhZGRpbmcgcGFkZGlu ZyB0byBUTFMgMS4yLCBlc3BlY2lhbGx5IHNpbmNlIHRoZSByZWNvcmQgdHlwZSBpcyBwbGFpbnRl eHQgYW5kIGNvdWxkIGVhc2lseSBiZSBieXBhc3NlZC4NCg== From nobody Wed Mar 16 12:27:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4337A12DADB for ; Wed, 16 Mar 2016 12:27:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 7ayJUKDiyBVY for ; Wed, 16 Mar 2016 12:27:24 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0697.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::697]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF07F12DAD1 for ; Wed, 16 Mar 2016 12:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gTiEGNz1VNPzxVLqqFIlnOSeUnpiJYwug5TjsxU8Muo=; b=o1yghhJhI90TnzK0VjG9zjN5mk7CFliRvJPKy19a6nOvYq29tF5cTWnA2EuW2jOjH9DpnSSQLZSnkZxoEsEJu6q8GmSwFNfh0/JRDHUdtSQiQ6WFe6U8s/TOBhsgH6UMJ6U4Dx7P0f19Z27Y07rF3QHIdMz9XG+xnObFebXPt18= Received: from DB5PR03MB1813.eurprd03.prod.outlook.com (10.166.171.146) by DB5PR03MB1816.eurprd03.prod.outlook.com (10.166.171.149) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 19:26:59 +0000 Received: from DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) by DB5PR03MB1813.eurprd03.prod.outlook.com ([10.166.171.146]) with mapi id 15.01.0434.019; Wed, 16 Mar 2016 19:26:59 +0000 From: "Paterson, Kenny" To: Watson Ladd Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egAFHsAAAAb9CQAAAL3XAAABgj0A Date: Wed, 16 Mar 2016 19:26:59 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [92.3.218.210] x-ms-office365-filtering-correlation-id: e81974de-fb27-4b89-6460-08d34dd0f1ac x-microsoft-exchange-diagnostics: 1; DB5PR03MB1816; 5:9ySmMMySbK+NaJ98NVDTBX0OuihfROVNgN7NwV+nSiBUHgGRRkBHEnkPQTDgz2ah/c7BJvT5MwH/736tCL9RhFM/O/GXmYwGM+qbHBmqN0Myx2tX58tvzufm4svJZfTls+lZAcT7cBqcbR/AQ+jXCQ==; 24:Y2oKSdcJLT379C4Of1Gnz5O8hNsV7dKQtdimnmhdk4ckW3/T8VPF0Nkr7YVKro3UxNz81yOEHTGDnrcuErsq2pUYnOANykEpUgBlMnfkO8c= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB5PR03MB1816; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DB5PR03MB1816; BCL:0; PCL:0; RULEID:; SRVR:DB5PR03MB1816; x-forefront-prvs: 08831F51DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(479174004)(24454002)(3280700002)(5008740100001)(81166005)(15975445007)(2900100001)(10400500002)(189998001)(5002640100001)(2950100001)(3660700001)(36756003)(110136002)(586003)(77096005)(74482002)(122556002)(86362001)(93886004)(19580395003)(19580405001)(102836003)(6116002)(3846002)(87936001)(92566002)(1411001)(50986999)(4001350100001)(11100500001)(4326007)(66066001)(1220700001)(54356999)(1096002)(83506001)(2906002)(5004730100002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR03MB1816; H:DB5PR03MB1813.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 19:26:59.1421 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR03MB1816 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:27:27 -0000 SGkNCg0KT24gMTYvMDMvMjAxNiAxODo0NCwgIldhdHNvbiBMYWRkIiA8d2F0c29uYmxhZGRAZ21h aWwuY29tPiB3cm90ZToNCg0KPk9uIFdlZCwgTWFyIDE2LCAyMDE2IGF0IDExOjIyIEFNLCBQYXRl cnNvbiwgS2VubnkNCj48S2VubnkuUGF0ZXJzb25Acmh1bC5hYy51az4gd3JvdGU6DQo+PiBIaQ0K Pj4NCj4+IE9uIDE2LzAzLzIwMTYgMTU6MDIsICJUTFMgb24gYmVoYWxmIG9mIFdhdHNvbiBMYWRk Ig0KPj48dGxzLWJvdW5jZXNAaWV0Zi5vcmcNCj4+IG9uIGJlaGFsZiBvZiB3YXRzb25ibGFkZEBn bWFpbC5jb20+IHdyb3RlOg0KPj4NCj4+IDxzbmlwPg0KPj4NCj4+PlRoZSBhbmFseXNpcyBvZiBU TFMgMS4zIGlzIGp1c3Qgd3JvbmcuIFRMUyAxLjMgaGFzIGJlZW4gZmFyIG1vcmUNCj4+PmV4dGVu c2l2ZWx5IGFuYWx5emVkIHRoZW4gVExTIDEuMi4gSXQncyBhbG1vc3QgbGlrZSB5b3UgZG9uJ3Qg YmVsaWV2ZQ0KPj4+Y3J5cHRvZ3JhcGh5IGV4aXN0czogdGhhdCBpcyBhIGJvZHkgb2Yga25vd2xl ZGdlIHRoYXQgY2FuIGRlbW9uc3RyYXRlDQo+Pj50aGF0IHByb3RvY29scyBhcmUgc2VjdXJlLCBh bmQgd2hpY2ggaGFzIGJlZW4gYXBwbGllZCB0byB0aGUgZHJhZnQuDQo+Pg0KPj4gVGhpcyBpcyBw YXRlbnRseSB1bnRydWUuIFRoZXJlIGlzIGEgdmFzdCBib2R5IG9mIHJlc2VhcmNoIGFuYWx5c2lu ZyBUTFMNCj4+IDEuMiBhbmQgZWFybGllci4gQSBnb29kIHN1cnZleSBhcnRpY2xlIGlzIGhlcmU6 DQo+Pg0KPj4gaHR0cHM6Ly9lcHJpbnQuaWFjci5vcmcvMjAxMy8wNDkNCj4NCj5UaGVyZSdzIGEg dmFzdCBsaXRlcmF0dXJlLCBidXQgbXVjaCBvZiBpdCBtYWtlcyBzaW1wbGlmeWluZw0KPmFzc3Vt cHRpb25zIG9yIGRvZXNuJ3QgYWRkcmVzcyB0aGUgY29tcGxldGUgcHJvdG9jb2wuDQoNCkNvcnJl Y3QsIGJ1dCB0aGF0IGRvZXMgbm90IG1ha2UgaXQgaXJyZWxldmFudCBvciB2YWx1ZWxlc3MuIE9y IGFyZSB5b3UNCmFjdHVhbGx5IHNheWluZyB0aGF0IGl0IGRvZXM/IFF1aXRlIGEgc3dlZXBpbmcg cHJlc3VtcHRpb247IHNlZQ0KaW1tZWRpYXRlbHkgYmVsb3cuDQoNCj5UaGUgZmlyc3QgcmVhbGx5 DQo+Y29tcGxldGUgYW5hbHlzaXMgd2FzIG1pVExTIEFGQUlLLg0KDQpZZXMsIGFuZCBldmVuIHRo ZXJlIHRoZSBhbmFseXNpcyB3YXMgZG9uZSBzdGVwIGJ5IHN0ZXAsIHNwcmVhZCBvdXQgb3ZlciBh DQpzZXJpZXMgb2YgcGFwZXJzIHdoaWNoIGdyYWR1YWxseSBidWlsdCB1cCB0aGUgY29tcGxleGl0 eSBvZiB0aGUgY29kZS1iYXNlDQpiZWluZyBoYW5kbGVkLiBBbmQsIGluIHBhcmFsbGVsLCB2YXJp b3VzIG90aGVyIGdyb3VwcyB3ZXJlIGRvaW5nIGhhbmQNCnByb29mcyBvZiBhYnN0cmFjdGlvbnMg b2YgdGhlIGNvcmUgcHJvdG9jb2wuIEFuZCBJIGJlbGlldmUgaXQncyBmYWlyIHRvDQpzYXkgLSBm cm9tIGhhdmluZyBkaXNjdXNzZWQgaXQgZXh0ZW5zaXZlbHkgd2l0aCB0aGUgcGVvcGxlIGludm9s dmVkIC0gdGhhdA0KdGhlIG1pVExTIGZpbmFsIGFuYWx5c2lzIGJlbmVmaXR0ZWQgYSBsb3QgZnJv bSB0aGUgZXhwZXJpZW5jZSBnYWluZWQgYnkNCnRoZSB0ZWFtcyBkb2luZyB0aGUgaGFuZCBwcm9v ZnMsIGdvaW5nIHJpZ2h0IGJhY2sgdG8gYSBwYXBlciBpbiAyMDAyIGJ5DQpKb25zc29uIGFuZCBL YWxpc2tpIEpyLg0KDQpNeSBwb2ludCBpcyB0aGF0IHRoZSBUTFMgMS4yICJmaW5hbCIgYW5hbHlz aXMgcmVwcmVzZW50ZWQgYnkgdGhlIG1pVExTDQp3b3JrIHdhcyB0aGUgY3VsbWluYXRpb24gb2Yg YSBsb25nIGxpbmUgb2YgcmVzZWFyY2ggaW52b2x2aW5nIG1hbnkgcGVvcGxlDQphbmQgaW5mbHVl bmNlZCBieSBtYW55IHNvdXJjZXMuDQoNCj4gRnVydGhlcm1vcmUsIGEgbG90IG9mIHRoZSBiYXJy aWVycw0KPnRvIGFuYWx5c2lzIGluIFRMUyAxLjIgZ290IHJlbW92ZWQgaW4gVExTIDEuMy4NCg0K VW5mb3J0dW5hdGVseSwgc29tZSBvZiB0aGVtIG1heSBiZSBjb21pbmcgYmFjayBhZ2Fpbi4gQnV0 IGFnYWluLCB0aGlzIGhhcw0Kbm90aGluZyB0byBkbyB3aXRoIHRoZSBhcmd1bWVudCB5b3Ugd2Vy ZSBtYWtpbmcuDQoNCj5UaGUgcXVlc3Rpb24gaXMgbm90IGhvdw0KPm1hbnkgcGFwZXJzIGFyZSB3 cml0dGVuLCBidXQgaG93IG11Y2ggdGhlIHBhcGVycyBjYW4gc2F5IGFib3V0IHRoZQ0KPnByb3Rv Y29sIGFzIGltcGxlbWVudGVkLiBBbmQgZnJvbSB0aGF0IHBlcnNwZWN0aXZlIFRMUyAxLjMncyBU YW1hcmluDQo+bW9kZWwgaXMgYSBmYWlybHkgaW1wb3J0YW50IHN0ZXAsIHdoZXJlIHRoZSBlcXVp dmFsZW50IHN0ZXBzIGluIFRMUw0KPjEuMiBnb3QgcmVhY2hlZCBvbmx5IG11Y2ggbGF0ZXIuDQoN ClRoZSB0aW1pbmcgaXMgZW50aXJlbHkgaXJyZWxldmFudCB0byB0aGUgYXJndW1lbnQgeW91IHdl cmUgbWFraW5nLg0KDQpJIGFncmVlIHRob3VnaCB0aGF0IGl0J3MgYWJvdXQgdGhlIGRlcHRoIGFu ZCByZWFjaCBvZiB0aGUgYW5hbHlzaXMuIEFuZA0KZnJvbSB0aGlzIHBlcnNwZWN0aXZlLCBJJ2Qg c2F5IHRoYXQgVExTIDEuMyBpcyBzdGlsbCB3YXkgYmVoaW5kIFRMUyAxLjIsDQpkZXNwaXRlIHRo ZSB2ZXJ5IG5pY2UgYW5hbHlzZXMgZG9uZSBieSBTYW0gYW5kIFRoeWxhIChhbmQgdGhlaXINCmNv bGxhYm9yYXRvcnMpLCBieSBIdWdvICYgSG9ldGVjaywgYW5kIGJ5IEZlbGl4ICYgY28uDQoNCkkg Y291bGQgZ28gZnVydGhlciwgYnV0IEkgZXhwZWN0IHRoYXQsIGJ5IG5vdywgb25seSB5b3UgYW5k IEkgYXJlIGFjdHVhbGx5DQpyZWFkaW5nIHRoaXMuDQoNCj5JdCdzIHRydWUgMC1SVFQgaXNuJ3Qg aW5jbHVkZWQ6IHNvIGRvbid0IGRvIGl0LiBCdXQgSSB0aGluayBpZiB3ZQ0KPnN1YnNldCAobm90 IGFkZCBhZGRpdGlvbmFsIGltcGxlbWVudGF0aW9uIHJlcXVpcmVtZW50cykgVExTIDEuMw0KPmFw cHJvcHJpYXRlbHkgd2UgZW5kIHVwIHdpdGggYSBsb25nLXRlcm0gcHJvZmlsZSB0aGF0J3MgbW9y ZSB1c2VhYmxlDQo+dGhhbiBpZiB3ZSBzdWJzZXQgVExTIDEuMiwgYW5kIGRlZmluaXRlbHkgbW9y ZSB0aGFuIGFkZGluZyB0byB0aGUgc2V0DQo+b2YgbWVjaGFuaXNtcy4gSSB0aGluayBjbGFpbXMg dGhhdCBUTFMgMS4zIG91dHNpZGUgb2YgMC1SVFQgaXMgbGlrZWx5DQo+dG8gaGF2ZSBjcnlwdG8g d2Vha25lc3NlcyBkdWUgdG8gbmV3bmVzcyBhcmUgdmFzdGx5IG92ZXJzdGF0ZWQuDQoNCkkgZGlk bid0IG1ha2UgdGhhdCBjbGFpbS4NCg0KQ2hlZXJzDQoNCktlbm55DQoNCj4tLSANCj4iTWFuIGlz IGJvcm4gZnJlZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4gY2hhaW5zIi4NCj4tLVJvdXNzZWF1 Lg0KDQoiSWYgSSBoYXZlIHNlZW4gZnVydGhlciBpdCBpcyBieSBzdGFuZGluZyBvbiB0aGUgc2hv dWxkZXJzIG9mIEdpYW50cyINCi0tIE5ld3RvbiwgaW4gYSBsZXR0ZXIgdG8gUm9iZXJ0IEhvb2tl DQoNCg0K From nobody Wed Mar 16 12:28:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B04512DAF0 for ; Wed, 16 Mar 2016 12:27:53 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 mdWf1NQEGlIh for ; Wed, 16 Mar 2016 12:27:50 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7DD312DADE for ; Wed, 16 Mar 2016 12:27:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,346,1454972400"; d="scan'208,217";a="208184939" Received: from lfbn-1-4428-119.w92-170.abo.wanadoo.fr (HELO mbbp.home) ([92.170.166.119]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Mar 2016 20:27:43 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_65546849-159C-46FB-A3BD-3ECCEC0DC571" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Benjamin Beurdouche In-Reply-To: Date: Wed, 16 Mar 2016 20:27:42 +0100 Message-Id: <2626B234-D6FB-4560-B9B1-C7A99BC0F863@inria.fr> References: To: =?utf-8?Q?Colm_MacC=C3=A1rthaigh?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ML IETF TLS Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:27:53 -0000 --Apple-Mail=_65546849-159C-46FB-A3BD-3ECCEC0DC571 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all ! > On 16 Mar 2016, at 19:49, Colm MacC=C3=A1rthaigh = wrote: >=20 > On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny = > wrote: > Much better would be implementing an optional padding feature for the = AEAD > modes. Something like this draft proposes: >=20 > https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02 = >=20 > I hadn't seen that! I wonder is there an appetite here for including = more robust LH in TLS1.2 in some form? I mean a real one; as in - = let=E2=80=99s it get it into servers and browsers sooner than TLS1.3.=20 FYI, the experimental length-hiding feature from miTLS described by = Alexandre earlier implements the draft specification linked by Kenny=E2=80= =A6 Best,=20 B.= --Apple-Mail=_65546849-159C-46FB-A3BD-3ECCEC0DC571 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all !

On 16 Mar 2016, at 19:49, Colm = MacC=C3=A1rthaigh <colm@allcosts.net> wrote:

On Wed, Mar 16, 2016 at 2:14 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> = wrote:
Much better would = be implementing an optional padding feature for the AEAD
modes. Something like this draft proposes:

https://tools.ietf.org/html/draft-pironti-tls-length-hiding-02<= /a>

I = hadn't seen that! I wonder is there an appetite here for including more = robust LH in TLS1.2 in some form? I mean a real one; as in - let=E2=80=99s= it get it into servers and browsers sooner than = TLS1.3. 


= --Apple-Mail=_65546849-159C-46FB-A3BD-3ECCEC0DC571-- From nobody Wed Mar 16 17:47:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95312D889 for ; Wed, 16 Mar 2016 17:47: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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DN0TyHtNIvcx for ; Wed, 16 Mar 2016 17:47:35 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 087D712D9C9 for ; Wed, 16 Mar 2016 17:47:33 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id g184so23175029ioa.3 for ; Wed, 16 Mar 2016 17:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oylOs+UyQKFDZ2cdNBWoOl80mWnGqviyMWcYKpe2uQI=; b=JYPAKHVmify6nBSX1wBdzlVtakPaz4Y3ASjNzlq74506kS3rn0OU9J6iq7ZA8MtW/v V2IRZjvl4vMJEjuaIzGYvPCL0s6bXC+RJbu0wKAab1Vyz+PrzkiomCxVzK67FpyMeYVM HBkT9E7KMAOB4BNzUcVHmcLVhlRbx6VsfLioU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oylOs+UyQKFDZ2cdNBWoOl80mWnGqviyMWcYKpe2uQI=; b=XJHkYsg7I2iWJYlj5HJ/LFAG7CnBxMw+0QyG0SpqYEpHFIHyEI2o1rjvVDi0HBKb+z w6fhd4tAM/kLUE0pteum2xk4UofXZgBKgB0nVUKJE6yfcEeIJ7j1OCZrAA6tsutMJRPt Vh+eqctFbAXvWAc+gygE2yenk0TOwYh+waP3/YTgzgbSVO2vvgxD3IoJlmlWRYMe4HYM gHqaBZ80qFCuljY45jgjERU3wA84NZFFXKhNiw58XcN0bXVVuNPOmLN0SieGPnt8QkNx VQrteJNGRBrrbQzgQo3G3EdGxV3U+K37YXIAH+cCzBK03UWAUC7yAGITfrKEyISpZeGa j7/Q== X-Gm-Message-State: AD7BkJLjyBFT47gTe7bOkGswIg2xdv7y1ENZfkGfyc0nuVi2xnW5Ndozgh6vCqGoQx8Sqymbv84w8cvgSawUHbuU X-Received: by 10.107.136.167 with SMTP id s39mr6670063ioi.120.1458175652193; Wed, 16 Mar 2016 17:47:32 -0700 (PDT) MIME-Version: 1.0 References: <201601152007.12464.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Thu, 17 Mar 2016 00:47:21 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113eba3cc5471f052e33f979 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 00:47:38 -0000 --001a113eba3cc5471f052e33f979 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla wrote: > On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin > wrote: > >> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: >> >>> - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then >>> we'll probably want to define >>> >> code points for 1.5 in both in-protocol (CertificateVerify) and >>> certificates to distinguish these. >>> >> >> Oh? Why would they need to be separate? The others defined for both >> aren't. >> > > The idea here would be that we want to be able to deprecate the use of > v1.5 in > CertificateVerify before its us in certs (which we can't deprecate for > quite some > time). > Gotcha. This is true independent of this change, right? Without it, we'd need to define two v1.5 SignatureAlgorithm values instead. I'm not sure this is worth the nuisance. If we expect to deprecate it soon, we should just keep it out of 1.3. If not, we only need to advertise removal if there are v1.5-preferring servers that can sign anything else, in which case why aren't they signing that to begin with? Otherwise rejecting v1.5 is going to break those servers regardless. (Then again, with SHA-1 vs. SHA-256 in ServerKeyExchange, I myself found SHA-1-preferring SHA-256-capable servers, which is baffling. Would be good if 1.3 implementers didn't repeat that one...) Should we split all other code points in anticipation of deprecating them? Why not a separate extension altogether then? Anyway, I think this is orthogonal. We can certainly allocate more v1.5 code points in either universe if people want that. *shrug* David > -Ekr > > >> >> David >> >> >>> As far as process, it seemed like people were generally positive about >>> this in this discussion, >>> but I'll rely on the chairs to determine consensus. >>> >>> -Ekr >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin >>> wrote: >>> >>>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: >>>> >>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin >>>> > wrote: >>>>> >>>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett >>>>>> wrote: >>>>>> >>>>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. >>>>>>> In TLS >>>>>>> > 1.2, signature algorithms are spread across the handshake. >>>>>>> [...] >>>>>>> > I propose we fold the negotiable parameters under one name. >>>>>>> [...] >>>>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>>>>> SignatureAndHashAlgorithm as >>>>>>> > they are. Introduce a new SignatureAlgorithm u16 type and >>>>>>> negotiate that >>>>>>> > instead. >>>>>>> >>>>>>> I previously proposed this here: >>>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>>>>> >>>>>>> ekr was against it, though it hasn't been discussed that throughly. >>>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>>>>> >>>>>> >>>>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it >>>>>> and forgot. >>>>>> >>>>>> ekr, are you still against this sort of thing? I think the new CFRG >>>>>> signature algorithms tying decisions together is a good argument for why >>>>>> we'd want this. If we believe this trend is to continue (and I hope it >>>>>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>>>>> seems poor. >>>>>> >>>>> >>>>> I'm not sure. I agree that the CFRG thing seems to be a new >>>>> development. I'll >>>>> try to confirm my previous opinion or develop a new one over the >>>>> weekend :) >>>>> >>>> >>>> ekr, did you have confirmed or new thoughts on this change? >>>> >>>> From elsewhere in the thread, I put together a draft PR if you wanted >>>> something to look at in that form. >>>> https://github.com/tlswg/tls13-spec/pull/404 >>>> It incorporated some of the suggestions in the thread (not mentioning >>>> the really legacy values, pairing NIST curves with hashes, etc.), but >>>> that's not the important part. The meat of the proposal is unifying >>>> signature algorithms under one number and a shared interface, which I think >>>> is a valuable simplification. >>>> >>>> David >>>> >>> >>> --001a113eba3cc5471f052e33f979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 15, 20= 16 at 10:37 AM, David Benjamin <davidben@chromium.org> w= rote:
On Mon, Mar 14, 2016 at 8:22 PM Eric Rescor= la <ekr@rtfm.com&g= t; wrote:
- I= f we decide to allow PKCS#1 v1.5 for in-protocol signatures, then we'll= probably want to define
=C2=A0 code points for 1.5 in both in-protocol (CertificateVerify) = and certificates to distinguish these.

Oh? Why would they need to be separate? The others defined f= or both aren't.

The idea here would be that we want to be able to deprecate the us= e of v1.5 in
CertificateVerify before its us in certs (which we c= an't deprecate for quite some
time).
<= /blockquote>

Gotcha. This is true independent of th= is change, right? Without it, we'd need to define two v1.5 SignatureAlg= orithm values instead.

I'm not sure this is wo= rth the nuisance. If we expect to deprecate it soon, we should just keep it= out of 1.3. If not, we only need to advertise removal if there are v1.5-pr= eferring servers that can sign anything else, in which case why aren't = they signing that to begin with? Otherwise rejecting v1.5 is going to break= those servers regardless. (Then again, with SHA-1 vs. SHA-256 in ServerKey= Exchange, I myself found SHA-1-preferring SHA-256-capable servers, which is= baffling. Would be good if 1.3 implementers didn't repeat that one...)= Should we split all other code points in anticipation of deprecating them?= Why not a separate extension altogether then?

Any= way, I think this is orthogonal. We can certainly allocate more v1.5 code p= oints in either universe if people want that. *shrug*

<= div>David
=C2=A0
-Ekr<= /div>
=C2=A0

=
David
=C2=A0
As far as process, it seemed like = people were generally positive about this in this discussion,
but= I'll rely on the chairs to determine consensus.

-Ekr













On Mon, Feb 29, 2016 at 9:16 AM, David Benj= amin <davidben@chromium.org> wrote:
On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <davidben@chromium.org> wrote:
On = Fri, Jan 15, 2016 at 8:07 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm D= avid Benjamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG = thing seems to be a new development. I'll
try to confirm = my previous opinion or develop a new one over the weekend :)

ekr, did you have confirmed or new thoughts on this= change?

From elsewhere in the thread, I put together a draft PR if = you wanted something to look at in that form.
https://github.com/tlswg/t= ls13-spec/pull/404
It incorporated some of the suggestion= s in the thread (not mentioning the really legacy values, pairing NIST curv= es with hashes, etc.), but that's not the important part. The meat of t= he proposal is unifying signature algorithms under one number and a shared = interface, which I think is a valuable simplification.

David

--001a113eba3cc5471f052e33f979-- From nicholas.sullivan@gmail.com Wed Mar 16 12:07:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD4812D675 for ; Wed, 16 Mar 2016 12:07:47 -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 VdM2vwqG90ha for ; Wed, 16 Mar 2016 12:07:45 -0700 (PDT) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::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 7BAB712D59D for ; Wed, 16 Mar 2016 12:07:45 -0700 (PDT) Received: by mail-pf0-x22d.google.com with SMTP id n5so85888085pfn.2 for ; Wed, 16 Mar 2016 12:07:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ouGgKZqvx9kbhc2waFDsjYw4nrjH5ED7iKGFA9U7AMI=; b=iQc8vptVgFzRsgOQFX1plOfUSJhXUq6OZDgL3/DNkEF1pOYemqrpBn9W/hx3uzDjHF T553r+W74pNYR//bCqMAc/Te+rnz0q3Q4qskikkBb3gOqsuKEIyzjyKUsygVsoGLUbm0 wCz+JTQxx5N20JE0pj5sNjzGSXwagq5vwzMf8u2jfIb4zeZadA4/WDpol4UiMiKfkjM0 tQpxGRHVOEaEt59XsI0pg7J7TCykqKOZ+d6jj8GL9E8h9eWOK/SFkLO+KNOHrHkFC8qo GcctQjk7jcycJr8UGr2O2mABygLdCK57knqypO4csH7Jjs921BIbUrzXEsdgIzQqz0q6 uQhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ouGgKZqvx9kbhc2waFDsjYw4nrjH5ED7iKGFA9U7AMI=; b=m4j0BzUYbKew4m2IGx3/s1wO8qvhReIIMm/ea/i1XuhXErE00cvE/Sr4cFmwGsIFx4 6cwd2BeOvBFchrwN/psuXz1pryjr0tOrhX3+1wQXOQCktdP/TFWG6DDLEH5qbHb8ye2D C8TJFyLX5Qyko8OnMCOOFeeif0rYyyP1SvYGjWI5OzCwW+shcDMdT3ESzHDHZYIiDnTz k13Vmopu6fVt4ckwJzES30h5/6rXTQDa0Ja0dE1FpJuuOqXbnzTlO0MvBjO+SLH2/vBu loh3q2NhFy37aZlZ+dsZ0coIb1UrjS1HWWmqKoy1ZCJHQRbPaR1CLSQpfe+XdMQY1dyI dXSw== X-Gm-Message-State: AD7BkJL9nu6X2l26F2l88DZx+qaWaoFgJaYYPEN9GW5dVLu/xF01JlA29PFScvlpjN2HBg== X-Received: by 10.98.72.213 with SMTP id q82mr8494415pfi.164.1458155265041; Wed, 16 Mar 2016 12:07:45 -0700 (PDT) Received: from [10.106.196.252] (mobile-166-137-176-021.mycingular.net. [166.137.176.21]) by smtp.gmail.com with ESMTPSA id f66sm7485364pff.8.2016.03.16.12.07.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 16 Mar 2016 12:07:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Nicholas Sullivan X-Mailer: iPhone Mail (13D15) In-Reply-To: <20160316164539.GB21439@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 16 Mar 2016 12:07:42 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <51A8A7B6-D28F-49AE-AA45-6645DDBD9356@gmail.com> References: <20160316081717.GA21439@LK-Perkele-V2.elisa-laajakaista.fi> <20160316164539.GB21439@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Archived-At: X-Mailman-Approved-At: Wed, 16 Mar 2016 18:18:42 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] Simple, secure 0-RTT for the masses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:10:52 -0000 What problem are you trying to solve here? The forward secrecy properties of 0-RTT data in PSK mode are tied to the lif= etime of the resumption secret, not a long-lived secret like the private key= . If we limit the maximum lifetime of a given session ticket (say to 7 days a= s previously proposed on this mailing list) and recommend a similar lifetime= for session ticket encryption keys, then what is the forward secrecy risk? > On Mar 16, 2016, at 9:45 AM, Ilari Liusvaara wr= ote: >=20 >> On Wed, Mar 16, 2016 at 08:12:48AM -0400, Colm MacC=C3=A1rthaigh wrote: >> On Wed, Mar 16, 2016 at 4:17 AM, Ilari Liusvaara >> wrote: >>>=20 >>> - Duplication of 0-RTT data into 1-RTT data of _different_ connection. >>=20 >> I think using a different content type solves this; the early data is >> illegal in the 1-RTT phase and the content type would distinguish it. >=20 > Nope, this can not be realistically solved, _even_ with server state > (the 0-RTT to 0-RTT duplication is unsolveable without state, but can > be solved with server state). >=20 >=20 >> As an aside: an application protocol where latency is so sensitive that >> 0RTT is attractive would hardly have its own back-and-forth with banners i= n >> the first place. >=20 > The problem is that such banners would not be bound to the TLS connection > in any way, which causes problems (TLS has no facility to transport data > from application inside extension). >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Mar 17 01:00:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9412A12D8C0 for ; Thu, 17 Mar 2016 01:00:41 -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 S-o74EsfEbMJ for ; Thu, 17 Mar 2016 01:00:39 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 1FFD912D552 for ; Thu, 17 Mar 2016 01:00:39 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id y89so66189732qge.2 for ; Thu, 17 Mar 2016 01:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=Y7IO2omxnuUP9MWMcridbLgp3aACdqIKwX5oKL7F1Xg=; b=uLpJrEBhznyhR/pmppo+UVPSBPbym2FZmw89gcKuMH8NqI+w1VkJKd5p3VhD89p7TH XLEQyLc6DJhuTDj5Aj0D8nxYlvu+j/YCZ3XrNGWmcSuTQgfY6u1Pc1fMZNqIDMoOwith vuzt04jGpzmZ3mpOY/4pG6WTFWP4B7k5h0/EjClIjmkfIT8tqauHG0O5+fJwQWeWIaUj qKD7cWjInl/ooEgwtctEcuz3GvTPPA46vl5ZCmu/Js6JJQ7gkYPW87bjJ/2dmqy0W+aq NGIX8UKJiJ7TA7eU4yrYV6z/EItAWTNGaTOVkj3KcAwTwgGM7GhMJ/95tGT/LRmg09F7 Pa1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Y7IO2omxnuUP9MWMcridbLgp3aACdqIKwX5oKL7F1Xg=; b=B/Bu3QJ6st+manhYwpPAh/SFjdyvy8UzZo01SHtSmDWxNG31q4azq4ZsWLtFqqm6FM nBBuaH66AwfvNZIqNrAg6IH5XqUVyQkdzflK+fN0KbUdYcAwpSFqY4tL6jlOIEURShYp 3i2fhMmWq0i9GlpwAmBo6HQxYuesfPyVWrQ96TjCmI8IV7QBV6fpfv7E4aIOCBd7gQhP IW38QAbgHKOuzGTMf3FNeZ+kGuigp3UowGmo0gU8LG4ygBEz9TCraTGoQdkxWtVdfH2O Tc50YLoHnZ703TjNAXyAfwyfONype+NUARbSMMO/rFzS+mjaqz4hTeD/sFCgdz1darb7 KBOg== X-Gm-Message-State: AD7BkJLmNK5s+CQD1pqEGkJ5lNER+pvnOROhhUGMdf8dmrPrfHI0Sj9QlPYF47U6xCtclA== X-Received: by 10.140.218.139 with SMTP id o133mr12957373qhb.33.1458201638189; Thu, 17 Mar 2016 01:00:38 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id b24sm3306201qkj.31.2016.03.17.01.00.37 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 17 Mar 2016 01:00:37 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Peter Gutmann Date: Thu, 17 Mar 2016 04:00:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201603170400.36176.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:00:41 -0000 On Wednesday, March 16, 2016 08:36:05 am Peter Gutmann wrote: > After a number of, uh, gentle reminders from people who have been waiting for > this, I've finally got around to posting the TLS-LTS draft I mentioned a while > back. It's now available as: > > http://www.ietf.org/id/draft-gutmann-tls-lts-00.txt Allowing CBC+encrypt-then-MAC seems like a messy route when AEAD is already available and deployed more widely. If you want to permit it, please make it optional and only have AEAD ciphers as MTI. Also, you should add a recommendation/requirement of ChaChaPoly support in there so that there will be a backup in the long-term in the event of the need to panic disable AES under TLS 1.2 for some unforeseen reason. This is aiming to be an LTS, after all. The big glaring problem, however, in multiple places, are the statements that something is "implicit in TLS-LTS, there is no need to signal it" via its designated extension. No! These features MUST be implemented in full, according to their specifications, such that they will work fully with servers that support them but not this new LTS proposal. Skimping on this just makes this messy situation even messier, which is the opposite of what you're trying to do here. Dave From nobody Thu Mar 17 05:34:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B9612D903 for ; Thu, 17 Mar 2016 05:34:05 -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 u3ZmtvP9Euqu for ; Thu, 17 Mar 2016 05:34:03 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E752E12D8F1 for ; Thu, 17 Mar 2016 05:33:55 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id m126so73745054ywd.0 for ; Thu, 17 Mar 2016 05:33:55 -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=R5mH2Ei9636HFCkXrHs3gajontPsbTyEEjygJOFjt+E=; b=rXPw9pOfoeqz7IJWJsLKS+1R9D3mjzrquX6bxK5uY1cCH9wTKXCfLPAUHR3zZgk9HM VVtPFeibGTvieT61vDN/pQe1d0mFZbORhakTocYlrekqb4OcApo2xG5NZ2z9ItY66pvA ZOf5n4eDVKpvZcigAREhUBj/q6G+LHmvRJZ2+ttfg5lpz+WHW99IZMSHW2Y4XMsyDVAu /QrchSUUmrvomlhGw0fffcA4gTvNTjybCNjr1AtEPNTxToCpxQoOqcpOBU/ofd5oXnAt zRgkJZlQs7Itj/m50T6HHMNC115NM558dbjoznX/XgXquUj6Jfxyor3J1pLFJ1YE76PA 5Fbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R5mH2Ei9636HFCkXrHs3gajontPsbTyEEjygJOFjt+E=; b=LRdXFEOAY5qukdubGEkC8QgqmordvgchRxBARTLv765z/6J7fQhEqJZ/BxhPj1zqVg erhNM4uwUqKj7Tm5ZoqEhRmpcf9pYnnPnQ0VuGPYMoA972h3HlPGRUmHVQtOvmvohDR4 lFmT326f4P8Jz87SH+oNYKnBhHkaBm2aEXlW9gDUoce+5EVwJX4MI/XHlELZ6H+OX2kO g76h2O8n30xUj1n6eBzjkGJlh6APaJOIhdDogUWuy9uXHltyDL+wDYmAlv81TFlUxkhv 6z0UqdsMovKJ0CF7vY8BIKuBVB+nrUr4aDECt2tZrH4w1ehoV8xhNQ9ip8Mt+kElgw0H IpXQ== X-Gm-Message-State: AD7BkJJNJejvq5jRtkVQAHkVU4Af0PUvRqom2w0gBonzOQFj3VDQyQdBA08G3sB4jZuvjGGv8oJblN302jFDUw== X-Received: by 10.37.95.70 with SMTP id t67mr3903178ybb.82.1458218034877; Thu, 17 Mar 2016 05:33:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 17 Mar 2016 05:33:15 -0700 (PDT) In-Reply-To: References: <201601152007.12464.davemgarrett@gmail.com> From: Eric Rescorla Date: Thu, 17 Mar 2016 05:33:15 -0700 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11423c44fb32f5052e3dd7f9 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:34:05 -0000 --001a11423c44fb32f5052e3dd7f9 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin wrote: > On Tue, Mar 15, 2016 at 7:06 PM Eric Rescorla wrote: > >> On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin >> wrote: >> >>> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: >>> >>>> - If we decide to allow PKCS#1 v1.5 for in-protocol signatures, then >>>> we'll probably want to define >>>> >>> code points for 1.5 in both in-protocol (CertificateVerify) and >>>> certificates to distinguish these. >>>> >>> >>> Oh? Why would they need to be separate? The others defined for both >>> aren't. >>> >> >> The idea here would be that we want to be able to deprecate the use of >> v1.5 in >> CertificateVerify before its us in certs (which we can't deprecate for >> quite some >> time). >> > > Gotcha. This is true independent of this change, right? Without it, we'd > need to define two v1.5 SignatureAlgorithm values instead. > Correct. I'm not sure this is worth the nuisance. If we expect to deprecate it soon, > we should just keep it out of 1.3. If not, we only need to advertise > removal if there are v1.5-preferring servers that can sign anything else, > in which case why aren't they signing that to begin with? Otherwise > rejecting v1.5 is going to break those servers regardless. (Then again, > with SHA-1 vs. SHA-256 in ServerKeyExchange, I myself found > SHA-1-preferring SHA-256-capable servers, which is baffling. Would be good > if 1.3 implementers didn't repeat that one...) Should we split all other > code points in anticipation of deprecating them? Why not a separate > extension altogether then? > I don't think we will be deprecating 1.5 for certs soon. I do see your point about 1.5 for CertificateVerify > Anyway, I think this is orthogonal. We can certainly allocate more v1.5 > code points in either universe if people want that. *shrug* > > David > > >> -Ekr >> >> >>> >>> David >>> >>> >>>> As far as process, it seemed like people were generally positive about >>>> this in this discussion, >>>> but I'll rely on the chairs to determine consensus. >>>> >>>> -Ekr >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin >>>> wrote: >>>> >>>>> On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: >>>>> >>>>>> On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin < >>>>>> davidben@chromium.org> wrote: >>>>>> >>>>>>> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett >>>>>>> wrote: >>>>>>> >>>>>>>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>>>>>>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. >>>>>>>> In TLS >>>>>>>> > 1.2, signature algorithms are spread across the handshake. >>>>>>>> [...] >>>>>>>> > I propose we fold the negotiable parameters under one name. >>>>>>>> [...] >>>>>>>> > 2. Remove HashAlgorithm, SignatureAlgorithm, >>>>>>>> SignatureAndHashAlgorithm as >>>>>>>> > they are. Introduce a new SignatureAlgorithm u16 type and >>>>>>>> negotiate that >>>>>>>> > instead. >>>>>>>> >>>>>>>> I previously proposed this here: >>>>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>>>>>>> >>>>>>>> ekr was against it, though it hasn't been discussed that throughly. >>>>>>>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >>>>>>> >>>>>>> >>>>>>> Ah, thanks! I must have missed this discussion. Or perhaps I saw it >>>>>>> and forgot. >>>>>>> >>>>>>> ekr, are you still against this sort of thing? I think the new CFRG >>>>>>> signature algorithms tying decisions together is a good argument for why >>>>>>> we'd want this. If we believe this trend is to continue (and I hope it >>>>>>> does. Ed25519 is a nice and simple interface), trying to decompose it all >>>>>>> seems poor. >>>>>>> >>>>>> >>>>>> I'm not sure. I agree that the CFRG thing seems to be a new >>>>>> development. I'll >>>>>> try to confirm my previous opinion or develop a new one over the >>>>>> weekend :) >>>>>> >>>>> >>>>> ekr, did you have confirmed or new thoughts on this change? >>>>> >>>>> From elsewhere in the thread, I put together a draft PR if you wanted >>>>> something to look at in that form. >>>>> https://github.com/tlswg/tls13-spec/pull/404 >>>>> It incorporated some of the suggestions in the thread (not mentioning >>>>> the really legacy values, pairing NIST curves with hashes, etc.), but >>>>> that's not the important part. The meat of the proposal is unifying >>>>> signature algorithms under one number and a shared interface, which I think >>>>> is a valuable simplification. >>>>> >>>>> David >>>>> >>>> >>>> --001a11423c44fb32f5052e3dd7f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 16, 2016 at 5:47 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
On Tue, Mar= 15, 2016 at 7:06 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Tue, Mar 15, 2016 at 10:37 AM, David Benjamin= <davidben@chromium.org> wrote:
On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <= ;ekr@rtfm.com> wro= te:
- If we decide to allow PKCS#1 v1.5 for in-protocol signatur= es, then we'll probably want to define
=C2=A0 code points for 1.= 5 in both in-protocol (CertificateVerify) and certificates to distinguish t= hese.

Oh? Why would they= need to be separate? The others defined for both aren't.

The idea here would be t= hat we want to be able to deprecate the use of v1.5 in
Certificat= eVerify before its us in certs (which we can't deprecate for quite some=
time).

Gotcha. This is true independent of this change, right? Without = it, we'd need to define two v1.5 SignatureAlgorithm values instead.

Correct.

I'm not sure this is worth the nuisance= . If we expect to deprecate it soon, we should just keep it out of 1.3. If = not, we only need to advertise removal if there are v1.5-preferring servers= that can sign anything else, in which case why aren't they signing tha= t to begin with? Otherwise rejecting v1.5 is going to break those servers r= egardless. (Then again, with SHA-1 vs. SHA-256 in ServerKeyExchange, I myse= lf found SHA-1-preferring SHA-256-capable servers, which is baffling. Would= be good if 1.3 implementers didn't repeat that one...) Should we split= all other code points in anticipation of deprecating them? Why not a separ= ate extension altogether then?
I don't think we will be deprecating 1.5 for certs soon. I = do see your point about
1.5 for CertificateVerify

<= /div>
=C2=A0
Anyway, I think this is orthogonal. We can = certainly allocate more v1.5 code points in either universe if people want = that. *shrug*

=
David
=C2= =A0
-Ekr
=C2= =A0

David
=C2=A0
As far as process, it seemed like people were generally posit= ive about this in this discussion,
but I'll rely on the chair= s to determine consensus.

-Ekr













On Mon, Feb 29, 2016 at 9:16 AM, David Benjamin <= davidben@chromiu= m.org> wrote:
On Fri, Jan 15, 2016 = at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Fri,= Jan 15, 2016 at 5:19 PM, David Benjamin <davidben@chromium.org>= ; wrote:
On Fri, Jan 15, 2016 at 8:07 PM D= ave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG = thing seems to be a new development. I'll
try to confirm = my previous opinion or develop a new one over the weekend :)

ekr, did you have confirmed or new thoughts on this= change?

From elsewhere in the thread, I put together a draft PR if = you wanted something to look at in that form.
https://github.com/tlswg/t= ls13-spec/pull/404
It incorporated some of the suggestion= s in the thread (not mentioning the really legacy values, pairing NIST curv= es with hashes, etc.), but that's not the important part. The meat of t= he proposal is unifying signature algorithms under one number and a shared = interface, which I think is a valuable simplification.

David


--001a11423c44fb32f5052e3dd7f9-- From nobody Thu Mar 17 10:41:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E963E12DD19 for ; Thu, 17 Mar 2016 10:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTt3fzTtzlcd for ; Thu, 17 Mar 2016 10:41:43 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2E40012DD37 for ; Thu, 17 Mar 2016 10:34:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id C58713987; Thu, 17 Mar 2016 19:34:38 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id fh6zuOq7Vv6v; Thu, 17 Mar 2016 19:34:38 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 670762310; Thu, 17 Mar 2016 19:34:38 +0200 (EET) Date: Thu, 17 Mar 2016 19:34:37 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160317173436.GA19169@LK-Perkele-V2.elisa-laajakaista.fi> References: <201601152007.12464.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:41:46 -0000 On Tue, Mar 15, 2016 at 05:37:20PM +0000, David Benjamin wrote: > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > > > I would probably characterize it less as suites vs orthogonality, but as > wanting to keep divisions in meaningful and universal places and not > splitting up tightly-coupled decisions. The flexibility from orthogonality > can be handy, but going too far---as I believe TLS 1.2 did with signature, > prehash, and curve---complicates everything. Imagine if negotiating > AES_128_GCM required separately negotiating block cipher AES-128, mode CTR, > and MAC GHASH. It isn't even orthogonal, it is coupled, which is way worse and quite difficult to implement correctly. I now consider the way TLS 1.3 draft / RFC4492bis draft currently does EdDSA negotiation a bad idea (what is proposed here is vast improvement). -Ilari From iosifidise@gmail.com Wed Mar 16 23:35:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFC812D764 for ; Wed, 16 Mar 2016 23:35:45 -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 zbqQ6qrkBAVn for ; Wed, 16 Mar 2016 23:35:43 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::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 23A3112D642 for ; Wed, 16 Mar 2016 23:35:43 -0700 (PDT) Received: by mail-ob0-x22a.google.com with SMTP id ts10so74493051obc.1 for ; Wed, 16 Mar 2016 23:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=hIDMPB7SKunTD8Rc7gpWXDnl9uCr+XV49tZJMkD/xNI=; b=VQsYWHor5zsIpRtbz2BQMOIUYU1VVXmqCAspf9R03QqfQowzxxYz6ZfTmpQN4U89Y8 hAw9L99vPGRSWCd65EZ+DmmZFNNmhqWYgdM50BSH4vSuwHqEtuUGju8MSX3IQ4sDuRJv 8+MwllBSD4TmDPqKaaMkSmeY8jPLgmgNYXEObZ2VLXfRldEcbguCunIKxl9KDLDjOyrz EW9UO1MKcY+x69gzng3S/4W6y3Ei1k/ErN6kFZ/pWj6pwgCEBvlEnYONYh5WJ60JbV2J f3pgkJVf/ge3KPr0dZtJNHK5YXtFw42or7IUwdmuqzRqWlWtBcSI1/QlZY9RLTNP2Cfk RprQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=hIDMPB7SKunTD8Rc7gpWXDnl9uCr+XV49tZJMkD/xNI=; b=G5A7fPFEBHw7LHSmTxVVyIa6DL3uxz5m61cJ6CewG0Eu6mCjrmoDdVhth260ehvNpz QqMKqiSz+r6yh/I++jPvW0//GL0DgfThPzMLDsUT+e1RxnULKnH6qm4sk8scRemXfN2e OVc9V60Nd0daTmW2G/C34Fkoj2fwPjFGkzqq6GVfzn9YboHmnuwQeCLqWXGmtkcJZvEV G32aoJnRnhbMdViycjQg5W/yIwzffcIs9x84LHFJhO8ZY2qoZjztJGZtK0IrelseEn3C aXWd9SdauAaPVtHnpTra0uusnB9fB9m5drReqdYWSMkAuvogoEFW2SgwJHpZo38nN0/i tkGg== X-Gm-Message-State: AD7BkJL20L+WZZDvmxnnujb9/T5Kazq6jGgHgXvX+FVM+qou0fuHSGqMubWs8+lqSb0tF1csLMhlSxACHKbE9A== MIME-Version: 1.0 X-Received: by 10.60.17.135 with SMTP id o7mr4952346oed.25.1458196542502; Wed, 16 Mar 2016 23:35:42 -0700 (PDT) Received: by 10.157.3.75 with HTTP; Wed, 16 Mar 2016 23:35:42 -0700 (PDT) Date: Thu, 17 Mar 2016 08:35:42 +0200 Message-ID: From: Efthymios Iosifides To: joachim@secworks.se, hanno@hboeck.de Content-Type: multipart/alternative; boundary=089e012955ecedc1e5052e38d6ab Archived-At: X-Mailman-Approved-At: Thu, 17 Mar 2016 18:28:15 -0700 Cc: klimn@di.uoa.gr, tls@ietf.org Subject: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 06:54:40 -0000 --089e012955ecedc1e5052e38d6ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello all. I have just found on the ietf archives an email discussion about the inclusion of the SPECK Cipher in the tls standards. It's reference is below : https://www.ietf.org/mail-archive/web/tls/current/msg13824.html Even though that this cipher originates from the NSA one cannot find a whitepaper that describes it's full cryptanalysis. In the above discussion Mr. Str=C3=B6mbergson somehow perfunctorily presents two whitepapers that describe the SPECK's cryptanalysis. Although we shall keep in mind that these papers describe a limited round cryptanalysis. Also we shall not forget that a similar cryptanalysis has taken place for the famous AES. Therefore i personally do not see any actual arguments apart from the facts that concerns the algorithm's provenance for not including it in a future tls specification. In conclusion even by this day the SPECK cipher has not been yet fully cryptanalyzed succesfully. Thank you! Yours sincerely, Efthimios Iosifides --089e012955ecedc1e5052e38d6ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello all.

I have just found on the ietf = archives an email discussion about the inclusion of the SPECK Cipher
in the tls standards.
It's reference is below :http= s://www.ietf.org/mail-archive/web/tls/current/msg13824.html

Even= though that this cipher originates from the NSA one cannot find a whitepap= er that describes it's full cryptanalysis. In the above discussion Mr. = Str=C3=B6mbergson somehow perfunctorily presents two whitepapers that descr= ibe the SPECK's cryptanalysis. Although we shall keep in mind that thes= e papers describe a limited round cryptanalysis. Also we shall not forget t= hat a similar cryptanalysis has taken place for the famous AES. Therefore i= personally do not see any actual arguments apart from t= he facts that concerns the algorithm's=C2=A0 provenance for not includi= ng it in a future tls specification. In conclusion even by this day the SPE= CK cipher has not been yet fully cryptanalyzed succesfully.

<= div>Thank you!


Yours sincerely,
<= div>Efthimios Iosifides




--089e012955ecedc1e5052e38d6ab-- From nobody Thu Mar 17 18:37:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0185D12DEAC for ; Thu, 17 Mar 2016 18:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=shiftleft.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Aa14_M-UdA0 for ; Thu, 17 Mar 2016 18:37:26 -0700 (PDT) Received: from astral.shiftleft.org (192-195-80-246.PUBLIC.monkeybrains.net [192.195.80.246]) by ietfa.amsl.com (Postfix) with ESMTP id 62F1612DE9D for ; Thu, 17 Mar 2016 18:37:26 -0700 (PDT) Received: from [10.184.148.249] (unknown [209.36.6.242]) (Authenticated sender: mike) by astral.shiftleft.org (Postfix) with ESMTPSA id 1EF239FFEE; Thu, 17 Mar 2016 18:37:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shiftleft.org; s=sldo; t=1458265046; bh=Cvn3A6xDB0JgebAIeMe9pUYFIK+q9EtCnIV62h8F0B8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=Q5cAl6qwdAfy21k7vugaSkTJ9O/RXcD6GiDPBjPTx8cwYLtt8MUO2fZpQhHuMiHRn 2bSzdgyO2NQdTaubkXH1lyKZTBRR3tgfJAJg1DMAOlOwca3uCZRarH9LRn1PVdyvnz J/SzbFVqOLs8QCOaxOMw2V8UWw9NYYYRuntBNGns= Content-Type: multipart/alternative; boundary="Apple-Mail=_CB7D29C0-BE7D-4E38-AFC7-B8F7F8DA8D50" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Mike Hamburg In-Reply-To: Date: Thu, 17 Mar 2016 18:37:25 -0700 Message-Id: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> References: To: Efthymios Iosifides X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at astral X-Virus-Status: Clean Archived-At: Cc: klimn@di.uoa.gr, tls@ietf.org Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:37:28 -0000 --Apple-Mail=_CB7D29C0-BE7D-4E38-AFC7-B8F7F8DA8D50 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No. The goal should be to remove ciphers, not add new ones, unless we = have a really compelling reason. Short source code is not a compelling = reason in a protocol so complicated as TLS. Cheers, =E2=80=94 Mike > On Mar 16, 2016, at 11:35 PM, Efthymios Iosifides = wrote: >=20 > Hello all. >=20 > I have just found on the ietf archives an email discussion about the = inclusion of the SPECK Cipher=20 > in the tls standards.=20 > It's reference is below = :https://www.ietf.org/mail-archive/web/tls/current/msg13824.html = >=20 > Even though that this cipher originates from the NSA one cannot find a = whitepaper that describes it's full cryptanalysis. In the above = discussion Mr. Str=C3=B6mbergson somehow perfunctorily presents two = whitepapers that describe the SPECK's cryptanalysis. Although we shall = keep in mind that these papers describe a limited round cryptanalysis. = Also we shall not forget that a similar cryptanalysis has taken place = for the famous AES. Therefore i personally do not see any actual = arguments apart from the facts that concerns the algorithm's provenance = for not including it in a future tls specification. In conclusion even = by this day the SPECK cipher has not been yet fully cryptanalyzed = succesfully.=20 >=20 > Thank you! >=20 >=20 > Yours sincerely, > Efthimios Iosifides=20 >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_CB7D29C0-BE7D-4E38-AFC7-B8F7F8DA8D50 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
No.  The goal should be to remove = ciphers, not add new ones, unless we have a really compelling reason. =  Short source code is not a compelling reason in a protocol so = complicated as TLS.

Cheers,
=E2=80=94 Mike

On Mar 16, 2016, at 11:35 PM, Efthymios Iosifides <iosifidise@gmail.com> wrote:

Hello all.

I have just found on the ietf archives an email discussion = about the inclusion of the SPECK Cipher
in the tls = standards.
It's reference is below = :https://www.ietf.org/mail-archive/web/tls/current/msg13824.html=

Even though that this cipher = originates from the NSA one cannot find a whitepaper that describes it's = full cryptanalysis. In the above discussion Mr. Str=C3=B6mbergson = somehow perfunctorily presents two whitepapers that describe the SPECK's = cryptanalysis. Although we shall keep in mind that these papers describe = a limited round cryptanalysis. Also we shall not forget that a similar = cryptanalysis has taken place for the famous AES. Therefore i personally = do not see any actual arguments apart from the = facts that concerns the algorithm's  provenance for not including = it in a future tls specification. In conclusion even by this day the = SPECK cipher has not been yet fully cryptanalyzed succesfully.

Thank you!


Yours sincerely,
Efthimios = Iosifides




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

= --Apple-Mail=_CB7D29C0-BE7D-4E38-AFC7-B8F7F8DA8D50-- From nobody Thu Mar 17 18:40:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ED912DEBC for ; Thu, 17 Mar 2016 18:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 uzoLqBX9cyan for ; Thu, 17 Mar 2016 18:40:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9556012DEB1 for ; Thu, 17 Mar 2016 18:40:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D4E8043341F; Fri, 18 Mar 2016 01:40:09 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id B5529433418; Fri, 18 Mar 2016 01:40:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458265209; bh=aA0cZKYiN7RfhtRiMuhxlE6yz0lL2u/6m7g8HEOgmaA=; l=174; h=From:To:CC:Date:References:In-Reply-To:From; b=Ag+icsY35PaK/r/jNEfgl30MBky9A4ZxHOvKBkjynWijqOTueJHsJcgAg+JYYE38J hI0wNViTiD/NKubfSqjhfLEpG3zbmIcIGBFlQbQfwvZ+9rbXUTNXgFq6zSGLplEtYY aDIAwv1Vj1ny49il1I/FJiG6vUesj4SPCdFDMQ6g= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id AF7561FC8E; Fri, 18 Mar 2016 01:40:09 +0000 (GMT) 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.1130.7; Thu, 17 Mar 2016 21:40:09 -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.1130.005; Thu, 17 Mar 2016 21:40:09 -0400 From: "Salz, Rich" To: Mike Hamburg , Efthymios Iosifides Thread-Topic: [TLS] Include Speck block cipher? Thread-Index: AQHRgLV073ctYd12P0CIElVs+Ylqn59erxWA//+9JiA= Date: Fri, 18 Mar 2016 01:40:08 +0000 Message-ID: <52619425f1ef48ff8755389e3c00ab6a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> In-Reply-To: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> 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.32.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "klimn@di.uoa.gr" , "tls@ietf.org" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:40:12 -0000 VGhlcmUgaXMgbm8gc2VyaW91cyBwcm9wb3NhbCB0byB1c2UgU3BlY2sgaW4gVExTIDEuMy4gIE9u ZSBtYWpvciByZWFzb24gaXMgdGhhdCB0aGVyZSBpcyBpbnN1ZmZpY2llbnQgY3J5cHRhbmFseXNp cyBvZiBpdC4NCg0K From nobody Thu Mar 17 18:51:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE9A12DEB7 for ; Thu, 17 Mar 2016 18:51:47 -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 gmz0PyDVy_in for ; Thu, 17 Mar 2016 18:51:44 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F43912D9EE for ; Thu, 17 Mar 2016 18:51:44 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id v123so10812978ioe.0 for ; Thu, 17 Mar 2016 18:51:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+R1YY3f4nSiR/L0BW8olg7tGkEpfgdvA2oTxe4dWfGA=; b=A6BOXBlIBH63LLus9nwIvb0mk5sZHpmWMGd3vc3TJ7OPI9ulDRFQPjD+LWa9IovRvb ZMNqk7eMPmAX30/NcwgXp6bg5xvIUfutskcX5dD99A9ZNXYkbePGalvzzspwZ82HU80H lb4IDY8UrrvX2P5EnfYgFAfIou/L69/laxQCJuqtYErnR6TTFwvHykih9cPFRJZVt5Cp h+qgh+YHAN63ZIXbIw9KbYrA6U8WzNcYP0OrJAy2du3E7Fup254r8DhA60aq9PksAhrk z/l8No2Ft7RwCPr8ZgExz6/GWyHIbGoLcVbZHmsEPfdlG2cg8U6uwWyKJAHuKgKzjAJH L4Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+R1YY3f4nSiR/L0BW8olg7tGkEpfgdvA2oTxe4dWfGA=; b=QY7NgYSiYDX4UVNeZgPQrAzQauyJJj8iTImI4kI5pflTIqulqVW6vBRkoadIVwjWdI fIEE6gpN4Ds3ej6a2jsINeNU54M1puaqtL1NrGKWxW72ixUid44r/N113uOwQOi69k7L UNnnUVdfwtFy/NvVv8LHtwr49GG1CMT5lqb3ptF/78l0ph2j/jj3FBK1NNaa2Mm0Uyhd u0wiu/k+HSE2Mlo5AUheKgFJRALsjkkO9pIqUQXjQWOi2/l9B5oul7BGrP1ZrB59mz// NULMIulXbdtANy246f9imRLTHsHPS2rpiAC6WB+f86xhmzhGsJHvJhrG9nwV8yPtTSDo n/1A== X-Gm-Message-State: AD7BkJLaNW8CWtQzar0GpCwsj5pJjN5ajIckE61yrZI4lgeBTBTCm3Mc/UBMzlMR3CijuQ9YBnmi/BVdbNx5nw== X-Received: by 10.107.185.134 with SMTP id j128mr12794721iof.23.1458265903438; Thu, 17 Mar 2016 18:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.132.4 with HTTP; Thu, 17 Mar 2016 18:51:24 -0700 (PDT) In-Reply-To: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> References: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> From: Tony Arcieri Date: Thu, 17 Mar 2016 18:51:24 -0700 Message-ID: To: Mike Hamburg Content-Type: multipart/alternative; boundary=94eb2c0810ac29a462052e48fd47 Archived-At: Cc: klimn@di.uoa.gr, Efthymios Iosifides , "" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:51:47 -0000 --94eb2c0810ac29a462052e48fd47 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 17, 2016 at 6:37 PM, Mike Hamburg wrote: > No. The goal should be to remove ciphers, not add new ones, unless we > have a really compelling reason. > +1 -- Tony Arcieri --94eb2c0810ac29a462052e48fd47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 17, 2016 at 6:37 PM, Mike Hamburg <mike@shiftleft.org> wrote:
No.=C2=A0 The goal should be to remove ciphers, not add new ones= , unless we have a really compelling reason.=C2=A0
=

+1=C2=A0

--
Tony Arcieri
--94eb2c0810ac29a462052e48fd47-- From nobody Thu Mar 17 19:09:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF49B12D814 for ; Thu, 17 Mar 2016 19:09:06 -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 rZCB2EwlPLCq for ; Thu, 17 Mar 2016 19:09:05 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 3CF6A12D808 for ; Thu, 17 Mar 2016 19:09:05 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id o5so37607765iod.2 for ; Thu, 17 Mar 2016 19:09:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=cx2jS5tv0WEEk0HmBW0jmLwMzMwFWlgZHrf8ZRnxDQM=; b=bTmIKQRCWlPooyW+W95xPpN+aNNg7jNr57qYdVRVgt2GtqF0kyBAJEMdRvyFWpqyhE G401ehaI+aU7tmrKLmfrsgF6fTrLtup/pgXppPJO8iCF29Mz+Ydf8wWytSyMP8EdgfVA O99uRiDh8Y33r9stDY3BF0KUoC9BECgsP06MJQmxyMfaqLAwNN+ByTKqzi3UwXN0nZi5 0kPsReRoCxUOmc+9WXHGdkXyKoB5pCX+qAw7khXffc7tYrFEYHHq3XM70vQcnI4WLrD0 gytwRJtg1aogZiKmK/sExboFI8rlaOk2x61Ux337GTtagWFyqXlVOqkenDaLFhtZMIms vr8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=cx2jS5tv0WEEk0HmBW0jmLwMzMwFWlgZHrf8ZRnxDQM=; b=b6PlMLOroOgPA9Z7uCu1qcXZxfuBl+Igx5ZpPmjsHlolh8Y3M2RW4QuDKrx0nZml/3 u2nehR0tLHh+NqPw5p84e3uKz+gzyW5JRBLZcAaVUbbTMC1XX8Vltx0UHPXOQ8oNtGxm nBnXIV1fWeLtE2BetIJF+xIQevkigh/08FxHzrKug0XgkbIKPZWThsjrK+IHxr9DY/Ub o2LsTqwWNefHHuizqT4sG7MsFLGSsz5703TJgZYw/976Cp/Uyafq8OfWWjqOnyfeAy7t 5l/Lvb1ogeg+YXup0nG38JvrxUEk/u/OAGs7O8uWrtkNRIM/sWffrR1ip9smk5ydwARb WLYg== X-Gm-Message-State: AD7BkJJNYE1k8ElhlWx5qG0hKFnaOitDq7s/rGF260/1AzRm6qqjY3jK2Z4IbWv7aPS30j/FZyCLkE4R72hCww== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr12162035ioi.108.1458266944663; Thu, 17 Mar 2016 19:09:04 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Thu, 17 Mar 2016 19:09:04 -0700 (PDT) In-Reply-To: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> References: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> Date: Fri, 18 Mar 2016 13:09:04 +1100 Message-ID: From: Martin Thomson To: Mike Hamburg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: klimn@di.uoa.gr, Efthymios Iosifides , "tls@ietf.org" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 02:09:07 -0000 On 18 March 2016 at 12:37, Mike Hamburg wrote: > No. The goal should be to remove ciphers, not add new ones, unless we have > a really compelling reason. A necessary, but sufficient set of reasons might include: 1. thorough cryptanalysis 2. advantages over existing ciphers on important metrics like security and speed, though this would likely need to be significant at this point 3. interest in implementation Speck is 0 from 3. From nobody Thu Mar 17 19:47:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8212D82C for ; Thu, 17 Mar 2016 19:47:46 -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 EGz3VijAxPGM for ; Thu, 17 Mar 2016 19:47:44 -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 AD93812D58E for ; Thu, 17 Mar 2016 19:47:44 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id h129so124012226ywb.1 for ; Thu, 17 Mar 2016 19:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Vyb3FQ/rx5S/4c0tPJVoS+iQY4Al3pkstG2nma5XgNo=; b=w4R6+Sl1OfB6KmAaoENKMxSbj4GGaTvJVgZvbOHQWNaIdz6jhdpHqcCC48eNe1nmPw Bu2mcY7myhBVHn5XtzVlCgk3tJtgkrK/IS+97+VPXMIIKVC53BtRbJcxVYNyN78IizkL nH8BkwE+0afhj+w1Dt4V7cb0gqSInrenu3AlRIICGFm0Ir1NZh2P3G2FGwBu2hL2cQ3y hKyAUQhVGNoGpOhtvB/PfEPM1KI/XRSJHzjhgzczAcoGchzde/2vRKPy5pospCecP29q 6Qp1Q5Ip6zCrtZm2+hzWAaMcY2reTyxM7hQSmN9wH/uCaU94Kxgepxa8kD0KlT7MfpyT odxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Vyb3FQ/rx5S/4c0tPJVoS+iQY4Al3pkstG2nma5XgNo=; b=Y9Anroycjzc6wAaYEl4d7R2jUKQXKEqVZT77wMZw479nQSUSjuIVoRBpX1uZUhcakF /ZxMYk1NjOyjx2s2WsvFi3f9XU/ffX/NVg/REb/qMSPwFciwh0GT5TYbOm5daMycVUNA tvUnMdlOXnhNU93TZZL1MbbxmWKtvNjAXc/bkI68jbaIj+/afrxRyWiNcb33bMIY7wZ/ 3uFiX75ratxi7nDTYGIgPt/iDJQIGxoRhbwBVF/DtIheR39HB8jms0McgLvA3NFOxrir IEFepny5KBNWRkMJk186cSyi+Gk6YkGLwg0RUoi1RtYHcNjmpsTC/f0rol3Dy22Se7Gz Katw== X-Gm-Message-State: AD7BkJKqdNXHka8Qc8yMgNwBn3xvNrTEZJWxfXPX7JerELTzNvEJsbnuqIhJ+MWv/WDvgOQccWPdi4wx07PqyA== X-Received: by 10.129.80.69 with SMTP id e66mr6554182ywb.231.1458269263904; Thu, 17 Mar 2016 19:47:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 17 Mar 2016 19:47:04 -0700 (PDT) In-Reply-To: References: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> From: Eric Rescorla Date: Thu, 17 Mar 2016 19:47:04 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1147f0787671d5052e49c5a7 Archived-At: Cc: klimn@di.uoa.gr, Efthymios Iosifides , "tls@ietf.org" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 02:47:46 -0000 --001a1147f0787671d5052e49c5a7 Content-Type: text/plain; charset=UTF-8 Piling on, I can't see why we would want to do this -Ekr On Thu, Mar 17, 2016 at 7:09 PM, Martin Thomson wrote: > On 18 March 2016 at 12:37, Mike Hamburg wrote: > > No. The goal should be to remove ciphers, not add new ones, unless we > have > > a really compelling reason. > > A necessary, but sufficient set of reasons might include: > > 1. thorough cryptanalysis > 2. advantages over existing ciphers on important metrics like security > and speed, though this would likely need to be significant at this > point > 3. interest in implementation > > Speck is 0 from 3. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1147f0787671d5052e49c5a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Piling on, I can't see why we would want to do this
-Ekr

=
On Thu, Mar 17, 2016 at 7:09 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
On 18 March 2016 at 12:37, Mike Hamburg= <mike@shiftleft.org> wrote= :
> No.=C2=A0 The goal should be to remove ciphers, not add new ones, unle= ss we have
> a really compelling reason.

A necessary, but sufficient set of reasons might include:

1. thorough cryptanalysis
2. advantages over existing ciphers on important metrics like security
and speed, though this would likely need to be significant at this
point
3. interest in implementation

Speck is 0 from 3.

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

--001a1147f0787671d5052e49c5a7-- From nobody Fri Mar 18 01:57:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B40012D795 for ; Fri, 18 Mar 2016 01:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqL0q5SSb-HD for ; Fri, 18 Mar 2016 01:57:29 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8438012D769 for ; Fri, 18 Mar 2016 01:57:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458291449; x=1489827449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Za+OVcmZTTnn/0TnYizueoT5k1e1H8aWoYD9tslnoi4=; b=PqpnBVmGWfQNGIa7QaEgYF4vJotlN3aeYv46pCtxnP1dFgT/ivl+PcqP KmjozhOfr8NHSG9Eyc6elv++cmFihSbN0csRcIzwHsjhOID3NY/V9ALdM kVUXxxglVX+/XFTAZXqUh5CiMQxveau2dEi3z5P5/cnU9jzs0gHnC3YfF tS294+yTEPYgN75QmyLCNChQkCdknhkcENM4sLsKgCKtOGP2WdX/D3bP+ tugIi39/llQLB3dW6wnN+mIeHMKyYFOElfL2YVAYwtrXnFEBqHoPzR7h0 wBDDO3iE7SeLn/F1lvtmLVxEeYCFacZt/lbCji6yNjiD9NTW9PAv5ioud g==; X-IronPort-AV: E=Sophos;i="5.24,354,1454929200"; d="scan'208";a="75063931" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Mar 2016 21:57:27 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Fri, 18 Mar 2016 21:57:27 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3A= Date: Fri, 18 Mar 2016 08:57:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:57:35 -0000 Watson Ladd writes:=0A= =0A= >As written supporting this draft requires adopting the encrypt-then-MAC=0A= >extension. But there already is a widely implemented secure way to use MAC= s=0A= >in TLS: AES-GCM. =0A= =0A= This is there as an option if you want it. Since it offers no length hidin= g,=0A= it's completely unacceptable to some users, for example one protocol uses T= LS=0A= to communicate monitoring commands to remote gear, they're very short and= =0A= fixed-length, different for each command, so if you use GCM you may as well= be=0A= sending plaintext. In addition GCM is incredibly brittle, get the IV handl= ing=0A= wrong and you get a complete, catastrophic loss of both integrity and=0A= confidentiality. The worst that happens with CBC, even with a complete abu= se=0A= like using an all-zero IV, is that you drop back to ECB mode.=0A= =0A= >Likewise, this draft modifies the way the master secret is computed, despi= te=0A= >a widely implemented different solution to the problem, namely the EMS tri= ple=0A= >handshake fix. =0A= =0A= Firstly, that solves an entirely different problem, and secondly I don't=0A= recall ever seeing EMS support in any embedded device, it may be widely=0A= implemented in Windows and OpenSSL but I don't know how much further it goe= s.=0A= =0A= >The use of uncompressed points makes off-curve attacks much easier than wi= th=0A= >compressed points. =0A= =0A= Everything uses uncompressed points at the moment without any problems, and= =0A= compressed points are patented.=0A= =0A= >The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensive= ly=0A= >analyzed then TLS 1.2. =0A= =0A= As the rationale points out, the mechanisms in SSL were also very heavily= =0A= analysed when they were released. It didn't protect the protocol from 20= =0A= years of subsequent attacks, which we've leared about over those 20 years o= f=0A= implementation and deployment experience. With TLS 1.3 we have zero=0A= implementation and deployment experience. Do you really believe there will= =0A= never be any attacks on it after it's rolled out?=0A= =0A= Peter.= From nobody Fri Mar 18 01:59:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1F712D793 for ; Fri, 18 Mar 2016 01:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9NJc9zTpSfo for ; Fri, 18 Mar 2016 01:59:03 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F3DB12D769 for ; Fri, 18 Mar 2016 01:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458291543; x=1489827543; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=STy3UqdLXM1bGNdoXv2IHZ45T5LD3V6Z7W8sGJZtDig=; b=Bpu5k6T5d4rQiXIMLflVT2jB/Vk5o3yd+f8lDgYa5lnTDtee1Yq7lPJ0 7Emwr2KpeJaYgW7ws0Ax3KFxX3daUQGgxTw2f+i6Vg/1w0MULNDY0t58I lrMvlgR8AaCynFV36ZtAP96szN2Rbbn6Ys2TJQ+pZmvnTEDW0wXcefwya U3gtdEw7dA2HwyiiUoQr0PYkmp5VO25Msv/zzOi/3hlfa17CxPdPAVWkr CQRVk6KFUMtwr5T7+g8+FCWm9tFAeFSL50XOaaXfvbmG0rSyIohWw0/FX IFuAh9i90QYojMLjOMUVP/7Iol1m6lhp/t+uSuz+TBApKRNTVIllWqZhu w==; X-IronPort-AV: E=Sophos;i="5.24,354,1454929200"; d="scan'208";a="75064031" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Mar 2016 21:59:01 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Fri, 18 Mar 2016 21:59:01 +1300 From: Peter Gutmann To: Wan-Teh Chang Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//VvcAgAOQ/pw= Date: Fri, 18 Mar 2016 08:59:00 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C25E7E@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:59:05 -0000 Wan-Teh Chang writes:=0A= =0A= >This is the procedure specified in PKCS #1 v2.1 (RFC 3447), Section 8.2.2,= =0A= >with the additional requirement that the comparison in Step 4 be constant-= =0A= >time, right?=0A= =0A= Good catch, thanks! I've added it to the draft.=0A= =0A= Peter.= From nobody Fri Mar 18 02:06:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5D412D538 for ; Fri, 18 Mar 2016 02:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXWtkCVaUp8Q for ; Fri, 18 Mar 2016 02:06:04 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 142E612D7A4 for ; Fri, 18 Mar 2016 02:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458291964; x=1489827964; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=zmxHfO98Zryva6wNHjp8TUO+yyQeYEhQIapk0CucxTM=; b=3dY1zyLxTsy8ePiRGODHk9uS8ftmImSTrhrQLoD6c7EomyFhvagftG3s kMX3RgSdHXdZ5CrfvAoiS6E3z8yAJ8+gVPC2pKB5CbB/WpJASISbjejMb l1HTx2qy8zwVo/2YsvOiKPhEug07VcT0SOCdMaGDaSMVRgUDC9hmATV/O qK6AouoFcb6rDtaLfZyAJAo7/9JITWgPp0ZmyTBPxR6fQ5oeuiwCg3JzO ViBMmV7gjbYw9SIxmtlemZzfHgMnY3bzPlyJfUvA30Nc+rp41gkfNPcAo 9SAcx3FZiu/qtA0hZCmuO79VbUPIZ2fvHCudUYVqJj6yguIKxeqXXIcax w==; X-IronPort-AV: E=Sophos;i="5.24,354,1454929200"; d="scan'208";a="75065518" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Mar 2016 22:05:50 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 18 Mar 2016 22:05:50 +1300 From: Peter Gutmann To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egANbZiAAE/Mgtw= Date: Fri, 18 Mar 2016 09:05:50 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C25EAB@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz>, <201603170400.36176.davemgarrett@gmail.com> In-Reply-To: <201603170400.36176.davemgarrett@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:06:05 -0000 Dave Garrett writes:=0A= =0A= I've already replied to the other parts in an earlier reply, leaving:=0A= =0A= >The big glaring problem, however, in multiple places, are the statements t= hat=0A= >something is "implicit in TLS-LTS, there is no need to signal it" via its= =0A= >designated extension. No! These features MUST be implemented in full,=0A= >according to their specifications, such that they will work fully with=0A= >servers that support them but not this new LTS proposal. Skimping on this= =0A= >just makes this messy situation even messier, which is the opposite of wha= t=0A= >you're trying to do here.=0A= =0A= Good point, I've changed the text to say that for TLS-LTS purposes you don'= t=0A= need it, but you do if you need to interop with non-LTS servers/clients.=0A= =0A= Peter.= From nobody Fri Mar 18 07:40:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77D912D81A for ; Fri, 18 Mar 2016 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 UjLB-raIqR4o for ; Fri, 18 Mar 2016 07:40:08 -0700 (PDT) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c: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 28C9612D918 for ; Fri, 18 Mar 2016 07:39:02 -0700 (PDT) Received: by mail-vk0-x236.google.com with SMTP id k1so143903638vkb.0 for ; Fri, 18 Mar 2016 07:39:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=sxB+RtS5rJc757hhcvZJ+Dp6Xx3k2hqzoniDPhnxjJ8=; b=dAlmK1Ds/cYsSgF05PrvJgEqeBhLSHMDOJ7tuCGrvmT+y0HvGB0wobC4dbhaO90BWI e8Vfpq31jkHGA2J2vrebNfwL4aNgWqaMRL4VkazPTcwhyvKU6U89NMgcsni/x1Ejjw0i S7+YrkapRfvdwGmwBMx8GWWSdMuVL8p53lP2k52xoy8x7F5S7NyEQy+5eIpEOLSHZrNz IW81n1azOGsnIMGfjXQ2OqHQGYKUPionUO2dyWQsGxN9kUdXMLFZO7q6kjyCRDItM9RV /Q9bx8qCicdpJf2BRbBgABKRJHr9YYsFrtHSrKr4tbp5TbrqI7FO4eOefwYIlc16oKzC 3ZPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=sxB+RtS5rJc757hhcvZJ+Dp6Xx3k2hqzoniDPhnxjJ8=; b=i2A4lJgjSsTwQ8NFwSFx1vhZzvtgA4IL/7vH7Z3VwJCMvBXgKD0Tjz0eFBwiPMs547 2r7vlgv6+aCuTUMtCub3/tdXqILsTo3z5VCr6rz/PJ2VXOENZi9ZcHr1DybtHqm/4Jva tkq7lZiJUEn8blZPcDc0JHKwwRkNKjDNJEn0u0HIF5YAbQ5EYA2IrGJr7wgwkwKRHqez n+QwiqMjxgoPaoaUowGZ3y0we1kKw1ar0hR0AHCGEk/9NuWNOrpmuKstOtOA1lHuA7at JbSGDK/u1RegDi3KLbW2h6HdUObucxNGvfrx5HlWAqOFLBw+Pf7uLi2qEq2pU9YqQ7a0 NVzg== X-Gm-Message-State: AD7BkJKTig9xO6f8tXXm61jjiq5ZFqrApU4uI8WwTSfRD+pG7RQJKDMV3GRldIyLEwuKHnxwZ13AZn3bzsQF+A== MIME-Version: 1.0 X-Received: by 10.31.10.199 with SMTP id 190mr17624420vkk.51.1458311941119; Fri, 18 Mar 2016 07:39:01 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Fri, 18 Mar 2016 07:39:01 -0700 (PDT) Date: Fri, 18 Mar 2016 07:39:01 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:40:11 -0000 On Fri, Mar 18, 2016 at 1:57 AM, Peter Gutmann wrote: > Watson Ladd writes: > >>As written supporting this draft requires adopting the encrypt-then-MAC >>extension. But there already is a widely implemented secure way to use MACs >>in TLS: AES-GCM. > > This is there as an option if you want it. Since it offers no length hiding, > it's completely unacceptable to some users, for example one protocol uses TLS > to communicate monitoring commands to remote gear, they're very short and > fixed-length, different for each command, so if you use GCM you may as well be > sending plaintext. In addition GCM is incredibly brittle, get the IV handling > wrong and you get a complete, catastrophic loss of both integrity and > confidentiality. The worst that happens with CBC, even with a complete abuse > like using an all-zero IV, is that you drop back to ECB mode. Then use a padding extension that solves all problems, instead of relying on a side effect of CBC mode. Why do we want this to look different from TLS, instead of a subset of widely deployed things ala UTA? Furthermore, GCM only requires adding a counter for each packet, which you have to do anyway. If you want, specify GCM-SIV. > >>Likewise, this draft modifies the way the master secret is computed, despite >>a widely implemented different solution to the problem, namely the EMS triple >>handshake fix. > > Firstly, that solves an entirely different problem, and secondly I don't > recall ever seeing EMS support in any embedded device, it may be widely > implemented in Windows and OpenSSL but I don't know how much further it goes. What is your master secret change solving? I don't see how EMS is solving an entirely different problem, but maybe that's because I don't understand what your change is solving. > >>The use of uncompressed points makes off-curve attacks much easier than with >>compressed points. > > Everything uses uncompressed points at the moment without any problems, and > compressed points are patented. At RWC 2016 one of the presentations decrypted connections to a server by exploiting off-curve point attacks. Your draft claims that verifying signatures before sending will address an ECC security threat. I don't see what threat that addresses, and there is a much worse one that is left unaddressed, namely off-curve point attacks. We should mandate no reuse of ephemerals to help with that. > >>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more extensively >>analyzed then TLS 1.2. > > As the rationale points out, the mechanisms in SSL were also very heavily > analysed when they were released. It didn't protect the protocol from 20 > years of subsequent attacks, which we've leared about over those 20 years of > implementation and deployment experience. With TLS 1.3 we have zero > implementation and deployment experience. Do you really believe there will > never be any attacks on it after it's rolled out? Deployment does not affect the protocol's amenability to analysis, or the degree of analysis it should receive. The actual history of TLS 1.2 and earlier analysis shows that many of the vaunted "attacks" are the result of old publications being dusted off, due to the anemic response of the security industry to the attacks, and that there's an actual body of knowledge The use of predictable IVs in TLS 1.0 was first commented on by Rogaway in 1995. (I'm hunting down the source, but this is from a presentation of Patterson) That should have immediately resulted in a protocol change but didn't. Did it really take 20 years to realize this was a problem? Or was it 20 years of ignoring the problem until exploitation? In 1998 Bleichenbacher noted that PKCS 1.5 encryption is dangerous. TLS could use much better simpler designs which hash the ciphertext and plaintext together, but didn't. Today we still haven't killed a nearly 20 year old attack. That TLS doesn't sign enough when using DH was an observation made in 2004. Sadly I don't recall who did it. It wasn't fixed over two revisions, and culminates in Logjam. Did this require deployment to be observed? Lastly, it's the primitives but the protocol that is the proper unit of analysis. With TLS 1.3 we have a symbolic model and have a considerable amount of examination of the cryptographic security. That should give far more confidence than 20 years of being run: computers don't analyse the protocols they run. Sincerely, Watson > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Mar 18 07:46:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC2512D6A5 for ; Fri, 18 Mar 2016 07:46:51 -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=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 2RpyF-6gr8tr for ; Fri, 18 Mar 2016 07:46:49 -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 5A90912D5CF for ; Fri, 18 Mar 2016 07:46:20 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id h129so141541718ywb.1 for ; Fri, 18 Mar 2016 07:46:20 -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=WUEFvdoMcMnJ8d3HVvECMo7QlHFByOzq5ozKimuwGlU=; b=1dA/O9GbsEeAxGewKcNPW8T7nZayn/NWAV5JuwGOJ8k7Gd/1FySGldOmDlvHQqpNKc PwvGjQ9i1NCl4zzqP+qpQGNGCnBNlvWtDTyd/59CedyGH2a/PwSfAqMGtsznVciNniyn JkyOBz43HS8u6W2gsmgxj5ZeKn4cAxVs78PcA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WUEFvdoMcMnJ8d3HVvECMo7QlHFByOzq5ozKimuwGlU=; b=VESMlUU65kWLdRwM03zlNxEmxxiRnWVdWnn1ZsRTH2Ga3WBoQQJfprXlajgOl4QhL7 iDDi0jtjNdkHzTwRy/YppxznBvQEPisESk60gBiArv60Uc6Qejfsuo78pUMW7jMHYUzd TRs+RzU8ORapRoIHoI9Jxe7TATDs10qCKzWx4hZvJZZymwdYzgNoWEyC7NpE1zDnN792 wOdFWXAiIuVJ/xCpcHZsUEQ0sZqGNuftFnyvhJ3eCkUKUyjl6L2htMIgrbx8zlEDP9ja YP+AYdR5s6sfrXoWHCd+QAtE7nZSgoX6a1e7EaFjBtyC61pXAoYvB3vGAn/kEv2O4cym yazQ== X-Gm-Message-State: AD7BkJKNos7Uwqd7dsXaGO7XIqyDbXFywrUxnsSdmOSEyOGPXb5i/Gaqy93SDJZrbVHaOfjgCoWyK+vZHGrlNZJx X-Received: by 10.37.97.22 with SMTP id v22mr3671006ybb.71.1458312379480; Fri, 18 Mar 2016 07:46:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.126.197 with HTTP; Fri, 18 Mar 2016 07:46:00 -0700 (PDT) In-Reply-To: References: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> From: Tom Ritter Date: Fri, 18 Mar 2016 09:46:00 -0500 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: klimn@di.uoa.gr, Efthymios Iosifides , "tls@ietf.org" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:46:51 -0000 On 17 March 2016 at 21:09, Martin Thomson wrote: > On 18 March 2016 at 12:37, Mike Hamburg wrote: >> No. The goal should be to remove ciphers, not add new ones, unless we have >> a really compelling reason. > > A necessary, but sufficient set of reasons might include: > > 1. thorough cryptanalysis > 2. advantages over existing ciphers on important metrics like security > and speed, though this would likely need to be significant at this > point > 3. interest in implementation > > Speck is 0 from 3. I might make it .5 for 3. Speck is specifically designed to be a lightweight cipher for constrained devices. With RC4 dead in the water - we don't have one of those. (Unless ChaCha20 is better than Speck/Simon/related...) That said, we'd still need the other 2.5 - and no, I'm not supporting it either. -tom From nobody Fri Mar 18 10:09:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BDF12D58B for ; Fri, 18 Mar 2016 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPBb744hfT2F for ; Fri, 18 Mar 2016 10:08:58 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF7E12D61A for ; Fri, 18 Mar 2016 10:08:57 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 8002144CF4; Fri, 18 Mar 2016 18:08:55 +0100 (CET) X-purgate-ID: 152705::1458320935-00007292-50577E28/0/0 X-purgate-size: 738 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 1C4D140D2E; Fri, 18 Mar 2016 18:08:54 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id CB0801A471; Fri, 18 Mar 2016 18:08:54 +0100 (CET) In-Reply-To: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Fri, 18 Mar 2016 18:08:54 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="ISO-8859-1" Message-Id: <20160318170854.CB0801A471@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Mar 2016 17:09:00 -0000 Colm MacC=E1rthaigh wrote: >=20 > But I take the point that AEAD modes are harder for programmers to screw > up; and that does have value. Though it is a pretty flawed assumption. I've seen an AEAD cipher implementation fail badly just recently (resulting in corrupted plaintext that went unnoticed within TLS--MACing the ciphertext is obviously a pretty dumb idea), something that is *MUCH* more unlikely to happen to any cipher suites using GenericBlockCipher PDU. Pretty much all of othe known crypto attacks are highly theoretical and meaningless in practice, whereas corrupted plaintext is an immediate real pain in the ass. I'm glad that the problem was spotted before the affected code was shipped. -Martin From nobody Fri Mar 18 10:10:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAD012D780 for ; Fri, 18 Mar 2016 10:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MiSUS3V8dfRL for ; Fri, 18 Mar 2016 10:10:53 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145E512D6AF for ; Fri, 18 Mar 2016 10:10:51 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 893172B077; Fri, 18 Mar 2016 18:10:49 +0100 (CET) X-purgate-ID: 152705::1458321049-00007292-CA36A798/0/0 X-purgate-size: 367 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4852840CEB; Fri, 18 Mar 2016 18:10:49 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 429551A471; Fri, 18 Mar 2016 18:10:49 +0100 (CET) In-Reply-To: To: Alexandre Anzala-Yamajako Date: Fri, 18 Mar 2016 18:10:49 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20160318171049.429551A471@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list 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 Mar 2016 17:10:55 -0000 Alexandre Anzala-Yamajako wrote: > > IMO, the layer creating the plaintext shouldn't have to pad it for security > that's the job of the TLS layer. Yep. And retrofitting random padding into TLS (all protocol versions, all PDUs) could be actually pretty simple and straightforward. http://www.ietf.org/mail-archive/web/tls/current/msg11626.html -Martin From nobody Fri Mar 18 10:49:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CCF12D627 for ; Fri, 18 Mar 2016 10:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 91Tyv24RZzIZ for ; Fri, 18 Mar 2016 10:49:23 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9307112D61B for ; Fri, 18 Mar 2016 10:49:23 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id l68so47613032wml.1 for ; Fri, 18 Mar 2016 10:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=cPgCYEJhhPQSVyI4YIwRTZxjardEj+hxaMIQhL3dxbI=; b=QQzRAz7R994BbmdGfdJFHw6dOKFG3Zedsxx5TDHeiXgIpmg2XAmPuk1RIOQ9yR2Vjo mvurnlFsxb055ON0FJR6vZrO0SBZHmECyqhG/gF/BQNF1E5Xiet7hdhhlPKXGY04s9BS zmor3LanI9mPz2nmGlD8AFIICrhGct9OnMNj0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=cPgCYEJhhPQSVyI4YIwRTZxjardEj+hxaMIQhL3dxbI=; b=Pd7rdmmSwzWJWibOhJkuy760Rua8yB8EaoUZBWz/pduoxdU0nX1+Jb9WACXYnKJziL GktvHVbhGqXaXPawZ6of0VdzbXhJGlnJnPeQyY2tLCjOq4NG7IsebWJJ47s/4DNFFtP5 E2/ph6DnBEa417SchbFSqjIlUzi8WM4rVO1wbA+Pwrx6L6g4g07dTouEkjep+RVwtF9T sPdospunK9SXfE5WmFyCMdkf94lZwTTcqyIWKVvmqCwBU0qGtlPELwpXyOVR9Qg8ZSdN s7N8nGoGOF0ZefenGVS3b1zPYG3gRlhwBEKSYeSchZFaaX7gTPKyH9sEjLBNmsZ20TY3 JlNw== X-Gm-Message-State: AD7BkJLK7/f/tiUVJMvij+IyRM3HvnTG2x5N8lYNlkKGly/U5Ppa20hJEzok0d9+fAP4IA== X-Received: by 10.194.80.38 with SMTP id o6mr18781276wjx.57.1458323362008; Fri, 18 Mar 2016 10:49:22 -0700 (PDT) Received: from [172.20.5.60] (port-213-160-6-163.static.qsc.de. [213.160.6.163]) by smtp.gmail.com with ESMTPSA id w10sm450767wmw.1.2016.03.18.10.49.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Mar 2016 10:49:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C219A4B7-445F-4911-BF11-D69CF74019EC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: Date: Fri, 18 Mar 2016 18:49:18 +0100 Message-Id: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> References: To: Efthymios Iosifides X-Mailer: Apple Mail (2.3112) Archived-At: Cc: klimn@di.uoa.gr, tls@ietf.org Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:49:26 -0000 --Apple-Mail=_C219A4B7-445F-4911-BF11-D69CF74019EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 17 Mar 2016, at 07:35, Efthymios Iosifides = wrote: >=20 > Hello all. >=20 > I have just found on the ietf archives an email discussion about the = inclusion of the SPECK Cipher > in the tls standards. > It's reference is below = :https://www.ietf.org/mail-archive/web/tls/current/msg13824.html >=20 > Even though that this cipher originates from the NSA one cannot find a = whitepaper that describes it's full cryptanalysis. In the above = discussion Mr. Str=C3=B6mbergson somehow perfunctorily presents two = whitepapers that describe the SPECK's cryptanalysis. Although we shall = keep in mind that these papers describe a limited round cryptanalysis. = Also we shall not forget that a similar cryptanalysis has taken place = for the famous AES. Therefore i personally do not see any actual = arguments apart from the facts that concerns the algorithm's provenance = for not including it in a future tls specification. In conclusion even = by this day the SPECK cipher has not been yet fully cryptanalyzed = succesfully. I don't see any compelling argument for the inclusion of SPECK? Not only = would the affiliation with NSA give the TLS-WG a bad rep. in the public, = more importantly, it makes one of our main problems worse: combinatorial = explosion of possible cipher-suites in TLS. This problem is so bad that = it needs multiple blog posts, an effort by Mozilla and bettercrypto.org = to get sys-admins to configure their services. Aaron --Apple-Mail=_C219A4B7-445F-4911-BF11-D69CF74019EC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW7D+fAAoJEOTbZJL9ubXVg/YP+QFvjkxFNYrApTaKinFReRFI w/zxwnT1PLsW1DWirJwVWwP8Gntd/uCVSe1f+gZiNeJM2wR8a16ldenB+/S90OM4 LBxlBp0b10qIED1tdLjIlj4bupj2ryJRCt7X7xqBVaO4aULlJ9kvRm3BQe31GXxy bhrAb9Beh93JT9BXe9/r47giGFdykWqtDZzDPwOG8eofo4pCDjV13p3CMLmP6Nkr Cu5WkRsRmGffJmL1MWBl1qbD36bccu0aJ1GqkOw6XNOSO6Q5jNHaX8JAbbrgHhj3 OlFu2jqU7qr9CFpidsQsWHYRt1VbOatmlRpuAmjE2yeOusw+/unfOAAXOtPVf06R gJQ6EGSqFXhiQi0UTnIcYwDoKuCJN7iw2DWG4b2BuC8tV++iVc8vvC9Uu2nMbm7q UQkpnOIr8b2u3U/X2w3Xf+nuL7zbjaFt2UM62HUBWQ8GioWv/R0x9ODTD733iLGF Rdi5HT0yVWYqbf9FiuJGSajn95f6R/KGHQ02NSAkSc3G9RW66zlOf46SZUE4/FYQ qSTN/IWS5L8P/JD3X/w7pxtRaJJfNlXFQ3TKsShwYSVIEt5OG762d2/NFTFNQSs+ 8PEWgc9LJ8Cx8qzOkYjYp3vqOQ03DhKA3bfLjLNeg4MA/64V0AyFdOm+IZPjOjyc 7EmcHdw8rddF5uZ3eGU+ =KUrS -----END PGP SIGNATURE----- --Apple-Mail=_C219A4B7-445F-4911-BF11-D69CF74019EC-- From nobody Fri Mar 18 12:13:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D67312D505 for ; Fri, 18 Mar 2016 12:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahBW7T2orv83 for ; Fri, 18 Mar 2016 12:12:59 -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 C4B9412D5D5 for ; Fri, 18 Mar 2016 12:12:59 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 3B12BD4E62; Fri, 18 Mar 2016 19:12:59 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2IJCvDY025231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Mar 2016 15:12:58 -0400 From: Hubert Kario To: tls@ietf.org Date: Fri, 18 Mar 2016 20:12:52 +0100 Message-ID: <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.4-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2831036.68QhK05a0G"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 18 Mar 2016 19:12:59 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:13:01 -0000 --nextPart2831036.68QhK05a0G Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 18 March 2016 08:57:26 Peter Gutmann wrote: > Watson Ladd writes: > >Likewise, this draft modifies the way the master secret is computed,= > >despite a widely implemented different solution to the problem, > >namely the EMS triple handshake fix. >=20 > Firstly, that solves an entirely different problem, and secondly I > don't recall ever seeing EMS support in any embedded device, it may > be widely implemented in Windows and OpenSSL but I don't know how > much further it goes. it may solve a different problem, but its solution is a superset of wha= t=20 you propose I haven't seen support for X9.42 DHE parameters or selective mixing in=20= of them to master secret in embedded devices either... you modify behaviour of Master Secret calculation one way or another,=20= let's do this in a way that is interoperable with other implementations= ,=20 not add a third way to do that also, if it really is supposed to be Long Term Support, why it doesn't=20= say anything about implementation explicitly being able to handle big=20= key sizes? both RSA and DHE? I might have missed, but where is the specification of the acceptable=20= signature algorithms (hash especially) on Server and Client Key Exchang= e=20 messages? Finally, I'd prefer the tls-lts to mostly say "see those other=20 extensions? I really do mean it" + some pleasantries like the "no=20 rehandshake". =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2831036.68QhK05a0G 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 iQIcBAABCgAGBQJW7FM0AAoJEJKo0bgB0vX11f0P/iDG1l7d+xP4b0yNhft0DyWD wiyb3fpYBqI60oCBqZY7Xk9M6r/ZYPNPyFRABxo24Ajg2fyRX2Tu+QI2pDCdDETp Kw6J/tzr91ryk4xvULjeg8pV7cwB+Yh+ZTOF8DJuNEBPMUKRd4ieLgWeIofRf+gv 1ZRQ5+pej1/FtTaewH5IYnppN0TPcDj/YwHtuCr+ovNPr625rSWpeT6039QLEcWe HkPDmt+pA8T3OUthlg33+1fUEAbqiT85eTQfIXqdYgpaHbwHUJuYphVvBUj52qiC KKIHYJrb/bZB0zgC7Ip6sZ+Ueb3XaLa6BnJHmpRZFe3KXYMOE/EBK/9MB16XE8tz F3hPJpI+tN5stgOvw7QSNR3c06ji8TPhkwFuH0EJWDTSzRB2H0VcQk2wl/jLanPb M0gLvkY1GAvO8kMpcVZHvofaCjMdRJtR/sF58EeFhqPeBvE4p1UKTZ2KAKThcVqb r2ynqHeU4zv835EogPbCY5MQDv06vAlc70NEMlrTjkTqVfZsa1e0XBif5sAZLsYk 5iEPWTs3n4OakNrsSw7i983Kv2EVgnELWVS8zYaiR9SrY5LmWEBErKwJ7pmGLfI3 K9iQYP1B5QveCzkclRK5RPmW0EfMiV9It0nRWtcg9Ri+49I/KBlHuL9kCI1wmVfo 7mguLzqG+DGq3wqwlYUE =PP02 -----END PGP SIGNATURE----- --nextPart2831036.68QhK05a0G-- From nobody Fri Mar 18 12:42:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 094A812D758 for ; Fri, 18 Mar 2016 12:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.903 X-Spam-Level: X-Spam-Status: No, score=-106.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FaXxSsRzu369 for ; Fri, 18 Mar 2016 12:42:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AEBF12D6FA for ; Fri, 18 Mar 2016 12:42:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 2701E180003; Fri, 18 Mar 2016 12:41:26 -0700 (PDT) To: ekr@rtfm.com, nagendra@cs.stanford.edu, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20160318194126.2701E180003@rfc-editor.org> Date: Fri, 18 Mar 2016 12:41:26 -0700 (PDT) Archived-At: Cc: worley@ariadne.com, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC6347 (4642) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:42:12 -0000 The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=4642 -------------------------------------- Type: Editorial Reported by: Dale R. Worley Section: 4.1 Original Text ------------- version The version of the protocol being employed. This document describes DTLS version 1.2, which uses the version { 254, 253 }. The version value of 254.253 is the 1's complement of DTLS version 1.2. This maximal spacing between TLS and DTLS version numbers ensures that records from the two protocols can be easily distinguished. It should be noted that future on-the-wire version numbers of DTLS are decreasing in value (while the true version number is increasing in value.) Corrected Text -------------- Replace "1's complement of DTLS version" with "1's complement of TLS version": version The version of the protocol being employed. This document describes DTLS version 1.2, which uses the version { 254, 253 }. The version value of 254.253 is the 1's complement of TLS version 1.2. This maximal spacing between TLS and DTLS version numbers ensures that records from the two protocols can be easily distinguished. It should be noted that future on-the-wire version numbers of DTLS are decreasing in value (while the true version number is increasing in value.) Notes ----- Clearly this won't confuse the reader, but it is incorrect as written and should be corrected at some time. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Mar 18 16:31:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74FED12D557 for ; Fri, 18 Mar 2016 16:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SjmCjfN0aqdJ for ; Fri, 18 Mar 2016 16:31:28 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3553312D884 for ; Fri, 18 Mar 2016 16:31:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458343888; x=1489879888; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/wK8vvAYZSghYr0oVXJzHqdGUhJfsEv/Bjjlh7ykUp4=; b=k3Ht7mF43GcJ/HIiYNjm3flfdmFVvfpwRhxoPMYEgH1yc8khmE/mbaRX KWvnUI0fx9mbBnIFt3Z5LGhOgUmv2ZLlGnv8Rnz0Ja5sb7+jTNqJLm4hE NfEF9yS1AQxSzCaQ5FsdfiOhZV+VavpgkmWZGo1UIGkqS/UMLBNzsdFwG VccXNxxiXR2FeQ8tKpYsX72ubjJQr3WFBAEIlxw/Hag/ksfbwHZnikEOT 4HfjfmPd7ScJrcWdHWpQ1e25pvZwGbMBmnwd4qQukHrvpaMmA87/2Kc+o BPvGRNHbjTDbLqm/XwmRqFHDJ1CJpb5e2/kFmWueidJidp9BS2puzg1/S Q==; X-IronPort-AV: E=Sophos;i="5.24,357,1454929200"; d="scan'208";a="75143985" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Mar 2016 12:31:26 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Sat, 19 Mar 2016 12:31:25 +1300 From: Peter Gutmann To: Watson Ladd Thread-Topic: History of TLS analysis (was Re: [TLS] TLS 1.2 Long-term Support Profile draft posted) Thread-Index: AQHRgSPsNtKHnKFH4U2s3fp8fjKVEJ9f2c6k Date: Fri, 18 Mar 2016 23:31:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C2682D@uxcn10-tdc05.UoA.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:31:32 -0000 Watson Ladd writes:=0A= =0A= >Then use a padding extension that solves all problems, instead of relying = on=0A= >a side effect of CBC mode. =0A= =0A= It's not a "side-effect of CBC mode", CBC mode allows padding packets, GCM= =0A= doesn't, see Colm MacC=E1rthaigh's recent post on the topic.=0A= =0A= >Why do we want this to look different from TLS, instead of a subset of wid= ely=0A= >deployed things ala UTA?=0A= =0A= CBC mode ciphers have been part of TLS since SSL 2.0 (AFAIK) in 1994, I don= 't=0A= know if SSL2 allowed for packet padding but 3.0 certainly did, so it's hard= ly=0A= a major change.=0A= =0A= >What is your master secret change solving?=0A= =0A= Preventing manipulation of DH/ECDH parameters.=0A= =0A= >Your draft claims that verifying signatures before sending will address an= =0A= >ECC security threat. I don't see what threat that addresses=0A= =0A= The fact that ECC algorithms are extremely vulnerable to fault attacks, and= a=0A= single faulty signature can leak the private key, at which point its game= =0A= over.=0A= =0A= I don't really know how to say the following without it sounding like an ad= =0A= hominem attack, but how much do you really know about real-world deployment= =0A= issues for this stuff? You seem to be arguing for all sorts of personal=0A= preferences based on, I dunno, abstract theorising, but you appear to be=0A= totally unaware of actual real-world issues. What I'm trying to figure out= =0A= is, how seriously am I supposed to take your comments? Do you actually hav= e=0A= any real-world deployment experience with using this stuff in the field?=0A= =0A= Peter.= From nobody Fri Mar 18 16:54:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73E212D5AA for ; Fri, 18 Mar 2016 16:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQqQa4kNzV2s for ; Fri, 18 Mar 2016 16:53:59 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D35912D557 for ; Fri, 18 Mar 2016 16:53:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458345239; x=1489881239; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e2VFj6QZrEu2M19bk//PloYphrOBPdaZ07IpSPlXUJE=; b=wMub1vT1fMRkm/LPBAWrm44d8YPvixCwNNgMiELFy2hXonulq0GINA5Y m54lvM7vZ9wjWMTfFdyGhsnPIloMP9swX2f1IEqC0SnpiH0bhLhNmjCsf 6lRRRpMDfp7kjSQYq3m6wsRS5xIQroLVwfCNMig9/vOc5p5u3d2yrc9aY 0fJeycM0crNzwwildO1SfTKZrCEBOb7itMgO2tMpJ5dszoOW8XnL2+RBz P6FLbm/gshIWulvUGTxDU5OLsk8dDWUTCBJNzvFSeYgOyNPwqKJrMKYEN 5h6xX9vGxZzjn79dpKSbHTQ2Zt2/1idahnXJCisU7zKyp/qEvKIbaovJT A==; X-IronPort-AV: E=Sophos;i="5.24,357,1454929200"; d="scan'208";a="75145243" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Mar 2016 12:53:45 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Sat, 19 Mar 2016 12:53:44 +1300 From: Peter Gutmann To: "mrex@sap.com" , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= Thread-Topic: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? Thread-Index: AQHRf6/SV1Ay+QdHmEWVtQKTdggsTJ9bixwAgAMNSQCAAUr1TA== Date: Fri, 18 Mar 2016 23:53:44 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C2687E@uxcn10-tdc05.UoA.auckland.ac.nz> References: , <20160318170854.CB0801A471@ld9781.wdf.sap.corp> In-Reply-To: <20160318170854.CB0801A471@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:54:01 -0000 Martin Rex writes:=0A= =0A= >Though it is a pretty flawed assumption.=0A= >=0A= >I've seen an AEAD cipher implementation fail badly just recently (resultin= g=0A= >in corrupted plaintext that went unnoticed within TLS--MACing the cipherte= xt=0A= >is obviously a pretty dumb idea), something that is *MUCH* more unlikely t= o=0A= >happen to any cipher suites using GenericBlockCipher PDU.=0A= =0A= There have been many more failures with GCM, the most notorious being Colin= =0A= Percival's tarsnap, where a single missed operation (increment the IV)=0A= resulted in a total loss of security. Colin is a very experienced crypto= =0A= developer, so its not like this was some beginner mistake. This is why I= =0A= referred to GCM as "brittle", you can be about as abusive as you like with = CBC=0A= and the worst you get is degradation to ECB, while with GCM you make one=0A= mistake and you get a catastrophic loss of security.=0A= =0A= Peter.= From nobody Fri Mar 18 17:13:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1327012D6B8 for ; Fri, 18 Mar 2016 17:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93Ts93Mde2fA for ; Fri, 18 Mar 2016 17:12:56 -0700 (PDT) Received: from BLU004-OMC2S36.hotmail.com (blu004-omc2s36.hotmail.com [65.55.111.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E58312D592 for ; Fri, 18 Mar 2016 17:12:56 -0700 (PDT) Received: from BLU177-W25 ([65.55.111.71]) by BLU004-OMC2S36.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 18 Mar 2016 17:12:55 -0700 X-TMN: [c32E5SRTUOq6DOrZluLfVWZAiJz0cjdR] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Watson Ladd , Peter Gutmann Date: Fri, 18 Mar 2016 17:12:54 -0700 Importance: Normal In-Reply-To: References: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 19 Mar 2016 00:12:55.0258 (UTC) FILETIME=[15CFBBA0:01D18174] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 00:12:58 -0000 > That TLS doesn't sign enough when using DH was an observation made in=0A= > 2004. Sadly I don't recall who did it. It wasn't fixed over two=0A= > revisions=2C and culminates in Logjam. Did this require deployment to be= =0A= > observed?=0A= Don't forget how OpenSSL disabled the stronger EXPORT1024 ciphersuites in 2= 006 too.=0A= =0A= Yuhong Bao = From nobody Sat Mar 19 02:31:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB58112D5A3 for ; Sat, 19 Mar 2016 02:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaRxwQVEMZgG for ; Sat, 19 Mar 2016 02:30:58 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6F7112D591 for ; Sat, 19 Mar 2016 02:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458379857; x=1489915857; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=y6rNcdFSc2DqNh8wl83qQlMY+/kwqXsXLcZK0RsfGY4=; b=pQMIlcRqbfaIvEjxFFF7JlEieRI7NlbHL1Oaq8Uxi4LGDN99Qlw3jO6x QwppaCFVjZ95gZ83pygtYVOgjTL8KTzNmfkRaQGuBZjYwjX5ynbUZe8aU UGVhkntcXArB8K3m7QpB6GqzuZKD1dowzx7sBwgJWiaonzLj8NfYKTKL/ h0dty4WwMADn92npk2TU6qLjhwzMflVG8i2jYvZhckMtyWNU/G51OCtBl GW5XbUaeCst2B34zDYdo0pFD65yjP5ZvHoqyc/WfC8mjCRClwZ+E70coF DqZ7CyjyT90c4RJcHuODK0y37FAEvDUXWYcBzyQEFaJhlbTErvKGmJsMA w==; X-IronPort-AV: E=Sophos;i="5.24,360,1454929200"; d="scan'208";a="75186239" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Mar 2016 22:30:26 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Sat, 19 Mar 2016 22:30:26 +1300 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROr Date: Sat, 19 Mar 2016 09:30:26 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz>, <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> In-Reply-To: <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:31:03 -0000 Hubert Kario writes: >also, if it really is supposed to be Long Term Support, why it doesn't say >anything about implementation explicitly being able to handle big key size= s? >both RSA and DHE? I've deliberately avoided getting into that because it's such a rathole, you've got everything from the NIST numerologists at one extreme to the "go= od enough for now" folks at the other, and you'll never get any consensus beca= use there are completely different worldviews involved. A possible median is: Implementations SHOULD choose public-key algorithm key sizes that are appropriate for the situation, weighted by the value of the information bei= ng protected, the probability of an attack, and the ability of the hardware to deal with large keys. For example a SCADA system being used to switch a ventilator on and off doesn't require anywhere near the keysize-based secur= ity of a system used to transfer classified information. One way to avoid havi= ng to use very large public keys is to switch keys periodically. This can be done by regenerating DH parameters in a background thread and rolling them over from time to time, or if this isn't possible, by pre-generating a selection of DH parameters and choosing one at random for each new handshak= e, or again rolling them over from time to time. >I might have missed, but where is the specification of the acceptable >signature algorithms (hash especially) on Server and Client Key Exchange >messages? That's implicit in the cipher suites, RSA or ECDSA + SHA256. Peter.= From nobody Sat Mar 19 07:51:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F9012D560 for ; Sat, 19 Mar 2016 07:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 cDavgt34RBt7 for ; Sat, 19 Mar 2016 07:51:01 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c: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 39FD012D556 for ; Sat, 19 Mar 2016 07:51:01 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id q138so81032301vkb.3 for ; Sat, 19 Mar 2016 07:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=fyRNMJRl6aAOn5KSLKuyEnqflPnMHI2mWvoVtt2NXjM=; b=uR4cpXOoYcV2Ao1D4kpUb3QruHboxO76PllLrYTVl/ulfov7g4KZ1Lpz8vYMAewLZu v4/sSGsqwg/YXf2QFqpyVSiYUcKX0V3H7OSAhTGeVAdqSa1aDzBm46cMz8V/8e8KQJKR uDqNqgoHWoaMnrsD6cvjO3kSkRGeLLSelanuMPthgEGVNHJJXcFVd4VB5Z/aO31W4KpP Tp8VUPlgw2cUEtK8ju6l7BtV54NPNu+r1toLs1oJZYIdJB9YuXSbMx/t99YNNxt+I+e9 taFvAB4jAYloJFblOOhGTxi2YX9Y4NgiBcaoDTJqfCgCKgcLbNqMk5EDX2UwcN/UadQ9 aT3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=fyRNMJRl6aAOn5KSLKuyEnqflPnMHI2mWvoVtt2NXjM=; b=dtfTr88QvGObwWpaWYbxMXisWHhCgTYUejxYKlw18kOTrp6La4jT9mjezc/d6KYzo2 hQzZ5g1pRCw4oRjTypNH1dhto4FyZ9DDQXzmp07FBziUVw6ruoQPGvDwXRTsrEV36+hA tvOzw8gaODUegOmkNu1cp98BSXz88Fw2Qd4DE4rmTo9PDR5GYTeCmydul8bo+wkg1oFL 4Wh/XySoc1TvJ0l09h+AK8IjEYdCze1MQjZxaDA2F2iceWb6YENvvOSF1u7gOCgRGaoE 6LXIbIGX4prU8QINrB5uPmr5yPOxyukvB2wpYGmFd6JrWwWnOz3HXBKK677sXkIiNI2B Qs+Q== X-Gm-Message-State: AD7BkJJ25br87qok0yPOTMkHt2jptHu/eOJ8n94nKS3ufQHPWhHkQD9HuJx58zAaU4YvCsZRlNZAIOGMpm9OwQ== MIME-Version: 1.0 X-Received: by 10.31.162.3 with SMTP id l3mr23617296vke.68.1458399060155; Sat, 19 Mar 2016 07:51:00 -0700 (PDT) Received: by 10.176.1.183 with HTTP; Sat, 19 Mar 2016 07:51:00 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2682D@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2682D@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sat, 19 Mar 2016 07:51:00 -0700 Message-ID: From: Watson Ladd To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:51:03 -0000 On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann wrote: > Watson Ladd writes: > >>Then use a padding extension that solves all problems, instead of relying= on >>a side effect of CBC mode. > > It's not a "side-effect of CBC mode", CBC mode allows padding packets, GC= M > doesn't, see Colm MacC=C3=A1rthaigh's recent post on the topic. GnuTLS is the only implementation that pads to more than 16 byte boundaries > >>Why do we want this to look different from TLS, instead of a subset of wi= dely >>deployed things ala UTA? > > CBC mode ciphers have been part of TLS since SSL 2.0 (AFAIK) in 1994, I d= on't > know if SSL2 allowed for packet padding but 3.0 certainly did, so it's ha= rdly > a major change. It's not the CBC modes that's the change, but the EtM extension. > >>What is your master secret change solving? > > Preventing manipulation of DH/ECDH parameters. It's not immediately clear that it does so correctly. All data that affects the interpretation must be in the master secret, and I think that includes some data you haven't yet hashed. EMS we know gets this right. > >>Your draft claims that verifying signatures before sending will address a= n >>ECC security threat. I don't see what threat that addresses > > The fact that ECC algorithms are extremely vulnerable to fault attacks, a= nd a > single faulty signature can leak the private key, at which point its game > over. The same fault attack commonly works on embedded implementations for ECDH. Except here the attacker just sends a point off the curve, instead of inducing a fault in the signature routine. RSA signatures with CRT optimization (commonly used on embedded devices) is also vulnerable to similar fault attacks. I'm really not sure why you're ignoring wrong-curve attacks on cached ephemerals: just add a recommendation to not cache ephemerals. > > I don't really know how to say the following without it sounding like an = ad > hominem attack, but how much do you really know about real-world deployme= nt > issues for this stuff? You seem to be arguing for all sorts of personal > preferences based on, I dunno, abstract theorising, but you appear to be > totally unaware of actual real-world issues. What I'm trying to figure o= ut > is, how seriously am I supposed to take your comments? Do you actually h= ave > any real-world deployment experience with using this stuff in the field? Given that I'm proposing subsetting what existing implementations already do, instead of implementing new extensions, I find it remarkable you're arguing that my proposal is harder to deploy. As for what I know, I'm listed in the release notes of several TLS implementations. > > Peter. --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Sat Mar 19 14:06:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAF612D53D for ; Sat, 19 Mar 2016 14:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MPXq4VKPGFp for ; Sat, 19 Mar 2016 14:06:32 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B8312D50C for ; Sat, 19 Mar 2016 14:06:32 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id d205so113933946oia.0 for ; Sat, 19 Mar 2016 14:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=31K1yExy17eP7atc4EVPQ9USRzekA2jbCEnLuO4Acmk=; b=fU8eaeWs7o+R+Z9563YJ5YYy5eaKVBdGmggZBZnu1Q5Stp28yDkvBK3YzBeCgnwPxV k+RbrNklLZ84yLjMez7NSsKBGHxvC/QmR2I+f01SAU0jPzA/DSD/luZcsVlzEuSC/3Ed I5uAAWKzTW9Htkl1UYVJyb+cCJrg3S6OEBdrSTIoE6btACKLTOX95LMvdH83KT4yRovb R7+DHXytMiWzVo/EnsDtI7v1v6KqnYZSgoY4wI0G0PrRaYpK4RotUJzJ3/qxNRy2UnrW dGvHzQ0yxRmnStjcefDGxOoxxufW+wxkiCI/j32oN1JGx7nmiCu0e7synPZKmqHnFDny CN7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=31K1yExy17eP7atc4EVPQ9USRzekA2jbCEnLuO4Acmk=; b=TmdQdziO3OKDkLCnDb9Sk2+RMiwQApLvTldk8BPM9PmbsrrThvOCLTG8cbXFjzJTlp XBJcsAkHVNm8cVlGJkKoma/DbkaUr1bY1iG9Ko5EMcs23j2YM7+9vZQuTmWF+G+suUPi aoAI1KLTzWBgSdSEXLGkxl1ZCf0wBHVjxav1DSXLkCU6P1ydu9Y+mZ9xdr8Gw8aZq18K +IeBeOqR1h1Mwp3WCHUEzhVjNvd71HiKgDfhLYkWu6xtCXx2WiYYy0h4FBZmvSaX5Nus MOwAs9TV8HLWC+6IMAroZKE91nlMvGSaefEJX8aIgVN/CrmYr62tBGS4cdh5OJrtYcny k6ng== X-Gm-Message-State: AD7BkJJnrNrn5FzoJ9yglqfWfmSdYDyckiH7xUlLPzDsQePLVhQ/RKh7MkXyr3j76QJCV3G6DH0m+Q1duLMVfw== MIME-Version: 1.0 X-Received: by 10.202.221.87 with SMTP id u84mr13471977oig.93.1458421592065; Sat, 19 Mar 2016 14:06:32 -0700 (PDT) Sender: sschaege@googlemail.com Received: by 10.182.24.101 with HTTP; Sat, 19 Mar 2016 14:06:31 -0700 (PDT) In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sat, 19 Mar 2016 22:06:31 +0100 X-Google-Sender-Auth: isjKF5VammgHtzDQlbt2HBhsId0 Message-ID: From: =?UTF-8?B?U3ZlbiBTY2jDpGdl?= To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=001a113d526ced8eed052e6d3cf7 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:06:35 -0000 --001a113d526ced8eed052e6d3cf7 Content-Type: text/plain; charset=UTF-8 Dear Kenny, thank you for clarifying the state of the cryptographic analysis of TLS 1.2 and 1.3! I also do not see TLS 1.3 being nearly as good understood from a security standpoint as the previous version. This is only natural given that it is so recent. I am also not quite happy with the existing results and their meaning for the final version of the standard (although I really am happy that the cryptographic community in general accompanies the standard development process.) I would expect the most valuable results to be published once there is an entirely fixed candidate specification. As Hugo has mentioned several times details really matter. Therefore I really like the idea of giving cryptographers time to analyse the final candidate quite thoroughly before acceptance. And no, you guys are not the only ones reading this. Many greetings, Sven 2016-03-16 20:26 GMT+01:00 Paterson, Kenny : > Hi > > On 16/03/2016 18:44, "Watson Ladd" wrote: > > >On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny > > wrote: > >> Hi > >> > >> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd" > >> >> on behalf of watsonbladd@gmail.com> wrote: > >> > >> > >> > >>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far more > >>>extensively analyzed then TLS 1.2. It's almost like you don't believe > >>>cryptography exists: that is a body of knowledge that can demonstrate > >>>that protocols are secure, and which has been applied to the draft. > >> > >> This is patently untrue. There is a vast body of research analysing TLS > >> 1.2 and earlier. A good survey article is here: > >> > >> https://eprint.iacr.org/2013/049 > > > >There's a vast literature, but much of it makes simplifying > >assumptions or doesn't address the complete protocol. > > Correct, but that does not make it irrelevant or valueless. Or are you > actually saying that it does? Quite a sweeping presumption; see > immediately below. > > >The first really > >complete analysis was miTLS AFAIK. > > Yes, and even there the analysis was done step by step, spread out over a > series of papers which gradually built up the complexity of the code-base > being handled. And, in parallel, various other groups were doing hand > proofs of abstractions of the core protocol. And I believe it's fair to > say - from having discussed it extensively with the people involved - that > the miTLS final analysis benefitted a lot from the experience gained by > the teams doing the hand proofs, going right back to a paper in 2002 by > Jonsson and Kaliski Jr. > > My point is that the TLS 1.2 "final" analysis represented by the miTLS > work was the culmination of a long line of research involving many people > and influenced by many sources. > > > Furthermore, a lot of the barriers > >to analysis in TLS 1.2 got removed in TLS 1.3. > > Unfortunately, some of them may be coming back again. But again, this has > nothing to do with the argument you were making. > > >The question is not how > >many papers are written, but how much the papers can say about the > >protocol as implemented. And from that perspective TLS 1.3's Tamarin > >model is a fairly important step, where the equivalent steps in TLS > >1.2 got reached only much later. > > The timing is entirely irrelevant to the argument you were making. > > I agree though that it's about the depth and reach of the analysis. And > from this perspective, I'd say that TLS 1.3 is still way behind TLS 1.2, > despite the very nice analyses done by Sam and Thyla (and their > collaborators), by Hugo & Hoeteck, and by Felix & co. > > I could go further, but I expect that, by now, only you and I are actually > reading this. > > >It's true 0-RTT isn't included: so don't do it. But I think if we > >subset (not add additional implementation requirements) TLS 1.3 > >appropriately we end up with a long-term profile that's more useable > >than if we subset TLS 1.2, and definitely more than adding to the set > >of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely > >to have crypto weaknesses due to newness are vastly overstated. > > I didn't make that claim. > > Cheers > > Kenny > > >-- > >"Man is born free, but everywhere he is in chains". > >--Rousseau. > > "If I have seen further it is by standing on the shoulders of Giants" > -- Newton, in a letter to Robert Hooke > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d526ced8eed052e6d3cf7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Kenny,

thank you for clarifying the state of t= he cryptographic analysis of TLS 1.2 and 1.3! I also do not see TLS 1.3 bei= ng nearly as good understood from a security standpoint as the previous ver= sion. This is only natural given that it is so recent. I am also not quite = happy with the existing results and their meaning for the final version of = the standard (although I really am happy that the cryptographic community i= n general accompanies the standard development process.)
I would expect = the most valuable results to be published once there is an entirely fixed c= andidate specification. As Hugo has mentioned several times details really = matter. Therefore I really like the idea of giving cryptographers time to a= nalyse the final candidate quite thoroughly before acceptance.=C2=A0
= =C2=A0
And no, you guys are not the only ones reading this.

Many = greetings,
Sven


2016-03-16 20:26 GMT+01:00 Paterson, Kenny <Kenny.Paterson@rhul.ac.uk>:

On 16/03/2016 18:44, "Watson Ladd" <watsonbladd@gmail.com> wrote:

>On Wed, Mar 16, 2016 at 11:22 AM, Paterson, Kenny
><Kenny.Paterson@rhul.ac= .uk> wrote:
>> Hi
>>
>> On 16/03/2016 15:02, "TLS on behalf of Watson Ladd"
>><tls-bounces@ietf.org
>> on behalf of watsonbladd@= gmail.com> wrote:
>>
>> <snip>
>>
>>>The analysis of TLS 1.3 is just wrong. TLS 1.3 has been far mor= e
>>>extensively analyzed then TLS 1.2. It's almost like you don= 't believe
>>>cryptography exists: that is a body of knowledge that can demon= strate
>>>that protocols are secure, and which has been applied to the dr= aft.
>>
>> This is patently untrue. There is a vast body of research analysin= g TLS
>> 1.2 and earlier. A good survey article is here:
>>
>> https://eprint.iacr.org/2013/049
>
>There's a vast literature, but much of it makes simplifying
>assumptions or doesn't address the complete protocol.

Correct, but that does not make it irrelevant or valueless. Or are y= ou
actually saying that it does? Quite a sweeping presumption; see
immediately below.

>The first really
>complete analysis was miTLS AFAIK.

Yes, and even there the analysis was done step by step, spread out o= ver a
series of papers which gradually built up the complexity of the code-base being handled. And, in parallel, various other groups were doing hand
proofs of abstractions of the core protocol. And I believe it's fair to=
say - from having discussed it extensively with the people involved - that<= br> the miTLS final analysis benefitted a lot from the experience gained by
the teams doing the hand proofs, going right back to a paper in 2002 by
Jonsson and Kaliski Jr.

My point is that the TLS 1.2 "final" analysis represented by the = miTLS
work was the culmination of a long line of research involving many people and influenced by many sources.

> Furthermore, a lot of the barriers
>to analysis in TLS 1.2 got removed in TLS 1.3.

Unfortunately, some of them may be coming back again. But again, thi= s has
nothing to do with the argument you were making.

>The question is not how
>many papers are written, but how much the papers can say about the
>protocol as implemented. And from that perspective TLS 1.3's Tamari= n
>model is a fairly important step, where the equivalent steps in TLS
>1.2 got reached only much later.

The timing is entirely irrelevant to the argument you were making.
I agree though that it's about the depth and reach of the analysis. And=
from this perspective, I'd say that TLS 1.3 is still way behind TLS 1.2= ,
despite the very nice analyses done by Sam and Thyla (and their
collaborators), by Hugo & Hoeteck, and by Felix & co.

I could go further, but I expect that, by now, only you and I are actually<= br> reading this.

>It's true 0-RTT isn't included: so don't do it. But I think= if we
>subset (not add additional implementation requirements) TLS 1.3
>appropriately we end up with a long-term profile that's more useabl= e
>than if we subset TLS 1.2, and definitely more than adding to the set >of mechanisms. I think claims that TLS 1.3 outside of 0-RTT is likely >to have crypto weaknesses due to newness are vastly overstated.

I didn't make that claim.

Cheers

Kenny

>--
>"Man is born free, but everywhere he is in chains".
>--Rousseau.

"If I have seen further it is by standing on the shoulders of G= iants"
-- Newton, in a letter to Robert Hooke


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

--001a113d526ced8eed052e6d3cf7-- From nobody Sat Mar 19 16:30:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A737B12D57F for ; Sat, 19 Mar 2016 16:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R7QL1pyOP7c for ; Sat, 19 Mar 2016 16:30:38 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7993112D522 for ; Sat, 19 Mar 2016 16:30:38 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id s68so63724720qkh.3 for ; Sat, 19 Mar 2016 16:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version :content-transfer-encoding:message-id; bh=ruK2umjoeyJHfQ2csga7lFQdk9/XHMemZnRScekkMUE=; b=jVWa2dK3PLNnd9Y/sAizsDvznLf2VJ0/wSCthaUnR7tjl/hnfct+if+BdbsfMmLFeg 6wy5zE1VKRbCs+amZHHHl40nluOuQE33ccXaxfUf5HknZfM8w315H1ixsSMWEu/Vd+Zj WYsnE4YdmhZa2ZiTMLun5DnSf1Cm7bMHQKeZlTfeeMXKa/Zo0q+7imVSc1mrQcryaQK6 pF3ZSUSOU02ODJPfhiQTwiJjV0yNfLBV6470amRIXd01DHX/c78EPMljPWz9fz69vDzD WgrYVXqRKzPmGUP+xDPh42b2SwWR3d+jAGjrwnEd3ofYuW/gGXSdvD/fLQxiMAB3CvEf hzgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=ruK2umjoeyJHfQ2csga7lFQdk9/XHMemZnRScekkMUE=; b=gonngqlSLdui3v2hg80I+aEt1D4OvvzzD5eafvLnXgVn9iiCykf+RoN7clNTdJ538C aPxl4OtBbwmlstshZ2GCega7dOKBb5MClnxQLU25JnuA7Lxron28FNnz4dljf3qxzgXv 5UNZmQkZssa9oF4tE2jw8UTGfwCSN0++iaHs9nXlXSw0rQE1/eZ7NvsjMzxeYgupWRqS PP7LuRXgc3LtYgh2CNsasc7T64x1zKlkHBNqpzYNvfF5jk9z7LRa/9H8Q19tlprAa6Fq luTnQw+tJj61xte7AzxxGX4hB3/nzWM4hO9fy6svVQZwTFQ9eBGLr0AtL1pU+IQvjmlq dfGA== X-Gm-Message-State: AD7BkJJKPICfMQ0E1XAdrvqZ3wAtYaNeFdq1rZN7Cpch3E/Jh7miCoQDsT9TQOnjeWby+w== X-Received: by 10.55.73.199 with SMTP id w190mr31301902qka.77.1458430237478; Sat, 19 Mar 2016 16:30:37 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id a8sm9032179qhd.38.2016.03.19.16.30.36 (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 19 Mar 2016 16:30:36 -0700 (PDT) From: Dave Garrett To: tls@ietf.org, Peter Gutmann Date: Sat, 19 Mar 2016 19:30:35 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201603191930.35445.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:30:40 -0000 https://tools.ietf.org/html/draft-gutmann-tls-lts-01#section-3.2 > TLS-LTS adds a hash of the domain parameters into the master secret > to protect against the use of manipulated curves/domain parameters: > > o TLS-LTS implementations MUST include a SHA-256 hash of the EDH or > ECDH parameters in the master secret computation by concatenating > the hash to the pre_master_secret value. In the case of EDH, the > value that's hashed is the ServerDHParams structure. In the case > of ECDH the value that's hashed is the ServerECDHParams structure. > This means that the master_secret computation becomes: > > master_secret = PRF(pre_master_secret || param_hash, "master secret", > ClientHello.random + ServerHello.random) > [0..47]; It would be a lot simpler, safer, and interoperable to just mandate use of the Extended Master Secret Extension [RFC 7627]. https://tools.ietf.org/html/rfc7627 Dave From nobody Sat Mar 19 23:36:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 549D912D565 for ; Sat, 19 Mar 2016 23:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPG7qoV9sdcp for ; Sat, 19 Mar 2016 23:36:12 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5AC912D54D for ; Sat, 19 Mar 2016 23:36:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458455771; x=1489991771; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hldbE4Nvz4I9RmC85tUIgtrtdBRcv743CZuZklynAZU=; b=F0Jz2D4Cij7LB5ouywgrsywCsdTTsffuov+3R8JtTOkJSA0kHR+LHriS mRHaEi5Tk5iafkO9q4V2nqAWipDfn2VKWFIk99KDn+57B3lDF6cubRlNo HCvwQEC2w3pNhRgN5Rv7u/h0xSzczM6po8m68I/xB/0l9Xkg2L1zuwUqn 4hA64vxowEP2ZyXwFMsyedPhFOnDOmawZmRnh14rRMQW/Yg86/1SdOWNY 1XKGIZfThui+Q/6c36LwzpZBmUFv7fbtR1e4+UcEbm+hYhFQDnrDCOF1R tNi91/sZ57+cSEc5rYnDPQ71GuYnZGhftPO8pxNovPH/a8AjTW6zNDD37 Q==; X-IronPort-AV: E=Sophos;i="5.24,364,1454929200"; d="scan'208";a="75286120" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Mar 2016 19:36:09 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Sun, 20 Mar 2016 19:36:09 +1300 From: Peter Gutmann To: Dave Garrett , "tls@ietf.org" Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egCSfaaAACoKC6o= Date: Sun, 20 Mar 2016 06:36:09 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz>, <201603191930.35445.davemgarrett@gmail.com> In-Reply-To: <201603191930.35445.davemgarrett@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 06:36:16 -0000 Dave Garrett writes:=0A= =0A= >It would be a lot simpler, safer, and interoperable to just mandate use of= =0A= >the Extended Master Secret Extension [RFC 7627].=0A= >=0A= >https://tools.ietf.org/html/rfc7627=0A= =0A= Yeah, in hindsight it makes more sense, I'll update the draft, although the= =0A= update may not get in before the IETF freeze. I was trying to avoid having= to=0A= run two parallel hashing operations throughout the handshake (the other one= =0A= being for the Finished message), but EMS is just a much more comprehensive= =0A= solution (like EtM, it's one of those things where you think "why wasn't th= is=0A= added to TLS years ago") even if it means running two lots of hashing.=0A= =0A= The other update is to clean up the wording around which extensions TLS-LTS= =0A= implies, replacing the current wording scattered all over the draft.=0A= =0A= Peter.= From nobody Sun Mar 20 04:09:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCC612D6A3 for ; Sun, 20 Mar 2016 04:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGp6diDs6qUz for ; Sun, 20 Mar 2016 04:09:50 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id BE89D12D656 for ; Sun, 20 Mar 2016 04:09:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id C1B0123F9; Sun, 20 Mar 2016 13:09:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id zryDKbturM94; Sun, 20 Mar 2016 13:09:47 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id AB0F12310; Sun, 20 Mar 2016 13:09:47 +0200 (EET) Date: Sun, 20 Mar 2016 13:09:45 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 11:09:53 -0000 On Sun, Mar 20, 2016 at 06:36:09AM +0000, Peter Gutmann wrote: > Dave Garrett writes: > > >It would be a lot simpler, safer, and interoperable to just mandate use of > >the Extended Master Secret Extension [RFC 7627]. > > > >https://tools.ietf.org/html/rfc7627 > > Yeah, in hindsight it makes more sense, I'll update the draft, although the > update may not get in before the IETF freeze. I was trying to avoid having to > run two parallel hashing operations throughout the handshake (the other one > being for the Finished message), but EMS is just a much more comprehensive > solution (like EtM, it's one of those things where you think "why wasn't this > added to TLS years ago") even if it means running two lots of hashing. Well, if you have suitable implementation for it, the hash in EMS is over prefix of what hash in Finished is over (so if you can finalize multiple times, you can get away with just one computation). Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello and ServerHello. This was famously exploited for FREAK and LOGJAM (and then there is the DHE vs. ECDHE issue). Sadly, this was found out too late for changing EMS extension to extend the signature. Then there is the problem that DHE parameter sizes are not negotiated. This is severe enough problem that it renders DHE effecively unusable in some contexts[1][2]. And if you want ciphers that are actually not fragile, look at various MRAE algorithms, not generic composition of CBC mode with HMAC (I have seen even cryptographers get the latter wrong). [1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has negotiated DHE parameter sizes, there is nothing preventing down- negotiation to TLS 1.2, followed by server dumping some bad para- meter sizes (forcing client to either break connection or being vuln- erable to downgrade attacks). [2] If you wonder why Chrome is deprecating DHE, it is exactly this problem. -Ilari From nobody Sun Mar 20 04:49:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1F12D6D3 for ; Sun, 20 Mar 2016 04:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZguTmb64sML for ; Sun, 20 Mar 2016 04:49:28 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74BF412D6BC for ; Sun, 20 Mar 2016 04:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458474569; x=1490010569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zUOW6mNAae2akBItv6ucW85uskj4FE5RvHJ7YiLiPhM=; b=4g4DQjp0Yy9+ZSuqaIh0WmMZLnK2sKEJ9KIpZvHoXkyOGRmvt3s0lA6r Soe9PAaTvp1onO0KWo+JRMxKSxOJMUmDJE4Xs1T92y8jvQsavoYn4iUIM QFmAJ4r2bc6qv7/jAAh8G80fLZ8JHxu5yKhs/bMG6TdcxxKrtsFVyiqjI fiAiS/V3vjLW/jy3l/X4LPqOO8toFnX0RPN04QoyV2fXo1e8V68seLxuT rDCviHEXvtR35Vdw9plYemFEraDE9BqoDBX3IEdQnq1wzWgLPjxYX2Ehi tcsq9e9gbr9P7xTbUvEO3ARk8CSpxvfIgAVpPq9sRKbRCgx3ZqmCmCewv Q==; X-IronPort-AV: E=Sophos;i="5.24,365,1454929200"; d="scan'208";a="75314470" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Mar 2016 00:49:25 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Mon, 21 Mar 2016 00:49:24 +1300 From: Peter Gutmann To: Ilari Liusvaara Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egCSfaaAACoKC6r//3MHgIAA5Mgg Date: Sun, 20 Mar 2016 11:49:23 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz>, <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 11:49:32 -0000 ilariliusvaara@welho.com writes:=0A= =0A= >Well, if you have suitable implementation for it, the hash in EMS is over= =0A= >prefix of what hash in Finished is over (so if you can finalize multiple= =0A= >times, you can get away with just one computation).=0A= =0A= The problem with this is that the standard hash API is { Init, [ Update,=0A= Update, ... ], Final }, so this only works if you've got access to a custom= =0A= API that allows you to fork the state so one branch goes to Final and the= =0A= other continues with Update. It's good if you've got it, but a lot of=0A= implementations don't.=0A= =0A= >Also, TLS 1.2 ServerKeyExchange signature is not taken over ClientHello an= d=0A= >ServerHello. This was famously exploited for FREAK and LOGJAM (and then th= ere=0A= >is the DHE vs. ECDHE issue). Sadly, this was found out too late for changi= ng=0A= >EMS extension to extend the signature.=0A= =0A= Hmm, what do people feel about adding this as a fix? Given that the attack= s=0A= were based on implementations supporting crippled crypto when they shouldn'= t=0A= have and accepting an export cipher suite when they shouldn't have (i.e. th= ey=0A= were pretty broken to begin with), is it worth the compatibility-breaking= =0A= change to try and address this?=0A= =0A= >Then there is the problem that DHE parameter sizes are not negotiated. Thi= s=0A= >is severe enough problem that it renders DHE effecively unusable in some= =0A= >contexts=0A= =0A= That's such a can of worms there that I don't really want to get into it in= =0A= -LTS, unless lots of people really want to see it addressed...=0A= =0A= Peter.= From nobody Sun Mar 20 05:02:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C398F12D559 for ; Sun, 20 Mar 2016 05:02:41 -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 FvC9qXyCg_zi for ; Sun, 20 Mar 2016 05:02:39 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8682012D520 for ; Sun, 20 Mar 2016 05:02:39 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id p65so90982310wmp.0 for ; Sun, 20 Mar 2016 05:02:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5UtiA/F3z6DX3yxfx4GACmiaPcg0b0VlOzBYVcQnk4=; b=DMKEZf+X1EjULFF+Nehw0803NF8tZ5Ih+NRdicy3/4peAK8wDTYRlrDg6CnoslSsOG C/XKlXZbHoRwkzu0y6mFt1WO5FLTcXEnBGR6PiIty/378LKL/G8h0PDHJ7WIAlVMjA9y LaohsNZ2giX9OQOOIDRd1YVTddUNk+xn4aHb8aA3caovktFtNRfvP9PYh5vnvG/ySLv2 alPPPYodZGi6WRpVAojHUJ2EXo5AKJlOQM1iK06Q8XOAzCt31Imxlb5LZxCDoGHFYbvq wT7SI+v3FgXrHOw0XZ0yKSUa5mxHUk4n/FQDtxHLUgbenwlb8nQ0DBwrxg7U4ZyDk/WL 7mLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=j5UtiA/F3z6DX3yxfx4GACmiaPcg0b0VlOzBYVcQnk4=; b=UXVrCrSukqn5/eM1EkCGB+YcV+i7shtCkvT/2GyIlkNa+6t4vfq1DY9Lj2lLKcEWLq Ua+rUaX9tWL2AuDYdt17yBT7rLLzlcnpEC94eBtrJgBPI2hxbuWNK/9dVNSEn084gSIA ZeyHi/MJMCmWmsDpC2DHpiOtUnKobJ2buktQoOoi69p9jIbn+5uXtSXy//PwJCTCbNQm HDxKWn4g74VAj4cNHVgDcmBVVa0QrTq+/CEq89xN1kOgpZGD19RvFb/CGDEP2LN6tZR8 K407MTMvj/0n32/uMxASblAEf4kTL8D+2jXtiOMfu/lRVn6U1b7QCiPM9Mh++2rAR/by 4mLQ== X-Gm-Message-State: AD7BkJJTSufrLw7gD2BEPeeqYOXbIWBZP8KLxovnCYnCLQw9KeooXUEPVEBjCMMTynlIIQ== X-Received: by 10.28.35.16 with SMTP id j16mr8624089wmj.78.1458475358011; Sun, 20 Mar 2016 05:02:38 -0700 (PDT) Received: from [192.168.0.16] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id t8sm20391394wjy.41.2016.03.20.05.02.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Mar 2016 05:02:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 20 Mar 2016 13:02:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 12:02:42 -0000 > The problem with this is that the standard hash API is { Init, [ = Update, > Update, ... ], Final }, so this only works if you've got access to a = custom > API that allows you to fork the state so one branch goes to Final and = the > other continues with Update. It's good if you've got it, but a lot of > implementations don=E2=80=99t. Indeed, the hash required for EMS is usually the same as that required = for client authentication, so implementations that support client auth already support this, others = may not. >> Also, TLS 1.2 ServerKeyExchange signature is not taken over = ClientHello and >> ServerHello. This was famously exploited for FREAK and LOGJAM (and = then there >> is the DHE vs. ECDHE issue). Sadly, this was found out too late for = changing >> EMS extension to extend the signature. >=20 > Hmm, what do people feel about adding this as a fix? Given that the = attacks > were based on implementations supporting crippled crypto when they = shouldn't > have and accepting an export cipher suite when they shouldn't have = (i.e. they > were pretty broken to begin with), is it worth the = compatibility-breaking > change to try and address this? Adding the handshake hash to the ServerKeyExchange (a la EMS) provides some nice protections against downgrade and seems to be worth the = effort. Of course, for all of these LTS improvements, we need to assume that the LTS extension itself cannot be deleted by the attacker. That is, we=E2=80=99= d assume that the client or server supports *only* LTS mode. Otherwise, we=E2=80=99= d have to look closer to eliminate other downgrade attacks. -Karthik >=20 >> Then there is the problem that DHE parameter sizes are not = negotiated. This >> is severe enough problem that it renders DHE effecively unusable in = some >> contexts >=20 > That's such a can of worms there that I don't really want to get into = it in=20 > -LTS, unless lots of people really want to see it addressed... >=20 > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Mar 20 05:37:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5FA12D751 for ; Sun, 20 Mar 2016 05:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmwFFuzJQWQG for ; Sun, 20 Mar 2016 05:37:18 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1A1412D6FB for ; Sun, 20 Mar 2016 05:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458477438; x=1490013438; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aaVZtAGQRBIRRnPrjLxJkp/tDp70gUpV+x2UpEJaTRs=; b=Gqn2YN+nohLBUHegpICn8H18rfJYLc/7RJ+e9D0rMkgPcapYcXzR+wxn JRQcQKwOQW6hI6PQzvkNRYz0XEzndB3YjGvwAdSHZFxgvYXfP0zRAWRZe CmWOa2DkMWquF3RaYF2vstWaNY2Iu5KkbbwKUm+VYWpxEI6PvyE+8QtHG u0OveCqfdpJ/5GUxpGvSsdKVmCaKq2rIc9U8EZeoJh4/AQtMENcSkx4B5 ZgO63m0oNU0PbmYvcs9BCSxflyy7eZcdjArjDCGYSWqSKAIG0kSKMplPI 3PBr8JHgEaTVPF7eWjnU51fz10IxLMh6Ws2afyZW16nowUR7GeP4DGAGP w==; X-IronPort-AV: E=Sophos;i="5.24,365,1454929200"; d="scan'208";a="75319752" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Mar 2016 01:37:16 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Mon, 21 Mar 2016 01:37:15 +1300 From: Peter Gutmann To: Karthikeyan Bhargavan Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egCSfaaAACoKC6r//3MHgIAA5Mgg//8p5wCAAOOLTw== Date: Sun, 20 Mar 2016 12:37:15 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C27A2B@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz>, <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> In-Reply-To: <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 12:37:19 -0000 Karthikeyan Bhargavan writes:=0A= =0A= >Adding the handshake hash to the ServerKeyExchange (a la EMS) provides som= e=0A= >nice protections against downgrade and seems to be worth the effort.=0A= =0A= My only real concern with this is that if you've got an API that doesn't al= low=0A= forking, you're now running three hashes in parallel. Still, for everythin= g=0A= else it'd be pretty straightforward, fork once after Server Hello for the= =0A= Server Keyex sig and a second time after Client Keyex for EMS.=0A= =0A= So presumably instead of hashing the bare nonces for the keyex sig you'd ha= sh=0A= the entire hello message that contains them?=0A= =0A= >Of course, for all of these LTS improvements, we need to assume that the L= TS=0A= >extension itself cannot be deleted by the attacker. That is, we=92d assume= that=0A= >the client or server supports *only* LTS mode. Otherwise, we=92d have to l= ook=0A= >closer to eliminate other downgrade attacks.=0A= =0A= There's an SCSV-shaped hole in the draft for that :-).=0A= =0A= Peter.= From nobody Sun Mar 20 05:53:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D912D771 for ; Sun, 20 Mar 2016 05:53:41 -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 J8depeKiJDNy for ; Sun, 20 Mar 2016 05:53:39 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C0C012D753 for ; Sun, 20 Mar 2016 05:53:39 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p65so122088640wmp.1 for ; Sun, 20 Mar 2016 05:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k6H9FOI9xykfRfvoqA2G1y20SeEbKefdX6u9DptgGFk=; b=U44haTG4tPEHNQtwdLlGxYdoAMrODk/0in+pPR7RmPFc2HhKYLVCL9JNgFvG5fVMwn CNaZvAaSTdfwzA024NINoJROt8ZAcV01iLKoV7YIBnViH9ivwpvdtGmnAGjOnISWLGd1 JNWVg4aS6zx3NFFwEWAyhtjl9Mjl6boEgZubjYbvepMLwwvkv/ixxqJ1lNreFTF6KoDb 3Y6e14Jg+SxPx75TYzBkRfzyyRn7HBWsLkwjHIVAEWm9xL1cw5xr0aK0NQ1DAyfpTH+s 90IiKvnsg22OZaP6A9IzF+qIrIV09rNGh1ptZUA4OJa2lsAIUmOEUqmzz9QzOBdch3J1 1Kig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k6H9FOI9xykfRfvoqA2G1y20SeEbKefdX6u9DptgGFk=; b=FxcToDiOcWGJu2KAoO3lHC84vz2bnVeJ3SO9rUH8by3kMfnkjmEsLbdSvJPJaU17Oi aGnGmTnnX1ktxb1KrFtHuqw8/bCj8gUckodF1+1OJhsed1KWV1UkIYNdIv/VhYPeAPOO MA9V9+WxWnPs8KIuQMSWVICULENo1wWLuKNMitsumL8pyPqns4T0ycfw4g6R91lWocvQ 760yrumDkjtfRiGRada4YXkyatqTwWWeiJQM6LiSj06eqxUJ7ZemSNcTZswO5PnFtRb3 FWnyDspnbCIPvxvWMM/Q/iA3cu5F+emhVoJaN8Ufy9cFfj09S63YrrKfoRfKa+e8OJhk e3+A== X-Gm-Message-State: AD7BkJKBQNkjqslKqbeLzf2CuSURdCb8fEVnm9UIKKVWLwV/9Olb2ueOpNy/6c2vfCxbvQ== X-Received: by 10.194.222.234 with SMTP id qp10mr25032195wjc.138.1458478417999; Sun, 20 Mar 2016 05:53:37 -0700 (PDT) Received: from [192.168.0.16] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id ux5sm20535883wjc.17.2016.03.20.05.53.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 20 Mar 2016 05:53:36 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C27A2B@uxcn10-tdc05.UoA.auckland.ac.nz> Date: Sun, 20 Mar 2016 13:53:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <26C23DDE-0BE5-486F-B6EB-FD181E2EDFEF@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27A2B@uxcn10-tdc05.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 12:53:41 -0000 > So presumably instead of hashing the bare nonces for the keyex sig = you'd hash > the entire hello message that contains them? Yes, I=92d suggest hashing in the log up to ServerHello, or if you don=92t= want to clone the hash state, then maybe the log up to ServerCertificate.=20 I agree that the benefit of this is not so clear for known-weak/export = ciphersuites which should simply be disabled. The main advantage is that it is a uniform way to prevent potential = future downgrades on things like the elliptic curve. It also prevents some downgrade attacks on False Start in case LTS = enables it (I assume it doesn=92t).=20 > There's an SCSV-shaped hole in the draft for that :-). Yeah, SCSV-like mechanisms can prevent downgrades from LTS to non-LTS, = but only as long as the non-LTS version does not support weak key exchanges like = export RSA/DHE. Otherwise, the attacker first deletes LTS, then downgrades to a weak key = exchange,=20 then breaks it to complete and hijack the connection. So to get the full gain of LTS, we must require LTS implementations to = blacklist weak ciphers even for non-LTS TLS 1.2 connections.=20 -Karthik= From nobody Sun Mar 20 10:02:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1620912D590 for ; Sun, 20 Mar 2016 10:02:24 -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 hgHVjkqjmdDV for ; Sun, 20 Mar 2016 10:02:23 -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 E168D12D508 for ; Sun, 20 Mar 2016 10:02:22 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g3so192564658ywa.3 for ; Sun, 20 Mar 2016 10:02:22 -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=PTM8mkdumBEav+OOIR53c3nbXPKKP3m0qleOnirSlug=; b=hk+Ymd9uAsgetFZPVu0UVCOd7fdozAQDimsuefiCmw3e6/Z8ywcsvrd0wfTI8sJ3cx qyJTXbpQpMwWNH3tXzL6YwHSNBgSsROFiR2GoSNTwBSyF9kEAl38QOJ3EvkPa4Y+dR/t 7ir9Wyj0oKvdk91B9zIWUrxUgEEJx3FqlGSNCiGf69znriHSAySX93pFWWcBD+Ow2wSb oi/Xkop8vXoLi8DEcRhYU8vINwO00F2jNi4j4rNGj4aUoLwbofOAHOLYqpcQB7zJeuIk 6FaacH4GKFPe/cOlMgactlYKgx3Hta++L1UNnkR/+7lACp2YXMpwnMLdwDpghIWAmrTx MzTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PTM8mkdumBEav+OOIR53c3nbXPKKP3m0qleOnirSlug=; b=Gn6xSP+MttIStNDMbJKKTy80pHDfNXJbbPxtrpQ0WNeO18nqyqhMy1Cx2c20YsnVMk 8rgmxT06JmRYCfaxSLnTYWipm0RRpCzgluAqeu0QhclRMpBSA95OMsV9KarDmc0md29S /t2Z1PtEx68KFSD/RmhyG510FvmwAwDPBvXoAurZG2/5WawhH0Z3RHQhsFm9fQlzI3Ym 1vmwH6TJbqoqAD+bc3F1mPfaXhzW6fpB0XbXzFn3GvWc9Gb63/n08mdmdnKRxiA0UpzJ fklCbZSNP5QL/+1U0E/7PussXAZLx3XQ6dOX2K09m2j3ng1f/tB9JQVaa+/61G4aj+/+ xDJQ== X-Gm-Message-State: AD7BkJJW+2JQz9nBqrddjwxkCvsStbCDQjfH2BYoagwnfddsAIVVhT0+Id11MFt1juWmHcU2EKsZK5VaQiJLTg== X-Received: by 10.37.231.146 with SMTP id e140mr10368389ybh.57.1458493341979; Sun, 20 Mar 2016 10:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 20 Mar 2016 10:01:42 -0700 (PDT) In-Reply-To: <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 20 Mar 2016 10:01:42 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0b12e88ec3db052e7df1a6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 17:02:24 -0000 --94eb2c0b12e88ec3db052e7df1a6 Content-Type: text/plain; charset=UTF-8 On Sun, Mar 20, 2016 at 4:09 AM, Ilari Liusvaara wrote: > > [1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has > negotiated DHE parameter sizes, there is nothing preventing down- > negotiation to TLS 1.2, followed by server dumping some bad para- > meter sizes (forcing client to either break connection or being vuln- > erable to downgrade attacks). > The ServerRandom anti-downgrade mechanism should prevent this downgrade from 1.3 to 1.2 even in this setting. -Ekr --94eb2c0b12e88ec3db052e7df1a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Mar 20, 2016 at 4:09 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
[1] TLS 1.3 doesn't completely fix this: Even if TLS 1.3 itself has
negotiated DHE parameter sizes, there is nothing preventing down-
negotiation to TLS 1.2, followed by server dumping some bad para-
meter sizes (forcing client to either break connection or being vuln-
erable to downgrade attacks).

The Serve= rRandom anti-downgrade mechanism should prevent this downgrade
fr= om 1.3 to 1.2 even in this setting.

-Ekr
--94eb2c0b12e88ec3db052e7df1a6-- From nobody Sun Mar 20 10:51:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E5E12D642 for ; Sun, 20 Mar 2016 10:51:21 -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 Dt7Gnm4bzj5v for ; Sun, 20 Mar 2016 10:51:20 -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 B060412D572 for ; Sun, 20 Mar 2016 10:51:20 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h65so50396909ywe.0 for ; Sun, 20 Mar 2016 10:51:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QzZEjCiQCjj6ARMzmDu49widhCLAiESJeNfpGnsJX90=; b=HfYMDwFuiJn2LapoXVBfzdD8B/NIqmZt514ELPlkS3lyot9HP6SoHS4eN+C3ZI/6LE C9pGzWq2JFn54DA5ZieeWz0BH1sg67LZhLWUk3XvWIGWj/cLvvYCMBnGZjYOkRCgL7TM Wkz6jljEYJQD1w+EFDVALPVcC+bW9K0uA0wYUeQamspVF4DmqmhUC5ytbse4ECyDrqtk AOdBtwDc4MTECENkqwnfNQ5z5bjo3FubzY6xMIeDqmmW37KQ3ugU9f9eX2V/Nquj0uUR Z9SUdVAe+5PdL2k7wnWeVQep1aQbN9Z6k2gngoNQB3LYMfz0W0pLkzINCOz3LZ2Ba7wU oHHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QzZEjCiQCjj6ARMzmDu49widhCLAiESJeNfpGnsJX90=; b=VRQ1wssPGYljWul4CU64mEHJGOEgmszIEXoYDu5Q+YF4JilHMHR5jyqRlX93WyAIuO /YKpFoBfI52sst5CfKodZ+L+KcuQu+1S7mv58ry0NQUNMRFb6P7LVtMo/q7c4e+1PFWH g+6e0fhkMOvgy0v0M+210V9wJ4CsSb5Exk7PaYZv51st0EKl4F7AmadcmXCW2Na9B7GM RuuvMPZ8spjl2mMu73sKmfXCJ/+uU4dELdS/i0NRTp1ewUH5UGnE9psJCUbJWIpLUbCN CW0/bvd4ROM1wBfaRQ0E6ufFTpwX97qykQYwFvD/nqOk+LOWWsfIlE355J9ijWcPAbgT Xrvw== X-Gm-Message-State: AD7BkJKFvoCzV68Zve7181y6BhlwtM1kydIVG713CnikREfOW60UBIm0B9VGKfwpVwILZCesvyuXy4x2Tg+3Yw== X-Received: by 10.129.80.69 with SMTP id e66mr13526206ywb.231.1458496279885; Sun, 20 Mar 2016 10:51:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 20 Mar 2016 10:50:40 -0700 (PDT) In-Reply-To: <20160317173436.GA19169@LK-Perkele-V2.elisa-laajakaista.fi> References: <201601152007.12464.davemgarrett@gmail.com> <20160317173436.GA19169@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 20 Mar 2016 10:50:40 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1147f078ab68a4052e7ea0e8 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 17:51:22 -0000 --001a1147f078ab68a4052e7ea0e8 Content-Type: text/plain; charset=UTF-8 It sounds like we have general consensus here. Does anyone object to my merging this PR? -Ekr On Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara wrote: > On Tue, Mar 15, 2016 at 05:37:20PM +0000, David Benjamin wrote: > > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: > > > > > > I would probably characterize it less as suites vs orthogonality, but as > > wanting to keep divisions in meaningful and universal places and not > > splitting up tightly-coupled decisions. The flexibility from > orthogonality > > can be handy, but going too far---as I believe TLS 1.2 did with > signature, > > prehash, and curve---complicates everything. Imagine if negotiating > > AES_128_GCM required separately negotiating block cipher AES-128, mode > CTR, > > and MAC GHASH. > > It isn't even orthogonal, it is coupled, which is way worse and quite > difficult to implement correctly. > > I now consider the way TLS 1.3 draft / RFC4492bis draft currently does > EdDSA negotiation a bad idea (what is proposed here is vast improvement). > > > -Ilari > --001a1147f078ab68a4052e7ea0e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It sounds like we have general consensus here. Does anyone= object to my merging
this PR?

-Ekr
=

O= n Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara <ilariliusvaara@we= lho.com> wrote:
On Tue, Mar 15, 2016 at 05:37:20PM +0000, David Benjamin wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> I would probably characterize it less as suite= s vs orthogonality, but as
> wanting to keep divisions in meaningful and universal places and not > splitting up tightly-coupled decisions. The flexibility from orthogona= lity
> can be handy, but going too far---as I believe TLS 1.2 did with signat= ure,
> prehash, and curve---complicates everything. Imagine if negotiating > AES_128_GCM required separately negotiating block cipher AES-128, mode= CTR,
> and MAC GHASH.

It isn't even orthogonal, it is coupled, which is way worse and = quite
difficult to implement correctly.

I now consider the way TLS 1.3 draft / RFC4492bis draft currently does
EdDSA negotiation a bad idea (what is proposed here is vast improvement).

-Ilari

--001a1147f078ab68a4052e7ea0e8-- From nobody Sun Mar 20 12:53:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5FB12D546 for ; Sun, 20 Mar 2016 12:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 (1024-bit key) header.d=setec.io header.b=j017a2ST; dkim=pass (1024-bit key) header.d=setec.io header.b=o18XGo8m Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rxVz1a0LE7V for ; Sun, 20 Mar 2016 12:53:33 -0700 (PDT) Received: from xmenrevolution.com (xmenrevolution.com [97.107.134.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3388412D55C for ; Sun, 20 Mar 2016 12:53:33 -0700 (PDT) Received: by xmenrevolution.com (Postfix, from userid 113) id 949A916D76; Sun, 20 Mar 2016 15:53:32 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1458503612; bh=gq5yzmBFlS5o0V1LpAsXE+2U85ZfToiDLvbdKWYNqqQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=j017a2STLhTf1iT9VTemhj4i0J2RkYAo3q7YdzQgXyBBaSyQLD3lfoSqqmrqtb58w WzQ+plIXj6nKwUrNi4LT9U2R3ro5rVky89uWGfGAmZZhIEfKVK7gaMFSZT1xt9++2t qbyi3JW7kzLzYcxUI9VhEHR5SFS2KJE2PBrwwI6k= Received: from agartha (static-155-212-141-65.mas.onecommunications.net [155.212.141.65]) by xmenrevolution.com (Postfix) with ESMTPSA id 68A8B16CA8; Sun, 20 Mar 2016 15:53:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=setec.io; s=mail; t=1458503611; bh=gq5yzmBFlS5o0V1LpAsXE+2U85ZfToiDLvbdKWYNqqQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=o18XGo8moGcsBfzPDDs0ZcNfgpxx2Wd96+VSPLW+0F3KrrbgpyKZmKFYbVvVQpvcy SRbaSzVo2NtvDjD7HUNe405fPUIvd1fZeRmoaCQFGmROTG7bgfJwd/qYVE60l7N5dw jlTxgxQJtYyYJLYIn7kq74iTny3UHo1cZWM7k5es= From: Harlan Lieberman-Berg To: Peter Gutmann , "mrex\@sap.com" , Colm =?utf-8?Q?MacC=C3=A1rthaigh?= In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C2687E@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20160318170854.CB0801A471@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4C2687E@uxcn10-tdc05.UoA.auckland.ac.nz> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 20 Mar 2016 15:53:30 -0400 Message-ID: <87zitt2af9.fsf@setec.io> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 19:53:34 -0000 Peter Gutmann writes: > This is why I referred to GCM as "brittle", you can be about as > abusive as you like with CBC and the worst you get is degradation to > ECB, while with GCM you make one mistake and you get a catastrophic > loss of security. Couldn't you say the same about CTR mode, or stream ciphers themselves? Sure -- it's definitely a lot harder to screw up "incrementing a counter" than it is all the stuff GCM requires you to do, but.... Sincerely, -- Harlan Lieberman-Berg ~hlieberman From nobody Sun Mar 20 13:19:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C6D12D5AD for ; Sun, 20 Mar 2016 13:18:51 -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 7qbfpU52677N for ; Sun, 20 Mar 2016 13:18:45 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2516812D6EA for ; Sun, 20 Mar 2016 13:18:45 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g127so195458301ywf.2 for ; Sun, 20 Mar 2016 13:18:45 -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=XZDn659U/4dEiVSzt2pa+ixbUAhAHdkYlyxZVz0bunw=; b=dT8fDk6FulPoIYYugEYhsUaTXPGEBSPeN1sm1IEZWHjwNNhRZ5MP7gcxnFD8Eqd9cA K57yE1Ny3LH01rNPofv3zsLuAYvHVfRhQiNhBK3O0q/nkv4+ElnAMg9vvPu3cvpsJe21 UG6sKT2bKBxuo9cIuih5oApgzP8pwsBMmOxHIreo2yBbs5AwSqba1dk1p1cs75rKeI2g sUSkH+Xsh9tM8D73PHv7v0aiXM+SoFGhBaq6nH3iJ2lER+Zwe2ocAhPjSkvl60MkvTqw iQ1vjKINWk/8hCfOHgC+Gg93u/CVEOcRZULBpAVhYb0SucinM8x6+NLljr2oqOnXiSLl yvyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XZDn659U/4dEiVSzt2pa+ixbUAhAHdkYlyxZVz0bunw=; b=Bsrgw+2qPlO3MvVFUv/7m0HFwzXpb36Lv/NHAqe574Epx7f5pe7HVdrENzrhCg5wk+ poe9E+PtTLvKTFD15LlHNGrOhCkWyn5YgHtO9yic5r4ZbjWRoZfHh96SRKALsmYo1YSl viYjNTyVyGCUd43QSKKuaBpya7897ZHVMvySxmmgHX0N73dlaF51OR8AZj7VzpCIxgaX lrlXSDbRRVtFkPB2JyHMvo3rtsM3LHYEVGtMdm9IyFVcQ2gKB/IwBUhCNUpFBNp+O++o dk0NNas1/AshZ+8vBJOetROwNOzAJ0uOWxwUDzHTaxuzgvl1h/P4r2oq9bDI6dKSk0qv OOaw== X-Gm-Message-State: AD7BkJLPwb1ALwSst/lRXmHo8+qwxPpP5s4+pLqH9VBb7DN/Qj1RLis/V1B0MkZqI5InB3SPxlRrIgZImzCdKg== X-Received: by 10.37.230.201 with SMTP id d192mr5933562ybh.159.1458505124271; Sun, 20 Mar 2016 13:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 20 Mar 2016 13:18:04 -0700 (PDT) In-Reply-To: <87zitt2af9.fsf@setec.io> References: <20160318170854.CB0801A471@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4C2687E@uxcn10-tdc05.UoA.auckland.ac.nz> <87zitt2af9.fsf@setec.io> From: Eric Rescorla Date: Sun, 20 Mar 2016 13:18:04 -0700 Message-ID: To: Harlan Lieberman-Berg Content-Type: multipart/alternative; boundary=94eb2c0a876ed63435052e80affa Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 20:18:51 -0000 --94eb2c0a876ed63435052e80affa Content-Type: text/plain; charset=UTF-8 Note: TLS 1.3 should significantly decrease the risk of this because the record sequence number is used as the nonce, therefore if you fail to increment the sequence number, you will quickly not interoperate with other implementations which are correct. -Ekr On Sun, Mar 20, 2016 at 12:53 PM, Harlan Lieberman-Berg wrote: > Peter Gutmann writes: > > This is why I referred to GCM as "brittle", you can be about as > > abusive as you like with CBC and the worst you get is degradation to > > ECB, while with GCM you make one mistake and you get a catastrophic > > loss of security. > > Couldn't you say the same about CTR mode, or stream ciphers themselves? > Sure -- it's definitely a lot harder to screw up "incrementing a > counter" than it is all the stuff GCM requires you to do, but.... > > Sincerely, > > -- > Harlan Lieberman-Berg > ~hlieberman > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a876ed63435052e80affa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Note: TLS 1.3 should significantly decrease the risk of th= is because the
record sequence number is used as the nonce, therefore i= f you fail to
increment the sequence number, you will quickly not= interoperate with
other implementations which are correct.
=

-Ekr


On Sun, Mar 20, 2016 at 12:53 PM, Harlan = Lieberman-Berg <hlieberman@setec.io> wrote:
Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
> This is why I referred to GCM as "brittle", you can be about= as
> abusive as you like with CBC and the worst you get is degradation to > ECB, while with GCM you make one mistake and you get a catastrophic > loss of security.

Couldn't you say the same about CTR mode, or stream ciphers them= selves?
Sure -- it's definitely a lot harder to screw up "incrementing a counter" than it is all the stuff GCM requires you to do, but....

Sincerely,

--
Harlan Lieberman-Berg
~hlieberman

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

--94eb2c0a876ed63435052e80affa-- From nobody Sun Mar 20 16:41:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F95712D643 for ; Sun, 20 Mar 2016 16:41:00 -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 s3UjwwA3i3PK for ; Sun, 20 Mar 2016 16:40:57 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A04012D555 for ; Sun, 20 Mar 2016 16:40:57 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g127so198381186ywf.2 for ; Sun, 20 Mar 2016 16:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NLhTih6fzJ/LlHlLd8lO9o6XQg2b3GsXs60+M2lJ0SA=; b=NzcmGeobteQlj87qdpkTDvbaNOSGKzwFVoZL0PRPV6qlIn3Vs/PZVdD7QowrPI/4M2 4nUVrdhxz/aI0I4lOpaWj498jrLmiUYzNg0IbnaIUW5dkcdCzeqwLToW9/UQlMXyM2tB a7PhQxmUqfdZsgLk4H3e6B064lzXdAXbL+B1ArFPjduX37L+sn7h3G9eg+5n5Ac78dxb TJLhhgsqGosPqDmjCjKrOR1a0N2gBo2fwSl2AHUURxAajJMt0VVUTRXCRsJcfDNhpKPb CWk54/I3rHgI+5WDvJdXwLHfs0AKLSK3UhzYYJR/5XJh7Lqb75ftLNlI1AB5L56ab1/G mbig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NLhTih6fzJ/LlHlLd8lO9o6XQg2b3GsXs60+M2lJ0SA=; b=Igw8GLGL+16FbzcFN+KBbYSiLTtYl+1fdzS6lPZWDId9eNailqzdChhn92SaHDp/jR 6Dlwv0k4DAIIBkixJL2kF6E9vjrlcsG8q981MmaBjZ5sDUUn1qjM7HTdWPwx10Zv5rux zRBYy87AxN5rmAhKnL5hncq3TdRqPnXaJcV5Fxxl4tfwHQAjLws818nqXMsvIGDWyVyV oS2sZMF4VaQqdLemm9nxDJCdo2q+fBPGNtRLsbbKY4cfaEt1BToP90mVgds1Pbvos5Nl yuNPz6OTciartjTtUE2amFY9uwxDeZHeQt0Us5qs6NUvA6v0TYkpvA4KOP0b4H9ggl3X ZUMQ== X-Gm-Message-State: AD7BkJKiA2TKu6660+FQ5Vm3a/NG0JOLkiqeHMtx9IhidAZ/ARW27E5oWQVtzXsA8wN0UbGw1alrebA39KD6qg== X-Received: by 10.37.95.70 with SMTP id t67mr12742861ybb.82.1458517256744; Sun, 20 Mar 2016 16:40:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 20 Mar 2016 16:40:17 -0700 (PDT) In-Reply-To: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> From: Eric Rescorla Date: Sun, 20 Mar 2016 16:40:17 -0700 Message-ID: To: aluykx Content-Type: multipart/alternative; boundary=001a11423c44fce275052e838298 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Data Volume Limits Analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 23:41:00 -0000 --001a11423c44fce275052e838298 Content-Type: text/plain; charset=UTF-8 Atul, Kenny, Thanks for doing this. My initial impression is that these results are uncomfortably close to the line for AES-GCM, especially for the scenario where we have multiple keys: there are probably well upward of 2^{32} HTTPS connections a day. A few questions: 1. As I understand it, failure in these models is fairly catastrophic, so I should be reading Table 1 as "chance of total collapse of confidentiality", not "chance of being able to read one plaintext" value. Is that correct? 2. Are there available proofs for a non-chosen plaintext context? This seems to bear on the multiple key question: it seems plausible that an attacker could capture a very large number of AES-GCM encrypted connections passively, but collecting a huge number of AES-GCM connections where it gets to specify the plaintexts seems more challenging, even with BEAST-style attacks. 3. Naively, from equation 5, it seems like as \sigma >> q you should be able to encrypt rather more submaximal (e.g., 1K) records than maximal size records. Finally, and this calls for an opinion: do you believe that given these results we should include a KeyUpdate feature in TLS 1.3? Thanks, -Ekr On Tue, Mar 8, 2016 at 2:16 PM, aluykx wrote: > Kenny Paterson and I prepared a document providing an overview of how much > data ChaCha20+Poly1305 and AES-GCM can process with a single key. Besides > summarizing the results, the document also gives an explanation of why the > limits are there. The document confirms the analysis done by Watson and > others in the thread on "Data Volume Limits", but goes into more detail. > > The document can be found on Kenny's website: > http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf > > Atul Luykx > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11423c44fce275052e838298 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Atul, Kenny,

Thanks for doing this. My = initial impression is that these results are uncomfortably
close = to the line for AES-GCM, especially for the scenario where we have multiple=
keys: there are probably well upward of 2^{32} HTTPS connections= a day.=C2=A0

=C2=A0A few questions:
1. As I understand it, failure in these models is fairly catast= rophic,
so I should be reading Table 1 as "chance of total c= ollapse of confidentiality",
not "chance of being able = to read one plaintext" value. Is that correct?

2. Are there available proofs for a non-chosen plaintext context? This se= ems
to bear on the multiple key question: it seems plausible that= an attacker could
capture a very large number of AES-GCM encrypt= ed connections passively,
but collecting a huge number of AES-GCM= connections where it gets to
specify the plaintexts seems more c= hallenging, even with BEAST-style
attacks.

3. Naively, from equation 5, it seems like as \sigma >> q you shou= ld be able
to encrypt rather more submaximal (e.g., 1K) records t= han maximal size
records.


Finally, and this calls for an opinion: do you believe that given these re= sults
we should include a KeyUpdate feature in TLS 1.3?

Thanks,
-Ekr



On Tue, = Mar 8, 2016 at 2:16 PM, aluykx <Atul.Luykx@esat.kuleuven.be&= gt; wrote:
Kenny Paterson and I pr= epared a document providing an overview of how much data ChaCha20+Poly1305 = and AES-GCM can process with a single key. Besides summarizing the results,= the document also gives an explanation of why the limits are there. The do= cument confirms the analysis done by Watson and others in the thread on &qu= ot;Data Volume Limits", but goes into more detail.

The document can be found on Kenny's website:
http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf

Atul Luykx

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

--001a11423c44fce275052e838298-- From nobody Sun Mar 20 17:27:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2D5112D7E3 for ; Sun, 20 Mar 2016 17:27:52 -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=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 aJNVwWC8_56u for ; Sun, 20 Mar 2016 17:27:51 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA01312D5B7 for ; Sun, 20 Mar 2016 17:27:50 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id d82so52032462lfe.3 for ; Sun, 20 Mar 2016 17:27:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UcuOITJhm+ReiMVud75Fa5QXP7jC7xaWJTYFAJv2sVM=; b=UxWA/0fSK6BsYmiKZEP6NdUWuU7vx3YjTWSXffQ+e751ZuJpaOGwas9BohLqa/+s1p goLyuLWtKs+e5Iz7tgsuKWwDCxYSPHPXIv4tMZIqsnlp0pVS5ARVfZBAUAdeKUksogpx /jQJZgyPZsMm6uaNvmqPfswpwBo+aoVq4WIHtFUurJC0lqCTCKPOpHQAur7E/vtNYmU/ gzF01MQD6yO4Hn1xMq/PVfVtCEZd+PfuhPfus4+9k6U9bsYGQBNPbdmyX8rB7NvRFrSK WuI6FC1IhZuYpX7YjrTJiEjmBNwEwMGfP/7iYVXLcjYlWWH6So0MNedESbfrNrCeBpLy Ru6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UcuOITJhm+ReiMVud75Fa5QXP7jC7xaWJTYFAJv2sVM=; b=XsT66O/rfrYbHZy8g1cXk9MiPHKVM1QAW83wxNFsogp2KhMCRgV361r1PDJ+tTJZVx Lz6frUdcrqFWrGXHQWCJQZtiL1rO9ZRtuZC2rzgjUEPKK4Vh2vlXJS68WznQhglCdLpJ ln6nqtWpV8+TOkzNO/uaS0kVcXO8DmOX2TtD8gphDpggsL8nFooV+t4rwRTJEpar2wpK IQ2UfIMnyC1PPVbNzHcsTvAJvVCwCKzlyqukREcGNfaU91f6ecuw0A+U93X+SwoZy5tI EAfnW4tOfWKgKQpr+FVn9J6Odwp6ppYs0q0S4ff1gteqmrLCco09k5UiGaIHVUrsEmui T6NA== X-Gm-Message-State: AD7BkJIH62SCaXo5JODh+F4euaOULW/KNzi/dL/Yj/cMKOzsH4U1eOJOzdQCoSS1orBhEJ8psF32OROEa4SDEw== X-Received: by 10.25.78.80 with SMTP id c77mr10626169lfb.62.1458520068928; Sun, 20 Mar 2016 17:27:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.2.104 with HTTP; Sun, 20 Mar 2016 17:27:29 -0700 (PDT) In-Reply-To: References: <201601152007.12464.davemgarrett@gmail.com> <20160317173436.GA19169@LK-Perkele-V2.elisa-laajakaista.fi> From: Joseph Salowey Date: Sun, 20 Mar 2016 17:27:29 -0700 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114194e49b503b052e842abf Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 00:27:53 -0000 --001a114194e49b503b052e842abf Content-Type: text/plain; charset=UTF-8 No objection, it looks good. I don't see any objections on the list so I say merge it. On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla wrote: > It sounds like we have general consensus here. Does anyone object to my > merging > this PR? > > -Ekr > > > On Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > >> On Tue, Mar 15, 2016 at 05:37:20PM +0000, David Benjamin wrote: >> > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: >> > >> > >> > I would probably characterize it less as suites vs orthogonality, but as >> > wanting to keep divisions in meaningful and universal places and not >> > splitting up tightly-coupled decisions. The flexibility from >> orthogonality >> > can be handy, but going too far---as I believe TLS 1.2 did with >> signature, >> > prehash, and curve---complicates everything. Imagine if negotiating >> > AES_128_GCM required separately negotiating block cipher AES-128, mode >> CTR, >> > and MAC GHASH. >> >> It isn't even orthogonal, it is coupled, which is way worse and quite >> difficult to implement correctly. >> >> I now consider the way TLS 1.3 draft / RFC4492bis draft currently does >> EdDSA negotiation a bad idea (what is proposed here is vast improvement). >> >> >> -Ilari >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114194e49b503b052e842abf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
No objection, =C2=A0it looks good.=C2=A0 I don't see a= ny objections on the list so I say merge it. =C2=A0

On Sun, Mar 20, 2016 at 10:50 AM, E= ric Rescorla <ekr@rtfm.com> wrote:
It sounds like we have general consensus here. Does = anyone object to my merging
this PR?

-Ekr


On Thu, Mar 17, 2016 at 10:34 = AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:=
On Tue, Mar 15, 2016 at 05:37:20PM= +0000, David Benjamin wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> I would probably characterize it less as suites vs orthog= onality, but as
> wanting to keep divisions in meaningful and universal places and not > splitting up tightly-coupled decisions. The flexibility from orthogona= lity
> can be handy, but going too far---as I believe TLS 1.2 did with signat= ure,
> prehash, and curve---complicates everything. Imagine if negotiating > AES_128_GCM required separately negotiating block cipher AES-128, mode= CTR,
> and MAC GHASH.

It isn't even orthogonal, it is coupled, which is way worse and = quite
difficult to implement correctly.

I now consider the way TLS 1.3 draft / RFC4492bis draft currently does
EdDSA negotiation a bad idea (what is proposed here is vast improvement).

-Ilari


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


--001a114194e49b503b052e842abf-- From nobody Sun Mar 20 18:11:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE4D12D6C5 for ; Sun, 20 Mar 2016 07:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VpMWk1cwQjh for ; Sun, 20 Mar 2016 07:38:23 -0700 (PDT) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 8B1E2127058 for ; Sun, 20 Mar 2016 07:38:21 -0700 (PDT) Received: (qmail 516 invoked by uid 1017); 20 Mar 2016 14:38:46 -0000 Received: from unknown (unknown) by unknown with QMTP; 20 Mar 2016 14:38:46 -0000 Received: (qmail 20818 invoked by uid 1000); 20 Mar 2016 14:33:55 -0000 Date: 20 Mar 2016 14:33:55 -0000 Message-ID: <20160320143355.20816.qmail@cr.yp.to> From: "D. J. Bernstein" To: tls@ietf.org Mail-Followup-To: tls@ietf.org In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Sun, 20 Mar 2016 18:11:31 -0700 Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 20 Mar 2016 14:38:26 -0000 Peter Gutmann writes: > compressed points are patented Which patent are you referring to? US 6141420, I suppose. Let's ignore the question of what's in the prior art (1992 Harper--Menezes--Vanstone) and what's actually claimed in the patent. Are you aware that this patent expired in July 2014? > Everything uses uncompressed points at the moment without any problems The same way that everyone uses C and C++ without any problems? https://www.nds.rub.de/research/publications/ESORICS15/ completely broke two implementations of uncompressed (x,y) ECDH in TLS. The problem, of course, is that the implementors forgot to check that the input (x,y) was on the curve. OpenSSL _does_ try to check, but it seems that this check is sometimes affected by recently announced bugs in OpenSSL's carry handling. The impact isn't clear---analyzing this sort of thing is very difficult. Using compressed (x,y) significantly reduces the amount of rarely tested checking code for the implementor to screw up. More importantly, there's a third option (introduced in Miller's original ECC paper), namely using just x-coordinates. Section 4.1 of https://cr.yp.to/papers.html#nistecc explains how X25519 uses this third option to proactively and robustly avoid this type of attack. ---Dan From nobody Sun Mar 20 19:19:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7167B12D552 for ; Sun, 20 Mar 2016 19:19:21 -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 sG_dVyvuEWvG for ; Sun, 20 Mar 2016 19:19:19 -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 A440712D52F for ; Sun, 20 Mar 2016 19:19:19 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g127so200872427ywf.2 for ; Sun, 20 Mar 2016 19:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y04j1E9Rv04u5iRdGqIk/EvH7wBAEndSc1gX9rvo3Kk=; b=PiQ9ZDDh9isdE7JhgaviCVGpcReovRlggzvI/ZYWf+KqL9CohsOFWnp8RjHQ0QBuw0 XxUW2B8fdq5slSUH8UphTBNZz75brgv79obJ5VjyT9FmxLg641q0+JhJvK2nJfjD9ui7 9mJlwTPaxKoEtlldGweiA8zJivZ1ESPRAW7mSS7BMHretT1BZ82LqW5uOUqNIw5bz1O8 EKy4FoCGluWGwaWevHU38OMwFoEzwWZJ07eeg2MqZ1DpB0oymj2QKanpr6uVqgnZorCc JiwJ7+oSEHs7ERIDV3dtWgqLlXt/QjsrvSVSrbDw2GUAFGYiRpqT8VsKgNnHvbS058VP 2qRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y04j1E9Rv04u5iRdGqIk/EvH7wBAEndSc1gX9rvo3Kk=; b=ODjW286aWfaABGs1ubRzuwtNdXQIqXSS88XeQ6zDhWMauBNgcRIYm/2dBIpUC3haw8 mqybhIEX3BvL+jterM2hXT+R53f/IKetp1uPOyKi3Py8KZSS09checE19KXrLx289U8n uXiBdpN8L5LRUVpbZ/uML5GskH9VSpv/7ipPJiN2EMxlVsvADGyek8+HS4gnIzGVyP/R TrGj91MmExqbe9SlMf1v5w19MY69eeY2S8TSMTGzujWBcK0Lp4o/nuGGsPxkuO8q+AI8 7ZBmSHrgJ9MJqeey37Ph3BLQDRaBafQInf+oZB+dadYHJIAkXnk40TvlutwwIIoreWes GH6Q== X-Gm-Message-State: AD7BkJIEp7U6GFk4Pn92/LrPLM8S8bhjeyoi/r7eMDbAcBySkpE6zt71voyRUXd8AEuMvseZGt9lBiyKc93CKg== X-Received: by 10.37.38.197 with SMTP id m188mr11927205ybm.162.1458526758791; Sun, 20 Mar 2016 19:19:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 20 Mar 2016 19:18:39 -0700 (PDT) In-Reply-To: References: <201601152007.12464.davemgarrett@gmail.com> <20160317173436.GA19169@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sun, 20 Mar 2016 19:18:39 -0700 Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a1143b77e5a9f3a052e85b946 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 02:19:21 -0000 --001a1143b77e5a9f3a052e85b946 Content-Type: text/plain; charset=UTF-8 Acknowledged. This will be in draft-12. On Sun, Mar 20, 2016 at 5:27 PM, Joseph Salowey wrote: > No objection, it looks good. I don't see any objections on the list so I > say merge it. > > On Sun, Mar 20, 2016 at 10:50 AM, Eric Rescorla wrote: > >> It sounds like we have general consensus here. Does anyone object to my >> merging >> this PR? >> >> -Ekr >> >> >> On Thu, Mar 17, 2016 at 10:34 AM, Ilari Liusvaara < >> ilariliusvaara@welho.com> wrote: >> >>> On Tue, Mar 15, 2016 at 05:37:20PM +0000, David Benjamin wrote: >>> > On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla wrote: >>> > >>> > >>> > I would probably characterize it less as suites vs orthogonality, but >>> as >>> > wanting to keep divisions in meaningful and universal places and not >>> > splitting up tightly-coupled decisions. The flexibility from >>> orthogonality >>> > can be handy, but going too far---as I believe TLS 1.2 did with >>> signature, >>> > prehash, and curve---complicates everything. Imagine if negotiating >>> > AES_128_GCM required separately negotiating block cipher AES-128, mode >>> CTR, >>> > and MAC GHASH. >>> >>> It isn't even orthogonal, it is coupled, which is way worse and quite >>> difficult to implement correctly. >>> >>> I now consider the way TLS 1.3 draft / RFC4492bis draft currently does >>> EdDSA negotiation a bad idea (what is proposed here is vast improvement). >>> >>> >>> -Ilari >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --001a1143b77e5a9f3a052e85b946 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Acknowledged. This will be in draft-12.

On S= un, Mar 20, 2016 at 5:27 PM, Joseph Salowey <joe@salowey.net> wrote:
No objection, = =C2=A0it looks good.=C2=A0 I don't see any objections on the list so I = say merge it. =C2=A0

On Sun, Mar 20, 2016 at 10:50 AM, Eric Resc= orla <ekr@rtfm.com> wrote:
It sounds like we have gene= ral consensus here. Does anyone object to my merging
this PR?

-Ekr


On Thu, Mar 17, 2016 at 10:34 AM, I= lari Liusvaara <ilariliusvaara@welho.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Tue, Mar 15, 2016 at 05:37:20PM +000= 0, David Benjamin wrote:
> On Mon, Mar 14, 2016 at 8:22 PM Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> I would probably characterize it less as suites vs orthog= onality, but as
> wanting to keep divisions in meaningful and universal places and not > splitting up tightly-coupled decisions. The flexibility from orthogona= lity
> can be handy, but going too far---as I believe TLS 1.2 did with signat= ure,
> prehash, and curve---complicates everything. Imagine if negotiating > AES_128_GCM required separately negotiating block cipher AES-128, mode= CTR,
> and MAC GHASH.

It isn't even orthogonal, it is coupled, which is way worse and = quite
difficult to implement correctly.

I now consider the way TLS 1.3 draft / RFC4492bis draft currently does
EdDSA negotiation a bad idea (what is proposed here is vast improvement).

-Ilari


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



--001a1143b77e5a9f3a052e85b946-- From nobody Sun Mar 20 23:17:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50C812D69E for ; Sun, 20 Mar 2016 23:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GM_zkP-MR1zr for ; Sun, 20 Mar 2016 23:17:40 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB31312D695 for ; Sun, 20 Mar 2016 23:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458541060; x=1490077060; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=B9UCCuRWEmlEKPKT6gs7jvFjfU0RipHqCpZL4PoflGY=; b=gfAmTtUdseq6ET6ms7D6Wz9ftYGFZRlZftIoVlyXNWDSIpCvcNJt+Aki 53bbde36c583SM/DKf7UkWHO5ragUFyw0rxaDSRhwGAFvUFKqCgB1/WAT lbsTKQe5JSuvf6SC5CKaca7lFRFJp49iAKh/Yal0BP9FkJ/N8885FXLA8 x3/eIz1bcDeniRhp0IYAppvEmJ3L+khFV5aqpG6n04QPhg+QX2cUmFGwH uwLaySfJPkO1MTzyrevokfPvf5jDUk2ZkyNJrwbDX2dNLq3nWxH3J/SRa nQUgJz36ay0rzRSafgqoYNqJQHMZS/0EJycQ41Q0Q+8aD2NY7ew9i9X2u w==; X-IronPort-AV: E=Sophos;i="5.24,370,1454929200"; d="scan'208";a="75522693" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Mar 2016 19:17:38 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Mon, 21 Mar 2016 19:17:38 +1300 From: Peter Gutmann To: Karthikeyan Bhargavan Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egCSfaaAACoKC6r//3MHgIAA5Mgg//8p5wCAAOOLT///KsoAgAH9h3w= Date: Mon, 21 Mar 2016 06:17:37 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C28374@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27A2B@uxcn10-tdc05.UoA.auckland.ac.nz>, <26C23DDE-0BE5-486F-B6EB-FD181E2EDFEF@gmail.com> In-Reply-To: <26C23DDE-0BE5-486F-B6EB-FD181E2EDFEF@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 06:17:44 -0000 Karthikeyan Bhargavan writes:=0A= =0A= >Yes, I=92d suggest hashing in the log up to ServerHello, or if you don=92t= want=0A= >to clone the hash state, then maybe the log up to ServerCertificate.=0A= =0A= OK, I've posted another update that specifies this, as well as use of EMS, = and=0A= cleans up a few other areas. It's a bit of a rush job because of the=0A= impending lockdown for IETF 95, but hopefully the gist is there:=0A= =0A= http://www.ietf.org/id/draft-gutmann-tls-lts-02.txt=0A= =0A= Peter.=0A= From nobody Sun Mar 20 23:20:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 748B612D675 for ; Sun, 20 Mar 2016 23:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blAgrkVWeKHP for ; Sun, 20 Mar 2016 23:20:44 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3575E12D603 for ; Sun, 20 Mar 2016 23:20:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458541244; x=1490077244; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NsJpxd0ZSB/ZXBU2Izts/38AV3W07J/51q+7paX1cDM=; b=25zdx4V4PtttSKRAitEiIx8FOPgKgRPjAy/KHWiJvLn5I9HCV7M74yLu 9B4GPURYux9GV+U/5w3wBYmTnlhUCP8zFVHgSA4/Op3TeEZpG9RfoOJPa j2DU7QvC4FAM5rqCQSHS+wTFrgujqI7nKA8G069EPQEu3WJ7ZVxXQ1UZ4 gbJXm6VeFuwV2iIX4jOCdR7++HwHUWS9uJO3bIfUjWxf2LvJcZH+YTKs0 5r/LrdNJUC3c8iwJLgOwOjh8C28C/sxN4o7ph3aBtrKRzNH18s9+4OdOB ZsFxvruKhos/630ZebXTEXa8vMZfQ9aiDZp/DP9zstwPvFr56+j1tDh/r g==; X-IronPort-AV: E=Sophos;i="5.24,370,1454929200"; d="scan'208";a="75523174" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Mar 2016 19:20:43 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Mon, 21 Mar 2016 19:20:42 +1300 From: Peter Gutmann To: Harlan Lieberman-Berg , "mrex@sap.com" , =?iso-8859-1?Q?Colm_MacC=E1rthaigh?= Thread-Topic: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? Thread-Index: AQHRf6/SV1Ay+QdHmEWVtQKTdggsTJ9bixwAgAMNSQCAAUr1TIACB7IAgAGJD/o= Date: Mon, 21 Mar 2016 06:20:41 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C28389@uxcn10-tdc05.UoA.auckland.ac.nz> References: <20160318170854.CB0801A471@ld9781.wdf.sap.corp> <9A043F3CF02CD34C8E74AC1594475C73F4C2687E@uxcn10-tdc05.UoA.auckland.ac.nz>, <87zitt2af9.fsf@setec.io> In-Reply-To: <87zitt2af9.fsf@setec.io> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Are the AEAD cipher suites a security trade-off win with TLS1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 06:20:45 -0000 Harlan Lieberman-Berg writes:=0A= =0A= >Couldn't you say the same about CTR mode, or stream ciphers themselves?=0A= =0A= Yep, the KSG ciphers are all equally bad, just RC4 in another form.=0A= Microsoft, and the downstream users of its APIs, were do badly burned by th= is=0A= over and over again that their build tools now flag any use of RC4 as a=0A= security failure.=0A= =0A= Peter.= From nobody Mon Mar 21 01:21:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE28F12D6EF for ; Mon, 21 Mar 2016 01:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUXPkNo1DJbl for ; Mon, 21 Mar 2016 01:21:43 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D14412D6D8 for ; Mon, 21 Mar 2016 01:21:43 -0700 (PDT) Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 779E9206E8; Mon, 21 Mar 2016 09:21:40 +0100 (CET) Message-ID: <56EFAF13.3070203@secworks.se> Date: Mon, 21 Mar 2016 09:21:39 +0100 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Tom Ritter References: <98D69E40-44F4-4BA0-83F6-1B804B4AABB7@shiftleft.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Cc: klimn@di.uoa.gr, Efthymios Iosifides , "tls@ietf.org" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 08:21:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Tom Ritter wrote: > On 17 March 2016 at 21:09, Martin Thomson > wrote: >> On 18 March 2016 at 12:37, Mike Hamburg >> wrote: >>> No. The goal should be to remove ciphers, not add new ones, >>> unless we have a really compelling reason. >> A necessary, but sufficient set of reasons might include: >> >> 1. thorough cryptanalysis 2. advantages over existing ciphers on >> important metrics like security and speed, though this would likely >> need to be significant at this point 3. interest in implementation >> >> Speck is 0 from 3. > > I might make it .5 for 3. Speck is specifically designed to be a > lightweight cipher for constrained devices. With RC4 dead in the > water - we don't have one of those. (Unless ChaCha20 is better than > Speck/Simon/related...) ChaCha20 was not explicitly designed to be lightweight. That said, it is fairly compact and get good performance on smaller architectures. Even though the internal variables ate 64-bit, the ARX operations are easy to map to smaller registers. The closely related Salsa20 cipher requires about 5 cycles/byte on ARM: https://www.hyperelliptic.org/tanja/vortraege/20121129.pdf But if we wanted algorithms optimized for embedded, small architectures we could look at the ECRYPT eSTREAM profile 2 ciphers: http://www.ecrypt.eu.org/stream/ AFAIK they did get a fair amount of analysis. - -- Med vnlig hlsning, Yours Joachim Strmbergson - Alltid i harmonisk svngning. ======================================================================== Joachim Strmbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW768TAAoJEF3cfFQkIuyNI6kQAJqE8LL0RJl4hZGufq/qeMId q4t6m+kHLu0mZhufNUAs15yMz5XA4El0ZBOKuNml4sUUYRZWyUCinALjXvJ6gxEV jptsj9XiEKYGrmIOjOZxBo85oeKYgDKDvvXmgS5BWmsOFzvjTteuIV2udwEzydWo yWoHmYba47vI/R6GwNLykkaum3dYpYuZQtcRYHZO34/+asxcmhDydR03iYKOJWM6 EG1HyT2Wc9nzeXifzp21IdMFYe67IFz3E9/0YLExyInBA2ZCE1/ziQn/m2ZpSsBN DFjp6Rg3U6FkcvJ9f/xz0ltG5rp5+NZAGfzc5rcRNZ3sZfF1DbyV9bCcppWngjmd /7HYuzAWoveMmxcWU64ClFdUhkyMDyeBd3gRDq74GWXjHszZifFNxtEG2IKclqco HmrP7OWdEpeaaSF1EmKZwSjwNlpWD7OAYykTYoRqtETF4hzj2jqniFuG+QEy7MsS 9oMnI2ojNVkfDISlWmeDDIXEnH5m/RHQqXqK9YQwSM/YDz1mGidQjjJm576+M10y Ok9v/WswIuqwATtfKX8AWXci1YojwhY9iBegTDawphwRLtV11JRsY0C+iUD1xjJ3 Jywlx7d+HDZ0XX10NJS80FhJE9wzo12F93fntGlKsLDPzKhtiQfmulY4RFrr/LlU INSG+VzHMYQmPAjTVDCc =2IW+ -----END PGP SIGNATURE----- From nobody Mon Mar 21 02:24:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA73312D664 for ; Mon, 21 Mar 2016 02:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKudS9WiERBG for ; Mon, 21 Mar 2016 02:24:38 -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 B0B7012D5C2 for ; Mon, 21 Mar 2016 02:24:38 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 09027711CA; Mon, 21 Mar 2016 09:24:38 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.171]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2L9OZKJ015809 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Mar 2016 05:24:37 -0400 Message-ID: <1458552275.3008.25.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Watson Ladd Date: Mon, 21 Mar 2016 10:24:35 +0100 In-Reply-To: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2682D@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 21 Mar 2016 09:24:38 +0000 (UTC) Archived-At: Cc: "" Subject: Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 09:24:41 -0000 On Sat, 2016-03-19 at 07:51 -0700, Watson Ladd wrote: > On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann > wrote: > > > > Watson Ladd writes: > > > > > > > > Then use a padding extension that solves all problems, instead of > > > relying on > > > a side effect of CBC mode. > > It's not a "side-effect of CBC mode", CBC mode allows padding > > packets, GCM > > doesn't, see Colm MacCárthaigh's recent post on the topic. > GnuTLS is the only implementation that pads to more than 16 byte > boundaries This is no longer true. We disabled that feature few years ago since it was the main cause for several compatibility failures. The failures were with other broken implementations, but no-one cares who is at fault if the session doesn't work. regards, Nikos From nobody Mon Mar 21 02:57:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA4F12D5BE for ; Mon, 21 Mar 2016 02:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] 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 j0be0BttMRJf for ; Mon, 21 Mar 2016 02:57:50 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3EE12D6F7 for ; Mon, 21 Mar 2016 02:57:49 -0700 (PDT) Received: from mail-lf0-f50.google.com ([209.85.215.50]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0Mg0zl-1aTJU626on-00NRe9 for ; Mon, 21 Mar 2016 10:57:47 +0100 Received: by mail-lf0-f50.google.com with SMTP id e196so28622928lfg.1 for ; Mon, 21 Mar 2016 02:57:47 -0700 (PDT) X-Gm-Message-State: AD7BkJL32scTFdQO1JznXPxi18FEGr422/cd72BXIqukgDbf5Kjmjyi1TpuuzoDyQdX5Cxn63nBQ0lpjIJVtJQ== MIME-Version: 1.0 X-Received: by 10.25.135.8 with SMTP id j8mr10461755lfd.64.1458554266897; Mon, 21 Mar 2016 02:57:46 -0700 (PDT) Received: by 10.112.22.67 with HTTP; Mon, 21 Mar 2016 02:57:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Mar 2016 10:57:46 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: Watson Ladd Content-Type: multipart/alternative; boundary=001a113fc32cf6d2db052e8c203b X-Provags-ID: V03:K0:RsrgP0mTLB7316DgyKUb/KmMfUyagqrzq65NoYQl2U2qPM7zzuW +wWEFWixBZGNrXeTVTBI/XanerYH5CSCgqnXvAeCpU3gwifqI1xwKf+RjJnuIzgnNlOA83F S721klbaJpuNLn2hbxpYKmyKMtgEc1V5+rqleewZaeSWUveiJgZufIJN1EsZu714wOA260q NjgKLtIa20c98uePH6Ifw== X-UI-Out-Filterresults: notjunk:1;V01:K0:PqRBtMMvY1Q=:z8Jw+MbeZTI79r0dFV+uqS py82i3swNLRBaqdfY3S9Y7HJ+gKQmvSC+sz2WUVuXHKnOcO5mNq4i4vS01feQ4CTlAlTfH/LY Y92Cbg9auwukE7qgoycZ39RiCnDJuVNREREI3hZe/vQ8t3l746K/YV0ENQ7NuZSa115QEu2ef hU6bt1dJASiXZQe32r8o9T191S5sgfD6VQ+4VpBAKZqwDfWhWUkXFjFr5jiAM3Dc9tsYnkWxI xqnbgNGgIIzJoKQuAEeEsDZd3X1oFXXG1IJCD335yNIvv2E+0XIKAdYSe+UXaY4drUANmHA0L PBONzGN8TP48q0/MOZRJp3eXB9wJurJjrjRXAL3/GGQs/67MVpCU8DFlwrrWXW66cf43cChg9 JzJF85h7KD3WyOou5SLrGAe+OfCY4AiIcIwBqiWKJYfKV0xsHO9V2IMD4YnA+o5se5bL97w8c uN5FotodWYhszhwbsm+KfG9MeR8L1HNhL1Ex8F9Imtv1Uvl/UvA/HgbDcj1b+NW6FIVqKsHAr vlAUY0Q12SLv8P5em5s7lS7ngJhbfAWFNxH8FKV/1sys6HUQ83ZGuaMJSsBk66l0HDL0eThx/ Z8Gh8OxdWK0f8qPBRHNyi5uvZKoW/V155j+icdLNxUyY62iSpRJBvoabzPNvm4jE/AvPsZwJn jzbk6w0RSr+/7ovnd3Te4dUTIRuEYOSUbe7QjhjdNcXuHi3bFjj7YIMoSD6AWyDm2WYzYyRvt cr1ixxRZZXsxqu+W Archived-At: Cc: "" Subject: Re: [TLS] History of TLS analysis (was Re: TLS 1.2 Long-term Support Profile draft posted) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 09:57:53 -0000 --001a113fc32cf6d2db052e8c203b Content-Type: text/plain; charset=UTF-8 Watson Ladd : The use of predictable IVs in TLS 1.0 was first commented on by > Rogaway in 1995. (I'm hunting down the source, but this is from a > presentation of Patterson) I think you mean http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipsec-comments-00.txt, which discussed the problem of predictable IVs in the context of work towards IPSEC, without making the connection to SSL. Note that this was before TLS 1.0 and, I think, before SSL 3.0. SSL 2.0 already had predictable CBC IVs but placed the MAC before the payload in the to-be-encrypted data, which, through sheer luck, avoided the problem. Bodo --001a113fc32cf6d2db052e8c203b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wats= on Ladd <watsonbladd@gmail.com>:

The use of predictable IVs in TLS 1.0 was first commented on by
Rogaway in 1995. (I'm hunting down the source, but this is from a
presentation of Patterson)

I think you mean= http://web.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ips= ec-comments-00.txt, which discussed the problem of predictable IVs in t= he context of work towards IPSEC, without making the connection to SSL.=C2= =A0 Note that this was before TLS 1.0 and, I think, before SSL 3.0.=C2=A0 S= SL 2.0 already had predictable CBC IVs but placed the MAC before the payloa= d in the to-be-encrypted data, which, through sheer luck, avoided the probl= em.

Bodo

--001a113fc32cf6d2db052e8c203b-- From nobody Mon Mar 21 04:29:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B34612D70D for ; Mon, 21 Mar 2016 04:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNM3GzfgQH51 for ; Mon, 21 Mar 2016 04:29:30 -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 956D512D554 for ; Mon, 21 Mar 2016 04:29:30 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 117A07F0AD; Mon, 21 Mar 2016 11:29:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LBTSC6028250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 07:29:29 -0400 From: Hubert Kario To: Peter Gutmann Date: Mon, 21 Mar 2016 12:29:27 +0100 Message-ID: <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart37404067.nBxsATmIGf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 11:29:32 -0000 --nextPart37404067.nBxsATmIGf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Saturday 19 March 2016 09:30:26 Peter Gutmann wrote: > Hubert Kario writes: > >also, if it really is supposed to be Long Term Support, why it > >doesn't say anything about implementation explicitly being able to > >handle big key sizes? both RSA and DHE? >=20 > I've deliberately avoided getting into that because it's such a > rathole, you've got everything from the NIST numerologists at one > extreme to the "good enough for now" folks at the other, and you'll > never get any consensus because there are completely different > worldviews involved. A possible median is: >=20 > Implementations SHOULD choose public-key algorithm key sizes that are= > appropriate for the situation, weighted by the value of the > information being protected, the probability of an attack, and the > ability of the hardware to deal with large keys. For example a SCADA= > system being used to switch a ventilator on and off doesn't require > anywhere near the keysize-based security of a system used to transfer= > classified information. One way to avoid having to use very large > public keys is to switch keys periodically. This can be done by > regenerating DH parameters in a background thread and rolling them > over from time to time, or if this isn't possible, by pre-generating > a selection of DH parameters and choosing one at random for each new > handshake, or again rolling them over from time to time. Note that I asked for "being able to handle", not "selects and uses". Yes, server which now uses 2048 bit DH parameters now is fine. It's not= =20 like it will use RSA keys that are any stronger, but it should be=20 possible for the administrator to tell it to use 4096 bit (probably=20 larger). Similarly, implementation shouldn't halt and catch fire if the= =20 server gives it big asymmetric keys. It's not Long Term otherwise. > >I might have missed, but where is the specification of the acceptabl= e > >signature algorithms (hash especially) on Server and Client Key > >Exchange messages? >=20 > That's implicit in the cipher suites, RSA or ECDSA + SHA256. no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1. of= =20 RFC 5246, you need to be explicit about it. I really don't see the upside for decreasing the number of extensions=20= the Client Hello carries. The implementation will need to interoperate=20= with normal (i.e. already deployed) TLS 1.2 implementations anyway, why= =20 prevent code reuse? =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 99/71, 612 45, Brno, Czech Republi= c --nextPart37404067.nBxsATmIGf 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 iQIcBAABCgAGBQJW79sXAAoJEJKo0bgB0vX1g1YQAJ0XMi2Otd8mx8y/Wrvm8Cw9 8jrsymHAnx2n3bocszDfpSyzPlIbVZwF4UEet4zkgExTm/rUouc9D13WWYsincef ytM26kuKWS5/iOTP32U9sWJeoca8fHKtgN4LKqVQryXnAbrfkvj29t+XzW4t2Rts mk8HVgRE2Dw8GFOHLVpimZosf58+JenoO+mBgUK1dY5Kv614VZ9ia+LrnVLjsS/z 4I85okrf5ijUcpsLNLUCQvxa8Hnf8qpc3tIvxzGCRLnW0LXPeyE21H5FnOjwwoJe q4EVWUjOWLzoLqoImJEGdAh+sHI59YPIWUM4Pjg/41qV5mURUfR8w5z2TGfzxRfW n+rj9GxZGtOzkgvc9w+oqeIcpGSZmzqPFSNfuRYTWWR3gvRB4RLigHGPD7LjJ4lx /W8gUa3na1IDoByNwXFtyXHgUVmbzvDH4Kd+/O/nNrIMrwlnhnTrM9TQodxkvUT0 k4rcfM5SE4CoGAtS4nRr/Gj9+2cehQf4+33pZ1hf67aZBhpXUVGqeDO6Hc0nbjW5 IW6IGyaIVj+AQTaxxQ8FgFnRmsLiI/0GCxBrp71nvJBAOdH/n3ZTwO6RdNxVJjne nI7wkurPPRGO81CCHPt/9WXypivhc0+Jq4UbKzzuGzAVNcc3bHSJOYXYQd55dNFg 4J4p64Ngd6vSnMhUHKmO =N3hc -----END PGP SIGNATURE----- --nextPart37404067.nBxsATmIGf-- From nobody Mon Mar 21 05:43:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61D612D770 for ; Mon, 21 Mar 2016 05:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QML2XKkyXiyC for ; Mon, 21 Mar 2016 05:43:21 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F4012D748 for ; Mon, 21 Mar 2016 05:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458563729; x=1490099729; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=HmKpoMpO9UNzcP04iRCfz/R/LyDE5SSE8u1S4Stm9Bg=; b=RE4w0j1exPphH68/5jcMdpY2BCFkPHXWDfKTsVcObVjmgP7annRmgo56 WHzrXwuZvDjz2cIt/qPi8sNcNilPIkgE5HTWi40OcH9o9N/kUR1RCW6O6 n8BSAuzf75U/LTH9ns7VVYiuwvwWmr+y5PR7H/Pt2EmYh9K6q5Gr02v7c AyZ2XFkGMYw31+vJwwwTHOdbGxrlk0KNpmC0slr7NaFbCrXVA4ttudx5O iPZ7PkSmss3VD6iwOtYsisVz8fCg5CX3YZzpslNHoR823ijEg3CQ0dPRg lM46XmjwctKgGgLjHddWD0DqG610iVM1zIJZ0rAv5PRPelF9AK0KTxQLw A==; X-IronPort-AV: E=Sophos;i="5.24,372,1454929200"; d="scan'208";a="75556981" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Mar 2016 01:35:27 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 22 Mar 2016 01:35:25 +1300 From: Peter Gutmann To: Hubert Kario Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROrgAJscYCAAOwz3w== Date: Mon, 21 Mar 2016 12:35:25 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz>, <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> In-Reply-To: <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 12:43:21 -0000 Hubert Kario writes:=0A= =0A= >Note that I asked for "being able to handle", not "selects and uses".=0A= =0A= The issue here is that a Cortex M3 isn't going to be able to handle RSA-204= 8,=0A= no matter what an RFC says :-). That's what the "ability of the hardware t= o=0A= deal with large keys" was meant to say.=0A= =0A= When I've run into upper limits, it's almost always because the hardware ca= n't=0A= go much beyond the given upper-limit value (Sun's Java implementation with = its=0A= braindamaged 1024-bit upper limit for DLP keys was a notable exception). S= o I=0A= could perhaps say something like "implementations SHOULD handle key sizes o= f=0A= up to 2048 bits, and MAY expect to see key sizes up to 4096 bits" or someth= ing=0A= similar.=0A= =0A= >no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1. of RF= C=0A= >5246, you need to be explicit about it.=0A= =0A= Maybe I'm missing something here, but the text that refers to signing with= =0A= "RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty unambiguous. Is= =0A= there something else I need to add there?=0A= =0A= >The implementation will need to interoperate with normal (i.e. already=0A= >deployed) TLS 1.2 implementations anyway, why prevent code reuse?=0A= =0A= Right, and if you need that you can include all the extensions you want. I= f=0A= you only need TLS-LTS, you can leave them out.=0A= =0A= Peter.= From nobody Mon Mar 21 06:08:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E33A712D7FA for ; Mon, 21 Mar 2016 06:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 jKlkMQpwSCBD for ; Mon, 21 Mar 2016 06:08:01 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606AE12D5F4 for ; Mon, 21 Mar 2016 06:08:00 -0700 (PDT) Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 911C52355C; Mon, 21 Mar 2016 14:07:58 +0100 (CET) Message-ID: <56EFF22C.5040505@secworks.se> Date: Mon, 21 Mar 2016 14:07:56 +0100 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz>, <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 13:08:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Peter Gutmann wrote: > Hubert Kario writes: > >> Note that I asked for "being able to handle", not "selects and >> uses". > > The issue here is that a Cortex M3 isn't going to be able to handle > RSA-2048, no matter what an RFC says :-). That's what the "ability > of the hardware to deal with large keys" was meant to say. When you say that "a Cortex M3 isn't going to be able to handle RSA-2048", what do you mean specifically? Considering that it is being done by for example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fail to see what hardware limits you are seeing. Yes, the speed you get is not impressive (1-2 seconds to decrypt), but it might be ok, depending on your application. [1] https://realtimelogic.com/products/sharkssl/Cortex-M3/ [2] https://tls.mbed.org/ - -- Med vnlig hlsning, Yours Joachim Strmbergson - Alltid i harmonisk svngning. ======================================================================== Joachim Strmbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW7/IsAAoJEF3cfFQkIuyNRlIQALbyX6t1xkXXQhj1PKLXvJqk OGWio/xk6pGow5Cqm3szXaUBOUThsuO6qkjFwZWrgj+sd+IXLd6rPxUlsPlJaAU5 hwib7jp5eCo/gFz9qTXe7PE8dZ2MU9BxRI8cB7paiR9VXxOS9v7m56SLsiPZRYNx S1U+trMzYPOZXJcy+HyTMQGvVpwWWcXsg03t66b5Lwem0SJK6yRSjnDmH5kCwJrX YsN4sQWvNCFsYf8e0A1/pTWeEo/+JqmNYo7b6sa/RanY7dhH8nwDJYPQnMTbOsdb MP73CC6yu1+tM30i6ubN89TLBzhtHpClW06tFr5rES06AE0UlW4hw43+3nfyp6QF j6gvpCO43LC36eIvu/sY/MBlZ2S3RfHAjexbSZo4TXJM3e/kavlPmPEyFJmEu0q4 kdM+VtXoq89cL10jqCPeTLzsWwJoap+iJzmPIOhlY9os4eGCV49z6wxMgV4WNu1v G7icxZnIdjSJiOs1DBt0jr2gDs1KTs936EzBp3LjeElo43IituUtYhyaiWG3trjI YDMcQpZa1uQDh7rMfNzyjVtV7FBUVUDDLOLk4vHO/0jL0q1PGA6lZjQ2Bg9cAFTs yhFbQhb9xgsI69aPcfqaVVZJEEyMZ7YMyhfykltp208iCgQTwlIVE3liqnlCwH2V xzxKDvzDwGqaNawLEZx7 =FHTY -----END PGP SIGNATURE----- From nobody Mon Mar 21 06:20:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06C12D800 for ; Mon, 21 Mar 2016 06:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 4foUNp2-7vCc for ; Mon, 21 Mar 2016 06:19:57 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1414F12D7AC for ; Mon, 21 Mar 2016 06:19:57 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2D9EA423724; Mon, 21 Mar 2016 13:19:56 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 178D242371D; Mon, 21 Mar 2016 13:19:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458566396; bh=/4+FZScbtPiWeuCj5bNceDMSLo/3luCd5tUoNADfvSI=; l=373; h=From:To:CC:Date:References:In-Reply-To:From; b=GirujLsWbWfoLd4tAUo/ggXRS6ZaPUD19Kp4djshaGrFHC8yOrR1BqWkE297esJeD 4UvrD9XHfhjvxTS1gL4Fn1jMwgYIABZecFcKMd2h/pHjQy4gxiUzn6UGtIUm/jkOm7 sO9Qy5OG3t6Wqn+sT7TqrsbB4E3gXVmz+kRO7aOg= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 115DC1FC86; Mon, 21 Mar 2016 13:19:56 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 21 Mar 2016 09:19:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 21 Mar 2016 09:19:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Mon, 21 Mar 2016 09:19:55 -0400 From: "Salz, Rich" To: Peter Gutmann , Karthikeyan Bhargavan Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2egC2HSmAAA7c3YAACY4sgAABYlqAAABzfAAAATh6gAAAki4AACR2PYAABlrJAA== Date: Mon, 21 Mar 2016 13:19:55 +0000 Message-ID: <1c0fb8f002d44a8b8073d9df9913a451@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27A2B@uxcn10-tdc05.UoA.auckland.ac.nz>, <26C23DDE-0BE5-486F-B6EB-FD181E2EDFEF@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28374@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C28374@uxcn10-tdc05.UoA.auckland.ac.nz> 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.34.47] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 13:20:00 -0000 > OK, I've posted another update that specifies this, as well as use of EMS= , and > cleans up a few other areas. It's a bit of a rush job because of the imp= ending > lockdown for IETF 95, but hopefully the gist is there: >=20 > http://www.ietf.org/id/draft-gutmann-tls-lts-02.txt So is someone "in the camp" coming to BA and can present this? Or remotely= ? From nobody Mon Mar 21 07:22:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E15312D84E for ; Mon, 21 Mar 2016 07:07:25 -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 u8syNqIoszPB for ; Mon, 21 Mar 2016 07:07:23 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 A852712D844 for ; Mon, 21 Mar 2016 07:07:23 -0700 (PDT) Received: by mail-ob0-x233.google.com with SMTP id ts10so175415781obc.1 for ; Mon, 21 Mar 2016 07:07:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YcwuiaKNaCeHwut0dyMBayUPvRU3K6HbJCAyS+Dobgc=; b=M6alz7brmzEQEsPi/Nu5Hrgf0MttEJW+jTf7qcKr2A/xzSWfSna3vCFw2TLe/YeN61 xwzMyWXM0N2r7pSbcdSeBqki2uK8APyUrxL2p2ioXoEnY8LNQjlJM8F9l4Ep4LxiylkJ s7Smtm6HA/uYweJwg2tAi6Jp7YoRcZdbECP2Fm9L2HSiai0j0gowwtr/XAhQRHCLlA8J k7BhkpITFQ3d7UkA8bi27haBDdGszDjgkSjwBpSlbSitvmIcob0q9Tw24b/FbZnZoBVo fVp9PB1TuXQnhfpkUpswKj3Lry/+naxuyEKuh851T/2qYjhI5C4QUtFKL3kWs50Lxzpl MOgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YcwuiaKNaCeHwut0dyMBayUPvRU3K6HbJCAyS+Dobgc=; b=YBkB/dY8AY4bA89eUkWTzdrKNw+xaJTHacEi9qMSYyqRES18shcUmRpzGojcPECiXs l9AZiWHE/Nd1pkiuB2TF7SJBagJ/zCe0pdCKLQYHC3DCY/9pNqAA9YwzzqAIMewM/0s4 vS6wN8xxOaQ7x/dnAP3yp/R9OxX5TWXAwzC5plCT6r4JPzCnefYGLOFyOfqKs83ooSc0 R+y4cAQ3AaAtrgggA8QN70saYONKKzTUDhrZMhWrqAhooHTbBUWtVwbAOxF+/LfNW5Lv vn9Q6YXIijya2HA529DlkrFRZ0D4ghJne9fpiIPKNiv5QM91QjbJxVtUm7ly3Rhm9WuD fsNw== X-Gm-Message-State: AD7BkJIeHY14EiSMF+fsdsnl4j7i7rPWnQmOPTi82DaUuTc/lhe4hA6lIaE24Fti2fH3RG3FkjEwl+K99rni7A== MIME-Version: 1.0 X-Received: by 10.182.158.42 with SMTP id wr10mr17080431obb.37.1458569243014; Mon, 21 Mar 2016 07:07:23 -0700 (PDT) Received: by 10.157.3.4 with HTTP; Mon, 21 Mar 2016 07:07:22 -0700 (PDT) In-Reply-To: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> References: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> Date: Mon, 21 Mar 2016 16:07:22 +0200 Message-ID: From: Efthymios Iosifides To: Aaron Zauner Content-Type: multipart/alternative; boundary=089e01537ea29c3fdd052e8f9d3c Archived-At: X-Mailman-Approved-At: Mon, 21 Mar 2016 07:22:24 -0700 Cc: klimn@di.uoa.gr, tls@ietf.org Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 14:07:25 -0000 --089e01537ea29c3fdd052e8f9d3c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable >I don't see any compelling argument for the inclusion of SPECK? Not only would the affiliation with NSA give the >TLS-WG a bad rep. in the public, more importantly, it makes one of our main problems worse: combinatorial explosion >of possible cipher-suites in TLS. This problem is so bad that it needs multiple blog posts, an effort by Mozilla and >bettercrypto.org to get sys-admins to configure their services. Hi all. The reputation aspect is not necessarily and strictly correlated with it's provenance, but with it's actual security and performance. And the SPECK we shall note that performs quite well. Also we shall not forget that even the infamous AES has been approved by the NSA before the widespread use of it. In any case i wouldn't like for us to stand on the popular press. On the other hand we shall evaluate if the SPECK could be actually used. For example, the fact that it lacks extensive cryptanalysis is a serious argument for not using it today, but what about the future specifications. On top to that what if we could prove that the SPECK can have better performance than other algos without sacrificing the security. BRs, Efthimios Iosifides 2016-03-18 19:49 GMT+02:00 Aaron Zauner : > Hi, > > > On 17 Mar 2016, at 07:35, Efthymios Iosifides > wrote: > > > > Hello all. > > > > I have just found on the ietf archives an email discussion about the > inclusion of the SPECK Cipher > > in the tls standards. > > It's reference is below : > https://www.ietf.org/mail-archive/web/tls/current/msg13824.html > > > > Even though that this cipher originates from the NSA one cannot find a > whitepaper that describes it's full cryptanalysis. In the above discussio= n > Mr. Str=C3=B6mbergson somehow perfunctorily presents two whitepapers that > describe the SPECK's cryptanalysis. Although we shall keep in mind that > these papers describe a limited round cryptanalysis. Also we shall not > forget that a similar cryptanalysis has taken place for the famous AES. > Therefore i personally do not see any actual arguments apart from the fac= ts > that concerns the algorithm's provenance for not including it in a futur= e > tls specification. In conclusion even by this day the SPECK cipher has no= t > been yet fully cryptanalyzed succesfully. > > I don't see any compelling argument for the inclusion of SPECK? Not only > would the affiliation with NSA give the TLS-WG a bad rep. in the public, > more importantly, it makes one of our main problems worse: combinatorial > explosion of possible cipher-suites in TLS. This problem is so bad that i= t > needs multiple blog posts, an effort by Mozilla and bettercrypto.org to > get sys-admins to configure their services. > > Aaron > --089e01537ea29c3fdd052e8f9d3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>I don't see any compelling argument for the i= nclusion of SPECK? Not only would the affiliation with NSA give the >TLS-WG a bad rep. in the=20 public, more importantly, it makes one of our main problems worse:=20 combinatorial explosion >of possible cipher-suites in TLS. This problem= =20 is so bad that it needs multiple blog posts, an effort by Mozilla and >bet= tercrypto.org to get sys-admins to configure their services.

Hi all.

The reputation aspect is not necessar= ily and strictly correlated with it's provenance, but with it's act= ual security and performance. And the SPECK we shall note that performs quite well. Also we shal= l not forget that even the infamous AES has been approved by the NSA before= the widesp= read use of it. In any case i wouldn't like for us to stand on the popu= lar press. On the other hand we shall evaluate if the SPECK could be actual= ly used. For example, the fact that it lacks extensive cryptanalysis is a s= erious argument for not using it today, but what about the future specifica= tions. On top to that what if we could prove that the SPECK can have better= performance than other algos without sacrificing the security.

BRs,
Efthimios Iosifides
<= /div>

2016-03= -18 19:49 GMT+02:00 Aaron Zauner <azet@azet.org>:
Hi,

> On 17 Mar 2016, at 07:35, Efthymios Iosifides <iosifidise@gmail.com> wrote:
>
> Hello all.
>
> I have just found on the ietf archives an email discussion about the i= nclusion of the SPECK Cipher
> in the tls standards.
> It's reference is below :htt= ps://www.ietf.org/mail-archive/web/tls/current/msg13824.html
>
> Even though that this cipher originates from the NSA one cannot find a= whitepaper that describes it's full cryptanalysis. In the above discus= sion Mr. Str=C3=B6mbergson somehow perfunctorily presents two whitepapers t= hat describe the SPECK's cryptanalysis. Although we shall keep in mind = that these papers describe a limited round cryptanalysis. Also we shall not= forget that a similar cryptanalysis has taken place for the famous AES. Th= erefore i personally do not see any actual arguments apart from the facts t= hat concerns the algorithm's=C2=A0 provenance for not including it in a= future tls specification. In conclusion even by this day the SPECK cipher = has not been yet fully cryptanalyzed succesfully.

I don't see any compelling argument for the inclusion of SPECK? = Not only would the affiliation with NSA give the TLS-WG a bad rep. in the p= ublic, more importantly, it makes one of our main problems worse: combinato= rial explosion of possible cipher-suites in TLS. This problem is so bad tha= t it needs multiple blog posts, an effort by Mozilla and bettercrypto.org= to get sys-admins to configure their services.

Aaron

--089e01537ea29c3fdd052e8f9d3c-- From nobody Mon Mar 21 07:25:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3C812D6A5 for ; Mon, 21 Mar 2016 07:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 Xa9u115kwEjy for ; Mon, 21 Mar 2016 07:25:01 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id F18DE12D64B for ; Mon, 21 Mar 2016 07:25:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4D719433413; Mon, 21 Mar 2016 14:25:00 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 27647433402; Mon, 21 Mar 2016 14:25:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458570300; bh=MH9Bzs2GeT3TNg9ExI6d4gq+BE2AQJ8hbq1x5GWP0g0=; l=514; h=From:To:CC:Date:References:In-Reply-To:From; b=XQ/V+T6PHKXJdcdQfpftlN4cQZg23IAIsgMsCnO+uX8Cak2/OquuvtCvX/i685DRh v11CtknAIlZ8lu4Y3gcene4px3OsCHs3sgX7elRjqL8yvDWjVEdYX7C2dQvqAjlUGE cLOh9gntG3VpAJyC2+h/KX7DObz+1Jo6+bksm4QI= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 11EE21FC8B; Mon, 21 Mar 2016 14:25:00 +0000 (GMT) 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.1130.7; Mon, 21 Mar 2016 10:24:59 -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.1130.005; Mon, 21 Mar 2016 10:24:59 -0400 From: "Salz, Rich" To: Efthymios Iosifides , Aaron Zauner Thread-Topic: [TLS] Include Speck block cipher? Thread-Index: AQHRgLV073ctYd12P0CIElVs+Ylqn59fvqAAgAR4/AD//8FZcA== Date: Mon, 21 Mar 2016 14:24:58 +0000 Message-ID: <53e19c184c144dba841c2ebe59549faa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> 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.34.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "klimn@di.uoa.gr" , "tls@ietf.org" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 14:25:02 -0000 PiBvdGhlciBoYW5kIHdlIHNoYWxsIGV2YWx1YXRlIGlmIHRoZSBTUEVDSyBjb3VsZCBiZSBhY3R1 YWxseSB1c2VkDQo+IHdoYXQgYWJvdXQgdGhlIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucw0KPiB3aGF0 IGlmIHdlIGNvdWxkIHByb3ZlIHRoYXQgLi4NCg0KVGhvc2UgYXJlIGFsbCBncmVhdCBxdWVzdGlv bnMuICBCdXQgaW4gdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhpbmdzLCB0aGV5IGFyZSB1bmFuc3dl cmVkIHF1ZXN0aW9ucy4NCg0KSWYgc29tZW9uZSB3YW50cyB0byBzZWUgU1BFQ0sgYWRvcHRlZCBi eSBJRVRGIHByb3RvY29scywgdGhlIGZpcnN0IHRoaW5nIHRoYXQgd2lsbCBoYXZlIHRvIGhhcHBl biBpcyBwYXBlcnMgYW5hbHl6aW5nIGl0Lg0KDQoNCg== From nobody Mon Mar 21 07:27:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EA012D84D for ; Mon, 21 Mar 2016 07:27:18 -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 ATz-T4sr9hoZ for ; Mon, 21 Mar 2016 07:27:16 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 515D612D6A5 for ; Mon, 21 Mar 2016 07:27:16 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id w104so153221923qge.1 for ; Mon, 21 Mar 2016 07:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RsbQruZlPFIDpa0qFqEbiEZgxiV0hD9lvP78rRwQGQg=; b=MwlyTXcWElp7eRIlL49MRA+GT8ZRvJ6SI+9LTEWmlRBMc6FwbrHIahWkQvBbtj0xrY PmNS53M0yI5ObsxWS6zTU3L0BU9OjE5Z7Nrxc4rgIy+3Cy1HjUTCVEwNIAgaHqFMnS2Z MoSCWc1geOJrBy5psIlkeZFq6z4YYK197u2E4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RsbQruZlPFIDpa0qFqEbiEZgxiV0hD9lvP78rRwQGQg=; b=eeEOf8XzSlyAb4NqiUThQ+QbXaJVG9YgGY3u6MxytTICoONSE9CyDHB1/p4K5H4r8N 3RF6dZgqkWu5giQL0AwU1x9X3OGBqFbqE1MrP47c1ui2iE3A8BcTuXxu/Cf81vHYL4wZ xniYU9YWKyo76pSit7F/dHFiVnoKrf9gu13f5CeDU0Q3ketMkHrHf4rkZF8p0IJxcn24 GTBVVrqnfy5SvLM91OdSbIIxL1i/4T+l6uaSZHcTDMqnJkKiRyNtI5TApxONWU8VJKnH EKB1V9APy6xqI6bsMMc02Ij3C/W3nBDyPRALvpc5YZokz1SqTtnwFcfWqEukPR0ukMBA 5y9A== X-Gm-Message-State: AD7BkJI2Gabe8GWo6WITR9VQBmaoFt7HzeX8zLPCPiwApWp3mYTIFM8ovM4Vu6di6wKhhA== X-Received: by 10.141.4.135 with SMTP id g129mr43792417qhd.31.1458570435416; Mon, 21 Mar 2016 07:27:15 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id r18sm12379680qkl.24.2016.03.21.07.27.14 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 07:27:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: Date: Mon, 21 Mar 2016 10:27:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> To: Efthymios Iosifides X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 14:27:18 -0000 If we=E2=80=99re going to get into the cryptanalysis of SPECK then this = thread should move off the TLS list and possibly to the CFRG list. spt > On Mar 21, 2016, at 10:07, Efthymios Iosifides = wrote: >=20 > >I don't see any compelling argument for the inclusion of SPECK? Not = only would the affiliation with NSA give the >TLS-WG a bad rep. in the = public, more importantly, it makes one of our main problems worse: = combinatorial explosion >of possible cipher-suites in TLS. This problem = is so bad that it needs multiple blog posts, an effort by Mozilla and = >bettercrypto.org to get sys-admins to configure their services. >=20 >=20 > Hi all. >=20 > The reputation aspect is not necessarily and strictly correlated with = it's provenance, but with it's actual security and performance. And the = SPECK we shall note that performs quite well. Also we shall not forget = that even the infamous AES has been approved by the NSA before the = widespread use of it. In any case i wouldn't like for us to stand on the = popular press. On the other hand we shall evaluate if the SPECK could be = actually used. For example, the fact that it lacks extensive = cryptanalysis is a serious argument for not using it today, but what = about the future specifications. On top to that what if we could prove = that the SPECK can have better performance than other algos without = sacrificing the security.=20 >=20 >=20 > BRs, > Efthimios Iosifides >=20 > 2016-03-18 19:49 GMT+02:00 Aaron Zauner : > Hi, >=20 > > On 17 Mar 2016, at 07:35, Efthymios Iosifides = wrote: > > > > Hello all. > > > > I have just found on the ietf archives an email discussion about the = inclusion of the SPECK Cipher > > in the tls standards. > > It's reference is below = :https://www.ietf.org/mail-archive/web/tls/current/msg13824.html > > > > Even though that this cipher originates from the NSA one cannot find = a whitepaper that describes it's full cryptanalysis. In the above = discussion Mr. Str=C3=B6mbergson somehow perfunctorily presents two = whitepapers that describe the SPECK's cryptanalysis. Although we shall = keep in mind that these papers describe a limited round cryptanalysis. = Also we shall not forget that a similar cryptanalysis has taken place = for the famous AES. Therefore i personally do not see any actual = arguments apart from the facts that concerns the algorithm's provenance = for not including it in a future tls specification. In conclusion even = by this day the SPECK cipher has not been yet fully cryptanalyzed = succesfully. >=20 > I don't see any compelling argument for the inclusion of SPECK? Not = only would the affiliation with NSA give the TLS-WG a bad rep. in the = public, more importantly, it makes one of our main problems worse: = combinatorial explosion of possible cipher-suites in TLS. This problem = is so bad that it needs multiple blog posts, an effort by Mozilla and = bettercrypto.org to get sys-admins to configure their services. >=20 > Aaron >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Mar 21 07:38:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D948812D641 for ; Mon, 21 Mar 2016 07:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHVBa6ygYkkZ for ; Mon, 21 Mar 2016 07:38:57 -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 70ADC12D520 for ; Mon, 21 Mar 2016 07:38:51 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E2293B8939; Mon, 21 Mar 2016 14:38:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LEcn4o004180 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 10:38:50 -0400 From: Hubert Kario To: Peter Gutmann Date: Mon, 21 Mar 2016 15:38:43 +0100 Message-ID: <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4232841.RrqJr5uJ9M"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 14:38:59 -0000 --nextPart4232841.RrqJr5uJ9M Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 21 March 2016 12:35:25 Peter Gutmann wrote: > Hubert Kario writes: > >Note that I asked for "being able to handle", not "selects and uses"= . >=20 > The issue here is that a Cortex M3 isn't going to be able to handle > RSA-2048, no matter what an RFC says :-). That's what the "ability > of the hardware to deal with large keys" was meant to say. even 10 seconds to establish a session that is then kept up for days=20= and/or uses session resumption is something many environments would be=20= able to handle. If your hardware really can't do anything better than 2048 bit RSA, it'= s=20 not LTS, it's a crippled embedded system, and it definitely shouldn't=20= get a stamp of approval "good for next X0 years" or anything similar=20= like a LTS moniker would imply. Also, you're explicitly saying that this proposal is limiting the TLS=20= parameter set to "known-good subset". 1024 bit RSA and DHE are not=20 known-good, if Cortex M3 really can't handle RSA-2048, for crypto it's=20= as good as a coaster already. the system is only as strong as the weakest link > When I've run into upper limits, it's almost always because the > hardware can't go much beyond the given upper-limit value (Sun's Java= > implementation with its braindamaged 1024-bit upper limit for DLP > keys was a notable exception). So I could perhaps say something like= > "implementations SHOULD handle key sizes of up to 2048 bits, and MAY > expect to see key sizes up to 4096 bits" or something similar. there's a similar limit in NSS with client certificates, although I=20 don't remember the exact number now, I'm quite sure that a 8k key would= =20 get rejected. > >no, it's not, not in TLSv1.2. If it does override section 7.4.1.4.1.= > >of RFC 5246, you need to be explicit about it. >=20 > Maybe I'm missing something here, but the text that refers to signing= > with "RSA-SHA-256" and "ECDSA-P256-SHA-256" seems to be pretty > unambiguous. Is there something else I need to add there? it doesn't explain where this "RSA-SHA-256" is used. IMHO it is=20 ambiguous. The "no MAC truncation" is also not explicit about what the sizes shoul= d=20 be. > >The implementation will need to interoperate with normal (i.e. > >already deployed) TLS 1.2 implementations anyway, why prevent code > >reuse? > Right, and if you need that you can include all the extensions you > want. If you only need TLS-LTS, you can leave them out. my point is, that the code path of the tls-lts extension should check=20= the sanity of extensions passed and abort if anything is not according=20= to the LTS when LTS is supposed to be enforced. in other words, LTS should be an addition to already existing code, not= =20 a replacement. You may be dealing with hardware that often requires careful pruning of= =20 code base to make it fit. Thing is, that there are also millions of=20 devices which can handle full OpenSSL/PolarSSL/etc. just fine. And for=20= those it's better if the code paths used are the same or as similar as=20= possible in all situations. Any other approach leads to subtle and hard= =20 to find bugs. Exactly what we don't want to see in LTS code. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart4232841.RrqJr5uJ9M 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 iQIcBAABCgAGBQJW8AdzAAoJEJKo0bgB0vX1lH4P/2Zc8PM65M9rpdFPQhzhAVtx U124peV9r4V4fLnyiwDNUpd/gzFE4LqtTDaehf3CvaM6dySNV/wd2GSEBP6N6FTz Lhj09wFlsHqsjWAxCLd+GXrlgIdnwfy3ss/4BUhgSq4I8ecHsaT0Uh0lFbKliMkG 4xulI+FrxM//V2T/DLv9P2Fj/1qv2ekFdzLTDys205YaqPMxyGtR9eIfoRPqXave Ev690GcHgiY9CHv268ukIljPrJ1wB4Rc4RTPVd43VuBaZT9MEJnAZsZ71Ryg59/1 Y3F3XfKSzlwCfVtrOrk0xBNlIqChSVOuQBbdRrqO819nF7WKZhPr1GaeZJf6L8gX wHsVL8I39X1dqRfIVz1y80UDPJ39e02d3ou4uFBj8QcptPb9guqqZXDte24WHxp4 3naLeRSUwZ12SsSSM/1UBILUW6IVC58YRhOcjggCvLYdaPYxUGdfAtmaolVGc/AL OoIjfZUXPV3SOI8C5mId1YrpR1kAHjyj8d/C7MgGzgxJABw2+CxfNK/tYN/ph1AM B5qOlN6PaFaY57dhoIxW1YmpKobkG83NJm4Ux3Fhlyo7N6WJabZe58HhGlgzmv+d NuwCgNaRo8XHQUGgvk8EBMkmIwSJPUL1YjATX5ud5PbCyqJ3cc+ZsE1rv3WPRs08 rFCcHPYQ05Ef4O7R5qIV =4MyJ -----END PGP SIGNATURE----- --nextPart4232841.RrqJr5uJ9M-- From nobody Mon Mar 21 07:43:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B64A812D89D for ; Mon, 21 Mar 2016 07:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.187 X-Spam-Level: X-Spam-Status: No, score=-1.187 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_RHS_DOB=1.514] 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 wsKpC4Q294X8 for ; Mon, 21 Mar 2016 07:43:12 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 428EB12D88F for ; Mon, 21 Mar 2016 07:42:57 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id u110so153538051qge.3 for ; Mon, 21 Mar 2016 07:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=UbOmh5Ogb09+pstPvm+YO2pIJApx6Jr7HWKSh41FGW0=; b=OrpAUcLmPgtRpFHZkJgMWoA6cGZPW06laxGD2B5lZcfYCPe3RDo0PUU+MLUYSo90dc kEW8lNDWEqOEN7HPMq5MC3HQmCfPGfyEidi7X6Z5WYklyT0DzCbjr31JelyMuMEs+0zR ysJTyjsmzJIBZwyIZp5spDWypn1F0NColqFY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=UbOmh5Ogb09+pstPvm+YO2pIJApx6Jr7HWKSh41FGW0=; b=hDubA2INel0LZOaerxG7iMfY1O2F5McnDh1bcaxMJvv5dG6pVxpa1OKZ5FarQX6YYd qrEqzjYyMlRkVysSPFY/xWfz4XbsERjfTQA+oGiZLfya3ZUfeDlUaFR5ZuAJurvc7LoD A34N5RwTajYv+ZHZ2BdgDJHlOgmWBkG8HUbZw6TUrDk7ZHo7n0uOe5vYUCehq5QEDdVU 75ar0gETOrwXU4PrBDXWYL395qHRnqWPdnDYuLknfToGpm6494sJqEW9TtTVVaLrMTFb Mu3zI24qd945hWIqzyy/Cxwh7at+IWv08j2QZ3h5Rj9xkcwsjodtqMfFb9nMI8IAok1E CJxQ== X-Gm-Message-State: AD7BkJJlTisAJZ66d7+BMIyfdBi03u0IomFib+p+Z6IWZsai+d2Hhf82ahe2J1Luzy7GXg== X-Received: by 10.140.168.85 with SMTP id o82mr42742791qho.75.1458571376415; Mon, 21 Mar 2016 07:42:56 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id w66sm12354348qgd.26.2016.03.21.07.42.55 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 07:42:56 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2016 10:42:54 -0400 References: <20160321144210.31961.73044.idtracker@ietfa.amsl.com> To: "" Message-Id: <1CED2E40-587B-4822-9E5D-AA0AB5BC160C@sn3rd.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] Fwd: Publication has been requested for draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 14:43:19 -0000 FYI > Begin forwarded message: >=20 > From: "Sean Turner" > Subject: Publication has been requested for = draft-ietf-tls-falsestart-01 > Date: March 21, 2016 at 10:42:10 EDT > To: > Cc: "Sean Turner" , iesg-secretary@ietf.org, = tls-chairs@ietf.org, sean@sn3rd.com >=20 > spt has requested publication of draft-ietf-tls-falsestart-01 as = Experimental on behalf of the TLS working group. >=20 > Please verify the document's state at = https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ >=20 From nobody Mon Mar 21 07:49:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1FC12D77F for ; Mon, 21 Mar 2016 07:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zWqZlmfscrxv for ; Mon, 21 Mar 2016 07:48:59 -0700 (PDT) Received: from gateway22.websitewelcome.com (gateway22.websitewelcome.com [192.185.47.65]) (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 F2D9612D6C4 for ; Mon, 21 Mar 2016 07:48:58 -0700 (PDT) Received: from cm5.websitewelcome.com (cm5.websitewelcome.com [192.185.178.233]) by gateway22.websitewelcome.com (Postfix) with ESMTP id 58557486906D4 for ; Mon, 21 Mar 2016 09:48:58 -0500 (CDT) Received: from gator3286.hostgator.com ([198.57.247.250]) by cm5.websitewelcome.com with id Yeow1s00u5Qt53201eoxxr; Mon, 21 Mar 2016 09:48:58 -0500 Received: from [96.231.217.211] (port=60749 helo=[172.16.0.112]) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ai18a-000Q0y-8L; Mon, 21 Mar 2016 09:48:56 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Sean Turner In-Reply-To: <56E03023.1090703@gmx.net> Date: Mon, 21 Mar 2016 10:48:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <28F167AC-1FC0-47AF-ADE5-FD316BC46F79@ieca.com> References: <01B45068-A591-4F31-9993-CEF6A538F3CB@ieca.com> <56E03023.1090703@gmx.net> To: Hannes Tschofenig X-Mailer: Apple Mail (2.3112) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source-IP: 96.231.217.211 X-Exim-ID: 1ai18a-000Q0y-8L X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([172.16.0.112]) [96.231.217.211]:60749 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: "" Subject: Re: [TLS] Cached Info X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 14:49:00 -0000 On Mar 09, 2016, at 09:16, Hannes Tschofenig = wrote: =85snip > ----------------- >=20 > In a nutshell, while I do not believe that the attack described is > realistic I am sensitive to the problem of creating brittle code. >=20 > If it is OK for the working group then I would like to revert back to > the previous version of the draft where we use the longer hash. >=20 > Ciao > Hannes Hannes, It=92s been 10 days and there=92s been no objections so I think it=92s = safe to revert back to the long hash. spt From nobody Mon Mar 21 08:24:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71F212D587 for ; Mon, 21 Mar 2016 08:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.085 X-Spam-Level: X-Spam-Status: No, score=-1.085 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_RHS_DOB=1.514] 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 Tu7nPsnBWsnr for ; Mon, 21 Mar 2016 08:24:44 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFAD312D566 for ; Mon, 21 Mar 2016 08:24:43 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h65so75925175ywe.0 for ; Mon, 21 Mar 2016 08:24:43 -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=vKKlSn+gd9/rEdmYXE2kHIhrwjMZVekFCLdfn/f8+Vs=; b=IQzORH4hEMNLz4dpo4raenOlyPOPHtT2lCL4qkoTHyTm4NEiKoCGrZDTKofsv5IS5s 6brKaHI/d1yNkfqpGPPRzCZCG86UOK3GKW5q4BmVO3+OOI5th4Yg5Jg8NdHN6qSvbJK3 SCPqruCgnTFKyjvNMPZk/p+/0IAV0esnRTTj1MyzCJlrKVb1SFza/q0+PwDYbkSneMpD Bluvy433g9aB3ee+CjzWA/FHteeiGItN4aWLaoNywx7DKvEVXDizpRv53xc4vmPZL+dk hcl5RIXv17ySI7HIe8NaPStHDAmj33NkWyKlo4GQWuenoHsNnFooQ25VeaqOKsTFuxUx DtJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vKKlSn+gd9/rEdmYXE2kHIhrwjMZVekFCLdfn/f8+Vs=; b=PhS8BKf0DUsZlcZYnWKmBuT9OaMDVSb46NAeENP5xCFUcuQ7k+kQ2136a0pWA/OU20 WYIw09jUH+XS4upd+7r45qcqbbZrD+U9R/1Ug04KSKKGuvqO3E2XyK9mWEi8OHXeAIhT 5xczI3hqeGCpWT8vxDDD/YEQVlpI3z5NUhL/ctfRxHM97YK05NUtPTXtHO63TWaA/Bk2 hGaB7Hwr5M/O8XwBCAOLK2qNSvbzk00XGNBH3TwWG/dnsUJ4Vs+gL5vczEMSUmbpzA3R 3EXQuE+MNKzIAlYN8/QTmsdUSLxc7bBYT0TUO8ZVwy4QfMq9B2tP5cq0clQYyMuAFqsA EHcw== X-Gm-Message-State: AD7BkJIrQXBXQx0X25uuiTGoM/QNpqCFp2KjzCJUV/tPSxSQQjbbAJazWQoZZb06syLZmt96TgpKocFSIO9nUg== X-Received: by 10.13.193.4 with SMTP id c4mr15844373ywd.192.1458573883170; Mon, 21 Mar 2016 08:24:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 21 Mar 2016 08:24:03 -0700 (PDT) In-Reply-To: <1CED2E40-587B-4822-9E5D-AA0AB5BC160C@sn3rd.com> References: <20160321144210.31961.73044.idtracker@ietfa.amsl.com> <1CED2E40-587B-4822-9E5D-AA0AB5BC160C@sn3rd.com> From: Eric Rescorla Date: Mon, 21 Mar 2016 08:24:03 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a114caa9e2f901c052e90b241 Archived-At: Cc: "" Subject: Re: [TLS] Fwd: Publication has been requested for draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 15:24:46 -0000 --001a114caa9e2f901c052e90b241 Content-Type: text/plain; charset=UTF-8 Our long national nightmare is over. On Mon, Mar 21, 2016 at 7:42 AM, Sean Turner wrote: > FYI > > > Begin forwarded message: > > > > From: "Sean Turner" > > Subject: Publication has been requested for draft-ietf-tls-falsestart-01 > > Date: March 21, 2016 at 10:42:10 EDT > > To: > > Cc: "Sean Turner" , iesg-secretary@ietf.org, > tls-chairs@ietf.org, sean@sn3rd.com > > > > spt has requested publication of draft-ietf-tls-falsestart-01 as > Experimental on behalf of the TLS working group. > > > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/ > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114caa9e2f901c052e90b241 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Our long national nightmare is over.

On Mon, Mar 21, 2016 at 7:42 AM, = Sean Turner <sean@sn3rd.com> wrote:
FYI

> Begin forwarded message:
>
> From: "Sean Turner" <se= an@sn3rd.com>
> Subject: Publication has been requested for draft-ietf-tls-falsestart-= 01
> Date: March 21, 2016 at 10:42:10 EDT
> To: <stephen.farrell@c= s.tcd.ie>
> Cc: "Sean Turner" <sean= @sn3rd.com>, iesg-secreta= ry@ietf.org, tls-chairs@ietf.org= , sean@sn3rd.com
>
> spt has requested publication of draft-ietf-tls-falsestart-01 as Exper= imental on behalf of the TLS working group.
>
> Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-falsestart/
>

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

--001a114caa9e2f901c052e90b241-- From nobody Mon Mar 21 08:37:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3F712D8C3 for ; Mon, 21 Mar 2016 08:37:20 -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 aN8saXtLk2mg for ; Mon, 21 Mar 2016 08:37:18 -0700 (PDT) Received: from mail-lf0-x242.google.com (mail-lf0-x242.google.com [IPv6:2a00:1450:4010:c07::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED9FD12D8C2 for ; Mon, 21 Mar 2016 08:37:17 -0700 (PDT) Received: by mail-lf0-x242.google.com with SMTP id h198so10141246lfh.3 for ; Mon, 21 Mar 2016 08:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=LXqYHzHEbYOOaFC1f/ou0RIbrPzxTxejgNLP2cZGaRI=; b=k/WSbHypw6pg11PCSvHfinGRIrjlCvRuWHU6uKFgwqj0eSLpfntXCGD01BT9IXnFql iR3mJ8zTUtRHfjOrk4feU9ophkREDmPWGf0isx2Whmdbd2lYDNzQ/aEGEy1lIV+r3xI7 Yudys2DsgsZuIREzpXz7yt8820qs8NvIx0FbfVEHB34ADKbHxleniwQlAX3CZaHGC/Pq WYESRlGZhvqakqkhTN8BE7fW/qLFBing47bxtBXytZFA04JuaxbfT9IFOW7bWlGL2Euz 75OVr9BmzFGvxFzyDRNjoihyqLcutXLwT5Q5hW6ANxelqnejYmvsVmLL/2+rhFlAlEkk 0Qzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=LXqYHzHEbYOOaFC1f/ou0RIbrPzxTxejgNLP2cZGaRI=; b=e42qYSlnjTosYYwhOfGf8NgVKzcPiu7WBCoYPBlHnEr5XOdEYT9Z6/KAS9eC6nyVga s4uJ3fhYCyz2518zqhLkHSzcGk5BJFoecO6+ly3yH97O+4Av2fNYsD0YTqaXVbG7tiyC W0mtvItwysdg1rx2+FRjrXiGItdC9yjFkxNzAN1SdXeCPJSoa+UQFon/4Y7su/uJ1wOS EEPr1CoqMasQwdQ6hm+z5JJCRePldtNVZRYMA7jwIskCyo7yTlalbu8FN6ndry7y1z2+ a2HzHtCpwmA63Htog+ZiBuTVdpOu6r3uZsfm6K8iTvcTEt6j8YYv12OLabaBaiTFS3J8 BMgQ== X-Gm-Message-State: AD7BkJLoPmBYK4g9Oo6mAEtM7eQD8KHB0c8rB36nBYnJpzfPxaT3h16j3oozqlv6xDSF5OMElFw6cFQfRFs+tw== MIME-Version: 1.0 X-Received: by 10.25.154.65 with SMTP id c62mr11958383lfe.54.1458574636010; Mon, 21 Mar 2016 08:37:16 -0700 (PDT) Received: by 10.112.170.67 with HTTP; Mon, 21 Mar 2016 08:37:15 -0700 (PDT) In-Reply-To: <20160318194126.2701E180003@rfc-editor.org> References: <20160318194126.2701E180003@rfc-editor.org> Date: Mon, 21 Mar 2016 16:37:15 +0100 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sean+ietf@sn3rd.com, Kathleen.Moriarty.ietf@gmail.com, worley@ariadne.com, "tls@ietf.org" , nagendra@cs.stanford.edu Subject: Re: [TLS] [Editorial Errata Reported] RFC6347 (4642) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 15:37:20 -0000 On Fri, Mar 18, 2016 at 8:41 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6347, > "Datagram Transport Layer Security Version 1.2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6347&eid=3D4642 > > -------------------------------------- > Type: Editorial > Reported by: Dale R. Worley > > Section: 4.1 > > Original Text > ------------- > version > The version of the protocol being employed. This document > describes DTLS version 1.2, which uses the version { 254, 253 }. > The version value of 254.253 is the 1's complement of DTLS version > 1.2. This maximal spacing between TLS and DTLS version numbers > ensures that records from the two protocols can be easily > distinguished. It should be noted that future on-the-wire version > numbers of DTLS are decreasing in value (while the true version > number is increasing in value.) > > > Corrected Text > -------------- > Replace "1's complement of DTLS version" with "1's complement > of TLS version": > > version > The version of the protocol being employed. This document > describes DTLS version 1.2, which uses the version { 254, 253 }. > The version value of 254.253 is the 1's complement of TLS version > 1.2. This maximal spacing between TLS and DTLS version numbers > ensures that records from the two protocols can be easily > distinguished. It should be noted that future on-the-wire version > numbers of DTLS are decreasing in value (while the true version > number is increasing in value.) As far as I can see, the original text is correct, which is easy to see if you look at the corresponding paragraph of RFC 4347 (DTLS 1.0): version The version of the protocol being employed. This document describes D= TLS Version 1.0, which uses the version { 254, 255 }. The version value of 254.255 is the 1's complement of DTLS Version 1.0. If the suggested text had been correct, then the encoding in RFC 4347 would have been { 254, 254 } as DTLS 1.0 is based on TLS 1.1. --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Mon Mar 21 10:07:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08212D8CB for ; Mon, 21 Mar 2016 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, URIBL_RHS_DOB=1.514] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rhul.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 iDa6dbNJgbm0 for ; Mon, 21 Mar 2016 10:07:21 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0670.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::670]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DC912D512 for ; Mon, 21 Mar 2016 10:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vGIIFTaBtiALMWCQ2Fx3tUqML/aKBLOHYpfOlSutrGE=; b=YOEC4EaXycjGlJ6cO7chXgoKoFIKiHXY2VXiQtiOHCBii+3qn9kVXQPRiZCk/vRgijQb/ataEw+RnrvrPN4ao+6sdiYPUqHX0VOacjgyoRusBnBxvRQ/stQGwb1xiJvOpHqvSLZA6pFZgKQzzJYyttXm6inIkoG0Bzkr8aPhvwQ= Received: from VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) by VI1PR03MB1822.eurprd03.prod.outlook.com (10.166.42.148) with Microsoft SMTP Server (TLS) id 15.1.443.12; Mon, 21 Mar 2016 17:07:04 +0000 Received: from VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) by VI1PR03MB1822.eurprd03.prod.outlook.com ([10.166.42.148]) with mapi id 15.01.0443.014; Mon, 21 Mar 2016 17:07:04 +0000 From: "Paterson, Kenny" To: Sean Turner , Efthymios Iosifides Thread-Topic: [TLS] Include Speck block cipher? Thread-Index: AQHRgLV7oLH5mnkCaEOW6/o4gDVN2p9fe5EAgAR4/QCAAAWMgIAALLuA Date: Mon, 21 Mar 2016 17:07:04 +0000 Message-ID: References: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 authentication-results: sn3rd.com; dkim=none (message not signed) header.d=none;sn3rd.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [80.254.78.161] x-ms-office365-filtering-correlation-id: 87e95964-cefc-4c5f-d8f9-08d351ab3a1e x-microsoft-exchange-diagnostics: 1; VI1PR03MB1822; 5:74CHTtVZZzUcqahCJ8BU1yBztY8IUOpm+T+hJGYeIU43GDqqItvOi7ZWTUhzFMS6um5RquljcWUHqSKCGUwPHruIGC+Z8bcMHrpvEgIkHrI2FSqzYJFF0CWUfcJgeqa8mZ99zWedXqoidiJ1xmUIHQ==; 24:oxwqOMgONf5d8V4BJI2IW7rd7aF3JOTSidWRSLPJ+Ryz2qEDSyC0/z9hnETj61fb7Leg2UZQe9nMZQC43MXD2tbp3Lc+1JNnPJCqwe0uVaE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:VI1PR03MB1822; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:VI1PR03MB1822; BCL:0; PCL:0; RULEID:; SRVR:VI1PR03MB1822; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(53754006)(377424004)(24454002)(5002640100001)(86362001)(66066001)(1096002)(93886004)(122556002)(1220700001)(54356999)(5001770100001)(19580405001)(106116001)(2900100001)(77096005)(19580395003)(10400500002)(81166005)(5004730100002)(6116002)(102836003)(3846002)(586003)(74482002)(15975445007)(4001350100001)(83506001)(2950100001)(92566002)(50986999)(5008740100001)(189998001)(4326007)(36756003)(2906002)(3660700001)(11100500001)(76176999)(3280700002)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR03MB1822; H:VI1PR03MB1822.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 17:07:04.4635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB1822 Archived-At: Cc: "" Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 17:07:28 -0000 SGkNCg0KSSB0aGluayBSaWNoIFNhbHogYWxyZWFkeSBzYWlkIGV4YWN0bHkgd2hhdCBDRlJHIHdv dWxkIHNheToNCg0KPiBJZiBzb21lb25lIHdhbnRzIHRvIHNlZSBTUEVDSyBhZG9wdGVkIGJ5IElF VEYgcHJvdG9jb2xzLCB0aGUgZmlyc3QgdGhpbmcNCj50aGF0IHdpbGwgaGF2ZSB0byBoYXBwZW4g aXMgcGFwZXJzIGFuYWx5emluZyBpdC4NCg0KVGhlcmUncyBzb21lIGFuYWx5c2lzIGFscmVhZHks IGJ1dCBub3QgdGhhdCBtdWNoLg0KDQpSZWdhcmRzLA0KDQpLZW5ueSANCg0KDQoNCg0KT24gMjEv MDMvMjAxNiAxNDoyNywgIlRMUyBvbiBiZWhhbGYgb2YgU2VhbiBUdXJuZXIiIDx0bHMtYm91bmNl c0BpZXRmLm9yZw0Kb24gYmVoYWxmIG9mIHNlYW5Ac24zcmQuY29tPiB3cm90ZToNCg0KPklmIHdl 4oCZcmUgZ29pbmcgdG8gZ2V0IGludG8gdGhlIGNyeXB0YW5hbHlzaXMgb2YgU1BFQ0sgdGhlbiB0 aGlzIHRocmVhZA0KPnNob3VsZCBtb3ZlIG9mZiB0aGUgVExTIGxpc3QgYW5kIHBvc3NpYmx5IHRv IHRoZSBDRlJHIGxpc3QuDQo+DQo+c3B0DQo+DQo+PiBPbiBNYXIgMjEsIDIwMTYsIGF0IDEwOjA3 LCBFZnRoeW1pb3MgSW9zaWZpZGVzIDxpb3NpZmlkaXNlQGdtYWlsLmNvbT4NCj4+d3JvdGU6DQo+ PiANCj4+ID5JIGRvbid0IHNlZSBhbnkgY29tcGVsbGluZyBhcmd1bWVudCBmb3IgdGhlIGluY2x1 c2lvbiBvZiBTUEVDSz8gTm90DQo+Pm9ubHkgd291bGQgdGhlIGFmZmlsaWF0aW9uIHdpdGggTlNB IGdpdmUgdGhlID5UTFMtV0cgYSBiYWQgcmVwLiBpbiB0aGUNCj4+cHVibGljLCBtb3JlIGltcG9y dGFudGx5LCBpdCBtYWtlcyBvbmUgb2Ygb3VyIG1haW4gcHJvYmxlbXMgd29yc2U6DQo+PmNvbWJp bmF0b3JpYWwgZXhwbG9zaW9uID5vZiBwb3NzaWJsZSBjaXBoZXItc3VpdGVzIGluIFRMUy4gVGhp cyBwcm9ibGVtDQo+PmlzIHNvIGJhZCB0aGF0IGl0IG5lZWRzIG11bHRpcGxlIGJsb2cgcG9zdHMs IGFuIGVmZm9ydCBieSBNb3ppbGxhIGFuZA0KPj4+YmV0dGVyY3J5cHRvLm9yZyB0byBnZXQgc3lz LWFkbWlucyB0byBjb25maWd1cmUgdGhlaXIgc2VydmljZXMuDQo+PiANCj4+IA0KPj4gSGkgYWxs Lg0KPj4gDQo+PiBUaGUgcmVwdXRhdGlvbiBhc3BlY3QgaXMgbm90IG5lY2Vzc2FyaWx5IGFuZCBz dHJpY3RseSBjb3JyZWxhdGVkIHdpdGgNCj4+aXQncyBwcm92ZW5hbmNlLCBidXQgd2l0aCBpdCdz IGFjdHVhbCBzZWN1cml0eSBhbmQgcGVyZm9ybWFuY2UuIEFuZCB0aGUNCj4+U1BFQ0sgd2Ugc2hh bGwgbm90ZSB0aGF0IHBlcmZvcm1zIHF1aXRlIHdlbGwuIEFsc28gd2Ugc2hhbGwgbm90IGZvcmdl dA0KPj50aGF0IGV2ZW4gdGhlIGluZmFtb3VzIEFFUyBoYXMgYmVlbiBhcHByb3ZlZCBieSB0aGUg TlNBIGJlZm9yZSB0aGUNCj4+d2lkZXNwcmVhZCB1c2Ugb2YgaXQuIEluIGFueSBjYXNlIGkgd291 bGRuJ3QgbGlrZSBmb3IgdXMgdG8gc3RhbmQgb24gdGhlDQo+PnBvcHVsYXIgcHJlc3MuIE9uIHRo ZSBvdGhlciBoYW5kIHdlIHNoYWxsIGV2YWx1YXRlIGlmIHRoZSBTUEVDSyBjb3VsZCBiZQ0KPj5h Y3R1YWxseSB1c2VkLiBGb3IgZXhhbXBsZSwgdGhlIGZhY3QgdGhhdCBpdCBsYWNrcyBleHRlbnNp dmUNCj4+Y3J5cHRhbmFseXNpcyBpcyBhIHNlcmlvdXMgYXJndW1lbnQgZm9yIG5vdCB1c2luZyBp dCB0b2RheSwgYnV0IHdoYXQNCj4+YWJvdXQgdGhlIGZ1dHVyZSBzcGVjaWZpY2F0aW9ucy4gT24g dG9wIHRvIHRoYXQgd2hhdCBpZiB3ZSBjb3VsZCBwcm92ZQ0KPj50aGF0IHRoZSBTUEVDSyBjYW4g aGF2ZSBiZXR0ZXIgcGVyZm9ybWFuY2UgdGhhbiBvdGhlciBhbGdvcyB3aXRob3V0DQo+PnNhY3Jp ZmljaW5nIHRoZSBzZWN1cml0eS4NCj4+IA0KPj4gDQo+PiBCUnMsDQo+PiBFZnRoaW1pb3MgSW9z aWZpZGVzDQo+PiANCj4+IDIwMTYtMDMtMTggMTk6NDkgR01UKzAyOjAwIEFhcm9uIFphdW5lciA8 YXpldEBhemV0Lm9yZz46DQo+PiBIaSwNCj4+IA0KPj4gPiBPbiAxNyBNYXIgMjAxNiwgYXQgMDc6 MzUsIEVmdGh5bWlvcyBJb3NpZmlkZXMgPGlvc2lmaWRpc2VAZ21haWwuY29tPg0KPj53cm90ZToN Cj4+ID4NCj4+ID4gSGVsbG8gYWxsLg0KPj4gPg0KPj4gPiBJIGhhdmUganVzdCBmb3VuZCBvbiB0 aGUgaWV0ZiBhcmNoaXZlcyBhbiBlbWFpbCBkaXNjdXNzaW9uIGFib3V0IHRoZQ0KPj5pbmNsdXNp b24gb2YgdGhlIFNQRUNLIENpcGhlcg0KPj4gPiBpbiB0aGUgdGxzIHN0YW5kYXJkcy4NCj4+ID4g SXQncyByZWZlcmVuY2UgaXMgYmVsb3cNCj4+Omh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvdGxzL2N1cnJlbnQvbXNnMTM4MjQuaHRtbA0KPj4gPg0KPj4gPiBFdmVuIHRob3Vn aCB0aGF0IHRoaXMgY2lwaGVyIG9yaWdpbmF0ZXMgZnJvbSB0aGUgTlNBIG9uZSBjYW5ub3QgZmlu ZA0KPj5hIHdoaXRlcGFwZXIgdGhhdCBkZXNjcmliZXMgaXQncyBmdWxsIGNyeXB0YW5hbHlzaXMu IEluIHRoZSBhYm92ZQ0KPj5kaXNjdXNzaW9uIE1yLiBTdHLDtm1iZXJnc29uIHNvbWVob3cgcGVy ZnVuY3RvcmlseSBwcmVzZW50cyB0d28NCj4+d2hpdGVwYXBlcnMgdGhhdCBkZXNjcmliZSB0aGUg U1BFQ0sncyBjcnlwdGFuYWx5c2lzLiBBbHRob3VnaCB3ZSBzaGFsbA0KPj5rZWVwIGluIG1pbmQg dGhhdCB0aGVzZSBwYXBlcnMgZGVzY3JpYmUgYSBsaW1pdGVkIHJvdW5kIGNyeXB0YW5hbHlzaXMu DQo+PkFsc28gd2Ugc2hhbGwgbm90IGZvcmdldCB0aGF0IGEgc2ltaWxhciBjcnlwdGFuYWx5c2lz IGhhcyB0YWtlbiBwbGFjZQ0KPj5mb3IgdGhlIGZhbW91cyBBRVMuIFRoZXJlZm9yZSBpIHBlcnNv bmFsbHkgZG8gbm90IHNlZSBhbnkgYWN0dWFsDQo+PmFyZ3VtZW50cyBhcGFydCBmcm9tIHRoZSBm YWN0cyB0aGF0IGNvbmNlcm5zIHRoZSBhbGdvcml0aG0ncyAgcHJvdmVuYW5jZQ0KPj5mb3Igbm90 IGluY2x1ZGluZyBpdCBpbiBhIGZ1dHVyZSB0bHMgc3BlY2lmaWNhdGlvbi4gSW4gY29uY2x1c2lv biBldmVuDQo+PmJ5IHRoaXMgZGF5IHRoZSBTUEVDSyBjaXBoZXIgaGFzIG5vdCBiZWVuIHlldCBm dWxseSBjcnlwdGFuYWx5emVkDQo+PnN1Y2Nlc2Z1bGx5Lg0KPj4gDQo+PiBJIGRvbid0IHNlZSBh bnkgY29tcGVsbGluZyBhcmd1bWVudCBmb3IgdGhlIGluY2x1c2lvbiBvZiBTUEVDSz8gTm90DQo+ Pm9ubHkgd291bGQgdGhlIGFmZmlsaWF0aW9uIHdpdGggTlNBIGdpdmUgdGhlIFRMUy1XRyBhIGJh ZCByZXAuIGluIHRoZQ0KPj5wdWJsaWMsIG1vcmUgaW1wb3J0YW50bHksIGl0IG1ha2VzIG9uZSBv ZiBvdXIgbWFpbiBwcm9ibGVtcyB3b3JzZToNCj4+Y29tYmluYXRvcmlhbCBleHBsb3Npb24gb2Yg cG9zc2libGUgY2lwaGVyLXN1aXRlcyBpbiBUTFMuIFRoaXMgcHJvYmxlbQ0KPj5pcyBzbyBiYWQg dGhhdCBpdCBuZWVkcyBtdWx0aXBsZSBibG9nIHBvc3RzLCBhbiBlZmZvcnQgYnkgTW96aWxsYSBh bmQNCj4+YmV0dGVyY3J5cHRvLm9yZyB0byBnZXQgc3lzLWFkbWlucyB0byBjb25maWd1cmUgdGhl aXIgc2VydmljZXMuDQo+PiANCj4+IEFhcm9uDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBUTFMgbWFpbGluZyBsaXN0DQo+PiBUTFNA aWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5UTFMg bWFpbGluZyBsaXN0DQo+VExTQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby90bHMNCg0K From nobody Mon Mar 21 12:40:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3B12DAA2 for ; Mon, 21 Mar 2016 12:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDLYw5ZDcKst for ; Mon, 21 Mar 2016 12:40:19 -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 90BC812D89D for ; Mon, 21 Mar 2016 12:40:16 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id ED85164460; Mon, 21 Mar 2016 19:40:15 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-61.brq.redhat.com [10.40.204.61]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2LJeE1A009486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Mar 2016 15:40:15 -0400 From: Hubert Kario To: tls@ietf.org Date: Mon, 21 Mar 2016 20:40:07 +0100 Message-ID: <5862743.k85ct04I0v@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2342438.iOIDtIIVtI"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 21 Mar 2016 19:40:16 +0000 (UTC) Archived-At: Cc: Geoffrey Keating Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 19:40:21 -0000 --nextPart2342438.iOIDtIIVtI Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Monday 14 March 2016 12:12:51 Geoffrey Keating wrote: > Colm MacC=C3=A1rthaigh writes: > > On Mon, Mar 14, 2016 at 11:04 AM, Subodh Iyengar =20= wrote: > > > Like Kyle mentioned the thing that 0-RTT adds to this is infinite= > > > replayability. As mentioned in the other thread we have ways to > > > reduce the impact of infinite replayable data for TLS, making it > > > reasonably replay safe. > >=20 > > That too is a mis-understanding. The deeper problem is that a third= > > party can do the replay, and that forward secrecy is gone for what > > likely is sensitive data. Neither is the case with ordinary > > retries. >=20 > Just to expand on this: >=20 > HTTP GET is idempotent and so replayable, correct? That is, if you > send two GET requests in a row, you should get the same results, no > changes should be caused on the server side, and the attacker learns > nothing new, even if the attacker could not have issued the original > GET. Only in theory, in practice you can do most of the same things in GET's= =20 as you can in POSTs. in other words, basically web frameworks can be made to modify server=20= state upon receiving GET request and even just the fact that the server thinks it has processed so many=20= requests can be damaging (think timestamping service in which you pay=20= per request) =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2342438.iOIDtIIVtI 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 iQIcBAABCgAGBQJW8E4XAAoJEJKo0bgB0vX1u0UQAIVF2pF1i6WaYUoeHSfHdvzW lksQ+jf6iR0fuM+dJUqBSjjRdy2prd44SVXQ8OJ8AKYqN+SDW68VgXGeODgw2yoM 9REGud3TwMXB9xTFHHLnpksOgNsolQzc1+0Pxj32AYvPxEBlEA0tRXdIoR4OffRa 8CG+3r+b8xo3/q7QcE10/vQb3vH3l7mpud/bJe0I9OsA4ghX2FTVwfMPusxyFx5D lTKwTjs7GNNW4Qad/UUjXqkEmNdFKp8a4+YYRqPKyyMpLRMRZhgIkI++2DAV8xp8 HI9VESl2WxWGnTznb0ZdvzfjaSPiooJinbNZ9qQ/n1SOG8jnf9Z8UHC01LlOWit+ XIkTdXSxh6guvI8pvlZCK/eMjtuoRF6nh5Pol11Y5Byl46RkpfOwAPLxxlWdXye0 gNnJgZYJFWMyFlylHp/QzYFVFOKxSItCfYa4K/ffwo4x5ODCmxJZLyeXUhvhNYbh Uh/8iY+RCbmpbrAogflOXWCl9nXhObVeLETTYKcB6JnUxXCc5I6k+0H/eyGXHjqi HGbS8fqMVTX05uwOtJWadavuxPAFoWd8jtYA8zjZ4bw0WOqarNvBFKj4AKAy1EzX TGNTrHDL8EUokPzJIzIYU2dkHWuKtXURr0l947QgK/C7SZEuXR7fT/SDkMek4DgH dd2B+N7XBygISI6uCJBK =D+f1 -----END PGP SIGNATURE----- --nextPart2342438.iOIDtIIVtI-- From nobody Mon Mar 21 12:42:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637812DAC0 for ; Mon, 21 Mar 2016 12:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0f3j1ylOdLu for ; Mon, 21 Mar 2016 12:42:07 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::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 F16F412DA51 for ; Mon, 21 Mar 2016 12:42:03 -0700 (PDT) Received: by mail-qg0-x232.google.com with SMTP id a36so129464244qge.0 for ; Mon, 21 Mar 2016 12:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=gxn9c0aa4OI0emmOy1QrlrW+pYLMw+X66AD8X+8yYzI=; b=U4gw4nGHORP5x9qjgWSW9GuYKiK0JuKEHdcy8Jec6eaZxdz5KBaGi4p7yEGdO9FXrC De+9MGsZVetr+FYP+yOJoWSmWrwPJupI0QSTP9eWHZ9N7y4q2BR4Y9T/si6YkQZf0a4A 9Pou3IJ3g9JkkTiZUajglNsxJrkHeoeXK72nYN0EopBHlffGAvFvpGe0ueHfwTnSAdjy KOzN2h3yNXJQO5SD9Dv3JGJAxae8AzWwf+/ey6FklU9t8d1g5xWIjiuRB77n6Jfa286N FqKWMl/iG7pPQTrMaOlurGCFxlgxB6T2dGmJ6kkC7jqQHlYSkSppZNOeinYrXLZLP2PW Xh/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=gxn9c0aa4OI0emmOy1QrlrW+pYLMw+X66AD8X+8yYzI=; b=WcSlbauiLjDa+cjYHewzJD+lxAnPxtor15c22h5algtWHOL3aewmUXGCerKHBrfMS/ 34xJaSGKSJfmMwMLDXrd8KQSmNxx06quROG5F7JTy+GBIEwfbdCxGmTN9fsjExWkzFFI hLZEREc2/TUtNo42w66JAAD03dTdz3absnuvQDMOr9WtFdfOahmy++kqgE25DrC0KhBm qsPdwJoqCEeeQjFlPtucCtDNhmvCZr1coIV7WZQ5tEj0VxHZ0khegAjONzCjWmCNOr/Q RirRNFD0x8ZBx2zFjT2CfY27cWY5zTMNVbWSWiqJbgzfwUvvpKQa6SlYhPdDbwkXoMFl PdiA== X-Gm-Message-State: AD7BkJIMTWfD10Z887fRdZkue5rMZ3C3mVTpaWt262l3xob9wi1pxaL18TYe8+eJi/jwDw== X-Received: by 10.140.93.166 with SMTP id d35mr42008340qge.29.1458589323107; Mon, 21 Mar 2016 12:42:03 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id e34sm12900911qga.4.2016.03.21.12.42.02 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Mar 2016 12:42:02 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Mon, 21 Mar 2016 15:42:00 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> In-Reply-To: <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603211542.01011.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 19:42:11 -0000 On Monday, March 21, 2016 10:38:43 am Hubert Kario wrote: > If your hardware really can't do anything better than 2048 bit RSA, it's > not LTS, it's a crippled embedded system, and it definitely shouldn't > get a stamp of approval "good for next X0 years" or anything similar > like a LTS moniker would imply. +1 Frankly, I think this document should be renamed "Extended Support Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). In anything even approaching the long-term, TLS is dead due to the need for post-quantum crypto, yet to be defined. I'm not even convinced this document is capable of defining a known-good set that can survive for ten years, so that text should really be relaxed significantly. (in this context, 10 years is not "long-term") The bare minimum anyone should be stating for a 10 year window is something like 3248 bit RSA or ~256 bit ECDSA/EdDSA, and only with the qualifier that upgrades will probably be needed at some point over the next decade. Hardware that can't handle this is not short or medium-term viable, let alone long-term. https://www.keylength.com/en/3/ Hardware needs to accommodate the viable specifications, not the other way around. If it takes a second or two to perform a handshake, then that's what it takes until it's upgraded/replaced. Dave From nobody Mon Mar 21 15:00:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B609E12D0DD for ; Mon, 21 Mar 2016 15:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2bbOIB_yUOg for ; Mon, 21 Mar 2016 15:00:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D883A12D0E7 for ; Mon, 21 Mar 2016 14:59:56 -0700 (PDT) Received: from [192.168.10.140] ([94.79.182.6]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M35iN-1ZtJhG0qf9-00swjY; Mon, 21 Mar 2016 22:59:53 +0100 To: Eric Rescorla References: <56E874A4.3030506@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56F06EDC.9080406@gmx.net> Date: Mon, 21 Mar 2016 22:59:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="X3v0HFQF7uvBC9iOwBNBTv1awuCL2t56u" X-Provags-ID: V03:K0:rEw0Wo+B5dANBDg5wYlItMW+NOc4CkSJwfKlAwLbwA7eFbx7mdY njEMIA0eTPvXxly9odyBDgnGvcfMJLZH4kFybu0OObAnIe7ZBP5E/lSpE8ipLyuTifZJiyZ bhtv6WFO5A2/yZQymyhy3icxuI4lNdOLMK03Ab5n5QCVUZ7SmaVgmpdk0nhWw0YVcKbcWMC mc5XGYfqxhTAre04iHkCw== X-UI-Out-Filterresults: notjunk:1;V01:K0:2xxFG/o5BAg=:X6jXypkU0jUDyQbulkVl7L 1ieiGlCCykxPOAyUb9TFwP9tFAhqA7KTY+1m75xbK0LdnOpTE+q2x3H+YDGMUCSD3KVacfx54 MpmN3Eo7UJqTQUwYf4InsNIhb3MThr56woHuZSR1G60SafCMBFvAWmJE0mmXS/nTLq+Z5xhCN a0UMyaUOMEWJckL2oK2sGvpMXpqbr6kitXKq7VOKS64QGpTIqbT5yKQkmUR3CZ5pZMr/m30QU 14Ua+GD6HmUBP9NuzT+7Xkd025k/PbvIWjR4aqUH/nh3oWAfiICvAgWdxI3ek1nH35ZbVKfNT 6qQAM74jnJb+e/HE2sJSMki15K3+BC9Uu854sodPtxeBXNZOLnsrfWsRGdqLPh/k+NW8yXvUq vxYbxeoW7y4MUwJsG54xFmPHUe3mdrpSZp17JAr2UfuAzF2JORvEAaCioIoaNWKDhsZB5cgVR CR6e7Fc8N83B/V3ZPvpQFl4Yqc7xDyjiBcYPMhlpXmW0ThZ+pAClyJ/lSSw3uVbHoeqlWDXPj PQ6u8FLNJ5DpTVQJZIhSBMCtV5YzkUA2eMUC4dYRjqeT5tbeyqtiS0I3cdCDcLEZvYgeSVaxl iZdQg2/D3sOezXC/3ANW1EVE9BNEauYjc7xAZZYGb33DIuo2YiLW2zrs5I+s/4WLQesmL8uEB RIK0O1EflfZEjzB3+OLu5zkx+XX+dYRHq1xBccLIq4MMsfUNEsUeCs0NNwjT9GgM/bZ8FDBJk 4gijMpPKCknHgO9YV586LaIkqY6xqhRmTRROOoEq5r1tlZZXhHXPEMvWrSs= Archived-At: Cc: "" Subject: Re: [TLS] PSK in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 22:00:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --X3v0HFQF7uvBC9iOwBNBTv1awuCL2t56u Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, ~snip~ > Section 6.3.1.2 explains that the ServerHello message handling: >=20 > " > The server will send this message in response to a ClientHello mess= age > when it was able to find an acceptable set of algorithms and the > client=E2=80=99s =E2=80=9Ckey_share=E2=80=9D extension was acceptab= le. If the client proposed > groups are not acceptable by the server, it will respond with a > =E2=80=9Chandshake_failure=E2=80=9D fatal ale > " >=20 > What this text should be saying is that the response from the serve= r > depends on the selected ciphersuite. Implicitly you are saying that= in > another part of the document, namely in Section 8.2 "MTI Extensions= ". >=20 >=20 > Sorry, I'm not following your question here. Can you say more? >=20 The conditions for the server to return a ServerHello are complex and the wording is confusing. The decisions are at least based on: - Is there an acceptable set of algorithms and groups that are mutually supported? - Did the client=E2=80=99s KeyShare contain an acceptable offer? - Is a KeyShare extension present? - Is =E2=80=9Csignature_algorithms=E2=80=9D extension present? - Does msg offer (EC)DHE cipher suites? Ciao Hannes --X3v0HFQF7uvBC9iOwBNBTv1awuCL2t56u Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW8G7cAAoJEGhJURNOOiAte5kH/021eAamzulNBo6oFXT5x9w2 LEv8XDizL25JOOkb+x/gqNDKU0lILSbALPgykwnMREZzuiXGXXTUj8qkNT2q4eYN JlNlGVnwzODtDHGMW3b+iO5lkJsblcLcwvdcIrc8gDe/+KeV43d/Qcehe+LG4ahx 55EyVMJwphsuZW4gbo1LpMcnVOOHq3tv1Hgu82FJArRm3Q5OAnLfLRfap5Qdgu9r 5xLhPtWvJ/ANf2EsZa6fthWaEWBfadTyzTROHAaGzAUl4l6xf0cyZFUeMJBYv4Qs t2h/PGPg2XH/uWB1UcAcJRa5vAEyXVr3/dBnzh2hPO2BXOoaFmTdYzwBEKc+SCM= =qK2z -----END PGP SIGNATURE----- --X3v0HFQF7uvBC9iOwBNBTv1awuCL2t56u-- From nobody Mon Mar 21 15:09:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B38E12D10D for ; Mon, 21 Mar 2016 15:09:46 -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 UIP6U4FiWB1n for ; Mon, 21 Mar 2016 15:09:33 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E3412D0F1 for ; Mon, 21 Mar 2016 15:09:25 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g3so232155537ywa.3 for ; Mon, 21 Mar 2016 15:09:25 -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=CiFC3dv5S0PehfVI4hqmLHQifAKgSfdQbcW5VNCce8o=; b=zduCQdfREAOWjSU3DAMLNkLQWg1SPhGZPO+ts/JRFOopDNHk4//yKiIuClhE39EOLN CeeerGr6zjglMwxW29JnKC66vYLOVphyg8byIiA4PW4XeMCAvh1xI/Ksd8kNXSR93NJl 87VnBjP8r5ppWE++8uz4Gtk0ko5b/cG41/xpSwUGL/M8snOnDaL6WaR4qoyAWQ6t49o4 lHUK3vIWnhMhSUC9dFDXKBo7Oq4EXG+rhIUvFXYaWCPu0+Rmn1XB5Qnmb0EPA/MJJCQF AZJMZ2C3zqW8yo5hWstRwogU9vB0EypWvjsJk0I6zsiME0IMxf3CpQ2fDBfDwvZwY9tA djFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CiFC3dv5S0PehfVI4hqmLHQifAKgSfdQbcW5VNCce8o=; b=jyVPxV3SfTY80yPkQe86jdv9QG0VxnqYEoxrY5nq060Dhe8TgoNFR8XE3Cek9kGUGo mS86uMQ2tMX2J65fiOAdmXP9ms7ff2Djq4WCntZNBhl8G+DhTU+j6J3leAIgLL09dkQ+ 9Qmkid5kqcNLev2VkKa4Gw160jHfqBOtSHKQ6/URZk3adVx1kTnGFz0BEe6p044yJksa /YpKxzojpw2CZHGfSrX37hph3zq8OxyRscKxduiITbf9g/vC41atQabSQSx/0plNCaQ6 r0ig5cQT/FtMpJD0IkTq4iq1r9I+c0xk5WxEz0TwvDkrj+BMgrk92LidcA2eqOHLdK0s siPQ== X-Gm-Message-State: AD7BkJJGTrI92lMAK6dMHv64WEBtzfLxyVPGn8AwCnFdISc77Vt03RqXPtY7iq4fCRT6xLuuzmo3PnyObeMtKA== X-Received: by 10.129.46.87 with SMTP id u84mr14521721ywu.129.1458598165166; Mon, 21 Mar 2016 15:09:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 21 Mar 2016 15:08:45 -0700 (PDT) In-Reply-To: <56F06EDC.9080406@gmx.net> References: <56E874A4.3030506@gmx.net> <56F06EDC.9080406@gmx.net> From: Eric Rescorla Date: Mon, 21 Mar 2016 15:08:45 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a114140ba816cf6052e96591b Archived-At: Cc: "" Subject: Re: [TLS] PSK in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 22:09:46 -0000 --001a114140ba816cf6052e96591b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 21, 2016 at 2:59 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Ekr, > > ~snip~ > > > Section 6.3.1.2 explains that the ServerHello message handling: > > > > " > > The server will send this message in response to a ClientHello > message > > when it was able to find an acceptable set of algorithms and the > > client=E2=80=99s =E2=80=9Ckey_share=E2=80=9D extension was acceptab= le. If the client proposed > > groups are not acceptable by the server, it will respond with a > > =E2=80=9Chandshake_failure=E2=80=9D fatal ale > > " > > > > What this text should be saying is that the response from the serve= r > > depends on the selected ciphersuite. Implicitly you are saying that > in > > another part of the document, namely in Section 8.2 "MTI Extensions= ". > > > > > > Sorry, I'm not following your question here. Can you say more? > > > > The conditions for the server to return a ServerHello are complex and > the wording is confusing. > > The decisions are at least based on: > > - Is there an acceptable set of algorithms and groups that are mutually > supported? > > - Did the client=E2=80=99s KeyShare contain an acceptable offer? > > - Is a KeyShare extension present? > > - Is =E2=80=9Csignature_algorithms=E2=80=9D extension present? > > - Does msg offer (EC)DHE cipher suites? > Ah, I see. Let me see if I can clear this up, if you wanted to send a PR, that wouldn't help too. -Ekr --001a114140ba816cf6052e96591b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 21, 2016 at 2:59 PM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:
Hi = Ekr,

~snip~

>=C2=A0 =C2=A0 =C2=A0Section 6.3.1.2 explains that the ServerHello messa= ge handling:
>
>=C2=A0 =C2=A0 =C2=A0"
>=C2=A0 =C2=A0 =C2=A0The server will send this message in response to a = ClientHello message
>=C2=A0 =C2=A0 =C2=A0when it was able to find an acceptable set of algor= ithms and the
>=C2=A0 =C2=A0 =C2=A0client=E2=80=99s =E2=80=9Ckey_share=E2=80=9D extens= ion was acceptable. If the client proposed
>=C2=A0 =C2=A0 =C2=A0groups are not acceptable by the server, it will re= spond with a
>=C2=A0 =C2=A0 =C2=A0=E2=80=9Chandshake_failure=E2=80=9D fatal ale
>=C2=A0 =C2=A0 =C2=A0"
>
>=C2=A0 =C2=A0 =C2=A0What this text should be saying is that the respons= e from the server
>=C2=A0 =C2=A0 =C2=A0depends on the selected ciphersuite. Implicitly you= are saying that in
>=C2=A0 =C2=A0 =C2=A0another part of the document, namely in Section 8.2= "MTI Extensions".
>
>
> Sorry, I'm not following your question here. Can you say more?
>

The conditions for the server to return a ServerHello are complex an= d
the wording is confusing.

The decisions are at least based on:

- Is there an acceptable set of algorithms and groups that are mutually
supported?

- Did the client=E2=80=99s KeyShare contain an acceptable offer?

- Is a KeyShare extension present?

- Is =E2=80=9Csignature_algorithms=E2=80=9D extension present?

- Does msg offer (EC)DHE cipher suites?

Ah, I see. Let me see if I can clear this up, if you wanted to send a PR, = that wouldn't
help too.

-Ekr


--001a114140ba816cf6052e96591b-- From nobody Mon Mar 21 15:44:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C117312D0DB for ; Mon, 21 Mar 2016 15:44:00 -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 bP6PbAzKO7b4 for ; Mon, 21 Mar 2016 15:43:58 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6495212D0AE for ; Mon, 21 Mar 2016 15:43:58 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id l68so140339644wml.1 for ; Mon, 21 Mar 2016 15:43:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gT87PyibjkEntJddowVl3g5YOIWb0Nn2W+FwGt480M0=; b=f2912zs0D1O1U6LqbSCNyP9HGCvhJIQJ+sQSEX5jADzI1J12h/b8lnqu2qtSJng/Nx a4uPe6plybnrzuSKboTKHBjgXTyUi8sMmSQRxnXmQ6P85U0cKpSWSXoYktOKqrHimvz2 cUhLmByANh4FEBHYrMt+VZ9WftTJwwxmnxQzS/iHjRyQW9Ehn4MAeVu1OY1AD7jt0d4G mUua+c+82yn4Cd34I6ZaIncTsvyiZ2Bno/pF2hrgr9+b4O7K9T7RK7CiJ86LtKhhW5YH 3xO6yKPRRfeQgYdOlDHMQ7/yw1KnmrlP8QPSerz7wCFS383rsU2z3VNniEhWme4ye9uZ Dj7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gT87PyibjkEntJddowVl3g5YOIWb0Nn2W+FwGt480M0=; b=QJJInVJMFDjrsXokwDpudwJIBNlfnolSnIOvXKwr98jOC426JH6LJmUdVUi1HB/LNW ZykfdH3VvAKh6bo/ucconAn4kLQ80YCKisqh3JA5OjeUxLSqEhAf4BYRXoqe2yLhGRUM y6LwvqI+axkusRY7+tXPN7kzMRdykvc+6nPMJokq4X14orm/hvlEFXbi3mf22akEj3gq XXDUQd1Q5UJ0w3Vyog4uLDeX2ShdtjN2IObYBYfZVspZ2EuC8ljkwedWfl7/2Zkwxlke culVc8yVVJk+COwa68y6dVC7JaUDGvacMUf+5HsIZrBnFVNnlBA01IlQM3npKPMeMnM5 dCRg== X-Gm-Message-State: AD7BkJL0VhiVGD0+cDkFoezZAF/09EKMLazPM52DHShJvXylupn0grI10PlS8zDnd2E3LA== X-Received: by 10.28.127.151 with SMTP id a145mr17035381wmd.53.1458600236972; Mon, 21 Mar 2016 15:43:56 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id 8sm14457970wmk.13.2016.03.21.15.43.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Mar 2016 15:43:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <1c0fb8f002d44a8b8073d9df9913a451@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 22 Mar 2016 00:43:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603191930.35445.davemgarrett@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27783@uxcn10-tdc05.UoA.auckland.ac.nz> <20160320110945.GA30544@LK-Perkele-V2.elisa-laajakaista.fi> <9A043F3CF02CD34C8E74AC1594475C73F4C279D0@uxcn10-tdc05.UoA.auckland.ac.nz> <8AE45263-3667-4B0B-974F-CB6B2BD20AAE@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C27A2B@uxcn10-tdc05.UoA.auckland.ac.nz> <26C23DDE-0BE5-486F-B6EB-FD181E2EDFEF@gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28374@uxcn10-tdc05.UoA.auckland.ac.nz> <1c0fb8f002d44a8b8073d9df9913a451@usma1ex-dag1mb1.msg.corp.akamai.com> To: Rich Salz X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 22:44:01 -0000 > On 21 Mar 2016, at 3:19 PM, Salz, Rich wrote: >=20 >=20 >> OK, I've posted another update that specifies this, as well as use of = EMS, and >> cleans up a few other areas. It's a bit of a rush job because of the = impending >> lockdown for IETF 95, but hopefully the gist is there: >>=20 >> http://www.ietf.org/id/draft-gutmann-tls-lts-02.txt >=20 > So is someone "in the camp" coming to BA and can present this? Or = remotely? I don=E2=80=99t know who=E2=80=99s =E2=80=9Cin the camp=E2=80=9D. I = don=E2=80=99t think I am. But if someone would like to prepare slides = and request a slot, I can volunteer to present them. This usually turns out better than presenting remotely. Yoav From nobody Mon Mar 21 16:13:01 2016 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 AE7FB12D177; Mon, 21 Mar 2016 16:12:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160321231255.12215.23672.idtracker@ietfa.amsl.com> Date: Mon, 21 Mar 2016 16:12:55 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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, 21 Mar 2016 23:12:55 -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 of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Authors : Yoav Nir Simon Josefsson Manuel Pegourie-Gonnard Filename : draft-ietf-tls-rfc4492bis-07.txt Pages : 31 Date : 2016-03-21 Abstract: This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards Digital Signature Algorithm (EdDSA) as new authentication mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-07 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 Mar 21 16:45:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C4412D18A for ; Mon, 21 Mar 2016 16:45:34 -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 K6bw5P7fEfpK for ; Mon, 21 Mar 2016 16:45:33 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 75F0C12D10B for ; Mon, 21 Mar 2016 16:45:33 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id 124so75558613iov.3 for ; Mon, 21 Mar 2016 16:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=CSPtgVSS5OqTcXwlepqLMS3nNoj58lvK15XFl7lI15o=; b=RVV4Yf86+LwCvch8K9v7H1xdUtZK9tXDAtDMlp4HY7ZfyFbfDsxEDyQQW+vQQDLktf 2iLZbGsuM9CKV8Qw3oUERy9y84KZ8kVAkqIpbCgyNOUfLRWtdRIoUEMGKt49LZQzMqa7 UTejH6D+VXBtzuqRQXHLC1B/gj5vwIyvMir2RubGNyjF3pk/JZ12rNtWelixgYUmoLjl 98XU/oTOMcFaczkmoAuzN2Kes2M73bKwtfCPwUJFPPNXNvY2WglUPkAOmS2zQEqjXqb/ slIWvVln8OTKxxXtEzsVdRJiob7eMYdG7cu5YNejIjZqNljx7J+JdXQFXSMOkSzIT0Tj L4Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=CSPtgVSS5OqTcXwlepqLMS3nNoj58lvK15XFl7lI15o=; b=eUcmN3+80yU407ufWblOtOlWCZloA/bF+U1FFarW5/LqzNLxwjioTjcE+iblCjJmSM iwGCr4YwjiQMiASRx6zllFbtJNFywsXeDiUI9HgBavtZqOaSdiEoqmCg+uaZpYNw59t3 VQ29k02MfdtJ++dWLrnO9+xQ148sP61pWJzeF5QfZdBzoalA+GNsWRhd3BgkZvhE9Lm3 +k5JjYLyvVBKgVIgyjmDpPWUNpk/bk6jB7QZRXX/X9UTGXa9hGEGv52NOj/K4QaQA1ut av5Wr7iKWmesP1fhJBawpnsKfRWJG0n6664LxlUoYR0HlL0L9HfO3cJrohtBSEaZFLJM u0GQ== X-Gm-Message-State: AD7BkJImGOgxGmAzH4iOBKsUV82opcKh9XOE4OJ0KU4B/3Y2rJZGa8TSZIGKqzL2uhF9jZrSq5Q4Q6TvCg+wUA== MIME-Version: 1.0 X-Received: by 10.107.131.105 with SMTP id f102mr33048501iod.190.1458603932889; Mon, 21 Mar 2016 16:45:32 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Mon, 21 Mar 2016 16:45:32 -0700 (PDT) In-Reply-To: <5862743.k85ct04I0v@pintsize.usersys.redhat.com> References: <56E54B85.4050204@cs.tcd.ie> <5862743.k85ct04I0v@pintsize.usersys.redhat.com> Date: Tue, 22 Mar 2016 10:45:32 +1100 Message-ID: From: Martin Thomson To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" , Geoffrey Keating Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 21 Mar 2016 23:45:34 -0000 On 22 March 2016 at 06:40, Hubert Kario wrote: > Only in theory, in practice you can do most of the same things in GET's > as you can in POSTs. > > in other words, basically web frameworks can be made to modify server > state upon receiving GET request Ahh yes, but it's not the *client's* fault if the server does that and the client tries multiple times. The server is entirely responsible for the consequences of state modification at that point. From nobody Mon Mar 21 18:06:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B14212D1A7 for ; Mon, 21 Mar 2016 18:06:11 -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 8d9a-Qgk4w-K for ; Mon, 21 Mar 2016 18:06:09 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B17AC12D515 for ; Mon, 21 Mar 2016 18:06:09 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g3so236038806ywa.3 for ; Mon, 21 Mar 2016 18:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0rxSeW8GqHRoVc/YgH+Alp5vzQLoBHN+DNkate7pGXA=; b=1+GOr5p58IZEp3dfRWa5WdG18NrckGWwdgDwf96nv4oUi/piKzg/dQE6Swkk7UFsW3 L7jizvsuqp0fwwv9emhTWIcXTaNNp+EQnH5jlsZDiNKWefL2mwkiPCxNlQJ74ov2E9z2 4tWSSUjb15BkDmeLCpYzR5LHRZwdFF1LeJpW6TJVbPgsRMGeyGtcPt+gPvGm+O5OVhqr 5X7Hz6dP0JCjlbDrBH8Cxd4EVEtOg+3bcSZGYwhj33cMHoUTKZ1p1y87nMg/fwHRaOwh 6nKxMaQKejI2XFdIP8u95qpooPTkKHix4/NixYxJQAHAV5xU5Y+03iSvk/BDHm7+ZX7i P59A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0rxSeW8GqHRoVc/YgH+Alp5vzQLoBHN+DNkate7pGXA=; b=Q37ljTXLo2hhvYGB/RA9owpr2yqkTH3HmbA3+jJHG5AA5M6+GRx0B7Be5DY//hw9fY rfEPKNWtpFtculG8kUlTjaQOIRMojBAoAZE7VWFcAIOtKs3Q4VchDAkPWWbwQj28GJ2V hjw4cy609Koy6LGa3TwIQ9OnCPj4sbH8nPhWnB3feYmVV8mYBQ9pOD3MWzAhKGh4i4Qw TInPTsUMy4uM3mq8rtoGUFXtZcHj1Sqw6z+ecsEj/gNaoU39tIyrna+1A2UViJE3imzS Rg8pJE0HGWKM+glChF0e9pnG59bzw4XW9412izGBM6fK0fwe+HBoBm0QwY9NiXwp16/y N+MQ== X-Gm-Message-State: AD7BkJLhHl+sWy79zxZrdeyF1j3YAGWzWtRpRfEZ16MpCqwbpzOKJvb0DeSnfB+eMEeP5clwUWebL6q43u5/Lg== X-Received: by 10.37.231.137 with SMTP id e131mr7053407ybh.130.1458608768944; Mon, 21 Mar 2016 18:06:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 21 Mar 2016 18:05:29 -0700 (PDT) From: Eric Rescorla Date: Mon, 21 Mar 2016 18:05:29 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b1d6c8a3932052e98d144 Archived-At: Subject: [TLS] TLS 1.3 draft 12 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:06:11 -0000 --94eb2c0b1d6c8a3932052e98d144 Content-Type: text/plain; charset=UTF-8 Folks, I've just submitted TLS 1.3 draft-12 and it should appear once it makes its way through secretariat processing. Until then, you can find it at: http://tlswg.github.io/tls13-spec/ This revision is largely cleanup of a bunch of outstanding PRs and of issues found during interop testing. It should be largely wire compatible with draft-11 and also defines preliminary code points in a few places where we had to define them to do implementations. I've attached a changelog to the end of this message. Note: I have taken no action on the topic of 0-RTT DHE (both with and without Client Authentication). I believe we are nearing consensus but I'll work with the chairs to bring it to resolution. Also, look for a proposal to flesh out the details of 0-RTT PSK, which I recognize is currently underspecified. As usual, please send comments to the list or as Github PRs. Thanks -Ekr CHANGELOG - Provide a list of the PSK cipher sutes. - Remove the ability for the ServerHello to have no extensions (this aligns the syntax with the text). - Clarify that the server can send application data after its first flight (0.5 RTT data) - Revise signature algorithm negotiation to group hash, signature algorithm, and curve together. This is backwards compatible. - Make ticket lifetime mandatory and limit it to a week. - Make the purpose strings lower-case. This matches how people are implementing for interop. - Define exporters. - Editorial cleanup --94eb2c0b1d6c8a3932052e98d144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Folks,

I've just submitt= ed TLS 1.3 draft-12 and it should appear once it
makes its way th= rough secretariat processing. Until then, you can find
it at:


This= revision is largely cleanup of a bunch of outstanding PRs and of
issues found during interop testing. It should be largely wire
c= ompatible with draft-11 and also defines preliminary code points in a
=
few places where we had to define them to do implementations.
I've attached a changelog to the end of this message.

<= /div>
Note: I have taken no action on the topic of 0-RTT DHE (both with= and
without Client Authentication). I believe we are nearing con= sensus but
I'll work with the chairs to bring it to resolutio= n. Also, look for
a proposal to flesh out the details of 0-RTT PS= K, which I recognize
is currently underspecified.

<= /div>
As usual, please send comments to the list or as Github PRs.
Thanks
-Ekr


CHANGEL= OG

- Provide a list of the PSK cipher sutes.
=

- Remove the ability for the ServerHello to have no ext= ensions
=C2=A0 (this aligns the syntax with the text).
=
- Clarify that the server can send application data after it= s first
=C2=A0 flight (0.5 RTT data)

- R= evise signature algorithm negotiation to group hash, signature
= =C2=A0 algorithm, and curve together. This is backwards compatible.

- Make ticket lifetime mandatory and limit it to a week.<= /div>

- Make the purpose strings lower-case. This matche= s how people
=C2=A0 are implementing for interop.

<= /div>
- Define exporters.

- Editorial cleanup<= /div>


--94eb2c0b1d6c8a3932052e98d144-- From nobody Mon Mar 21 18:59:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100C412D1E1 for ; Mon, 21 Mar 2016 18:59:49 -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 pWvTQK8P8QJJ for ; Mon, 21 Mar 2016 18:59:47 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2B012D0E1 for ; Mon, 21 Mar 2016 18:59:47 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id m184so230445711iof.1 for ; Mon, 21 Mar 2016 18:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1RtlV0MDFSEfcQvfWEh7fTRmmiw05JV0npl9Fzjj5L8=; b=buGCjTPi2tCYgwpQWmARfERT0MkRzdk06haELzyl9YPd3qSKvuDybtX96qDYfpdLAO LGK6XMCRBjClUVwKCYlNa43YtAhvBRDcYMaLdALnD6XD3sRjVhvicc5Z3uP+PSBpDyUc 6HNrzAoMjIOWMmbzxx1/aBzO27RR/sW9K4hqJPKFhuiRyLfbiyjoHdlGFemvXx7jFapY U2iSmZoCTlGi3nbY3A67uff/z+M1Ha7YsfSwRc5MHFK4ydFS6qDvv5gf9RlTueSp4/NS 7ywtITv6IgiErZ3LzMfoqLBqeLISi2uRCdkI7JSYa5XIIEBxy/Wess0Wtf/UASc0K3G4 2f8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1RtlV0MDFSEfcQvfWEh7fTRmmiw05JV0npl9Fzjj5L8=; b=iX0iPyClG9ZQnBO/65JC4SiZP6iuLx010Ii6bFt0n5foDU7+kELZ9+vYLRp3bbAAaA FAEo3h9eU1n8ZzHYJr4Za+tkwBuLG6bYG1ofmoOg7OreBrNPJaLtifJHYuPx5N8g+p99 Fz/BkDs0GDIlOVb7NGj69UU/Oj2aYkCCn8NYBJ6yVQBqCokHpSMt0Pd6D2qfZPkU9Ing e2Z8RoLGcdyR92Riv+cPNTEt3SrRzlB+bx987ibtElX3YeeIJpOTCG1WCLOBAyO8EEP0 1+nBT11cbJo735VyUjn1f9KkwZiAMnOUXfhHkmlqKRg82ojTYz61/pesVM/NvT1a1Z9r lM4g== X-Gm-Message-State: AD7BkJIugegowbbMvocjt7sb0CUgbXiYOqONSjN+PIpPzgsev5caPjOzoaAGuG9Mi+qqkv5y+fulFbStzrEC4A== X-Received: by 10.107.164.84 with SMTP id n81mr32352776ioe.25.1458611987059; Mon, 21 Mar 2016 18:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.132.4 with HTTP; Mon, 21 Mar 2016 18:59:27 -0700 (PDT) In-Reply-To: <201603211542.01011.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz> <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> <201603211542.01011.davemgarrett@gmail.com> From: Tony Arcieri Date: Mon, 21 Mar 2016 18:59:27 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11421b9e5a9b96052e999144 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:59:49 -0000 --001a11421b9e5a9b96052e999144 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett wrote: > Frankly, I think this document should be renamed "Extended Support > Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). Legacy Support Profile? Then you don't have to change the acronym -- Tony Arcieri --001a11421b9e5a9b96052e999144 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11421b9e5a9b96052e999144-- From nobody Mon Mar 21 21:22:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95712D5AA for ; Mon, 21 Mar 2016 21:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9Rd3REC3Aim for ; Mon, 21 Mar 2016 21:22:37 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 547D112D122 for ; Mon, 21 Mar 2016 21:22:37 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id w104so169493574qge.1 for ; Mon, 21 Mar 2016 21:22:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=5tJGbY+62mMqorE5fmS0BBFowG447JybGYEKSxBAIkk=; b=kQ/9cWyaat4MeOWh8c2z8EecZWxfKYxHSw1eA7PpTUKK3nZ8hCADqnUyYOblWCt1rj 8qnUTI1QKHA5x9WNw45vsdhuhX6m3U/oQdU2HwCAst1UVqpnN/8U9F/y8kkubba+r09W fPTRcvGcgvj3lkGUVsLCrO05FCR/rvg7xrehWE6uFA6AorzR81bOX+1UysIw/kEiYyKp Kdnz6QySREuD566YUhGk7ewQhxg+1bz1IpPI8OrBq9wpLUpevm+fOz1lKvYz/+paNBHH ulhW81vPBQMZfPONxdWpZSx19zH1sm9/AcSkom8sWRACp7DvlyQEruFcmDJMP8riI3RX 7Oyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=5tJGbY+62mMqorE5fmS0BBFowG447JybGYEKSxBAIkk=; b=IRjHmGH09FjQJqOLpFo/m8FCV7qu9fiDkjqlTPRRIMwa0c53HPARprBE28unVY8wqD 5wMHbYFwUPskBqZ0MgpIRoSMmOs7v/Tl2bFrqLgWI0exNLH8I6bhk9v9/kCdAFrGaKy+ mVWaUU7WJK+hPak35SbB1qn+UzpgEAvjMLz1bW1DHMa8tuzfuziU7y0oMvwWTa8RtRBB 3omXKiVwDwCMAxunSTC5n6mm4RHqBgLedIlk6D9EeXWqDCxdFweo3ZzICjiLcgpxjDxy xd9n/6sHpSonYecdrNln8fpi9ADfrTj6UiDtSly7Mwn7WR8bL7eb7GPQ4wZ2Vslv7yos E1Sg== X-Gm-Message-State: AD7BkJJoEVDqVFyFwdXEb/b/o3F4htaKU67qD9O+zHWrSNRo/Rx0kBlMWihw6o5QW/D+rg== X-Received: by 10.140.220.207 with SMTP id q198mr47366550qhb.103.1458620556471; Mon, 21 Mar 2016 21:22:36 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id s8sm13708495qhb.20.2016.03.21.21.22.35 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Mar 2016 21:22:35 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 22 Mar 2016 00:22:33 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56E874A4.3030506@gmx.net> <56F06EDC.9080406@gmx.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603220022.34304.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] PSK in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:22:39 -0000 On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote: > Ah, I see. Let me see if I can clear this up, if you wanted to send a PR, > that wouldn't help too. I assume you meant "wouldn't hurt" or "would help" here. ;) Dave From nobody Mon Mar 21 21:26:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEA512D611 for ; Mon, 21 Mar 2016 21:26: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, 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 VbYefgz1VyZO for ; Mon, 21 Mar 2016 21:26:49 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 9570A12D5AA for ; Mon, 21 Mar 2016 21:26:49 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id w104so169540376qge.1 for ; Mon, 21 Mar 2016 21:26:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=jzM7MHCqPI3aOKqv/mkg9m1vJXiOEscnJ447nU2DODE=; b=TcS+qphPNmJLFdTeIHU+8/Fy9Xh6vcrwy9rzNNZ32Bf1t8TBBwGgOWN2WBCR4QcJ3s nOkUK8XA4iNKus4u/ebsu9vlq62wHdJYGDhQ1JJHjP5sAmhMpGEYoa/W3dRDkrqQ6IGN M1rdJwUOdg6ZmPkRB9UEgTpi54FwL6vER/GePe5Np8ESXQp4nZQ7Wa5JdXYJaUZWbfLz 9OLa9LFROVihnjc8N0ca54hYOPH02PsAkRhIG++xsx8qaG72A//BqjTAwK5EUosJd7Xu gRTdEkbJDs59S/Qb/DMb6MouvonJL+WXOixkKLZXxAxkFBRKrN1IetAEsiimmTnYoWi2 PEwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=jzM7MHCqPI3aOKqv/mkg9m1vJXiOEscnJ447nU2DODE=; b=MKBAJRTfBO2siri1zj5aqSGaBY1Xkm2kiSQIASViPP+R6q37p8MhGKngS1TqZBw3Rg RctvOTmXLUEmc/fzNoEuxn3WKv1mSkAxazb9sGj0S8jo8MYZHh56v1IqSZqOWS1fgkL7 45vVwDZDBvV4RdFeqp/F/UKjWttRQz8OtnQe5Yvem1Oy7AuCLKnQ7989Li2CAHW87rpd 9jbUVyNrxWqzfJJVeBbXS9BC4F8DuImKOpvBllkt+W2LxszXLXfMQoJ5pZ5X3uAT0Gvo l1ecPo2PVH91uCk83mEx5GYHOJ76dp+kqjq42LFVF/0uESuMo5bm3pUXg0vvb7aWYOml 9FVw== X-Gm-Message-State: AD7BkJLFcfoGn3WkgMzzSmk8SPpX335mXbUTB0yBXW6SE5h5GtC0I3cIlin/ghDhQxI0fQ== X-Received: by 10.140.22.101 with SMTP id 92mr44285553qgm.64.1458620808824; Mon, 21 Mar 2016 21:26:48 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id q198sm13740290qhb.16.2016.03.21.21.26.48 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Mar 2016 21:26:48 -0700 (PDT) From: Dave Garrett To: Tony Arcieri Date: Tue, 22 Mar 2016 00:26:46 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603211542.01011.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603220026.47012.davemgarrett@gmail.com> Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:26:51 -0000 On Monday, March 21, 2016 09:59:27 pm Tony Arcieri wrote: > On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett wrote: > > Frankly, I think this document should be renamed "Extended Support > > Profile", rather than "Long-term Support Profile" (and ESP instead of LTS). > > Legacy Support Profile? Then you don't have to change the acronym I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"... ;) Dave From nobody Mon Mar 21 21:32:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB93A12D558 for ; Mon, 21 Mar 2016 21:32:02 -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 I0494h6DLoN0 for ; Mon, 21 Mar 2016 21:32:01 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001: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 45D6412D5AE for ; Mon, 21 Mar 2016 21:32:01 -0700 (PDT) Received: by mail-ig0-x22f.google.com with SMTP id ig19so82974748igb.1 for ; Mon, 21 Mar 2016 21:32:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=v7yrvN+f71PRM+yz1aQcPnq4pvhO0NVgdH30iR9d1Fs=; b=M2sJPxvOSSYC+Se62nNpcEScxt5pjQBUTRimYcu4karWp7I/Xu0NBhQGrgJuGrnh/d Jn0OAmQpR2CC3eVfqaiqlvtWi57+zOH3kqpJqh8cTRDNtR7CmXX3+4FDh+ssgZFmCzhK cbS2IPzwy4AixwhISGex9nBFL8coCN4oPvP9Ulxa/kG9lGhHFQQJxj4GgoSx9IuzgKDA esnlccJSCRAVDxqsbutmxVAX2oiCWNcP6uR6vzfKDQoMNO/ejwI1Qmjm88e3aOoDQP0X TDqhxYWPBXpCh6LZLdLA9W1/JKUs/R4uYc/51xHz5hi7S2i9wrDhwn+6k/WexvlG0ERO ExgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=v7yrvN+f71PRM+yz1aQcPnq4pvhO0NVgdH30iR9d1Fs=; b=XVa4Cl4QvLT32Ddmj8CzsUql8kVyLfCSO7MAxfriSr/ZvPAotfyEsZf5GYQv2M+YVh G06ksHT8BmKamlHAvFH1xTJnNAeDllahmn412VaUFIG80z9Ebf2k+8DciNNTfG5ev1b/ QD4+T4XtsUYJ++1HdU5T2x+WaCZmiIzD1LF6pn+5qHdaTmP9w4rjx3tAOPNfN2boAr2S ktdgWJqIB20rpjfhW5iGJjbNz0jLaKIGZDl8CWdi0RfsdsQI9MXcTI7tqBKRMOnroQ2f DL8BwOFiStLkDBmo9ws0bVlFZd8W6EnGcCW5CT+SQxZ/+9KpZK5TAIZqsaaQYb4x02du KsHg== X-Gm-Message-State: AD7BkJKYWAV0T8BAa6vz7V25jtiB7EaMBJ2NTYFtjdZehPB15fr33+lM8Z9WNJp/cvvYNGB34NJNjrRkq0+f3w== MIME-Version: 1.0 X-Received: by 10.50.20.161 with SMTP id o1mr13899422ige.2.1458621120529; Mon, 21 Mar 2016 21:32:00 -0700 (PDT) Received: by 10.36.132.4 with HTTP; Mon, 21 Mar 2016 21:32:00 -0700 (PDT) In-Reply-To: <201603220026.47012.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603211542.01011.davemgarrett@gmail.com> <201603220026.47012.davemgarrett@gmail.com> Date: Mon, 21 Mar 2016 21:32:00 -0700 Message-ID: From: Tony Arcieri To: Dave Garrett Content-Type: multipart/alternative; boundary=047d7bd75708c04dbc052e9bb197 Archived-At: Cc: "" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:32:02 -0000 --047d7bd75708c04dbc052e9bb197 Content-Type: text/plain; charset=UTF-8 On Monday, March 21, 2016, Dave Garrett wrote: > I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"... ;) > Haha, oops. LSP? -- Tony Arcieri --047d7bd75708c04dbc052e9bb197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 21, 2016, Dave Garrett <davemgarrett@gmail.com> wrote:
I don't exactly see a 'T' for "LTS" in "= Legacy Support Profile"...=C2=A0 ;)

Haha, oops. LSP?=C2=A0
<= br>
--
Tony Arcieri

--047d7bd75708c04dbc052e9bb197-- From nobody Tue Mar 22 02:14:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F6A12D66E for ; Tue, 22 Mar 2016 02:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 QczmpeNSI4cZ for ; Tue, 22 Mar 2016 02:14:44 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47A6D12D65A for ; Tue, 22 Mar 2016 02:14:44 -0700 (PDT) Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 437E51FE02; Tue, 22 Mar 2016 10:14:41 +0100 (CET) Message-ID: <56F10CFF.8020603@secworks.se> Date: Tue, 22 Mar 2016 10:14:39 +0100 From: =?UTF-8?B?Sm9hY2hpbSBTdHLDtm1iZXJnc29u?= User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Efthymios Iosifides References: <690C4271-64DE-4F61-8283-C5BE7A575BFC@azet.org> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: klimn@di.uoa.gr, tls@ietf.org Subject: Re: [TLS] Include Speck block cipher? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:14:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Efthymios Iosifides wrote: > The reputation aspect is not necessarily and strictly correlated > with it's provenance, but with it's actual security and performance. > And the SPECK we shall note that performs quite well. Also we shall > not forget that even the infamous AES has been approved by the NSA > before the widespread use of it. In any case i wouldn't like for us > to stand on the popular press. On the other hand we shall evaluate if > the SPECK could be actually used. For example, the fact that it lacks > extensive cryptanalysis is a serious argument for not using it today, > but what about the future specifications. Hold on here. There is imho a fairly big difference of how AES came about with an open competition compared to how Simon and Speck has been developed. Yes, NSA was an important part in the selection of Rijndael as AES. But that is not the same thing as they actually designed it. Right? Also, there has been tens of ciphers proposed the last few years aiming for the ultralight space. Some of them are as complex in terms of code and data requirements as Speck and sports about the same performance. See for example: https://eprint.iacr.org/2013/295.pdf http://www.ijsce.org/attachments/File/v3i5/E1933113513.pdf Most of these are Feistel based and some of them uses S-boxes. But there are really quite a few alternatives. And besides, as is shown in those links AES can be implemented to not hog resources. The internal operations operates on Bytes. The big issue is the S-box and the extra space needed if you need to expand the key (which is only really needed if you need to decrypt. If you use a good cipher mode, it i not needed.) > On top to that what if we could prove that the SPECK can have better > performance than other algos without sacrificing the security. Start by proving that. Based on what is published I think it will be hard to show significant gains with Speck compared to other ciphers. The two papers published so far on the cryptanalysis does not give me a good warm feeling for long term security of Speck. And the last point is really the thing, right? We are talking about a cipher for embedded stuff, Internet of Things devices. These things are deployed and will be doing their chores for 20-30+ years without much love and maintenance. The communication are typically low bandwidth and with good delay resilience. So what is needed is something cheap (compact in terms of resources) and good, well proven security. I don't see Speck shining much brighter than others in this respect, on the contrary in fact. If you look at what MCUs are used for IoT today and moving forward it is quite probably an ARM based device (Cortex M0, M0+ for example). AES can be implemented very compact and give good performance on this architecture. And even better, for well under 1 USD you can get an ARM based MCU with AES in HW. I fail to see why anyone would be interested in Speck and would never recommend anyone to use it. But hey, write a draft and try to get an informational RFC for it if it scratches your itch. There are several other RFCs describing ciphers not being used very much. - -- Med vänlig hälsning, Yours Joachim Strömbergson - Alltid i harmonisk svängning. ======================================================================== Joachim Strömbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW8Qz+AAoJEF3cfFQkIuyN2eoQAK85EwmpLc2iqAMkA/I2ogB+ DsCvYl7ZxwpBgWzTfHSeVwccclC0FwcGvPIvCegAU5Barv58Mc5L+7mLnJ1hn8LR qTfQYz9yXyipn/6L0PDca2gpoSi/QqbJtlBRWfNYdmaqb1K8X5A8qgljtJMHNDEP eSHgmLFKLVpJFQbp2aGlqSwysEwaseTvLWfbWLBeA6itBivwxm2LtN1GT9ZTHlD9 /NfZockKF3bLOYaachtS84tIA8CKUhmRvf2/5e1MVDEZ53JivoSNZuNAjeMAlCED NMG6IfsKrEWisQaBliUaE3OzGxh2y1AGpw72/Fx2MmduaroR4nhiYWnMfvk2PRue ALEx0qFmBqverSTK78NzseGQBGu+iER7mQl2wK7d+1NDoNTNiijqB4aYNZeGwRc9 IeeVIKo/qTbZBH5qoI5nQRKsCdvsN36Sw7kSy1oCw5NMBMQBnk9vOZeAna7TUMas jnAF1ReH3dc2XeKJ9GdomZk60eHambIQBrPVlkziXcfECQo9CtXHK/OvYtGDHCmr Owb5ftgqojWKZdp+IA0hHWQe01x1nwrwE95G2VtWfN+ZqpSTcE21GBDRRL6TcogQ gfRMfcSMrggSE3BH/i+Bmaloee9vvo13t1SS7YpxJjjMZgCtngaWbtgS8xlcf0TQ ioZfyFBxQMckohswjyWp =s6MB -----END PGP SIGNATURE----- From nobody Tue Mar 22 02:49:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C741812D63B for ; Tue, 22 Mar 2016 02:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53tSLZQjHCNs for ; Tue, 22 Mar 2016 02:48:55 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DFFC12D09A for ; Tue, 22 Mar 2016 02:48:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458640134; x=1490176134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ei+ecJ7RgRHJj2KcU7ZZjuN1qUp8BiGNQizNAowLeX0=; b=EEk9ygpnS4ZXMhOTONUyhGCgwbV5J3rE1We0Yplna6ZIzEELMqM4x6xV Wcj1X0VWmBDL654glwq8V4MFe1ALMgu6ukcdLE/NA9Uc1mCPme050q8HQ ETK3oVI6XwMUtNgoVgW1VjwzxaCHtAdTltDVcbzHPx0lCNy0CMOqoLwX4 dpFfRt49/u9SpUVvkScdcZynUkWnf07baDrUQ1xZp53W38mDFFcZvzz3w Myk1X4x7OG5otkhB1FoBrYBGxsMZ7m8wJEjtcqC1AovI81ZeZgZzrFi18 6JuzKL53JVro8YUeLo85UmtlofY48+8s5w96WTfcIAaIR7auXq8EniduW Q==; X-IronPort-AV: E=Sophos;i="5.24,376,1454929200"; d="scan'208";a="75752792" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Mar 2016 22:48:52 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0266.001; Tue, 22 Mar 2016 22:48:52 +1300 From: Peter Gutmann To: =?iso-8859-1?Q?Joachim_Str=F6mbergson?= Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROrgAJscYCAAOwz3///L1EAgAI0jb4= Date: Tue, 22 Mar 2016 09:48:51 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz>, <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz>, <56EFF22C.5040505@secworks.se> In-Reply-To: <56EFF22C.5040505@secworks.se> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:48:59 -0000 Joachim Str=F6mbergson writes:=0A= =0A= >When you say that "a Cortex M3 isn't going to be able to handle RSA-2048",= =0A= >what do you mean specifically? Considering that it is being done by for=0A= >example SharkSSL [1], is supported by ARM mbed TLS (nee PolarSSL) [2] I fa= il=0A= >to see what hardware limits you are seeing. Yes, the speed you get is not= =0A= >impressive (1-2 seconds to decrypt), but it might be ok, depending on your= =0A= >application.=0A= =0A= It's not just RSA, it's DH as well (looking at the SharkSSL library link it= =0A= looks like it doesn't do DH at all, only RSA key transport). I've seen PLC= s=0A= where DHE+RSA leads to handshake times of 10-15s (not an M3, I just use tha= t=0A= as a convenient mental model for an embedded CPU, this was using an industr= ial=0A= Power SoC), which isn't a good thing when what you're trying to communicate= is=0A= an emergency shutdown command.=0A= =0A= In these situations, crypto comes at about position 77 in the priority list= ,=0A= with most of the previous ones taken up by "reliability" and "availability"= .=0A= If you write a spec that in effect mandates a 15-second delay in communicat= ing=0A= commands to a controller, guess what vendors are going to do?=0A= =0A= Peter.= From nobody Tue Mar 22 02:55:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD62812D1B8 for ; Tue, 22 Mar 2016 02:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oe6TathsBmEp for ; Tue, 22 Mar 2016 02:55:25 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C36812D09A for ; Tue, 22 Mar 2016 02:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458640525; x=1490176525; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/oNkckV+J6HhC+vKHl/uLsjA1ISLsisCfYmAbBRblRM=; b=JqydieMV4ydh4w868Lc+UQZYlqtnCU/7lQQqYmq3avltIGbgssF3VRJt a0r/24z6gnP00w4SfyXYzzaT/Nhbnx17uD07aYBK5Q5sVF8UycD5sZHOo jJSukF6YLtXnH2QbBfKhBakHpm4iUqNcm02wCyDNhSVDseuwghvTxVxfP kfjbEgg/uWBl6/1TnYOZsyYRe6LFb6UROsiyXMgK4VSvD7OVyZIbcT5YQ 8q+u0V/YWX+GtJPaT4HRJHYfuA9XKR2fF2Ww3T/xN1MvbCYaN2yBxztU9 PnmjYo92gyFpzBbabEv2XVoBRZhGRB/gMJN1uSuxaj9g0eS+D7tp3B8qS w==; X-IronPort-AV: E=Sophos;i="5.24,376,1454929200"; d="scan'208";a="75753289" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Mar 2016 22:55:09 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0266.001; Tue, 22 Mar 2016 22:55:08 +1300 From: Peter Gutmann To: Hubert Kario Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROrgAJscYCAAOwz3///SK6AgAIc7FE= Date: Tue, 22 Mar 2016 09:55:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C29525@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz>, <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> In-Reply-To: <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:55:27 -0000 Hubert Kario writes:=0A= =0A= >it doesn't explain where this "RSA-SHA-256" is used. IMHO it is ambiguous.= =0A= >=0A= >The "no MAC truncation" is also not explicit about what the sizes should b= e.=0A= =0A= Well can you suggest some wording? I can't see how much more unambiguous a= =0A= statement like "no MAC truncation" can be.=0A= =0A= Peter.= From nobody Tue Mar 22 03:05:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74212D52B for ; Tue, 22 Mar 2016 03:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 nx-Jwlg6yf-L for ; Tue, 22 Mar 2016 03:05:00 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC00B12D09A for ; Tue, 22 Mar 2016 03:04:59 -0700 (PDT) Received: from Knubbis.local (unknown [80.252.219.34]) by mail.frobbit.se (Postfix) with ESMTPSA id 672D821465; Tue, 22 Mar 2016 11:04:57 +0100 (CET) Message-ID: <56F118C7.1010203@secworks.se> Date: Tue, 22 Mar 2016 11:04:55 +0100 From: =?ISO-8859-1?Q?Joachim_Str=F6mbergson?= User-Agent: Postbox 4.0.8 (Macintosh/20151105) MIME-Version: 1.0 To: Peter Gutmann References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <1561199.VzgNuqeJQW@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C26CD5@uxcn10-tdc05.UoA.auckland.ac.nz>, <7261615.38m5dF3AYF@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C28640@uxcn10-tdc05.UoA.auckland.ac.nz>, <56EFF22C.5040505@secworks.se> <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 10:05:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Aloha! Peter Gutmann wrote: > In these situations, crypto comes at about position 77 in the > priority list, with most of the previous ones taken up by > "reliability" and "availability". If you write a spec that in effect > mandates a 15-second delay in communicating commands to a controller, > guess what vendors are going to do? They are going to do the handshake once every day (or even less) and keep the session alive. Or use session resumption. Based on what I've seen in PLCs you normally don't start a new session for every single command. YMMV. - -- Med vnlig hlsning, Yours Joachim Strmbergson - Alltid i harmonisk svngning. ======================================================================== Joachim Strmbergson Secworks AB joachim@secworks.se ======================================================================== -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCAAGBQJW8RjHAAoJEF3cfFQkIuyNVTEP/ip7HWyE6MROHjT1OhDHnYa2 R+dcW4nW8cf6BzCg3SmQl5ldB4Fw5t6m/htySDzmSMgGSAnXO9XaFaALHrKHQKc5 csI00gWz6bO+LXRgsFnXD5z7lcEAu6NJ6IPMR9z1ueUXIzZoRUkE1o4G4zUmAgjR nNITn9HRmPyeysKiYPHwkHrQTQTf1kBgdp7yfvLPu0j8WQUOhzxLPk1S/9pbRgI6 9CnpngVNf4aRBRzqmRDQwtNsSswNP7xRwEVvjObfzXqOME7CZsxegEN/wNDPkx5H Gp7J1Q/l5zUBW7wRXHJdlmq2vlUc6B4kJMC1deZDLA0sNM+3BNVN1SEaroW9TMDj GdEjdVO6MImBgrLBpOlpgHoD/FRXJXENv+QR8AQMFbUejkP3gcyb0xtz2PTC79xl Qvr2pwCCStr8QIoWVaDTF9ia8CCPtZpVEZ0Zl8B91QqQ0+7tSoDqUy84JA0m3kMN rskv70CREq48U8yvPDh7EWbd9eOIz8jIiy7dMSAYprNdeZ0K5QMZe+iZbpz70Djn vZd5vyBySxMeKHqvf8BV0H2hx6gU0Y+RC/A+DQ69ieBicdzpb2BZrgpW/rFrM+TA 3L+3nKOIvL3xZ7xhlAayj7bbvaN6NloSH2OG246Zus4UAPZTzifKYEPQ3ogEC7VQ L37kW5FIZxmdAgzi2eTs =eO/5 -----END PGP SIGNATURE----- From nobody Tue Mar 22 03:06:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC20612D14F for ; Tue, 22 Mar 2016 03:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pEYk6043BpQ3 for ; Tue, 22 Mar 2016 03:06:19 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F1F12D09A for ; Tue, 22 Mar 2016 03:06:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 08356BE35 for ; Tue, 22 Mar 2016 10:06:17 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avg5_7EaadS1 for ; Tue, 22 Mar 2016 10:06:15 +0000 (GMT) Received: from [192.150.181.190] (unknown [192.150.181.190]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 46C52BDD0 for ; Tue, 22 Mar 2016 10:06:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458641175; bh=thLe/S73gax9wo5+3VOiyl+yD/gJURTcFi4/HbF8gfs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=pi+aSDa+4p4sfEu6bqv474SOt49jr4HYJi0rA2XUFIhndEwJ5CNNTMqTGjqcpy1tT 3TcIi6cKP8WR8FCbHUkH2eJnL3hpXyC4wM1RRx/47x0d98LDOVQjCW66STkJ+8sg3o o22fy8fsyuVX/XJ7ja2xjYoCLlWPO+SQnbBJsjJY= To: "tls@ietf.org" References: <56E1CE06.3020705@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F11917.6000408@cs.tcd.ie> Date: Tue, 22 Mar 2016 10:06:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56E1CE06.3020705@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030900050105050409080609" Archived-At: Subject: Re: [TLS] AD review of draft-ietf-tls-chacha20-poly1305-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 10:06:21 -0000 This is a cryptographically signed message in MIME format. --------------ms030900050105050409080609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 10/03/16 19:41, Stephen Farrell wrote: > This is ready to go but I've one question. Sorry I don't > recall if this was discussed previously, if it was, then > just say and I'll move this along to IETF LC. >=20 > My question is: Should the WG take the opportunity to more > tightly define the key exchange parameters for these > ciphersuites? Since it seems nobody liked that suggestion, I've asked for IETF last call to be started on the doucment as-is. Cheers, S. --------------ms030900050105050409080609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjIx MDA2MTVaMC8GCSqGSIb3DQEJBDEiBCAcGHTSCwBwAxuItSu3G7IaEPc2WkH0lEGVJU5mRpKx BTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAzWUNYJv8qv7Cxb/sVDeA4CT5zkh66IZw9gsd9uBho5ggKTrsE8s5w RbKNEZ2fJHarJeB9xUF3HCqX/0pHIjupvzgisayRkpqWrKdWN0aUtB4R9B7FL6B6OZPFgT9e 7vBsBoPZaWl02qHcukZ7/nqSsGbtY48g83LHL6gmG+GgwzLfXtWFLU1fdJEpVoeln5I7rel3 BrRWdG030hxlU/vpmbd7ifV9k6pzDBFBV7yfmgSuW+HUmzpemMKvfmp8Z6c/AmH63uh2UslT TWD8K70GKCNge3I41zrWBtmGfr6RdA3vEV7AM9BgjgfP+Km01XCAKJl1Enl237siFWRN8yYQ AAAAAAAA --------------ms030900050105050409080609-- From nobody Tue Mar 22 03:48:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDA12D6B1 for ; Tue, 22 Mar 2016 03:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aNK6YaR3fiS for ; Tue, 22 Mar 2016 03:48:21 -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 6B83412D101 for ; Tue, 22 Mar 2016 03:42:31 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id A6D1D3DD; Tue, 22 Mar 2016 10:42:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MAgT4l018020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 06:42:30 -0400 From: Hubert Kario To: Peter Gutmann Date: Tue, 22 Mar 2016 11:42:23 +0100 Message-ID: <15689268.cdSCJdr7cB@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <56EFF22C.5040505@secworks.se> <9A043F3CF02CD34C8E74AC1594475C73F4C29500@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2494083.S12pyfxVKd"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 10:48:22 -0000 --nextPart2494083.S12pyfxVKd Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 22 March 2016 09:48:51 Peter Gutmann wrote: > Joachim Str=C3=B6mbergson writes: > >When you say that "a Cortex M3 isn't going to be able to handle > >RSA-2048", what do you mean specifically? Considering that it is > >being done by for example SharkSSL [1], is supported by ARM mbed TLS= > >(nee PolarSSL) [2] I fail to see what hardware limits you are > >seeing. Yes, the speed you get is not impressive (1-2 seconds to > >decrypt), but it might be ok, depending on your application. >=20 > It's not just RSA, it's DH as well (looking at the SharkSSL library > link it looks like it doesn't do DH at all, only RSA key transport).=20= > I've seen PLCs where DHE+RSA leads to handshake times of 10-15s (not > an M3, I just use that as a convenient mental model for an embedded > CPU, this was using an industrial Power SoC), which isn't a good > thing when what you're trying to communicate is an emergency shutdown= > command. >=20 > In these situations, crypto comes at about position 77 in the priorit= y > list, with most of the previous ones taken up by "reliability" and > "availability". If you write a spec that in effect mandates a > 15-second delay in communicating commands to a controller, guess what= > vendors are going to do? attacks only get better if the hardware can't do crypto securely now, it certainly won't be abl= e=20 to do it tomorrow (you know, in the "Long Term") it's a waste of time to patch up attacks that are still largely=20 theoretical if you leave a mile wide hole in the fence =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2494083.S12pyfxVKd 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 iQIcBAABCgAGBQJW8SGPAAoJEJKo0bgB0vX1GegP/3QMu4XaRgaGrDMfbRkNPOZq FP/7qnLySq191w2exbnnhtssrCMhjKI8+Evu9ECwlJLGb7dwtvTziCjmH/bpc7Ua r8gHlwXC7KUJxej81bL3nUjcNkxtXMooM2HqYHQLLykVdh86Qb4dB0q8q+tjWCgT Cudak+cr4wXStOfQUnLJEGf16K1bhTk6JribBYohs3pTy0mMzcf7KNO2wqMh4Al7 LPLnIybFnIcV4hDctS0X8DR5At6dPD4LPKgn+GivOpRMQJW38VBB8vArRy/R8zXH +8ZX/k2Ms/nCDwiEKSFD9oyamKZovD8BNpjqBnZbMTE/8Aye4nWpI56Bwidxumqk wmFRlA25LaM0Zw0mLmOBhl337UviJbgpogHsgxPln2eJQLJscut7tb43q83s6uYL H8fIJ/lBmUp082XvqFbfMSyE29gcevU3FDP2fZ0vw5kzzyy1tnJijHIH3tz29yp2 lYm7WA9Ww83nq+tcKLrnnwnki2DPxoFuRy1BtHPP9r/7fxuWfNlvMAhFq6QFtFG8 n3Ih7BCnb0blUfSvs20G7ptIi/YgU9Iu9pVQfbOpRON31qrHBGXA76lZKGEzgCY4 a8mXp1KjEcPEUdLffhBjoN/vM7XDf7wkeKZoxnofz6cKC2llIj5c08OHwCzZCqzN 23lOfFdle/ZLX6O30A82 =wptp -----END PGP SIGNATURE----- --nextPart2494083.S12pyfxVKd-- From nobody Tue Mar 22 03:57:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCD912D538 for ; Tue, 22 Mar 2016 03:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP1-p-tlPwF2 for ; Tue, 22 Mar 2016 03:57:33 -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 CD6AB12D5D6 for ; Tue, 22 Mar 2016 03:57:33 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 8DC5A46214; Tue, 22 Mar 2016 10:57:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MAvWCY018405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 06:57:33 -0400 From: Hubert Kario To: Peter Gutmann Date: Tue, 22 Mar 2016 11:57:31 +0100 Message-ID: <1516479.oKZilPeJ5Q@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C29525@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C29525@uxcn10-tdc05.UoA.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1704982.1iP4WAkRij"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 10:57:35 -0000 --nextPart1704982.1iP4WAkRij Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 22 March 2016 09:55:07 Peter Gutmann wrote: > Hubert Kario writes: > >it doesn't explain where this "RSA-SHA-256" is used. IMHO it is > >ambiguous. > > > >The "no MAC truncation" is also not explicit about what the sizes > >should be. > Well can you suggest some wording? I can't see how much more > unambiguous a statement like "no MAC truncation" can be. The Finished hash comes from PRF, which in turn comes from P_hash=20 construct which has practically unlimited output. The MAC is not=20 truncated there, the PRF output is, because it must be, as it is=20 defined. I was thinking of something like the following: The length of verify_data (verify_data_length) in the Finished messag= e MUST be equal to the length of output of the hash function used as th= e=20 basis of the PRF selected for the ciphersuite. That is, in case of=20= SHA-256 based PRF 32 octets MUST be used. This overrides the=20 requirement from Section 7.4.9. of RFC 5246 that all ciphersuites=20 defined at that time have verify_data_length of 12. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1704982.1iP4WAkRij 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 iQIcBAABCgAGBQJW8SUbAAoJEJKo0bgB0vX1pwoQAJ6/1zENs6LPawbLe3LCpicB Lg3TZ2xLa7JZ7yeIySb69OfT3TtUokIqYrhu9+3X9xPkoHAmP43qu82Kv4dWFHp2 RMOMdv2/uIw6Ri0defZhzn6pT95bqMwqoPf38ODApE4NUaYUR389Oxe06FWHqmDt aB8MZt82YNo8uZLzM42pFmYhDRvIIh2EsMM1YH6P4O4stylI12sNQ38tr5PYTUho qtxzTvukE4B9iVTxcFtKTkbF/JfpZnZY/wwxgWfe+HQ0+o1Wmg67QsfZ9UBEXGBm qjLa8RhF0tb08EHEB+4iTleDyo1Qztu+PeS4RYBXMeR8qvUBn8BC9XaoqVIaJ9lf STEhpJMkBUNlMXR7Qy3OIukTFQKbiKu/JKfa0paWcRoRB9bzq7YUdZAAn28nZyGF kUJeryTdtwHXe9v26DlBlSCAdaQFFXGw3ye+kEfSymTP/jJP//Brbd4Ax+X3xeDn arocXMy57iVAG9BmfDSCW6/waWCo6S0Z2GaAAO3u9wPNq1OBZJumRHhqjrQuFOgD vnXuj5gAszxpWqXpGyX7SHeLLvXwOW3+SnKnUdP+o/4VcaUX1hkEqprE+zh8VvhF Zdz2OyepGkwWAgPfxSDFqTzjOccPt0C7GZgBy1ry9qJoKfXWfD2/J3R0WrJ7Qnvy ux+1EQ/2skwoxUvEmt4f =QW4C -----END PGP SIGNATURE----- --nextPart1704982.1iP4WAkRij-- From nobody Tue Mar 22 03:59:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1912D5EF for ; Tue, 22 Mar 2016 03:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77NwfeQCJUEp for ; Tue, 22 Mar 2016 03:59:33 -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 2D1A512D101 for ; Tue, 22 Mar 2016 03:59:33 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E96E347D3; Tue, 22 Mar 2016 10:59:32 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MAxVJ8029281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 06:59:32 -0400 From: Hubert Kario To: Martin Thomson Date: Tue, 22 Mar 2016 11:59:30 +0100 Message-ID: <18948364.DHqrV9xL1y@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: References: <56E54B85.4050204@cs.tcd.ie> <5862743.k85ct04I0v@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart19986360.QD0pYRIh65"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "tls@ietf.org" , Geoffrey Keating Subject: Re: [TLS] analysis of wider impact of TLS1.3 replayabe data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 10:59:34 -0000 --nextPart19986360.QD0pYRIh65 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 22 March 2016 10:45:32 Martin Thomson wrote: > On 22 March 2016 at 06:40, Hubert Kario wrote: > > Only in theory, in practice you can do most of the same things in > > GET's as you can in POSTs. > >=20 > > in other words, basically web frameworks can be made to modify > > server > > state upon receiving GET request >=20 > Ahh yes, but it's not the *client's* fault if the server does that an= d > the client tries multiple times. The server is entirely responsible > for the consequences of state modification at that point. true, but that means that a blanket statement like "Sending GET request= s=20 in 0-RTT data is safe" is untrue. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart19986360.QD0pYRIh65 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 iQIcBAABCgAGBQJW8SWSAAoJEJKo0bgB0vX1CKIP/3/mpYcGp31U7mvENFwE1pyo waoYdxMLOUBtkvXhM1UJvheGHPsLVK7euNM/zyl529Gqmdh50IRslA+eDTq/hKhW 1R1KfMOhQgvE31v3hMcFh9hSq8PAduzPlxhbNU85jCRTub8S26CAT9wdFAPCBqVa IppisidaungOfrUl+KgnPI5fVwjYlJLFa6+XONTncwGsccj6B89hHCsJwRfBwKrQ dwiybaW2pl5DXj8TXQDg6c2up1Ph5X+Huwwy3rs5DvuFO4MVnxkhBq8icO312yVC RujEPXNOHtoG2+frPiKAmRAxcLyAMC0BotdR0nOvmongfaWl23ctAmwdDdjBuYV8 YCJFQWemYF+1C+QPEzaIX/dE7A3kwSje/XR0HwW6CofQzosN2ldSriCzvXk3IqUu YNpnJszKasc9HStMjW/xABXasKeRGWq7wYUVH3V3NY+4hCTYZm20yJOQqOoR24mm BbUazssfiPxgdcreUBuFh6amPdVBLaH+9BRhOKps5zdPu/pT/FiYtj56McKiIvSw 2HPcCvFlrsPQ9nkgb4+KGSUSWnD9+FlMYRaTJzi+PSOyztrYEBZevIj1ATmPKHue JvGEcsRgpGd+R+O5ijl7DxlTPNT3CXjxhe2Sl6XKq6AD4DM8hO7GS4GAFe6uNidM dXaMr+6ujVCWkPVEXoPK =qY9s -----END PGP SIGNATURE----- --nextPart19986360.QD0pYRIh65-- From nobody Tue Mar 22 04:29:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764F312D5B8 for ; Tue, 22 Mar 2016 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.923 X-Spam-Level: X-Spam-Status: No, score=-6.923 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0QDtZrFjsGq for ; Tue, 22 Mar 2016 04:29:33 -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 2FF4612D595 for ; Tue, 22 Mar 2016 04:29:33 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id D0A3C6445D; Tue, 22 Mar 2016 11:29:32 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2MBTVfe012063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 22 Mar 2016 07:29:32 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 22 Mar 2016 12:29:30 +0100 Message-ID: <3050121.iQnPKsMOqq@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <201603220026.47012.davemgarrett@gmail.com> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <201603220026.47012.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1741414.VfJDIFC9Ce"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 22 Mar 2016 11:29:32 +0000 (UTC) Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:29:34 -0000 --nextPart1741414.VfJDIFC9Ce Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 22 March 2016 00:26:46 Dave Garrett wrote: > On Monday, March 21, 2016 09:59:27 pm Tony Arcieri wrote: > > On Mon, Mar 21, 2016 at 12:42 PM, Dave Garrett=20 wrote: > > > Frankly, I think this document should be renamed "Extended Suppor= t > > > Profile", rather than "Long-term Support Profile" (and ESP instea= d > > > of LTS).>=20 > > Legacy Support Profile? Then you don't have to change the acronym >=20 > I don't exactly see a 'T' for "LTS" in "Legacy Support Profile"... ;= ) given that we're trying to predict future, Extra Sensory Perception is = a=20 good acronym to use ;) =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1741414.VfJDIFC9Ce 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 iQIcBAABCgAGBQJW8SyaAAoJEJKo0bgB0vX12MgP/jdhFVJfabEE19yZscrXeLRr gy4qbxeJDD++7U/7WpbPZxs6KlStZGVGXcz4JDOVNYhTERABLF8TKFpXHW/aT9O/ shj0aatPgb5uzNp46CmJ3UAOVtB53TZstbBI/JoZu7PRV3Dwd6uIPBkgVx6zivbZ 2HnnZ+JOsxQm/PzL1y8wnTOdTpiPrb7cfcuRN7orPIVC7HD9KU5vk7qqgkhCfxbh Sm2hyVVLLS9k70kSQxHXdqCyN9CCEs3hE75dt5mUjBa30EQxRKgxuaO3bbCqOXUB 4Pg6+SlxCIr2o1ZgiemZVEV39ABal3bde7mo00rNzYNvsnCBP2fGKZokK6NIiRyD PcqZG00Rxyisk4XawYwSYxPSXq6wp2MXpdPMqKcwo084cEotHnbaOr2/Bzf4syhs QWtQEYK2ijfcHGjK2Iz5m0mNwCxmhGHJjHbg2xR+JN2lhrScf0CDV1yN6EiNr3p5 Z8fuozG9r0/T3u1fpvk0SAe11BFz4qIiG8aWhy7EPdOuIWzqWx50x1RSh/BABlPz 2kPFcV4Q+rD+sq8aU2aVpgsCghYuGTR3nBbohhK4vxRr9PYTbNQToMHUXbAsDVGd 7ByhGuXrHztX0UmToSeFIf6tXUxRed2Z+qM2YdCSEGCK+NLK2Xe6fU1lMiqKN4K8 h9jt7XA4jZw+CkUNri4w =BT0X -----END PGP SIGNATURE----- --nextPart1741414.VfJDIFC9Ce-- From nobody Tue Mar 22 07:00:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1561712D7AC for ; Tue, 22 Mar 2016 07:00:03 -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 IGp0NPO_jhUF for ; Tue, 22 Mar 2016 07:00:01 -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 ADE1912D7E5 for ; Tue, 22 Mar 2016 07:00:01 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id g3so255280335ywa.3 for ; Tue, 22 Mar 2016 07:00: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=hAZFRliNfYNJqOGw9YpdZ4uAibsRG5lLQ0vo+M+dSeE=; b=lDfYkHe6fRrRYoXZxoXE72YVFpiKDw2GjKWJT/SWejM6h6GWgA/Wio872qbMUhEpEB 2Kx+SL1xIYYhGcAFHtPYRG4nmJV01CHV8L4kKjAi6qzYvhKwrHfNgP9KM2eBJeAszd1+ qbormgzNLLL7WsXRdcXCsYZXvLPru0DADfytycR2qi3dpXg4jmoyxyGNxNKzpR6zI71T rjvdopeVpa899jUnDVechTe6NivmJ7+FCrACzaV416tMZI2uYKg379tMEJx49o2HLFSp 3DGoNtaUq65EdWclY0BKpDusv4HQyRIrh6CH6aL8O9sDQ+9+0QFwfgvro9JLQl0Iucu/ 8iyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hAZFRliNfYNJqOGw9YpdZ4uAibsRG5lLQ0vo+M+dSeE=; b=X/RtMYnyhjJCxXXLbr5NmRZx97xf6xBZ2W7xr5Nqq7rEwRFGTGO5QnWjXlyK8d+Iqv WJ0jelHhms9ysj8lGTlQAWU+HKOoiFOql574MBqNbXyf+mXoc2fDycvO/D9yCk+EhZd6 ThLq8cdbw0l+kcF4X+BektS96OlhBjeaE8pixo3tXiJPuI0tmx5CgAlVCKaxOsKC2wLR ijRmdG0oWgGTMSVHFEvQIToa5jUEXZra7xOymSfRNy03ALWGT/bVWIhCytXxcaWKSAOb NIbhN0RlAKhGpfeZbY/ebV8kCEEQPnjj/DKapm2iYWC2U3KnLdmiG+aDIXICFMe9MYOq cz+w== X-Gm-Message-State: AD7BkJL4UkbHw05XY1o78KTz1U0JZRAtYcvUazgrToxhRbLg+RbsnhEvBXQ1xRPPeSZu3LcQx7i2nFxZQlrJNQ== X-Received: by 10.129.46.87 with SMTP id u84mr16239880ywu.129.1458655200910; Tue, 22 Mar 2016 07:00:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 22 Mar 2016 06:59:21 -0700 (PDT) In-Reply-To: <201603220022.34304.davemgarrett@gmail.com> References: <56E874A4.3030506@gmx.net> <56F06EDC.9080406@gmx.net> <201603220022.34304.davemgarrett@gmail.com> From: Eric Rescorla Date: Tue, 22 Mar 2016 06:59:21 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114140ba19d01b052ea3a1d4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSK in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:00:03 -0000 --001a114140ba19d01b052ea3a1d4 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 9:22 PM, Dave Garrett wrote: > On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote: > > Ah, I see. Let me see if I can clear this up, if you wanted to send a PR, > > that wouldn't help too. > > I assume you meant "wouldn't hurt" or "would help" here. ;) We won't know till we see it :) :) > > > Dave > --001a114140ba19d01b052ea3a1d4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 21, 2016 at 9:22 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Monday, March 21, 2016 06:08:45 pm Eric Rescorla wrote:
> Ah, I see. Let me see if I can clear this up, if you wanted to send a = PR,
> that wouldn't help too.

I assume you meant "wouldn't hurt" or "would help= " here. ;)

We won't know till we s= ee it :) :)=C2=A0


Dave

--001a114140ba19d01b052ea3a1d4-- From nobody Tue Mar 22 07:24:29 2016 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 AD5BC12D830; Tue, 22 Mar 2016 07:24:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160322142428.4104.65067.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 07:24:28 -0700 Archived-At: Cc: tls-chairs@ietf.org, draft-ietf-tls-chacha20-poly1305@ietf.org, tls@ietf.org Subject: [TLS] Last Call: (ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "This is the mailing list 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 Mar 2016 14:24:28 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-04-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the use of the ChaCha stream cipher and Poly1305 authenticator in the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-chacha20-poly1305/ballot/ No IPR declarations have been submitted directly on this I-D. I-D nits notes that the abstract doesn't mention the two RFCs being updated. That is a useful practice (in case someone only sees the abstract) so we'll fix it after IETF LC. This draft normatively references RFCs 4492, 5489 and 7539 which are algorithm definitions. If needed we will put those in the DownRef registry after this last call concludes. From nobody Tue Mar 22 10:16:57 2016 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 887AF12D85C; Tue, 22 Mar 2016 10:16:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160322171656.4034.35936.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 10:16:56 -0700 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-tls13-12.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list 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 Mar 2016 17:16:56 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : The Transport Layer Security (TLS) Protocol Version 1.3 Author(s) : E. Rescorla Filename : draft-ietf-tls-tls13 Pages : 118 Date : 2016-03-22 This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. A URL for this Internet-Draft is: https://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-tls-tls13"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2016-03-22101656.I-D@ietf.org> --NextPart-- From nobody Tue Mar 22 11:53:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8212D892 for ; Tue, 22 Mar 2016 11:53:15 -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 7nzcwMsSeqmT for ; Tue, 22 Mar 2016 11:53:13 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 A21AC12D7E7 for ; Tue, 22 Mar 2016 11:53:13 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id w104so186192131qge.1 for ; Tue, 22 Mar 2016 11:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YISlYGrU/220D8GNyZl9Qz8W25GoKG+TEVqbpwatSWs=; b=SfTCyXsCMcdgaf/35uu9Nv0FJTrGsjzax5I2nmOJ++2fS5qgHp76aqG4M0nUPXMLiT WYlBvh2/gxHIsaZzMM+lNGGQ6JEd8bnhE1bWkvSfT1h7eP4qrj1/QIqtpR/2uSxigqYW mIQ/IuR0vUpFDfHMDXUbtBlYQltZx/8DvjmtM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YISlYGrU/220D8GNyZl9Qz8W25GoKG+TEVqbpwatSWs=; b=PH2AF8kD8qTguSPA9E9EcPxZhXAl+3VmZ0TWPLO0TDeSZEGsH0imGbl9xJEbnrhklA tWgyErNPYH0QS50Pxra6JM8esIOVDECxfu+cGlYIrDIVbuxnvoSN5HoQXEcQRkTjPVtK M78pSHKldbEwuPVBH+PQSui/cGW4UwOgE8ulU2wRoCbPJY38nsXJ0t4OG/59S74Nz90b OC6X5ZMMbwGqFt5kBr7Zhwrg1ws7W7RKaG1F0Gf1JxMvTBHOQmaShOSlMZAcNmQllWXJ Stl050U4HgjMaVO90Ha7SnmSXvhc2Z7f8LkIoEJEgW23vINXxeUG3jgVzhadtjULurHQ LQdg== X-Gm-Message-State: AD7BkJJsztMyaVHs68iXPGYA1RBXe1vCogAjv9xKnU1LIZE2b7DMw1OrFj60Ek6KZQdozA== X-Received: by 10.140.98.163 with SMTP id o32mr50295766qge.46.1458672792771; Tue, 22 Mar 2016 11:53:12 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id 107sm15235332qge.16.2016.03.22.11.53.11 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 11:53:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <20160322171656.4034.35936.idtracker@ietfa.amsl.com> Date: Tue, 22 Mar 2016 14:53:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <15C6993A-A6D3-41C1-ACD8-348456A3C191@sn3rd.com> References: <20160322171656.4034.35936.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-tls13-12.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:53:15 -0000 Thanks for the getting this out. Obviously, what=E2=80=99s changed and what=E2=80=99s still outstanding = is going to be the lion share of our discussions in BA. spt > On Mar 22, 2016, at 13:16, internet-drafts@ietf.org wrote: >=20 > A new Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security Working = Group of the IETF. >=20 > Title : The Transport Layer Security (TLS) Protocol Version = 1.3 > Author(s) : E. Rescorla > Filename : draft-ietf-tls-tls13 > Pages : 118=20 > Date : 2016-03-22=20 >=20 > This document specifies Version 1.3 of the Transport Layer Security > (TLS) protocol. The TLS protocol allows client/server applications > to communicate over the Internet in a way that is designed to = prevent > eavesdropping, tampering, and message forgery. >=20 > A URL for this Internet-Draft is: > https://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-12.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 22 11:53:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0882D12D116 for ; Tue, 22 Mar 2016 11:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLCHi47sG9ay for ; Tue, 22 Mar 2016 11:17:25 -0700 (PDT) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D950812D0EC for ; Tue, 22 Mar 2016 11:17:24 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-10v.sys.comcast.net with comcast id Z6FA1s0032VvR6D016HQhy; Tue, 22 Mar 2016 18:17:24 +0000 Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-19v.sys.comcast.net with comcast id Z6HM1s00e1nMCLR016HNPG; Tue, 22 Mar 2016 18:17:23 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u2MIHLkj028470; Tue, 22 Mar 2016 14:17:21 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u2MIHJ47028462; Tue, 22 Mar 2016 14:17:19 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: In-Reply-To: (grubba@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 22 Mar 2016 14:17:19 -0400 Message-ID: <87bn662x8w.fsf@hobgoblin.ariadne.com> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458670644; bh=r/nf8nNZbjxfauaQwZ+I01BrtvqJdRCodK49aJdMRoU=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=Eztr+X6V9OcqP0oClTRwYMfSzteAjPa31mHjrvxuCAYC8VyoNLzL5kF18nritTLRe oxMqBL9dJpfBfdZx0f+COJ2h7+/zqLvLGIM4k5AP8NM98+Xocw0P5BFO//s/Z1xTAg XK70hTuB3bXZSJ4bPVb+cPpLjCUQld56M/5RfiiXdw6f9MrF1pHKXhTdRYL6YP5QH8 +fYPNGelhFxxvV9Y3koc7K3SrFZ1seKp0x2sgwbGFzYF1yenRzF6ImAMiY/oh219dX r+JMiX5vY3Zl+StG1+UMXE2ryb9tGg8Ymjp84WlzyA6cSRRctLsnOq4f3xmUomD//k D01GFrZQ4BYZQ== Archived-At: X-Mailman-Approved-At: Tue, 22 Mar 2016 11:53:36 -0700 Cc: sean+ietf@sn3rd.com, rfc-editor@rfc-editor.org, Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org, nagendra@cs.stanford.edu Subject: Re: [TLS] [Editorial Errata Reported] RFC6347 (4642) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:17:26 -0000 writes: > As far as I can see, the original text is correct, which is easy to > see if you look at the corresponding paragraph of RFC 4347 (DTLS 1.0): > > version > The version of the protocol being employed. This document > describes DTLS Version 1.0, which uses the version { 254, 255 }. > The version value of 254.255 is the 1's complement of DTLS > Version 1.0. > > If the suggested text had been correct, then the encoding in RFC 4347 > would have been { 254, 254 } as DTLS 1.0 is based on TLS 1.1. You're right, { 254, 255 } is the complement of { 1, 0 }, so the erratum must be incorrect. Oddly, the following sentence in RFC 4347 is factually incorrect as an architectural statement but is correct as a description of the protocol: "This maximal spacing between TLS and DTLS version numbers ensures ..." The Hamming spacing isn't maximal, that would be obtained with { 254, 254 }, but it is the value that is used and it does ensure that the protocols are easily distinguished. Dale From nobody Tue Mar 22 17:38:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C84912D5F8 for ; Tue, 22 Mar 2016 17:38:19 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.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 CA5KkWdiGFsu for ; Tue, 22 Mar 2016 17:38:16 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0088.outbound.protection.outlook.com [65.55.169.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7470A12D5EC for ; Tue, 22 Mar 2016 17:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W9b0rUIRoewRVQH7VWaF/CLVStg3WxAnDVa3GPb5/GI=; b=memRQq3OJGd4IDrET7cwzjM0qEgQi9sJ9NYaCvrXmc1WEb4g2kS2Syt8JLLxjlSieSNBdVrRoFfDl+W96KgFVngn+2NLpaTmy51+OOkoxYd0nTfbB7awIdkt5oCAZ6DLX1/CzO2XhmTheeY9r/Hlv6YhvlvtclyabsynlDjoovg= Received: from CY1PR10MB0441.namprd10.prod.outlook.com (10.163.89.27) by CY1PR10MB0443.namprd10.prod.outlook.com (10.163.89.29) with Microsoft SMTP Server (TLS) id 15.1.443.12; Wed, 23 Mar 2016 00:38:14 +0000 Received: from CY1PR10MB0441.namprd10.prod.outlook.com ([10.163.89.27]) by CY1PR10MB0441.namprd10.prod.outlook.com ([10.163.89.27]) with mapi id 15.01.0443.015; Wed, 23 Mar 2016 00:38:14 +0000 From: Timothy Jackson To: "tls@ietf.org" Thread-Topic: Ensuring consistent strength across certificate, ECDHE, cipher, and MAC Thread-Index: AQHRhJxIvdQqc8JxV0CUtKcN/21N7g== Date: Wed, 23 Mar 2016 00:38:13 +0000 Message-ID: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mobileiron.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [198.61.62.10] x-ms-office365-filtering-correlation-id: 750f7032-0e9e-421f-e41c-08d352b36b33 x-microsoft-exchange-diagnostics: 1; CY1PR10MB0443; 5:jPpKL62aaNEIynqGofNY2TQtCRlPHHRSKopu6XC74lUSXjh+rkO5lqkASahZ4vVKxDQCHEpKNKs7LcD4hmM4xiga+lmxLpJiOBfLg3rNOwiT3YDri3Q40n5OVMrEL/hBbs9gDklB6YR0DyQwcaksSg==; 24:T56eQuF+2WaxDT4HY8v/YFByPgko5cr6QpGuTTklOrlYiYfewZcU2mjC4StJSxXQ1yZHkkuNR9apyG9MspQUjPzNBd/67oqUvZMjvWEmgjE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR10MB0443; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:CY1PR10MB0443; BCL:0; PCL:0; RULEID:; SRVR:CY1PR10MB0443; x-forefront-prvs: 08902E536D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(1730700002)(3280700002)(3660700001)(54356999)(50986999)(92566002)(2501003)(106116001)(450100001)(10400500002)(81166005)(102836003)(6116002)(586003)(3846002)(99286002)(2900100001)(5008740100001)(33656002)(1096002)(110136002)(107886002)(1220700001)(561944003)(2906002)(189998001)(82746002)(2351001)(77096005)(11100500001)(5004730100002)(86362001)(36756003)(87936001)(66066001)(83716003)(16236675004)(122556002)(5640700001)(5002640100001)(229853001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR10MB0443; H:CY1PR10MB0441.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_97CC494EFB134A6B882480CF2C7A76BFmobileironcom_" MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2016 00:38:13.9620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR10MB0443 Archived-At: Subject: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 00:38:19 -0000 --_000_97CC494EFB134A6B882480CF2C7A76BFmobileironcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmXZlIG5vdGVkIHRoYXQgbWFueSAobW9zdD8pIFRMUyBpbXBsZW1lbnRhdGlvbnMgY2hvb3Nl IHRoZWlyIEVDREhFIGN1cnZlcyBzZWVtaW5nbHkgd2l0aG91dCByZWdhcmQgdG8gdGhlIGNpcGhl ciBzdWl0ZSBzdHJlbmd0aC4gVGh1cywgdGhleSdsbCBzZWxlY3QgYW4gQUVTMjU2IGNpcGhlciBz dWl0ZSAoZS5nLiBUTFNfRUNESEVfRUNEU0FfV0lUSF9BRVMyNTZfU0hBMzg0KSwgYnV0IHRoZW4g Z2VuZXJhdGUgYW4gRUNESEUga2V5IG9uIHRoZSBQMjU2IGN1cnZlLiBUaGlzIHNlZW1zIG9kZCB0 byBtZSwgc2luY2UgdGhlIFAyNTYgY3VydmUgb2J2aW91c2x5IGhhcyBhIGxvd2VyIHNlY3VyaXR5 IHN0cmVuZ3RoIHRoYW4gQUVTMjU2LiBUaGlzIHNlZW1zIGltcG9ydGFudCBpc3N1ZSB0byByZXNv bHZlIGJlY2F1c2UgbW9zdCBwcm9kdWN0cyAoYW5kIGV2ZW4gVExTIGxpYnJhcmllcykgZG8gbm90 IGFsbG93IHRoZSBhZG1pbmlzdHJhdG9yIHRvIGNvbmZpZ3VyZSB0aGUgYXZhaWxhYmxlIEVDREhF IGN1cnZlcywgb25seSB0aGUgY2lwaGVyIHN1aXRlcy4gVGh1cywgRUNESEUgbWF5IGJlIGludmlz aWJseSB1bmRlcm1pbmluZyB0aGUgc2VjdXJpdHkgb2YgeW91ciBUTFMgY29ubmVjdGlvbi4NCg0K SXMgdGhpcyBhbiBpbnRlbnRpb25hbCBjaG9pY2UgYnkgdGhpcyBncm91cCBmb3Igc29tZSByZWFz b24gdGhhdCBJIGhhdmVu4oCZdCByZWFsaXplZCB5ZXQ/DQoNCkhvdyB3b3VsZCB0aGlzIGdyb3Vw IGZlZWwgYWJvdXQgYSBwcm9wb3NhbCB0byBhZGRyZXNzIHRoaXMgYnkgc3BlY2lmeWluZyBpbiB0 aGUgMS4zIHNwZWNpZmljYXRpb24gdGhhdCBpbXBsZW1lbnRhdGlvbnMgbXVzdCBlbnN1cmUgdGhh dCB0aGUgc3RyZW5ndGggb2YgdGhlIGNlcnRpZmljYXRlIG11c3QgYmUgPj0gc3RyZW5ndGggb2Yg RUNESEUvREhFID49IHN0cmVuZ3RoIG9mIHRoZSBjaXBoZXI/IFBlcmhhcHMgYW4gZXF1aXZhbGVu Y3kgcnVsZSBmb3IgdGhlIE1BQyBtaWdodCBhbHNvIGJlIGluIG9yZGVyPyBBcG9sb2dpZXMgaWYg dGhpcyBpcyBhbHJlYWR5IHJlc29sdmVkIHNvbWV3aGVyZSBpbiB0aGUgZHJhZnQgUkZDLiBJIGxv b2tlZCBidXQgZGlkbuKAmXQgZmluZCBpdC4NCg0KRm9yIHdoYXQgaXTigJlzIHdvcnRoLCBJ4oCZ dmUgbm90aWNlZCBPcGVuU1NMIGFuZCBvdGhlciBpbXBsZW1lbnRhdGlvbnMgdHJ5aW5nIHRvIGFk ZHJlc3MgdGhpcyBieSBjcmVhdGluZyBhIOKAnFN1aXRlIEIgTW9kZeKAnSwgYnV0IHRoYXQgc2Vl bXMgdG8gYWRkcmVzcyBhIHNwZWNpZmljIGNhc2UgYnV0IGxlYXZlIHRoZSBnZW5lcmljIGNhc2Ug dW5yZXNvbHZlZC4NCg0KQ2hlZXJzLA0KDQpUaW0NCg== --_000_97CC494EFB134A6B882480CF2C7A76BFmobileironcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9C502A84205B9D4AAF45ADFE6715D54A@namprd10.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+SeKAmXZlIG5vdGVkIHRoYXQgbWFu eSAobW9zdD8pIFRMUyBpbXBsZW1lbnRhdGlvbnMgY2hvb3NlIHRoZWlyIEVDREhFIGN1cnZlcyBz ZWVtaW5nbHkgd2l0aG91dCByZWdhcmQgdG8gdGhlIGNpcGhlciBzdWl0ZSBzdHJlbmd0aC4gVGh1 cywgdGhleSdsbCBzZWxlY3QgYW4gQUVTMjU2IGNpcGhlciBzdWl0ZSAoZS5nLiBUTFNfRUNESEVf RUNEU0FfV0lUSF9BRVMyNTZfU0hBMzg0KSwNCiBidXQgdGhlbiBnZW5lcmF0ZSBhbiBFQ0RIRSBr ZXkgb24gdGhlIFAyNTYgY3VydmUuIFRoaXMgc2VlbXMgb2RkIHRvIG1lLCBzaW5jZSB0aGUgUDI1 NiBjdXJ2ZSBvYnZpb3VzbHkgaGFzIGEgbG93ZXIgc2VjdXJpdHkgc3RyZW5ndGggdGhhbiBBRVMy NTYuIFRoaXMgc2VlbXMgaW1wb3J0YW50IGlzc3VlIHRvIHJlc29sdmUgYmVjYXVzZSBtb3N0IHBy b2R1Y3RzIChhbmQgZXZlbiBUTFMgbGlicmFyaWVzKSBkbyBub3QgYWxsb3cgdGhlIGFkbWluaXN0 cmF0b3INCiB0byBjb25maWd1cmUgdGhlIGF2YWlsYWJsZSBFQ0RIRSBjdXJ2ZXMsIG9ubHkgdGhl IGNpcGhlciBzdWl0ZXMuIFRodXMsIEVDREhFIG1heSBiZSBpbnZpc2libHkgdW5kZXJtaW5pbmcg dGhlIHNlY3VyaXR5IG9mIHlvdXIgVExTIGNvbm5lY3Rpb24uJm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPjxicj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7Ij5JcyB0aGlzIGFuIGludGVudGlv bmFsIGNob2ljZSBieSB0aGlzIGdyb3VwIGZvciBzb21lIHJlYXNvbiB0aGF0IEkgaGF2ZW7igJl0 IHJlYWxpemVkIHlldD88L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0 YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1z dGFuZGFyZDsiPkhvdyB3b3VsZCB0aGlzIGdyb3VwIGZlZWwgYWJvdXQgYSBwcm9wb3NhbCB0byBh ZGRyZXNzIHRoaXMgYnkgc3BlY2lmeWluZyBpbiB0aGUgMS4zIHNwZWNpZmljYXRpb24gdGhhdCBp bXBsZW1lbnRhdGlvbnMgbXVzdCBlbnN1cmUgdGhhdCB0aGUgc3RyZW5ndGggb2YgdGhlIGNlcnRp ZmljYXRlIG11c3QgYmUgJmd0Oz0gc3RyZW5ndGggb2YgRUNESEUvREhFICZndDs9IHN0cmVuZ3Ro DQogb2YgdGhlIGNpcGhlcj8gUGVyaGFwcyBhbiBlcXVpdmFsZW5jeSBydWxlIGZvciB0aGUgTUFD IG1pZ2h0IGFsc28gYmUgaW4gb3JkZXI/IEFwb2xvZ2llcyBpZiB0aGlzIGlzIGFscmVhZHkgcmVz b2x2ZWQgc29tZXdoZXJlIGluIHRoZSBkcmFmdCBSRkMuIEkgbG9va2VkIGJ1dCBkaWRu4oCZdCBm aW5kIGl0LjwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IC13ZWJraXQtc3RhbmRhcmQ7 Ij48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJk OyI+Rm9yIHdoYXQgaXTigJlzIHdvcnRoLCBJ4oCZdmUgbm90aWNlZCBPcGVuU1NMIGFuZCBvdGhl ciBpbXBsZW1lbnRhdGlvbnMgdHJ5aW5nIHRvIGFkZHJlc3MgdGhpcyBieSBjcmVhdGluZyBhIOKA nFN1aXRlIEIgTW9kZeKAnSwgYnV0IHRoYXQgc2VlbXMgdG8gYWRkcmVzcyBhIHNwZWNpZmljIGNh c2UgYnV0IGxlYXZlIHRoZSBnZW5lcmljIGNhc2UgdW5yZXNvbHZlZC48L2Rpdj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPkNoZWVycyw8L2Rpdj4NCjxkaXYg c3R5bGU9ImZvbnQtZmFtaWx5OiAtd2Via2l0LXN0YW5kYXJkOyI+PGJyPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTogLXdlYmtpdC1zdGFuZGFyZDsiPlRpbTwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_97CC494EFB134A6B882480CF2C7A76BFmobileironcom_-- From nobody Tue Mar 22 17:46:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404B12D5C9 for ; Tue, 22 Mar 2016 17:46:32 -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 ob7Mq-40wy_s for ; Tue, 22 Mar 2016 17:46:30 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC5912D5EC for ; Tue, 22 Mar 2016 17:46:30 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id c63so7153979iof.0 for ; Tue, 22 Mar 2016 17:46:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=FyksbPYtVblfc4nrJLBUJgHOCxwaE6hVZIFdC2ZUeoc=; b=Jpj9MVXtH2mCpsBERkXBXoYGeRwuuPRacGk93zIbs1kfWl/+ZUnpdFiVSQAq7VfmP8 gQpJ3uPNu2pXkQdUSj+ldv954CyzJVvuYsePtAdPMc4jZDY+1qIvwbswdMLKjHHNuckE S3rAVQxklf8Ee4tjxRXRRTQwecB3OU9SUphgMRnq1j9xycpbkEas7UUCmJ4saLZtLX8M A/YWEAWnj4K0xBpS/AwMUvVnvLJrvFq4fg+JM1QpRB6qwePO0xhTw7Gs/euoI/8Xpp3Y vh1jg30k9YZ6gL0C8FTxQxwvTOJEzTNHmyfykf2z97kKZPn1NAWRtgVasLvY7vkh11RC UFdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=FyksbPYtVblfc4nrJLBUJgHOCxwaE6hVZIFdC2ZUeoc=; b=dwnB0gLGOAXC1XI8aAiqUpBV6rOeSeUVZjobLptdvGcDY2cpgsTIiCASbN8Wbn8ngy V8iTkHdDgsw6qVZNE6ZWsOupCRXCKgEEhkFugk3jyOKiEpjrlaMTEaQt6W4f1K/lkCkT bE/40dIB9O14s0kcosrBzB/6bZB7Qx6FLYzAkhWBGAVOy7wCtBlGeUN4vT6KaLuBHAQI YzdyVV/iBpREWCQ8EHXPjOdj2UKUch+3rWqyONI8/0t+lS9008LdW2AD0qyOEDB9GWOc x/kAbx3OojD2c9zK1+wSpO3V6bg0qkUEYAdVg2j95qs0BP7qhi8ok31cfHFCRUkZ5i41 xMQA== X-Gm-Message-State: AD7BkJKc64hFKwTjejN/tc309TCS1CjgSWY7uUby2u/j4+bLCSZONBQ9pZ6YO+fiZS6HZW2zAFVY2fQjJqYAOw== MIME-Version: 1.0 X-Received: by 10.107.137.100 with SMTP id l97mr556584iod.100.1458693989463; Tue, 22 Mar 2016 17:46:29 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Tue, 22 Mar 2016 17:46:29 -0700 (PDT) In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> Date: Wed, 23 Mar 2016 11:46:29 +1100 Message-ID: From: Martin Thomson To: Timothy Jackson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 00:46:32 -0000 On 23 March 2016 at 11:38, Timothy Jackson wrote: > How would this group feel about a proposal to address this by specifying in > the 1.3 specification that implementations must ensure that the strength of > the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? There are good reasons to make certain parts of the suite stronger than others. For example, record protection and ephemeral key exchange strength are tied to the potential lifetime of the ciphertext. If someone is scooping up sessions, that could be a long time (lifetime might actually need to be a lifetime). On the other hand, authentication keys need only be strong enough to resist a break until their expiration date. To given an example, in WebRTC, we used to use 1024-bit RSA keys; the lifetime of the keys was a single session (and it was still too slow). From nobody Tue Mar 22 17:50:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F13012D9A9 for ; Tue, 22 Mar 2016 17:50:16 -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 ws16rZ5rZtIL for ; Tue, 22 Mar 2016 17:50:14 -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 DF3DA12DAF9 for ; Tue, 22 Mar 2016 17:49:55 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id h65so867594ywe.0 for ; Tue, 22 Mar 2016 17:49:55 -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=/tE/GdTTsZoB8NHb7uEOtBITlT24RryUgJMxuoGdiN8=; b=Io6ruihWi3th3xHDJx/+DUW32b04t9Ipagxn3iXiKKBihu2pLkH+J5dG4nzTTek02I 0O58uNj/c4Y2/4c4cxJ0D+aKh4FIuSHi2ii9O8Q/Wa/0m/jOqwaQD1khpEkCnaJXXZS7 C1bsWOPxi2+2MTuMi8SayGcSNeafELZFZQsRSn+i/vemrxPaztYuuJO473XI8OgEPosJ rECeREp5I+n/zT8v7CoQHaUbuPLnEUsXw7+4it4cK8suvu9jB6AxHM/in5sHev5lLPQi sx2zukcqS7bA67LDbQwmfDbQsBersfUUQeuBFkv6kCFMFMGp0mbpwGX6UP+92i3XWlAh Jlvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/tE/GdTTsZoB8NHb7uEOtBITlT24RryUgJMxuoGdiN8=; b=Q1TKmRkwf92xt/f2yb90JiN2HpI3M8/8KlRdAH1jZ6+KVwPJhbdVBaCbX9K+ARmG8H dpUtOycYlNHLaMNQArz+WkjszMIYVUhO6RxfjQvWhpvhQPeZDxQgcUbq34wFgtcRSjHy a6N/EfYHVgE6nNYfkFzFDNnQG4DvMPZojb0nd6GOTvePqnsNkOGa/8bePxuE965eg2tx dBWO+Z4kRcED4hP9AQydC2slbDkv1681ZIDini6uST4RU124wePadbCxzTIzj/2lVWKW 62Fcdr7+w0hXYzsbeYK84l1tbSdoBjaoZPtavGRB0CLwd2kDSmrE0VIBh/9m5lNunzru fofA== X-Gm-Message-State: AD7BkJLCEWcdtrEsVXvWOcd9GjE9k4xqIANJsKtDdIWYjXfZjqreklmGhsOT5YQnd61uIwRaz4ilmFvdlV5fHA== X-Received: by 10.37.95.70 with SMTP id t67mr55722ybb.82.1458694195114; Tue, 22 Mar 2016 17:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 22 Mar 2016 17:49:15 -0700 (PDT) In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> From: Eric Rescorla Date: Tue, 22 Mar 2016 17:49:15 -0700 Message-ID: To: Timothy Jackson Content-Type: multipart/alternative; boundary=001a11423c445680cf052eacb586 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 00:50:16 -0000 --001a11423c445680cf052eacb586 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 22, 2016 at 5:38 PM, Timothy Jackson wrote: > I=E2=80=99ve noted that many (most?) TLS implementations choose their ECD= HE curves > seemingly without regard to the cipher suite strength. Thus, they'll sele= ct > an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but the= n > generate an ECDHE key on the P256 curve. This seems odd to me, since the > P256 curve obviously has a lower security strength than AES256. This seem= s > important issue to resolve because most products (and even TLS libraries) > do not allow the administrator to configure the available ECDHE curves, > only the cipher suites. Thus, ECDHE may be invisibly undermining the > security of your TLS connection. > > Is this an intentional choice by this group for some reason that I haven= =E2=80=99t > realized yet? > > How would this group feel about a proposal to address this by specifying > in the 1.3 specification that implementations must ensure that the streng= th > of the certificate must be >=3D strength of ECDHE/DHE >=3D strength of th= e > cipher? Perhaps an equivalency rule for the MAC might also be in order? > Apologies if this is already resolved somewhere in the draft RFC. I looke= d > but didn=E2=80=99t find it. > Off the top of my head, this rule seems like it would have several quite negative side effects: - It would require you to use Curve448 or P521 with ChaCha/Poly1305 (256-bit key) but allow you to use Curve25519 with AES-GCM 128, which cuts against one of the major reasons to use ChaCha/Poly1305, namely that it's faster on mobile platforms. - It would essentially preclude using RSA certificates with ECC at all, because the RSA modulus you need to match 256-bit ECC is impractically large. It's also worth noting that AES-GCM 256 and 128 use the same authentication tag size. -Ekr > For what it=E2=80=99s worth, I=E2=80=99ve noticed OpenSSL and other imple= mentations trying > to address this by creating a =E2=80=9CSuite B Mode=E2=80=9D, but that se= ems to address a > specific case but leave the generic case unresolved. > > Cheers, > > Tim > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11423c445680cf052eacb586 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Mar 22, 2016 at 5:38 PM, Timothy Jackson <tjackson@mobileiron.c= om> wrote:
I=E2=80=99ve noted that many (m= ost?) TLS implementations choose their ECDHE curves seemingly without regar= d to the cipher suite strength. Thus, they'll select an AES256 cipher s= uite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key on the P256 curve. This seems odd to me, si= nce the P256 curve obviously has a lower security strength than AES256. Thi= s seems important issue to resolve because most products (and even TLS libr= aries) do not allow the administrator to configure the available ECDHE curves, only the cipher suites. Thus, ECD= HE may be invisibly undermining the security of your TLS connection.=C2=A0<= /div>

Is this an intentional choice b= y this group for some reason that I haven=E2=80=99t realized yet?

How would this group feel about= a proposal to address this by specifying in the 1.3 specification that imp= lementations must ensure that the strength of the certificate must be >= =3D strength of ECDHE/DHE >=3D strength of the cipher? Perhaps an equivalency rule for the MAC might also be in or= der? Apologies if this is already resolved somewhere in the draft RFC. I lo= oked but didn=E2=80=99t find it.

Off the top of my head, this rule seems like it would have several = quite negative
side effects:

- It would = require you to use Curve448 or P521 with ChaCha/Poly1305
=C2=A0 (= 256-bit key) but allow you to use Curve25519 with AES-GCM 128,
= =C2=A0 which cuts against one of the major reasons to use ChaCha/Poly1305,<= /div>
=C2=A0 namely that it's faster on mobile platforms.

- It would essentially preclude using RSA certificates with= ECC at all,
=C2=A0 because the RSA modulus you need to match 256= -bit ECC is impractically
=C2=A0 large.

= It's also worth noting that AES-GCM 256 and 128 use the same authentica= tion
tag size.

-Ekr


For what it=E2=80=99s worth, I= =E2=80=99ve noticed OpenSSL and other implementations trying to address thi= s by creating a =E2=80=9CSuite B Mode=E2=80=9D, but that seems to address a= specific case but leave the generic case unresolved.

Cheers,

Tim

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


--001a11423c445680cf052eacb586-- From nobody Tue Mar 22 19:19:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 270A812D60C for ; Tue, 22 Mar 2016 19:19:23 -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=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 VrJ93N6BFm5x for ; Tue, 22 Mar 2016 19:19:21 -0700 (PDT) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::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 5D8D912D608 for ; Tue, 22 Mar 2016 19:19:15 -0700 (PDT) Received: by mail-lb0-x230.google.com with SMTP id bc4so1205398lbc.2 for ; Tue, 22 Mar 2016 19:19:15 -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:cc; bh=1RwzfejTa94HI1lk0gJanh/yR9yhD0XhhTO5kLhwkrA=; b=zBNxqwbQBhmhgsu20ivtt9ot45lCakDBkcHBzfVIWEcoE/Jxr43BTZT/kps5BLX+hb Hv3M5JwCFMw968Ps1efLrugam3uXk+jGe9ayT3H3ZCAE8/zhgLGfEaGgT0/v8mvUFri+ R7MC35cfb22NHBwNJj5nBtb5DK7uhAfSqbzhJ760y0tLPkeALfaUzjx/V9q7AHXUbH5z J2suED3FacM5TazQ9AubEbvzpxyxUZmM48JZ729xAeMvCTwaS/1eWssbUgZ1xtWdIPGH qLUIBIJ9+xy70Y8ZGC3aMucMnysY4QPQr4yW4fyxz+9HAvwd6Xso4/IkUmv3KZqHRoXr /xVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=1RwzfejTa94HI1lk0gJanh/yR9yhD0XhhTO5kLhwkrA=; b=ULDTEZuK8G0uvP8c+oBYHvR8uY6hBWLyW0hqlXSD3gga0bd9BxH0FujM5VLKxnmtla RKIVKHs+PArot4mmxEDwrM+7+gBXJ3Co+tyy0J098aBzPoPdzlR1Q/saeAPL8KrRxfDL YsZEXuAfQ7W7W4nOo7uiPUMXbN1K2EvHdT0cuGa3kGJExv631W8eOHVLmuKsjNi7DaTF EVXy/Vum5qR4waWw2gDA5DY19LdsO0CbUaEOICj0lITzEaQeHMgtiJNXtKWC/lBQotPY Tj1XAR40sa8oHXDcR7n2EDVSeeSchNLL5jX41m4w+OEH9BT/8iQnc/786UM40HpNofKE uLGA== X-Gm-Message-State: AD7BkJKCi9Z3x57SlJ2IPkyLcxwXxXOlqOCaly4E4CsNU2nov/QUB+jDXIl1ijNet9EwP16BCKcZWRyVata+3w== X-Received: by 10.112.150.233 with SMTP id ul9mr125325lbb.61.1458699553562; Tue, 22 Mar 2016 19:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.2.104 with HTTP; Tue, 22 Mar 2016 19:18:54 -0700 (PDT) From: Joseph Salowey Date: Tue, 22 Mar 2016 19:18:54 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=047d7b342f6cb976aa052eadf467 Archived-At: Cc: "" Subject: [TLS] Additional Agenda topics X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 02:19:23 -0000 --047d7b342f6cb976aa052eadf467 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Please let the chairs know if you have an addition topic you wish to get on the agenda. We can't guarantee that there will be time as TLS 1.3 work takes precedence right now. Thanks, Joe On Tue, Mar 22, 2016 at 11:53 AM, Sean Turner wrote: > Thanks for the getting this out. > > Obviously, what=E2=80=99s changed and what=E2=80=99s still outstanding is= going to be the > lion share of our discussions in BA. > > spt > > > On Mar 22, 2016, at 13:16, internet-drafts@ietf.org wrote: > > > > A new Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Transport Layer Security Working Group > of the IETF. > > > > Title : The Transport Layer Security (TLS) Protocol Version > 1.3 > > Author(s) : E. Rescorla > > Filename : draft-ietf-tls-tls13 > > Pages : 118 > > Date : 2016-03-22 > > > > This document specifies Version 1.3 of the Transport Layer Security > > (TLS) protocol. The TLS protocol allows client/server applications > > to communicate over the Internet in a way that is designed to prevent > > eavesdropping, tampering, and message forgery. > > > > A URL for this Internet-Draft is: > > https://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-12.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > > 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 > --047d7b342f6cb976aa052eadf467 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Please let the chairs know if you have an addition topic y= ou wish to get on the agenda.=C2=A0 We can't guarantee that there will = be time as TLS 1.3 work takes precedence right now. =C2=A0

Thanks,

Joe

On Tue, Mar 22, 2016 at 11:53 AM, Sean Tur= ner <sean@sn3rd.com> wrote:
T= hanks for the getting this out.

Obviously, what=E2=80=99s changed and what=E2=80=99s still outstanding is g= oing to be the lion share of our discussions in BA.

spt

> On Mar 22, 2016, at 13:16, internet-drafts@ietf.org wrote:
>
> A new Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Transport Layer Security Working Grou= p of the IETF.
>
>=C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport La= yer Security (TLS) Protocol Version 1.3
>=C2=A0 =C2=A0 Author(s)=C2=A0 =C2=A0 =C2=A0: E. Rescorla
>=C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 : draft-ietf-tls-tls13
>=C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 118
>=C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2016-03-22
>
>=C2=A0 =C2=A0This document specifies Version 1.3 of the Transport Layer= Security
>=C2=A0 =C2=A0(TLS) protocol.=C2=A0 The TLS protocol allows client/serve= r applications
>=C2=A0 =C2=A0to communicate over the Internet in a way that is designed= to prevent
>=C2=A0 =C2=A0eavesdropping, tampering, and message forgery.
>
> A URL for this Internet-Draft is:
> https://www.ietf.org/internet-d= rafts/draft-ietf-tls-tls13-12.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> <Mail Attachment>___________________________________= ____________
> 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

--047d7b342f6cb976aa052eadf467-- From nobody Tue Mar 22 19:20:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B898012DA36 for ; Tue, 22 Mar 2016 19:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.722 X-Spam-Level: X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 OLj0rOyWqs4K for ; Tue, 22 Mar 2016 19:20:04 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id EBD2812D608 for ; Tue, 22 Mar 2016 19:20:02 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 119E33F4052; Wed, 23 Mar 2016 02:20:02 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D8BA24F0D9; Wed, 23 Mar 2016 02:20:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1458699601; bh=L+vg/Q6aBBEZiZ3iEnDUJ2VZhdIHrrRwuBcStK03Mq4=; l=360; h=From:To:CC:Date:References:In-Reply-To:From; b=rw3DcCxirEd2Grn2RKBCiafTU0iY95DQh580x9xyGcJ73aG9mXxFQ+JOK7rzlcPXq EE57z7k8wp5UtpSlaNiEQqDgOh+EYY0yvFPOeSeNnisw1gPQiG7wpJRqPZppLaCosW JYVO+DJMDp6O//mXEc//OlygbOXzEz/jKBVkDLnI= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 94C031FC90; Wed, 23 Mar 2016 02:20:01 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Tue, 22 Mar 2016 22:20:01 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1130.005; Tue, 22 Mar 2016 22:20:01 -0400 From: "Salz, Rich" To: Martin Thomson , Timothy Jackson Thread-Topic: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC Thread-Index: AQHRhJxIvdQqc8JxV0CUtKcN/21N7p9mdLWA///WljA= Date: Wed, 23 Mar 2016 02:20:00 +0000 Message-ID: References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.152] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 02:20:06 -0000 > How would this group feel about a proposal to address this by > specifying in the 1.3 specification that implementations must ensure > that the strength of the certificate must be >=3D strength of ECDHE/DHE >= =3D > strength of the cipher? Strongly opposed, for the reasons Martin said. Insisting that everything l= ine up is kinda like crypto OCD. From nobody Tue Mar 22 20:26:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A6612D576 for ; Tue, 22 Mar 2016 20:26:28 -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 uRfdoZiIhgKr for ; Tue, 22 Mar 2016 20:26:26 -0700 (PDT) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 18A2C12D157 for ; Tue, 22 Mar 2016 20:26:26 -0700 (PDT) Received: by mail-qg0-x236.google.com with SMTP id y89so2613161qge.2 for ; Tue, 22 Mar 2016 20:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=Pd76PVyb3+0bleZVXKMXD5W/yJ4Lv1lGPjrwwuJEaw0=; b=vwBZ3KOda8DunFwsHdEGCqj95CFO4GEHI18gCcAlc9FYiA2cExriMWm8eWy3cvCjmb lUoKBC52pHLSu5iz40EIbDKWegg6X4DPMV/1z47hv3YywEPy8PBaIsy29zZnXdk7tDQ1 CKz7i4RJcwexwh96a5hN9RwLyz0tZOwrHJ3ZeC+Kzy5aLWfln5ZF9RZ8ynw7DWNpNRKl YvwMzWI4mX0iYz+tnQ0eKt5yC1ndtc0dGFvjO4ziieVde8y5qpatWMn1JZswtpT/T1Jm M+mCcU+Dtoqg6UjsB5Zq3RkF5ICnNvyNXZq8Pz0gQVyP/7A4wWoTOKxGcOEaaz+Vb96J 7x0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Pd76PVyb3+0bleZVXKMXD5W/yJ4Lv1lGPjrwwuJEaw0=; b=QryeZIGp9aOJF1c8EiHu+YPV7BjHTmymGFzV2hePgXyk59/HUgJYDMe5PlEWrbGSGj qjjgKlNYj+7JZUm3jJOGzOcFCgImqHm9xZtendc3katbpZNeX3GTqJX4DJdYvypYHIIo 4xDmCSvgVvrUHQrPKuZQ08Y+YTc6+SQAFZuECYWpAkqVFsPqXDp0Bw9+m8wDRiO4tVZ9 QPR84ilyaFuayAiudHNBA3Pc+6OS4YXqqK4PiURMjgaLpE1IBqp0j24L9Cw8MkXueLP5 PuRVMLZEoR0oz/9EZh/l87ox/QQaD/3wxyU2SzQB7mKnstAlYuZf/yoQdWwpQthj7PV6 kkzg== X-Gm-Message-State: AD7BkJKBv3JL14lin9bOcZg+NdtXaXV44qkCH9q2X7RhubEtLjFLtbc1L9UiBONMnijqLA== X-Received: by 10.140.130.14 with SMTP id 14mr557692qhc.85.1458703585108; Tue, 22 Mar 2016 20:26:25 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id o67sm233245qho.12.2016.03.22.20.26.24 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 22 Mar 2016 20:26:24 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 22 Mar 2016 23:26:22 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201603222326.23260.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 03:26:28 -0000 On Tuesday, March 22, 2016 08:38:13 pm Timothy Jackson wrote: > How would this group feel about a proposal to address this by specifying = in the 1.3 specification that implementations must ensure that the strength= of the certificate must be >=3D strength of ECDHE/DHE >=3D strength of the= cipher? Perhaps an equivalency rule for the MAC might also be in order? Ap= ologies if this is already resolved somewhere in the draft RFC. I looked bu= t didn=E2=80=99t find it. I've had a changeset sitting around for a while for recommendations (not ha= rd requirements) to match the strengths for key exchange and bulk cipher ke= y size. (it was leftover from a batch of other work, long since merged) Tha= t said, I'm not actually sure what my opinion is on this anymore. It's been= on my todo list to bring up a discussion. https://github.com/tlswg/tls13-spec/pull/296 There's complications here that make picking a matching number less than st= raightforward: 1) A main reason to switch to 256-bit ciphers is for post-quantum crypto, b= ut all (EC)DHE is completely broken in that scenario. Bigger numbers there = won't help in any meaningful way. 2) Neither AES-256 nor ChaChaPoly match up things perfectly, already. For P= RF, AES-256 uses SHA2-384, not SHA2-512; ChaChaPoly uses SHA2-256. AES-256 = also has a 128-bit block size. 3) There's more to group security than bits. For a start: https://safecurve= s.cr.yp.to/ At this time, I'm leaning towards sticking in a recommendation to prioritiz= e the following groups, in this descending order: X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then lastly, ff= dhe8192 and/or secp521r1 only as emergency backup (arguably, X448 belongs b= ack here too) I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use for TLS= 1.3+ and only support it for transition in older TLS. (this came up on-lis= t a long while ago, but needs further discussion) I'd state secp384r1 and f= fdhe6144 as "NOT RECOMMENDED" to bother with, but still permitted (or, alte= rnatively, just not explicitly recommended and not recommended against). I'd make the recommendation that X25519 and secp256r1, in that order, be se= nt in first-flight key shares, unless prior expectations exist for the serv= er that another group is desired or required. Implementations would of cour= se be permitted to send a more conservative set, such as (instead or additi= onally) X448 and ffdhe8192 or secp521r1, but even though I think this might= make sense for 256-bit bulk ciphers, I concede that it would likely be ove= rkill that wouldn't really help. Those who want something stronger should p= robably be refocusing their effort on getting some kind of PQ key exchange = standardized. Am I somewhere in the ballpark of what the WG might deem appropriate here? = There has been a "TODO" note sitting in the draft to address this for quite= some time, and I'd like to get something in here at some point. Just to re= state: my goal here is a set of recommendations to narrow down the zoo, not= hard requirements (beyond requiring ~128+ bit strength security). Dave From nobody Wed Mar 23 00:43:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEAB12D9F2 for ; Wed, 23 Mar 2016 00:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FORGED_FROMDOMAIN=0.249, 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 header.b=zZM+V5ni; dkim=pass (2048-bit key) header.d=ieee-org.20150623.gappssmtp.com header.b=1LDD1ArF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIr3EfeK4-3y for ; Wed, 23 Mar 2016 00:43:45 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 15A0D12D8A2 for ; Wed, 23 Mar 2016 00:43:45 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m184so22919729iof.1 for ; Wed, 23 Mar 2016 00:43:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+0DyH7Zzh1rEhhCZEP50yfJ4jCqhh6tJweE0waSn/hw=; b=zZM+V5niFnQX3egHrKsyz6RHMcQ8EyGhJx5zc/RLk9+SclNfYFL1JJjMQwT7yV0+4B oG27qYEOWHx29L7fNHmYOrpJVrd+m3jrHystt5zG2nhMXxaEmh0rOHbFMffp1rnp9d7F FTREKWdauy/cTBSN+DuMMLHtGURoItvvQDCh3OXt/3j+UEuzsR9gzpvPyCvxulPdj390 IFg4DRoExq0LY1VjEptZecaMO961r/36lX1N6hLmZFN+4cdRxOCjdtExw0FGvM9jvUpy yAZWhWB/K6SemsucYvSzgJmkwfvSn6F8dbMeKcjw7sXByNAN6hjcP3ZMAUZrqBaJdsfs 8dow== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee-org.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+0DyH7Zzh1rEhhCZEP50yfJ4jCqhh6tJweE0waSn/hw=; b=1LDD1ArFMmkp49GcpdbjUxV9nIx20qxirMBR5hnk2w7q3JZ9K25vvNBMADBLeXGz/J NDCIHElwyvhv8zBL+vdyHtcgkv7uWZqG7zmgAzCmdENwe0afuGQJGgY5kaBX+x8uNY2a Q9NS7ES56QMosPKUZgdAMWELZpkIXC+Pn7xVctC2DkXpaSbRR4rc8EepVVWU9MWXAhGy 5UJg35U8cwWqmTYRZ9SuDZrBeSFR5zq+GxwsGg/i/2k7uRLxwPaei0IAkACwz+AI8S1s gcPp5M/QrBNeBNJ3Mm8caDhoePGiRwoRWKbiWyhcSt59WVInJt6QZMlyA3D7+JLhAt7s b77w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+0DyH7Zzh1rEhhCZEP50yfJ4jCqhh6tJweE0waSn/hw=; b=SQL180gflxHNLM9PSttSBpAXL6G/i76M+QQIKn3HPHdVbCsJEl2pLNUFKR8q0/f3qC B7gQUM0pcxEQIU4bonDEbqPaMK0QbuRshpkarYBsFDAgSxX5zoQyXd9Q1lRqDc02Gghw d3DCB/QYpoL0zAe4+UaTBhSifRuQy9t/3gYwgK19gQda+QmQsNzy0sHxwwjRIQ83PECO 3B77j2kuIC2D0nkuM18DqyZaSTTVslkpdLJ/IfnstYzAWEbTCKcnkWmaPEreePl/ZM0m uf2TWvhIC75q19slIGUDQyizmEsL9eoHbv8X0Ys05E5u/g5VlbDyshxDKFatrMGaHM96 T/ZQ== X-Gm-Message-State: AD7BkJJVGL7vITbZ4JH/cSlLb0mnmYBj4fQTEgZvkEmgemG0oaKXDxIikJc2ssNGpo/cH+ZPckBcIugZxTKqWA== MIME-Version: 1.0 X-Received: by 10.107.153.200 with SMTP id b191mr1981623ioe.54.1458719024398; Wed, 23 Mar 2016 00:43:44 -0700 (PDT) Sender: gknowles92603@gmail.com Received: by 10.107.16.17 with HTTP; Wed, 23 Mar 2016 00:43:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Mar 2016 00:43:44 -0700 X-Google-Sender-Auth: Pv52RFrlyZVfYyMi_gQmNAMp0XI Message-ID: From: Glen Knowles To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1145dfea46c561052eb27d89 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 draft 12 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 07:43:46 -0000 --001a1145dfea46c561052eb27d89 Content-Type: text/plain; charset=UTF-8 On Mon, Mar 21, 2016 at 6:05 PM, Eric Rescorla wrote: > Folks, > > This revision is largely cleanup of a bunch of outstanding PRs and of > issues found during interop testing. It should be largely wire > compatible with draft-11 and also defines preliminary code points in a > few places where we had to define them to do implementations. > I've attached a changelog to the end of this message. > Is there a list of implementations somewhere? I've started working on 1.3 as a side project and just talking to myself may get lonely. :) --001a1145dfea46c561052eb27d89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 21, 2016 at 6:05 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
Folks,
This revision is largely cleanup of a bunch of outstanding PRs= and of
issues found during interop testing. It should be lar= gely wire
compatible with draft-11 and also defines preliminary c= ode points in a
few places where we had to define them to do impl= ementations.
I've attached a changelog to the end of this mes= sage.
=C2=A0
Is there a list of impl= ementations somewhere? I've started working on 1.3 as a side project an= d just talking to myself may get lonely. :)

--001a1145dfea46c561052eb27d89-- From nobody Wed Mar 23 01:12:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90312D62D for ; Wed, 23 Mar 2016 01:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] 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 vXPLna8FzQ-5 for ; Wed, 23 Mar 2016 01:11:56 -0700 (PDT) Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (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 5DA7412D1AD for ; Wed, 23 Mar 2016 01:11:55 -0700 (PDT) X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 959D6128163.A24A4 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 959D6128163; Wed, 23 Mar 2016 09:11:52 +0100 (CET) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTP id 923052009A; Wed, 23 Mar 2016 09:11:43 +0100 (CET) Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 8FE1D60030; Wed, 23 Mar 2016 09:11:43 +0100 (CET) Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 891BB40; Wed, 23 Mar 2016 09:11:43 +0100 (CET) Received: from eduroam-24-4.eduroam.ruhr-uni-bochum.de ([134.147.24.4]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Wed, 23 Mar 2016 09:11:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Mar 2016 09:11:43 +0100 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: aluykx To: Eric Rescorla In-Reply-To: References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> Message-ID: <0b6588fb0237c89d71192560b3487e11@esat.kuleuven.be> X-Sender: aluykx@esat.kuleuven.be User-Agent: ESAT webmail service, powered by Roundcube X-Virus-Scanned: clamav-milter 0.99 at cobalt X-Virus-Status: Clean Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data Volume Limits Analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 08:12:00 -0000 Hey, > 1. As I understand it, failure in these models is fairly catastrophic, > so I should be reading Table 1 as "chance of total collapse of > confidentiality", > not "chance of being able to read one plaintext" value. Is that > correct? Actually, confidentiality will not collapse, the limit indicates the moment when information starts leaking, which could start off as little as one bit of plaintext. The bigger issue is when integrity fails. For AES-GCM this could lead to the integrity key being recovered, allowing adversaries to forge TLS records (though to do so for chosen plaintext messages needs a bit more adversarial capability - essentially, enough contiguous known plaintext at the start of a record for some TLS sequence number). > 2. Are there available proofs for a non-chosen plaintext context? This > seems > to bear on the multiple key question: it seems plausible that an > attacker could > capture a very large number of AES-GCM encrypted connections passively, > but collecting a huge number of AES-GCM connections where it gets to > specify the plaintexts seems more challenging, even with BEAST-style > attacks. As far as we know, there are no non-chosen plaintext proofs, however, the bounds do not improve when only considering known-plaintext attacks. Also, analysis where the adversary only sees ciphertext is not very realistic since in practice one can always deduce something about the plaintext. > 3. Naively, from equation 5, it seems like as \sigma >> q you should be > able > to encrypt rather more submaximal (e.g., 1K) records than maximal size > records. If \sigma >> q, this means you've processed many long records. Switching to short records will allow you to process more of them, although the amount of data you can process will not change. > Finally, and this calls for an opinion: do you believe that given these > results > we should include a KeyUpdate feature in TLS 1.3? Ideally it would be better to include a KeyUpdate feature, but the added complexity could risk introducing vulnerabilities worse than what happens when the bounds are not respected, since all of these attacks require adversaries to monitor large amounts of data. If KeyUpdate is simple, then include it, but otherwise it might not be worth the risk. Kenny and Atul On 2016-03-21 00:40, Eric Rescorla wrote: > Atul, Kenny, > > Thanks for doing this. My initial impression is that these results are > uncomfortably > close to the line for AES-GCM, especially for the scenario where we > have multiple > keys: there are probably well upward of 2^{32} HTTPS connections a > day. > > A few questions: > > 1. As I understand it, failure in these models is fairly catastrophic, > so I should be reading Table 1 as "chance of total collapse of > confidentiality", > not "chance of being able to read one plaintext" value. Is that > correct? > > 2. Are there available proofs for a non-chosen plaintext context? This > seems > to bear on the multiple key question: it seems plausible that an > attacker could > capture a very large number of AES-GCM encrypted connections > passively, > but collecting a huge number of AES-GCM connections where it gets to > specify the plaintexts seems more challenging, even with BEAST-style > attacks. > > 3. Naively, from equation 5, it seems like as \sigma >> q you should > be able > to encrypt rather more submaximal (e.g., 1K) records than maximal size > records. > > Finally, and this calls for an opinion: do you believe that given > these results > we should include a KeyUpdate feature in TLS 1.3? > > Thanks, > -Ekr > > On Tue, Mar 8, 2016 at 2:16 PM, aluykx > wrote: > >> Kenny Paterson and I prepared a document providing an overview of >> how much data ChaCha20+Poly1305 and AES-GCM can process with a >> single key. Besides summarizing the results, the document also gives >> an explanation of why the limits are there. The document confirms >> the analysis done by Watson and others in the thread on "Data Volume >> Limits", but goes into more detail. >> >> The document can be found on Kenny's website: >> http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf >> >> Atul Luykx >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Wed Mar 23 01:42:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B950F12D672 for ; Wed, 23 Mar 2016 01:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmhgyhFxJibM for ; Wed, 23 Mar 2016 01:42:24 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 7636712DB76 for ; Wed, 23 Mar 2016 01:42:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id E004F11C7; Wed, 23 Mar 2016 10:42:21 +0200 (EET) 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 xeCM1QCY0Dz0; Wed, 23 Mar 2016 10:42:21 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AE09E21C; Wed, 23 Mar 2016 10:42:21 +0200 (EET) Date: Wed, 23 Mar 2016 10:42:19 +0200 From: Ilari Liusvaara To: Timothy Jackson Message-ID: <20160323084219.GA4476@LK-Perkele-V2.elisa-laajakaista.fi> References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 08:42:26 -0000 On Wed, Mar 23, 2016 at 12:38:13AM +0000, Timothy Jackson wrote: > I’ve noted that many (most?) TLS implementations choose their ECDHE > curves seemingly without regard to the cipher suite strength. Thus, > they'll select an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), > but then generate an ECDHE key on the P256 curve. This seems odd to > me, since the P256 curve obviously has a lower security strength than > AES256. This seems important issue to resolve because most product > (and even TLS libraries) do not allow the administrator to configure > the available ECDHE curves, only the cipher suites. Thus, ECDHE may > be invisibly undermining the security of your TLS connection. The security levels are much less obvious than they at first seem. 128 bit symmetric encryption, 128 bit elliptic curve DH and 128 bit MAC are not even _close_ to being the same security. And if you want to configure things, configuring strong enough ECDHE and strong enough ciphers should be enough... If 128-bit ECDHE is enough, 256-bit symmetric encryption will certainly be enough (can't say the same about 128-bit symmetric encryption). -Ilari From nobody Wed Mar 23 05:13:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BF5312DC77 for ; Wed, 23 Mar 2016 05:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 JmruXLQ4cXb4 for ; Wed, 23 Mar 2016 05:12:32 -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 D2FD512D6CA for ; Wed, 23 Mar 2016 05:07:46 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 8DADE711CB; Wed, 23 Mar 2016 11:31:22 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2NBVLSM012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 07:31:22 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 23 Mar 2016 12:31:20 +0100 Message-ID: <13766372.8JDB5lPV2a@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2987836.N7LvKqy9iR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Wed, 23 Mar 2016 11:31:22 +0000 (UTC) Archived-At: Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 12:13:02 -0000 --nextPart2987836.N7LvKqy9iR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wednesday 23 March 2016 00:38:13 Timothy Jackson wrote: > I=E2=80=99ve noted that many (most?) TLS implementations choose their= ECDHE > curves seemingly without regard to the cipher suite strength. Thus, > they'll select an AES256 cipher suite (e.g. > TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key > on the P256 curve. This seems odd to me, since the P256 curve > obviously has a lower security strength than AES256. This seems > important issue to resolve because most products (and even TLS > libraries) do not allow the administrator to configure the available > ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly > undermining the security of your TLS connection. In my experience, many (12%) servers simply ignore the list of curves=20= advertised by client and use the P-256 curve always. Some (58%) check if it was advertised and fallback to non-ECDHE if P-25= 6=20 is not advertised. > Is this an intentional choice by this group for some reason that I > haven=E2=80=99t realized yet? IMHO, it's just a result of limitation in the libraries - i.e. closer t= o=20 "a bug" than "design choice" =20 > How would this group feel about a proposal to address this by > specifying in the 1.3 specification that implementations must ensure > that the strength of the certificate must be >=3D strength of ECDHE/D= HE > >=3D strength of the cipher? Perhaps an equivalency rule for the MAC > might also be in order? Apologies if this is already resolved > somewhere in the draft RFC. I looked but didn=E2=80=99t find it. Recommendation? maybe. Requirement? unneeded if not harmful, for the=20= points already raised =20 > For what it=E2=80=99s worth, I=E2=80=99ve noticed OpenSSL and other i= mplementations > trying to address this by creating a =E2=80=9CSuite B Mode=E2=80=9D, = but that seems > to address a specific case but leave the generic case unresolved. Only the new OpenSSL actually can use more than one curve on the server= =20 side... =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2987836.N7LvKqy9iR 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 iQIcBAABCgAGBQJW8n6IAAoJEJKo0bgB0vX15KkQAJHdcDiWkJMw39isKYTnjeS8 0Bb/IZG/kPS5uVysJdArC0WIobYjEajkkZWR6zX2zdxMYcnXBng5wtAfEZdGoNtR Bzo96IzONxaD5hd7XF5trjWzvkJ6T8PCCgINh8mR5UdsJjxGadI2wu6Wm6JKnysM Pm7MIwB2OYMjA602wc8m6qJ3Q66DL5BXnNsU22EPYAFd+RPnm/I+rszhZbAAptES PDYxxgDwWWTEGKZilid6MGJf7lELJLNKCtE/sOtDBWZ7gCUSxO0N1/kwX78cWVnM CjvtAemF4rhkajfW0Zf6/xtS/v24u9xS3djkdnPaPq0dfLQYZw0EFQLZqV+/j1cg lv994Tx8eqyYPLMhUBKCl3nqzMMntWoJeJFInABAx3mt589kz7ky124GuSCsHldq wwilNwUCP178G5s8ALYmKw5oOm23b/DsJDeZxgEyR44gomHlh0doZeG17018Zl+2 d8uxqnMZBunFvx54hTaTGXMdMRZ9prcoPgHzArg+bDAwwQGqobOwXObLgRbpaNHq 7xxjSh+Fdlrg7bVYISyqbG6KTkTzJ9zwWYSn38s6j/Kw+VJAWyC3jIeM/1uzRvPL 91w6U2fY2f7u0zekaMLymzvgD2ue170FMRLq9wvWnsc4ukXbvsD3FZFGHEXdYc22 C9tUcbshyBqP+e3vovfU =3XN7 -----END PGP SIGNATURE----- --nextPart2987836.N7LvKqy9iR-- From nobody Wed Mar 23 05:19:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA51B12DC1C for ; Wed, 23 Mar 2016 05:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ng_orGgxKPCG for ; Wed, 23 Mar 2016 05:19: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 4AF0B12DC25 for ; Wed, 23 Mar 2016 05:10:31 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 0AFD62EC; Wed, 23 Mar 2016 11:45:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-113.brq.redhat.com [10.34.0.113]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2NBj7p3021722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 07:45:08 -0400 From: Hubert Kario To: tls@ietf.org Date: Wed, 23 Mar 2016 12:45:07 +0100 Message-ID: <2460523.xZ3yuSrhFl@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.5-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <201603222326.23260.davemgarrett@gmail.com> References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> <201603222326.23260.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2008497.d9QKmqlL0L"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 12:19:17 -0000 --nextPart2008497.d9QKmqlL0L Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 22 March 2016 23:26:22 Dave Garrett wrote: > X25519, secp256r1, X448, one of ffdhe3072 or ffdhe4096, and then > lastly, ffdhe8192 and/or secp521r1 only as emergency backup > (arguably, X448 belongs back here too) >=20 > I'd like to specify ffdhe2048 (~103-bit strength) as "MUST NOT" use > for TLS 1.3+ and only support it for transition in older TLS. (this > came up on-list a long while ago, but needs further discussion) DHE gets prohibitive (computationally) rather quickly, and given that=20= 1024 only /may/ have been broken, a "SHOULD NOT" for 2048 with "MUST us= e=20 ephemeral key share" is IMHO more appropriate > I'd > state secp384r1 (...) as "NOT RECOMMENDED" to bother with, > but still permitted=20 I'd say it is a tad bit too strong of a wording for the strongest curve= =20 supported by SChannel... =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 99/71, 612 45, Brno, Czech Republi= c --nextPart2008497.d9QKmqlL0L 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 iQIcBAABCgAGBQJW8oHDAAoJEJKo0bgB0vX1ODAP/2xf9YkCoZ8kCDrhx/rcbYCN B2KKb8xLez8vutQmSmtwUkIInwRZ/iQYd3E4LmMY/SehLRFdmcpbB14N+e+VDz2s UTUOcRv6jDRFTDaVCXP/QGgpCdSl+VMsl8k4TDKKEdElT0Soh49yBr8sOLCPtQCL zi4CCGSoGme9EvvZvXD9V+5tRvi+DsMkdqmrOFcVhjbYay4Tw/nJl9jZ5yfu1LHt 73v4hHGUvY9ABDM1P4NSru0VcYPhshfhe0CFSKfa6D1rn5k2QfUNmnfN2Yd755RR fWgKTb6Tdl2MEv2YLEivRWGmvo7vxioJZPO+uIGe+P3xRg1wxJ6KYGOz0im5kwE+ aB2vtjvb1sO/OU3cqQ+hfJ9TzTS+mogcoRN4MyE5f6rSVoHpfTmhdmetQbbvFX49 ldOjoYeMVSYZufW4p+NnUf+e5+tT9+LjX/MvvYCsA1U6cUsZkYf3t7f1vPPlbPV4 FNAbQsxSgvpm76gKH3rSvyiWaZeyG0dts81XFBud70qXQTtqE03DIX04FNR2qdP3 fKU0lwd4uxOg3TJ46t5qOVPnxJYmoGvsJTG8Dta9LO19tO+a+qw8t/8XVIO0pSXg gvs4Up38X8t3JqRcGk4gkbgRPMtVjbnUplrbq+zTutLPI6bf9ytbL8wezEu9kNIQ hHBr4i0sLZibmbtXzkAO =4U3z -----END PGP SIGNATURE----- --nextPart2008497.d9QKmqlL0L-- From nobody Wed Mar 23 05:41:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B0C12D544 for ; Wed, 23 Mar 2016 05:41: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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WvX0WCJJtVVs for ; Wed, 23 Mar 2016 05:41:21 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC2CC12DC38 for ; Wed, 23 Mar 2016 05:31:24 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id r129so133973270wmr.1 for ; Wed, 23 Mar 2016 05:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=eLk2vMWKuhv/iPO3tF7/viyBKoEaMKGlNcP/fRISwzY=; b=VPJLhUP7dCr3XZKUERqWhQ5/0QEaWkQZMfB4bBjM44hknSBStoMIGumtxZhdHBe7FH A3qqr/ckYTqY4fDoqgWTHIamiSmKfYRthcy5mWoIe7mdKAvr5XDPFkiNqonvYPKqYIpE c2teFwlbp+dgoSndeKjBCpo70jmi4o41BFSe0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=eLk2vMWKuhv/iPO3tF7/viyBKoEaMKGlNcP/fRISwzY=; b=a50NAVgV3bITavyGgd1tOQ/GVQH/seDaY6PFXqdRzB52ZlBALbyQ3My5VM2pgh4Iy1 tWEEQQSjnCELySAFfzdSYn3dkbXOhPNtAXSpj+WOAqwIiWtTLHfbjZsAbvv5olvywAef DCJCnCTATRtOt0HWrr9dYqhQR3ir/gT9IlB6mf4MQgIKHnRUgHawBpnICc+kPcqbv91o co3grLdXHU/UQGRggnToKkNMA802sbERnAIXk005E/qkvR4v5XWJfn2qusJEDonAbPQw +YxL65yuY9A5/idg3VAWazkLNppcWbyiwP6Jk2S2gWeBEzqnZsbO0yXEylzDw7yb0Mif 4y2A== X-Gm-Message-State: AD7BkJKnm+Qmp1+Zb0mxkcGCGpQ0L5V5GDv02rEo2zqLkyZ/XNmagpiGWrcrxjjHiQOHMA== X-Received: by 10.28.131.141 with SMTP id f135mr25350007wmd.33.1458730022308; Wed, 23 Mar 2016 03:47:02 -0700 (PDT) Received: from typhoon.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id jo6sm1908349wjb.48.2016.03.23.03.47.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2016 03:47:00 -0700 (PDT) Date: Wed, 23 Mar 2016 11:46:59 +0100 From: Aaron Zauner To: aluykx Message-ID: <20160323114457.2d269ae6a9@24e3576741335c9> References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> <0b6588fb0237c89d71192560b3487e11@esat.kuleuven.be> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <0b6588fb0237c89d71192560b3487e11@esat.kuleuven.be> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Data Volume Limits Analysis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 12:41:40 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * aluykx [23/03/2016 09:12:02] wrote: > >Finally, and this calls for an opinion: do you believe that given these > >results > >we should include a KeyUpdate feature in TLS 1.3? >=20 > Ideally it would be better to include a KeyUpdate feature, but the added > complexity could risk introducing vulnerabilities worse than what happens > when the bounds are not respected, since all of these attacks require > adversaries to monitor large amounts of data. If KeyUpdate is simple, then > include it, but otherwise it might not be worth the risk. Thinking about this a bit before I read your reply, I came to the same conclusion. It could be useful if it's well done and implementations update securely. But that's hard :) Aaron --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJW8nQhAAoJEOTbZJL9ubXVfBwQANiyqFjSgSeIFiq0PxDGoDJ1 81WgLFyv0BT4PyiZkiSejeyh1gyoyF2V7kTnFNc1pWFxF2SFlCA5rbGCyXK/Iq0E n79G8dZuJvMkotejDiNdCRpCgcJ/cHNHEJrcFP4A0OYK5G/ZYa7qrWHk34tvj7ZH kVx5Vg5MvapSetcVK0UcHG7+ELMZotmAYvcZjl2b2qMMiE1iUuzo/va3yngvoelt OwC3XwE5Uz2/PCT54MuFSWwek9FwXMDECCLatLNxT771nD7kpfHXrr2U5kgHkFK9 +wn9tSD0SoJP2P8ZW9ulV7c9ThT+B7nP+mNSl4b4DsC9waVs7BTK2OEre0wII1rG ZjHVMvCztxI5395xifOcpM1PB2Kr01R+MR6J1xKSKpB7DzT9bnHCTvAf5TWhCF+Z JiZ8jv3sZyEzdl5gqps6/yG4qupAJt5BtKNA0qTLh0b8kXmOC3tF3qoQivXfgPPt 4iFzJqWpwEAuULoO2ezGToCGvNoFUeDOrADiDhr+e3RZMJynRhSx+l6WimU97kmq P6GD+tJvgNz+XNUyNJEup7oZhZGXMpGELDLEekfAl+EoKSTycnbX955tt4qSUiD/ 2nsOB0DWi5ZwpSg/Cldwh/l002HfwLaV+lLK+05iMxXF6UtsVfth/EwZyX+sd381 0dQf96uPPnak6l2mc4s6 =DHf4 -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From nobody Wed Mar 23 05:46:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AF112D5C2 for ; Wed, 23 Mar 2016 05:46:57 -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 TRXfnPYJLJJv for ; Wed, 23 Mar 2016 05:46:55 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::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 C216F12D65C for ; Wed, 23 Mar 2016 05:36:21 -0700 (PDT) Received: by mail-ob0-x22c.google.com with SMTP id fp4so10496617obb.2 for ; Wed, 23 Mar 2016 05:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=QSujW7GvQdLXYe7+xLu7K+77oMK41ofpA04GDx+h1OU=; b=Rp33aC8oOLtzFSkF2zPd7yrvr8TTdXkXsEhef+icRMO+FPRf9DXLSqcsgB9tC7Mp6a HUp1Gy9CoRKcFX+vBbZX51I4JoM9O/JukJWIGUo9ZyMi4WIH9gTbQFInexHubpp1Bjm5 plR6AVFdNXvm27dmnhHdX7RY7E/oEKZT+Ikhc+ybiTgNhC1F2Csr2cWdrjXR4OxISl4W 5VAMmNmemXJecotflvY+g5K+Ey0zKetuHAzFOESAT+6cQgpN1eS9sk9774dMvFF0OLTH WdEsqGNNF9ezbSGVExNh06IBg0n5hakhG3FmaQc11W2WZsMNe1+dV7Q+97aTgdv6TOhV ngaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=QSujW7GvQdLXYe7+xLu7K+77oMK41ofpA04GDx+h1OU=; b=O8mU6tuAXhJV8FUAWDP4V0K1GZ2w+sEcjdrMGcpgf00bPhwhYFWzIhPJgbHrHaGt9C Lonha5oZkMMeHG4EJwb4NOxkETpm9epwcu8iI9iwWF1RrUWp+b+L8JytEkeK28OpZl/8 9D6mLFqwHNkeTAG0NxOgNzCSlr5TyzJk8wSxPvaIlVGcQ55vh6JTQ6Ks6cKIGFvZgjwy t4mKt1+8TP2EAi0gqhEnbWFcIPUltmFE0ME2zrwDH0Al57UY1syt3jOBIEkhAh/JNiT0 6C+qVOtjjFsHm6kFQbbKwFx0w+38YaOZyO00ChWscUVtYntjEHKqJCk970anJValoWIN KQmQ== X-Gm-Message-State: AD7BkJIv9hWd8GLeY/xluyje/WUwbfC3ekXaBer0CKwZk92eEyQ7eg91+nMeFL0YSFeovOMLsDeSS2TJasVWsg== MIME-Version: 1.0 X-Received: by 10.50.171.130 with SMTP id au2mr23639984igc.58.1458729962066; Wed, 23 Mar 2016 03:46:02 -0700 (PDT) Received: by 10.36.43.5 with HTTP; Wed, 23 Mar 2016 03:46:02 -0700 (PDT) Date: Wed, 23 Mar 2016 21:46:02 +1100 Message-ID: From: Martin Thomson To: Glen Knowles Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: [TLS] List of implementations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 12:46:57 -0000 I think that we're getting to the point now where a list might help. https://github.com/tlswg/tls13-spec/wiki/Implementations Add your implementation to the list, or talk to me about getting it added. On 23 March 2016 at 18:43, Glen Knowles wrote: > Is there a list of implementations somewhere? I've started working on 1.3 as > a side project and just talking to myself may get lonely. :) From nobody Wed Mar 23 07:11:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B4D12D782 for ; Wed, 23 Mar 2016 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] 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 f0M-p48Px0mU for ; Wed, 23 Mar 2016 07:11:37 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A443F12DBC9 for ; Wed, 23 Mar 2016 06:55:25 -0700 (PDT) Received: from mail-lb0-f180.google.com ([209.85.217.180]) by mrelayeu.kundenserver.de (mreue104) with ESMTPSA (Nemesis) id 0Lsi5p-1ZlVy62QAb-012Kjo for ; Wed, 23 Mar 2016 14:55:23 +0100 Received: by mail-lb0-f180.google.com with SMTP id bc4so10993164lbc.2 for ; Wed, 23 Mar 2016 06:55:23 -0700 (PDT) X-Gm-Message-State: AD7BkJJjSObo5VAFgYpz7TuYVRbcq3kF1FeojQJY/Ka5SC3jWyVr+x3xdu+RrYMTzptE7aA+I9f2W8iPSG+dDg== MIME-Version: 1.0 X-Received: by 10.112.13.33 with SMTP id e1mr1115794lbc.79.1458741322835; Wed, 23 Mar 2016 06:55:22 -0700 (PDT) Received: by 10.112.22.67 with HTTP; Wed, 23 Mar 2016 06:55:22 -0700 (PDT) Received: by 10.112.22.67 with HTTP; Wed, 23 Mar 2016 06:55:22 -0700 (PDT) In-Reply-To: References: Date: Wed, 23 Mar 2016 14:55:22 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c39e265defa3052eb7ae99 X-Provags-ID: V03:K0:Rf9w/KgQhtw9pHmj9zowgpZlUYm8j3AalWumSIyDJkvP09yw3Mb O81bS2/FIjWC7TP9PmdYn3YP9qDE7/MNJU/mgybQcv4QSV0WzxUYKhjDEdY8WL26MFNyJAy OKyOXktfS7bvanfOeswcgBFsEDsf8L2I/1/5/R1EhQa3VBBSzD8bpn9ob+vnFAHDYo9yYVx H+npRK1+MJUVJde/D1Z+A== X-UI-Out-Filterresults: notjunk:1;V01:K0:jBn+0SLd0DE=:EbWEDX3mhq5vrCkNUX9G8k CGXudRG35pgp+Es7FJhqkbSJmFQ6J2FhGVqRVs9OXI3xTj/rJhGc9Zx8N0mOISxvlZGzYQSuK Zmaoe4n2BqN+c9YhDOwbc++V+KmpNCOlPgjxyBVG6XwZkCCeTiifGc5MkBzejs3svr34/SL48 D7qCADRMaaCmVLkNRnO7sba/EFnHsgpKbvK22vmGoJg6kDi+qbHFf72ay3Deh9hNTO25OGdr4 i2D6pb/9nj7HblVwX0xV5XQisn+qKsxwq7UR3e5JR0SUxLgsFqD8ZSFLmTsIwVAMWYdul6fzU FAcnwpI96sBBXrs0Pq3OXD4yWvUV1QXRZHFAL45qUViungqm+6ZElUO271pWKwyws+Tw3pRqU 24EMK2AFhG5X8x8LRvIP8OA/pSt7VYoegFYhlKrr/C+52/c/I3d16DW6Jk07BlUgmjOjBBRJO VCx/zBSFiW83oOY88nlQDod95PgHII84uiZPUkmYIS6qhkrzsB4h9FrXFp3FRmdw+qjNgNdYf amzXBUF9JAYy3tB3FV1lwynaT9Er/3qIvBCOIg/womNB4M/C9wy4HZvXFwc1DAegLqC3jR9N/ NwONmRds3oY+vIQq8uk+w/SaAPjh8k0wZLhEuzfZE4CsqzOFInA4CtIju76FH6poQHYOBXRH/ qrtMs/jLarTbjMzGsijtqvuzkRsbGpmG2eTT6XinCnUFn8Xwtk0WNcGjS1pVSopFxPaq9YMnv hQZqAsE+YcVaWmps Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] List of implementations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 14:11:39 -0000 --001a11c39e265defa3052eb7ae99 Content-Type: text/plain; charset=UTF-8 Martin, two remarks regarding the section "Version Negotiation" (quoted below). 1. The ASCII encoding of digit "1" is *decimal* 49, or 0x31 (the given example 0x494a corresponds to "IJ"). 2. It might be useful to remark that server implementations of the final protocol version should still watch out for the extension during a migration period, and if the extension is present, check that the value provided agrees to the draft suffix of the version that eventually got standardized. (More importantly, the draft implementations must be taken out of use before anyone other than the early adopters completes their implementation of the protocol :-) ) Bodo *Version Negotiation* Note that most of these implementations signal the draft version in a two-octet extension that uses the code point 0xff02. Set this to the ASCII encoding of the draft suffix (for example, draft -12 is the value 0x494a). Until the final version is released, please require this extension before negotiating TLS 1.3. If the value is not present, or it doesn't match your implemented version you should negotiate TLS 1.2, or fail. Am 23.03.2016 13:47 schrieb "Martin Thomson" : > I think that we're getting to the point now where a list might help. > > https://github.com/tlswg/tls13-spec/wiki/Implementations > > Add your implementation to the list, or talk to me about getting it added. > > On 23 March 2016 at 18:43, Glen Knowles wrote: > > Is there a list of implementations somewhere? I've started working on > 1.3 as > > a side project and just talking to myself may get lonely. :) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c39e265defa3052eb7ae99 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Martin,

two remarks regarding the section "Version Negotiation&= quot; (quoted below).

1. The ASCII encoding of digit "1" is *decimal* 49= , or 0x31 (the given example 0x494a corresponds to "IJ").

2. It might be useful to remark that server=C2=A0 implementa= tions of the final protocol version should still watch out for the extensio= n during a migration period, and if the extension is present, check that th= e value provided agrees to the draft suffix of the version that eventually = got standardized. (More importantly, the draft implementations must be take= n out of use before anyone other than the early adopters completes their im= plementation of the protocol :-) )

Bodo

Version Negotiation

Note that most of these implementations signal the draft ver= sion in a two-octet extension that uses the code point=C2=A00xff02. Set thi= s to the ASCII encoding of the draft suffix (for example, draft -12 is the = value=C2=A00x494a). Until the final version is released, please require thi= s extension before negotiating TLS 1.3. If the value is not present, or it = doesn't match your implemented version you should negotiate TLS 1.2, or= fail.

Am 23.03.2016 13:47 schrieb "Martin Thomson= " <martin.thomson@gmail= .com>:
I thin= k that we're getting to the point now where a list might help.

https://github.com/tlswg/tls13-spec/wiki/Imp= lementations

Add your implementation to the list, or talk to me about getting it added.<= br>
On 23 March 2016 at 18:43, Glen Knowles <gknowles@ieee.org> wrote:
> Is there a list of implementations somewhere? I've started working= on 1.3 as
> a side project and just talking to myself may get lonely. :)

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a11c39e265defa3052eb7ae99-- From nobody Wed Mar 23 08:15:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4E12D0EE for ; Wed, 23 Mar 2016 08:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 6r3NSuMPpBtt for ; Wed, 23 Mar 2016 08:14:57 -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 1EE0A12D598 for ; Wed, 23 Mar 2016 08:14:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C4EF2BE2D for ; Wed, 23 Mar 2016 15:14:50 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXVyw2YVIvlL for ; Wed, 23 Mar 2016 15:14:48 +0000 (GMT) Received: from [192.150.181.133] (unknown [192.150.181.133]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A2CF0BDD0 for ; Wed, 23 Mar 2016 15:14:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458746088; bh=Wox9GMT0pvG43KK89lz8PEgYIb9i8eA9AafEKJATuQw=; h=To:From:Subject:Date:From; b=A8rRSW+bMJokZNE6LKzKc0Fv5b/mU5RMgUsodxZKoQuhtsU3HX8+EGvBp0aW4fjcl FpfTKaDh7NPZ0NZBfzYO3BiY5yZJkjwIo707JpV6JSrZow4vhws44p/XvIaNmm7WXi D3pa78qpiYNz+qI7+I5icCDAoUxbdNSC00OfV7yE= To: "tls@ietf.org" From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F2B2E7.1060809@cs.tcd.ie> Date: Wed, 23 Mar 2016 15:14:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090404070109050808020306" Archived-At: Subject: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 15:15:00 -0000 This is a cryptographically signed message in MIME format. --------------ms090404070109050808020306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I've done my AD review of this and have three questions I'd like to ask before starting IETF last call. I mostly care about the answer to #3. #1 is just a suggestion that might avoid some process-crap and #2 is just me being curious (unless #2 turns out to be a part of #3). (1) Why experimental? Wouldn't this be better as info and documented as "here's a spec for a thing that's widely deployed." I fear we may get questions like "what's the experiment?", "where's this going in future?" if this aims for experimental, and info may avoid that esp if we really want people to move to TLS1.3. I also didn't see list discussion about what kind of RFC to aim for, but maybe it was discussed at a meeting or interim? (Apologies if I missed that in my scan of the list.) (2) The write up and some mail list traffic and AGL's bloggy thing all refer to NPN, but there's no mention of NPN or ALPN in the draft. What's up with that? (Not saying that needs to be explained, but I wondered.) (3) Why is there no description of the reasons for all the MUST only use whitelisted and for the choices that are whitelisted? Wouldn't omitting that tend to lead people to use this more badly? That could be done with some explanatory text and using some of the references below maybe. Or, if we don't really want new folks to implement this (do we?) then just saying that might mean it's ok to not explain the "why." (And then you could also address #1 above then by issuing this as an historic RFC too if you wanted.) Cheers, S. Possible refs: - http://www.ieee-security.org/TC/SP2015/papers-archived/6949a535.pdf (esp Section V-C) - http://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf - https://hal.inria.fr/hal-01184171/document - https://arxiv.org/pdf/1602.02396.pdf - https://eprint.iacr.org/2016/072.pdf --------------ms090404070109050808020306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjMx NTE0NDdaMC8GCSqGSIb3DQEJBDEiBCCW7Gp65HhLuuC6hKrnrFGKW4cqb4qp9X6jeuNOpSAw eDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAxVeyWrtG/Lbtn9sUWTx0g/X2SWuYOuja0rXpkQ3yrcw3TQnFNhG4G 1U/dwV4hEEgRCFiGOf741zYHfpG5HTRRG2aeETu/jDjsnGuUoP2tyughEyWz+k6rz4VPG12P GIuERDLjXZZWmOCMgs0ODoGNhL2HQaGJTg0DFllSoml/U039oGxGFVsaltN+JxnofJhSoure 1IlWkO3LV/brJsQiI8D1jYiVz9D6zBJXTOik/Ou33Gb+Gdmoxvc19WNRg/uzvL3PZ1OWl9RB BnMrSAHX3CqOmmONrccuorq6bpFwI94BlXs3i3QVaENcuyK7YlQ6KQhgiKPRYXvlg3V73j3A AAAAAAAA --------------ms090404070109050808020306-- From nobody Wed Mar 23 08:29:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6778C12D633 for ; Wed, 23 Mar 2016 08:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaG5_TZpeEYO for ; Wed, 23 Mar 2016 08:28:58 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id A773812D5BB for ; Wed, 23 Mar 2016 08:28:56 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u2NFRq6e032208 for ; Wed, 23 Mar 2016 11:27:54 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC Thread-Index: AQHRhJxIvdQqc8JxV0CUtKcN/21N7p9moWAAgACLWoD///trgA== Date: Wed, 23 Mar 2016 15:28:53 +0000 Message-ID: References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> <201603222326.23260.davemgarrett@gmail.com> <2460523.xZ3yuSrhFl@pintsize.usersys.redhat.com> In-Reply-To: <2460523.xZ3yuSrhFl@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-originating-ip: [172.25.177.51] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha384; boundary="B_3541577323_76510640" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-23_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound 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-1601100000 definitions=main-1603230238 Archived-At: Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 23 Mar 2016 15:29:00 -0000 --B_3541577323_76510640 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable >>I=E2=80=99d state secp384r1 (...) as "NOT RECOMMENDED" to bother with, >> but still permitted > >I'd say it is a tad bit too strong of a wording for the strongest curve >supported by SChannel... +1 to Hubert. --B_3541577323_76510640 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQ4AYJKoZIhvcNAQcCoIIQ0TCCEM0CAQExDzANBglghkgBZQMEAgIFADALBgkqhkiG9w0B BwGggg6fMIIE6jCCA9KgAwIBAgIKMztKZQAAAABumTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzMzN1oXDTE5MDExMzE3MzMzN1ow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqifs8K0OoodbmOo5G/j2+p2ibbOsEoJ9GJjK8K1Iw 6iig59a3EuNB6NR4tAR3INwjjUwMCa4o8ysnk1hN32B3HPrK5Z8++Y/xcX5iP1L6fc51YQ5C /EGvrSbjuPLvt19SNfVdwcuoc842Sgk9N/HemdwmvcqJkwzWDsuxKikI2clT1N5LTAaPMkhr HVuYOHBE0mCXjHjFnYuHsEXyVvUZLxziDgduV9WKbC90Z1NZMXB6ZeQTACUWgMfpFrE12LKb fvOmxepCBfCPbGB3ZyG+FaUdtQoCEAbGTnY7nCedQFn7pV1hppCt4jjLVlOpgYc3dPmyiXsL nhDQZ5ptmks/AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUiXqPublGfd0sWKNk/BObT6Oorzgw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAK7HM6o1IolvkCJrlsjj N1+0Z2JG8anwkHkVKAg/K9qUD0LE9zbnK3kZRGZsljJUDG+hMWmTWCkx0TTzbg/BeVrypVPD 7rn1Tagi9QBV2eJhdBZRHWOcsteRldUukKbMw74hkNGH9o/p/FFZYMA0kHnA7XfECilF9Yl6 uKDv1lbjuWdgcKD1FdEj7rL/IdX0wKJVUKjwLG1RQZel1nuwyRjVtXWz8IUMJXRsYHf6uSzy YoNBeZuWyMx/J5c0ACKXXs1O721GPJ5U5gcEaQ/b8lwQGcOgPk28RPwgiBF3f5TgrTa7QxGf ozmNsTj1OV1vU0vjqKrg7USi9q0xTdGUIyowggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIE7TCCA9WgAwIBAgIKMziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJV UzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYD VQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBl b3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4cot eDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4 u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n 2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh 6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQV ubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCow KKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEE WjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYI KwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAu BiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUE HjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIB AwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUA cwBlAHIARQBuAGMALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV 2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwX ENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2Pz BkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvv k0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa 1Vshx7ElBIk0cXhep6mLMLqGNX3azAkxggIFMIICAQIBATBfMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTMCCjM7SmUAAAAAbpkwDQYJYIZIAWUDBAICBQCgeTA/BgkqhkiG9w0BCQQx MgQwk+wVD69Ns6cJy2UG8kMVOILjuiDdZMOgPT87hX2PFipOEz9iTOlzpA5teUZOPpNNMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDMyMzE1Mjg0M1ow DQYJKoZIhvcNAQEBBQAEggEAlRr0nivZw6Cpo4ghRkNFTxoSymyn7MVmCaniZ+hgWjfUuTyw clNS94Ud4GF9ZWXDmWMA0KHIgakT87GGEci6Y6fIZkAtb4wTSZ6B1dk0VZR9moE3YFkW639I 1Zj6csXDek6SHZb0MUi+69UZzZeyhsXMn/f0DUdMMLyANIhKff1UhlPdjL3XsrPWCNb2Cr4E 4Gn5eJ24ppE/hyZjx7/H894iuzZJKdycDo+2ItzRBQyAMr94A29HO0FegblGg27M87nZpL1H LbzVDdRn0k0WAVaIlAT/occdVQyFTIdpFV7vyQukg75a6zOIg3M6RwcGEKy2PUktz7zr7BbU dyyhqQ== --B_3541577323_76510640-- From nobody Wed Mar 23 17:38:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CAE12D112 for ; Wed, 23 Mar 2016 17:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_SOFTFAIL=0.665] 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 Ai2Im4DwAMtR for ; Wed, 23 Mar 2016 17:38:21 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F56128874 for ; Wed, 23 Mar 2016 17:38:21 -0700 (PDT) Received: from mail-lf0-f49.google.com ([209.85.215.49]) by mrelayeu.kundenserver.de (mreue002) with ESMTPSA (Nemesis) id 0M8u6u-1adMRD1dVM-00C9fS for ; Thu, 24 Mar 2016 01:38:19 +0100 Received: by mail-lf0-f49.google.com with SMTP id d82so23296925lfe.3 for ; Wed, 23 Mar 2016 17:38:18 -0700 (PDT) X-Gm-Message-State: AD7BkJJFxurOnRmdSykMQyC4tUUPVJiQdmHt4DTIpO9Qyl27l3UB+bWLKTQlP64sXUh7J6MrR8gwXELZqjvwxw== MIME-Version: 1.0 X-Received: by 10.25.207.204 with SMTP id f195mr2301060lfg.41.1458779898598; Wed, 23 Mar 2016 17:38:18 -0700 (PDT) Received: by 10.112.22.67 with HTTP; Wed, 23 Mar 2016 17:38:18 -0700 (PDT) Received: by 10.112.22.67 with HTTP; Wed, 23 Mar 2016 17:38:18 -0700 (PDT) In-Reply-To: <56F2B2E7.1060809@cs.tcd.ie> References: <56F2B2E7.1060809@cs.tcd.ie> Date: Thu, 24 Mar 2016 01:38:18 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1140052ea95df1052ec0a954 X-Provags-ID: V03:K0:Md6NgWg1q5HHjpezx7BfJyoLM2Aadl9yQwaHjAq0BzOXa6mFGWP ugbZqPX8JiNaHus6Op/cLWm0pbzDyAEh9FmrBNwMSnd6PqwjXTS3nWn8x+UWML2bwMMZCzv sZpIVqxBv19PaD67oiWMGjBq5c7KwdtH+2SuGao2YOnFedMmIaUdbZQ1FHtUd+DZ189V8yK iQVi90TLxIyFlrPanRyhg== X-UI-Out-Filterresults: notjunk:1;V01:K0:94Gomiju8mQ=:vwE1DTFPJKHPV3KVbw/yPK 8vZ47xeRpYMU7xr+GjQnOKK96O66Gut1vwRW08jgB7SxA2vyWdRPsi8yEIuvkyKuln4hvd8xJ 638TANJ8JQ6KwyG8ziGTb7dB9VZN8hBHFsnNQl4uIKjBotan+tZDsV8dJfYtCdqTcwyNcwO+n OJjbReo/gMLLSEbPFXtJDedEHPIgTeJXh6as0C+IRjtLxQ+yzTc1NvP2qhK+Qq0JARsD7C1qb N7mpARjekYiylRRdaTHrAQVyc0JzjMgt034rqwYuqFZLzwclRvy89Uvo80ovSV3LoSI5wIgYb Rw2Ca0y6bTnLtzjTW011sG5JQ2Fe9fxg0RpCTtkKde7V9LDblwRTalLxE2HQDR+gvuhtriIU1 SPNJEmkblMi3RBhsnAQ9lNJ+f1QDqHU/K3UL/oS5B5I14VWJQbGlgm1hWduu2+Gx6GaGdJs4T dlNBUPNwVRtO47jlvWuJywce/QiA7vJxKAr/lcvytCsZlH+o3WHHZXw0NyQnCcBrHX02Me39V 3bmK2Xpq5C53Y1eRQJ+JK1VTy1a8eZTX+vqdrH4AC2IIHBM61EvdVXPxTCEO0aZHa4COdN4vM RykLapdmAq0zxH0DV5xAijMHq/LAlW92rAQvn9CVTA/SQQZljYMn+9URgKFbdFztADTkJG9CM HzpPqW/xSsHk5d52wYiwESNQ/xKZFZb51AU2zBss5ZTHtlOQPHfwO2iwK6AdQtMdDSzyKU+7L oYMHEbx7S/grac5d Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 00:38:24 -0000 --001a1140052ea95df1052ec0a954 Content-Type: text/plain; charset=UTF-8 "Stephen Farrell" : > (1) Why experimental? Wouldn't this be better as info > and documented as "here's a spec for a thing that's > widely deployed." I fear we may get questions like > "what's the experiment?", "where's this going in > future?" if this aims for experimental, and info may > avoid that esp if we really want people to move to > TLS1.3. I also didn't see list discussion about what > kind of RFC to aim for, but maybe it was discussed at > a meeting or interim? (Apologies if I missed that in > my scan of the list.) I'm myself torn between "Experimental" and "Informational" (certainly not "Historic" because the spec has not been superseded by a more recent one and is not obsolete for any other reason [ https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow manage to complete TLS 1.3 standardization before this). Taking into account how False Start is actually deployed (and taking into account that we expect it to eventually be replaced by a TLS 1.3 mechanism) and how our I-D is cited in research papers on TLS, "Experimental" sounds right to me: the spec really is part of a research and development effort [ https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational" wouldn't be wrong either. > (2) The write up and some mail list traffic and AGL's > bloggy thing all refer to NPN, but there's no mention of > NPN or ALPN in the draft. What's up with that? (Not > saying that needs to be explained, but I wondered.) The NPN dependency was a design decision for one implementation, but it's not common to clients using False Start. For interoperability, you always have to consider how to deal with what you expect to be deployed *currently* (and NPN support certainly is one good indicator for False Start tolerance, if you don't mind tons of false negatives), but I wouldn't see much value in compiling the minutae of that in this kind of document: it'll go stale quickly. > (3) Why is there no description of the reasons for all > the MUST only use whitelisted and for the choices > that are whitelisted? Wouldn't omitting that tend to > lead people to use this more badly? Well, I tried to capture the general reasoning in the spec -- but not the detailed reasons for the specific choices suggested, because that again would just go stale quickly. In particular, I think this is an important observation in the I-D: "If heuristically a small list of cipher suites and a single protocol version is found to be sufficient for the majority of TLS handshakes in practice, it could make sense to forego False Start for any handshake that does not match this expected pattern, even if there is no concrete reason to assume a cryptographic weakness." So the whitelists should have algorithms that are actually used in practice and that don't have critical weaknesses, but why exactly those particular algorithms happen to get used in practice is mostly out of scope here. Bodo > That could be done > with some explanatory text and using some of the > references below maybe. Or, if we don't really want new > folks to implement this (do we?) then just saying that > might mean it's ok to not explain the "why." (And then > you could also address #1 above then by issuing this > as an historic RFC too if you wanted.) --001a1140052ea95df1052ec0a954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

"Stephen Farrell" <stephen.farrell@cs.tcd.ie>:

> (1) Why experimental? Wouldn't this be better as in= fo
> and documented as "here's a spec for a thing that's
> widely deployed." I fear we may get questions like
> "what's the experiment?", "where's this going i= n
> future?" if this aims for experimental, and info may
> avoid that esp if we really want people to move to
> TLS1.3. I also didn't see list discussion about what
> kind of RFC to aim for, but maybe it was discussed at
> a meeting or interim? (Apologies if I missed that in
> my scan of the list.)

I'm myself torn between "Experimental" and &qu= ot;Informational" (certainly not "Historic" because the spec= has not been superseded by a more recent one and is not obsolete for any o= ther reason [= https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow m= anage to complete TLS 1.3 standardization before this). Taking into account= how False Start is actually deployed (and taking into account that we expe= ct it to eventually be replaced by a TLS 1.3 mechanism) and how our I-D is = cited in research papers on TLS, "Experimental" sounds right to m= e: the spec really is part of a research and development effort [https://tools.ietf.org/= html/rfc2026#section-4.2.4]. "Informational" wouldn't be = wrong either.

> (2) The write up and some mail list traffic and AGL'= ;s
> bloggy thing all refer to NPN, but there's no mention of
> NPN or ALPN in the draft.=C2=A0 What's up with that? (Not
> saying that needs to be explained, but I wondered.)

The NPN dependency was a design decision for one implementat= ion, but it's not common to clients using False Start. For interoperabi= lity, you always have to consider how to deal with what you expect to be de= ployed *currently* (and NPN support certainly is one good indicator for Fal= se Start tolerance, if you don't mind tons of false negatives), but I w= ouldn't see much value in compiling the minutae of that in this kind of= document: it'll go stale quickly.

> (3) Why is there no description of the reasons for all<= br> > the MUST only use whitelisted <foo> and for the choices
> that are whitelisted?=C2=A0 Wouldn't omitting that tend to
> lead people to use this more badly?

Well, I tried to capture the general reasoning in the spec -= - but not the detailed reasons for the specific choices suggested, because = that again would just go stale quickly.

In particular, I think this is an important observation in t= he I-D:

"If heuristically a small list of cipher suites and a s= ingle protocol version is found to be sufficient for the majority of TLS ha= ndshakes in practice, it could make sense to forego False Start for any han= dshake that does not match this expected pattern, even if there is no concr= ete reason to assume a cryptographic weakness."

So the whitelists should have algorithms that are actually u= sed in practice and that don't have critical weaknesses, but why exactl= y those particular algorithms happen to get used in practice is mostly out = of scope here.

Bodo

> That could be done
> with some explanatory text and using some of the
> references below maybe. Or, if we don't really want new
> folks to implement this (do we?) then just saying that
> might mean it's ok to not explain the "why." (And then > you could also address #1 above then by issuing this
> as an historic RFC too if you wanted.)

--001a1140052ea95df1052ec0a954-- From nobody Wed Mar 23 22:27:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A835B12D515 for ; Wed, 23 Mar 2016 22:27:22 -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 5JxNiiVI4uJy for ; Wed, 23 Mar 2016 22:27:20 -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 C602A12D168 for ; Wed, 23 Mar 2016 22:27:20 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m184so75606617iof.1 for ; Wed, 23 Mar 2016 22:27:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hIBL1SUI/Fz8fA6fbQ4SK7BrYzB+8GabNBu+AxINKI4=; b=T/ZFR1TTMzG1wdO1Raoyp1WbZxqKcCwtHJbOGPIJ3WGQh28esrjG3+Z/ysJKqan9Pd rVDjkaaypDSx5tPdch83j7Dt7QRglI4iPVWBT9szw1v/24O3aNdIm/xysAyhdWeeCocl dFrHijEDZs/bSi36brZ+JOnl8p0QbcZhjjwk8NzDcHOe1kguGLubM5JxeIqNM9ilEWMI P6UMWDqU1GdneJrZ3L6NHpGQv/LZ2/qrfQ39gpzoc1Fxu7m5eYIawk9gjNbvC9sNwTme AQ7Q7csxFrRAq1qAK1mIPPSMtn+DmwACFninwKXETl3WfxmLhNSWngCYIdU2TW28LDJE uXcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hIBL1SUI/Fz8fA6fbQ4SK7BrYzB+8GabNBu+AxINKI4=; b=JchywvY9c0nkdu9MeiTx3qcqRR0zO6jfOT053bP4uSjvmDQWQN0Vr389m+Vk3zx5bs i8I0YP+olUo7WVqKbu4CYHboDW30YUdqIHHaGisjEEbuUj4SNV/wYEKNqf6UlqYgWim+ Q0cM9nJJu7pdKexTfbCQatUg876Cw7efBPltQQYdevShcnMXaui2ileRi8NPmca4c5Jc X+SYqwiEqIL3evZpEtUSheqejsaAUT8iJThHI5dxA99TEB6m4Rfk5AXWfJsJyYXeOyp0 Zxyy6DX+MV+L2dYNDGZEG1RL2EU88UWhiVuhiseWTdVyjKKD83ZlI2TsicCPAlvDH/k3 PGXg== X-Gm-Message-State: AD7BkJI4MxquClLO1gDK6awQwwJvyaNVnd9NCvlE7Alcf5hxkbrut1+JvWZVxM7OT0kYSwjDF1vUcFQdwGkCcA== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr6545524ioi.108.1458797240166; Wed, 23 Mar 2016 22:27:20 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 23 Mar 2016 22:27:20 -0700 (PDT) In-Reply-To: References: <56F2B2E7.1060809@cs.tcd.ie> Date: Thu, 24 Mar 2016 16:27:20 +1100 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 05:27:22 -0000 On 24 March 2016 at 11:38, Bodo Moeller wrote: > The NPN dependency was a design decision for one implementation, but it's > not common to clients using False Start. For interoperability, you always > have to consider how to deal with what you expect to be deployed *currently* > (and NPN support certainly is one good indicator for False Start tolerance, > if you don't mind tons of false negatives), but I wouldn't see much value in > compiling the minutae of that in this kind of document: it'll go stale > quickly. But I agree with this analysis, the original reason for the test was - if a little iffy - rational. Correlation might not imply causation, but sometimes correlation is all you need. BTW, Firefox still has the option to require that a site advertise NPN (or ALPN) before false starting. It's off by default and hard to find, but it's there. And there are still people who flip that bit. As a feature, it's not one we need to keep. I certainly wouldn't want to bless it by putting it in an RFC, Experimental or otherwise. Let's chalk that up to the ugly things we have to do to get things to work. Which reminds me... From nobody Wed Mar 23 22:30:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67EB12D570 for ; Wed, 23 Mar 2016 22:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnaWQYYiax2F for ; Wed, 23 Mar 2016 22:30:30 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59BAE12D52F for ; Wed, 23 Mar 2016 22:30:30 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id v187so45556160ioe.2 for ; Wed, 23 Mar 2016 22:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=hV/5oKPwMZTHdr1HMlg6dbF9VjBKIoZPZJIga/g+hmU=; b=gC93GNF/F1cP+6J72GrHtFXskhzK0FSJNHF4HRZWvCgjdjGusMM6oDyhseerOvqLAx bOC7BnUi7Vup18nRhcaC995prBIAZmJDfU5Ve5YpXa6aEyeIb7w2o1QkumGaEzsNfpQq MvTC7DXABMv9mWlIs7J/j8e2Hbcn8UEEe/8bqCC7dYSQZnfHKctD41Nyj4IFHzUsxFEz xFn/4kZNTaj94x8p54Yao41GJDSw3QDbiiUOYci9EsdE71Xo1zmZiUeWNrbjNjPfqkW5 17DZT6uI4OUvfuFPSsqRdteIo3YS0JWLM5jwd/dPQxgt1nLpPEjMbwt3MBokgmfhWm+7 jRMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=hV/5oKPwMZTHdr1HMlg6dbF9VjBKIoZPZJIga/g+hmU=; b=OZwNDq4YxEiQUnWiON6vCzO3ScbLyK9fL0IdAEQp/nWdEcDLtDoq78HGHGS250cWFc lvs+Vged09Z81WjchC9Q8WMkUIX7Dom2xWjmYpo6TNoSTpLyubHB/PzyBq97VggJzOmr pzzi6tc0PCdNwKux6rS85f+FZ/r/eipZvy23qAjYvhByWXJyX4PzmkXQUNYiqT6EytrG rKvJ5gQWXgSGdJyseP2MM080Q03CVeO9RCaoe9O0BthIU5y8MBemSy3ls89QLrBGZxVP V6Z/UKhAU3a8A9Kxa8jHQVA3WWdeE44Egb9QjJZo7bjz0R6/lQfrtqk80gyaEUCBYZRr h3IA== X-Gm-Message-State: AD7BkJLu+ZXoEcsUUSH6xDx7FhZktCcUvhNqiALsbQD7h3Tgxyp28oUkI4DlyMHP80MFAsIPfEVC2eHkyowELQ== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr6552591ioi.108.1458797429809; Wed, 23 Mar 2016 22:30:29 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 23 Mar 2016 22:30:29 -0700 (PDT) Date: Thu, 24 Mar 2016 16:30:29 +1100 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Empty extensions don't go last X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 05:30:32 -0000 (This is probably already known to a bunch of people, but it's probably a good idea to put out there.) When deploying EMS, we recently discovered, with the help of our friends at Google (who discovered this long before that) a quirk in some implementations. Short story: Don't place an empty extension at the end of your ClientHello. You will find that a small number of servers choke. From nobody Thu Mar 24 00:04:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F412D609 for ; Thu, 24 Mar 2016 00:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] 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 4i_ImCCbBn-N for ; Thu, 24 Mar 2016 00:04:25 -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 B266C12D146 for ; Thu, 24 Mar 2016 00:04:25 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h129so48551884ywb.1 for ; Thu, 24 Mar 2016 00:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2e3EUxyA2GLVM59Y7QeEbmbMsr9UmxypkL5HI0LSWL4=; b=joh6lkUKhInW3bPQbi5bdODztl+rDHjsfq0qeL/k34KOggC782f8XaljfFim+Il58c tK4Etk07/Z4t7+raoTlvJ9N6Vi6KkSw2gJcZ9RhdJH9HSjboyCA3ThuB4hlzSDDgMwp8 ueS/dG4Fe34uc+CEjHWwjpQRSf7Mp0RAHcTcIAimocnIBg1D98oEpEL+nE8fItEVdi/8 YMqNdHJKJSE54Z47XkAGEweFjmME/ugrnYWwgFulcrIKM6/fEwR01YAEmXJvbuO8wnA7 VvXpSK2GjJIQwdL9wrHldYMdAB+nb7stTfu4hVFmUVXlf8MAqluHDRD0fVvYIqbbVdbm 8XKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2e3EUxyA2GLVM59Y7QeEbmbMsr9UmxypkL5HI0LSWL4=; b=KcffD/FVYnphNNFFGiF+gRPagy8eWxbZdHhPPDEPva6GsqzzXITw5tYF5RZINeTRrI 4CVnpzo+Dcn8tiAPFdUIAtYZv9bxOtLYVrDbk7NFN3SecXgc9KpkQhfpD+pF9ExIPQg2 xVZg2gJykY4YbmUnPN+6hGFg6s/6Y2EXsOftUpFimsoc2SgfBiFe8O/jVSMcUnF8pbx6 Y4GU4bYdiArGpzOoht2/DjmvYfVw6V45OcT0eqiKcwS+duICXfkaOnGTMc3FPMBY/WpB BLd9n+ISZ8JIprCjJ0t4UqloityXbjpjiK1AwvZ7R9E0K4GiNEa8fzk4deGBhdAKIXQE i3OQ== X-Gm-Message-State: AD7BkJJc/ImWjyf8HiejMNUPu2EgIBfCzafnKDWLMdk+8ZgCIvpup4pWKBLspj5BfvOpY0NOvptdkOZg+LGfp7wn MIME-Version: 1.0 X-Received: by 10.13.233.66 with SMTP id s63mr3454942ywe.36.1458803064736; Thu, 24 Mar 2016 00:04:24 -0700 (PDT) Received: by 10.37.113.67 with HTTP; Thu, 24 Mar 2016 00:04:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Mar 2016 00:04:24 -0700 Message-ID: From: Wan-Teh Chang To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Empty extensions don't go last X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 07:04:27 -0000 On Wed, Mar 23, 2016 at 10:30 PM, Martin Thomson wrote: > (This is probably already known to a bunch of people, but it's > probably a good idea to put out there.) > > When deploying EMS, we recently discovered, with the help of our > friends at Google (who discovered this long before that) a quirk in > some implementations. > > Short story: Don't place an empty extension at the end of your > ClientHello. You will find that a small number of servers choke. This interop problem surfaces when we added to Chrome the signed_certificate_timestamp extension for Certificate Transparency (RFC 6962): https://bugs.chromium.org/p/chromium/issues/detail?id=353009#c4 https://bugs.chromium.org/p/chromium/issues/detail?id=363583#c13 https://codereview.chromium.org/240633006 The change that David Benjamin made to ssl3_CalculatePaddingExtensionLength() in his patch probably should also be considered if the padding extension (RFC 7685) is placed at the end: https://codereview.chromium.org/240633006/diff/110001/net/third_party/nss/ssl/ssl3ext.c Wan-Teh Chang From nobody Thu Mar 24 02:56:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77E12D6CE for ; Thu, 24 Mar 2016 02:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 EIQSEM8rZzg4 for ; Thu, 24 Mar 2016 02:56:35 -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 23BBE12D6CD for ; Thu, 24 Mar 2016 02:56:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 24EC9BE33; Thu, 24 Mar 2016 09:56:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYyw0OYb40RE; Thu, 24 Mar 2016 09:56:30 +0000 (GMT) Received: from [10.87.49.100] (unknown [86.46.21.5]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B230FBE2D; Thu, 24 Mar 2016 09:56:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1458813390; bh=/ehXGgxeiZxAvAVQ/jUPtxG6M0J9Fa6Zd5MXL3H/mho=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=cvdZTDNV+EmAWBeSH6G9TMHvcSf7VCNlpF56oLoSINhv+i/YGS/1Fi45fhbWgkRc5 CMr48QtpeYrufEloZpjVeg/oRoLrEJzKz+9sbS4Ym1FN2Je2e7/Lv3gHhBKCCau2tG H4UAZJUridH99elSmAcLE5RG+iZjs1ntPrC8mKLU= To: Bodo Moeller References: <56F2B2E7.1060809@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56F3B9CC.8050305@cs.tcd.ie> Date: Thu, 24 Mar 2016 09:56:28 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070808020205080108070205" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 09:56:38 -0000 This is a cryptographically signed message in MIME format. --------------ms070808020205080108070205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Thanks for the speedy response... Again #3 below is what I care about, the other stuff isn't a big deal. On 24/03/16 00:38, Bodo Moeller wrote: > "Stephen Farrell" : >=20 >> (1) Why experimental? Wouldn't this be better as info >> and documented as "here's a spec for a thing that's >> widely deployed." I fear we may get questions like >> "what's the experiment?", "where's this going in >> future?" if this aims for experimental, and info may >> avoid that esp if we really want people to move to >> TLS1.3. I also didn't see list discussion about what >> kind of RFC to aim for, but maybe it was discussed at >> a meeting or interim? (Apologies if I missed that in >> my scan of the list.) >=20 > I'm myself torn between "Experimental" and "Informational" (certainly n= ot > "Historic" because the spec has not been superseded by a more recent on= e > and is not obsolete for any other reason [ > https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow > manage to complete TLS 1.3 standardization before this). Taking into > account how False Start is actually deployed (and taking into Right. TLS1.3 will hopefully make this historic, so we could just park this in the RFC editor queue and have both RFCs emerge on the same day with this one as Historic. With did that with DKIM (4871) and DomainKeys (4870, Historic) for example. Note that I'm not arguing for doing that, just raising the option if that's what the WG want and if the list hasn't discussed it. I assume though that the WG don't want to take this route so no need to discuss it more in that case. > account that > we expect it to eventually be replaced by a TLS 1.3 mechanism) and how = our > I-D is cited in research papers on TLS, "Experimental" sounds right to = me: > the spec really is part of a research and development effort [ > https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational" > wouldn't be wrong either. I think the latter matches much better myself, as there really is no experiment being done here and we're not gonna develop this any more once TLS1.3 is done, but whatever - I'm ok with saying that the WG just wanted experimental. But you'll likely get asked this again and again. At least we can now point at this thread and say that it was discussed on the list though. (Which was partly why I asked:-) It'd be no harm though if a couple of others chimed in on this just to there's recorded opinion from more than just the AD and an author. We can change to informational at the end of LC if need be, i.e., there's no need to hold stuff up for that and such a change then doesn't add any delay. >=20 >> (2) The write up and some mail list traffic and AGL's >> bloggy thing all refer to NPN, but there's no mention of >> NPN or ALPN in the draft. What's up with that? (Not >> saying that needs to be explained, but I wondered.) >=20 > The NPN dependency was a design decision for one implementation, but it= 's > not common to clients using False Start. For interoperability, you alwa= ys > have to consider how to deal with what you expect to be deployed > *currently* (and NPN support certainly is one good indicator for False > Start tolerance, if you don't mind tons of false negatives), but I woul= dn't > see much value in compiling the minutae of that in this kind of documen= t: > it'll go stale quickly. Fair enough, thanks. (Same to Martin for his follow up.) >=20 >> (3) Why is there no description of the reasons for all >> the MUST only use whitelisted and for the choices >> that are whitelisted? Wouldn't omitting that tend to >> lead people to use this more badly? >=20 > Well, I tried to capture the general reasoning in the spec -- but not t= he > detailed reasons for the specific choices suggested, because that again= > would just go stale quickly. Where are those general reasons stated? I don't see 'em. >=20 > In particular, I think this is an important observation in the I-D: >=20 > "If heuristically a small list of cipher suites and a single protocol > version is found to be sufficient for the majority of TLS handshakes in= > practice, it could make sense to forego False Start for any handshake t= hat > does not match this expected pattern, even if there is no concrete reas= on > to assume a cryptographic weakness." That may be important but it doesn't address the issue about which I'm asking. >=20 > So the whitelists should have algorithms that are actually used in prac= tice > and that don't have critical weaknesses, but why exactly those particul= ar > algorithms happen to get used in practice is mostly out of scope here. Why is the logic behind such security relevant choices out of scope? That makes no sense to me. Let's imagine a new ciphersuite is invented and folks start to wonder whether or not it's ok to whitelist that for false-start - wouldn't they expect this document to explain (maybe mostly via references) why some ciphersuites are not good enough to whitelist? I would expect that to be clear. And to be clear, I'm not asking for an essay, but more like some text in the intro saying "False start is not safe for a ciphersuite that has properties such as because of . See [refs] for full details." For added clarity it'd also be good to have something like: "Ciphersuites MUST have to be safe to whitelist for false-start." If figuring out text for the above is very hard, then I do think that would indicate a real issue with this spec. If figuring that out is just a minor bit of tedium, then I think it's worthwhile so that future readers of the RFC can understand what's going on here, which I don't think is the case from the current text. Cheers, S. >=20 > Bodo >=20 >> That could be done >> with some explanatory text and using some of the >> references below maybe. Or, if we don't really want new >> folks to implement this (do we?) then just saying that >> might mean it's ok to not explain the "why." (And then >> you could also address #1 above then by issuing this >> as an historic RFC too if you wanted.) >=20 --------------ms070808020205080108070205 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjQw OTU2MjhaMC8GCSqGSIb3DQEJBDEiBCBfmX8HG2YZIaLE/bzFy4Jvz2nws8c5nWP4pn/IIlwk hjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCrXRczHxDYDG4fakRyHTT/G/l68yjNigieeOhrdsSko8S9C9YQkoBj eU4HPDJf/uZzhSsym1KNTk0yjYT7xTKtqaxwHcJQlPQRtWYPxN2tJB5ZvSO1bEcUFzr41jnJ 7hOK7ukmEGd5PF2uz3rjFRv5KF6RFge/gi7UQbrgTzct5ypPdUk5eamUe3HImMQv3sm3oN23 Q2+pMllK7ci3yEVSw06GK8AAjSYWERI/F+l5gzXucdxS44ASrH5568TPHIU6B7n8a/0hRyAP 2EI4mbHH+jLzOkOiYatXgmB7u8+jNXOp779BBnBHnWiKLaK6P3V1k9nj2Jh7+Wm23WiSfC7t AAAAAAAA --------------ms070808020205080108070205-- From nobody Thu Mar 24 03:13:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5215C12D6CD for ; Thu, 24 Mar 2016 03:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=azet.sk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnE09vq_ToGN for ; Thu, 24 Mar 2016 03:13:16 -0700 (PDT) Received: from smtp2.azet.sk (smtp-05-out.s.azet.sk [91.235.53.55]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C557512D658 for ; Thu, 24 Mar 2016 03:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=azet.sk; s=azet; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=BGdAJaUDUNa6Auvr9nLST5s0QNdGbRRZCwajQGcgfZg=; b=PBAFrJk8OBqiDxlzu+t1XUfogbCOv3Ycmy7ePVODXprjQXDiZMS9ytcX61hZceltXn3VGYhBjcDDkHaI2kf3mIEiTgO+AbrI5S+NICMCig2X8i6+G6KCX9dlWVXsZTOlnAFmDJ2ncbU1/gMBUhw8yc9VVqywsnPE8nTWU0oI0Tc=; Received: from smtp-02-auth.e.etech.sk ([10.11.2.101] helo=smtp.azet.sk) by smtp2.azet.sk stage1 with esmtp (Exim MailCleaner) id 1aj2GP-0001HH-CT for from ; Thu, 24 Mar 2016 11:13:13 +0100 Received: from 127.0.0.1 (atlantic480.us.unmetered.com [188.138.9.49]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 4D7308B for ; Thu, 24 Mar 2016 11:13:04 +0100 (CET) X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 4D7308B Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk To: tls@ietf.org References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> From: Fedor Brunner Message-ID: <56F3BDAD.1040402@azet.sk> Date: Thu, 24 Mar 2016 11:13:01 +0100 MIME-Version: 1.0 In-Reply-To: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-MailCleaner-DMARC: quarantine Archived-At: Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 10:13:18 -0000 Timothy Jackson: > I’ve noted that many (most?) TLS implementations choose their ECDHE curves seemingly without regard to the cipher suite strength. Thus, they'll select an AES256 cipher suite (e.g. TLS_ECDHE_ECDSA_WITH_AES256_SHA384), but then generate an ECDHE key on the P256 curve. This seems odd to me, since the P256 curve obviously has a lower security strength than AES256. This seems important issue to resolve because most products (and even TLS libraries) do not allow the administrator to configure the available ECDHE curves, only the cipher suites. Thus, ECDHE may be invisibly undermining the security of your TLS connection. > > Is this an intentional choice by this group for some reason that I haven’t realized yet? > > How would this group feel about a proposal to address this by specifying in the 1.3 specification that implementations must ensure that the strength of the certificate must be >= strength of ECDHE/DHE >= strength of the cipher? Perhaps an equivalency rule for the MAC might also be in order? Apologies if this is already resolved somewhere in the draft RFC. I looked but didn’t find it. > > For what it’s worth, I’ve noticed OpenSSL and other implementations trying to address this by creating a “Suite B Mode”, but that seems to address a specific case but leave the generic case unresolved. > > Cheers, > > Tim > > There are good reasons to combine AES256 with ECDHE on the P256 curve. Please read https://blog.cr.yp.to/20151120-batchattacks.html "Bottom line: 128-bit AES keys are not comparable in security to 255-bit elliptic-curve keys. Is 2^255−19 big enough? Yes. Is 128-bit AES safe? Unclear." There is also the paper "Understanding brute force" from Daniel J. Bernstein. https://cr.yp.to/papers.html#bruteforce > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Mar 24 05:23:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83EA512DAC6 for ; Thu, 24 Mar 2016 05:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1Jl1vWVoPny for ; Thu, 24 Mar 2016 05:23:00 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2391C12DABB for ; Thu, 24 Mar 2016 05:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458822179; x=1490358179; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=m5bNNgfDpclEyvk8Ul/UK0W9HuF1HzvdnAXly0vEEKg=; b=gUOKjzrv1o3a7MsUgoZ8O4Ts86JprCjp8aMyAQAPAXJ6e+CpxKPHOYgt 9QdG6I5Zu6qoG9g7FrCPVqS88cc9PVPCdm6P43MgP+mXKqbV0Xv9/3wtq yYyzCUnGsy5IFMMQ3doYfCnFNy2SkbiRy1+urZInnbdyoPOHV3q5uzsJ9 yxC53c24MSyViJiZDuAcLVtlLcUDHzu91hsdE4AL5zA0YMmbM8o6dW6Y2 AhN1OD5zaHcTaWKf8Gbw60motei3PezD+4+kREkqQFDMDqiUIH8GvS0fZ xfmmv3YPBDUFvV5AyvxbiWhWSkwvn6hNJP8k+AZ/ySIgZGcjaFWtR2wYn A==; X-IronPort-AV: E=Sophos;i="5.24,385,1454929200"; d="scan'208";a="76229436" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Mar 2016 01:22:57 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 25 Mar 2016 01:22:57 +1300 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC Thread-Index: AQHRhJxIvdQqc8JxV0CUtKcN/21N7p9mC+QAgAJ6hsI= Date: Thu, 24 Mar 2016 12:22:56 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C2BE69@uxcn10-tdc05.UoA.auckland.ac.nz> References: <97CC494E-FB13-4A6B-8824-80CF2C7A76BF@mobileiron.com>, <13766372.8JDB5lPV2a@pintsize.usersys.redhat.com> In-Reply-To: <13766372.8JDB5lPV2a@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Ensuring consistent strength across certificate, ECDHE, cipher, and MAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 12:23:04 -0000 Hubert Kario writes:=0A= =0A= >In my experience, many (12%) servers simply ignore the list of curves=0A= >advertised by client and use the P-256 curve always.=0A= >=0A= >Some (58%) check if it was advertised and fallback to non-ECDHE if P-256 i= s=0A= >not advertised.=0A= =0A= When I checked, which is a year or two back now, I found similar problems (= I=0A= didn't get hard figures but I had the feeling it was a lot higher than 12%,= =0A= but then I wasn't conducting a rigorous survey). Conversely, I found that = if=0A= you just ploughed ahead with P-256, things usually worked. This is what=0A= motivated the use of P-256 in -LTS, it's the de facto standard curve.=0A= =0A= Peter.=0A= From nobody Thu Mar 24 10:33:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B31D12D6C1 for ; Thu, 24 Mar 2016 10:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 KNkG1zk_6AfB for ; Thu, 24 Mar 2016 10:33:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0121.outbound.protection.outlook.com [207.46.100.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673B112D69A for ; Thu, 24 Mar 2016 10:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/bEgYSgY56suuhyMszVr+R/SRF+HyrlqGQyP5EbRuVQ=; b=ngaiW6AqBaWhN7NuUkwgKl7wqO79m1sbxIENh54f7VLYl5ASbLMVmy+xTfCKIz4bDXlMugQLA0GGjEpfkNrX376iCfITraMqIf/lLBc0Mu46JBaNc3Oer20Ju2/It95+MM+ayCJkNwMLLe89XXhUeb0dmXLs0X6Mjw3OW6xC5CE= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 24 Mar 2016 17:33:29 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Thu, 24 Mar 2016 17:33:29 +0000 From: Andrei Popov To: Wan-Teh Chang , Martin Thomson Thread-Topic: [TLS] Empty extensions don't go last Thread-Index: AQHRhY5NbiqsMo+6OUmS/1R85gL06Z9oK64AgACuj0A= Date: Thu, 24 Mar 2016 17:33:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 8c8ba735-18e7-49fd-6fb6-08d3540a69d6 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:MwTQwxRx2geNiM6j/kUTOEQdCChnTn0NjV/J9hMKczMmYP0hDY/dlo0dLUK8mhg3Lh3JiLq/xW/OW4PgTizDze+M7Fq+dHl7err62AYVFp4kS9FmfMTv3iMbKc3k1spKwOGnjwwhnDMZDWslUgmPzg==; 24:H4hUHSoYEZ84mHXrr1vFDLm5YJc227lacmQwWb2NKbaK/A1nF2IHEX7oZvD3s6sKdxaHgMsW9dXq66miEFgAewV51em12lN57kBigsVpB58= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0891BC3F3D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(5002640100001)(19580405001)(92566002)(122556002)(10090500001)(5004730100002)(5001770100001)(189998001)(10400500002)(11100500001)(10290500002)(586003)(575784001)(19580395003)(86362001)(5005710100001)(33656002)(50986999)(54356999)(76176999)(106116001)(5003600100002)(99286002)(74316001)(2950100001)(2900100001)(1096002)(6116002)(2906002)(87936001)(102836003)(77096005)(4326007)(76576001)(15975445007)(3660700001)(5008740100001)(3280700002)(1220700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2016 17:33:28.9251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Empty extensions don't go last X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 24 Mar 2016 17:33:33 -0000 Yes, we found this a while ago as well, and had to move extensions around. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Wan-Teh Chang Sent: Thursday, March 24, 2016 12:04 AM To: Martin Thomson Cc: tls@ietf.org Subject: Re: [TLS] Empty extensions don't go last On Wed, Mar 23, 2016 at 10:30 PM, Martin Thomson = wrote: > (This is probably already known to a bunch of people, but it's=20 > probably a good idea to put out there.) > > When deploying EMS, we recently discovered, with the help of our=20 > friends at Google (who discovered this long before that) a quirk in=20 > some implementations. > > Short story: Don't place an empty extension at the end of your=20 > ClientHello. You will find that a small number of servers choke. This interop problem surfaces when we added to Chrome the signed_certificat= e_timestamp extension for Certificate Transparency (RFC 6962): https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fbugs.chr= omium.org%2fp%2fchromium%2fissues%2fdetail%3fid%3d353009%23c4&data=3D01%7c0= 1%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f98= 8bf86f141af91ab2d7cd011db47%7c1&sdata=3DYUuVpA6X5QhQZGOS%2bHbs30ooKE%2bW9U0= W4cr6tG%2bbKEo%3d https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fbugs.chr= omium.org%2fp%2fchromium%2fissues%2fdetail%3fid%3d363583%23c13&data=3D01%7c= 01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f9= 88bf86f141af91ab2d7cd011db47%7c1&sdata=3DddplXkVwDs4SMUaRpcdc0TY%2fipYDB8rY= wWeTAsvc0Kc%3d https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fcoderevi= ew.chromium.org%2f240633006&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7= c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sd= ata=3D5bQKBz4Y8R%2fmVKHLzpbnVBOj428W0T3regpgaBkl0MY%3d The change that David Benjamin made to ssl3_CalculatePaddingExtensionLength() in his patch probably should also be= considered if the padding extension (RFC 7685) is placed at the end: https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fcoderevi= ew.chromium.org%2f240633006%2fdiff%2f110001%2fnet%2fthird_party%2fnss%2fssl= %2fssl3ext.c&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7c916a8a6aa2eb4b= 8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DjH5GKij0h= %2boPSy4BaRvePsiN7zx2gycuSYraYDiTS4E%3d Wan-Teh Chang _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7c916a8a6aa2eb4b8fd3e908d353b28e2d%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3DgdOOA8X6H1QMVzL3JLh%2b%2f0YHesyIQKZjjhimdP3%2fYn0%3d From nobody Fri Mar 25 02:12:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16D5512D675 for ; Fri, 25 Mar 2016 02:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NuB6feUKePW for ; Fri, 25 Mar 2016 02:11:57 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C51B12D5DE for ; Fri, 25 Mar 2016 02:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1458897116; x=1490433116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NP3XXRYYLvbpcxkCyPcr1O3ZMCQ69xhsuj/LoiMEwh8=; b=DevR32eSshBvj2/M77MH5D5+cHpDokTrgajfuJLNiynvkgrM3TxITQEu yo9RAiQnJKAlgf+X2FUj62n6mWhQnvpWR01soSGv/k/sf4C93uyThA+XE gvc4aI9McwAfxqv799eo3n1yIJpgzCs64u8pplOGHqqqu4HZ76rZ3kvf8 8p1jc/a7Gb0HRyDS7tJ53RjBvelkLUHxZ7XYGzPM57ruQP+7ulDJl95Ak 5bKSeNbe3xbf7sqOz55VEmokmXsFJ6+6YaQRwYuaUsXOlazBwgz1T0dB+ TZsTs2d3Bkvuv2smSyDfB7J4QDy1GmLdRkGZbNajnGQIvqRkWpA1Vg3B9 w==; X-IronPort-AV: E=Sophos;i="5.24,390,1454929200"; d="scan'208";a="76335863" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Mar 2016 22:11:53 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe3.UoA.auckland.ac.nz ([169.254.143.234]) with mapi id 14.03.0266.001; Fri, 25 Mar 2016 22:11:53 +1300 From: Peter Gutmann To: Hubert Kario Thread-Topic: [TLS] TLS 1.2 Long-term Support Profile draft posted Thread-Index: AdF/gGiJXC2ZI/lER3iVToFYg5p2ev//TwgAgAOYO3D//9JUAIAByROrgAJscYCAAOwz3///SK6AgAIc7FH//zecgACuama8 Date: Fri, 25 Mar 2016 09:11:52 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C2CDCD@uxcn10-tdc05.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <4725393.qBtCaC0ZGN@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4C29525@uxcn10-tdc05.UoA.auckland.ac.nz>, <1516479.oKZilPeJ5Q@pintsize.usersys.redhat.com> In-Reply-To: <1516479.oKZilPeJ5Q@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.2.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 09:12:01 -0000 Hubert Kario writes:=0A= =0A= >I was thinking of something like the following:=0A= >=0A= > The length of verify_data (verify_data_length) in the Finished message= =0A= > MUST be equal to the length of output of the hash function used as the= =0A= > basis of the PRF selected for the ciphersuite. That is, in case of=0A= > SHA-256 based PRF 32 octets MUST be used. This overrides the=0A= > requirement from Section 7.4.9. of RFC 5246 that all ciphersuites=0A= > defined at that time have verify_data_length of 12.=0A= =0A= Thanks, I've added words to that effect to the draft, and also added a few= =0A= other cleanups as well.=0A= =0A= Peter.= From nobody Fri Mar 25 02:29:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAAF12DC02 for ; Fri, 25 Mar 2016 02:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 dPc-4EJjTBE3 for ; Fri, 25 Mar 2016 02:29:09 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74ED912D6AB for ; Fri, 25 Mar 2016 02:29:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,390,1454972400"; d="scan'208";a="170776388" Received: from unknown (HELO [128.93.82.51]) ([128.93.82.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2016 10:29:07 +0100 From: Karthik Bhargavan Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 25 Mar 2016 10:29:06 +0100 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 09:29:12 -0000 We currently allow 0-RTT with Semi-static DH, with PSK resumption, and = with pure PSK. Whether or not we keep all of these, it would be good to clean up the = protocol design=20 so that both the client and server have a uniform way of signaling their = preferences. After implementing and analyzing TLS 1.3, here are a few suggestions for = discussion. 1) Early Data Extension The current early-data extension is too DH-specific. When using PSK, we now have to look at both early_data and pre_shared = extensions. I suggest reusing the same extension for both, with the following = interpretation: struct { select (Role) { case client: opaque id<1..2^16-1>; opaque context<0..255>; CipherSuite cipher_suite; Extension extensions<0..2^16-1>; case server: struct {}; } } EarlyDataIndication; In the semi-static DH case: - id is the configuration id - context is the hash of the ServerConfiguration + Server Certificate + = CertificateRequest In the PSK resumption case: - id is the session ticket - context is a *public* value unique to the derived session. For = example, it could be defined as the session hash of the original = handshake, or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly data = context=E2=80=9D) In the pure PSK case - id is the PSK identifier - context is unique to the PSK and its allowed use. For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Cear= ly data context=E2=80=9D) 2) New Session Ticket The NewSessionTicket message needs to indicate whether the server will = accept 0-RTT, and what ciphersuites it is willing to accept (e.g. pure PSK resumption = vs only PSK-ECDHE). I suggest the following modification to this message: struct { uint32 ticket_lifetime; opaque ticket<0..2^16-1>; CipherSuite cipher_suites<2..2^16-2>; EarlyDataType early_data_type } NewSessionTicket; enum { no_early_data_allowed(0), replayable_early_data_allowed (1), all_early_data_allowed(2), (65535) } EarlyDataType; The interpretation of the early_data_type field is that the server is = either: (a) unwilling to accept 0-RTT (no_early_data_allowed),=20 (b) willing to accept 0-RTT, but it has no replay cache = (replayable_early_data_allowed), (c) willing to accept 0-RTT and has a replay cache that it uses to = prevent replay (all_early_data_allowed) The client=E2=80=99s response to this ticket message should be to store = it in its session along with the =E2=80=9Ccontext=E2=80=9D (session hash or = derived from RMS), the allowed cipher suites, and the early_data_indication. When resuming with this ticket: - the client should not send any 0-RTT data if no_early_data_allowed - the client should only send replayable data if = replayable_early_data_allowed (e.g. GET requests) - the client can send any 0-RTT data if all_early_data_allowed, trusting = the server to do the right thing. A note on replay ---------------------- There has been much discussion on 0-RTT replay and here=E2=80=99s a = quick summary of my understanding. We already knew that an active attacker, or a lossy network, or an = overzealous web browser could and would cause 0-RTT (and even 1-RTT) data to be replayed to the = server. This can already happen in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. The new concerns on the mailing list (and in my TRON talk which was = based on a ProVerif model)=20 are that unlike TLS 1.2: (a) even a passive attacker could replay 0-RTT data, long after the = client has gone away, (b) replaying authenticated 0-RTT data can be more damaging (whether = authenticated with client cert or with a cookie), and (c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT = data which opens up new attack vectors. As a result of these new concerns, I would say that TLS 1.3 should = recommend that all servers SHOULD implement a replay cache, and those that cannot should clearly signal = this to the client, so that the client can adjust its 0-RTT use case and its expectations accordingly. A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D ---------------------------------------------------------- When trying to figure out how to authenticate 0-RTT DH mode in an = earlier draft, we came upon the design of signing the Handshake Context that consists of the ClientHello = + additional information from the previous handshake. This construction prevents 0-RTT authentication from unknown key share = attacks. Even if we eliminate client certificate authentication from 0-RTT, this = notion of =E2=80=9Ccontext" is still useful for two reasons: (a) the application may use TokenBinding or some such protocol to = authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel = binding=E2=80=9D to provide for this case, (b) in PSK resumption mode, since the handshake log does not contain = much information that is specific to the previous connection, it would = be more robust to add an explicit context. If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the = EarlyDataIndication extension, then we can use the hash of the = ClientHello uniformly in all 0-RTT modes for deriving keys, and for deriving a channel binding for = the application. Furthermore, we can safely introduce a PSK_ECDHE mode where the server sends its Certificate and CertificateVerify and = its signature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80= =9D field). Best regards, Karthik From nobody Fri Mar 25 04:53:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4DE912D65F for ; Fri, 25 Mar 2016 04:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 K2lA2fpIcbJq for ; Fri, 25 Mar 2016 04:53:48 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE912D599 for ; Fri, 25 Mar 2016 04:53:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E887B49F4; Fri, 25 Mar 2016 13:53:45 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 1R3qt-P_xjP9; Fri, 25 Mar 2016 13:53:45 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8274B2310; Fri, 25 Mar 2016 13:53:45 +0200 (EET) Date: Fri, 25 Mar 2016 13:53:43 +0200 From: Ilari Liusvaara To: Karthik Bhargavan Message-ID: <20160325115343.GA13213@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 11:53:51 -0000 On Fri, Mar 25, 2016 at 10:29:06AM +0100, Karthik Bhargavan wrote: > We currently allow 0-RTT with Semi-static DH, with PSK resumption, and with pure PSK. > Whether or not we keep all of these, it would be good to clean up the protocol design > so that both the client and server have a uniform way of signaling their preferences. > > After implementing and analyzing TLS 1.3, here are a few suggestions for discussion. > > 1) Early Data Extension > > The current early-data extension is too DH-specific. > When using PSK, we now have to look at both early_data and pre_shared extensions. > I suggest reusing the same extension for both, with the following interpretation: > > struct { > select (Role) { > case client: > opaque id<1..2^16-1>; > opaque context<0..255>; > CipherSuite cipher_suite; > Extension extensions<0..2^16-1>; > > case server: > struct {}; > } > } EarlyDataIndication; You mean combining the 0-RTT aspects of pre_shared_key extension with early_data? Because I don't think this type of structure can present what PSK extension presents (e.g. multiple candidate PSK identities). > In the semi-static DH case: > - id is the configuration id > - context is the hash of the ServerConfiguration + Server Certificate + CertificateRequest This would close the loop between static key and the handshake (this loop being open in previous versions creates some "excitement" (not a good thing)). Also, is this hash also used to bind the configuration, identity and possible certificate request to 0-RTT keys? ServerConfiguration and CertificateRequest are not problematic to reconstruct from small space, but Certificate message can be good bit larger... Ah, later it looks like these could then be dropped form 0-RTT key derivation then... > In the PSK resumption case: > - id is the session ticket > - context is a *public* value unique to the derived session. For example, it could be defined as the session hash of the original handshake, > or it could be derived by the client as HKDF(RMS, “early data context”) The first would break symmetry between resumption and PSK. The second would be symmetric with HKDF(PSK, “early data context”). > In the pure PSK case > - id is the PSK identifier > - context is unique to the PSK and its allowed use. > For example, it can be generated (out-of-band) as HKDF(PSK, “early data context”) Seems reasonable way to generate the context. > 2) New Session Ticket > > The NewSessionTicket message needs to indicate whether the server will accept 0-RTT, > and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs only PSK-ECDHE). > > I suggest the following modification to this message: > struct { > uint32 ticket_lifetime; > opaque ticket<0..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > EarlyDataType early_data_type > } NewSessionTicket; > > enum { > no_early_data_allowed(0), > replayable_early_data_allowed (1), > all_early_data_allowed(2), > (65535) > } EarlyDataType; > > The interpretation of the early_data_type field is that the server is either: > (a) unwilling to accept 0-RTT (no_early_data_allowed), > (b) willing to accept 0-RTT, but it has no replay cache (replayable_early_data_allowed), > (c) willing to accept 0-RTT and has a replay cache that it uses to prevent replay (all_early_data_allowed) (b) vs (c) don't affect the next handshake except if 0-RTT data is sent or not? (I ask, because early_data_type with 0rtt auth does affect next handshake in a way that is not signaled there, making it look horrifying to implement, at least if one wants to enforce strict state machine behaviour). > > A note on authenticating the 0-RTT “context” > ---------------------------------------------------------- > > When trying to figure out how to authenticate 0-RTT DH mode in an > earlier draft, we came upon the design of signing the Handshake > Context that consists of the ClientHello + additional information > from the previous handshake. This construction prevents 0-RTT > authentication from unknown key share attacks. It also looks to protect the _main_ TLS handshake from unknown key share attacks when using 0-RTT DH mode. > Even if we eliminate client certificate authentication from 0-RTT, > this notion of “context" is still useful for two reasons: Also, lacking 0-RTT certificate auth would be useful to deflect the headlines if flaw in scheme is discovered (the flaw would then be blamed on $PROTOCOL, not TLS). :-) More seriously, if I was pick one aspect of current TLS 1.3 implmentability that terrifies me the most, it would be 0-RTT cert. auth, by far. When writing code doing state-machine handshake sequencing on TLS 1.2 and 1.3, by far the source of most expletives is either: 1) Some crazyness TLS 1.2 does with resumption (when session tickets are involved). 2) TLS 1.3 0-RTT cert auth (would really love to rip that code out). > (a) the application may use TokenBinding or some such protocol to > authenticate 0-RTT data, and we need to understand what “channel > binding” to provide for this case, > (b) in PSK resumption mode, since the handshake log does not contain > much information that is specific to the previous connection, it > would be more robust to add an explicit context. > If we accept the definition of “context” in the EarlyDataIndication > extension, then we can use the hash of the ClientHello uniformly in > all 0-RTT modes for deriving keys, and for deriving a channel binding > for the application. Furthermore, we can safely introduce a PSK_ECDHE > mode where the server sends its Certificate and CertificateVerify and > its signature is correctly bound to the PSK (via the “context” field). Yeah. Would solve a lot of problems with the current design. -Ilari From nobody Fri Mar 25 04:59:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351BA12D599 for ; Fri, 25 Mar 2016 04:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 W0MbYd6jClQB for ; Fri, 25 Mar 2016 04:59:20 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732BF12D6BE for ; Fri, 25 Mar 2016 04:59:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,390,1454972400"; d="scan'208,217";a="170804868" Received: from unknown (HELO [128.93.82.51]) ([128.93.82.51]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2016 12:59:17 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F40E1CA0-7EFA-42CE-A643-8BC4A725EA24" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan In-Reply-To: <20160325115343.GA13213@LK-Perkele-V2.elisa-laajakaista.fi> Date: Fri, 25 Mar 2016 12:59:16 +0100 Message-Id: <68AC2856-70B5-4B4C-80E8-B8AD1512199A@inria.fr> References: <20160325115343.GA13213@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 11:59:23 -0000 --Apple-Mail=_F40E1CA0-7EFA-42CE-A643-8BC4A725EA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > You mean combining the 0-RTT aspects of pre_shared_key extension with > early_data? Because I don't think this type of structure can present = what > PSK extension presents (e.g. multiple candidate PSK identities). Good question. For 0-RTT, multiple PSK identities make no sense,=20 because we can only use one of these for the 0-RTT key derivation. Are there cases where the client wants to advertise multiple PSK = identities for 1-RTT? If so, we could retain the pre_shared_key extension = specifically for the 1-RTT PSK case, and disregard it for 0-RTT. Best, Karthik >=20 >> In the semi-static DH case: >> - id is the configuration id >> - context is the hash of the ServerConfiguration + Server Certificate = + CertificateRequest >=20 > This would close the loop between static key and the handshake (this > loop being open in previous versions creates some "excitement" (not a > good thing)). >=20 > Also, is this hash also used to bind the configuration, identity and > possible certificate request to 0-RTT keys? ServerConfiguration and > CertificateRequest are not problematic to reconstruct from small = space, > but Certificate message can be good bit larger... >=20 > Ah, later it looks like these could then be dropped form 0-RTT key > derivation then... >=20 >> In the PSK resumption case: >> - id is the session ticket >> - context is a *public* value unique to the derived session. For = example, it could be defined as the session hash of the original = handshake, >> or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly = data context=E2=80=9D) >=20 > The first would break symmetry between resumption and PSK. The second > would be symmetric with HKDF(PSK, =E2=80=9Cearly data context=E2=80=9D).= >=20 >> In the pure PSK case >> - id is the PSK identifier >> - context is unique to the PSK and its allowed use. >> For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Ce= arly data context=E2=80=9D) >=20 > Seems reasonable way to generate the context. >=20 >> 2) New Session Ticket >>=20 >> The NewSessionTicket message needs to indicate whether the server = will accept 0-RTT, >> and what ciphersuites it is willing to accept (e.g. pure PSK = resumption vs only PSK-ECDHE). >>=20 >> I suggest the following modification to this message: >> struct { >> uint32 ticket_lifetime; >> opaque ticket<0..2^16-1>; >> CipherSuite cipher_suites<2..2^16-2>; >> EarlyDataType early_data_type >> } NewSessionTicket; >>=20 >> enum { >> no_early_data_allowed(0), >> replayable_early_data_allowed (1), >> all_early_data_allowed(2), >> (65535) >> } EarlyDataType; >>=20 >> The interpretation of the early_data_type field is that the server is = either: >> (a) unwilling to accept 0-RTT (no_early_data_allowed),=20 >> (b) willing to accept 0-RTT, but it has no replay cache = (replayable_early_data_allowed), >> (c) willing to accept 0-RTT and has a replay cache that it uses to = prevent replay (all_early_data_allowed) >=20 > (b) vs (c) don't affect the next handshake except if 0-RTT data is = sent > or not? >=20 > (I ask, because early_data_type with 0rtt auth does affect next = handshake > in a way that is not signaled there, making it look horrifying to = implement, > at least if one wants to enforce strict state machine behaviour). >=20 >>=20 >> A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D >> ---------------------------------------------------------- >>=20 >> When trying to figure out how to authenticate 0-RTT DH mode in an >> earlier draft, we came upon the design of signing the Handshake >> Context that consists of the ClientHello + additional information >> from the previous handshake. This construction prevents 0-RTT >> authentication from unknown key share attacks. >=20 > It also looks to protect the _main_ TLS handshake from unknown key = share > attacks when using 0-RTT DH mode. >=20 >> Even if we eliminate client certificate authentication from 0-RTT, >> this notion of =E2=80=9Ccontext" is still useful for two reasons: >=20 > Also, lacking 0-RTT certificate auth would be useful to deflect the > headlines if flaw in scheme is discovered (the flaw would then be > blamed on $PROTOCOL, not TLS). :-) >=20 > More seriously, if I was pick one aspect of current TLS 1.3 > implmentability that terrifies me the most, it would be 0-RTT cert. > auth, by far. >=20 > When writing code doing state-machine handshake sequencing on TLS 1.2 > and 1.3, by far the source of most expletives is either: >=20 > 1) Some crazyness TLS 1.2 does with resumption (when session tickets > are involved). > 2) TLS 1.3 0-RTT cert auth (would really love to rip that code out). >=20 >> (a) the application may use TokenBinding or some such protocol to=20 >> authenticate 0-RTT data, and we need to understand what =E2=80=9Ccha= nnel >> binding=E2=80=9D to provide for this case, >> (b) in PSK resumption mode, since the handshake log does not contain >> much information that is specific to the previous connection, it >> would be more robust to add an explicit context. >=20 >=20 >> If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the = EarlyDataIndication >> extension, then we can use the hash of the ClientHello uniformly in >> all 0-RTT modes for deriving keys, and for deriving a channel binding >> for the application. Furthermore, we can safely introduce a PSK_ECDHE >> mode where the server sends its Certificate and CertificateVerify and >> its signature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2= =80=9D field). >=20 > Yeah. Would solve a lot of problems with the current design. >=20 >=20 > -Ilari --Apple-Mail=_F40E1CA0-7EFA-42CE-A643-8BC4A725EA24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
You mean combining the 0-RTT aspects of = pre_shared_key extension with
early_data? Because I don't think this type of = structure can present what
PSK extension presents (e.g. multiple candidate = PSK identities).

Good = question. For 0-RTT, multiple PSK identities make no = sense, 
because we can only use one of these for the = 0-RTT key derivation.

Are there = cases where the client wants to advertise multiple PSK = identities
for 1-RTT? If so, we could retain the = pre_shared_key extension specifically
for the 1-RTT PSK case, = and disregard it for 0-RTT.

Best,
Karthik


In the semi-static DH = case:
- id is the configuration id
- context = is the hash of the ServerConfiguration + Server Certificate + = CertificateRequest

This would close the loop between static = key and the handshake (this
loop being open in previous versions creates = some "excitement" (not a
good thing)).

Also, is this hash also used to bind the = configuration, identity and
possible certificate request to 0-RTT keys? = ServerConfiguration and
CertificateRequest are not problematic to = reconstruct from small space,
but Certificate message can be good bit = larger...

Ah, later it looks like = these could then be dropped form 0-RTT key
derivation then...

In = the PSK resumption case:
- id is the session ticket
- context is a *public* value unique to the derived session. = For example, it could be defined as the session hash of the original = handshake,
 or it could be derived by the client as = HKDF(RMS, =E2=80=9Cearly data context=E2=80=9D)

The first would break symmetry between = resumption and PSK. The second
would be symmetric with HKDF(PSK, = =E2=80=9Cearly data context=E2=80=9D).

In the = pure PSK case
- id is the PSK identifier
- = context is unique to the PSK and its allowed use.
 For = example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Cearly = data context=E2=80=9D)

Seems reasonable way to = generate the context.

2) New Session Ticket

The NewSessionTicket message needs to indicate = whether the server will accept 0-RTT,
and what = ciphersuites it is willing to accept (e.g. pure PSK resumption vs only = PSK-ECDHE).

I suggest the following = modification to this message:
struct {
        uint32 = ticket_lifetime;
        opaque = ticket<0..2^16-1>;
 CipherSuite = cipher_suites<2..2^16-2>;
 EarlyDataType = early_data_type
     } = NewSessionTicket;

       enum {
=   no_early_data_allowed(0= ),
         replayabl= e_early_data_allowed (1),
         all_early= _data_allowed(2),
         (65535)      } EarlyDataType;

The interpretation of the early_data_type = field is that the server is either:
(a) unwilling to = accept 0-RTT (no_early_data_allowed), 
(b) willing = to accept 0-RTT, but it has no replay cache = (replayable_early_data_allowed),
(c) willing to accept = 0-RTT and has a replay cache that it uses to prevent replay = (all_early_data_allowed)

(b) vs (c) don't affect = the next handshake except if 0-RTT data is sent
or not?

(I ask, because early_data_type with 0rtt = auth does affect next handshake
in a way that is not signaled there, = making it look horrifying to implement,
at least if one wants to enforce strict = state machine behaviour).


A note on = authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D
----------------------------------------------------------

When trying to figure out how to authenticate = 0-RTT DH mode in an
earlier draft, we came upon the design = of signing the Handshake
Context that consists of the = ClientHello + additional information
from the previous = handshake. This construction prevents 0-RTT
authentication = from unknown key share attacks.

It also looks to protect = the _main_ TLS handshake from unknown key share
attacks when using 0-RTT = DH mode.

Even if we eliminate client = certificate authentication from 0-RTT,
this notion of = =E2=80=9Ccontext" is still useful for two reasons:

Also, lacking 0-RTT certificate auth would be = useful to deflect the
headlines if flaw in scheme is discovered (the = flaw would then be
blamed on $PROTOCOL, not TLS). :-)

More seriously, if I was pick one aspect = of current TLS 1.3
implmentability that terrifies me the most, it = would be 0-RTT cert.
auth, by far.

When writing code doing state-machine handshake = sequencing on TLS 1.2
and 1.3, by far the source of most expletives is = either:

1) Some crazyness TLS 1.2 = does with resumption (when session tickets
  are involved).
2) TLS 1.3 0-RTT cert auth = (would really love to rip that code out).

(a) the = application may use TokenBinding or some such protocol to 
   authenticate 0-RTT data, and we need to = understand what =E2=80=9Cchannel
   binding=E2=80=9D to provide for this = case,
(b) in PSK resumption mode, since the handshake log = does not contain
   much information that = is specific to the previous connection, it
   would be more robust to add an explicit = context.


If we accept the definition = of =E2=80=9Ccontext=E2=80=9D in the EarlyDataIndication
extension, then we can use the hash of the ClientHello = uniformly in
all 0-RTT modes for deriving keys, and for = deriving a channel binding
for the application. = Furthermore, we can safely introduce a PSK_ECDHE
mode = where the server sends its Certificate and CertificateVerify and
its signature is correctly bound to the PSK (via the = =E2=80=9Ccontext=E2=80=9D field).

Yeah. Would solve a lot of = problems with the current design.


-Ilari

= --Apple-Mail=_F40E1CA0-7EFA-42CE-A643-8BC4A725EA24-- From nobody Fri Mar 25 08:33:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E12A12DB83 for ; Fri, 25 Mar 2016 08:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9P3ISAMe0wAY for ; Fri, 25 Mar 2016 08:33:21 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 43FF312DB22 for ; Fri, 25 Mar 2016 08:33:21 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id k1so94668661vkb.0 for ; Fri, 25 Mar 2016 08:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=KxDrzIVadfyxXtqme2VuQuHjNFPTOS04uL2sAOBgcHI=; b=UWHuS44fVa4B6IteNsQr0KN6c0p3QFrJw5WTNBFdn/fwGFCKLg6r0JxasZ0GaLgMyt /NRaSnZqyI9s2EduDmXEILcgfCLskXa5FwZTorVWXjWxM1+fCvQPkZmRTBeKcX1BYOZj COrInjR5Hn3fxNKar5MgBapd3pYz+3xwK+bTS8OMV9XBpUUMS6r2gbg+7hcbPxJ/xgO2 uu0uxDCJ8ddkFMjIjQOvq1zZGqDTmDc2wO4yd0Z7vfhgNrNfJZFmz9MyzSOYHlHw7LCh IB1H9xl/NUkvopjZpUJnhErzUa8qGvdVo/M96Qno+9L2cKk7g9Qz5niYqyBmoEtw/Cg5 H8LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=KxDrzIVadfyxXtqme2VuQuHjNFPTOS04uL2sAOBgcHI=; b=TibhP6Nh1utqEJilHHfhlEO64b/i6LHGDEtOV6LoZN53w8pt7/3KqIJxffmcWAI1sK qwWXauGCtTPZaRMkW6e2NPgJ39hatxWt30seLazCPFOdN3BOUrMbnhei39wxJK/weBmL kJR6fFBDcV5whZh4qujSwht5vkgSNvbIoDtC8cD7Os+pI4FMR7cuzlKTzAZgYDKrES/c /++tUbLq98ay/REMM0luaUyvl/6EyaJlwVX5SechlavxCq5sNqbIolhKs2YWIm1xNONW hjAbyJS0GAG/ZuWtjGNXqCI8L34UfMpmVfnPsVzCziPrjYI/Tmf1khAsNlCZM0l5W8pW e+cw== X-Gm-Message-State: AD7BkJIo1xtXsf7F+g3janIYti5YH55sqMjlK47JVzTc5WOswo0RE/fiHr0emApWXsT7KAuS1O76SiDRKGJ6ev6b MIME-Version: 1.0 X-Received: by 10.31.150.215 with SMTP id y206mr7338185vkd.63.1458920000212; Fri, 25 Mar 2016 08:33:20 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Fri, 25 Mar 2016 08:33:20 -0700 (PDT) In-Reply-To: <68AC2856-70B5-4B4C-80E8-B8AD1512199A@inria.fr> References: <20160325115343.GA13213@LK-Perkele-V2.elisa-laajakaista.fi> <68AC2856-70B5-4B4C-80E8-B8AD1512199A@inria.fr> Date: Fri, 25 Mar 2016 08:33:20 -0700 Message-ID: From: Bill Cox To: Karthik Bhargavan Content-Type: multipart/alternative; boundary=001a1140fdd85ea58c052ee14873 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 15:33:23 -0000 --001a1140fdd85ea58c052ee14873 Content-Type: text/plain; charset=UTF-8 Adding 1 byte EarlyDataType seems like a good idea. As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to require that the cipher suite negotiated from the original 1-RTT connection be used? For channel binding, the only mode that seems to work with 0-RTT is when we issue new tickets on each 0-RTT connection to emulate a single session like we have in TLS 1.2, and use a replay cache on the server. The only valid proof-of-possession the server can do with the client before processing application requests is the one done on the 1-RTT connection, so this single proof needs to secure the entire chain of 0-RTT connections. The master resumption secret becomes a bearer token and needs to be protected accordingly. The Export Key Material API also needs to be updated. The simplest implementation where keys are derived from the current ephemeral secrets will cause the exported keys to be different whenever new keys are negotiated. This will probably cause bugs at the application layer. We may need to have an EKM API that depends only on the original PSK, and another one for generating ephemeral EKM material. Bill --001a1140fdd85ea58c052ee14873 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Adding 1 byte EarlyDataType see= ms like a good idea.

As for the CipherSuite, assuming DH-0RTT goes away, would = it be simpler to require that the cipher suite negotiated from the original= 1-RTT connection be used?

For channel binding, the only mode that seems to work = with 0-RTT is when we issue new tickets on each 0-RTT connection to emulate= a single session like we have in TLS 1.2, and use a replay cache on the se= rver.=C2=A0 The only valid proof-of-possession the server can do with the c= lient before processing application requests is the one done on the 1-RTT c= onnection, so this single proof needs to secure the entire chain of 0-RTT c= onnections.=C2=A0 The master resumption secret becomes a bearer token and n= eeds to be protected accordingly.

The Export Key Material API also needs to be up= dated.=C2=A0 The simplest implementation where keys are derived from the cu= rrent ephemeral secrets will cause the exported keys to be different whenev= er new keys are negotiated.=C2=A0 This will probably cause bugs at the appl= ication layer.=C2=A0 We may need to have an EKM API that depends only on th= e original PSK, and another one for generating ephemeral EKM material.
<= /div>

Bill
--001a1140fdd85ea58c052ee14873-- From nobody Fri Mar 25 08:40:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03B7D12DC21 for ; Fri, 25 Mar 2016 08:40:22 -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 Y4BI_EBp66Km for ; Fri, 25 Mar 2016 08:40:20 -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 AFB9C12DC13 for ; Fri, 25 Mar 2016 08:40:19 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id g3so98429537ywa.3 for ; Fri, 25 Mar 2016 08:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KzlArgbngun2uE4szB+wwWrkXjbTKB/e3cbOIoWoRrY=; b=XFzoS41SZPGehvdmWZLLWb46d4ntgWpfPlT4ahQouhuGESYSBzki7Fmzw28JrBGdSx Td9ZJTtYvcsfAu5DfkVnWRU4uzVuLdvr2OX9HBlYvXo6jOkOESDXz4oIzdI6xLU/G5J2 qBEQADIRSoANVV7CHEX44zeEY2eJM7eCCEFL/OFxOBJsO+Gi7BsMeKVrlj1KC/tNc27l CZYhkzcsfZCjwnsSj7UgE6ejfys6QrgbkNd8aCdCYSCE/8K/EuKk5hB7CPuRyEivVE/Z Lzz2b2obPH9MVHelh++YxD+iomQZbDjfge4QI0agYZCLOhqU+nWwLRKmv4EL1QNcrFa+ x76w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KzlArgbngun2uE4szB+wwWrkXjbTKB/e3cbOIoWoRrY=; b=F+LD9tZNq87yhHa7ZMxK+teEnVkVTirS7APo6H7kA+4HZZzDGcU48e+TOCDnHESHft cXnS7SJl4xVAVojqJubq8hW4yZvB5hbiuIJ/lddiG4wu+gVqdmslo8W85zu8RDoa9Zrt VRpN2gTSdunG0e9uiT4eEi+FXi/HTV9VxKYEa1SYegC5YsRf5mlZBDB1A2BDP/KHvgZC MEyJdLx/aHZcMdoKBGqfor7k5Dd+8h9cslIuX1N9CJYRpvgIuYc1DH4Gyh+s+A/pP2bb 2OSKPw19I2/4XpCGdYn5C5WS4AwVnhuq1RIgKqPIemdB27eKlMSHPhfnkaUoUE6HBUMQ pcCw== X-Gm-Message-State: AD7BkJLOH+78lhDdVSxu2gUTubJjlgjSy5FNcX13ujli+PRyW87W2lhd/UTTqoUJymBROZIc87WsCm6JtJrd3A== X-Received: by 10.37.64.6 with SMTP id n6mr6210430yba.162.1458920418923; Fri, 25 Mar 2016 08:40:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 25 Mar 2016 08:39:39 -0700 (PDT) In-Reply-To: References: <20160325115343.GA13213@LK-Perkele-V2.elisa-laajakaista.fi> <68AC2856-70B5-4B4C-80E8-B8AD1512199A@inria.fr> From: Eric Rescorla Date: Fri, 25 Mar 2016 08:39:39 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a11c0086653c6e7052ee1619b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 15:40:22 -0000 --001a11c0086653c6e7052ee1619b Content-Type: text/plain; charset=UTF-8 On Fri, Mar 25, 2016 at 8:33 AM, Bill Cox wrote: > Adding 1 byte EarlyDataType seems like a good idea. > > As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to > require that the cipher suite negotiated from the original 1-RTT connection > be used? > > For channel binding, the only mode that seems to work with 0-RTT is when > we issue new tickets on each 0-RTT connection to emulate a single session > like we have in TLS 1.2, and use a replay cache on the server. The only > valid proof-of-possession the server can do with the client before > processing application requests is the one done on the 1-RTT connection, so > this single proof needs to secure the entire chain of 0-RTT connections. > The master resumption secret becomes a bearer token and needs to be > protected accordingly. > > The Export Key Material API also needs to be updated. The simplest > implementation where keys are derived from the current ephemeral secrets > will cause the exported keys to be different whenever new keys are > negotiated. This will probably cause bugs at the application layer. We > may need to have an EKM API that depends only on the original PSK, and > another one for generating ephemeral EKM material. > PTAL at draft-12 which has a definition of exporters based on the Exporter Secret, which is computed at the end of the handshake. -Ekr > > > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c0086653c6e7052ee1619b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 25, 2016 at 8:33 AM, Bill Cox <waywardgeek@google.com= > wrote:
<= div class=3D"gmail_extra">Adding 1 byte EarlyDataType seems like a good ide= a.

As = for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to req= uire that the cipher suite negotiated from the original 1-RTT connection be= used?

For channel binding, the only mode that seems to work with 0-RTT is when w= e issue new tickets on each 0-RTT connection to emulate a single session li= ke we have in TLS 1.2, and use a replay cache on the server.=C2=A0 The only= valid proof-of-possession the server can do with the client before process= ing application requests is the one done on the 1-RTT connection, so this s= ingle proof needs to secure the entire chain of 0-RTT connections.=C2=A0 Th= e master resumption secret becomes a bearer token and needs to be protected= accordingly.

The Export Key Material API also needs to be updated.=C2=A0 The sim= plest implementation where keys are derived from the current ephemeral secr= ets will cause the exported keys to be different whenever new keys are nego= tiated.=C2=A0 This will probably cause bugs at the application layer.=C2=A0= We may need to have an EKM API that depends only on the original PSK, and = another one for generating ephemeral EKM material.
=

PTAL at draft-12 which has a definition of exporters ba= sed on the Exporter Secret, which is computed at the end of the handshake.<= /div>

-Ekr


=C2= =A0

<= /div>

Bill

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


--001a11c0086653c6e7052ee1619b-- From nobody Fri Mar 25 09:49:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5810212D715 for ; Fri, 25 Mar 2016 09:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 UZ2e82C3Hcjy for ; Fri, 25 Mar 2016 09:49:10 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 794E512D67E for ; Fri, 25 Mar 2016 09:49:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 3719C2DB4; Fri, 25 Mar 2016 18:49:07 +0200 (EET) 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 gmyttMmnZDnd; Fri, 25 Mar 2016 18:49:06 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D77FE2310; Fri, 25 Mar 2016 18:49:06 +0200 (EET) Date: Fri, 25 Mar 2016 18:49:05 +0200 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160325164904.GB13213@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160325115343.GA13213@LK-Perkele-V2.elisa-laajakaista.fi> <68AC2856-70B5-4B4C-80E8-B8AD1512199A@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 16:49:16 -0000 On Fri, Mar 25, 2016 at 08:33:20AM -0700, Bill Cox wrote: > Adding 1 byte EarlyDataType seems like a good idea. > > As for the CipherSuite, assuming DH-0RTT goes away, would it be simpler to > require that the cipher suite negotiated from the original 1-RTT connection > be used? TLS_PSK_* or TLS_ECDHE_PSK_*? Apparently the design currently includes doing ECDHE_PSK_* together with PSK for 0-RTT. And the unified session resumption is pure-PSK. So it would look like there are at least two valid ciphersuites... > For channel binding, the only mode that seems to work with 0-RTT is when we > issue new tickets on each 0-RTT connection to emulate a single session like > we have in TLS 1.2, and use a replay cache on the server. The only valid > proof-of-possession the server can do with the client before processing > application requests is the one done on the 1-RTT connection, so this > single proof needs to secure the entire chain of 0-RTT connections. The > master resumption secret becomes a bearer token and needs to be protected > accordingly. Once the crypto problems with DH-0RTT are fixed, one can use that with similar guarantees, but without sensitive state being kept by the client. > The Export Key Material API also needs to be updated. The simplest > implementation where keys are derived from the current ephemeral secrets > will cause the exported keys to be different whenever new keys are > negotiated. This will probably cause bugs at the application layer. We > may need to have an EKM API that depends only on the original PSK, and > another one for generating ephemeral EKM material. Err... You mean new exporter keys when doing new handshake? If so, that is intended. Or new exporter keys when rolling over keys? IIRC, key rollover only updates traffic keys, not the key used for exporter. And also, at TLS level? What is the "original PSK"? -Ilari From nobody Fri Mar 25 10:06:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB4612D15F for ; Fri, 25 Mar 2016 10:06:27 -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 9z4sHQGgEZKj for ; Fri, 25 Mar 2016 10:06:24 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2525512D122 for ; Fri, 25 Mar 2016 10:06:24 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id s5so33819687qkd.0 for ; Fri, 25 Mar 2016 10:06:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g977soxxDTbI1sWv7xClOuLZUEyYRrCPiZAmrdO92PM=; b=w113crI7hPNqPscME+7TigZYtAXjw398LbSUEZdMHGfPT0jQfQK5RU1Z6uG48HkU3T ZXPG7Wh97sgLrgh5lEP0lB4n9dF9kjs2TikGcwQKS7UZ0xkVgUwr4VY2O83J+sgbWD+S gYzZlI5jEEh6nQycfSDoCgzPrB8pFoYkO46l96nTFY7DioONcg/v9uH94UZvxvYoFm1Z GgXiLJni0QxFKjiERL3HTP6SgxuOtCI5SIb8ij12NJBqfFMieSAMX0jiExVVcgPTsV/U Q1FyUHrGdVgaf2gcELDJqwPGxgKrPAVMD2sbqrBmCSaLgAwL3RU/Qt1wDQYvvsOuDo0w tXfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g977soxxDTbI1sWv7xClOuLZUEyYRrCPiZAmrdO92PM=; b=Sqh2xomm7hLkfRrebA+ZHiNvusUJRMejmhRK9+POAexLd/z4ADpFWsSHOt9OIt+kDc eAA1bF0xeCHSlJ97PeGMGI+NiChbrk/90aJMXy2BEg3c4PClmLC3E9oLjNspMP5DbK5S /ozPRjrXQLQBNidSNaCEbT8c/HWtfJnCHj2sQ5OWXlOqkuXXgkdwFTmwxsGVNMSgF7tW oaK6ZTEFTu71oEAwTJanxOzmrhm3D+8tcIkln56LZV0o6pORjGaz3Ykxvct5ltn0RLWa ta0FZp8Eh3ETatV3lTcwxDw0MYg8FxeyQ1N253UNfZF0+tue5QmAbcV0ttNpd/suRxp4 6DrQ== X-Gm-Message-State: AD7BkJKHXdEJAPpy7p4vqKvptMi6t3BckSd7IelzhhBK0UBgjOH5c2eRU5pwUv/P11Qn8pj80qiFmfov0gD8Jg== X-Received: by 10.37.230.212 with SMTP id d203mr8432339ybh.74.1458925583155; Fri, 25 Mar 2016 10:06:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 25 Mar 2016 10:05:43 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 25 Mar 2016 10:05:43 -0700 Message-ID: To: Karthik Bhargavan Content-Type: multipart/alternative; boundary=94eb2c0a79ca239c38052ee29585 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 17:06:27 -0000 --94eb2c0a79ca239c38052ee29585 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Karthik, Thanks for sending this. Some initial thoughts below. > After implementing and analyzing TLS 1.3, here are a few suggestions for discussion. > > 1) Early Data Extension > > The current early-data extension is too DH-specific. > When using PSK, we now have to look at both early_data and pre_shared extensions. > I suggest reusing the same extension for both, with the following interpretation: > > struct { > select (Role) { > case client: > opaque id<1..2^16-1>; > opaque context<0..255>; > CipherSuite cipher_suite; > Extension extensions<0..2^16-1>; > > case server: > struct {}; > } > } EarlyDataIndication; > > > In the semi-static DH case: > - id is the configuration id > - context is the hash of the ServerConfiguration + Server Certificate + CertificateRequest > > In the PSK resumption case: > - id is the session ticket > - context is a *public* value unique to the derived session. For example, it could be defined as the session hash of the original handshake, > or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly data c= ontext=E2=80=9D) > > In the pure PSK case > - id is the PSK identifier > - context is unique to the PSK and its allowed use. > For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Cea= rly data context=E2=80=9D) There seem to be several ideas here: 1. Dispose of PreSharedKey and only use EarlyDataIndication. 2. Have an explicit context field that is derived in a deterministic fashion. I'm not sure that the first of these is a good idea, for several reasons. 1. While it's not sensible to have 0-RTT data encrypted with multiple PSKs, it's not at all silly for the client to offer multiple PSKs to the server. Note that the current TLS 1.2 PSK extension allows the server to provide a hint on the theory that the client might have more than one PSK. Having separate extensions allows this. 2. It burdens servers and clients which don't want to do 0-RTT (but do want to do PSK-resumption) with 0-RTT machinery. This is a particular concern with the extension version proposed above because it doesn't give the client any way to say "this is just a resumption, I'm not sending any 0-RTT data". This means that servers have to at least implement the 0-RTT skipping algorithm even if they refuse 0-RTT. [You could say that the server had indicated "I won't accept 0-RTT" when it established the ticket, and then act as if the client complied but that produces a really ugly decryption failure rather than a handshake failure]. We'd at least want to restore the EarlyDataType value from previous versions of EarlyDataIndication so that the client could express what it did here. The second idea seems sensible, and I do like the idea of binding the session hash of the previous handshake into PSK-Resumption. One thing that seems unclear would be what the responsibilities of the server are with respect to the context. In the current draft, the client and server both digest it explicitly but it's not signalled, which has the disadvantage that you can't just run the session transcript forward. If the client just provides it to the server, then that seems to have different security properties unless we require the server to verify it. Is that what you have in mind here? I note that the context value here was intended for a different purpose, namely tying the handshake to some external context (for instance, if you have an external anti-replay mechanism). I'm not sure if that's still valuable, but if we wanted to do so, then we'll need a separate field somewhere. Another possible design here would be: struct { opaque psk_identity<0..2^16-1>; opaque context<0..255>; } PreSharedKeyInfo; struct { select (Role) { case client: PreSharedKeyInfo keys<2..2^16-1>; case server: uint16 index; // The selected index } } PreSharedKeyExtension; struct { select (Role) { case client: CipherSuite cipher_suite; select (key_exchange) { case PSK: uint16 index; // PSK index case (EC)DHE opaque configuration_id<1..2^16-1>; opaque server_context<0..255>; // ServerConfiguration + Server Certificate + CertificateRequest } Extension extensions<0..2^16-1>; case server: struct {}; } } EarlyDataIndication; It's not super-elegant to have a switch here in the decode for EarlyDataIndication, but they actually are semantically different, so I'm not sure it's that bad. The idea here would be to design to a different invariant, namely: - The client gets to offer the server a bunch of options for the 1-RTT handshake. The server picks one. - The client offers the server exactly one option for 0-RTT and the server can take it or leave it. This is the way that 0-RTT DHE works now. It does open the door to the server somehow picking a different option for 1-RTT than the client chose for 0-RTT, but this is something we could forbid. > 2) New Session Ticket > > The NewSessionTicket message needs to indicate whether the server will accept 0-RTT, > and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs only PSK-ECDHE). > I suggest the following modification to this message: > struct { > uint32 ticket_lifetime; > opaque ticket<0..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > EarlyDataType early_data_type > } NewSessionTicket; The cipher suites indication seems generally sensible. > enum { > no_early_data_allowed(0), > replayable_early_data_allowed (1), > all_early_data_allowed(2), > (65535) > } EarlyDataType; > > The interpretation of the early_data_type field is that the server is either: > (a) unwilling to accept 0-RTT (no_early_data_allowed), > (b) willing to accept 0-RTT, but it has no replay cache (replayable_early_data_allowed), > (c) willing to accept 0-RTT and has a replay cache that it uses to prevent replay (all_early_data_allowed) This is an interested suggestion. I agree that it's important to be able to say "don't send me 0-RTT data" (see above). ISTM that "all_early_data_allowed" would be useful primarily if we allowed clients who received it to use the ordinary TLS 1.3 API for sending 0-RTT data. That would be a real advantage, it seems to me. > There has been much discussion on 0-RTT replay and here=E2=80=99s a quick= summary of my understanding. > We already knew that an active attacker, or a lossy network, or an overzealous web browser could > and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. This can already happen > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. > > The new concerns on the mailing list (and in my TRON talk which was based on a ProVerif model) > are that unlike TLS 1.2: > (a) even a passive attacker could replay 0-RTT data, long after the client has gone away, Nit: This doesn't sound like a passive attacker to me... > Even if we eliminate client certificate authentication from 0-RTT, this notion of =E2=80=9Ccontext" is still useful for two reasons: > (a) the application may use TokenBinding or some such protocol to authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel bi= nding=E2=80=9D to provide for this case, > (b) in PSK resumption mode, since the handshake log does not contain much information that is specific to the previous connection, it would be more robust to add an explicit context. Yes, I agree that this is an improvement. -Ekr On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > We currently allow 0-RTT with Semi-static DH, with PSK resumption, and > with pure PSK. > Whether or not we keep all of these, it would be good to clean up the > protocol design > so that both the client and server have a uniform way of signaling their > preferences. > > After implementing and analyzing TLS 1.3, here are a few suggestions for > discussion. > > 1) Early Data Extension > > The current early-data extension is too DH-specific. > When using PSK, we now have to look at both early_data and pre_shared > extensions. > I suggest reusing the same extension for both, with the following > interpretation: > > struct { > select (Role) { > case client: > opaque id<1..2^16-1>; > opaque context<0..255>; > CipherSuite cipher_suite; > Extension extensions<0..2^16-1>; > > case server: > struct {}; > } > } EarlyDataIndication; > > > In the semi-static DH case: > - id is the configuration id > - context is the hash of the ServerConfiguration + Server Certificate + > CertificateRequest > > In the PSK resumption case: > - id is the session ticket > - context is a *public* value unique to the derived session. For example, > it could be defined as the session hash of the original handshake, > or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly data c= ontext=E2=80=9D) > > In the pure PSK case > - id is the PSK identifier > - context is unique to the PSK and its allowed use. > For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Cea= rly data > context=E2=80=9D) > > 2) New Session Ticket > > The NewSessionTicket message needs to indicate whether the server will > accept 0-RTT, > and what ciphersuites it is willing to accept (e.g. pure PSK resumption v= s > only PSK-ECDHE). > > I suggest the following modification to this message: > struct { > uint32 ticket_lifetime; > opaque ticket<0..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > EarlyDataType early_data_type > } NewSessionTicket; > > enum { > no_early_data_allowed(0), > replayable_early_data_allowed (1), > all_early_data_allowed(2), > (65535) > } EarlyDataType; > > The interpretation of the early_data_type field is that the server is > either: > (a) unwilling to accept 0-RTT (no_early_data_allowed), > (b) willing to accept 0-RTT, but it has no replay cache > (replayable_early_data_allowed), > (c) willing to accept 0-RTT and has a replay cache that it uses to preven= t > replay (all_early_data_allowed) > > The client=E2=80=99s response to this ticket message should be to store i= t in its > session along with the =E2=80=9Ccontext=E2=80=9D (session hash or derived= from RMS), > the allowed cipher suites, and the early_data_indication. > > When resuming with this ticket: > - the client should not send any 0-RTT data if no_early_data_allowed > - the client should only send replayable data if > replayable_early_data_allowed (e.g. GET requests) > - the client can send any 0-RTT data if all_early_data_allowed, trusting > the server to do the right thing. > > > A note on replay > ---------------------- > > There has been much discussion on 0-RTT replay and here=E2=80=99s a quick= summary > of my understanding. > We already knew that an active attacker, or a lossy network, or an > overzealous web browser could > and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. > This can already happen > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. > > The new concerns on the mailing list (and in my TRON talk which was based > on a ProVerif model) > are that unlike TLS 1.2: > (a) even a passive attacker could replay 0-RTT data, long after the clien= t > has gone away, > (b) replaying authenticated 0-RTT data can be more damaging (whether > authenticated with client cert or with a cookie), and > (c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT > data which opens up new attack vectors. > > As a result of these new concerns, I would say that TLS 1.3 should > recommend that all servers SHOULD > implement a replay cache, and those that cannot should clearly signal thi= s > to the client, so that the client > can adjust its 0-RTT use case and its expectations accordingly. > > A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D > ---------------------------------------------------------- > > When trying to figure out how to authenticate 0-RTT DH mode in an earlier > draft, we came upon the > design of signing the Handshake Context that consists of the ClientHello = + > additional information from the previous handshake. > This construction prevents 0-RTT authentication from unknown key share > attacks. > > Even if we eliminate client certificate authentication from 0-RTT, this > notion of =E2=80=9Ccontext" is still useful for two reasons: > (a) the application may use TokenBinding or some such protocol to > authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel = binding=E2=80=9D > to provide for this case, > (b) in PSK resumption mode, since the handshake log does not contain much > information that is specific to the previous connection, it would be more > robust to add an explicit context. > > If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the EarlyData= Indication > extension, then we can use the hash of the ClientHello uniformly in all > 0-RTT modes for deriving keys, and for deriving a channel binding for the > application. Furthermore, we can safely introduce a PSK_ECDHE > mode where the server sends its Certificate and CertificateVerify and its > signature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80= =9D field). > > Best regards, > Karthik > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a79ca239c38052ee29585 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Karthik,

Thanks for sending = this. Some initial thoughts below.

> After impl= ementing and analyzing TLS 1.3, here are a few suggestions for discussion.<= /div>
>=C2=A0
> 1) Early Data Extension
>= =C2=A0
> The current early-data extension is too DH-specific.<= /div>
> When using PSK, we now have to look at both early_data and p= re_shared extensions.
> I suggest reusing the same extension f= or both, with the following interpretation:
>=C2=A0
= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 select (Role) {
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 case client:
> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque id<1..2^16-1>;
=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 op= aque context<0..255>;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CipherSuite cipher_suite;
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension ex= tensions<0..2^16-1>;
>=C2=A0
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case server:
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {};
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
&= gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 } EarlyDataIndication;
>=C2=A0=
>=C2=A0
> In the semi-static DH case:
= > - id is the configuration id
> - context is the hash of t= he ServerConfiguration + Server Certificate + CertificateRequest
= >=C2=A0
> In the PSK resumption case:
> - id i= s the session ticket
> - context is a *public* value unique to= the derived session. For example, it could be defined as the session hash = of the original handshake,
> =C2=A0 or it could be derived by = the client as HKDF(RMS, =E2=80=9Cearly data context=E2=80=9D)
>= ;=C2=A0
> In the pure PSK case
> - id is the PSK = identifier
> - context is unique to the PSK and its allowed us= e.
> =C2=A0 For example, it can be generated (out-of-band) as = HKDF(PSK, =E2=80=9Cearly data context=E2=80=9D)

Th= ere seem to be several ideas here:

1. Dispose of P= reSharedKey and only use EarlyDataIndication.
2. Have an explicit= context field that is derived in a deterministic fashion.


I'm not sure that the first of these is a good = idea, for several reasons.

1. While it's not s= ensible to have 0-RTT data encrypted with multiple
PSKs, it's= not at all silly for the client to offer multiple PSKs to
the se= rver. Note that the current TLS 1.2 PSK extension allows the
serv= er to provide a hint on the theory that the client might have more
than one PSK. Having separate extensions allows this.

2. It burdens servers and clients which don't want to do 0-RTT (b= ut do
want to do PSK-resumption) with 0-RTT machinery. This is a = particular
concern with the extension version proposed above beca= use it doesn't
give the client any way to say "this is j= ust a resumption, I'm not
sending any 0-RTT data". This = means that servers have to at least
implement the 0-RTT skipping = algorithm even if they refuse 0-RTT. [You
could say that the serv= er had indicated "I won't accept 0-RTT" when it
est= ablished the ticket, and then act as if the client complied but
t= hat produces a really ugly decryption failure rather than a handshake
=
failure]. We'd at least want to restore the EarlyDataType value fr= om
previous versions of EarlyDataIndication so that the client co= uld
express what it did here.


=
The second idea seems sensible, and I do like the idea of binding the<= /div>
session hash of the previous handshake into PSK-Resumption. One t= hing
that seems unclear would be what the responsibilities of the= server
are with respect to the context. In the current draft, th= e client
and server both digest it explicitly but it's not si= gnalled, which
has the disadvantage that you can't just run t= he session transcript
forward. If the client just provides it to = the server, then that
seems to have different security properties= unless we require the
server to verify it. Is that what you have= in mind here?

I note that the context value here = was intended for a different
purpose, namely tying the handshake = to some external context (for
instance, if you have an external a= nti-replay mechanism). I'm not sure
if that's still valua= ble, but if we wanted to do so, then we'll need a
separate fi= eld somewhere.


Another possible des= ign here would be:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 str= uct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque psk_identit= y<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaq= ue context<0..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } PreShared= KeyInfo;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role) {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case client:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pre= SharedKeyInfo keys<2..2^16-1>;

=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case server:
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 index; = =C2=A0// The selected index
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} PreSharedKeyExtension= ;


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (Role= ) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0case c= lient:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0CipherSuite cipher_suite;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0select (key_exchange) {
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 case PSK:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint16 index; =C2=A0 // PSK index=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 case (EC)DHE
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque co= nfiguration_id<1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque server_co= ntext<0..255>; // ServerConfiguration + Server Certificate + Certific= ateRequest
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Extension extensions<0..2^16-1>;
= =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cas= e server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 struct {};
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0} EarlyDataI= ndication;

It's not super-elegant to have a sw= itch here in the decode for
EarlyDataIndication, but they actuall= y are semantically different, so
I'm not sure it's that b= ad. The idea here would be to design to a
different invariant, na= mely:

- The client gets to offer the server a bunc= h of options for the
=C2=A0 1-RTT handshake. The server picks one= .
=C2=A0=C2=A0
- The client offers the server exactly o= ne option for 0-RTT and
=C2=A0 the server can take it or leave it= .

This is the way that 0-RTT DHE works now. It doe= s open the door
to the server somehow picking a different option = for 1-RTT than
the client chose for 0-RTT, but this is something = we could forbid.
=C2=A0=C2=A0

> 2) Ne= w Session Ticket
>=C2=A0
> The NewSessionTicket m= essage needs to indicate whether the server will accept 0-RTT,
&g= t; and what ciphersuites it is willing to accept (e.g. pure PSK resumption = vs only PSK-ECDHE).

> I suggest the following m= odification to this message:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 str= uct {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 ticket_lifeti= me;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque ticket<0..2^= 16-1>;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CipherSuite ciph= er_suites<2..2^16-2>;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0EarlyDataType early_data_type
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= } NewSessionTicket;

The cipher suites indication = seems generally sensible.


> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 enum {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 no_early_data_allowed(0),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 replayable_early_data_allowed (1),
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 all_early_data_allowed(2),
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 (65535)
> =C2=A0 =C2=A0 =C2=A0 =C2=A0} Ea= rlyDataType;
>=C2=A0
> The interpretation of the = early_data_type field is that the server is either:
> (a) unwi= lling to accept 0-RTT (no_early_data_allowed),
> (b) willing t= o accept 0-RTT, but it has no replay cache (replayable_early_data_allowed),=
> (c) willing to accept 0-RTT and has a replay cache that it = uses to prevent replay (all_early_data_allowed)

Th= is is an interested suggestion. I agree that it's important to
be able to say "don't send me 0-RTT data" (see above). ISTM= that
"all_early_data_allowed" would be useful primaril= y if we allowed
clients who received it to use the ordinary TLS 1= .3 API for sending
0-RTT data. That would be a real advantage, it= seems to me.



> T= here has been much discussion on 0-RTT replay and here=E2=80=99s a quick su= mmary of my understanding.
> We already knew that an active at= tacker, or a lossy network, or an overzealous web browser could
&= gt; and would cause 0-RTT (and even 1-RTT) data to be replayed to the serve= r. This can already happen
> in TLS 1.2, in QUIC, and so we ac= cepted it as a given in TLS 1.3.
>=C2=A0
> The ne= w concerns on the mailing list (and in my TRON talk which was based on a Pr= oVerif model)
> are that unlike TLS 1.2:
> (a) ev= en a passive attacker could replay 0-RTT data, long after the client has go= ne away,

Nit: This doesn't sound like a passiv= e attacker to me...


> Even if we= eliminate client certificate authentication from 0-RTT, this notion of =E2= =80=9Ccontext" is still useful for two reasons:
> (a) the= application may use TokenBinding or some such protocol to authenticate 0-R= TT data, and we need to understand what =E2=80=9Cchannel binding=E2=80=9D t= o provide for this case,
> (b) in PSK resumption mode, since t= he handshake log does not contain much information that is specific to the = previous connection, it would be more robust to add an explicit context.

Yes, I agree that this is an improvement.
=
-Ekr

On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bharg= avan <karthikeyan.bhargavan@inria.fr> wrote:
We currently allow 0-RTT with Semi-static D= H, with PSK resumption, and with pure PSK.
Whether or not we keep all of these, it would be good to clean up the proto= col design
so that both the client and server have a uniform way of signaling their pr= eferences.

After implementing and analyzing TLS 1.3, here are a few suggestions for di= scussion.

1) Early Data Extension

The current early-data extension is too DH-specific.
When using PSK, we now have to look at both early_data and pre_shared exten= sions.
I suggest reusing the same extension for both, with the following interpret= ation:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 select (Role) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque id<= ;1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque conte= xt<0..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CipherSuite = cipher_suite;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension ex= tensions<0..2^16-1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {}; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } EarlyDataIndication;


In the semi-static DH case:
- id is the configuration id
- context is the hash of the ServerConfiguration + Server Certificate + Cer= tificateRequest

In the PSK resumption case:
- id is the session ticket
- context is a *public* value unique to the derived session. For example, i= t could be defined as the session hash of the original handshake,
=C2=A0 or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly dat= a context=E2=80=9D)

In the pure PSK case
- id is the PSK identifier
- context is unique to the PSK and its allowed use.
=C2=A0 For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80= =9Cearly data context=E2=80=9D)

2) New Session Ticket

The NewSessionTicket message needs to indicate whether the server will acce= pt 0-RTT,
and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs = only PSK-ECDHE).

I suggest the following modification to this message:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 ticket_lifetime;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque ticket<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CipherSuite cipher_suites<2..2^16-2>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EarlyDataType early_data_type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } NewSessionTicket;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no_early_data_allowed(0),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replayable_early_data_allowed (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 all_early_data_allowed(2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (65535)
=C2=A0 =C2=A0 =C2=A0 =C2=A0} EarlyDataType;

The interpretation of the early_data_type field is that the server is eithe= r:
(a) unwilling to accept 0-RTT (no_early_data_allowed),
(b) willing to accept 0-RTT, but it has no replay cache (replayable_early_d= ata_allowed),
(c) willing to accept 0-RTT and has a replay cache that it uses to prevent = replay (all_early_data_allowed)

The client=E2=80=99s response to this ticket message should be to store it = in its
session along with the =E2=80=9Ccontext=E2=80=9D (session hash or derived f= rom RMS),
the allowed cipher suites, and the early_data_indication.

When resuming with this ticket:
- the client should not send any 0-RTT data if no_early_data_allowed
- the client should only send replayable data if replayable_early_data_allo= wed (e.g. GET requests)
- the client can send any 0-RTT data if all_early_data_allowed, trusting th= e server to do the right thing.


A note on replay
----------------------

There has been much discussion on 0-RTT replay and here=E2=80=99s a quick s= ummary of my understanding.
We already knew that an active attacker, or a lossy network, or an overzeal= ous web browser could
and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. T= his can already happen
in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

The new concerns on the mailing list (and in my TRON talk which was based o= n a ProVerif model)
are that unlike TLS 1.2:
(a) even a passive attacker could replay 0-RTT data, long after the client = has gone away,
(b) replaying authenticated 0-RTT data can be more damaging (whether authen= ticated with client cert or with a cookie), and
(c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT data= which opens up new attack vectors.

As a result of these new concerns, I would say that TLS 1.3 should recommen= d that all servers SHOULD
implement a replay cache, and those that cannot should clearly signal this = to the client, so that the client
can adjust its 0-RTT use case and its expectations accordingly.

A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D
----------------------------------------------------------

When trying to figure out how to authenticate 0-RTT DH mode in an earlier d= raft, we came upon the
design of signing the Handshake Context that consists of the ClientHello + = additional information from the previous handshake.
This construction prevents 0-RTT authentication from unknown key share atta= cks.

Even if we eliminate client certificate authentication from 0-RTT, this not= ion of =E2=80=9Ccontext" is still useful for two reasons:
(a) the application may use TokenBinding or some such protocol to authentic= ate 0-RTT data, and we need to understand what =E2=80=9Cchannel binding=E2= =80=9D to provide for this case,
(b) in PSK resumption mode, since the handshake log does not contain much i= nformation that is specific to the previous connection, it would be more ro= bust to add an explicit context.

If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the EarlyDataIn= dication extension, then we can use the hash of the ClientHello uniformly i= n all
0-RTT modes for deriving keys, and for deriving a channel binding for the a= pplication. Furthermore, we can safely introduce a PSK_ECDHE
mode where the server sends its Certificate and CertificateVerify and its s= ignature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80=9D f= ield).

Best regards,
Karthik





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

--94eb2c0a79ca239c38052ee29585-- From nobody Fri Mar 25 10:17:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1912D114 for ; Fri, 25 Mar 2016 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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, T_RP_MATCHES_RCVD=-0.01] 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 0fMCoo9YMU-m for ; Fri, 25 Mar 2016 10:17:01 -0700 (PDT) Received: from BLU004-OMC3S2.hotmail.com (blu004-omc3s2.hotmail.com [65.55.116.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4676F12D0B9 for ; Fri, 25 Mar 2016 10:17:01 -0700 (PDT) Received: from BLU177-W25 ([65.55.116.73]) by BLU004-OMC3S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 25 Mar 2016 10:16:59 -0700 X-TMN: [Z4GsKZQIiKBC3EXHoB+ylPtxLxPyCcZq] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: "tls@ietf.org" Date: Fri, 25 Mar 2016 10:16:59 -0700 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Mar 2016 17:17:00.0117 (UTC) FILETIME=[2447A850:01D186BA] Archived-At: Subject: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 17:17:03 -0000 I wonder if it would be possible to publish draft-ietf-tls-56-bit-ciphersui= tes as Historic (in the sense of RFC 6101).=0A= It would start with=A0https://tools.ietf.org/html/draft-ietf-tls-56-bit-cip= hersuites-01 =2C but the ciphersuites 0x60 and 0x61 would be added also as = they were implemented in OpenSSL.=0A= =0A= Yuhong Bao = From nobody Fri Mar 25 11:27:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2D112D627 for ; Fri, 25 Mar 2016 11:27:39 -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=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 b1wcxce6pfc1 for ; Fri, 25 Mar 2016 11:27:35 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BE312D622 for ; Fri, 25 Mar 2016 11:27:30 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id p130so36343252qke.1 for ; Fri, 25 Mar 2016 11:27:30 -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:date:message-id:subject:from:to :cc; bh=+RDDqaN2RTLIH7ijwwcHqD/vn9/7of0p1kdqYENbuLU=; b=z1FqNcOiX+xPzm0e7V9Vgpwu7pP99VKLEqvvnkm3dFZhQHT7YvfUK7wi0rjgsGL0CW glpVlZ6jSvKobQw1f52ni9+NqVqz456537tAxGi/cN1/pU0lN36S8WWFgUc4fzLs0DNb CSM9AQzALeIpQMxJIAxHBrdliiCt4JHlDqG6tqvIQraC/c0bnSFDJpkJkOt/7KYydY1D H7jhxSfljFX0eItMQUc4eq67d43fLttmrKFP8L6fQ9apeGJkXoeitycUX8EXHeVhn4PA yoWnAckJ50XAPUTdRQWmT7xAEOHKDwkfSK+7qfk97UkE0NLPcFsxFWpmn6iFwSo/IYXa 98Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+RDDqaN2RTLIH7ijwwcHqD/vn9/7of0p1kdqYENbuLU=; b=Xbg6PfaaQV4IATX2fM026OC2CITggvaPpL+6N0rsrErZtZcmpYSaLWRMtYj32TF3IX I7iQ4hmCVLsDfjxQ41flah7DGxFhOvIAqx+oj68efvKy5SBnPKH+8msspaDTIEwbR4Yi kToDkEGLFU2OwjpbThD3UGSAil2DxIhP0r6Naw4aFDsI0GWsarYD+2h2xMjA0cLv72op UK6dBp4GIXmcsJtiyjLpsdfPYQ77zHW/EGlmZIiKz5fH/aRczm3z6c6AWQvR106Z6VfX wh+C2ImiyunxIw3mEIyHeJghk7bXOupSRlwMyKZGeX0qisn9amaawblwc9gSD3rhbcJu N0Dw== X-Gm-Message-State: AD7BkJJNF3dxWJH+UScACNy5Pa20flRkaxmWBLtkf97LQHmiGXYjYPPCSCE1+Xg9TqmEim87sYADSWn4tx94cA== MIME-Version: 1.0 X-Received: by 10.13.192.5 with SMTP id b5mr8226271ywd.114.1458930449210; Fri, 25 Mar 2016 11:27:29 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Fri, 25 Mar 2016 11:27:29 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Mar 2016 11:27:29 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Karthik Bhargavan Content-Type: multipart/alternative; boundary=001a114e3f982db1ac052ee3b751 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 18:27:40 -0000 --001a114e3f982db1ac052ee3b751 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > There has been much discussion on 0-RTT replay and here=E2=80=99s a quick= summary > of my understanding. > We already knew that an active attacker, or a lossy network, or an > overzealous web browser could > and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. > This can already happen > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. > TLS is used by more than web browsers, so this unfortunately isn't the case. In particular: * There are applications and protocols built on top of TLS that do not retry, because they are not replay safe. It's legitimate to prefer bossiness over duplication, and to rely on TLS for anti-replay at the transport layer. * More commonly; there are many applications and protocols that are tolerant of a small number of retries and even duplicates, but suffer severe harm in the face of a large or unbounded number of duplicates. As a result of these new concerns, I would say that TLS 1.3 should > recommend that all servers SHOULD > implement a replay cache, and those that cannot should clearly signal thi= s > to the client, so that the client > can adjust its 0-RTT use case and its expectations accordingly. > +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server maintains state, and so that any given 0RTT ticket may only be used once (to preserve forward secrecy as much as possible within the constrains of 0RTT). --=20 Colm --001a114e3f982db1ac052ee3b751 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan &l= t;karth= ikeyan.bhargavan@inria.fr> wrote:
There has been much discussion on 0-RTT replay and here=E2=80=99s a = quick summary of my understanding.
We already knew that an active attacker, or a lossy network, or an overzeal= ous web browser could
and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. T= his can already happen
in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

TLS is used by more than web browsers, so this u= nfortunately isn't the case. In particular:

* = There are applications and protocols built on top of TLS that do not retry,= because they are not replay safe. It's legitimate to prefer bossiness = over duplication, and to rely on TLS for anti-replay at the transport layer= .=C2=A0

* More commonly; there are many applicatio= ns and protocols that are tolerant of a small number of retries and even du= plicates, but =C2=A0suffer severe harm in the face of a large or unbounded = number of duplicates.

As= a result of these new concerns, I would say that TLS 1.3 should recommend = that all servers SHOULD
implement a replay cache, and those that cannot should clearly signal this = to the client, so that the client
can adjust its 0-RTT use case and its expectations accordingly.

+1 but I think we can go further here and specify = 0RTT in such a way that it only works when the server maintains state, and = so that any given 0RTT ticket may only be used once (to preserve forward se= crecy as much as possible within the constrains of 0RTT).=C2=A0
=

--
Colm
--001a114e3f982db1ac052ee3b751-- From nobody Fri Mar 25 11:37:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6868112D5AA for ; Fri, 25 Mar 2016 11:37:12 -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 11cNQLORezZA for ; Fri, 25 Mar 2016 11:37:10 -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 A959412D59E for ; Fri, 25 Mar 2016 11:37:10 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id o6so36598650qkc.2 for ; Fri, 25 Mar 2016 11:37:10 -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=5covPaXNQxTre4Dv9idcbjLfk+zgoVN7KFEH6+TKXvk=; b=llKCP5XSL0W5tOH28gAyaMthXwMsTmckR+Dz2MywPU4safTLY8wDJ4AYXeXwBebb72 +Ixe/bp2U0RzNFsR4wNZshppdlKwrqY/TQvx76H+ine+ssThgR13gzfDnicZ6iAhKuvt LrCGN9tWsLuB+zZMBIZrszZz9IaQ7jrEojeD8bYw0Q0QOrX8+aMvWrnTyJ4MOiPvGrxY xI9WhQBSjQnKcoDfBoi6pto8uWEFK9qXqYEET+VQpzhbdVdl9BQDaPXy/gz9hqRYwJqW 35Nc8oCZdwIB+u/kSozeGwXhkYe6/aa0CIK8kqcaqD0V/gHw6toj/X67Q0lwyE1Am+V0 U3QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5covPaXNQxTre4Dv9idcbjLfk+zgoVN7KFEH6+TKXvk=; b=Lf8ZpyIjzPFz4ean2Jg7BDxMZ+/9jGqu8BDnHL+6zkPUvbnDgtzTaa1f5xjBURPKpx LAiHM0vvWqHjA/EnIfZxVmkS5WHPShlCffs08BdqFrWKwjZQ3np2ezTTa2hUHTZebU/v 5IfKLr2qZF+pTsl3wIVVR7Xzetv9Br7bJ8qN2b8FBBTOhhhHeUf2dRJ8Br+cz5x41UhA t6Tadzedpjwh21GkFY0LPqphmfvCKbQwNvGKsK3LLsDjN72yE32mEO9u3wKXWaVtNmfa AoIWBiJMl0acEKQWbqgMI8ZqsBsb/T4bwxcasVIvmvhxbanMHn4h9tXYPzRrEMaqk886 qZSw== X-Gm-Message-State: AD7BkJKYNrMJo5rqi5ZC+np13nRyuUzwKsKB0V3gtcxohBvHX0kTtkYOOsqlMoCI5SG8vonRZxGyl7XMt++78Q== X-Received: by 10.13.218.198 with SMTP id c189mr8974392ywe.165.1458931029818; Fri, 25 Mar 2016 11:37:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 25 Mar 2016 11:36:29 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 25 Mar 2016 11:36:29 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=94eb2c08192ac8f16d052ee3d977 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 18:37:12 -0000 --94eb2c08192ac8f16d052ee3d977 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2016 at 11:27 AM, Colm MacC=C3=A1rthaigh wrote: > > +1 but I think we can go further here and specify 0RTT in such a way that > it only works when the server maintains state, and so that any given 0RTT > ticket may only be used once (to preserve forward secrecy as much as > possible within the constrains of 0RTT). > I'm not enthusiastic about this. This seems like it would rule out a bunch of implementations which don't need that guarantee. -Ekr > > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c08192ac8f16d052ee3d977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 25, 2016 at 11:27 AM, Colm MacC=C3=A1rthaigh <= colm@allcosts.net> wrote:
+1 but I think we can go= further here and specify 0RTT in such a way that it only works when the se= rver maintains state, and so that any given 0RTT ticket may only be used on= ce (to preserve forward secrecy as much as possible within the constrains o= f 0RTT).

I'm no= t enthusiastic about this. This seems like it would rule out a bunch of imp= lementations
which don't need that guarantee.

--94eb2c08192ac8f16d052ee3d977-- From nobody Fri Mar 25 11:38:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CDB12D5AA for ; Fri, 25 Mar 2016 11:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 fFzxbweM6q7g for ; Fri, 25 Mar 2016 11:38:48 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 888A512D59E for ; Fri, 25 Mar 2016 11:38:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,392,1454972400"; d="scan'208,217";a="210260493" Received: from 89-156-8-219.rev.numericable.fr (HELO [192.168.0.51]) ([89.156.8.219]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2016 19:38:45 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_B5E314A5-0F71-472F-B907-09FB7B60E6D6" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan In-Reply-To: Date: Fri, 25 Mar 2016 19:38:44 +0100 Message-Id: <68D617BC-BE11-4972-BF28-40829EE5AA9B@inria.fr> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 18:38:51 -0000 --Apple-Mail=_B5E314A5-0F71-472F-B907-09FB7B60E6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eric, Yes, I now agree with Ilari and you that we should have a separate = pre_shared_key extension in order to signal multiple PSKs. I wonder if we could still share the = structure between PSK and DH though, although that=E2=80=99s mainly an aesthetic choice. > The second idea seems sensible, and I do like the idea of binding the > session hash of the previous handshake into PSK-Resumption. One thing > that seems unclear would be what the responsibilities of the server > are with respect to the context. In the current draft, the client > and server both digest it explicitly but it's not signalled, which > has the disadvantage that you can't just run the session transcript > forward. If the client just provides it to the server, then that > seems to have different security properties unless we require the > server to verify it. Is that what you have in mind here? I suggest that the =E2=80=9Ccontext=E2=80=9D is something that the = client generates and the server must check.=20 When a client receives a DH ServerConfiguration, or a NewSessionTicket, or an out-of-band PSK, it generates and stores the context with the key material. When the server receives the id+context, it always has enough information to be able to check the context after processing the id. (e.g. it decrypts the sessionticket and then verifies the context.) The server must perform this check. > I note that the context value here was intended for a different > purpose, Yeah, sorry for reusing the name, but we were already using Handshake = Context, so perhaps this confusion was already there. Best, Karthik >=20 > It's not super-elegant to have a switch here in the decode for > EarlyDataIndication, but they actually are semantically different, so > I'm not sure it's that bad. The idea here would be to design to a > different invariant, namely: >=20 > - The client gets to offer the server a bunch of options for the > 1-RTT handshake. The server picks one. > =20 > - The client offers the server exactly one option for 0-RTT and > the server can take it or leave it. >=20 > This is the way that 0-RTT DHE works now. It does open the door > to the server somehow picking a different option for 1-RTT than > the client chose for 0-RTT, but this is something we could forbid. > =20 >=20 > > 2) New Session Ticket > >=20 > > The NewSessionTicket message needs to indicate whether the server = will accept 0-RTT, > > and what ciphersuites it is willing to accept (e.g. pure PSK = resumption vs only PSK-ECDHE). >=20 > > I suggest the following modification to this message: > > struct { > > uint32 ticket_lifetime; > > opaque ticket<0..2^16-1>; > > CipherSuite cipher_suites<2..2^16-2>; > > EarlyDataType early_data_type > > } NewSessionTicket; >=20 > The cipher suites indication seems generally sensible. >=20 >=20 > > enum { > > no_early_data_allowed(0), > > replayable_early_data_allowed (1), > > all_early_data_allowed(2), > > (65535) > > } EarlyDataType; > >=20 > > The interpretation of the early_data_type field is that the server = is either: > > (a) unwilling to accept 0-RTT (no_early_data_allowed), > > (b) willing to accept 0-RTT, but it has no replay cache = (replayable_early_data_allowed), > > (c) willing to accept 0-RTT and has a replay cache that it uses to = prevent replay (all_early_data_allowed) >=20 > This is an interested suggestion. I agree that it's important to > be able to say "don't send me 0-RTT data" (see above). ISTM that > "all_early_data_allowed" would be useful primarily if we allowed > clients who received it to use the ordinary TLS 1.3 API for sending > 0-RTT data. That would be a real advantage, it seems to me. >=20 >=20 >=20 > > There has been much discussion on 0-RTT replay and here=E2=80=99s a = quick summary of my understanding. > > We already knew that an active attacker, or a lossy network, or an = overzealous web browser could > > and would cause 0-RTT (and even 1-RTT) data to be replayed to the = server. This can already happen > > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. > >=20 > > The new concerns on the mailing list (and in my TRON talk which was = based on a ProVerif model) > > are that unlike TLS 1.2: > > (a) even a passive attacker could replay 0-RTT data, long after the = client has gone away, >=20 > Nit: This doesn't sound like a passive attacker to me... >=20 >=20 > > Even if we eliminate client certificate authentication from 0-RTT, = this notion of =E2=80=9Ccontext" is still useful for two reasons: > > (a) the application may use TokenBinding or some such protocol to = authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel = binding=E2=80=9D to provide for this case, > > (b) in PSK resumption mode, since the handshake log does not contain = much information that is specific to the previous connection, it would = be more robust to add an explicit context. >=20 > Yes, I agree that this is an improvement. >=20 > -Ekr >=20 >=20 > On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan = > = wrote: > We currently allow 0-RTT with Semi-static DH, with PSK resumption, and = with pure PSK. > Whether or not we keep all of these, it would be good to clean up the = protocol design > so that both the client and server have a uniform way of signaling = their preferences. >=20 > After implementing and analyzing TLS 1.3, here are a few suggestions = for discussion. >=20 > 1) Early Data Extension >=20 > The current early-data extension is too DH-specific. > When using PSK, we now have to look at both early_data and pre_shared = extensions. > I suggest reusing the same extension for both, with the following = interpretation: >=20 > struct { > select (Role) { > case client: > opaque id<1..2^16-1>; > opaque context<0..255>; > CipherSuite cipher_suite; > Extension extensions<0..2^16-1>; >=20 > case server: > struct {}; > } > } EarlyDataIndication; >=20 >=20 > In the semi-static DH case: > - id is the configuration id > - context is the hash of the ServerConfiguration + Server Certificate = + CertificateRequest >=20 > In the PSK resumption case: > - id is the session ticket > - context is a *public* value unique to the derived session. For = example, it could be defined as the session hash of the original = handshake, > or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly = data context=E2=80=9D) >=20 > In the pure PSK case > - id is the PSK identifier > - context is unique to the PSK and its allowed use. > For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Ce= arly data context=E2=80=9D) >=20 > 2) New Session Ticket >=20 > The NewSessionTicket message needs to indicate whether the server will = accept 0-RTT, > and what ciphersuites it is willing to accept (e.g. pure PSK = resumption vs only PSK-ECDHE). >=20 > I suggest the following modification to this message: > struct { > uint32 ticket_lifetime; > opaque ticket<0..2^16-1>; > CipherSuite cipher_suites<2..2^16-2>; > EarlyDataType early_data_type > } NewSessionTicket; >=20 > enum { > no_early_data_allowed(0), > replayable_early_data_allowed (1), > all_early_data_allowed(2), > (65535) > } EarlyDataType; >=20 > The interpretation of the early_data_type field is that the server is = either: > (a) unwilling to accept 0-RTT (no_early_data_allowed), > (b) willing to accept 0-RTT, but it has no replay cache = (replayable_early_data_allowed), > (c) willing to accept 0-RTT and has a replay cache that it uses to = prevent replay (all_early_data_allowed) >=20 > The client=E2=80=99s response to this ticket message should be to = store it in its > session along with the =E2=80=9Ccontext=E2=80=9D (session hash or = derived from RMS), > the allowed cipher suites, and the early_data_indication. >=20 > When resuming with this ticket: > - the client should not send any 0-RTT data if no_early_data_allowed > - the client should only send replayable data if = replayable_early_data_allowed (e.g. GET requests) > - the client can send any 0-RTT data if all_early_data_allowed, = trusting the server to do the right thing. >=20 >=20 > A note on replay > ---------------------- >=20 > There has been much discussion on 0-RTT replay and here=E2=80=99s a = quick summary of my understanding. > We already knew that an active attacker, or a lossy network, or an = overzealous web browser could > and would cause 0-RTT (and even 1-RTT) data to be replayed to the = server. This can already happen > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. >=20 > The new concerns on the mailing list (and in my TRON talk which was = based on a ProVerif model) > are that unlike TLS 1.2: > (a) even a passive attacker could replay 0-RTT data, long after the = client has gone away, > (b) replaying authenticated 0-RTT data can be more damaging (whether = authenticated with client cert or with a cookie), and > (c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT = data which opens up new attack vectors. >=20 > As a result of these new concerns, I would say that TLS 1.3 should = recommend that all servers SHOULD > implement a replay cache, and those that cannot should clearly signal = this to the client, so that the client > can adjust its 0-RTT use case and its expectations accordingly. >=20 > A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D > ---------------------------------------------------------- >=20 > When trying to figure out how to authenticate 0-RTT DH mode in an = earlier draft, we came upon the > design of signing the Handshake Context that consists of the = ClientHello + additional information from the previous handshake. > This construction prevents 0-RTT authentication from unknown key share = attacks. >=20 > Even if we eliminate client certificate authentication from 0-RTT, = this notion of =E2=80=9Ccontext" is still useful for two reasons: > (a) the application may use TokenBinding or some such protocol to = authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel = binding=E2=80=9D to provide for this case, > (b) in PSK resumption mode, since the handshake log does not contain = much information that is specific to the previous connection, it would = be more robust to add an explicit context. >=20 > If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the = EarlyDataIndication extension, then we can use the hash of the = ClientHello uniformly in all > 0-RTT modes for deriving keys, and for deriving a channel binding for = the application. Furthermore, we can safely introduce a PSK_ECDHE > mode where the server sends its Certificate and CertificateVerify and = its signature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80= =9D field). >=20 > Best regards, > Karthik >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_B5E314A5-0F71-472F-B907-09FB7B60E6D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Eric,

Yes, I now agree with Ilari and you = that we should have a separate pre_shared_key extension
in order to signal multiple PSKs. I wonder if we could still = share the structure between
PSK and DH though, = although that=E2=80=99s mainly an aesthetic choice.

The= second idea seems sensible, and I do like the idea of binding = the
session hash of the previous handshake into = PSK-Resumption. One thing
that seems unclear would = be what the responsibilities of the server
are with = respect to the context. In the current draft, the client
and server both digest it explicitly but it's not signalled, = which
has the disadvantage that you can't just run = the session transcript
forward. If the client just = provides it to the server, then that
seems to have = different security properties unless we require the
server to verify it. Is that what you have in mind = here?

I suggest that the =E2=80=9Ccontext=E2=80= =9D is something that the client generates
and the = server must  check. 

When a client receives a DH = ServerConfiguration,
or a NewSessionTicket, or an = out-of-band PSK, it
generates and stores the = context with the key material.

When the server receives the = id+context, it always has
enough information to be = able to check the context
after processing the id. = (e.g. it decrypts the sessionticket
and then = verifies the context.) The server must perform this check.

I note that the = context value here was intended for a different
purpose,

Yeah, sorry for reusing the name, but we were already = using Handshake Context,
so perhaps this confusion = was already there.

Best,
Karthik


It's not = super-elegant to have a switch here in the decode for
EarlyDataIndication, but they actually are semantically = different, so
I'm not sure it's that bad. The idea = here would be to design to a
different invariant, = namely:

- The = client gets to offer the server a bunch of options for the
  1-RTT handshake. The server picks one.
  
- The client offers the = server exactly one option for 0-RTT and
  the = server can take it or leave it.

This is the way that 0-RTT DHE works = now. It does open the door
to the server somehow = picking a different option for 1-RTT than
the = client chose for 0-RTT, but this is something we could forbid.
  

> 2) New Session Ticket
> 
> The NewSessionTicket = message needs to indicate whether the server will accept = 0-RTT,
> and what ciphersuites it is willing to = accept (e.g. pure PSK resumption vs only PSK-ECDHE).

> I suggest the = following modification to this message:
>   =       struct {
>     =      uint32 ticket_lifetime;
> =          opaque = ticket<0..2^16-1>;
>       =    CipherSuite cipher_suites<2..2^16-2>;
>          EarlyDataType = early_data_type
>         } = NewSessionTicket;

The cipher suites indication seems generally = sensible.


>         enum = {
>           = no_early_data_allowed(0),
>       =     replayable_early_data_allowed (1),
>=           all_early_data_allowed(2),
>           (65535)
>        } EarlyDataType;
> 
> The interpretation of = the early_data_type field is that the server is either:
> (a) unwilling to accept 0-RTT = (no_early_data_allowed),
> (b) willing to accept = 0-RTT, but it has no replay cache = (replayable_early_data_allowed),
> (c) willing = to accept 0-RTT and has a replay cache that it uses to prevent replay = (all_early_data_allowed)

This is an interested suggestion. I agree that it's important = to
be able to say "don't send me 0-RTT data" (see = above). ISTM that
"all_early_data_allowed" would be = useful primarily if we allowed
clients who received = it to use the ordinary TLS 1.3 API for sending
0-RTT = data. That would be a real advantage, it seems to me.



> There has been much = discussion on 0-RTT replay and here=E2=80=99s a quick summary of my = understanding.
> We already knew that an active = attacker, or a lossy network, or an overzealous web browser = could
> and would cause 0-RTT (and even 1-RTT) = data to be replayed to the server. This can already happen
> in TLS 1.2, in QUIC, and so we accepted it as a given in = TLS 1.3.
> 
> The = new concerns on the mailing list (and in my TRON talk which was based on = a ProVerif model)
> are that unlike TLS = 1.2:
> (a) even a passive attacker could replay = 0-RTT data, long after the client has gone away,

Nit: This doesn't sound like a passive = attacker to me...


> Even if we = eliminate client certificate authentication from 0-RTT, this notion of = =E2=80=9Ccontext" is still useful for two reasons:
> (a) the application may use TokenBinding or some such = protocol to authenticate 0-RTT data, and we need to understand what = =E2=80=9Cchannel binding=E2=80=9D to provide for this case,
> (b) in PSK resumption mode, since the handshake log does = not contain much information that is specific to the previous = connection, it would be more robust to add an explicit = context.

Yes, = I agree that this is an improvement.

-Ekr


On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan = <karthikeyan.bhargavan@inria.fr> wrote:
We currently allow = 0-RTT with Semi-static DH, with PSK resumption, and with pure PSK.
Whether or not we keep all of these, it would be good to clean up the = protocol design
so that both the client and server have a uniform way of signaling their = preferences.

After implementing and analyzing TLS 1.3, here are a few suggestions for = discussion.

1) Early Data Extension

The current early-data extension is too DH-specific.
When using PSK, we now have to look at both early_data and pre_shared = extensions.
I suggest reusing the same extension for both, with the following = interpretation:

        struct {
          select (Role) {
              case client:
                  opaque = id<1..2^16-1>;
                  opaque = context<0..255>;
                  = CipherSuite cipher_suite;
                  Extension = extensions<0..2^16-1>;

              case server:
                 struct = {};
                }
        } EarlyDataIndication;


In the semi-static DH case:
- id is the configuration id
- context is the hash of the ServerConfiguration + Server Certificate + = CertificateRequest

In the PSK resumption case:
- id is the session ticket
- context is a *public* value unique to the derived session. For = example, it could be defined as the session hash of the original = handshake,
  or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly = data context=E2=80=9D)

In the pure PSK case
- id is the PSK identifier
- context is unique to the PSK and its allowed use.
  For example, it can be generated (out-of-band) as HKDF(PSK, = =E2=80=9Cearly data context=E2=80=9D)

2) New Session Ticket

The NewSessionTicket message needs to indicate whether the server will = accept 0-RTT,
and what ciphersuites it is willing to accept (e.g. pure PSK resumption = vs only PSK-ECDHE).

I suggest the following modification to this message:
        struct {
         uint32 ticket_lifetime;
         opaque ticket<0..2^16-1>;
         CipherSuite = cipher_suites<2..2^16-2>;
         EarlyDataType early_data_type
        } NewSessionTicket;

        enum {
          no_early_data_allowed(0),
          replayable_early_data_allowed (1),
          all_early_data_allowed(2),
          (65535)
       } EarlyDataType;

The interpretation of the early_data_type field is that the server is = either:
(a) unwilling to accept 0-RTT (no_early_data_allowed),
(b) willing to accept 0-RTT, but it has no replay cache = (replayable_early_data_allowed),
(c) willing to accept 0-RTT and has a replay cache that it uses to = prevent replay (all_early_data_allowed)

The client=E2=80=99s response to this ticket message should be to store = it in its
session along with the =E2=80=9Ccontext=E2=80=9D (session hash or = derived from RMS),
the allowed cipher suites, and the early_data_indication.

When resuming with this ticket:
- the client should not send any 0-RTT data if no_early_data_allowed
- the client should only send replayable data if = replayable_early_data_allowed (e.g. GET requests)
- the client can send any 0-RTT data if all_early_data_allowed, trusting = the server to do the right thing.


A note on replay
----------------------

There has been much discussion on 0-RTT replay and here=E2=80=99s a = quick summary of my understanding.
We already knew that an active attacker, or a lossy network, or an = overzealous web browser could
and would cause 0-RTT (and even 1-RTT) data to be replayed to the = server. This can already happen
in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

The new concerns on the mailing list (and in my TRON talk which was = based on a ProVerif model)
are that unlike TLS 1.2:
(a) even a passive attacker could replay 0-RTT data, long after the = client has gone away,
(b) replaying authenticated 0-RTT data can be more damaging (whether = authenticated with client cert or with a cookie), and
(c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT = data which opens up new attack vectors.

As a result of these new concerns, I would say that TLS 1.3 should = recommend that all servers SHOULD
implement a replay cache, and those that cannot should clearly signal = this to the client, so that the client
can adjust its 0-RTT use case and its expectations accordingly.

A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D
----------------------------------------------------------

When trying to figure out how to authenticate 0-RTT DH mode in an = earlier draft, we came upon the
design of signing the Handshake Context that consists of the ClientHello = + additional information from the previous handshake.
This construction prevents 0-RTT authentication from unknown key share = attacks.

Even if we eliminate client certificate authentication from 0-RTT, this = notion of =E2=80=9Ccontext" is still useful for two reasons:
(a) the application may use TokenBinding or some such protocol to = authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel = binding=E2=80=9D to provide for this case,
(b) in PSK resumption mode, since the handshake log does not contain = much information that is specific to the previous connection, it would = be more robust to add an explicit context.

If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the = EarlyDataIndication extension, then we can use the hash of the = ClientHello uniformly in all
0-RTT modes for deriving keys, and for deriving a channel binding for = the application. Furthermore, we can safely introduce a PSK_ECDHE
mode where the server sends its Certificate and CertificateVerify and = its signature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80= =9D field).

Best regards,
Karthik





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


= --Apple-Mail=_B5E314A5-0F71-472F-B907-09FB7B60E6D6-- From nobody Fri Mar 25 12:02:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B973012D15B for ; Fri, 25 Mar 2016 12:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 ViFM33BytqPT for ; Fri, 25 Mar 2016 12:02:25 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9128F12D18B for ; Fri, 25 Mar 2016 12:02:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.24,392,1454972400"; d="scan'208";a="170873518" Received: from 89-156-8-219.rev.numericable.fr (HELO [192.168.0.51]) ([89.156.8.219]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Mar 2016 20:02:22 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthik Bhargavan In-Reply-To: Date: Fri, 25 Mar 2016 20:02:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B85487A-850B-4347-80A7-A3A4D92593E6@inria.fr> References: To: =?utf-8?Q?Colm_MacC=C3=A1rthaigh?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:02:26 -0000 > +1 but I think we can go further here and specify 0RTT in such a way = that it only works when the server maintains state, and so that any = given 0RTT ticket may only be used once (to preserve forward secrecy as = much as possible within the constrains of 0RTT).=20 Do you envision clients only having one resumption handshake at a time? = I was under the impression that TLS 1.2 clients typically open multiple resumption handshakes in parallel, and that TLS 1.3 clients would want = to do the same. >=20 > --=20 > Colm From nobody Fri Mar 25 12:07:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC112D622 for ; Fri, 25 Mar 2016 12:07:08 -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 kXHgF4zco9QN for ; Fri, 25 Mar 2016 12:07:07 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1286D12D664 for ; Fri, 25 Mar 2016 12:07:07 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p65so32025937wmp.0 for ; Fri, 25 Mar 2016 12:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VbRWYrSitjNh6DSxZnz5MHc9T9xsfvqxF/BlkdXWNvc=; b=wGqi8ypZMEcG+BWo3XMEVTPOjiLT9Z2WTS5GlSeg/tFhRMglvLYTCZ6NVmv5ZrXJto v+wjBKO5gWfVoq5K2kR9YzI4KkoTzHxK6Z3+axzkWfTv5X9s6z7frsyBg+dTuf6RZEVm 5ZsyOwSeeExK2uUyuvgnlbFSsSvFFRJSKOdsgYPt5+V/DhzxoMiV1ciXkUiTvnehnd+r 8rYU0vLsB3yKrAOb0s4jWsluudYA0LSbYdSdtsLTghEqJnCFa30uAV7FCaaPJBb6NsXB AjynqmpnT6z3nv0qTqQzdqElh+ai5/pjBUf1aLi1pl0uOd2xPCFvaO/e+OWQqJ5DWTcn VevA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VbRWYrSitjNh6DSxZnz5MHc9T9xsfvqxF/BlkdXWNvc=; b=PY9RJk3/XgPRQU960aHHjPQy4DQ+K5L4E1FShdhMdVfKeNkaJCkkJYQuYmJ5QHXMCn 0iEzDwq2IJ5XMgfF49nh5F1SZgEEy0FW1a8n7KJ8nPpav3ky77YSI/HrCS0c2pUPYGTZ h5jh47oyHcRPEvCLF3JgiGYmMH/YgovgDGidJ7iCbyOXeXo5TfoQB5+ytueaIwnPhFMS yehcHwPD4ooGRGZvsG6VqkRge/O27Raz/VTSQQTnURmMIW4F8W7zinkq/UQXuDSjmcCO K01oaOvlF4TfZGlQpkNGyzj9vEMN5OtGosQG5LtqcQZeDTnSx5tYd3CN1xYVzpJU0kdA wvlg== X-Gm-Message-State: AD7BkJKn5Ois1kVXR7dbod+5PNSSmwoJwkggPk5eK+gBl95SHb8q/c10W+47kU5/gvcngg== X-Received: by 10.28.52.72 with SMTP id b69mr63350wma.35.1458932825521; Fri, 25 Mar 2016 12:07:05 -0700 (PDT) Received: from [192.168.1.13] (bzq-84-109-9-199.red.bezeqint.net. [84.109.9.199]) by smtp.gmail.com with ESMTPSA id 188sm98508wmk.6.2016.03.25.12.07.04 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Mar 2016 12:07:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Fri, 25 Mar 2016 22:07:02 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <14986FB4-9764-4A6A-B5E2-21DD15FB402A@gmail.com> References: To: Yuhong Bao X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:07:09 -0000 > On 25 Mar 2016, at 8:16 PM, Yuhong Bao = wrote: >=20 > I wonder if it would be possible to publish = draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC = 6101). > It would start with = https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 , but = the ciphersuites 0x60 and 0x61 would be added also as they were = implemented in OpenSSL. >=20 > Yuhong Bao =20 Hi It would be possible but I=E2=80=99m wondering some things: 1. Are the original authors interested, or are there alternative authors = willing to take this on? 2. What is the point? All of the ciphersuites in there have been = deprecated by some diediedie document or another, and no sane document = author (here or elsewhere) would include any of these 56-bit ciphers in = any profile for TLS that is intended to provide security. So what is the = benefit? Yoav From nobody Fri Mar 25 12:10:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D1A12D668 for ; Fri, 25 Mar 2016 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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, T_RP_MATCHES_RCVD=-0.01] 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 TVt9jt8Aky2M for ; Fri, 25 Mar 2016 12:10:31 -0700 (PDT) Received: from BLU004-OMC1S24.hotmail.com (blu004-omc1s24.hotmail.com [65.55.116.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF1612D664 for ; Fri, 25 Mar 2016 12:10:31 -0700 (PDT) Received: from BLU177-W40 ([65.55.116.8]) by BLU004-OMC1S24.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 25 Mar 2016 12:10:30 -0700 X-TMN: [T3b4blT4hTkpOOf428rb19jRmxjEUMEU] X-Originating-Email: [yuhongbao_386@hotmail.com] Message-ID: From: Yuhong Bao To: Yoav Nir Date: Fri, 25 Mar 2016 12:10:29 -0700 Importance: Normal In-Reply-To: <14986FB4-9764-4A6A-B5E2-21DD15FB402A@gmail.com> References: , <14986FB4-9764-4A6A-B5E2-21DD15FB402A@gmail.com> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 25 Mar 2016 19:10:30.0455 (UTC) FILETIME=[FF8EC470:01D186C9] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:10:33 -0000 >=0A= > Hi=0A= >=0A= > It would be possible but I=92m wondering some things:=0A= >=0A= > 1. Are the original authors interested=2C or are there alternative author= s willing to take this on?=0A= >=0A= > 2. What is the point? All of the ciphersuites in there have been deprecat= ed by some diediedie document or another=2C and no sane document author (he= re or elsewhere) would include any of these 56-bit ciphers in any profile f= or TLS that is intended to provide security. So what is the benefit?=0A= =0A= That is why I called them "historic". = From nobody Fri Mar 25 12:23:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B6212D0C1 for ; Fri, 25 Mar 2016 12:23:12 -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=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 7yhM7wfdEoeR for ; Fri, 25 Mar 2016 12:23:11 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E27E812D0FC for ; Fri, 25 Mar 2016 12:23:10 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id s5so37924186qkd.0 for ; Fri, 25 Mar 2016 12:23:10 -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:date:message-id:subject:from:to :cc; bh=j8aTAiHQ3Tvf97M6+dAZHwWQmkaGrxpGZET/kNNNzhs=; b=U1C9UOiHEowQ/f5/O5fsJpL7VtMoWHF9X6bq4dkXR5NhheLS5CQ2eZtEbcnKb8Npmk 52BmqvBzNKf3asauv9eBbDY3rg8IxJg8FGDnKWDgKYWPrBNBGvovjZ1Fpqu/6Q1YMpXX ZkwVwAcma38cslsUUGtpadPJBHbC4UaqDB/8HWdpXF2wBhMOVUQghG9cfnu91MrzSIWb k5PEH+WNM9aC3OZUfZZ4tQO5d4t8MS7VvrA+lXx88nKrOaXYPCPMk7iyPN4sEJ51bTJa YeW9RGJqnyJDi/jqv4M/AAa66DVruQdeGRoQi72EjoftPYp/6Y8X2euiwth74BlHDMXf +7Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=j8aTAiHQ3Tvf97M6+dAZHwWQmkaGrxpGZET/kNNNzhs=; b=F/RzUULF/d0c4fnrOE7NncSR0hYo2TA2vy44VzasbHX48Z7e8ylwGxQxkvFrTDFfVe 7J62NqL4n97+YnhB9JEmamC2E0mRwwEWvr3Z4OcO/t6d5J0Sy+aEFPcSBtcTO5huwctH Twvdu4KLC7Reb+6KIXvm7AH6+LBF5vm056FLeKI3MDtl7cB4hNfYfJabqOlz7t2v2hZx P+ieQSOz99HgGINmvsNvEnq56Da6sAA7aGQkkr23Q3uTZRLxRabm7lQYw8qSttFo98eF MVeaHn86TBhzyEnF2Khc15TmRz3eG0cJdp0JY7vdL5Ws/FN5TFWitNGP7UkcR2oEr2u5 6G+w== X-Gm-Message-State: AD7BkJJYYBZ+7xwPqwPheqklkLLRKeX7cJlESYoYS1uUqbH2yHzidFBFqqUW4Agz/NpBUWalng9thFqPjme9JA== MIME-Version: 1.0 X-Received: by 10.129.155.81 with SMTP id s78mr7968438ywg.24.1458933790020; Fri, 25 Mar 2016 12:23:10 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Fri, 25 Mar 2016 12:23:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Mar 2016 12:23:09 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c0b8e7c4e4c02052ee47ec3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:23:13 -0000 --94eb2c0b8e7c4e4c02052ee47ec3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla wrote: > On Fri, Mar 25, 2016 at 11:27 AM, Colm MacC=C3=A1rthaigh > wrote: >> >> +1 but I think we can go further here and specify 0RTT in such a way tha= t >> it only works when the server maintains state, and so that any given 0RT= T >> ticket may only be used once (to preserve forward secrecy as much as >> possible within the constrains of 0RTT). >> > > I'm not enthusiastic about this. This seems like it would rule out a bunc= h > of implementations > which don't need that guarantee. > With 0RTT, it doesn't seem to be possible to have anti-replay of the message itself without some kind of server state. It's also beneficial for cryptographic safety to prevent at-will re-use of the ticket - other-wise the data is subject to the kind of "try and iterate" attacks we've seen be very successful against DTLS because of its tolerance for duplicate and out of order messages. If server state is required, some more good can come of it by improving the forward secrecy of the 0RTT data to match that of regular data; which I think is most important of all. An implementation would have to be willing to sacrifice replay protection, some cryptographic safety and forward secrecy for the 0RTT data. I'm sure there are implementations that would sacrifice these things to get lower latency more cheaply, but should they be encouraged? I'll admit that this is an unfair simplification in this case since it's a more grey area, but "fast, secure, cheap: pick two" is at play here, and many would pick "fast, cheap". --=20 Colm --94eb2c0b8e7c4e4c02052ee47ec3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla <ekr@rtfm.com= > wrote:
On Fri, Mar 25, 2016 at 11= :27 AM, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
+1 but I think we can go further here and spec= ify 0RTT in such a way that it only works when the server maintains state, = and so that any given 0RTT ticket may only be used once (to preserve forwar= d secrecy as much as possible within the constrains of 0RTT).

I'm not enthusiastic = about this. This seems like it would rule out a bunch of implementations
which don't need that guarantee.
=C2=A0
With 0RTT, it doesn't seem to be possible t= o have anti-replay of the message itself without some kind of server state.= It's also beneficial for cryptographic safety to prevent at-will re-us= e of the ticket - other-wise the data is subject to the kind of "try a= nd iterate" attacks we've seen be very successful against DTLS bec= ause of its tolerance for duplicate and out of order messages. If server st= ate is required, some more good can come of it by improving the forward sec= recy of the 0RTT data to match that of regular data; which I think is most = important of all. =C2=A0

An implementation would h= ave to be willing to sacrifice replay protection, some cryptographic safety= and forward secrecy for the 0RTT data. I'm sure there are implementati= ons that would sacrifice these things to get lower latency more cheaply, bu= t should they be encouraged?=C2=A0 I'll admit that this is an unfair si= mplification in this case since it's a more grey area, but "fast, = secure, cheap: pick two" is at play here, and many would pick "fa= st, cheap". =C2=A0


--
Colm
--94eb2c0b8e7c4e4c02052ee47ec3-- From nobody Fri Mar 25 12:24:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5AE12D12E for ; Fri, 25 Mar 2016 12:24:14 -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 yZ3OFwfjKzC0 for ; Fri, 25 Mar 2016 12:24:11 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FE5312D676 for ; Fri, 25 Mar 2016 12:24:08 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id p130so37982194qke.1 for ; Fri, 25 Mar 2016 12:24:08 -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=Ij2EE9Yn78z+fVHvqDMg7IttuFRXNArXwzTgaJWuLIk=; b=XLXUtjNi8tx6i6ggZa9xrtNh8qXVaKhX13iVth8u9Hb4EvPUbtxki8kU1Rgn+RZG6s 17orkJmX1lvIxofLssJwLbOaFixftwmudvQ4a08k2NQCEqG2Twg5HhpsEigNCvQVyNvF IAtPE1dlnwl9gOUbYZ86TrHW47p8NanxfYjO2fo5xtBRQ9FnpccHh4AGC7hfrNKvxp4v vMANP7tq4vgc8mKbX4v7fSIR8dUfXT9f3QRJZrdNFJU+F++KfQ0TvLGnNwGlOcW4Ya+P nWG867R1x2h0iYL1nOVkyvQBABe5x9GqSFEMETIIOXEnMtNGemHbsgOzkZeGpLy1c3Gh ms0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ij2EE9Yn78z+fVHvqDMg7IttuFRXNArXwzTgaJWuLIk=; b=hEFG0CyDpnp5CO/aW9Obnpr9HWLG805ycpVtGcNUH3bIGWIwZeiqUckkIu1risToUj NtOFqTUAd7XphmUabSBnu1M/CiEtvwGU99BCtW2If4AFkYGqPR/Wxqh6Yr0smvsI4RmM 9QlPtJPJzaJo/aOicu2C81FK3ajMXOf4tqK0oglf0XUtGLZLRj9lf9lkiimOakPApxNY J3bAV4/0suwaMRvl4Zd0QdPHhqXEzXmvwN9RXtws0Gecg+PuQJSHd47+4PgruRD9WvBF A+wC7IpAlA2EXVZ3K+PnoZkbSDirfy37dinQtUvdWiqOEOI7uZiIv7BFv7c1My+f2U8X CDEA== X-Gm-Message-State: AD7BkJIsq7IaNzE6NxIl4EjKs35WWH+8xtQ4UtiXtBsEbA+4qG071XbGZALewgsH+P8JBawSmZf/g5v/Y8gFfQ== X-Received: by 10.37.231.78 with SMTP id e75mr1590807ybh.146.1458933848057; Fri, 25 Mar 2016 12:24:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 25 Mar 2016 12:23:28 -0700 (PDT) In-Reply-To: <68D617BC-BE11-4972-BF28-40829EE5AA9B@inria.fr> References: <68D617BC-BE11-4972-BF28-40829EE5AA9B@inria.fr> From: Eric Rescorla Date: Fri, 25 Mar 2016 12:23:28 -0700 Message-ID: To: Karthik Bhargavan Content-Type: multipart/alternative; boundary=94eb2c0b11dec3ed84052ee481e9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:24:14 -0000 --94eb2c0b11dec3ed84052ee481e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2016 at 11:38 AM, Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > Hi Eric, > > Yes, I now agree with Ilari and you that we should have a separate > pre_shared_key extension > in order to signal multiple PSKs. I wonder if we could still share the > structure between > PSK and DH though, although that=E2=80=99s mainly an aesthetic choice. > Yes. I'm not wholly satisfied with what I posted here :) > > The second idea seems sensible, and I do like the idea of binding the > session hash of the previous handshake into PSK-Resumption. One thing > that seems unclear would be what the responsibilities of the server > are with respect to the context. In the current draft, the client > and server both digest it explicitly but it's not signalled, which > has the disadvantage that you can't just run the session transcript > forward. If the client just provides it to the server, then that > seems to have different security properties unless we require the > server to verify it. Is that what you have in mind here? > > > I suggest that the =E2=80=9Ccontext=E2=80=9D is something that the client= generates > and the server must check. > > When a client receives a DH ServerConfiguration, > or a NewSessionTicket, or an out-of-band PSK, it > generates and stores the context with the key material. > > When the server receives the id+context, it always has > enough information to be able to check the context > after processing the id. (e.g. it decrypts the sessionticket > and then verifies the context.) The server must perform this check. > This is what I assumed. We would need to document that. I note that the context value here was intended for a different > purpose, > > > Yeah, sorry for reusing the name, but we were already using Handshake > Context, > so perhaps this confusion was already there. > I agree it was already confusing. I just wanted to note it for posterity -Ekr > Best, > Karthik > > > It's not super-elegant to have a switch here in the decode for > EarlyDataIndication, but they actually are semantically different, so > I'm not sure it's that bad. The idea here would be to design to a > different invariant, namely: > > - The client gets to offer the server a bunch of options for the > 1-RTT handshake. The server picks one. > > - The client offers the server exactly one option for 0-RTT and > the server can take it or leave it. > > This is the way that 0-RTT DHE works now. It does open the door > to the server somehow picking a different option for 1-RTT than > the client chose for 0-RTT, but this is something we could forbid. > > > > 2) New Session Ticket > > > > The NewSessionTicket message needs to indicate whether the server will > accept 0-RTT, > > and what ciphersuites it is willing to accept (e.g. pure PSK resumption > vs only PSK-ECDHE). > > > I suggest the following modification to this message: > > struct { > > uint32 ticket_lifetime; > > opaque ticket<0..2^16-1>; > > CipherSuite cipher_suites<2..2^16-2>; > > EarlyDataType early_data_type > > } NewSessionTicket; > > The cipher suites indication seems generally sensible. > > > > enum { > > no_early_data_allowed(0), > > replayable_early_data_allowed (1), > > all_early_data_allowed(2), > > (65535) > > } EarlyDataType; > > > > The interpretation of the early_data_type field is that the server is > either: > > (a) unwilling to accept 0-RTT (no_early_data_allowed), > > (b) willing to accept 0-RTT, but it has no replay cache > (replayable_early_data_allowed), > > (c) willing to accept 0-RTT and has a replay cache that it uses to > prevent replay (all_early_data_allowed) > > This is an interested suggestion. I agree that it's important to > be able to say "don't send me 0-RTT data" (see above). ISTM that > "all_early_data_allowed" would be useful primarily if we allowed > clients who received it to use the ordinary TLS 1.3 API for sending > 0-RTT data. That would be a real advantage, it seems to me. > > > > > There has been much discussion on 0-RTT replay and here=E2=80=99s a qui= ck > summary of my understanding. > > We already knew that an active attacker, or a lossy network, or an > overzealous web browser could > > and would cause 0-RTT (and even 1-RTT) data to be replayed to the > server. This can already happen > > in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. > > > > The new concerns on the mailing list (and in my TRON talk which was > based on a ProVerif model) > > are that unlike TLS 1.2: > > (a) even a passive attacker could replay 0-RTT data, long after the > client has gone away, > > Nit: This doesn't sound like a passive attacker to me... > > > > Even if we eliminate client certificate authentication from 0-RTT, this > notion of =E2=80=9Ccontext" is still useful for two reasons: > > (a) the application may use TokenBinding or some such protocol to > authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel = binding=E2=80=9D > to provide for this case, > > (b) in PSK resumption mode, since the handshake log does not contain > much information that is specific to the previous connection, it would be > more robust to add an explicit context. > > Yes, I agree that this is an improvement. > > -Ekr > > > On Fri, Mar 25, 2016 at 2:29 AM, Karthik Bhargavan < > karthikeyan.bhargavan@inria.fr> wrote: > >> We currently allow 0-RTT with Semi-static DH, with PSK resumption, and >> with pure PSK. >> Whether or not we keep all of these, it would be good to clean up the >> protocol design >> so that both the client and server have a uniform way of signaling their >> preferences. >> >> After implementing and analyzing TLS 1.3, here are a few suggestions for >> discussion. >> >> 1) Early Data Extension >> >> The current early-data extension is too DH-specific. >> When using PSK, we now have to look at both early_data and pre_shared >> extensions. >> I suggest reusing the same extension for both, with the following >> interpretation: >> >> struct { >> select (Role) { >> case client: >> opaque id<1..2^16-1>; >> opaque context<0..255>; >> CipherSuite cipher_suite; >> Extension extensions<0..2^16-1>; >> >> case server: >> struct {}; >> } >> } EarlyDataIndication; >> >> >> In the semi-static DH case: >> - id is the configuration id >> - context is the hash of the ServerConfiguration + Server Certificate + >> CertificateRequest >> >> In the PSK resumption case: >> - id is the session ticket >> - context is a *public* value unique to the derived session. For example= , >> it could be defined as the session hash of the original handshake, >> or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly data = context=E2=80=9D) >> >> In the pure PSK case >> - id is the PSK identifier >> - context is unique to the PSK and its allowed use. >> For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80=9Ce= arly data >> context=E2=80=9D) >> >> 2) New Session Ticket >> >> The NewSessionTicket message needs to indicate whether the server will >> accept 0-RTT, >> and what ciphersuites it is willing to accept (e.g. pure PSK resumption >> vs only PSK-ECDHE). >> >> I suggest the following modification to this message: >> struct { >> uint32 ticket_lifetime; >> opaque ticket<0..2^16-1>; >> CipherSuite cipher_suites<2..2^16-2>; >> EarlyDataType early_data_type >> } NewSessionTicket; >> >> enum { >> no_early_data_allowed(0), >> replayable_early_data_allowed (1), >> all_early_data_allowed(2), >> (65535) >> } EarlyDataType; >> >> The interpretation of the early_data_type field is that the server is >> either: >> (a) unwilling to accept 0-RTT (no_early_data_allowed), >> (b) willing to accept 0-RTT, but it has no replay cache >> (replayable_early_data_allowed), >> (c) willing to accept 0-RTT and has a replay cache that it uses to >> prevent replay (all_early_data_allowed) >> >> The client=E2=80=99s response to this ticket message should be to store = it in its >> session along with the =E2=80=9Ccontext=E2=80=9D (session hash or derive= d from RMS), >> the allowed cipher suites, and the early_data_indication. >> >> When resuming with this ticket: >> - the client should not send any 0-RTT data if no_early_data_allowed >> - the client should only send replayable data if >> replayable_early_data_allowed (e.g. GET requests) >> - the client can send any 0-RTT data if all_early_data_allowed, trusting >> the server to do the right thing. >> >> >> A note on replay >> ---------------------- >> >> There has been much discussion on 0-RTT replay and here=E2=80=99s a quic= k summary >> of my understanding. >> We already knew that an active attacker, or a lossy network, or an >> overzealous web browser could >> and would cause 0-RTT (and even 1-RTT) data to be replayed to the server= . >> This can already happen >> in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3. >> >> The new concerns on the mailing list (and in my TRON talk which was base= d >> on a ProVerif model) >> are that unlike TLS 1.2: >> (a) even a passive attacker could replay 0-RTT data, long after the >> client has gone away, >> (b) replaying authenticated 0-RTT data can be more damaging (whether >> authenticated with client cert or with a cookie), and >> (c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT >> data which opens up new attack vectors. >> >> As a result of these new concerns, I would say that TLS 1.3 should >> recommend that all servers SHOULD >> implement a replay cache, and those that cannot should clearly signal >> this to the client, so that the client >> can adjust its 0-RTT use case and its expectations accordingly. >> >> A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D >> ---------------------------------------------------------- >> >> When trying to figure out how to authenticate 0-RTT DH mode in an earlie= r >> draft, we came upon the >> design of signing the Handshake Context that consists of the ClientHello >> + additional information from the previous handshake. >> This construction prevents 0-RTT authentication from unknown key share >> attacks. >> >> Even if we eliminate client certificate authentication from 0-RTT, this >> notion of =E2=80=9Ccontext" is still useful for two reasons: >> (a) the application may use TokenBinding or some such protocol to >> authenticate 0-RTT data, and we need to understand what =E2=80=9Cchannel= binding=E2=80=9D >> to provide for this case, >> (b) in PSK resumption mode, since the handshake log does not contain muc= h >> information that is specific to the previous connection, it would be mor= e >> robust to add an explicit context. >> >> If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the EarlyDat= aIndication >> extension, then we can use the hash of the ClientHello uniformly in all >> 0-RTT modes for deriving keys, and for deriving a channel binding for th= e >> application. Furthermore, we can safely introduce a PSK_ECDHE >> mode where the server sends its Certificate and CertificateVerify and it= s >> signature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80= =9D field). >> >> Best regards, >> Karthik >> >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > --94eb2c0b11dec3ed84052ee481e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 25, 2016 at 11:38 AM, Karthik Bhargavan &= lt;kart= hikeyan.bhargavan@inria.fr> wrote:
Hi Eric,

Yes, I now agree with Ilari and you that we should have a separate = pre_shared_key extension
in order to signal multiple PSKs. I wond= er if we could still share the structure between
PSK and DH thoug= h, although that=E2=80=99s mainly an aesthetic choice.

Yes. I'm not wholly satisfied with what I poste= d here :)=C2=A0

The second idea seems sensible, and I do like t= he idea of binding the
session hash of the previous handshake int= o PSK-Resumption. One thing
that seems unclear would be what the = responsibilities of the server
are with respect to the context. I= n the current draft, the client
and server both digest it explici= tly but it's not signalled, which
has the disadvantage that y= ou can't just run the session transcript
forward. If the clie= nt just provides it to the server, then that
seems to have differ= ent security properties unless we require the
server to verify it= . Is that what you have in mind here?
I suggest that the =E2=80=9Ccontext=E2=80=9D is somethi= ng that the client generates
and the server must =C2=A0check.=C2= =A0

When a client receives a DH ServerConfiguratio= n,
or a NewSessionTicket, or an out-of-band PSK, it
gen= erates and stores the context with the key material.

When the server receives the id+context, it always has
enough = information to be able to check the context
after processing the = id. (e.g. it decrypts the sessionticket
and then verifies the con= text.) The server must perform this check.

This is what I assumed. We would need to document that.

I note that the context value here was intended for a different<= /div>
purpose,

Yeah= , sorry for reusing the name, but we were already using Handshake Context,<= /div>
so perhaps this confusion was already there.

I agree it was already confusing. I just wanted to = note it for posterity

-Ekr


Best,
Karthik


It's not supe= r-elegant to have a switch here in the decode for
EarlyDataIndica= tion, but they actually are semantically different, so
I'm no= t sure it's that bad. The idea here would be to design to a
d= ifferent invariant, namely:

- The client gets to o= ffer the server a bunch of options for the
=C2=A0 1-RTT handshake= . The server picks one.
=C2=A0=C2=A0
- The client offer= s the server exactly one option for 0-RTT and
=C2=A0 the server c= an take it or leave it.

This is the way that 0-RTT= DHE works now. It does open the door
to the server somehow picki= ng a different option for 1-RTT than
the client chose for 0-RTT, = but this is something we could forbid.
=C2=A0=C2=A0
> 2) New Session Ticket
>=C2=A0
> = The NewSessionTicket message needs to indicate whether the server will acce= pt 0-RTT,
> and what ciphersuites it is willing to accept (e.g= . pure PSK resumption vs only PSK-ECDHE).

> I s= uggest the following modification to this message:
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 struct {
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0uint32 ticket_lifetime;
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0opaque ticket<0..2^16-1>;
> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0CipherSuite cipher_suites<2..2^16-2>;
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EarlyDataType early_data_type
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 } NewSessionTicket;

T= he cipher suites indication seems generally sensible.

<= div>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 enum {
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no_early_data_allowed(0),
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replayable_early_data_allowed (1),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 all_early_data_allowed(2),
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (65535)
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0} EarlyDataType;
>=C2=A0
>= ; The interpretation of the early_data_type field is that the server is eit= her:
> (a) unwilling to accept 0-RTT (no_early_data_allowed),<= /div>
> (b) willing to accept 0-RTT, but it has no replay cache (rep= layable_early_data_allowed),
> (c) willing to accept 0-RTT and= has a replay cache that it uses to prevent replay (all_early_data_allowed)=

This is an interested suggestion. I agree that it= 's important to
be able to say "don't send me 0-RTT = data" (see above). ISTM that
"all_early_data_allowed&qu= ot; would be useful primarily if we allowed
clients who received = it to use the ordinary TLS 1.3 API for sending
0-RTT data. That w= ould be a real advantage, it seems to me.



> There has been much discussion on 0-RTT replay a= nd here=E2=80=99s a quick summary of my understanding.
> We al= ready knew that an active attacker, or a lossy network, or an overzealous w= eb browser could
> and would cause 0-RTT (and even 1-RTT) data= to be replayed to the server. This can already happen
> in TL= S 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.
>= =C2=A0
> The new concerns on the mailing list (and in my TRON = talk which was based on a ProVerif model)
> are that unlike TL= S 1.2:
> (a) even a passive attacker could replay 0-RTT data, = long after the client has gone away,

Nit: This doe= sn't sound like a passive attacker to me...

> Even if we eliminate client certificate authentication fr= om 0-RTT, this notion of =E2=80=9Ccontext" is still useful for two rea= sons:
> (a) the application may use TokenBinding or some such = protocol to authenticate 0-RTT data, and we need to understand what =E2=80= =9Cchannel binding=E2=80=9D to provide for this case,
> (b) in= PSK resumption mode, since the handshake log does not contain much informa= tion that is specific to the previous connection, it would be more robust t= o add an explicit context.

Yes, I agree that this = is an improvement.

-Ekr

=

On Fri, Mar 25, 2= 016 at 2:29 AM, Karthik Bhargavan <karthikeyan.bhargavan@inri= a.fr> wrote:
We currently a= llow 0-RTT with Semi-static DH, with PSK resumption, and with pure PSK.
Whether or not we keep all of these, it would be good to clean up the proto= col design
so that both the client and server have a uniform way of signaling their pr= eferences.

After implementing and analyzing TLS 1.3, here are a few suggestions for di= scussion.

1) Early Data Extension

The current early-data extension is too DH-specific.
When using PSK, we now have to look at both early_data and pre_shared exten= sions.
I suggest reusing the same extension for both, with the following interpret= ation:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 select (Role) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque id<= ;1..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque conte= xt<0..255>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 CipherSuite = cipher_suite;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Extension ex= tensions<0..2^16-1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case server:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct {}; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } EarlyDataIndication;


In the semi-static DH case:
- id is the configuration id
- context is the hash of the ServerConfiguration + Server Certificate + Cer= tificateRequest

In the PSK resumption case:
- id is the session ticket
- context is a *public* value unique to the derived session. For example, i= t could be defined as the session hash of the original handshake,
=C2=A0 or it could be derived by the client as HKDF(RMS, =E2=80=9Cearly dat= a context=E2=80=9D)

In the pure PSK case
- id is the PSK identifier
- context is unique to the PSK and its allowed use.
=C2=A0 For example, it can be generated (out-of-band) as HKDF(PSK, =E2=80= =9Cearly data context=E2=80=9D)

2) New Session Ticket

The NewSessionTicket message needs to indicate whether the server will acce= pt 0-RTT,
and what ciphersuites it is willing to accept (e.g. pure PSK resumption vs = only PSK-ECDHE).

I suggest the following modification to this message:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32 ticket_lifetime;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque ticket<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CipherSuite cipher_suites<2..2^16-2>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0EarlyDataType early_data_type
=C2=A0 =C2=A0 =C2=A0 =C2=A0 } NewSessionTicket;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 enum {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 no_early_data_allowed(0),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 replayable_early_data_allowed (1),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 all_early_data_allowed(2),
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (65535)
=C2=A0 =C2=A0 =C2=A0 =C2=A0} EarlyDataType;

The interpretation of the early_data_type field is that the server is eithe= r:
(a) unwilling to accept 0-RTT (no_early_data_allowed),
(b) willing to accept 0-RTT, but it has no replay cache (replayable_early_d= ata_allowed),
(c) willing to accept 0-RTT and has a replay cache that it uses to prevent = replay (all_early_data_allowed)

The client=E2=80=99s response to this ticket message should be to store it = in its
session along with the =E2=80=9Ccontext=E2=80=9D (session hash or derived f= rom RMS),
the allowed cipher suites, and the early_data_indication.

When resuming with this ticket:
- the client should not send any 0-RTT data if no_early_data_allowed
- the client should only send replayable data if replayable_early_data_allo= wed (e.g. GET requests)
- the client can send any 0-RTT data if all_early_data_allowed, trusting th= e server to do the right thing.


A note on replay
----------------------

There has been much discussion on 0-RTT replay and here=E2=80=99s a quick s= ummary of my understanding.
We already knew that an active attacker, or a lossy network, or an overzeal= ous web browser could
and would cause 0-RTT (and even 1-RTT) data to be replayed to the server. T= his can already happen
in TLS 1.2, in QUIC, and so we accepted it as a given in TLS 1.3.

The new concerns on the mailing list (and in my TRON talk which was based o= n a ProVerif model)
are that unlike TLS 1.2:
(a) even a passive attacker could replay 0-RTT data, long after the client = has gone away,
(b) replaying authenticated 0-RTT data can be more damaging (whether authen= ticated with client cert or with a cookie), and
(c) by replaying 0-RTT data, the attacker can obtain encrypted 0.5-RTT data= which opens up new attack vectors.

As a result of these new concerns, I would say that TLS 1.3 should recommen= d that all servers SHOULD
implement a replay cache, and those that cannot should clearly signal this = to the client, so that the client
can adjust its 0-RTT use case and its expectations accordingly.

A note on authenticating the 0-RTT =E2=80=9Ccontext=E2=80=9D
----------------------------------------------------------

When trying to figure out how to authenticate 0-RTT DH mode in an earlier d= raft, we came upon the
design of signing the Handshake Context that consists of the ClientHello + = additional information from the previous handshake.
This construction prevents 0-RTT authentication from unknown key share atta= cks.

Even if we eliminate client certificate authentication from 0-RTT, this not= ion of =E2=80=9Ccontext" is still useful for two reasons:
(a) the application may use TokenBinding or some such protocol to authentic= ate 0-RTT data, and we need to understand what =E2=80=9Cchannel binding=E2= =80=9D to provide for this case,
(b) in PSK resumption mode, since the handshake log does not contain much i= nformation that is specific to the previous connection, it would be more ro= bust to add an explicit context.

If we accept the definition of =E2=80=9Ccontext=E2=80=9D in the EarlyDataIn= dication extension, then we can use the hash of the ClientHello uniformly i= n all
0-RTT modes for deriving keys, and for deriving a channel binding for the a= pplication. Furthermore, we can safely introduce a PSK_ECDHE
mode where the server sends its Certificate and CertificateVerify and its s= ignature is correctly bound to the PSK (via the =E2=80=9Ccontext=E2=80=9D f= ield).

Best regards,
Karthik





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



--94eb2c0b11dec3ed84052ee481e9-- From nobody Fri Mar 25 12:31:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868B212D0EF for ; Fri, 25 Mar 2016 12:31: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=unavailable 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 l4VOAy2OdDST for ; Fri, 25 Mar 2016 12:31:03 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06CF512D0C1 for ; Fri, 25 Mar 2016 12:25:13 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id s68so38047830qkh.3 for ; Fri, 25 Mar 2016 12:25:12 -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=tYXT5GCLRs6XLoH+mZcsKpqnlqB5aeWDlxWHR4USHA8=; b=MWRFAyHc14q9d0hUlYEpCs485vlso6QaK8Le9wXC8RbSjOuVq3I//YnL9vb0m7+/T5 QcsquGlHsiLye+ASfMb7xTP9OIllLnr8u87/dO9DVK5Nj3Uo72a7HjpQ0ITxOd3zA2Rk efaSGZJhnEgn8jEGM5o31EHKi40kuDLvE1NZ+oe88FSX5rJ6ycVrtJJG7MgoV9KTkEGH G2ECeYmAvpeM6UQK+UsxmDyi/vubuuFkyWeRT5n3CAX3pa8xF0axAl32msOe6+q6hCAY 5vcixM0sJ8ZI/QjiyCXTjmOKLSxyrYAE1/jpTDQ79H3Rh6jWotC2yBCECEegywmIMB6B d7Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tYXT5GCLRs6XLoH+mZcsKpqnlqB5aeWDlxWHR4USHA8=; b=YWX5Fz34AGSryC4SSpZub8bul/kdoME6EMR93mITxBhcOqY4Pj9qFZxgLG/02g2da6 ggT6Lire/v4k0vsqLRidNkmJQon4TqrgHMLiI7VeXI4wb1B7LAWKE9jexroRlJ/UTlG+ gA6/5Bhjx7eL7cu0UvT9/hpy3amt8EAatE0JBF+el8leF6QHfckLY6AJARzXAOP0GLzp 3jl/WgUq8Rma+sj7rXuujWF8hCJQwCjiiCv/Fvt4ZTY3iCNU0THi2Rfv/2eIYNcZkOUc ub6VtMhKvG0RdGAg+7sQ6PCwcAggHrX7mli/u3ESImUfK+FyGQGmr2Qq1OkTYH+iGBas FWCg== X-Gm-Message-State: AD7BkJIZ9WIHO6b5J0A2DnudHb/l4BN/HVVb5ynvv2USQShTE+8G+GltrRLVjEZRtl7ly6odtMeCVkHwW3i61g== X-Received: by 10.129.152.208 with SMTP id p199mr1759978ywg.129.1458933912047; Fri, 25 Mar 2016 12:25:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 25 Mar 2016 12:24:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 25 Mar 2016 12:24:32 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=94eb2c0bbb0e944611052ee48504 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:31:04 -0000 --94eb2c0bbb0e944611052ee48504 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 25, 2016 at 12:23 PM, Colm MacC=C3=A1rthaigh wrote: > On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla wrote: > >> On Fri, Mar 25, 2016 at 11:27 AM, Colm MacC=C3=A1rthaigh >> wrote: >>> >>> +1 but I think we can go further here and specify 0RTT in such a way >>> that it only works when the server maintains state, and so that any giv= en >>> 0RTT ticket may only be used once (to preserve forward secrecy as much = as >>> possible within the constrains of 0RTT). >>> >> >> I'm not enthusiastic about this. This seems like it would rule out a >> bunch of implementations >> which don't need that guarantee. >> > > With 0RTT, it doesn't seem to be possible to have anti-replay of the > message itself without some kind of server state. > Yes. > It's also beneficial for cryptographic safety to prevent at-will re-use o= f > the ticket - other-wise the data is subject to the kind of "try and > iterate" attacks we've seen be very successful against DTLS because of it= s > tolerance for duplicate and out of order messages. If server state is > required, some more good can come of it by improving the forward secrecy = of > the 0RTT data to match that of regular data; which I think is most > important of all. > > An implementation would have to be willing to sacrifice replay protection= , > some cryptographic safety and forward secrecy for the 0RTT data. I'm sure > there are implementations that would sacrifice these things to get lower > latency more cheaply, but should they be encouraged? > The issue isn't encouraged. It's whether we should design the protocol so that it cannot be implemented any other way. -Ekr > I'll admit that this is an unfair simplification in this case since it'= s > a more grey area, but "fast, secure, cheap: pick two" is at play here, an= d > many would pick "fast, cheap". > > > -- > Colm > --94eb2c0bbb0e944611052ee48504 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Mar 25, 2016 at 12:23 PM, Colm MacC=C3=A1rthaigh <colm@allcost= s.net> wrote:
On Fri, Mar 25, 2016 at 11:36 AM, Eric Rescorla <ekr@rtfm.= com> wrote:
On Fri= , Mar 25, 2016 at 11:27 AM, Colm MacC=C3=A1rthaigh <colm@allcosts.net&= gt; wrote:
+1 but I think we can go f= urther here and specify 0RTT in such a way that it only works when the serv= er maintains state, and so that any given 0RTT ticket may only be used once= (to preserve forward secrecy as much as possible within the constrains of = 0RTT).

I'= ;m not enthusiastic about this. This seems like it would rule out a bunch o= f implementations
which don't need that guarantee.
=C2=A0
With 0RTT, it doesn&= #39;t seem to be possible to have anti-replay of the message itself without= some kind of server state.

Yes.

=C2=A0
It's also beneficial for cryptographic safety to prevent at-wi= ll re-use of the ticket - other-wise the data is subject to the kind of &qu= ot;try and iterate" attacks we've seen be very successful against = DTLS because of its tolerance for duplicate and out of order messages. If s= erver state is required, some more good can come of it by improving the for= ward secrecy of the 0RTT data to match that of regular data; which I think = is most important of all. =C2=A0

An implementation= would have to be willing to sacrifice replay protection, some cryptographi= c safety and forward secrecy for the 0RTT data. I'm sure there are impl= ementations that would sacrifice these things to get lower latency more che= aply, but should they be encouraged?

The issue isn't encouraged. It's whether we shoul= d design the protocol so that it cannot be implemented any other way.
=

-Ekr
=C2=A0
=C2=A0 I'll admit that this is an unfair simplification in this= case since it's a more grey area, but "fast, secure, cheap: pick = two" is at play here, and many would pick "fast, cheap". =C2= =A0
<= span class=3D"HOEnZb">

=

--
=
Colm

--94eb2c0bbb0e944611052ee48504-- From nobody Fri Mar 25 12:40:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C1912D6B7 for ; Fri, 25 Mar 2016 12:40:09 -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=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 K4DbMBMg5Y6N for ; Fri, 25 Mar 2016 12:40:08 -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 E892A12D682 for ; Fri, 25 Mar 2016 12:39:45 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id s68so38455446qkh.3 for ; Fri, 25 Mar 2016 12:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=JQd7na7i6SJvkBwbO4gBt78a5SBvz3Ms6I1zEX197LU=; b=PEc1Qfhe82gTOKTjmRqQdCC08+PGumojcEP/0yDNKT8jVRFBFYhR/IidhU0hauiY7m n+gwprZOA+3MJ1haVD3gAgTqonpjh+i338HK3xWnNNeCGhGrg5wI9f1cmmaOquSnkiMD TWeppt2IuLE2hTOIpldNG3tgxc9cFAGV2fIeVS0e9JPBOXax79eKuP2dgRt7I42pYK+s GfdJd7QNHIhq2rD12hjM5jL5PBI8+xCQ+xxe8IquT/isXqboKwOHNpHQT4FwzPdC0627 JB6cryohfnwNm84s0CXOLm5ByxQfkuh0ygyLPuuj4DVVlTdbIZVXPRLW1PMvtK/py3zx esqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JQd7na7i6SJvkBwbO4gBt78a5SBvz3Ms6I1zEX197LU=; b=dFuT7UvpEyrJoBz7cb1ucb9MX9s/CoxN0qjyvhRcEFEr5E8z4WLJMWILQYPOQwC8PQ 8m10Z84vec52+HTjuNs6ERz5kuEuGUNfqXEj6H3pLgVwaSvq3sL1kZ2yScBq4Pa3imvu 9NQcK8b7/DBSvXxSpEP0R8C1htPpZX4bhqcRFOjrkk8a5Dp/I+6925EmV46HCKy2RQmt VUdHG4SMzMNxcEUrij5OYKePzCMlE3LD37Xfc+PoFFff1Zf9mmpOb9rFYGTmiLEE8Pbg vnudlczMPKv1Aq4H6KGtPpdchgthv0w3TL+zDAGyOrb/fNRBEMwyTY7c+WXxHsKEMane J75A== X-Gm-Message-State: AD7BkJLgZIMvwYACzZLUaGnHeDKH0ilPnXjagTDyg3Mh6S/fyEwvE0lwy6tQUZwWkwEuS3fSTG9liPcy4I91xA== MIME-Version: 1.0 X-Received: by 10.13.212.202 with SMTP id w193mr8013621ywd.175.1458934785095; Fri, 25 Mar 2016 12:39:45 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Fri, 25 Mar 2016 12:39:45 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Mar 2016 12:39:45 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114fa17c9e32e1052ee4b937 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:40:09 -0000 --001a114fa17c9e32e1052ee4b937 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 25, 2016 at 12:24 PM, Eric Rescorla wrote: > The issue isn't encouraged. It's whether we should design the protocol so > that it cannot be implemented any other way. > I think it is encouraged ... not really intentionally, but economically. We all know that the keys encrypting TLS tickets should be rotated frequently; but that's not something that happens that much in the real world. Take Apache httpd or nginx for example; both lack any support for rotation schedules or key id indication in the ticket. I've encountered a lot of environments using these, and other servers, and besides my own employer - I've *never* seen an environment in which the keys are actually rotated. Folks, developers and operators, just set up things up to the point there things "work". The end effect is that users have no way to know if their connections are actually forward secure. Now one could argue; that's impossible to begin with - maybe the provider is logging everything, including the full request and response bodies, and maybe those logs are weakly protected, and so on. That's true, but it's rare, and particularly egregious. The default at the transport layer should be to keep users sessions secret; even in the face of a credential compromise. That's what we're aiming for with TLS1.3 I think. 0RTT data is likely to contain request data; which I'd regard as sensitive - so I really want to make sure it's protected and that a user can tell with some confidence that it likely really is. If we require server state; it flips the economics. The default "cheap" way would be FS (no 0RTT), and if you do implement a session cache, you'll be incentivized to evict entries ASAP with a single-use requirement. And it gets us to a place where a compromise can only decrypt future sessions; not previous ones - which is the same as (EC)DHE. -- Colm --001a114fa17c9e32e1052ee4b937 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 25, 2016 at 12:24 PM, Eric Rescorla <ekr@rtfm.com= > wrote:
The issue isn't en= couraged. It's whether we should design the protocol so that it cannot = be implemented any other way.

I think= it is encouraged ... not really intentionally, but economically.=C2=A0

We all know that the keys encrypting TLS tickets shou= ld be rotated frequently; but that's not something that happens that mu= ch in the real world. Take Apache httpd or nginx for example; both lack any= support for rotation schedules or key id indication in the ticket. I'v= e encountered a lot of environments using these, and other servers, and bes= ides my own employer - I've *never* seen an environment in which the ke= ys are actually rotated.=C2=A0 Folks, developers and operators, just set up= things up to the point there things "work".=C2=A0

=
The end effect is that users have no way to know if their connec= tions are actually forward secure. Now one could argue; that's impossib= le to begin with - maybe the provider is logging everything, including the = full request and response bodies, and maybe those logs are weakly protected= , and so on. That's true, but it's rare, and particularly egregious= . The default at the transport layer should be to keep users sessions secre= t; even in the face of a credential compromise. That's what we're a= iming for with TLS1.3 I think. =C2=A0

0RTT data is= likely to contain request data; which I'd regard as sensitive - so I r= eally want to make sure it's protected and that a user can tell with so= me confidence that it likely really is.=C2=A0

If w= e require server state; it flips the economics. The default "cheap&quo= t; way would be FS (no 0RTT), and if you do implement a session cache, you&= #39;ll be incentivized to evict entries ASAP with a single-use requirement.= And it gets us to a place where a compromise can only decrypt future sessi= ons; not previous ones - which is the same as (EC)DHE.=C2=A0

--
Colm
--001a114fa17c9e32e1052ee4b937-- From nobody Fri Mar 25 12:41:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2491B12D5EA for ; Fri, 25 Mar 2016 12:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Ew6XLr7lXDZs for ; Fri, 25 Mar 2016 12:41:18 -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 448C212D1D0 for ; Fri, 25 Mar 2016 12:41:05 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o6so38427738qkc.2 for ; Fri, 25 Mar 2016 12:41:05 -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:date:message-id:subject:from:to :cc; bh=rv0ZVlVfUC9zwaSJB1KzuVm6yqcQTSG5LNpCZe+JfMQ=; b=xC+2MaXDyDU/0EcmsKJDYoLjrc6y8Ob+dhw2mrGtIXfqUTONDiJc226osQ60F+XxQy 39OTvO4kId/XhAz7Q2E7HdyHxrpuunXs2WW/yWkSGd29bxWWE+3p+TbyzRVGtPWL5Zjc 8vQ+jGrugxxdQ+C0tirlp6PNt8vrd/OJIZ46SAaL7t8uZftY23mFBzIMDdJx3z1JUWjT XfdLfeKRkkoO5bTJBknp7GX4JznaVw0OWimUAWoVGSRmTudYXGog0vLt0KsQWBRFFAvm jSrZIJQNxvdOJXxKWbMv1HXy7pOnPnLlqXHHD1Ic+eEWJcRprEllm6xFryObt4/VzLBv hNBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rv0ZVlVfUC9zwaSJB1KzuVm6yqcQTSG5LNpCZe+JfMQ=; b=XLB1wSzyJTmInqed7K8aAWEA0XsLM9gsJCuEVrCALjs1N9Z8o9OdpLLJ889G3sDdNN QgtM4mGKPJnNmee+2BWDfVIYwhBPNNyeHffdPl00je+hAxxdTSEf4idqs489NqIl9Lq+ eA8yNiAM6f0EkiQQtWDfnjetD41ZfCRLSUZFm16ZhB3Qmgr7HfwI0pQJt1Et5Xn+SBa5 UOnYCm8a07YdP07ZxbKydtL85Pov3LIAMvomepnC0Gfx+hh9qXJpSZut1OG7ROFYf+HL aE+mOoDNyOnhHa7j3HU0T/9lEFUJWgU2BaU38GaKWT/BvnHmtYKkUvjQGZiV+prQ1j69 BXKA== X-Gm-Message-State: AD7BkJJ9/pI4zJv7dohXDT8b+kZ/LwstRqidxcMPKPdibCu9JMXZM3Qq/MHjw++xb4j6lM/aNbPa4+/aL8rgaQ== MIME-Version: 1.0 X-Received: by 10.37.94.138 with SMTP id s132mr8676316ybb.85.1458934864485; Fri, 25 Mar 2016 12:41:04 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Fri, 25 Mar 2016 12:41:04 -0700 (PDT) In-Reply-To: <4B85487A-850B-4347-80A7-A3A4D92593E6@inria.fr> References: <4B85487A-850B-4347-80A7-A3A4D92593E6@inria.fr> Date: Fri, 25 Mar 2016 12:41:04 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Karthik Bhargavan Content-Type: multipart/alternative; boundary=001a11422e16597157052ee4beb1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 25 Mar 2016 19:41:20 -0000 --001a11422e16597157052ee4beb1 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan < karthikeyan.bhargavan@inria.fr> wrote: > > +1 but I think we can go further here and specify 0RTT in such a way > that it only works when the server maintains state, and so that any given > 0RTT ticket may only be used once (to preserve forward secrecy as much as > possible within the constrains of 0RTT). > > Do you envision clients only having one resumption handshake at a time? I > was under the impression that TLS 1.2 clients typically open multiple > resumption handshakes in parallel, and that TLS 1.3 clients would want to > do the same. > It is common for existing clients to re-use the same ticket for many connections. This is at-odds with forward secrecy though :/ Clients could have many resumption tokens at a time though; e.g. they could ask for 10 and use each one once. It's just that each token is used once. So parallel resumptions could be supported. -- Colm --001a11422e16597157052ee4beb1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:
= > +1 but I think we can go further here and specify 0RT= T in such a way that it only works when the server maintains state, and so = that any given 0RTT ticket may only be used once (to preserve forward secre= cy as much as possible within the constrains of 0RTT).

Do you envision clients only having one resumption handshake at a ti= me? I was under the impression that TLS 1.2 clients typically open multiple=
resumption handshakes in parallel, and that TLS 1.3 clients would want to d= o the same.

It is common for existing c= lients to re-use the same ticket for many connections. This is at-odds with= forward secrecy though :/ Clients could have many resumption tokens at a t= ime though; e.g. they could ask for 10 and use each one once. It's just= that each token is used once. So parallel resumptions could be supported.<= /div>
=C2=A0

--
Colm
--001a11422e16597157052ee4beb1-- From nobody Sat Mar 26 13:10:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0A512D19E for ; Sat, 26 Mar 2016 13:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 Au0YoN_MfyJ8 for ; Sat, 26 Mar 2016 13:10:17 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD4012D14D for ; Sat, 26 Mar 2016 13:10:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 329984C57; Sat, 26 Mar 2016 22:10:16 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id lstf7N9HkNmh; Sat, 26 Mar 2016 22:10:15 +0200 (EET) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B9E182310; Sat, 26 Mar 2016 22:10:15 +0200 (EET) Date: Sat, 26 Mar 2016 22:10:13 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160326201013.GA14675@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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, 26 Mar 2016 20:10:20 -0000 On Fri, Mar 25, 2016 at 12:24:32PM -0700, Eric Rescorla wrote: > On Fri, Mar 25, 2016 at 12:23 PM, Colm MacCárthaigh > wrote: > > > > An implementation would have to be willing to sacrifice replay protection, > > some cryptographic safety and forward secrecy for the 0RTT data. I'm sure > > there are implementations that would sacrifice these things to get lower > > latency more cheaply, but should they be encouraged? > > > > The issue isn't encouraged. It's whether we should design the protocol so > that it cannot be implemented any other way. Also, implementing protocol that it can't be done another way isn't trivial (aside from limiting session IDs to some small size or something line that... If one has enough space to offload state, one can just ignore state updates, making things replayable... -Ilari From nobody Mon Mar 28 08:58:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC3812DB93 for ; Mon, 28 Mar 2016 08:58:35 -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 jGzMbeb5scUD for ; Mon, 28 Mar 2016 08:58:34 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB5D12DB87 for ; Mon, 28 Mar 2016 08:56:46 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id 127so27917932wmu.1 for ; Mon, 28 Mar 2016 08:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=aoRB87KrGKu8L+KcraKNUyE7E9GfiH06Ey/H4t9uzmw=; b=osUMs9wfojk4a7jC5IRjS4SS6GI3TH78B1xzD+vgjD5ZqR0yLCiL5Jg/9SFbf6ogM3 feuqlogA0bWaB49eLHR5LxK+ZNmMVV09FcPfSOsZWreCG2eY45dwaAnbwqdFkCKPHNGR 6pDGKMDh/MyPaaNohcTNq30Z3tH6D1JGFaxJ3SsgjhiwQvqGswvc7zEs8a2TCqwz20cz SkPef8Gb3hfejEFp6yN/eZRG0LetEhQWO5ABAizaeGYwY/wlY0e+pMFdN9DVeXJIrs8I Et6C3Uz03JxqlqLsA/TeBHPBBJc6Ecvi6CVf6noQIiMDC+g0OJvuDRIL0V+GO+lSqzI/ jgaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=aoRB87KrGKu8L+KcraKNUyE7E9GfiH06Ey/H4t9uzmw=; b=iINTbwz6kPvAhNzlEpqShHieoalADjZJikpZ4heK6hLv0cviK+MmgWsM01nB9fm1dj 3p6Ty7EAY7Dxh8pwLJmVGFFnsiqYUewQ8wiU/CmgpkUL1e/vU8VWkwSFpBBPLroL4a1E HAwpYeJg3CIshanAKjQgGIRcA1zsncWagHNLtjMVzVpJcZehy3K4U+TqaToIFHC4wcaf V0QuLtL+nXY9Lq4JH+cvg0PXi60AReGRarRLFaki4NzsqthkgXGFUUmZ4IpXNHKt97Z/ IVHpA+i8QkJJJ1dTq8yD8zA+v7ZEUwQWlBLNR9ncVwDR9ws95tIp+1EmodQ+AHBmwePE 2gYA== X-Gm-Message-State: AD7BkJLijTXSt8grnuLkG1kbD1kci1nXAX0UhC/GGoNYK+8SYiaIYfKXrYJzPLpOtWilEQbrSqgjhtSWaT/B2g== MIME-Version: 1.0 X-Received: by 10.194.71.70 with SMTP id s6mr28957561wju.1.1459180604666; Mon, 28 Mar 2016 08:56:44 -0700 (PDT) Received: by 10.28.55.146 with HTTP; Mon, 28 Mar 2016 08:56:44 -0700 (PDT) Date: Mon, 28 Mar 2016 17:56:44 +0200 Message-ID: From: Maarten Bodewes To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd91b7e9abcf5052f1df575 Archived-At: Subject: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:58:36 -0000 --047d7bd91b7e9abcf5052f1df575 Content-Type: text/plain; charset=UTF-8 Hi all, I see that the leading zero is stripped off of the value of Z (the shared secret) before it is used as input to HKDF. This seems to be compatible with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which uses the value of Z with the same size of the prime in octets. Furthermore, it is also different with regards to handling the coordinate X as used in ECDH. Was this a conscious decision to keep compatibility with TLS? Has the use of the value of Z including zero octets been considered? Regards, Maarten --047d7bd91b7e9abcf5052f1df575 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I see that the le= ading zero is stripped off of the value of Z (the shared secret) before it = is used as input to HKDF. This seems to be compatible with TLS 1.2. Then ag= ain, it is not compatible with e.g. NISP800-56A which uses the value of Z w= ith the same size of the prime in octets. Furthermore, it is also different= with regards to handling the coordinate X as used in ECDH.

Wa= s this a conscious decision to keep compatibility with TLS? Has the use of = the value of Z including zero octets been considered?

Regards,=
Maarten
--047d7bd91b7e9abcf5052f1df575-- From nobody Mon Mar 28 09:07:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF812DB5F for ; Mon, 28 Mar 2016 09:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RM03UlDAoZQN for ; Mon, 28 Mar 2016 09:07:16 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 0AC1912DA42 for ; Mon, 28 Mar 2016 09:07:11 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id e185so161078511vkb.1 for ; Mon, 28 Mar 2016 09:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=ljBKqMDvGxtaS8FIkaN20Vtl5x4wynXrZh5WvZRw9to=; b=DzCfWnvshxL6n+Q0JfVj2etCAGy/S47Y4SkLUdVFK+LiCUN2wcQTxUZoOYPNvJvMMw CHrs0IgILEpHu0n6iqjC+SXl+bG61MWHX8cSKPkvtR/8ufGolxmxFgVcbe+81O24o6GS NbYqQEnLinbyyLEruzXogMGPmDPcdyCSW0MlXzO0/eTsI7yvqQ3lFeujvm0djf1z6ted VEDpcYcsuavkLcXceRw7mvvXL2CMatavRycO1Bv2E60R0EgR2UxNAT4OqqsSci31kJ95 VjwX52w5TlMAE8RV9mBTtRdmBGihbZ9wD4qt1qekV6kBmsGRav8nDbXWo0eUTXArOsRt ZHkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ljBKqMDvGxtaS8FIkaN20Vtl5x4wynXrZh5WvZRw9to=; b=gvnw0Vidw0GWffK+2xQH7TVHgP9omphpAivXm6TsclSdJtREpe46d3uLflMnaVvwoF /zpqesSwflt5YWeGJnRvlAomiz829wcEEnxINdQDcOFrql0ruuqDKwH0v1OBrwE/oFfT huhspi6XEUEc5HNL2Pq9QWxGpPGyGR7NFqoph3rXEDh8Zy/ZTrHzTJvUqb0Q6yHcihVy VeB8STM6VcFYlXh/jtEFQjeH56LxGn3vlGuIM+qToJh5Z5IW/2onxmkqX48CORquUdhw 8enOwfkEFt5LWYIoy4bHJk96zBBDLByFY6N08VMbH6UWzWcWbqDFo10ACwwp9D5OLg0i ZRlw== X-Gm-Message-State: AD7BkJK9MQJB9H0GgYxKGTfDsdnGS+VekRlW0hJUfuxFQ7IUCTkx0egrlFfmdTBiX2+QN8c3U3iK16mQj+mQnGqP MIME-Version: 1.0 X-Received: by 10.159.37.242 with SMTP id 105mr15264138uaf.27.1459181229826; Mon, 28 Mar 2016 09:07:09 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Mon, 28 Mar 2016 09:07:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2016 09:07:09 -0700 Message-ID: From: Bill Cox To: Maarten Bodewes Content-Type: multipart/alternative; boundary=001a113ac86adeeaa7052f1e1a0c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:07:18 -0000 --001a113ac86adeeaa7052f1e1a0c Content-Type: text/plain; charset=UTF-8 I spent 2 weeks last year tracking down a flaky bug that only occurs once in every 256 connection: the leading 0 byte was no longer being stripped in a code change I ported from OpenSSL master, and only Maria DB ran random tests enough to trigger this condition. I guess I would prefer that this particular weird goober in TLS would go away, but it would be incompatible. Bill On Mon, Mar 28, 2016 at 8:56 AM, Maarten Bodewes wrote: > Hi all, > > I see that the leading zero is stripped off of the value of Z (the shared > secret) before it is used as input to HKDF. This seems to be compatible > with TLS 1.2. Then again, it is not compatible with e.g. NISP800-56A which > uses the value of Z with the same size of the prime in octets. Furthermore, > it is also different with regards to handling the coordinate X as used in > ECDH. > > Was this a conscious decision to keep compatibility with TLS? Has the use > of the value of Z including zero octets been considered? > > Regards, > Maarten > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113ac86adeeaa7052f1e1a0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I spent 2 weeks last year tracking down a flaky bug that o= nly occurs once in every 256 connection: the leading 0 byte was no longer b= eing stripped in a code change I ported from OpenSSL master, and only Maria= DB ran random tests enough to trigger this condition.

I= guess I would prefer that this particular weird goober in TLS would go awa= y, but it would be incompatible.

Bill
<= div class=3D"gmail_extra">
On Mon, Mar 28, 20= 16 at 8:56 AM, Maarten Bodewes <maarten.bodewes@gmail.com><= /span> wrote:
=
Hi all,

I see that the leading zero is stripped off = of the value of Z (the shared secret) before it is used as input to HKDF. T= his seems to be compatible with TLS 1.2. Then again, it is not compatible w= ith e.g. NISP800-56A which uses the value of Z with the same size of the pr= ime in octets. Furthermore, it is also different with regards to handling t= he coordinate X as used in ECDH.

Was this a conscious decision= to keep compatibility with TLS? Has the use of the value of Z including ze= ro octets been considered?

Regards,
Maarten

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


--001a113ac86adeeaa7052f1e1a0c-- From nobody Mon Mar 28 09:11:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3018512D99E for ; Mon, 28 Mar 2016 09:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 DemiF0ACFRhy for ; Mon, 28 Mar 2016 09:11:06 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 1110512DB65 for ; Mon, 28 Mar 2016 09:11:04 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 08A0143346A; Mon, 28 Mar 2016 16:11:04 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E65ED4DE70; Mon, 28 Mar 2016 16:11:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459181463; bh=PP1ZxjuVBhX6GTjnzdAx7N4QoAK2HMbUEoOGrUJNBhs=; l=6415; h=To:References:Cc:From:Date:In-Reply-To:From; b=YtINp9h3H7ywtEIgXkz1hkT3pUTHGN0UEAiMPuEb0dQH7MI0sLttHakm1dNUMJ6vc BcG+0VyqkWv3EhtO+rX/vh+7lhBllc4TuxzzhcCtZe++PS3ZDTi1LlgUE7/UrEDK1Q QZApwVpBkT9jkKTAIjITYc0Tge2KFhI3a1gkTpUE= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BA4881FC86; Mon, 28 Mar 2016 16:11:03 +0000 (GMT) To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= References: <4B85487A-850B-4347-80A7-A3A4D92593E6@inria.fr> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <56F95797.2070206@akamai.com> Date: Mon, 28 Mar 2016 11:11:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------040905020606050501030604" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:11:09 -0000 This is a multi-part message in MIME format. --------------040905020606050501030604 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/25/2016 02:41 PM, Colm MacCrthaigh wrote: > On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan > > wrote: > > > +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server > maintains state, and so that any given 0RTT ticket may only be > used once (to preserve forward secrecy as much as possible within > the constrains of 0RTT). > > Do you envision clients only having one resumption handshake at a > time? I was under the impression that TLS 1.2 clients typically > open multiple > resumption handshakes in parallel, and that TLS 1.3 clients would > want to do the same. > > > It is common for existing clients to re-use the same ticket for many > connections. This is at-odds with forward secrecy though :/ Clients > could have many resumption tokens at a time though; e.g. they could > ask for 10 and use each one once. It's just that each token is used > once. So parallel resumptions could be supported. > I understand there are good reasons to want to make the default behavior of a single-physical-server TLS server as secure as possible, but I think it's also well-understood that the more "exciting" portions of 0-RTT happen in a distributed setup, where there are different physical (well, maybe virtual) machines sharing a session ticket key, potentially in different data centers. I don't think we've seen a real description of how this proposal for "single-use" session tickets would behave in the distributed setup yet. Are you proposing to require a distributed replay cache shared by all machines sharing the session-ticket key? I expect a lot of pushback from operators in that case, since distributed replay caches are really annoying to get right, let alone performant. So then the "single-use" property would come with a caveat, that it's only "single use" per replay cache instance, and some limited number of replays become possible. Can you say more about how you envision your proposal working for these distributed environments? In a more general sense, it's starting to seem like we should consider the spectrum from "actually no replays possible" to "some small number of replays possible [on the order of the number of machines sharing the session ticket key]" and ending at "nearly unlimited (millions+) of replays possible". I think avoiding the last case is a reasonable goal, but I'm as-yet unconvinced that the first case is achievable. Perhaps the middle ground is good enough... -Ben --------------040905020606050501030604 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 03/25/2016 02:41 PM, Colm MacCrthaigh wrote:
On Fri, Mar 25, 2016 at 12:02 PM, Karthik Bhargavan <karthikeyan.bhargavan@inria.fr> wrote:
> +1 but I think we can go further here and specify 0RTT in such a way that it only works when the server maintains state, and so that any given 0RTT ticket may only be used once (to preserve forward secrecy as much as possible within the constrains of 0RTT).

Do you envision clients only having one resumption handshake at a time? I was under the impression that TLS 1.2 clients typically open multiple
resumption handshakes in parallel, and that TLS 1.3 clients would want to do the same.

It is common for existing clients to re-use the same ticket for many connections. This is at-odds with forward secrecy though :/ Clients could have many resumption tokens at a time though; e.g. they could ask for 10 and use each one once. It's just that each token is used once. So parallel resumptions could be supported.


I understand there are good reasons to want to make the default behavior of a single-physical-server TLS server as secure as possible, but I think it's also well-understood that the more "exciting" portions of 0-RTT happen in a distributed setup, where there are different physical (well, maybe virtual) machines sharing a session ticket key, potentially in different data centers. I don't think we've seen a real description of how this proposal for "single-use" session tickets would behave in the distributed setup yet. Are you proposing to require a distributed replay cache shared by all machines sharing the session-ticket key? I expect a lot of pushback from operators in that case, since distributed replay caches are really annoying to get right, let alone performant. So then the "single-use" property would come with a caveat, that it's only "single use" per replay cache instance, and some limited number of replays become possible.

Can you say more about how you envision your proposal working for these distributed environments?


In a more general sense, it's starting to seem like we should consider the spectrum from "actually no replays possible" to "some small number of replays possible [on the order of the number of machines sharing the session ticket key]" and ending at "nearly unlimited (millions+) of replays possible". I think avoiding the last case is a reasonable goal, but I'm as-yet unconvinced that the first case is achievable. Perhaps the middle ground is good enough...

-Ben
--------------040905020606050501030604-- From nobody Mon Mar 28 10:13:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CDD12DC0A for ; Mon, 28 Mar 2016 10:13:35 -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=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 HK68VdrQL6iS for ; Mon, 28 Mar 2016 10:13:30 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F3FA12DBED for ; Mon, 28 Mar 2016 10:13:30 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id s5so120516574qkd.0 for ; Mon, 28 Mar 2016 10:13:30 -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:date:message-id:subject:from:to :cc; bh=4Mu4QGAy1CAY7xUXAAmFiCoynmWxxU3yBqRuLnN9Hqk=; b=m7cQSiMQbadn4MgLZ9mlS9zmAN5OnKSFyZBSQlb4r5E9UJTPDR+1M5c3lszKKxaDzj ckRaZ2D8/2NMieu7yDetDtKgBkHNVbWPv1iIr9nNLvD/D1Um80lSbH44gC1S9iwnaN+F YKwLllPZua/bYUh7oPLCgcFIpq9wP7HVDJvs3Hq++xFRwQh977wR9r4IWt7PPvNkk2YI ulhDMMTzPV0I4NbrNRyC1shH6AzLXwxeModXqXvE2+6+4bqRRtPoe6CCUi4GRoF9OpsV fl91m8+hTVjDHXxwoGvayCatqQ9qzuC298jkxM2ttuxg/mIZMTf0usVQMiUuJnkdtUTF foqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4Mu4QGAy1CAY7xUXAAmFiCoynmWxxU3yBqRuLnN9Hqk=; b=MZXmZxOMMXr1S6f8pkpVdtIjTNIWwkEdQYzNt+oK1+oPsI8OY3bVZp6bZxh8Wt0l6h Cb/Aey+jKQwKMVm5XaSiSpdLqiwTr/RLWBUS9d0s4FHelMSDoELOANGrYqOv4nsysrsO NfR/PfTae898M7np7unp29lCaVQaq5Y/xK4KbbvlmrODSD+oP4KHLIDTit4nQxwHIGqR Hseyj5594JEdVghRfma/0bfW8qg0s1xHxYs2iHfDL6+VMxTICulzyVSadYYBLR49+FNa t1++fKqLEDxBbv4cgB/A6NUMsxCQl1j0zzfxQnp74fb8iSnO70QOz5Fu0G5Fc3CQNhFP OjOg== X-Gm-Message-State: AD7BkJIijdjqQ7QfqxFfeiPFMFjwd6dOH9zdm7ytpTAXS5D8/ylQ85NZqAnU44uT1+4qlLzQJhdHvqQHXBIERA== MIME-Version: 1.0 X-Received: by 10.13.252.197 with SMTP id m188mr14043171ywf.281.1459185209595; Mon, 28 Mar 2016 10:13:29 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Mon, 28 Mar 2016 10:13:29 -0700 (PDT) In-Reply-To: <56F95797.2070206@akamai.com> References: <4B85487A-850B-4347-80A7-A3A4D92593E6@inria.fr> <56F95797.2070206@akamai.com> Date: Mon, 28 Mar 2016 10:13:29 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c06c2401493af052f1f08cf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Cleaning up 0-RTT Signaling (ciphersuites, replays, PSK context) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:13:36 -0000 --94eb2c06c2401493af052f1f08cf Content-Type: text/plain; charset=UTF-8 On Mon, Mar 28, 2016 at 9:11 AM, Benjamin Kaduk wrote: > > I understand there are good reasons to want to make the default behavior > of a single-physical-server TLS server as secure as possible, but I think > it's also well-understood that the more "exciting" portions of 0-RTT happen > in a distributed setup, where there are different physical (well, maybe > virtual) machines sharing a session ticket key, potentially in different > data centers. I don't think we've seen a real description of how this > proposal for "single-use" session tickets would behave in the distributed > setup yet. Are you proposing to require a distributed replay cache shared > by all machines sharing the session-ticket key? I expect a lot of pushback > from operators in that case, since distributed replay caches are really > annoying to get right, let alone performant. So then the "single-use" > property would come with a caveat, that it's only "single use" per replay > cache instance, and some limited number of replays become possible. > > Can you say more about how you envision your proposal working for these > distributed environments? > > In a more general sense, it's starting to seem like we should consider the > spectrum from "actually no replays possible" to "some small number of > replays possible [on the order of the number of machines sharing the > session ticket key]" and ending at "nearly unlimited (millions+) of replays > possible". I think avoiding the last case is a reasonable goal, but I'm > as-yet unconvinced that the first case is achievable. Perhaps the middle > ground is good enough... > I've come to the same conclusion: I don't think it's possible to eliminate all possibility of replay - but it is possible to reduce it to a small window, and I think there are pragmatic design steps that can be made that reduce the idempotency risks too. I'm working on a small write-up now; will send out later today. -- Colm --94eb2c06c2401493af052f1f08cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 28, 2016 at 9:11 AM, Benjamin Kaduk <<= a href=3D"mailto:bkaduk@akamai.com" target=3D"_blank">bkaduk@akamai.com= > wrote:
I understand there are good reasons to want to make the default behavior of a single-physical-server TLS server as secure as possible, but I think it's also well-understood that the more "exciting" portions of 0-RTT happen in a distributed setup, w= here there are different physical (well, maybe virtual) machines sharing a session ticket key, potentially in different data centers.=C2=A0 I don't think we've seen a real description of how this proposal = for "single-use" session tickets would behave in the distributed = setup yet.=C2=A0 Are you proposing to require a distributed replay cache shar= ed by all machines sharing the session-ticket key?=C2=A0 I expect a lot of pushback from operators in that case, since distributed replay caches are really annoying to get right, let alone performant.=C2=A0 So then the "single-use" property would come with a caveat, that= it's only "single use" per replay cache instance, and some limited= number of replays become possible.

Can you say more about how you envision your proposal working for these distributed environments?

In a more general sense, it's starting to seem like we should consider the spectrum from "actually no replays possible" to = "some small number of replays possible [on the order of the number of machines sharing the session ticket key]" and ending at "near= ly unlimited (millions+) of replays possible".=C2=A0 I think avoiding= the last case is a reasonable goal, but I'm as-yet unconvinced that the first case is achievable. Perhaps the middle ground is good enough...

I've come to th= e same conclusion: I don't think it's possible to eliminate all pos= sibility of replay - but it is possible to reduce it to a small window, and= I think there are pragmatic design steps that can be made that reduce the = idempotency risks too. I'm working on a small write-up now; will send o= ut later today.=C2=A0


--
= Colm
--94eb2c06c2401493af052f1f08cf-- From nobody Mon Mar 28 11:55:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95712DC45 for ; Mon, 28 Mar 2016 11:55: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Zh4ZhzOMR3rq for ; Mon, 28 Mar 2016 11:55:33 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5540812DC48 for ; Mon, 28 Mar 2016 11:55:33 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id i4so85672633qkc.3 for ; Mon, 28 Mar 2016 11:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:date:message-id:subject:from:to; bh=AWxqrgwHyi0z+lYW80PrZi2kJppi9EeySm9/gTM6Mkc=; b=Nnbi7vQ+efUnUqQFFPsOuLPxIGyHMb+zcaHlxX2Kg+z0M0bAxPINsEOa4bstOVjhvf JUcFs75FAG6XfANc1/OOZpSfZJteroCIvTusCyviAaPV/MQTXOzyU3KOKMvNKGH4o5GU tQZ0bUb/kKc5gndLllAA384xaQg8T5SpftMMoWccgrcj2yR/Uho24QWTMRoSIYPOerpR bm9hJW02+n/KoWIaqNuCOz9wnCumylXp5krPMVGCsEJVMJcXA5w5Z2t1iZmvFlUku1vv mO8n04EJOAzx6wUeYKkuk5e5Gux/KnHHQuWMo1P8jCwTq2MqchHNbCqzf5e4W061HbKZ LfFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=AWxqrgwHyi0z+lYW80PrZi2kJppi9EeySm9/gTM6Mkc=; b=eAYVBhXdQU0LCa8dBNHBUrOibKtyGmbDzxiv/HI7EuZLCixoRySGi+zYgWnZH+mYaw KUn4kzA7sZaDBAiLPf7VjBfugrCQTfQycduVt+5FHnAwgadCnDYiIfCpWM00PA5/tfHw wOBi3GDQ19HaiYmQzd4e4mEqy7/O96B3ipl0qsXokXjstTq3Y4svrKjKsnw2R5/77S1i mUk4v539eFFivIhLhxAacU9InmOAnklrow/JI1bV7GCgRB0BWQrIiPHQKQ5QR+QbIaxJ lDhF9K50cog9Ai7SvNtCOSEObaHzUaV0qD106o+M3YniCXE5LeW1dJB4YobGXI3fxxUD HzCQ== X-Gm-Message-State: AD7BkJLlpCFaz0rWFwUqVvnGhMH01S3ez/MvW52HWcjfPv1U8JnK+A4/LiQjfrjgJ14WHtGTWepkegc4L90OSw== MIME-Version: 1.0 X-Received: by 10.37.78.193 with SMTP id c184mr13878014ybb.155.1459191332318; Mon, 28 Mar 2016 11:55:32 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Mon, 28 Mar 2016 11:55:32 -0700 (PDT) Date: Mon, 28 Mar 2016 11:55:32 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11467ba6063c4a052f2075f1 Archived-At: Subject: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:55:41 -0000 --001a11467ba6063c4a052f2075f1 Content-Type: text/plain; charset=UTF-8 Over the past week or so I've sent a few messages here on 0RTT but I've been muddling together some separate concerns, and I'd like to split them apart and treat them separately, with some concrete suggestions. *Resumption and Forward Secrecy* One of the reasons I'm excited about TLS1.3 is the prospect of greater deployment of forward secrecy. Compromise of a credential - like an RSA or ECDSA key - shouldn't crack open a trove of collected data. But a pitfall here has been session tickets and session caches. If an attacker compromises a session ticket encryption key, they can decrypt any sessions encrypted which used that key. If an attacker compromises a session cache, they can decrypt any sessions contained in the cache. In the real world: the former is much worse than the latter. A cache is bounded in size and capacity and has real cost associated with storing entries; it's also more likely to be sharded with "local" caches relying on routing affinity. On the other hand it is cheap and convenient to use a single session ticket encryption key. Widely deployed software (e.g. Apache, nginx ... ) has poor support for key rotation - for example no schedule for rotating keys, no tracking how many times each key is used, no support for multiple keys overlapping in time. It is not surprising to see configurations where the same ticket encryption key has been in use for years; outlasting RSA key lifetimes. Put bluntly; session tickets as deployed in the real world defeat the point of forward secrecy. A compromise of a single credential loads to a catastrophic loss in security for previously collected sessions. Worse of all: users have no way to audit how these keys are being managed. At least it's possible to observe how long an RSA/ECDSA key is in use. An alternative way to go is to restructure session resumption as single-use session resumption IDs. Here's how it would work: * TLS client asks server for 1 ... N session resumption IDs. Both the client and server iterate their PRF/KDFs N times ... deriving the same keys (without exchanging them). The server then nominates N small (e.g. 8 byte) IDs for each set of resumption state. * Each ID is valid for use on a future connection. TLS clients are advised that they MUST use each ID just once; discarding and erasing it upon use during the resumption handshake. Now this balloons the already-costly cost of session caches; by a factor of N. And strangely, that's the point - it structures things so that the cache implementor is incentivized to evict and replace entries. With eviction in place; the regular security model of TLS is also restored. A compromise of the cache only puts future connections at risk, and future connections are generally always at risk due to server compromise. I've built and operated a large CDN, and we use tickets (though we rotate the keys!), and it would be an increase in costs to implement a session cache, though I'd guess it's manageable. But that does suck. My argument here is squarely user-security-centric; TLS tickets are a dangerous sharp edge that implementors keep screwing up. I think they should be blunted, even at the expense of increasing costs for people like me. One might reasonably say that this cost is too much, that forward secrecy isn't worth losing tickets (which are cheap) over. But then, if we are willing to sacrifice FS, why not go back to just encrypting using the server key? that's a lot simpler. And that's how 0RTT is defined, which brings me to ... *0RTT and Safety* 0-RTT had the potential to lower the latency for a lot of web users; which is an awesome goal. Though I'd like to point out that the benefits don't look that great to me compared to keeping connections alive for very long periods of time: Despite the name 0RTT still requires 1RTT (the TCP SYN -> SYN|ACK exchange) before any data can be sent. A long-lived connection doesn't have this problem : and in response to web sockets, IOT, and other shifts, the technology to keep millions of connections open for long periods of times on the server side (and even move live connections between machines) is improving, along with long-lived connection battery-conserving improvements for mobile. A connection that you keep open is "really" 0RTT; the socket is primed for immediate I/O. I see at least three different challenges with 0RTT as defined. The first is a general and high level one: we seem to willing to accept a "lower" level of security for 0RTT data (e.g. no FS, even if the rest of the session has it). Why? What is it we think is special about this data that it is "less" worth protecting? surely there are very sensitive things in urls, surely there are potential oracles and other things in there too? It just seems super strange to me. The second challenge is that the replayability of the 0RTT poses a cryptographic safety challenge. Take Lucky13 - which is a brilliant attack and is stunningly effective against DTLS because it is so easy to replay over and over; barely needing to change any parameters - and let the server do the work. 0RTT looks very similar. It doesn't seem wise to let cipher text manipulators take as many cracks at the whip as they'd like. The third challenge is that the 0RTT plaintext data itself may not be safe to replay; that is that it might trigger some kind of non-idempotent action. Idempotence is really really hard, it isn't safe to simply plug in a replayable section to existing protocols. There's also a huge difference between being tolerant to a small number of replays, and a large unbounded number. For example: a large unbounded number may be used to generate DOS attacks against throttles and quotas. *Tying things together* Short of some kind of transactional locking protocol during TLS handshakes, I don't think there is a scheme that can perfectly prevent replay. Bill Cox' analysis is a really good one here. But I'd like to observe that the sort of single-use-session-id cache outlined above has a nice property that it makes for a sort of strike register. Since the server-side implementor is incentivized to evict entries, or at least mark them as used, so that the slot is available for re-use; that can be doubled-up as a "we've seen this already" signal. This reduces the replay window to the time period for that signal to propagate (e.g. for an eviction to happen from the cache). So 0RTT data could be encrypted under the resumption session id. That creates the challenge that the session might not be there any more, so the server may not be able to decrypt the 0RTT data. I actually think this is a plus, and lines up with a separate important change I think is necessary - the 0RTT data shouldn't be application data. It should be a separate, optional, stream. I find it helpful to think of it as a hint, so it could be called "replayable_hint". Instead of breaking apart an existing protocol and putting some of it in the early data and some in the application data transparently (a disaster in waiting), the client and server would have to formally agree on the kind of data that could be in a "replayable_hint". This goes a long way to mitigating many protocol level idempotency concerns, and has no impact on the kind of pre-fetching people want to do for HTTP and other protocols. At a bare minimum, I think we should make this change. Lastly, and this is a little crazy but I haven't let that stop me before ... to guard against the smaller replay window and idempotency problems at the application levels,clients should occasionally send duplicate and unrelated hints, just opportunistically. This keeps the server side application "on notice" that that kind of craziness can occur, and better to have it happen a little all of the time in a controlled way, than rarely by attackers. *Summary* A common theme in the above is that it makes things more expensive for server-side implementors, and that sucks - but I don't see another way to avoid some of the pitfalls here; and I'm unhappy with the state of tickets today. If I'm on my own on that, I'd be interested in what kinds of data people might kind convincing. My own impressions come from being an Apache httpd developer and assisting people with configurations and running workshops at conferences. It's not scientific, but the prevalence of non-rotation is so severe in my sample set that I'm convinced it's the norm. -- Colm --001a11467ba6063c4a052f2075f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Over the past week or so I've sent a few messages= here on 0RTT but I've been muddling together some separate concerns, a= nd I'd like to split them apart and treat them separately, with some co= ncrete suggestions.=C2=A0

Resumption and Forwar= d Secrecy
One of the reasons I'm excited about TLS1.3= is the prospect of greater deployment of forward secrecy. Compromise of a = credential - like an RSA or ECDSA key - shouldn't crack open a trove of= collected data. But a pitfall here has been session tickets and session ca= ches.=C2=A0

If an attacker compromises a session t= icket encryption key, they can decrypt any sessions encrypted which used th= at key. If an attacker compromises a session cache, they can decrypt any se= ssions contained in the cache.=C2=A0 In the real world: the former is much = worse than the latter. A cache is bounded in size and capacity and has real= cost associated with storing entries; it's also more likely to be shar= ded with "local" caches relying on routing affinity.=C2=A0 On the= other hand it is cheap and convenient to use a single session ticket encry= ption key. Widely deployed software (e.g. Apache, nginx ... ) has poor supp= ort for key rotation - for example no schedule for rotating keys, no tracki= ng how many times each key is used, no support for multiple keys overlappin= g in time. It is not surprising to see configurations where the same ticket= encryption key has been in use for years; outlasting RSA key lifetimes.=C2= =A0

Put bluntly; session tickets as deployed in th= e real world defeat the point of forward secrecy. A compromise of a single = credential loads to a catastrophic loss in security for previously collecte= d sessions. Worse of all: users have no way to audit how these keys are bei= ng managed. At least it's possible to observe how long an RSA/ECDSA key= is in use.=C2=A0

An alternative way to go is to r= estructure session resumption as single-use session resumption IDs. Here= 9;s how it would work:

* TLS client asks server fo= r 1 ... N session resumption IDs.=C2=A0 Both the client and server iterate = their PRF/KDFs N times ... deriving the same keys (without exchanging them)= . The server then nominates N small (e.g. 8 byte) IDs for each set of resum= ption state.=C2=A0

* Each ID is valid for use on a= future connection. TLS clients are advised that they MUST use each ID just= once; discarding and erasing it upon use during the resumption handshake.= =C2=A0

Now this balloons the already-costly cost o= f session caches; by a factor of N. And strangely, that's the point - i= t structures things so that the cache implementor is incentivized to evict = and replace entries. With eviction in place; the regular security model of = TLS is also restored. A compromise of the cache only puts future connection= s at risk, and future connections are generally always at risk due to serve= r compromise. =C2=A0

I've built and operated a= large CDN, and we use tickets (though we rotate the keys!), and it would b= e an increase in costs to implement a session cache, though I'd guess i= t's manageable. But that does suck. My argument here is squarely user-s= ecurity-centric; =C2=A0TLS tickets are a dangerous sharp edge that implemen= tors keep screwing up. I think they should be blunted, even at the expense = of increasing costs for people like me. =C2=A0

One= might reasonably say that this cost is too much, that forward secrecy isn&= #39;t worth losing tickets (which are cheap) over. But then, if we are will= ing to sacrifice FS, why not go back to just encrypting using the server ke= y? that's a lot simpler. And that's how 0RTT is defined, =C2=A0whic= h brings me to ...

0RTT and Safety
0-RTT had the potential to lower the latency for a lot of web users; whic= h is an awesome goal. Though I'd like to point out that the benefits do= n't look that great to me compared to keeping connections alive for ver= y long periods of time: =C2=A0Despite the name 0RTT still requires 1RTT (th= e TCP SYN -> SYN|ACK exchange) before any data can be sent. A long-lived= connection doesn't have this problem : and in response to web sockets,= IOT, and other shifts, the technology to keep millions of connections open= for long periods of times on the server side (and even move live connectio= ns between machines) is improving, along with long-lived connection battery= -conserving improvements for mobile. A connection that you keep open is &qu= ot;really" 0RTT; the socket is primed for immediate I/O.=C2=A0

I see at least three different challenges with 0RTT a= s defined. The first is a general and high level one: we seem to willing to= accept a "lower" level of security for 0RTT data (e.g. no FS, ev= en if the rest of the session has it). Why? What is it we think is special = about this data that it is "less" worth protecting? surely there = are very sensitive things in urls, surely there are potential oracles and o= ther things in there too? It just seems super strange to me.=C2=A0

The second challenge is that the replayability of the 0RTT= poses a cryptographic safety challenge. Take Lucky13 - which is a brillian= t attack and is stunningly effective against DTLS because it is so easy to = replay over and over; barely needing to change any parameters - and let the= server do the work. 0RTT looks very similar. It doesn't seem wise to l= et cipher text manipulators take as many cracks at the whip as they'd l= ike.=C2=A0

The third challenge is that the 0RTT pl= aintext data itself may not be safe to replay; that is that it might trigge= r some kind of non-idempotent action. Idempotence is really really hard, it= isn't safe to simply plug in a replayable section to existing protocol= s. There's also a huge difference between being tolerant to a small num= ber of replays, and a large unbounded number. For example: a large unbounde= d number may be used to generate DOS attacks against =C2=A0throttles and qu= otas.=C2=A0

Tying things together
=
Short of some kind of transactional locking protocol during TLS handsh= akes, I don't think there is a scheme that can perfectly prevent replay= . Bill Cox' analysis is a really good one here. But I'd like to obs= erve that the sort of single-use-session-id cache outlined above has a nice= property that it makes for a sort of strike register. Since the server-sid= e implementor is incentivized to evict entries, or at least mark them as us= ed, so that the slot is available for re-use; that can be doubled-up as a &= quot;we've seen this already" signal. This reduces the replay wind= ow to the time period for that signal to propagate (e.g. for an eviction to= happen from the cache).=C2=A0

So 0RTT data could = be encrypted under the resumption session id. That creates the challenge th= at the session might not be there any more, so the server may not be able t= o decrypt the 0RTT data. I actually think this is a plus, and lines up with= a separate important change I think is necessary - the 0RTT data shouldn&#= 39;t be application data. It should be a separate, optional, stream. I find= it helpful to think of it as a hint, so it could be called "replayabl= e_hint". Instead of breaking apart an existing protocol and putting so= me of it in the early data and some in the application data transparently (= a disaster in waiting), the client and server would have to formally agree = on the kind of data that could be in a "replayable_hint". This go= es a long way to mitigating many protocol level idempotency concerns, and h= as no impact on the kind of pre-fetching people want to do for HTTP and oth= er protocols. At a bare minimum, I think we should make this change.=C2=A0<= /div>

Lastly, and this is a little crazy but I haven'= ;t let that stop me before ... to guard against the smaller replay window a= nd idempotency problems at the application levels,clients should occasional= ly send duplicate and unrelated hints, just opportunistically. This keeps t= he server side application "on notice" that that kind of crazines= s can occur, and better to have it happen a little all of the time in a con= trolled way, than rarely by attackers. =C2=A0

Summary
A common theme in the above is that it makes thin= gs more expensive for server-side implementors, and that sucks - but I don&= #39;t see another way to avoid some of the pitfalls here; and I'm unhap= py with the state of tickets today. If I'm on my own on that, I'd b= e interested in what kinds of data people might kind convincing. My own imp= ressions come from being an Apache httpd developer and assisting people wit= h configurations and running workshops at conferences. It's not scienti= fic, but the prevalence of non-rotation is so severe in my sample set that = I'm convinced it's the norm.=C2=A0

--=C2= =A0
Colm
--001a11467ba6063c4a052f2075f1-- From nobody Mon Mar 28 13:06:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB12512D871 for ; Mon, 28 Mar 2016 13:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2bXeBt2bCaC7 for ; Mon, 28 Mar 2016 13:06:08 -0700 (PDT) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E38C12DB30 for ; Mon, 28 Mar 2016 12:58:29 -0700 (PDT) Received: by mail-ig0-x231.google.com with SMTP id av4so61019569igc.1 for ; Mon, 28 Mar 2016 12:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=D+i9AkR8A3Vng8LhnOkvDpcOcq0U5B05nA382ME2zC8=; b=wzp3FCG6zk+AHt4ACHJeyAI3qU85KbYpetZT1h5zP1rOfoUr8vm8e4UFWIqATmUoeV 0nveqPFJjdgkkDNd8AzpenDbFg11mEDKcCPzMonUT9X/00gZ3scnqvnsFxqSCBAqLN8a 0fsvqNMEWiSItkIKssMfeagOL6OO2oGPp3r/8aSMhCEZ+xmVGZ54HFrS36A/EMOcbfj6 TjRtoBFn5E0Hgj/JeAS1poM9IeTOUNaRTNqJkKbWjrszZsleUGTcRaSHvdusRJGXZ3Oc EzO4l6J1yJwuSeaJqz1VZ7vemMglVZ7dOC9lKAmxy3LQarnnfRF2Ucb+AF2CwL18ww6r 2Dbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=D+i9AkR8A3Vng8LhnOkvDpcOcq0U5B05nA382ME2zC8=; b=EaGuXrhLMty/LXfUtYdoxN8622UxXp6h/CDp05dqJ6KzkPJQeiQuCugL7d+YVf75hL MwwtxLjcvHauazRoNiQRhYMG2swrgdawOhwY9CDAFysBXti5Zka9ucCNbkPse6LqviEE KvAwjz7A4zsWXJSEYJJnIZlQhnwWXGrpXke8lXUwjFy7xPXK0zaOX77pEJ76xtwlLUY/ yPMzGHLZp+wl7AhF6Cd3ilVB9DSxi+rq2/sStbGGTNqBbaL5PvbTlpAS5R4RST7vjs2k Bbg2LhhNdmv68REt/yRmMdgeE8UJ67TYrmDSbeYZ6GAI69bmOY4rlNrbpCBt9Ie+oAt5 wxwA== X-Gm-Message-State: AD7BkJIluqrvF/j37Z269Dqi1cdHSVHodcyDoYcWVScdxbkmZgbu1xJgFubsdXhDMWpP23fqEVGrP5ZqwxI01g== MIME-Version: 1.0 X-Received: by 10.50.18.113 with SMTP id v17mr11710261igd.2.1459195108738; Mon, 28 Mar 2016 12:58:28 -0700 (PDT) Received: by 10.36.132.4 with HTTP; Mon, 28 Mar 2016 12:58:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 28 Mar 2016 12:58:28 -0700 Message-ID: From: Tony Arcieri To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: multipart/alternative; boundary=089e01494ff21d7c7e052f215637 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:06:10 -0000 --089e01494ff21d7c7e052f215637 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 28, 2016, Colm MacC=C3=A1rthaigh wrote= : > A long-lived connection doesn't have this problem : and in response to we= b > sockets, IOT, and other shifts, the technology to keep millions of > connections open for long periods of times on the server side (and even > move live connections between machines) is improving, along with long-liv= ed > connection battery-conserving improvements for mobile. > Mobile phones users constantly lose network connectivity and make up an increasingly growing majority of Internet clients. MPTCP is great but the reality is mobile network deployment isn't ubiquitous on planet earth and mobile clients constantly go offline and back online several times throughout a day on average. --=20 Tony Arcieri --089e01494ff21d7c7e052f215637 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, March 28, 2016, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
A long-lived connection doesn't have this= problem : and in response to web sockets, IOT, and other shifts, the techn= ology to keep millions of connections open for long periods of times on the= server side (and even move live connections between machines) is improving= , along with long-lived connection battery-conserving improvements for mobi= le.

Mobile phones users constan= tly lose network connectivity and make up an increasingly growing=C2=A0=C2= =A0majority of Internet clients. MPTCP is great but the reality is mobile n= etwork=C2=A0deployment isn't ubiquitous on planet earth an= d mobile clients constantly go offline and back online several times throug= hout a day on average.


--
Tony Arcieri

--089e01494ff21d7c7e052f215637-- From nobody Mon Mar 28 13:31:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40212DBE9 for ; Mon, 28 Mar 2016 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs4jDEOvQBBz for ; Mon, 28 Mar 2016 13:31:42 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A240A12D501 for ; Mon, 28 Mar 2016 13:31:10 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id p65so111390798wmp.0 for ; Mon, 28 Mar 2016 13:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ws+aQ5I2Dr0UWEmfmPC+mEOBiYZWPmRf9RJAPEpCBHc=; b=XgyMtfmWD8QEwYufNeGCK9yOwzxwvgveJGbBI7L5px6em5dtCBA+54B3WOYrXEYJMY WS/1YupxTpJujm4FdhDWbTHTRxbcC1oLaNhZhcP3vX9to/O9F6D5PxKGHVjs88VQ8A8R QlPm8nMdF8HwcULsBTkig8VVBVisqlOG56uh96YM18L7ag06RINz+U3wufs6mKsIoc4K PTuXqEjXsigkO9q6L9UGMjNc/yQUSCC3713ihaYXXgLoNOisjPRA8DFr36Jy38LHRiOJ 4ypuU+6Xw2UaQ2+559d6SFlKVcuwiDrD52EAl9nmUkIc1SiPk3TdkCN2pXUbMMvgDZgv e4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ws+aQ5I2Dr0UWEmfmPC+mEOBiYZWPmRf9RJAPEpCBHc=; b=l/ZamqVIONa07Xr64cehVt36ARP7HDR5WdbwN1V0/8qWoK5NCXDHdIvSjgOnAtNcdo P7WEAQhZhyOdv2DiIh1P0+jFCGJS5Rb+9PB6NSPMinScVE06Mz7DHi5yW6Mr2Bo/STP9 BiXaulMhVXNfrZxSNp4fT4ndpURIN+YofS1ugcK6KE6VlkA7h3Orr4bzq4M7REirPWhB H+QFRdbNybxMsZiEHzcCRqgHTQsWkrB+XxFoyrNApnUuOTjEQAONunxDSzrnIfthohh2 AQe/9m9KF6j2FxP+2a2tgNPWWoPHlead5VtY3FFCXUUrCSLlhmOtcInrYzRkVQaYp6go JkgQ== X-Gm-Message-State: AD7BkJIlyX2VGdEolDO93zNTo5dMhL1vftnAkWteAIi2Anx/VVAto0CS6PAeKX7TER7Ifg== X-Received: by 10.194.9.201 with SMTP id c9mr14660496wjb.47.1459197069201; Mon, 28 Mar 2016 13:31:09 -0700 (PDT) Received: from [192.168.0.51] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id s66sm11627846wmb.6.2016.03.28.13.31.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Mar 2016 13:31:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_73BC8236-D4E5-4372-997D-C674598B9B72" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Mon, 28 Mar 2016 22:31:07 +0200 Message-Id: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> References: To: =?utf-8?Q?Colm_MacC=C3=A1rthaigh?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:31:45 -0000 --Apple-Mail=_73BC8236-D4E5-4372-997D-C674598B9B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let me try to understand the concerns here. > Resumption and Forward Secrecy PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes? This is already better than TLS 1.2 where we had no way to do = forward-secret resumption. In that case, the concern is mainly for 0-RTT, which I agree is harder = to get right. > 0RTT and Safety > I see at least three different challenges with 0RTT as defined. The = first is a general and high level one: we seem to willing to accept a = "lower" level of security for 0RTT data (e.g. no FS, even if the rest of = the session has it). Why? What is it we think is special about this data = that it is "less" worth protecting? surely there are very sensitive = things in urls, surely there are potential oracles and other things in = there too? It just seems super strange to me.=20 I wonder if the QUIC folks have an answer to this question? It would be = good to gather =E2=80=9Ctypical=E2=80=9D intended use cases of 0-RTT = data. In any case, it is good to distinguish this forward secrecy concern from = replay, because secrecy is in the control of the client, who can choose = to send or not send sensitive data, but replay detection is in the hands = of the server. > The second challenge is that the replayability of the 0RTT poses a = cryptographic safety challenge. Take Lucky13 - which is a brilliant = attack and is stunningly effective against DTLS because it is so easy to = replay over and over; barely needing to change any parameters - and let = the server do the work. 0RTT looks very similar. It doesn't seem wise to = let cipher text manipulators take as many cracks at the whip as they'd = like.=20 > The third challenge is that the 0RTT plaintext data itself may not be = safe to replay; that is that it might trigger some kind of = non-idempotent action. Idempotence is really really hard, it isn't safe = to simply plug in a replayable section to existing protocols. There's = also a huge difference between being tolerant to a small number of = replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against throttles and = quotas.=20 Yes, detecting and preventing replays by default would be good. However, I wouldn=E2=80=99t tie this in with the session mechanism.=20 Wouldn=E2=80=99t we want to prevent replay of DH 0-RTT requests? Best, Karthik >=20 > The third challenge is that the 0RTT plaintext data itself may not be = safe to replay; that is that it might trigger some kind of = non-idempotent action. Idempotence is really really hard, it isn't safe = to simply plug in a replayable section to existing protocols. There's = also a huge difference between being tolerant to a small number of = replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against throttles and = quotas.=20 >=20 > Tying things together > Short of some kind of transactional locking protocol during TLS = handshakes, I don't think there is a scheme that can perfectly prevent = replay. Bill Cox' analysis is a really good one here. But I'd like to = observe that the sort of single-use-session-id cache outlined above has = a nice property that it makes for a sort of strike register. Since the = server-side implementor is incentivized to evict entries, or at least = mark them as used, so that the slot is available for re-use; that can be = doubled-up as a "we've seen this already" signal. This reduces the = replay window to the time period for that signal to propagate (e.g. for = an eviction to happen from the cache).=20 >=20 > So 0RTT data could be encrypted under the resumption session id. That = creates the challenge that the session might not be there any more, so = the server may not be able to decrypt the 0RTT data. I actually think = this is a plus, and lines up with a separate important change I think is = necessary - the 0RTT data shouldn't be application data. It should be a = separate, optional, stream. I find it helpful to think of it as a hint, = so it could be called "replayable_hint". Instead of breaking apart an = existing protocol and putting some of it in the early data and some in = the application data transparently (a disaster in waiting), the client = and server would have to formally agree on the kind of data that could = be in a "replayable_hint". This goes a long way to mitigating many = protocol level idempotency concerns, and has no impact on the kind of = pre-fetching people want to do for HTTP and other protocols. At a bare = minimum, I think we should make this change.=20 >=20 > Lastly, and this is a little crazy but I haven't let that stop me = before ... to guard against the smaller replay window and idempotency = problems at the application levels,clients should occasionally send = duplicate and unrelated hints, just opportunistically. This keeps the = server side application "on notice" that that kind of craziness can = occur, and better to have it happen a little all of the time in a = controlled way, than rarely by attackers. =20 >=20 > Summary > A common theme in the above is that it makes things more expensive for = server-side implementors, and that sucks - but I don't see another way = to avoid some of the pitfalls here; and I'm unhappy with the state of = tickets today. If I'm on my own on that, I'd be interested in what kinds = of data people might kind convincing. My own impressions come from being = an Apache httpd developer and assisting people with configurations and = running workshops at conferences. It's not scientific, but the = prevalence of non-rotation is so severe in my sample set that I'm = convinced it's the norm.=20 >=20 > --=20 > Colm > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_73BC8236-D4E5-4372-997D-C674598B9B72 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Let me try to understand the concerns here.

Resumption and Forward Secrecy

PSK_ECDHE in TLS 1.3 does provide forward secrecy for = 1-RTT data, yes?
This is already better than TLS 1.2 where we = had no way to do forward-secret resumption.
In that case, the = concern is mainly for 0-RTT, which I agree is harder to get = right.

0RTT and = Safety
I see at least = three different challenges with 0RTT as defined. The first is a general = and high level one: we seem to willing to accept a "lower" level of = security for 0RTT data (e.g. no FS, even if the rest of the session has = it). Why? What is it we think is special about this data that it is = "less" worth protecting? surely there are very sensitive things in urls, = surely there are potential oracles and other things in there too? It = just seems super strange to me. 

I wonder if the QUIC folks have an answer to this = question? It would be good to gather =E2=80=9Ctypical=E2=80=9D intended = use cases of 0-RTT data.
In any case, it is good to = distinguish this forward secrecy concern from replay, because secrecy is = in the control of the client, who can choose to send or not send = sensitive data, but replay detection is in the hands of the = server.

The second challenge is that the = replayability of the 0RTT poses a cryptographic safety challenge. Take = Lucky13 - which is a brilliant attack and is stunningly effective = against DTLS because it is so easy to replay over and over; barely = needing to change any parameters - and let the server do the work. 0RTT = looks very similar. It doesn't seem wise to let cipher text manipulators = take as many cracks at the whip as they'd = like. 
The third = challenge is that the 0RTT plaintext data itself may not be safe to = replay; that is that it might trigger some kind of non-idempotent = action. Idempotence is really really hard, it isn't safe to simply plug = in a replayable section to existing protocols. There's also a huge = difference between being tolerant to a small number of replays, and a = large unbounded number. For example: a large unbounded number may be = used to generate DOS attacks against  throttles and = quotas. 

Yes, detecting and preventing = replays by default would be good.
However, I wouldn=E2=80=99t = tie this in with the session mechanism. 
Wouldn=E2=80=99t = we want to prevent replay of DH 0-RTT requests?

Best,
Karthik



The third challenge is that the 0RTT plaintext data itself = may not be safe to replay; that is that it might trigger some kind of = non-idempotent action. Idempotence is really really hard, it isn't safe = to simply plug in a replayable section to existing protocols. There's = also a huge difference between being tolerant to a small number of = replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against  throttles and = quotas. 

Tying things together
Short of some kind of transactional locking protocol during = TLS handshakes, I don't think there is a scheme that can perfectly = prevent replay. Bill Cox' analysis is a really good one here. But I'd = like to observe that the sort of single-use-session-id cache outlined = above has a nice property that it makes for a sort of strike register. = Since the server-side implementor is incentivized to evict entries, or = at least mark them as used, so that the slot is available for re-use; = that can be doubled-up as a "we've seen this already" signal. This = reduces the replay window to the time period for that signal to = propagate (e.g. for an eviction to happen from the = cache). 

So= 0RTT data could be encrypted under the resumption session id. That = creates the challenge that the session might not be there any more, so = the server may not be able to decrypt the 0RTT data. I actually think = this is a plus, and lines up with a separate important change I think is = necessary - the 0RTT data shouldn't be application data. It should be a = separate, optional, stream. I find it helpful to think of it as a hint, = so it could be called "replayable_hint". Instead of breaking apart an = existing protocol and putting some of it in the early data and some in = the application data transparently (a disaster in waiting), the client = and server would have to formally agree on the kind of data that could = be in a "replayable_hint". This goes a long way to mitigating many = protocol level idempotency concerns, and has no impact on the kind of = pre-fetching people want to do for HTTP and other protocols. At a bare = minimum, I think we should make this change. 

Lastly, and this is a = little crazy but I haven't let that stop me before ... to guard against = the smaller replay window and idempotency problems at the application = levels,clients should occasionally send duplicate and unrelated hints, = just opportunistically. This keeps the server side application "on = notice" that that kind of craziness can occur, and better to have it = happen a little all of the time in a controlled way, than rarely by = attackers.  

Summary
A common theme in the above is that it makes things more = expensive for server-side implementors, and that sucks - but I don't see = another way to avoid some of the pitfalls here; and I'm unhappy with the = state of tickets today. If I'm on my own on that, I'd be interested in = what kinds of data people might kind convincing. My own impressions come = from being an Apache httpd developer and assisting people with = configurations and running workshops at conferences. It's not = scientific, but the prevalence of non-rotation is so severe in my sample = set that I'm convinced it's the norm. 

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

= --Apple-Mail=_73BC8236-D4E5-4372-997D-C674598B9B72-- From nobody Mon Mar 28 13:39:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C669C12D1A0 for ; Mon, 28 Mar 2016 13:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CsetU6RpoV_R for ; Mon, 28 Mar 2016 13:39:05 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052E912D155 for ; Mon, 28 Mar 2016 13:39:05 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o6so129132613qkc.2 for ; Mon, 28 Mar 2016 13:39:04 -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:date:message-id:subject:from:to :cc; bh=qhQU/P6vHsvEul43ZRNpBbROSMXPPgkP5CajPp4Jnhs=; b=1tY8WQDCatViZIVgeKQitzA9J+GHQ4M9BqZxqhARx8VWt4/kN76cx6/R/5+TjM3nMb cwHgfUS4Qv/jdmp/u99Y36iTOnIc0ZY5vXtBGsyXbMHve+bJ0vNQjHnMqDBvOG5x2pTy 93bC7B8TlpX3Ii2dpvGf8RSEiZ71AZWb9k6ZibTU3t2V73IYl7FJZm2MkAoHr4v/y8Pc Ndxs8QJ/8Ev4f6371R+PTRxeGi9qO80u0TzYJ4KXKMPmtpofJvsIW5t2CxyQxk2ruWJ0 P/8D4/exn6Mqgps96qUxjtEWeyJdFDlATr2DQUDuGx9gNiLIpJspVDH83h48WPCu5JOL c/tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=qhQU/P6vHsvEul43ZRNpBbROSMXPPgkP5CajPp4Jnhs=; b=AvJcfR/PTTJ5NQtTEZ4CjI9oQpvBZ73LWVAqpqZH0FkhzTFNaeyBQRK1GYWqiiZQad 7wrI1d+bCZ5NRmsyjQuUkVmjAiS4bnBre0ezhnytynPhObOALIb2Ic0TPWP2hXZj6ngb ozwHR52Cjph0xDBhbF3//fyV97f4jdXW4TbfqLD4JRdGQjJyloe2ofqjViyC1Mza0cgX dX1XtcPzqIc4qwdTZ4MTiPt/ugB4PK69oODoM7D59aYaI64gBTf/4gnUlIaONdPyrqoa cwKkUsJeJtYUm5Ug7KIhy8rKWtRHqRogoT7Dmzafccv8FAphxprrmH47lqp4mi3Aspiu nZOQ== X-Gm-Message-State: AD7BkJJtR4L9aEcFKGtPuHuIgjdjNs6h9h9eBDxzp4P3+XLDjBXyouBb6mHprth2K25inuz9BxR5Qr4/WQOAhw== MIME-Version: 1.0 X-Received: by 10.37.88.215 with SMTP id m206mr14657209ybb.168.1459197544022; Mon, 28 Mar 2016 13:39:04 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Mon, 28 Mar 2016 13:39:03 -0700 (PDT) In-Reply-To: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> Date: Mon, 28 Mar 2016 13:39:03 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a113fcb7a451680052f21e73f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:39:07 -0000 --001a113fcb7a451680052f21e73f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2016 at 1:31 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > *Resumption and Forward Secrecy* > > > PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes? > This is already better than TLS 1.2 where we had no way to do > forward-secret resumption. > In that case, the concern is mainly for 0-RTT, which I agree is harder to > get right. > Yes ... and I left that out in the interests of clarity for the argument ... but I mean this scheme for the 0RTT data (hence the tying it together). I should have been more clear, thanks! > *0RTT and Safety* > > I see at least three different challenges with 0RTT as defined. The first > is a general and high level one: we seem to willing to accept a "lower" > level of security for 0RTT data (e.g. no FS, even if the rest of the > session has it). Why? What is it we think is special about this data that > it is "less" worth protecting? surely there are very sensitive things in > urls, surely there are potential oracles and other things in there too? I= t > just seems super strange to me. > > > I wonder if the QUIC folks have an answer to this question? It would be > good to gather =E2=80=9Ctypical=E2=80=9D intended use cases of 0-RTT data= . > In any case, it is good to distinguish this forward secrecy concern from > replay, because secrecy is in the control of the client, who can choose t= o > send or not send sensitive data, but replay detection is in the hands of > the server. > A lot falls out from replay. If there are side-channels in how the server handles the 0RTT section (and we can be certain that there will be) then the ability to replay the section greatly amplifies the attackers ability to use those side-channels to determine things about the data. Where the data is a url, which can contain things like passwords, session ids, and other bearer tokens, that's a bad combo. > Yes, detecting and preventing replays by default would be good. > However, I wouldn=E2=80=99t tie this in with the session mechanism. > Wouldn=E2=80=99t we want to prevent replay of DH 0-RTT requests? > I should be more clear: I mean to replace the DH 0-RTT part with 0-RTT parts that are encrypted under separate single-use PSK states. --=20 Colm --001a113fcb7a451680052f21e73f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 28, 2016 at 1:31 PM, Karthikeyan Bhargavan <kart= hik.bhargavan@gmail.com> wrote:
Resumption and Forward Secrecy

PSK_ECDHE in TLS 1.3 does provide = forward secrecy for 1-RTT data, yes?
This is already better than = TLS 1.2 where we had no way to do forward-secret resumption.
In t= hat case, the concern is mainly for 0-RTT, which I agree is harder to get r= ight.

Yes =C2=A0... and = =C2=A0I left that out in the interests of clarity for the argument ... but = I mean this scheme for the 0RTT data (hence the tying it together). I shoul= d have been more clear, thanks! =C2=A0
=C2=A0
0RTT and Safety
I = see at least three different challenges with 0RTT as defined. The first is = a general and high level one: we seem to willing to accept a "lower&qu= ot; level of security for 0RTT data (e.g. no FS, even if the rest of the se= ssion has it). Why? What is it we think is special about this data that it = is "less" worth protecting? surely there are very sensitive thing= s in urls, surely there are potential oracles and other things in there too= ? It just seems super strange to me.=C2=A0
I wonder if the QUIC folks have an answer to this questi= on? It would be good to gather =E2=80=9Ctypical=E2=80=9D intended use cases= of 0-RTT data.
In any case, it is good to distinguish this forwa= rd secrecy concern from replay, because secrecy is in the control of the cl= ient, who can choose to send or not send sensitive data, but replay detecti= on is in the hands of the server.
=
A lot falls out from replay. If there are side-channels in h= ow the server handles the 0RTT section (and we can be certain that there wi= ll be) then the ability to replay the section greatly amplifies the attacke= rs ability to use those side-channels to determine things about the data. W= here the data is a url, which can contain things like passwords, session id= s, and other bearer tokens, that's a bad combo. =C2=A0
=C2=A0=
Yes, detecting and preventing replays by default would be good= .
However, I wouldn=E2=80=99t tie this in with the session mechan= ism.=C2=A0
Wouldn=E2=80=99t we want to prevent replay of DH 0-RTT= requests?

I should= be more clear: I mean to replace the DH 0-RTT part with 0-RTT parts that a= re encrypted under separate single-use PSK states. =C2=A0
<= br>
--
Colm
--001a113fcb7a451680052f21e73f-- From nobody Mon Mar 28 14:04:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C7A12D145 for ; Mon, 28 Mar 2016 14:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 Fn_GX60MLHDq for ; Mon, 28 Mar 2016 14:04:44 -0700 (PDT) Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 544F112D0E1 for ; Mon, 28 Mar 2016 14:04:41 -0700 (PDT) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1akeKn-0003r8-FT; Mon, 28 Mar 2016 17:04:25 -0400 Date: Mon, 28 Mar 2016 14:04:20 -0700 From: Bill Frantz To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec793086f65a086d7dad2ba842be69b6fe23350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:04:46 -0000 On 3/28/16 at 11:55 AM, colm@allcosts.net (Colm MacC=C3=A1rthaigh) wrote: >surely there are very sensitive things in urls, A number of URLs include an authorization token which authorizes=20 access to a resource. This token is frequently a long=20 "unguessable" number. It must be kept secret. I think DropBox=20 URLs are one example. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345=20 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos,=20 CA 95032 From nobody Mon Mar 28 14:28:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A0F12D0C1 for ; Mon, 28 Mar 2016 14:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ztQS8G1A8jU6 for ; Mon, 28 Mar 2016 14:28:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0125.outbound.protection.outlook.com [207.46.100.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4A012D992 for ; Mon, 28 Mar 2016 14:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7FVV2KyQPPb9CjgybDXnWL9zUgtyYCbHHTB8wKBHp0A=; b=NVgBbS8os0r4zLqiN0+tqAaS13YFkCEeZO99UHSyiAavOJQmwYdFgqsGEkNGSrrxxHXO+h64cgwNJqaca1wUfLX1prZR/Y3KRbryCFpc2BlfB91o+H9OZseO5iea2SPhwwAlArNdx7IG5K/9iz8l2MFvTPadCA27/ElemOlritE= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.434.16; Mon, 28 Mar 2016 21:28:14 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Mon, 28 Mar 2016 21:28:13 +0000 From: Andrei Popov To: "karthik@messengeruser.com" , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= Thread-Topic: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety Thread-Index: AQHRiSN2YMohgneox0CkzrCuSxAXNJ9vTzyAgAANb+A= Date: Mon, 28 Mar 2016 21:28:13 +0000 Message-ID: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> In-Reply-To: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: 1cd9a400-8261-49b9-1ca4-08d3574fdeb6 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:gmzqM119Ji0GpvWbL6BLyVR6kL7oWXDtvG6fgxhkYPZKJlUMkCTXRanmxC7SPPnNislQjckJt4Icsg09xL21SLgp5zfilVct0B3JmRGV2YIGkAkWWPROFSh5ienVzP6QothbHCvIoGm81Vp2DyyjaA==; 24:y8D8Zc/ZNmvUwMiFwXg57gsa9T/grvE8HPt6bKsazdRFOm07ZCYifjX18Gyj01gvPMxm9ZNAXvt1UCqMQgjN2ltadtOpZ1cGrDi0HpuK45I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 0895DF8FFD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(54094003)(99286002)(86362001)(76576001)(10090500001)(4326007)(1096002)(5001770100001)(1220700001)(5003600100002)(16236675004)(10400500002)(189998001)(3280700002)(6116002)(5005710100001)(102836003)(5002640100001)(790700001)(122556002)(2906002)(3660700001)(19300405004)(10290500002)(92566002)(586003)(19580395003)(5004730100002)(19617315012)(74316001)(86612001)(15975445007)(81166005)(2950100001)(77096005)(2900100001)(106116001)(33656002)(54356999)(19625215002)(19580405001)(50986999)(87936001)(76176999)(5008740100001)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139612FBF6332AFD3E74AB658C860BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2016 21:28:13.8006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:28:29 -0000 --_000_BLUPR03MB139612FBF6332AFD3E74AB658C860BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEl0IHdvdWxkIGJlIGdvb2QgdG8gZ2F0aGVyIOKAnHR5cGljYWzigJ0gaW50ZW5kZWQgdXNl IGNhc2VzIG9mIDAtUlRUIGRhdGEuDQpJdCBpcyBsaWtlbHkgdGhhdCB0aGUgdHlwaWNhbCB1c2Ug b2YgMC1SVFQgZGF0YSB3aWxsIGJlIHRvIGNvbnZleSBhIFdlYiBicm93c2Vy4oCZcyBmaXJzdCBH RVQgcmVxdWVzdCB0byBhIHNpdGUsIG9uIGEgbmV3bHkgZXN0YWJsaXNoZWQgY29ubmVjdGlvbi4N Cg0KDQrDmCAg4oCmIGJlY2F1c2Ugc2VjcmVjeSBpcyBpbiB0aGUgY29udHJvbCBvZiB0aGUgY2xp ZW50LCB3aG8gY2FuIGNob29zZSB0byBzZW5kIG9yIG5vdCBzZW5kIHNlbnNpdGl2ZSBkYXRh4oCm DQpHZW5lcmFsbHksIGhvdyBjYW4gYSBicm93c2VyIGRpc3Rpbmd1aXNoIHNlbnNpdGl2ZSBkYXRh Pw0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthcnRoaWtleWFuIEJoYXJnYXZhbg0KU2VudDogTW9uZGF5 LCBNYXJjaCAyOCwgMjAxNiAxOjMxIFBNDQpUbzogQ29sbSBNYWNDw6FydGhhaWdoIDxjb2xtQGFs bGNvc3RzLm5ldD4NCkNjOiB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVExTXSBSZXN1bXB0 aW9uIGFuZCBGb3J3YXJkIFNlY3JlY3ksIDAtUlRUIGFuZCBTYWZldHkNCg0KTGV0IG1lIHRyeSB0 byB1bmRlcnN0YW5kIHRoZSBjb25jZXJucyBoZXJlLg0KDQoNClJlc3VtcHRpb24gYW5kIEZvcndh cmQgU2VjcmVjeQ0KDQpQU0tfRUNESEUgaW4gVExTIDEuMyBkb2VzIHByb3ZpZGUgZm9yd2FyZCBz ZWNyZWN5IGZvciAxLVJUVCBkYXRhLCB5ZXM/DQpUaGlzIGlzIGFscmVhZHkgYmV0dGVyIHRoYW4g VExTIDEuMiB3aGVyZSB3ZSBoYWQgbm8gd2F5IHRvIGRvIGZvcndhcmQtc2VjcmV0IHJlc3VtcHRp b24uDQpJbiB0aGF0IGNhc2UsIHRoZSBjb25jZXJuIGlzIG1haW5seSBmb3IgMC1SVFQsIHdoaWNo IEkgYWdyZWUgaXMgaGFyZGVyIHRvIGdldCByaWdodC4NCg0KDQowUlRUIGFuZCBTYWZldHkNCkkg c2VlIGF0IGxlYXN0IHRocmVlIGRpZmZlcmVudCBjaGFsbGVuZ2VzIHdpdGggMFJUVCBhcyBkZWZp bmVkLiBUaGUgZmlyc3QgaXMgYSBnZW5lcmFsIGFuZCBoaWdoIGxldmVsIG9uZTogd2Ugc2VlbSB0 byB3aWxsaW5nIHRvIGFjY2VwdCBhICJsb3dlciIgbGV2ZWwgb2Ygc2VjdXJpdHkgZm9yIDBSVFQg ZGF0YSAoZS5nLiBubyBGUywgZXZlbiBpZiB0aGUgcmVzdCBvZiB0aGUgc2Vzc2lvbiBoYXMgaXQp LiBXaHk/IFdoYXQgaXMgaXQgd2UgdGhpbmsgaXMgc3BlY2lhbCBhYm91dCB0aGlzIGRhdGEgdGhh dCBpdCBpcyAibGVzcyIgd29ydGggcHJvdGVjdGluZz8gc3VyZWx5IHRoZXJlIGFyZSB2ZXJ5IHNl bnNpdGl2ZSB0aGluZ3MgaW4gdXJscywgc3VyZWx5IHRoZXJlIGFyZSBwb3RlbnRpYWwgb3JhY2xl cyBhbmQgb3RoZXIgdGhpbmdzIGluIHRoZXJlIHRvbz8gSXQganVzdCBzZWVtcyBzdXBlciBzdHJh bmdlIHRvIG1lLg0KDQpJIHdvbmRlciBpZiB0aGUgUVVJQyBmb2xrcyBoYXZlIGFuIGFuc3dlciB0 byB0aGlzIHF1ZXN0aW9uPyBJdCB3b3VsZCBiZSBnb29kIHRvIGdhdGhlciDigJx0eXBpY2Fs4oCd IGludGVuZGVkIHVzZSBjYXNlcyBvZiAwLVJUVCBkYXRhLg0KSW4gYW55IGNhc2UsIGl0IGlzIGdv b2QgdG8gZGlzdGluZ3Vpc2ggdGhpcyBmb3J3YXJkIHNlY3JlY3kgY29uY2VybiBmcm9tIHJlcGxh eSwgYmVjYXVzZSBzZWNyZWN5IGlzIGluIHRoZSBjb250cm9sIG9mIHRoZSBjbGllbnQsIHdobyBj YW4gY2hvb3NlIHRvIHNlbmQgb3Igbm90IHNlbmQgc2Vuc2l0aXZlIGRhdGEsIGJ1dCByZXBsYXkg ZGV0ZWN0aW9uIGlzIGluIHRoZSBoYW5kcyBvZiB0aGUgc2VydmVyLg0KDQoNClRoZSBzZWNvbmQg Y2hhbGxlbmdlIGlzIHRoYXQgdGhlIHJlcGxheWFiaWxpdHkgb2YgdGhlIDBSVFQgcG9zZXMgYSBj cnlwdG9ncmFwaGljIHNhZmV0eSBjaGFsbGVuZ2UuIFRha2UgTHVja3kxMyAtIHdoaWNoIGlzIGEg YnJpbGxpYW50IGF0dGFjayBhbmQgaXMgc3R1bm5pbmdseSBlZmZlY3RpdmUgYWdhaW5zdCBEVExT IGJlY2F1c2UgaXQgaXMgc28gZWFzeSB0byByZXBsYXkgb3ZlciBhbmQgb3ZlcjsgYmFyZWx5IG5l ZWRpbmcgdG8gY2hhbmdlIGFueSBwYXJhbWV0ZXJzIC0gYW5kIGxldCB0aGUgc2VydmVyIGRvIHRo ZSB3b3JrLiAwUlRUIGxvb2tzIHZlcnkgc2ltaWxhci4gSXQgZG9lc24ndCBzZWVtIHdpc2UgdG8g bGV0IGNpcGhlciB0ZXh0IG1hbmlwdWxhdG9ycyB0YWtlIGFzIG1hbnkgY3JhY2tzIGF0IHRoZSB3 aGlwIGFzIHRoZXknZCBsaWtlLg0KVGhlIHRoaXJkIGNoYWxsZW5nZSBpcyB0aGF0IHRoZSAwUlRU IHBsYWludGV4dCBkYXRhIGl0c2VsZiBtYXkgbm90IGJlIHNhZmUgdG8gcmVwbGF5OyB0aGF0IGlz IHRoYXQgaXQgbWlnaHQgdHJpZ2dlciBzb21lIGtpbmQgb2Ygbm9uLWlkZW1wb3RlbnQgYWN0aW9u LiBJZGVtcG90ZW5jZSBpcyByZWFsbHkgcmVhbGx5IGhhcmQsIGl0IGlzbid0IHNhZmUgdG8gc2lt cGx5IHBsdWcgaW4gYSByZXBsYXlhYmxlIHNlY3Rpb24gdG8gZXhpc3RpbmcgcHJvdG9jb2xzLiBU aGVyZSdzIGFsc28gYSBodWdlIGRpZmZlcmVuY2UgYmV0d2VlbiBiZWluZyB0b2xlcmFudCB0byBh IHNtYWxsIG51bWJlciBvZiByZXBsYXlzLCBhbmQgYSBsYXJnZSB1bmJvdW5kZWQgbnVtYmVyLiBG b3IgZXhhbXBsZTogYSBsYXJnZSB1bmJvdW5kZWQgbnVtYmVyIG1heSBiZSB1c2VkIHRvIGdlbmVy YXRlIERPUyBhdHRhY2tzIGFnYWluc3QgIHRocm90dGxlcyBhbmQgcXVvdGFzLg0KDQpZZXMsIGRl dGVjdGluZyBhbmQgcHJldmVudGluZyByZXBsYXlzIGJ5IGRlZmF1bHQgd291bGQgYmUgZ29vZC4N Ckhvd2V2ZXIsIEkgd291bGRu4oCZdCB0aWUgdGhpcyBpbiB3aXRoIHRoZSBzZXNzaW9uIG1lY2hh bmlzbS4NCldvdWxkbuKAmXQgd2Ugd2FudCB0byBwcmV2ZW50IHJlcGxheSBvZiBESCAwLVJUVCBy ZXF1ZXN0cz8NCg0KQmVzdCwNCkthcnRoaWsNCg0KDQoNCg0KVGhlIHRoaXJkIGNoYWxsZW5nZSBp cyB0aGF0IHRoZSAwUlRUIHBsYWludGV4dCBkYXRhIGl0c2VsZiBtYXkgbm90IGJlIHNhZmUgdG8g cmVwbGF5OyB0aGF0IGlzIHRoYXQgaXQgbWlnaHQgdHJpZ2dlciBzb21lIGtpbmQgb2Ygbm9uLWlk ZW1wb3RlbnQgYWN0aW9uLiBJZGVtcG90ZW5jZSBpcyByZWFsbHkgcmVhbGx5IGhhcmQsIGl0IGlz bid0IHNhZmUgdG8gc2ltcGx5IHBsdWcgaW4gYSByZXBsYXlhYmxlIHNlY3Rpb24gdG8gZXhpc3Rp bmcgcHJvdG9jb2xzLiBUaGVyZSdzIGFsc28gYSBodWdlIGRpZmZlcmVuY2UgYmV0d2VlbiBiZWlu ZyB0b2xlcmFudCB0byBhIHNtYWxsIG51bWJlciBvZiByZXBsYXlzLCBhbmQgYSBsYXJnZSB1bmJv dW5kZWQgbnVtYmVyLiBGb3IgZXhhbXBsZTogYSBsYXJnZSB1bmJvdW5kZWQgbnVtYmVyIG1heSBi ZSB1c2VkIHRvIGdlbmVyYXRlIERPUyBhdHRhY2tzIGFnYWluc3QgIHRocm90dGxlcyBhbmQgcXVv dGFzLg0KDQpUeWluZyB0aGluZ3MgdG9nZXRoZXINClNob3J0IG9mIHNvbWUga2luZCBvZiB0cmFu c2FjdGlvbmFsIGxvY2tpbmcgcHJvdG9jb2wgZHVyaW5nIFRMUyBoYW5kc2hha2VzLCBJIGRvbid0 IHRoaW5rIHRoZXJlIGlzIGEgc2NoZW1lIHRoYXQgY2FuIHBlcmZlY3RseSBwcmV2ZW50IHJlcGxh eS4gQmlsbCBDb3gnIGFuYWx5c2lzIGlzIGEgcmVhbGx5IGdvb2Qgb25lIGhlcmUuIEJ1dCBJJ2Qg bGlrZSB0byBvYnNlcnZlIHRoYXQgdGhlIHNvcnQgb2Ygc2luZ2xlLXVzZS1zZXNzaW9uLWlkIGNh Y2hlIG91dGxpbmVkIGFib3ZlIGhhcyBhIG5pY2UgcHJvcGVydHkgdGhhdCBpdCBtYWtlcyBmb3Ig YSBzb3J0IG9mIHN0cmlrZSByZWdpc3Rlci4gU2luY2UgdGhlIHNlcnZlci1zaWRlIGltcGxlbWVu dG9yIGlzIGluY2VudGl2aXplZCB0byBldmljdCBlbnRyaWVzLCBvciBhdCBsZWFzdCBtYXJrIHRo ZW0gYXMgdXNlZCwgc28gdGhhdCB0aGUgc2xvdCBpcyBhdmFpbGFibGUgZm9yIHJlLXVzZTsgdGhh dCBjYW4gYmUgZG91YmxlZC11cCBhcyBhICJ3ZSd2ZSBzZWVuIHRoaXMgYWxyZWFkeSIgc2lnbmFs LiBUaGlzIHJlZHVjZXMgdGhlIHJlcGxheSB3aW5kb3cgdG8gdGhlIHRpbWUgcGVyaW9kIGZvciB0 aGF0IHNpZ25hbCB0byBwcm9wYWdhdGUgKGUuZy4gZm9yIGFuIGV2aWN0aW9uIHRvIGhhcHBlbiBm cm9tIHRoZSBjYWNoZSkuDQoNClNvIDBSVFQgZGF0YSBjb3VsZCBiZSBlbmNyeXB0ZWQgdW5kZXIg dGhlIHJlc3VtcHRpb24gc2Vzc2lvbiBpZC4gVGhhdCBjcmVhdGVzIHRoZSBjaGFsbGVuZ2UgdGhh dCB0aGUgc2Vzc2lvbiBtaWdodCBub3QgYmUgdGhlcmUgYW55IG1vcmUsIHNvIHRoZSBzZXJ2ZXIg bWF5IG5vdCBiZSBhYmxlIHRvIGRlY3J5cHQgdGhlIDBSVFQgZGF0YS4gSSBhY3R1YWxseSB0aGlu ayB0aGlzIGlzIGEgcGx1cywgYW5kIGxpbmVzIHVwIHdpdGggYSBzZXBhcmF0ZSBpbXBvcnRhbnQg Y2hhbmdlIEkgdGhpbmsgaXMgbmVjZXNzYXJ5IC0gdGhlIDBSVFQgZGF0YSBzaG91bGRuJ3QgYmUg YXBwbGljYXRpb24gZGF0YS4gSXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUsIG9wdGlvbmFsLCBzdHJl YW0uIEkgZmluZCBpdCBoZWxwZnVsIHRvIHRoaW5rIG9mIGl0IGFzIGEgaGludCwgc28gaXQgY291 bGQgYmUgY2FsbGVkICJyZXBsYXlhYmxlX2hpbnQiLiBJbnN0ZWFkIG9mIGJyZWFraW5nIGFwYXJ0 IGFuIGV4aXN0aW5nIHByb3RvY29sIGFuZCBwdXR0aW5nIHNvbWUgb2YgaXQgaW4gdGhlIGVhcmx5 IGRhdGEgYW5kIHNvbWUgaW4gdGhlIGFwcGxpY2F0aW9uIGRhdGEgdHJhbnNwYXJlbnRseSAoYSBk aXNhc3RlciBpbiB3YWl0aW5nKSwgdGhlIGNsaWVudCBhbmQgc2VydmVyIHdvdWxkIGhhdmUgdG8g Zm9ybWFsbHkgYWdyZWUgb24gdGhlIGtpbmQgb2YgZGF0YSB0aGF0IGNvdWxkIGJlIGluIGEgInJl cGxheWFibGVfaGludCIuIFRoaXMgZ29lcyBhIGxvbmcgd2F5IHRvIG1pdGlnYXRpbmcgbWFueSBw cm90b2NvbCBsZXZlbCBpZGVtcG90ZW5jeSBjb25jZXJucywgYW5kIGhhcyBubyBpbXBhY3Qgb24g dGhlIGtpbmQgb2YgcHJlLWZldGNoaW5nIHBlb3BsZSB3YW50IHRvIGRvIGZvciBIVFRQIGFuZCBv dGhlciBwcm90b2NvbHMuIEF0IGEgYmFyZSBtaW5pbXVtLCBJIHRoaW5rIHdlIHNob3VsZCBtYWtl IHRoaXMgY2hhbmdlLg0KDQpMYXN0bHksIGFuZCB0aGlzIGlzIGEgbGl0dGxlIGNyYXp5IGJ1dCBJ IGhhdmVuJ3QgbGV0IHRoYXQgc3RvcCBtZSBiZWZvcmUgLi4uIHRvIGd1YXJkIGFnYWluc3QgdGhl IHNtYWxsZXIgcmVwbGF5IHdpbmRvdyBhbmQgaWRlbXBvdGVuY3kgcHJvYmxlbXMgYXQgdGhlIGFw cGxpY2F0aW9uIGxldmVscyxjbGllbnRzIHNob3VsZCBvY2Nhc2lvbmFsbHkgc2VuZCBkdXBsaWNh dGUgYW5kIHVucmVsYXRlZCBoaW50cywganVzdCBvcHBvcnR1bmlzdGljYWxseS4gVGhpcyBrZWVw cyB0aGUgc2VydmVyIHNpZGUgYXBwbGljYXRpb24gIm9uIG5vdGljZSIgdGhhdCB0aGF0IGtpbmQg b2YgY3JhemluZXNzIGNhbiBvY2N1ciwgYW5kIGJldHRlciB0byBoYXZlIGl0IGhhcHBlbiBhIGxp dHRsZSBhbGwgb2YgdGhlIHRpbWUgaW4gYSBjb250cm9sbGVkIHdheSwgdGhhbiByYXJlbHkgYnkg YXR0YWNrZXJzLg0KDQpTdW1tYXJ5DQpBIGNvbW1vbiB0aGVtZSBpbiB0aGUgYWJvdmUgaXMgdGhh dCBpdCBtYWtlcyB0aGluZ3MgbW9yZSBleHBlbnNpdmUgZm9yIHNlcnZlci1zaWRlIGltcGxlbWVu dG9ycywgYW5kIHRoYXQgc3Vja3MgLSBidXQgSSBkb24ndCBzZWUgYW5vdGhlciB3YXkgdG8gYXZv aWQgc29tZSBvZiB0aGUgcGl0ZmFsbHMgaGVyZTsgYW5kIEknbSB1bmhhcHB5IHdpdGggdGhlIHN0 YXRlIG9mIHRpY2tldHMgdG9kYXkuIElmIEknbSBvbiBteSBvd24gb24gdGhhdCwgSSdkIGJlIGlu dGVyZXN0ZWQgaW4gd2hhdCBraW5kcyBvZiBkYXRhIHBlb3BsZSBtaWdodCBraW5kIGNvbnZpbmNp bmcuIE15IG93biBpbXByZXNzaW9ucyBjb21lIGZyb20gYmVpbmcgYW4gQXBhY2hlIGh0dHBkIGRl dmVsb3BlciBhbmQgYXNzaXN0aW5nIHBlb3BsZSB3aXRoIGNvbmZpZ3VyYXRpb25zIGFuZCBydW5u aW5nIHdvcmtzaG9wcyBhdCBjb25mZXJlbmNlcy4gSXQncyBub3Qgc2NpZW50aWZpYywgYnV0IHRo ZSBwcmV2YWxlbmNlIG9mIG5vbi1yb3RhdGlvbiBpcyBzbyBzZXZlcmUgaW4gbXkgc2FtcGxlIHNl dCB0aGF0IEknbSBjb252aW5jZWQgaXQncyB0aGUgbm9ybS4NCg0KLS0NCkNvbG0NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0 DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_BLUPR03MB139612FBF6332AFD3E74AB658C860BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAzMjYxMTgzMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6OTExMzYwMTQ0IC0xNDc1MTk5OTc0IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNv LWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omww IGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkl0 IHdvdWxkIGJlIGdvb2QgdG8gZ2F0aGVyIOKAnHR5cGljYWzigJ0gaW50ZW5kZWQgdXNlIGNhc2Vz IG9mIDAtUlRUIGRhdGEuPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JdCBpcyBsaWtlbHkgdGhhdCB0aGUgdHlwaWNhbCB1c2Ugb2YgMC1SVFQgZGF0YSB3 aWxsIGJlIHRvIGNvbnZleSBhIFdlYiBicm93c2Vy4oCZcyBmaXJzdCBHRVQgcmVxdWVzdCB0byBh IHNpdGUsIG9uIGEgbmV3bHkgZXN0YWJsaXNoZWQgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT7igKYgYmVjYXVzZSBzZWNyZWN5IGlzIGluIHRoZSBjb250cm9sIG9mIHRoZSBjbGll bnQsIHdobyBjYW4gY2hvb3NlIHRvIHNlbmQgb3Igbm90IHNlbmQgc2Vuc2l0aXZlIGRhdGHigKY8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5HZW5lcmFsbHksIGhvdyBjYW4gYSBicm93c2VyIGRpc3Rpbmd1aXNoIHNlbnNp dGl2ZSBkYXRhPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hl ZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+S2FydGhpa2V5YW4gQmhhcmdh dmFuPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMjgsIDIwMTYgMTozMSBQTTxicj4N CjxiPlRvOjwvYj4gQ29sbSBNYWNDw6FydGhhaWdoICZsdDtjb2xtQGFsbGNvc3RzLm5ldCZndDs8 YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RM U10gUmVzdW1wdGlvbiBhbmQgRm9yd2FyZCBTZWNyZWN5LCAwLVJUVCBhbmQgU2FmZXR5PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0IG1lIHRyeSB0byB1 bmRlcnN0YW5kIHRoZSBjb25jZXJucyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+UmVzdW1wdGlvbiBhbmQg Rm9yd2FyZCBTZWNyZWN5PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QU0tfRUNESEUgaW4gVExT IDEuMyBkb2VzIHByb3ZpZGUgZm9yd2FyZCBzZWNyZWN5IGZvciAxLVJUVCBkYXRhLCB5ZXM/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlz IGFscmVhZHkgYmV0dGVyIHRoYW4gVExTIDEuMiB3aGVyZSB3ZSBoYWQgbm8gd2F5IHRvIGRvIGZv cndhcmQtc2VjcmV0IHJlc3VtcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGF0IGNhc2UsIHRoZSBjb25jZXJuIGlzIG1haW5seSBm b3IgMC1SVFQsIHdoaWNoIEkgYWdyZWUgaXMgaGFyZGVyIHRvIGdldCByaWdodC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjBS VFQgYW5kIFNhZmV0eTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgYXQgbGVh c3QgdGhyZWUgZGlmZmVyZW50IGNoYWxsZW5nZXMgd2l0aCAwUlRUIGFzIGRlZmluZWQuIFRoZSBm aXJzdCBpcyBhIGdlbmVyYWwgYW5kIGhpZ2ggbGV2ZWwgb25lOiB3ZSBzZWVtIHRvIHdpbGxpbmcg dG8gYWNjZXB0IGEgJnF1b3Q7bG93ZXImcXVvdDsgbGV2ZWwgb2Ygc2VjdXJpdHkgZm9yIDBSVFQg ZGF0YSAoZS5nLiBubyBGUywgZXZlbiBpZiB0aGUgcmVzdCBvZiB0aGUgc2Vzc2lvbiBoYXMgaXQp LiBXaHk/DQogV2hhdCBpcyBpdCB3ZSB0aGluayBpcyBzcGVjaWFsIGFib3V0IHRoaXMgZGF0YSB0 aGF0IGl0IGlzICZxdW90O2xlc3MmcXVvdDsgd29ydGggcHJvdGVjdGluZz8gc3VyZWx5IHRoZXJl IGFyZSB2ZXJ5IHNlbnNpdGl2ZSB0aGluZ3MgaW4gdXJscywgc3VyZWx5IHRoZXJlIGFyZSBwb3Rl bnRpYWwgb3JhY2xlcyBhbmQgb3RoZXIgdGhpbmdzIGluIHRoZXJlIHRvbz8gSXQganVzdCBzZWVt cyBzdXBlciBzdHJhbmdlIHRvIG1lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd29uZGVy IGlmIHRoZSBRVUlDIGZvbGtzIGhhdmUgYW4gYW5zd2VyIHRvIHRoaXMgcXVlc3Rpb24/IEl0IHdv dWxkIGJlIGdvb2QgdG8gZ2F0aGVyIOKAnHR5cGljYWzigJ0gaW50ZW5kZWQgdXNlIGNhc2VzIG9m IDAtUlRUIGRhdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JbiBhbnkgY2FzZSwgaXQgaXMgZ29vZCB0byBkaXN0aW5ndWlzaCB0aGlzIGZvcndh cmQgc2VjcmVjeSBjb25jZXJuIGZyb20gcmVwbGF5LCBiZWNhdXNlIHNlY3JlY3kgaXMgaW4gdGhl IGNvbnRyb2wgb2YgdGhlIGNsaWVudCwgd2hvIGNhbiBjaG9vc2UgdG8gc2VuZCBvciBub3Qgc2Vu ZCBzZW5zaXRpdmUgZGF0YSwgYnV0IHJlcGxheSBkZXRlY3Rpb24gaXMgaW4gdGhlIGhhbmRzIG9m IHRoZSBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBzZWNvbmQgY2hhbGxlbmdlIGlzIHRoYXQgdGhlIHJlcGxheWFiaWxpdHkg b2YgdGhlIDBSVFQgcG9zZXMgYSBjcnlwdG9ncmFwaGljIHNhZmV0eSBjaGFsbGVuZ2UuIFRha2Ug THVja3kxMyAtIHdoaWNoIGlzIGEgYnJpbGxpYW50IGF0dGFjayBhbmQgaXMgc3R1bm5pbmdseSBl ZmZlY3RpdmUgYWdhaW5zdCBEVExTIGJlY2F1c2UgaXQgaXMgc28gZWFzeSB0byByZXBsYXkgb3Zl ciBhbmQgb3ZlcjsgYmFyZWx5DQogbmVlZGluZyB0byBjaGFuZ2UgYW55IHBhcmFtZXRlcnMgLSBh bmQgbGV0IHRoZSBzZXJ2ZXIgZG8gdGhlIHdvcmsuIDBSVFQgbG9va3MgdmVyeSBzaW1pbGFyLiBJ dCBkb2Vzbid0IHNlZW0gd2lzZSB0byBsZXQgY2lwaGVyIHRleHQgbWFuaXB1bGF0b3JzIHRha2Ug YXMgbWFueSBjcmFja3MgYXQgdGhlIHdoaXAgYXMgdGhleSdkIGxpa2UuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGhpcmQgY2hhbGxlbmdlIGlzIHRoYXQgdGhl IDBSVFQgcGxhaW50ZXh0IGRhdGEgaXRzZWxmIG1heSBub3QgYmUgc2FmZSB0byByZXBsYXk7IHRo YXQgaXMgdGhhdCBpdCBtaWdodCB0cmlnZ2VyIHNvbWUga2luZCBvZiBub24taWRlbXBvdGVudCBh Y3Rpb24uIElkZW1wb3RlbmNlIGlzIHJlYWxseSByZWFsbHkgaGFyZCwgaXQgaXNuJ3Qgc2FmZSB0 byBzaW1wbHkgcGx1ZyBpbiBhIHJlcGxheWFibGUgc2VjdGlvbg0KIHRvIGV4aXN0aW5nIHByb3Rv Y29scy4gVGhlcmUncyBhbHNvIGEgaHVnZSBkaWZmZXJlbmNlIGJldHdlZW4gYmVpbmcgdG9sZXJh bnQgdG8gYSBzbWFsbCBudW1iZXIgb2YgcmVwbGF5cywgYW5kIGEgbGFyZ2UgdW5ib3VuZGVkIG51 bWJlci4gRm9yIGV4YW1wbGU6IGEgbGFyZ2UgdW5ib3VuZGVkIG51bWJlciBtYXkgYmUgdXNlZCB0 byBnZW5lcmF0ZSBET1MgYXR0YWNrcyBhZ2FpbnN0ICZuYnNwO3Rocm90dGxlcyBhbmQgcXVvdGFz LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WWVzLCBkZXRlY3RpbmcgYW5kIHByZXZlbnRpbmcgcmVwbGF5cyBieSBkZWZhdWx0 IHdvdWxkIGJlIGdvb2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ib3dldmVyLCBJIHdvdWxkbuKAmXQgdGllIHRoaXMgaW4gd2l0aCB0aGUgc2Vz c2lvbiBtZWNoYW5pc20uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Xb3VsZG7igJl0IHdlIHdhbnQgdG8gcHJldmVudCByZXBsYXkgb2Yg REggMC1SVFQgcmVxdWVzdHM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5LYXJ0aGlrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGhpcmQgY2hhbGxlbmdlIGlzIHRoYXQgdGhl IDBSVFQgcGxhaW50ZXh0IGRhdGEgaXRzZWxmIG1heSBub3QgYmUgc2FmZSB0byByZXBsYXk7IHRo YXQgaXMgdGhhdCBpdCBtaWdodCB0cmlnZ2VyIHNvbWUga2luZCBvZiBub24taWRlbXBvdGVudCBh Y3Rpb24uIElkZW1wb3RlbmNlIGlzIHJlYWxseSByZWFsbHkgaGFyZCwgaXQgaXNuJ3Qgc2FmZSB0 byBzaW1wbHkgcGx1ZyBpbiBhIHJlcGxheWFibGUgc2VjdGlvbg0KIHRvIGV4aXN0aW5nIHByb3Rv Y29scy4gVGhlcmUncyBhbHNvIGEgaHVnZSBkaWZmZXJlbmNlIGJldHdlZW4gYmVpbmcgdG9sZXJh bnQgdG8gYSBzbWFsbCBudW1iZXIgb2YgcmVwbGF5cywgYW5kIGEgbGFyZ2UgdW5ib3VuZGVkIG51 bWJlci4gRm9yIGV4YW1wbGU6IGEgbGFyZ2UgdW5ib3VuZGVkIG51bWJlciBtYXkgYmUgdXNlZCB0 byBnZW5lcmF0ZSBET1MgYXR0YWNrcyBhZ2FpbnN0ICZuYnNwO3Rocm90dGxlcyBhbmQgcXVvdGFz LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5UeWluZyB0aGluZ3MgdG9nZXRoZXI8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG9ydCBvZiBzb21lIGtpbmQgb2YgdHJhbnNh Y3Rpb25hbCBsb2NraW5nIHByb3RvY29sIGR1cmluZyBUTFMgaGFuZHNoYWtlcywgSSBkb24ndCB0 aGluayB0aGVyZSBpcyBhIHNjaGVtZSB0aGF0IGNhbiBwZXJmZWN0bHkgcHJldmVudCByZXBsYXku IEJpbGwgQ294JyBhbmFseXNpcyBpcyBhIHJlYWxseSBnb29kIG9uZSBoZXJlLiBCdXQgSSdkIGxp a2UgdG8gb2JzZXJ2ZSB0aGF0IHRoZSBzb3J0IG9mIHNpbmdsZS11c2Utc2Vzc2lvbi1pZA0KIGNh Y2hlIG91dGxpbmVkIGFib3ZlIGhhcyBhIG5pY2UgcHJvcGVydHkgdGhhdCBpdCBtYWtlcyBmb3Ig YSBzb3J0IG9mIHN0cmlrZSByZWdpc3Rlci4gU2luY2UgdGhlIHNlcnZlci1zaWRlIGltcGxlbWVu dG9yIGlzIGluY2VudGl2aXplZCB0byBldmljdCBlbnRyaWVzLCBvciBhdCBsZWFzdCBtYXJrIHRo ZW0gYXMgdXNlZCwgc28gdGhhdCB0aGUgc2xvdCBpcyBhdmFpbGFibGUgZm9yIHJlLXVzZTsgdGhh dCBjYW4gYmUgZG91YmxlZC11cCBhcyBhICZxdW90O3dlJ3ZlDQogc2VlbiB0aGlzIGFscmVhZHkm cXVvdDsgc2lnbmFsLiBUaGlzIHJlZHVjZXMgdGhlIHJlcGxheSB3aW5kb3cgdG8gdGhlIHRpbWUg cGVyaW9kIGZvciB0aGF0IHNpZ25hbCB0byBwcm9wYWdhdGUgKGUuZy4gZm9yIGFuIGV2aWN0aW9u IHRvIGhhcHBlbiBmcm9tIHRoZSBjYWNoZSkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIDBSVFQgZGF0YSBjb3VsZCBiZSBlbmNy eXB0ZWQgdW5kZXIgdGhlIHJlc3VtcHRpb24gc2Vzc2lvbiBpZC4gVGhhdCBjcmVhdGVzIHRoZSBj aGFsbGVuZ2UgdGhhdCB0aGUgc2Vzc2lvbiBtaWdodCBub3QgYmUgdGhlcmUgYW55IG1vcmUsIHNv IHRoZSBzZXJ2ZXIgbWF5IG5vdCBiZSBhYmxlIHRvIGRlY3J5cHQgdGhlIDBSVFQgZGF0YS4gSSBh Y3R1YWxseSB0aGluayB0aGlzIGlzIGEgcGx1cywgYW5kIGxpbmVzDQogdXAgd2l0aCBhIHNlcGFy YXRlIGltcG9ydGFudCBjaGFuZ2UgSSB0aGluayBpcyBuZWNlc3NhcnkgLSB0aGUgMFJUVCBkYXRh IHNob3VsZG4ndCBiZSBhcHBsaWNhdGlvbiBkYXRhLiBJdCBzaG91bGQgYmUgYSBzZXBhcmF0ZSwg b3B0aW9uYWwsIHN0cmVhbS4gSSBmaW5kIGl0IGhlbHBmdWwgdG8gdGhpbmsgb2YgaXQgYXMgYSBo aW50LCBzbyBpdCBjb3VsZCBiZSBjYWxsZWQgJnF1b3Q7cmVwbGF5YWJsZV9oaW50JnF1b3Q7LiBJ bnN0ZWFkIG9mIGJyZWFraW5nIGFwYXJ0DQogYW4gZXhpc3RpbmcgcHJvdG9jb2wgYW5kIHB1dHRp bmcgc29tZSBvZiBpdCBpbiB0aGUgZWFybHkgZGF0YSBhbmQgc29tZSBpbiB0aGUgYXBwbGljYXRp b24gZGF0YSB0cmFuc3BhcmVudGx5IChhIGRpc2FzdGVyIGluIHdhaXRpbmcpLCB0aGUgY2xpZW50 IGFuZCBzZXJ2ZXIgd291bGQgaGF2ZSB0byBmb3JtYWxseSBhZ3JlZSBvbiB0aGUga2luZCBvZiBk YXRhIHRoYXQgY291bGQgYmUgaW4gYSAmcXVvdDtyZXBsYXlhYmxlX2hpbnQmcXVvdDsuIFRoaXMg Z29lcyBhIGxvbmcNCiB3YXkgdG8gbWl0aWdhdGluZyBtYW55IHByb3RvY29sIGxldmVsIGlkZW1w b3RlbmN5IGNvbmNlcm5zLCBhbmQgaGFzIG5vIGltcGFjdCBvbiB0aGUga2luZCBvZiBwcmUtZmV0 Y2hpbmcgcGVvcGxlIHdhbnQgdG8gZG8gZm9yIEhUVFAgYW5kIG90aGVyIHByb3RvY29scy4gQXQg YSBiYXJlIG1pbmltdW0sIEkgdGhpbmsgd2Ugc2hvdWxkIG1ha2UgdGhpcyBjaGFuZ2UuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxh c3RseSwgYW5kIHRoaXMgaXMgYSBsaXR0bGUgY3JhenkgYnV0IEkgaGF2ZW4ndCBsZXQgdGhhdCBz dG9wIG1lIGJlZm9yZSAuLi4gdG8gZ3VhcmQgYWdhaW5zdCB0aGUgc21hbGxlciByZXBsYXkgd2lu ZG93IGFuZCBpZGVtcG90ZW5jeSBwcm9ibGVtcyBhdCB0aGUgYXBwbGljYXRpb24gbGV2ZWxzLGNs aWVudHMgc2hvdWxkIG9jY2FzaW9uYWxseSBzZW5kIGR1cGxpY2F0ZSBhbmQgdW5yZWxhdGVkIGhp bnRzLCBqdXN0DQogb3Bwb3J0dW5pc3RpY2FsbHkuIFRoaXMga2VlcHMgdGhlIHNlcnZlciBzaWRl IGFwcGxpY2F0aW9uICZxdW90O29uIG5vdGljZSZxdW90OyB0aGF0IHRoYXQga2luZCBvZiBjcmF6 aW5lc3MgY2FuIG9jY3VyLCBhbmQgYmV0dGVyIHRvIGhhdmUgaXQgaGFwcGVuIGEgbGl0dGxlIGFs bCBvZiB0aGUgdGltZSBpbiBhIGNvbnRyb2xsZWQgd2F5LCB0aGFuIHJhcmVseSBieSBhdHRhY2tl cnMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+U3VtbWFyeTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY29tbW9uIHRoZW1lIGluIHRoZSBhYm92ZSBpcyB0 aGF0IGl0IG1ha2VzIHRoaW5ncyBtb3JlIGV4cGVuc2l2ZSBmb3Igc2VydmVyLXNpZGUgaW1wbGVt ZW50b3JzLCBhbmQgdGhhdCBzdWNrcyAtIGJ1dCBJIGRvbid0IHNlZSBhbm90aGVyIHdheSB0byBh dm9pZCBzb21lIG9mIHRoZSBwaXRmYWxscyBoZXJlOyBhbmQgSSdtIHVuaGFwcHkgd2l0aCB0aGUg c3RhdGUgb2YgdGlja2V0cyB0b2RheS4gSWYgSSdtIG9uDQogbXkgb3duIG9uIHRoYXQsIEknZCBi ZSBpbnRlcmVzdGVkIGluIHdoYXQga2luZHMgb2YgZGF0YSBwZW9wbGUgbWlnaHQga2luZCBjb252 aW5jaW5nLiBNeSBvd24gaW1wcmVzc2lvbnMgY29tZSBmcm9tIGJlaW5nIGFuIEFwYWNoZSBodHRw ZCBkZXZlbG9wZXIgYW5kIGFzc2lzdGluZyBwZW9wbGUgd2l0aCBjb25maWd1cmF0aW9ucyBhbmQg cnVubmluZyB3b3Jrc2hvcHMgYXQgY29uZmVyZW5jZXMuIEl0J3Mgbm90IHNjaWVudGlmaWMsIGJ1 dCB0aGUgcHJldmFsZW5jZQ0KIG9mIG5vbi1yb3RhdGlvbiBpcyBzbyBzZXZlcmUgaW4gbXkgc2Ft cGxlIHNldCB0aGF0IEknbSBjb252aW5jZWQgaXQncyB0aGUgbm9ybS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q29sbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExT IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3RscyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_BLUPR03MB139612FBF6332AFD3E74AB658C860BLUPR03MB1396namp_-- From nobody Mon Mar 28 14:31:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D412D1DA for ; Mon, 28 Mar 2016 14:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 vbX_sw3DnzXu for ; Mon, 28 Mar 2016 14:31:33 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 A480812D0BD for ; Mon, 28 Mar 2016 14:31:31 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id 191so28695472wmq.0 for ; Mon, 28 Mar 2016 14:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=GtAQ7vimaoYRx7xx6qFJ8Hq/Ks2YTmn7HowQc0MEpCs=; b=ltQGLs2pmQQUMsw9gwrXbCO0jqA0kejt5D+PD7KQrZW/hvn/ZyeCAyaS6+JnQXfJZ6 Dg3dMQMW8+BclhmKidgpkbBDTjWd3pKqsr3OHFV+YkqgmHFlCGLzVYuLvarBuVF9IxHl Qou1BuZazI8HPofbAfLc5yqLmUomLkm8MD2O5cCPwQi8CMoIic9US0ACLjQEg2TziREV rYsxCmg14S5npZIVvQLALToV0XstvU2OR5neYK0ULZlKxTaBb/POS3LDYz+79iPrvw0e kI0o/kndPxf36iDfq1E9ujdpkEZCSjmc02OKGeFjjZKF7iqXXTHjr+jwlwLWrEdz6UOT QS5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GtAQ7vimaoYRx7xx6qFJ8Hq/Ks2YTmn7HowQc0MEpCs=; b=fHBfDtn0PrWM68T1yAb8+cyEKScsC66a4bfsKBlcyWzoVSaWE4MeYr8naW1WKKgiyu j2kDdGN42GoW66UQjCuyjJgPvURpLeBO3AKlo7PVdd/tedURWRutz9bG2RZPRHV6juf4 dEt2d34Kf37Ibt9fMj/W3vMom2T3pfuyPtWfSGI4ASLYXHVXEpN5wHZwdVlyylXDhmOX iVNlxFBhVbSGDo2hDGY1d3cXoi0nYzGbyEEH2dLEGfG6BxaNQ4aN/eUl8nfIZ13YrFtD na8RhTSO7Jq4rSwoi8hIYqBziJnVI234iFn9MUWa+pbjtAdOewPHlU84ZN4iwud4+Qkl bNGw== X-Gm-Message-State: AD7BkJKXLb/KMUreTbO+4uqRSGmWwG3McoVySotfk3bqAMcORkuLsBt7ukYRE9k3dasY+A== X-Received: by 10.28.22.74 with SMTP id 71mr12493442wmw.47.1459200690062; Mon, 28 Mar 2016 14:31:30 -0700 (PDT) Received: from [192.168.0.51] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id jf6sm26372257wjb.2.2016.03.28.14.31.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Mar 2016 14:31:28 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C625CD7D-2E74-41BC-B635-BFD6FE514C81" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Mon, 28 Mar 2016 23:30:39 +0200 Message-Id: <535576C4-F808-4937-946C-B53661F0645D@gmail.com> References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> To: Andrei Popov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:31:36 -0000 --Apple-Mail=_C625CD7D-2E74-41BC-B635-BFD6FE514C81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > =C3=98 =E2=80=A6 because secrecy is in the control of the client, who = can choose to send or not send sensitive data=E2=80=A6 > Generally, how can a browser distinguish sensitive data? By not sending cookies or authorization headers, for example? > =20 > Cheers, > =20 > Andrei > =20 > From: TLS [mailto:tls-bounces@ietf.org ] = On Behalf Of Karthikeyan Bhargavan > Sent: Monday, March 28, 2016 1:31 PM > To: Colm MacC=C3=A1rthaigh > > Cc: tls@ietf.org > Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety > =20 > Let me try to understand the concerns here. >=20 >=20 > Resumption and Forward Secrecy > =20 > PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes? > This is already better than TLS 1.2 where we had no way to do = forward-secret resumption. > In that case, the concern is mainly for 0-RTT, which I agree is harder = to get right. >=20 >=20 > 0RTT and Safety > I see at least three different challenges with 0RTT as defined. The = first is a general and high level one: we seem to willing to accept a = "lower" level of security for 0RTT data (e.g. no FS, even if the rest of = the session has it). Why? What is it we think is special about this data = that it is "less" worth protecting? surely there are very sensitive = things in urls, surely there are potential oracles and other things in = there too? It just seems super strange to me.=20 > =20 > I wonder if the QUIC folks have an answer to this question? It would = be good to gather =E2=80=9Ctypical=E2=80=9D intended use cases of 0-RTT = data. > In any case, it is good to distinguish this forward secrecy concern = from replay, because secrecy is in the control of the client, who can = choose to send or not send sensitive data, but replay detection is in = the hands of the server. >=20 >=20 > The second challenge is that the replayability of the 0RTT poses a = cryptographic safety challenge. Take Lucky13 - which is a brilliant = attack and is stunningly effective against DTLS because it is so easy to = replay over and over; barely needing to change any parameters - and let = the server do the work. 0RTT looks very similar. It doesn't seem wise to = let cipher text manipulators take as many cracks at the whip as they'd = like.=20 > The third challenge is that the 0RTT plaintext data itself may not be = safe to replay; that is that it might trigger some kind of = non-idempotent action. Idempotence is really really hard, it isn't safe = to simply plug in a replayable section to existing protocols. There's = also a huge difference between being tolerant to a small number of = replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against throttles and = quotas.=20 > =20 > Yes, detecting and preventing replays by default would be good. > However, I wouldn=E2=80=99t tie this in with the session mechanism.=20 > Wouldn=E2=80=99t we want to prevent replay of DH 0-RTT requests? > =20 > Best, > Karthik > =20 >=20 >=20 > =20 > The third challenge is that the 0RTT plaintext data itself may not be = safe to replay; that is that it might trigger some kind of = non-idempotent action. Idempotence is really really hard, it isn't safe = to simply plug in a replayable section to existing protocols. There's = also a huge difference between being tolerant to a small number of = replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against throttles and = quotas.=20 > =20 > Tying things together > Short of some kind of transactional locking protocol during TLS = handshakes, I don't think there is a scheme that can perfectly prevent = replay. Bill Cox' analysis is a really good one here. But I'd like to = observe that the sort of single-use-session-id cache outlined above has = a nice property that it makes for a sort of strike register. Since the = server-side implementor is incentivized to evict entries, or at least = mark them as used, so that the slot is available for re-use; that can be = doubled-up as a "we've seen this already" signal. This reduces the = replay window to the time period for that signal to propagate (e.g. for = an eviction to happen from the cache).=20 > =20 > So 0RTT data could be encrypted under the resumption session id. That = creates the challenge that the session might not be there any more, so = the server may not be able to decrypt the 0RTT data. I actually think = this is a plus, and lines up with a separate important change I think is = necessary - the 0RTT data shouldn't be application data. It should be a = separate, optional, stream. I find it helpful to think of it as a hint, = so it could be called "replayable_hint". Instead of breaking apart an = existing protocol and putting some of it in the early data and some in = the application data transparently (a disaster in waiting), the client = and server would have to formally agree on the kind of data that could = be in a "replayable_hint". This goes a long way to mitigating many = protocol level idempotency concerns, and has no impact on the kind of = pre-fetching people want to do for HTTP and other protocols. At a bare = minimum, I think we should make this change.=20 > =20 > Lastly, and this is a little crazy but I haven't let that stop me = before ... to guard against the smaller replay window and idempotency = problems at the application levels,clients should occasionally send = duplicate and unrelated hints, just opportunistically. This keeps the = server side application "on notice" that that kind of craziness can = occur, and better to have it happen a little all of the time in a = controlled way, than rarely by attackers. =20 > =20 > Summary > A common theme in the above is that it makes things more expensive for = server-side implementors, and that sucks - but I don't see another way = to avoid some of the pitfalls here; and I'm unhappy with the state of = tickets today. If I'm on my own on that, I'd be interested in what kinds = of data people might kind convincing. My own impressions come from being = an Apache httpd developer and assisting people with configurations and = running workshops at conferences. It's not scientific, but the = prevalence of non-rotation is so severe in my sample set that I'm = convinced it's the norm.=20 > =20 > --=20 > Colm > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_C625CD7D-2E74-41BC-B635-BFD6FE514C81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=C3=98  =E2=80=A6= because secrecy is in the control of the client, who can choose to send = or not send sensitive data=E2=80=A6
Generally, how can a browser distinguish sensitive = data?

By not sending cookies or authorization headers, = for example?

 
Cheers,
 
Andrei
 
From: TLS [mailto:tls-bounces@ietf.org] On Behalf = Of Karthikeyan = Bhargavan
Sent: Monday, March 28, 2016 1:31 = PM
To: Colm MacC=C3=A1rthaigh = <colm@allcosts.net>
Cc: tls@ietf.org
Subject: Re: [TLS] Resumption and = Forward Secrecy, 0-RTT and Safety
 
Let me try to understand the concerns here.


Resumption and Forward Secrecy
 
PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT = data, yes?
This is already better than TLS 1.2 where = we had no way to do forward-secret resumption.
In that case, the concern is mainly for 0-RTT, which I agree = is harder to get right.


0RTT and Safety
I = see at least three different challenges with 0RTT as defined. The first = is a general and high level one: we seem to willing to accept a "lower" = level of security for 0RTT data (e.g. no FS, even if the rest of the = session has it). Why? What is it we think is special about this data = that it is "less" worth protecting? surely there are very sensitive = things in urls, surely there are potential oracles and other things in = there too? It just seems super strange to me. 
 
I wonder if the QUIC folks have an answer to this = question? It would be good to gather =E2=80=9Ctypical=E2=80=9D intended = use cases of 0-RTT data.
In any case, it is = good to distinguish this forward secrecy concern from replay, because = secrecy is in the control of the client, who can choose to send or not = send sensitive data, but replay detection is in the hands of the = server.


The second challenge is that the = replayability of the 0RTT poses a cryptographic safety challenge. Take = Lucky13 - which is a brilliant attack and is stunningly effective = against DTLS because it is so easy to replay over and over; barely = needing to change any parameters - and let the server do the work. 0RTT = looks very similar. It doesn't seem wise to let cipher text manipulators = take as many cracks at the whip as they'd like. 
The third challenge is that the 0RTT plaintext data itself = may not be safe to replay; that is that it might trigger some kind of = non-idempotent action. Idempotence is really really hard, it isn't safe = to simply plug in a replayable section to existing protocols. There's = also a huge difference between being tolerant to a small number of = replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against  throttles and = quotas. 
 
Yes, detecting and = preventing replays by default would be good.
However, I wouldn=E2=80=99t tie this in with the session = mechanism. 
Wouldn=E2=80=99t we want to prevent = replay of DH 0-RTT requests?
 
Best,
Karthik
 


 
The third challenge is that the 0RTT plaintext data = itself may not be safe to replay; that is that it might trigger some = kind of non-idempotent action. Idempotence is really really hard, it = isn't safe to simply plug in a replayable section to existing protocols. = There's also a huge difference between being tolerant to a small number = of replays, and a large unbounded number. For example: a large unbounded = number may be used to generate DOS attacks against  throttles and = quotas. 
 
Tying things together
Short of some kind of transactional locking protocol during = TLS handshakes, I don't think there is a scheme that can perfectly = prevent replay. Bill Cox' analysis is a really good one here. But I'd = like to observe that the sort of single-use-session-id cache outlined = above has a nice property that it makes for a sort of strike register. = Since the server-side implementor is incentivized to evict entries, or = at least mark them as used, so that the slot is available for re-use; = that can be doubled-up as a "we've seen this already" signal. This = reduces the replay window to the time period for that signal to = propagate (e.g. for an eviction to happen from the cache). 
 
So 0RTT data could be encrypted under the = resumption session id. That creates the challenge that the session might = not be there any more, so the server may not be able to decrypt the 0RTT = data. I actually think this is a plus, and lines up with a separate = important change I think is necessary - the 0RTT data shouldn't be = application data. It should be a separate, optional, stream. I find it = helpful to think of it as a hint, so it could be called = "replayable_hint". Instead of breaking apart an existing protocol and = putting some of it in the early data and some in the application data = transparently (a disaster in waiting), the client and server would have = to formally agree on the kind of data that could be in a = "replayable_hint". This goes a long way to mitigating many protocol = level idempotency concerns, and has no impact on the kind of = pre-fetching people want to do for HTTP and other protocols. At a bare = minimum, I think we should make this change. 
 
Lastly, and this is a little crazy but I = haven't let that stop me before ... to guard against the smaller replay = window and idempotency problems at the application levels,clients should = occasionally send duplicate and unrelated hints, just opportunistically. = This keeps the server side application "on notice" that that kind of = craziness can occur, and better to have it happen a little all of the = time in a controlled way, than rarely by attackers.  
 
Summary
A common theme in the = above is that it makes things more expensive for server-side = implementors, and that sucks - but I don't see another way to avoid some = of the pitfalls here; and I'm unhappy with the state of tickets today. = If I'm on my own on that, I'd be interested in what kinds of data people = might kind convincing. My own impressions come from being an Apache = httpd developer and assisting people with configurations and running = workshops at conferences. It's not scientific, but the prevalence of = non-rotation is so severe in my sample set that I'm convinced it's the = norm. 
 
-- 
Colm
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_C625CD7D-2E74-41BC-B635-BFD6FE514C81-- From nobody Mon Mar 28 14:47:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74F8212D116 for ; Mon, 28 Mar 2016 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 XV0MwY9txbTK for ; Mon, 28 Mar 2016 14:47:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD45012D0C1 for ; Mon, 28 Mar 2016 14:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cN4wUYgYyCgw7/DOV/uzYOirzO4BqXlPNMk86x7dZJo=; b=ecL5cHpZGHGPEaa971tiUgbHwZjQoZn5dGI1Orhxe11G8IW2vYcs//b1fqP1Jli3FCB9lmrvvaDA+gGnFr6VVj31O947cpskkLvXzyPo5ebjcQkdojtpxkfWRI8JArKw8Eka3zb6e9Y8ifoIm31lfEGd6Da9tWzbwyxr6JWXP8E= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.447.15; Mon, 28 Mar 2016 21:47:23 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.023; Mon, 28 Mar 2016 21:47:23 +0000 From: Andrei Popov To: "karthik@messengeruser.com" Thread-Topic: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety Thread-Index: AQHRiSN2YMohgneox0CkzrCuSxAXNJ9vTzyAgAANb+CAAAMzgIAAAvyA Date: Mon, 28 Mar 2016 21:47:23 +0000 Message-ID: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> In-Reply-To: <535576C4-F808-4937-946C-B53661F0645D@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: 1e0d0e5c-b462-4f94-a922-08d357528c21 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:ffP4Nkrbx+zx3UawZfKfV1fneSiDhGd+wUsrYBGtzcfZUiHwF71OARW+4PRMdkzsaq9V/nuaoslXqdf5EIkDLwi3ZrrRkGshQgBiZpF7j4OhMsPmJ4oIwWlKkX7wRy3QDrNYLNleXeJzP3t1I/CxkQ==; 24:FgPNIWyPb02uFMbOKR++xwEtLBbk/Zj6eIWYUFvaQvvZWNFuPViIDqH1NIbIqIEmlaO8KyaXVT/Xg+QuP30J1ImPlYySpyRwo6F3d611tY8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394; x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394; x-forefront-prvs: 0895DF8FFD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(54094003)(2950100001)(2900100001)(92566002)(81166005)(19580395003)(19580405001)(77096005)(11100500001)(16236675004)(19609705001)(15975445007)(4326007)(122556002)(2906002)(110136002)(5004730100002)(5002640100001)(74316001)(5008740100001)(86362001)(86612001)(5003600100002)(102836003)(790700001)(6116002)(1220700001)(19300405004)(1096002)(189998001)(586003)(76176999)(19617315012)(10290500002)(19625215002)(106116001)(5005710100001)(10400500002)(54356999)(99286002)(33656002)(93886004)(2351001)(10090500001)(87936001)(50986999)(3280700002)(3660700001)(76576001)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB139671E889569CAD5E65E27D8C860BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2016 21:47:23.8229 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:47:46 -0000 --_000_BLUPR03MB139671E889569CAD5E65E27D8C860BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHNlbmRpbmcgY29va2llcy9hdXRoeiBoZWFkZXJzIGluIDAtUlRUIHdvdWxkIHNvbHZlIGEg cGFydCBvZiB0aGUgcHJvYmxlbSwgYnV0IHdpbGwgYnJvd3NlciB2ZW5kb3JzIGdvIGZvciB0aGF0 PyBJIGNvdWxkIGJlIHdyb25nLCBidXQgdGhlcmUgc2VlbXMgdG8gYmUgY29uc2lkZXJhYmxlIGlu dGVyZXN0IGluIDAtUlRUIFRva2VuIEJpbmRpbmfigKYuIHNvIGZvbGtzIG11c3QgYmUgcGxhbm5p bmcgb24gc2VuZGluZyB0b2tlbnPimLouDQoNCkZyb206IEthcnRoaWtleWFuIEJoYXJnYXZhbiBb bWFpbHRvOmthcnRoaWsuYmhhcmdhdmFuQGdtYWlsLmNvbV0NClNlbnQ6IE1vbmRheSwgTWFyY2gg MjgsIDIwMTYgMjozMSBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb20+DQpDYzogQ29sbSBNYWNDw6FydGhhaWdoIDxjb2xtQGFsbGNvc3RzLm5ldD47IHRsc0Bp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFJlc3VtcHRpb24gYW5kIEZvcndhcmQgU2VjcmVj eSwgMC1SVFQgYW5kIFNhZmV0eQ0KDQo+ICDigKYgYmVjYXVzZSBzZWNyZWN5IGlzIGluIHRoZSBj b250cm9sIG9mIHRoZSBjbGllbnQsIHdobyBjYW4gY2hvb3NlIHRvIHNlbmQgb3Igbm90IHNlbmQg c2Vuc2l0aXZlIGRhdGHigKYNCkdlbmVyYWxseSwgaG93IGNhbiBhIGJyb3dzZXIgZGlzdGluZ3Vp c2ggc2Vuc2l0aXZlIGRhdGE/DQoNCkJ5IG5vdCBzZW5kaW5nIGNvb2tpZXMgb3IgYXV0aG9yaXph dGlvbiBoZWFkZXJzLCBmb3IgZXhhbXBsZT8NCg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9t OiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthcnRoaWtl eWFuIEJoYXJnYXZhbg0KU2VudDogTW9uZGF5LCBNYXJjaCAyOCwgMjAxNiAxOjMxIFBNDQpUbzog Q29sbSBNYWNDw6FydGhhaWdoIDxjb2xtQGFsbGNvc3RzLm5ldDxtYWlsdG86Y29sbUBhbGxjb3N0 cy5uZXQ+Pg0KQ2M6IHRsc0BpZXRmLm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtUTFNdIFJlc3VtcHRpb24gYW5kIEZvcndhcmQgU2VjcmVjeSwgMC1SVFQgYW5kIFNhZmV0 eQ0KDQpMZXQgbWUgdHJ5IHRvIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm5zIGhlcmUuDQoNCg0KDQpS ZXN1bXB0aW9uIGFuZCBGb3J3YXJkIFNlY3JlY3kNCg0KUFNLX0VDREhFIGluIFRMUyAxLjMgZG9l cyBwcm92aWRlIGZvcndhcmQgc2VjcmVjeSBmb3IgMS1SVFQgZGF0YSwgeWVzPw0KVGhpcyBpcyBh bHJlYWR5IGJldHRlciB0aGFuIFRMUyAxLjIgd2hlcmUgd2UgaGFkIG5vIHdheSB0byBkbyBmb3J3 YXJkLXNlY3JldCByZXN1bXB0aW9uLg0KSW4gdGhhdCBjYXNlLCB0aGUgY29uY2VybiBpcyBtYWlu bHkgZm9yIDAtUlRULCB3aGljaCBJIGFncmVlIGlzIGhhcmRlciB0byBnZXQgcmlnaHQuDQoNCg0K DQowUlRUIGFuZCBTYWZldHkNCkkgc2VlIGF0IGxlYXN0IHRocmVlIGRpZmZlcmVudCBjaGFsbGVu Z2VzIHdpdGggMFJUVCBhcyBkZWZpbmVkLiBUaGUgZmlyc3QgaXMgYSBnZW5lcmFsIGFuZCBoaWdo IGxldmVsIG9uZTogd2Ugc2VlbSB0byB3aWxsaW5nIHRvIGFjY2VwdCBhICJsb3dlciIgbGV2ZWwg b2Ygc2VjdXJpdHkgZm9yIDBSVFQgZGF0YSAoZS5nLiBubyBGUywgZXZlbiBpZiB0aGUgcmVzdCBv ZiB0aGUgc2Vzc2lvbiBoYXMgaXQpLiBXaHk/IFdoYXQgaXMgaXQgd2UgdGhpbmsgaXMgc3BlY2lh bCBhYm91dCB0aGlzIGRhdGEgdGhhdCBpdCBpcyAibGVzcyIgd29ydGggcHJvdGVjdGluZz8gc3Vy ZWx5IHRoZXJlIGFyZSB2ZXJ5IHNlbnNpdGl2ZSB0aGluZ3MgaW4gdXJscywgc3VyZWx5IHRoZXJl IGFyZSBwb3RlbnRpYWwgb3JhY2xlcyBhbmQgb3RoZXIgdGhpbmdzIGluIHRoZXJlIHRvbz8gSXQg anVzdCBzZWVtcyBzdXBlciBzdHJhbmdlIHRvIG1lLg0KDQpJIHdvbmRlciBpZiB0aGUgUVVJQyBm b2xrcyBoYXZlIGFuIGFuc3dlciB0byB0aGlzIHF1ZXN0aW9uPyBJdCB3b3VsZCBiZSBnb29kIHRv IGdhdGhlciDigJx0eXBpY2Fs4oCdIGludGVuZGVkIHVzZSBjYXNlcyBvZiAwLVJUVCBkYXRhLg0K SW4gYW55IGNhc2UsIGl0IGlzIGdvb2QgdG8gZGlzdGluZ3Vpc2ggdGhpcyBmb3J3YXJkIHNlY3Jl Y3kgY29uY2VybiBmcm9tIHJlcGxheSwgYmVjYXVzZSBzZWNyZWN5IGlzIGluIHRoZSBjb250cm9s IG9mIHRoZSBjbGllbnQsIHdobyBjYW4gY2hvb3NlIHRvIHNlbmQgb3Igbm90IHNlbmQgc2Vuc2l0 aXZlIGRhdGEsIGJ1dCByZXBsYXkgZGV0ZWN0aW9uIGlzIGluIHRoZSBoYW5kcyBvZiB0aGUgc2Vy dmVyLg0KDQoNCg0KVGhlIHNlY29uZCBjaGFsbGVuZ2UgaXMgdGhhdCB0aGUgcmVwbGF5YWJpbGl0 eSBvZiB0aGUgMFJUVCBwb3NlcyBhIGNyeXB0b2dyYXBoaWMgc2FmZXR5IGNoYWxsZW5nZS4gVGFr ZSBMdWNreTEzIC0gd2hpY2ggaXMgYSBicmlsbGlhbnQgYXR0YWNrIGFuZCBpcyBzdHVubmluZ2x5 IGVmZmVjdGl2ZSBhZ2FpbnN0IERUTFMgYmVjYXVzZSBpdCBpcyBzbyBlYXN5IHRvIHJlcGxheSBv dmVyIGFuZCBvdmVyOyBiYXJlbHkgbmVlZGluZyB0byBjaGFuZ2UgYW55IHBhcmFtZXRlcnMgLSBh bmQgbGV0IHRoZSBzZXJ2ZXIgZG8gdGhlIHdvcmsuIDBSVFQgbG9va3MgdmVyeSBzaW1pbGFyLiBJ dCBkb2Vzbid0IHNlZW0gd2lzZSB0byBsZXQgY2lwaGVyIHRleHQgbWFuaXB1bGF0b3JzIHRha2Ug YXMgbWFueSBjcmFja3MgYXQgdGhlIHdoaXAgYXMgdGhleSdkIGxpa2UuDQpUaGUgdGhpcmQgY2hh bGxlbmdlIGlzIHRoYXQgdGhlIDBSVFQgcGxhaW50ZXh0IGRhdGEgaXRzZWxmIG1heSBub3QgYmUg c2FmZSB0byByZXBsYXk7IHRoYXQgaXMgdGhhdCBpdCBtaWdodCB0cmlnZ2VyIHNvbWUga2luZCBv ZiBub24taWRlbXBvdGVudCBhY3Rpb24uIElkZW1wb3RlbmNlIGlzIHJlYWxseSByZWFsbHkgaGFy ZCwgaXQgaXNuJ3Qgc2FmZSB0byBzaW1wbHkgcGx1ZyBpbiBhIHJlcGxheWFibGUgc2VjdGlvbiB0 byBleGlzdGluZyBwcm90b2NvbHMuIFRoZXJlJ3MgYWxzbyBhIGh1Z2UgZGlmZmVyZW5jZSBiZXR3 ZWVuIGJlaW5nIHRvbGVyYW50IHRvIGEgc21hbGwgbnVtYmVyIG9mIHJlcGxheXMsIGFuZCBhIGxh cmdlIHVuYm91bmRlZCBudW1iZXIuIEZvciBleGFtcGxlOiBhIGxhcmdlIHVuYm91bmRlZCBudW1i ZXIgbWF5IGJlIHVzZWQgdG8gZ2VuZXJhdGUgRE9TIGF0dGFja3MgYWdhaW5zdCAgdGhyb3R0bGVz IGFuZCBxdW90YXMuDQoNClllcywgZGV0ZWN0aW5nIGFuZCBwcmV2ZW50aW5nIHJlcGxheXMgYnkg ZGVmYXVsdCB3b3VsZCBiZSBnb29kLg0KSG93ZXZlciwgSSB3b3VsZG7igJl0IHRpZSB0aGlzIGlu IHdpdGggdGhlIHNlc3Npb24gbWVjaGFuaXNtLg0KV291bGRu4oCZdCB3ZSB3YW50IHRvIHByZXZl bnQgcmVwbGF5IG9mIERIIDAtUlRUIHJlcXVlc3RzPw0KDQpCZXN0LA0KS2FydGhpaw0KDQoNCg0K DQoNClRoZSB0aGlyZCBjaGFsbGVuZ2UgaXMgdGhhdCB0aGUgMFJUVCBwbGFpbnRleHQgZGF0YSBp dHNlbGYgbWF5IG5vdCBiZSBzYWZlIHRvIHJlcGxheTsgdGhhdCBpcyB0aGF0IGl0IG1pZ2h0IHRy aWdnZXIgc29tZSBraW5kIG9mIG5vbi1pZGVtcG90ZW50IGFjdGlvbi4gSWRlbXBvdGVuY2UgaXMg cmVhbGx5IHJlYWxseSBoYXJkLCBpdCBpc24ndCBzYWZlIHRvIHNpbXBseSBwbHVnIGluIGEgcmVw bGF5YWJsZSBzZWN0aW9uIHRvIGV4aXN0aW5nIHByb3RvY29scy4gVGhlcmUncyBhbHNvIGEgaHVn ZSBkaWZmZXJlbmNlIGJldHdlZW4gYmVpbmcgdG9sZXJhbnQgdG8gYSBzbWFsbCBudW1iZXIgb2Yg cmVwbGF5cywgYW5kIGEgbGFyZ2UgdW5ib3VuZGVkIG51bWJlci4gRm9yIGV4YW1wbGU6IGEgbGFy Z2UgdW5ib3VuZGVkIG51bWJlciBtYXkgYmUgdXNlZCB0byBnZW5lcmF0ZSBET1MgYXR0YWNrcyBh Z2FpbnN0ICB0aHJvdHRsZXMgYW5kIHF1b3Rhcy4NCg0KVHlpbmcgdGhpbmdzIHRvZ2V0aGVyDQpT aG9ydCBvZiBzb21lIGtpbmQgb2YgdHJhbnNhY3Rpb25hbCBsb2NraW5nIHByb3RvY29sIGR1cmlu ZyBUTFMgaGFuZHNoYWtlcywgSSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHNjaGVtZSB0aGF0IGNh biBwZXJmZWN0bHkgcHJldmVudCByZXBsYXkuIEJpbGwgQ294JyBhbmFseXNpcyBpcyBhIHJlYWxs eSBnb29kIG9uZSBoZXJlLiBCdXQgSSdkIGxpa2UgdG8gb2JzZXJ2ZSB0aGF0IHRoZSBzb3J0IG9m IHNpbmdsZS11c2Utc2Vzc2lvbi1pZCBjYWNoZSBvdXRsaW5lZCBhYm92ZSBoYXMgYSBuaWNlIHBy b3BlcnR5IHRoYXQgaXQgbWFrZXMgZm9yIGEgc29ydCBvZiBzdHJpa2UgcmVnaXN0ZXIuIFNpbmNl IHRoZSBzZXJ2ZXItc2lkZSBpbXBsZW1lbnRvciBpcyBpbmNlbnRpdml6ZWQgdG8gZXZpY3QgZW50 cmllcywgb3IgYXQgbGVhc3QgbWFyayB0aGVtIGFzIHVzZWQsIHNvIHRoYXQgdGhlIHNsb3QgaXMg YXZhaWxhYmxlIGZvciByZS11c2U7IHRoYXQgY2FuIGJlIGRvdWJsZWQtdXAgYXMgYSAid2UndmUg c2VlbiB0aGlzIGFscmVhZHkiIHNpZ25hbC4gVGhpcyByZWR1Y2VzIHRoZSByZXBsYXkgd2luZG93 IHRvIHRoZSB0aW1lIHBlcmlvZCBmb3IgdGhhdCBzaWduYWwgdG8gcHJvcGFnYXRlIChlLmcuIGZv ciBhbiBldmljdGlvbiB0byBoYXBwZW4gZnJvbSB0aGUgY2FjaGUpLg0KDQpTbyAwUlRUIGRhdGEg Y291bGQgYmUgZW5jcnlwdGVkIHVuZGVyIHRoZSByZXN1bXB0aW9uIHNlc3Npb24gaWQuIFRoYXQg Y3JlYXRlcyB0aGUgY2hhbGxlbmdlIHRoYXQgdGhlIHNlc3Npb24gbWlnaHQgbm90IGJlIHRoZXJl IGFueSBtb3JlLCBzbyB0aGUgc2VydmVyIG1heSBub3QgYmUgYWJsZSB0byBkZWNyeXB0IHRoZSAw UlRUIGRhdGEuIEkgYWN0dWFsbHkgdGhpbmsgdGhpcyBpcyBhIHBsdXMsIGFuZCBsaW5lcyB1cCB3 aXRoIGEgc2VwYXJhdGUgaW1wb3J0YW50IGNoYW5nZSBJIHRoaW5rIGlzIG5lY2Vzc2FyeSAtIHRo ZSAwUlRUIGRhdGEgc2hvdWxkbid0IGJlIGFwcGxpY2F0aW9uIGRhdGEuIEl0IHNob3VsZCBiZSBh IHNlcGFyYXRlLCBvcHRpb25hbCwgc3RyZWFtLiBJIGZpbmQgaXQgaGVscGZ1bCB0byB0aGluayBv ZiBpdCBhcyBhIGhpbnQsIHNvIGl0IGNvdWxkIGJlIGNhbGxlZCAicmVwbGF5YWJsZV9oaW50Ii4g SW5zdGVhZCBvZiBicmVha2luZyBhcGFydCBhbiBleGlzdGluZyBwcm90b2NvbCBhbmQgcHV0dGlu ZyBzb21lIG9mIGl0IGluIHRoZSBlYXJseSBkYXRhIGFuZCBzb21lIGluIHRoZSBhcHBsaWNhdGlv biBkYXRhIHRyYW5zcGFyZW50bHkgKGEgZGlzYXN0ZXIgaW4gd2FpdGluZyksIHRoZSBjbGllbnQg YW5kIHNlcnZlciB3b3VsZCBoYXZlIHRvIGZvcm1hbGx5IGFncmVlIG9uIHRoZSBraW5kIG9mIGRh dGEgdGhhdCBjb3VsZCBiZSBpbiBhICJyZXBsYXlhYmxlX2hpbnQiLiBUaGlzIGdvZXMgYSBsb25n IHdheSB0byBtaXRpZ2F0aW5nIG1hbnkgcHJvdG9jb2wgbGV2ZWwgaWRlbXBvdGVuY3kgY29uY2Vy bnMsIGFuZCBoYXMgbm8gaW1wYWN0IG9uIHRoZSBraW5kIG9mIHByZS1mZXRjaGluZyBwZW9wbGUg d2FudCB0byBkbyBmb3IgSFRUUCBhbmQgb3RoZXIgcHJvdG9jb2xzLiBBdCBhIGJhcmUgbWluaW11 bSwgSSB0aGluayB3ZSBzaG91bGQgbWFrZSB0aGlzIGNoYW5nZS4NCg0KTGFzdGx5LCBhbmQgdGhp cyBpcyBhIGxpdHRsZSBjcmF6eSBidXQgSSBoYXZlbid0IGxldCB0aGF0IHN0b3AgbWUgYmVmb3Jl IC4uLiB0byBndWFyZCBhZ2FpbnN0IHRoZSBzbWFsbGVyIHJlcGxheSB3aW5kb3cgYW5kIGlkZW1w b3RlbmN5IHByb2JsZW1zIGF0IHRoZSBhcHBsaWNhdGlvbiBsZXZlbHMsY2xpZW50cyBzaG91bGQg b2NjYXNpb25hbGx5IHNlbmQgZHVwbGljYXRlIGFuZCB1bnJlbGF0ZWQgaGludHMsIGp1c3Qgb3Bw b3J0dW5pc3RpY2FsbHkuIFRoaXMga2VlcHMgdGhlIHNlcnZlciBzaWRlIGFwcGxpY2F0aW9uICJv biBub3RpY2UiIHRoYXQgdGhhdCBraW5kIG9mIGNyYXppbmVzcyBjYW4gb2NjdXIsIGFuZCBiZXR0 ZXIgdG8gaGF2ZSBpdCBoYXBwZW4gYSBsaXR0bGUgYWxsIG9mIHRoZSB0aW1lIGluIGEgY29udHJv bGxlZCB3YXksIHRoYW4gcmFyZWx5IGJ5IGF0dGFja2Vycy4NCg0KU3VtbWFyeQ0KQSBjb21tb24g dGhlbWUgaW4gdGhlIGFib3ZlIGlzIHRoYXQgaXQgbWFrZXMgdGhpbmdzIG1vcmUgZXhwZW5zaXZl IGZvciBzZXJ2ZXItc2lkZSBpbXBsZW1lbnRvcnMsIGFuZCB0aGF0IHN1Y2tzIC0gYnV0IEkgZG9u J3Qgc2VlIGFub3RoZXIgd2F5IHRvIGF2b2lkIHNvbWUgb2YgdGhlIHBpdGZhbGxzIGhlcmU7IGFu ZCBJJ20gdW5oYXBweSB3aXRoIHRoZSBzdGF0ZSBvZiB0aWNrZXRzIHRvZGF5LiBJZiBJJ20gb24g bXkgb3duIG9uIHRoYXQsIEknZCBiZSBpbnRlcmVzdGVkIGluIHdoYXQga2luZHMgb2YgZGF0YSBw ZW9wbGUgbWlnaHQga2luZCBjb252aW5jaW5nLiBNeSBvd24gaW1wcmVzc2lvbnMgY29tZSBmcm9t IGJlaW5nIGFuIEFwYWNoZSBodHRwZCBkZXZlbG9wZXIgYW5kIGFzc2lzdGluZyBwZW9wbGUgd2l0 aCBjb25maWd1cmF0aW9ucyBhbmQgcnVubmluZyB3b3Jrc2hvcHMgYXQgY29uZmVyZW5jZXMuIEl0 J3Mgbm90IHNjaWVudGlmaWMsIGJ1dCB0aGUgcHJldmFsZW5jZSBvZiBub24tcm90YXRpb24gaXMg c28gc2V2ZXJlIGluIG15IHNhbXBsZSBzZXQgdGhhdCBJJ20gY29udmluY2VkIGl0J3MgdGhlIG5v cm0uDQoNCi0tDQpDb2xtDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3 dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZkYXRhPTAxJTdjMDElN2NBbmRy ZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjODhkMzg0ZTE2ZDc5NGEyM2JlMGMwOGQzNTc1MDU0 M2QlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9SVU5YVlXJTJi Nkd0MHBuYklWWG5UMnlHTnpPQ0dmbXZ2ZyUyZlk1eUZoaUtsWVklM2Q+DQoNCg== --_000_BLUPR03MB139671E889569CAD5E65E27D8C860BLUPR03MB1396namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob3Qgc2VuZGluZyBj b29raWVzL2F1dGh6IGhlYWRlcnMgaW4gMC1SVFQgd291bGQgc29sdmUgYSBwYXJ0IG9mIHRoZSBw cm9ibGVtLCBidXQgd2lsbCBicm93c2VyIHZlbmRvcnMgZ28gZm9yIHRoYXQ/IEkgY291bGQgYmUg d3JvbmcsIGJ1dCB0aGVyZSBzZWVtcyB0byBiZSBjb25zaWRlcmFibGUNCiBpbnRlcmVzdCBpbiAw LVJUVCBUb2tlbiBCaW5kaW5n4oCmLiBzbyBmb2xrcyBtdXN0IGJlIHBsYW5uaW5nIG9uIHNlbmRp bmcgdG9rZW5zPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBLYXJ0 aGlrZXlhbiBCaGFyZ2F2YW4gW21haWx0bzprYXJ0aGlrLmJoYXJnYXZhbkBnbWFpbC5jb21dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAyOCwgMjAxNiAyOjMxIFBNPGJyPg0KPGI+ VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gQ29sbSBNYWNDw6FydGhhaWdoICZsdDtjb2xtQGFsbGNvc3RzLm5ldCZn dDs7IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUmVzdW1wdGlv biBhbmQgRm9yd2FyZCBTZWNyZWN5LCAwLVJUVCBhbmQgU2FmZXR5PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdCI+Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj7igKYgYmVjYXVzZSBzZWNyZWN5IGlzIGluIHRoZSBjb250cm9sIG9mIHRo ZSBjbGllbnQsIHdobyBjYW4gY2hvb3NlIHRvIHNlbmQgb3Igbm90IHNlbmQNCiBzZW5zaXRpdmUg ZGF0YeKApjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkdlbmVyYWxseSwgaG93IGNhbiBhIGJy b3dzZXIgZGlzdGluZ3Vpc2ggc2Vuc2l0aXZlIGRhdGE/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJ5IG5vdCBzZW5kaW5nIGNvb2tpZXMgb3IgYXV0aG9yaXphdGlvbiBoZWFkZXJzLCBmb3Ig ZXhhbXBsZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRy ZWk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRMUw0KIFs8YSBocmVmPSJtYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzp0 bHMtYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkthcnRoaWtleWFuIEJoYXJnYXZhbjxi cj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5Nb25kYXksIE1hcmNoIDI4LCAyMDE2IDE6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkNvbG0gTWFjQ8Oh cnRoYWlnaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNvbG1AYWxsY29zdHMubmV0Ij48c3BhbiBzdHls ZT0iY29sb3I6cHVycGxlIj5jb2xtQGFsbGNvc3RzLm5ldDwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ dGxzQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtUTFNdIFJlc3VtcHRpb24g YW5kIEZvcndhcmQgU2VjcmVjeSwgMC1SVFQgYW5kIFNhZmV0eTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkxldCBtZSB0cnkgdG8gdW5kZXJzdGFuZCB0aGUgY29uY2VybnMgaGVyZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlJlc3VtcHRpb24gYW5kIEZvcndh cmQgU2VjcmVjeTwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UFNLX0VDREhFIGluIFRMUyAxLjMgZG9lcyBwcm92aWRlIGZvcndhcmQgc2VjcmVj eSBmb3IgMS1SVFQgZGF0YSwgeWVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBhbHJlYWR5IGJldHRlciB0 aGFuIFRMUyAxLjIgd2hlcmUgd2UgaGFkIG5vIHdheSB0byBkbyBmb3J3YXJkLXNlY3JldCByZXN1 bXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SW4gdGhhdCBjYXNlLCB0aGUgY29uY2VybiBpcyBtYWlubHkgZm9y IDAtUlRULCB3aGljaCBJIGFncmVlIGlzIGhhcmRlciB0byBnZXQgcmlnaHQuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj4wUlRUIGFuZCBTYWZldHk8L2I+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIGF0IGxlYXN0IHRocmVl IGRpZmZlcmVudCBjaGFsbGVuZ2VzIHdpdGggMFJUVCBhcyBkZWZpbmVkLiBUaGUgZmlyc3QgaXMg YSBnZW5lcmFsIGFuZCBoaWdoIGxldmVsIG9uZTogd2Ugc2VlbSB0byB3aWxsaW5nIHRvIGFjY2Vw dCBhICZxdW90O2xvd2VyJnF1b3Q7IGxldmVsIG9mIHNlY3VyaXR5IGZvciAwUlRUIGRhdGEgKGUu Zy4gbm8gRlMsIGV2ZW4gaWYgdGhlIHJlc3Qgb2YgdGhlIHNlc3Npb24gaGFzIGl0KS4gV2h5Pw0K IFdoYXQgaXMgaXQgd2UgdGhpbmsgaXMgc3BlY2lhbCBhYm91dCB0aGlzIGRhdGEgdGhhdCBpdCBp cyAmcXVvdDtsZXNzJnF1b3Q7IHdvcnRoIHByb3RlY3Rpbmc/IHN1cmVseSB0aGVyZSBhcmUgdmVy eSBzZW5zaXRpdmUgdGhpbmdzIGluIHVybHMsIHN1cmVseSB0aGVyZSBhcmUgcG90ZW50aWFsIG9y YWNsZXMgYW5kIG90aGVyIHRoaW5ncyBpbiB0aGVyZSB0b28/IEl0IGp1c3Qgc2VlbXMgc3VwZXIg c3RyYW5nZSB0byBtZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHdvbmRlciBpZiB0aGUgUVVJQyBmb2xrcyBoYXZlIGFuIGFuc3dlciB0 byB0aGlzIHF1ZXN0aW9uPyBJdCB3b3VsZCBiZSBnb29kIHRvIGdhdGhlciDigJx0eXBpY2Fs4oCd IGludGVuZGVkIHVzZSBjYXNlcyBvZiAwLVJUVCBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gYW55IGNhc2Us IGl0IGlzIGdvb2QgdG8gZGlzdGluZ3Vpc2ggdGhpcyBmb3J3YXJkIHNlY3JlY3kgY29uY2VybiBm cm9tIHJlcGxheSwgYmVjYXVzZSBzZWNyZWN5IGlzIGluIHRoZSBjb250cm9sIG9mIHRoZSBjbGll bnQsIHdobyBjYW4gY2hvb3NlIHRvIHNlbmQgb3Igbm90IHNlbmQgc2Vuc2l0aXZlIGRhdGEsIGJ1 dCByZXBsYXkgZGV0ZWN0aW9uIGlzIGluIHRoZSBoYW5kcyBvZiB0aGUgc2VydmVyLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2Vjb25kIGNoYWxsZW5nZSBpcyB0aGF0IHRo ZSByZXBsYXlhYmlsaXR5IG9mIHRoZSAwUlRUIHBvc2VzIGEgY3J5cHRvZ3JhcGhpYyBzYWZldHkg Y2hhbGxlbmdlLiBUYWtlIEx1Y2t5MTMgLSB3aGljaCBpcyBhIGJyaWxsaWFudCBhdHRhY2sgYW5k IGlzIHN0dW5uaW5nbHkgZWZmZWN0aXZlIGFnYWluc3QgRFRMUyBiZWNhdXNlIGl0IGlzIHNvIGVh c3kgdG8gcmVwbGF5IG92ZXIgYW5kIG92ZXI7IGJhcmVseQ0KIG5lZWRpbmcgdG8gY2hhbmdlIGFu eSBwYXJhbWV0ZXJzIC0gYW5kIGxldCB0aGUgc2VydmVyIGRvIHRoZSB3b3JrLiAwUlRUIGxvb2tz IHZlcnkgc2ltaWxhci4gSXQgZG9lc24ndCBzZWVtIHdpc2UgdG8gbGV0IGNpcGhlciB0ZXh0IG1h bmlwdWxhdG9ycyB0YWtlIGFzIG1hbnkgY3JhY2tzIGF0IHRoZSB3aGlwIGFzIHRoZXknZCBsaWtl LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHRoaXJkIGNoYWxsZW5nZSBpcyB0aGF0IHRoZSAwUlRUIHBsYWludGV4dCBkYXRhIGl0c2Vs ZiBtYXkgbm90IGJlIHNhZmUgdG8gcmVwbGF5OyB0aGF0IGlzIHRoYXQgaXQgbWlnaHQgdHJpZ2dl ciBzb21lIGtpbmQgb2Ygbm9uLWlkZW1wb3RlbnQgYWN0aW9uLiBJZGVtcG90ZW5jZSBpcyByZWFs bHkgcmVhbGx5IGhhcmQsIGl0IGlzbid0IHNhZmUgdG8gc2ltcGx5IHBsdWcgaW4gYSByZXBsYXlh YmxlIHNlY3Rpb24NCiB0byBleGlzdGluZyBwcm90b2NvbHMuIFRoZXJlJ3MgYWxzbyBhIGh1Z2Ug ZGlmZmVyZW5jZSBiZXR3ZWVuIGJlaW5nIHRvbGVyYW50IHRvIGEgc21hbGwgbnVtYmVyIG9mIHJl cGxheXMsIGFuZCBhIGxhcmdlIHVuYm91bmRlZCBudW1iZXIuIEZvciBleGFtcGxlOiBhIGxhcmdl IHVuYm91bmRlZCBudW1iZXIgbWF5IGJlIHVzZWQgdG8gZ2VuZXJhdGUgRE9TIGF0dGFja3MgYWdh aW5zdCAmbmJzcDt0aHJvdHRsZXMgYW5kIHF1b3Rhcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlllcywgZGV0ZWN0aW5nIGFuZCBwcmV2ZW50aW5nIHJlcGxheXMgYnkgZGVm YXVsdCB3b3VsZCBiZSBnb29kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciwgSSB3b3VsZG7igJl0IHRpZSB0 aGlzIGluIHdpdGggdGhlIHNlc3Npb24gbWVjaGFuaXNtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGRu 4oCZdCB3ZSB3YW50IHRvIHByZXZlbnQgcmVwbGF5IG9mIERIIDAtUlRUIHJlcXVlc3RzPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2FydGhpazxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHRoaXJkIGNoYWxsZW5nZSBpcyB0aGF0IHRoZSAwUlRUIHBsYWludGV4dCBkYXRhIGl0c2Vs ZiBtYXkgbm90IGJlIHNhZmUgdG8gcmVwbGF5OyB0aGF0IGlzIHRoYXQgaXQgbWlnaHQgdHJpZ2dl ciBzb21lIGtpbmQgb2Ygbm9uLWlkZW1wb3RlbnQgYWN0aW9uLiBJZGVtcG90ZW5jZSBpcyByZWFs bHkgcmVhbGx5IGhhcmQsIGl0IGlzbid0IHNhZmUgdG8gc2ltcGx5IHBsdWcgaW4gYSByZXBsYXlh YmxlIHNlY3Rpb24NCiB0byBleGlzdGluZyBwcm90b2NvbHMuIFRoZXJlJ3MgYWxzbyBhIGh1Z2Ug ZGlmZmVyZW5jZSBiZXR3ZWVuIGJlaW5nIHRvbGVyYW50IHRvIGEgc21hbGwgbnVtYmVyIG9mIHJl cGxheXMsIGFuZCBhIGxhcmdlIHVuYm91bmRlZCBudW1iZXIuIEZvciBleGFtcGxlOiBhIGxhcmdl IHVuYm91bmRlZCBudW1iZXIgbWF5IGJlIHVzZWQgdG8gZ2VuZXJhdGUgRE9TIGF0dGFja3MgYWdh aW5zdCAmbmJzcDt0aHJvdHRsZXMgYW5kIHF1b3Rhcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+VHlpbmcgdGhpbmdzIHRvZ2V0aGVyPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hvcnQgb2Yg c29tZSBraW5kIG9mIHRyYW5zYWN0aW9uYWwgbG9ja2luZyBwcm90b2NvbCBkdXJpbmcgVExTIGhh bmRzaGFrZXMsIEkgZG9uJ3QgdGhpbmsgdGhlcmUgaXMgYSBzY2hlbWUgdGhhdCBjYW4gcGVyZmVj dGx5IHByZXZlbnQgcmVwbGF5LiBCaWxsIENveCcgYW5hbHlzaXMgaXMgYSByZWFsbHkgZ29vZCBv bmUgaGVyZS4gQnV0IEknZCBsaWtlIHRvIG9ic2VydmUgdGhhdCB0aGUgc29ydCBvZiBzaW5nbGUt dXNlLXNlc3Npb24taWQNCiBjYWNoZSBvdXRsaW5lZCBhYm92ZSBoYXMgYSBuaWNlIHByb3BlcnR5 IHRoYXQgaXQgbWFrZXMgZm9yIGEgc29ydCBvZiBzdHJpa2UgcmVnaXN0ZXIuIFNpbmNlIHRoZSBz ZXJ2ZXItc2lkZSBpbXBsZW1lbnRvciBpcyBpbmNlbnRpdml6ZWQgdG8gZXZpY3QgZW50cmllcywg b3IgYXQgbGVhc3QgbWFyayB0aGVtIGFzIHVzZWQsIHNvIHRoYXQgdGhlIHNsb3QgaXMgYXZhaWxh YmxlIGZvciByZS11c2U7IHRoYXQgY2FuIGJlIGRvdWJsZWQtdXAgYXMgYSAmcXVvdDt3ZSd2ZQ0K IHNlZW4gdGhpcyBhbHJlYWR5JnF1b3Q7IHNpZ25hbC4gVGhpcyByZWR1Y2VzIHRoZSByZXBsYXkg d2luZG93IHRvIHRoZSB0aW1lIHBlcmlvZCBmb3IgdGhhdCBzaWduYWwgdG8gcHJvcGFnYXRlIChl LmcuIGZvciBhbiBldmljdGlvbiB0byBoYXBwZW4gZnJvbSB0aGUgY2FjaGUpLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyAwUlRUIGRhdGEgY291bGQgYmUgZW5jcnlwdGVkIHVu ZGVyIHRoZSByZXN1bXB0aW9uIHNlc3Npb24gaWQuIFRoYXQgY3JlYXRlcyB0aGUgY2hhbGxlbmdl IHRoYXQgdGhlIHNlc3Npb24gbWlnaHQgbm90IGJlIHRoZXJlIGFueSBtb3JlLCBzbyB0aGUgc2Vy dmVyIG1heSBub3QgYmUgYWJsZSB0byBkZWNyeXB0IHRoZSAwUlRUIGRhdGEuIEkgYWN0dWFsbHkg dGhpbmsgdGhpcyBpcyBhIHBsdXMsIGFuZCBsaW5lcw0KIHVwIHdpdGggYSBzZXBhcmF0ZSBpbXBv cnRhbnQgY2hhbmdlIEkgdGhpbmsgaXMgbmVjZXNzYXJ5IC0gdGhlIDBSVFQgZGF0YSBzaG91bGRu J3QgYmUgYXBwbGljYXRpb24gZGF0YS4gSXQgc2hvdWxkIGJlIGEgc2VwYXJhdGUsIG9wdGlvbmFs LCBzdHJlYW0uIEkgZmluZCBpdCBoZWxwZnVsIHRvIHRoaW5rIG9mIGl0IGFzIGEgaGludCwgc28g aXQgY291bGQgYmUgY2FsbGVkICZxdW90O3JlcGxheWFibGVfaGludCZxdW90Oy4gSW5zdGVhZCBv ZiBicmVha2luZyBhcGFydA0KIGFuIGV4aXN0aW5nIHByb3RvY29sIGFuZCBwdXR0aW5nIHNvbWUg b2YgaXQgaW4gdGhlIGVhcmx5IGRhdGEgYW5kIHNvbWUgaW4gdGhlIGFwcGxpY2F0aW9uIGRhdGEg dHJhbnNwYXJlbnRseSAoYSBkaXNhc3RlciBpbiB3YWl0aW5nKSwgdGhlIGNsaWVudCBhbmQgc2Vy dmVyIHdvdWxkIGhhdmUgdG8gZm9ybWFsbHkgYWdyZWUgb24gdGhlIGtpbmQgb2YgZGF0YSB0aGF0 IGNvdWxkIGJlIGluIGEgJnF1b3Q7cmVwbGF5YWJsZV9oaW50JnF1b3Q7LiBUaGlzIGdvZXMgYSBs b25nDQogd2F5IHRvIG1pdGlnYXRpbmcgbWFueSBwcm90b2NvbCBsZXZlbCBpZGVtcG90ZW5jeSBj b25jZXJucywgYW5kIGhhcyBubyBpbXBhY3Qgb24gdGhlIGtpbmQgb2YgcHJlLWZldGNoaW5nIHBl b3BsZSB3YW50IHRvIGRvIGZvciBIVFRQIGFuZCBvdGhlciBwcm90b2NvbHMuIEF0IGEgYmFyZSBt aW5pbXVtLCBJIHRoaW5rIHdlIHNob3VsZCBtYWtlIHRoaXMgY2hhbmdlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXN0bHksIGFuZCB0aGlzIGlzIGEgbGl0dGxlIGNyYXp5IGJ1 dCBJIGhhdmVuJ3QgbGV0IHRoYXQgc3RvcCBtZSBiZWZvcmUgLi4uIHRvIGd1YXJkIGFnYWluc3Qg dGhlIHNtYWxsZXIgcmVwbGF5IHdpbmRvdyBhbmQgaWRlbXBvdGVuY3kgcHJvYmxlbXMgYXQgdGhl IGFwcGxpY2F0aW9uIGxldmVscyxjbGllbnRzIHNob3VsZCBvY2Nhc2lvbmFsbHkgc2VuZCBkdXBs aWNhdGUgYW5kIHVucmVsYXRlZCBoaW50cywganVzdA0KIG9wcG9ydHVuaXN0aWNhbGx5LiBUaGlz IGtlZXBzIHRoZSBzZXJ2ZXIgc2lkZSBhcHBsaWNhdGlvbiAmcXVvdDtvbiBub3RpY2UmcXVvdDsg dGhhdCB0aGF0IGtpbmQgb2YgY3JhemluZXNzIGNhbiBvY2N1ciwgYW5kIGJldHRlciB0byBoYXZl IGl0IGhhcHBlbiBhIGxpdHRsZSBhbGwgb2YgdGhlIHRpbWUgaW4gYSBjb250cm9sbGVkIHdheSwg dGhhbiByYXJlbHkgYnkgYXR0YWNrZXJzLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPlN1bW1hcnk8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BIGNvbW1vbiB0aGVtZSBpbiB0aGUg YWJvdmUgaXMgdGhhdCBpdCBtYWtlcyB0aGluZ3MgbW9yZSBleHBlbnNpdmUgZm9yIHNlcnZlci1z aWRlIGltcGxlbWVudG9ycywgYW5kIHRoYXQgc3Vja3MgLSBidXQgSSBkb24ndCBzZWUgYW5vdGhl ciB3YXkgdG8gYXZvaWQgc29tZSBvZiB0aGUgcGl0ZmFsbHMgaGVyZTsgYW5kIEknbSB1bmhhcHB5 IHdpdGggdGhlIHN0YXRlIG9mIHRpY2tldHMgdG9kYXkuIElmIEknbSBvbg0KIG15IG93biBvbiB0 aGF0LCBJJ2QgYmUgaW50ZXJlc3RlZCBpbiB3aGF0IGtpbmRzIG9mIGRhdGEgcGVvcGxlIG1pZ2h0 IGtpbmQgY29udmluY2luZy4gTXkgb3duIGltcHJlc3Npb25zIGNvbWUgZnJvbSBiZWluZyBhbiBB cGFjaGUgaHR0cGQgZGV2ZWxvcGVyIGFuZCBhc3Npc3RpbmcgcGVvcGxlIHdpdGggY29uZmlndXJh dGlvbnMgYW5kIHJ1bm5pbmcgd29ya3Nob3BzIGF0IGNvbmZlcmVuY2VzLiBJdCdzIG5vdCBzY2ll bnRpZmljLCBidXQgdGhlIHByZXZhbGVuY2UNCiBvZiBub24tcm90YXRpb24gaXMgc28gc2V2ZXJl IGluIG15IHNhbXBsZSBzZXQgdGhhdCBJJ20gY29udmluY2VkIGl0J3MgdGhlIG5vcm0uJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNv bG08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NClRMUyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5UTFNAaWV0Zi5vcmc8L3NwYW4+PC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm dGxzJmFtcDtkYXRhPTAxJTdjMDElN2NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdjODhk Mzg0ZTE2ZDc5NGEyM2JlMGMwOGQzNTc1MDU0M2QlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzEmYW1wO3NkYXRhPUlVOWFZVyUyYjZHdDBwbmJJVlhuVDJ5R056T0NHZm12dmcl MmZZNXlGaGlLbFlZJTNkIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rsczwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLUPR03MB139671E889569CAD5E65E27D8C860BLUPR03MB1396namp_-- From nobody Mon Mar 28 15:07:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E0312D13F for ; Mon, 28 Mar 2016 15:07:07 -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 xtfY7BP7yj-N for ; Mon, 28 Mar 2016 15:07:03 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7107F12D160 for ; Mon, 28 Mar 2016 15:07:03 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h65so99939745ywe.0 for ; Mon, 28 Mar 2016 15:07: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=uLzr4yBbR5vT1vxhyCsSQOtin8SNiAeScSErbZE9zCI=; b=1zT3i1hnNGZbo24GRf5zoL5wj/LSAKAxi9LTtxCTbpy2xDMK08oTXsdngfj9d/t23d 3lxgO78orsIWHflom1IUbmSBYaac8PaIvWXw96k/5e2K3S0oVG+/rhjxsZz5FcCiixAX UppS4jyGU1LVrY1kLXVupY/b8wnvuIFCMu+Agg/64JzG7dZX3Q6BoVqoRImzzaeDtkXS FQzomiChoMlBgXka/hWijS+XUeDjk+qRBWWqjfA3/GhFoyO0FgM4MOOZ8+Vi9Y5EEjI9 v2rY0ZagPfJwOYiEfGrP61vuPS3mtv36yYvx0AUS4/5QmCogzLm8OI/n5C5fpY0wlstz LwvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uLzr4yBbR5vT1vxhyCsSQOtin8SNiAeScSErbZE9zCI=; b=mu0QBykVpUQ6r4dA00Y95tvySXUVePGLENayWQaQaLXCtdiZmp4g6HC9YQ1WCm8VOo 2GbtvqwW7x9cwFTdV/pre0YQFZ4G0lxjORyQuC4aSB4T4Sh6F6nX5GOIS41Qq0v8/BoA loMRLmcZ8traumIADUVL7TbKXVt8FpYwdOiVHS5Kwx9+83K+LLpk8RJ6daBxlwNFRLMo x4ZNv4xkurS8YQuGAf8+EVkZbvGFE6SYVHDbLoknZRG2Et8IwfvJCcvql9p7h8PC1dio 3sQ1ND4MU4D8RcLfjTnysN7Yyp0bqFe7ez74IXwbQO1RLvo1o6nk96Xm/95FkeLbmyDu lQMg== X-Gm-Message-State: AD7BkJIgUDjHNvCI9rByfmVIzPl2WJ+tebulbXsQES845NqO3ChIfZ2B5Ce9BTfQGbDsVkC1UDFtjL7YWx7mcg== X-Received: by 10.129.152.10 with SMTP id p10mr4632476ywg.129.1459202822601; Mon, 28 Mar 2016 15:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Mon, 28 Mar 2016 15:06:23 -0700 (PDT) In-Reply-To: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> From: Eric Rescorla Date: Mon, 28 Mar 2016 15:06:23 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c0bbf62e5af59052f23213a Archived-At: Cc: "karthik@messengeruser.com" , "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:07:07 -0000 --94eb2c0bbf62e5af59052f23213a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, I believe that this is what people want. On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov wrote: > Not sending cookies/authz headers in 0-RTT would solve a part of the > problem, but will browser vendors go for that? I could be wrong, but ther= e > seems to be considerable interest in 0-RTT Token Binding=E2=80=A6. so fol= ks must be > planning on sending tokensJ. > > > > *From:* Karthikeyan Bhargavan [mailto:karthik.bhargavan@gmail.com] > *Sent:* Monday, March 28, 2016 2:31 PM > *To:* Andrei Popov > *Cc:* Colm MacC=C3=A1rthaigh ; tls@ietf.org > > *Subject:* Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety > > > > =C3=98 =E2=80=A6 because secrecy is in the control of the client, who ca= n choose to > send or not send sensitive data=E2=80=A6 > > Generally, how can a browser distinguish sensitive data? > > > > By not sending cookies or authorization headers, for example? > > > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org ] *On > Behalf Of *Karthikeyan Bhargavan > *Sent:* Monday, March 28, 2016 1:31 PM > *To:* Colm MacC=C3=A1rthaigh > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety > > > > Let me try to understand the concerns here. > > > > > *Resumption and Forward Secrecy* > > > > PSK_ECDHE in TLS 1.3 does provide forward secrecy for 1-RTT data, yes? > > This is already better than TLS 1.2 where we had no way to do > forward-secret resumption. > > In that case, the concern is mainly for 0-RTT, which I agree is harder to > get right. > > > > > *0RTT and Safety* > > I see at least three different challenges with 0RTT as defined. The first > is a general and high level one: we seem to willing to accept a "lower" > level of security for 0RTT data (e.g. no FS, even if the rest of the > session has it). Why? What is it we think is special about this data that > it is "less" worth protecting? surely there are very sensitive things in > urls, surely there are potential oracles and other things in there too? I= t > just seems super strange to me. > > > > I wonder if the QUIC folks have an answer to this question? It would be > good to gather =E2=80=9Ctypical=E2=80=9D intended use cases of 0-RTT data= . > > In any case, it is good to distinguish this forward secrecy concern from > replay, because secrecy is in the control of the client, who can choose t= o > send or not send sensitive data, but replay detection is in the hands of > the server. > > > > > The second challenge is that the replayability of the 0RTT poses a > cryptographic safety challenge. Take Lucky13 - which is a brilliant attac= k > and is stunningly effective against DTLS because it is so easy to replay > over and over; barely needing to change any parameters - and let the serv= er > do the work. 0RTT looks very similar. It doesn't seem wise to let cipher > text manipulators take as many cracks at the whip as they'd like. > > The third challenge is that the 0RTT plaintext data itself may not be saf= e > to replay; that is that it might trigger some kind of non-idempotent > action. Idempotence is really really hard, it isn't safe to simply plug i= n > a replayable section to existing protocols. There's also a huge differenc= e > between being tolerant to a small number of replays, and a large unbounde= d > number. For example: a large unbounded number may be used to generate DOS > attacks against throttles and quotas. > > > > Yes, detecting and preventing replays by default would be good. > > However, I wouldn=E2=80=99t tie this in with the session mechanism. > > Wouldn=E2=80=99t we want to prevent replay of DH 0-RTT requests? > > > > Best, > > Karthik > > > > > > > > > The third challenge is that the 0RTT plaintext data itself may not be saf= e > to replay; that is that it might trigger some kind of non-idempotent > action. Idempotence is really really hard, it isn't safe to simply plug i= n > a replayable section to existing protocols. There's also a huge differenc= e > between being tolerant to a small number of replays, and a large unbounde= d > number. For example: a large unbounded number may be used to generate DOS > attacks against throttles and quotas. > > > > *Tying things together* > > Short of some kind of transactional locking protocol during TLS > handshakes, I don't think there is a scheme that can perfectly prevent > replay. Bill Cox' analysis is a really good one here. But I'd like to > observe that the sort of single-use-session-id cache outlined above has a > nice property that it makes for a sort of strike register. Since the > server-side implementor is incentivized to evict entries, or at least mar= k > them as used, so that the slot is available for re-use; that can be > doubled-up as a "we've seen this already" signal. This reduces the replay > window to the time period for that signal to propagate (e.g. for an > eviction to happen from the cache). > > > > So 0RTT data could be encrypted under the resumption session id. That > creates the challenge that the session might not be there any more, so th= e > server may not be able to decrypt the 0RTT data. I actually think this is= a > plus, and lines up with a separate important change I think is necessary = - > the 0RTT data shouldn't be application data. It should be a separate, > optional, stream. I find it helpful to think of it as a hint, so it could > be called "replayable_hint". Instead of breaking apart an existing protoc= ol > and putting some of it in the early data and some in the application data > transparently (a disaster in waiting), the client and server would have t= o > formally agree on the kind of data that could be in a "replayable_hint". > This goes a long way to mitigating many protocol level idempotency > concerns, and has no impact on the kind of pre-fetching people want to do > for HTTP and other protocols. At a bare minimum, I think we should make > this change. > > > > Lastly, and this is a little crazy but I haven't let that stop me before > ... to guard against the smaller replay window and idempotency problems a= t > the application levels,clients should occasionally send duplicate and > unrelated hints, just opportunistically. This keeps the server side > application "on notice" that that kind of craziness can occur, and better > to have it happen a little all of the time in a controlled way, than rare= ly > by attackers. > > > > *Summary* > > A common theme in the above is that it makes things more expensive for > server-side implementors, and that sucks - but I don't see another way to > avoid some of the pitfalls here; and I'm unhappy with the state of ticket= s > today. If I'm on my own on that, I'd be interested in what kinds of data > people might kind convincing. My own impressions come from being an Apach= e > httpd developer and assisting people with configurations and running > workshops at conferences. It's not scientific, but the prevalence of > non-rotation is so severe in my sample set that I'm convinced it's the > norm. > > > > -- > > Colm > > _______________________________________________ > 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 > > --94eb2c0bbf62e5af59052f23213a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, I believe that this is what people want.

On Mon, Mar 28, 2016 at = 2:47 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:

Not sending cookies/authz headers in = 0-RTT would solve a part of the problem, but will browser vendors go for th= at? I could be wrong, but there seems to be considerable interest in 0-RTT Token Binding=E2=80=A6. so folks must be planning on sen= ding tokensJ.

=C2=A0

From: Karthikeyan Bhargavan [mailto:= karthik.bh= argavan@gmail.com]
Sent: Monday, March 28, 2016 2:31 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Colm MacC=C3=A1rthaigh <colm@allcosts.net>; tls@ietf.org


Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety<= u>

=C2=A0

=C3=98<= span style=3D"font-size:7.0pt">=C2=A0=C2=A0=E2=80=A6 be= cause secrecy is in the control of the client, who can choose to send or no= t send sensitive data=E2=80=A6

Generally, how can a browser distingu= ish sensitive data?

=C2=A0

By not sending cookies or authorization headers, for= example?

=C2=A0

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From:=C2=A0TLS [mailto:tls-bounces@ietf.org]=C2=A0= On Behalf Of=C2=A0Karthikeyan Bhargavan
Sent:=C2=A0Monday, March 28, 2016 1:31 PM
To:=C2=A0Colm MacC=C3=A1rthaigh <colm@allco= sts.net>
Cc:=C2=A0tls@ietf.org
Subject:=C2=A0Re: [TLS] Resumption and Forward Secrecy,= 0-RTT and Safety

=C2=A0

Let me try to understand the concerns here.




Resumption and Forward Secrecy<= /p>

=C2=A0

PSK_ECDHE in TLS 1.3 does provide forward secrecy fo= r 1-RTT data, yes?

This is already better than TLS 1.2 where we had no = way to do forward-secret resumption.

In that case, the concern is mainly for 0-RTT, which= I agree is harder to get right.




0RTT and Safety

I see at least three different challenges with 0RTT = as defined. The first is a general and high level one: we seem to willing t= o accept a "lower" level of security for 0RTT data (e.g. no FS, e= ven if the rest of the session has it). Why? What is it we think is special about this data that it is "less"= worth protecting? surely there are very sensitive things in urls, surely t= here are potential oracles and other things in there too? It just seems sup= er strange to me.=C2=A0

=C2=A0

I wonder if the QUIC folks have an answer to this qu= estion? It would be good to gather =E2=80=9Ctypical=E2=80=9D intended use c= ases of 0-RTT data.

In any case, it is good to distinguish this forward = secrecy concern from replay, because secrecy is in the control of the clien= t, who can choose to send or not send sensitive data, but replay detection = is in the hands of the server.




The second challenge is that the replayability of th= e 0RTT poses a cryptographic safety challenge. Take Lucky13 - which is a br= illiant attack and is stunningly effective against DTLS because it is so ea= sy to replay over and over; barely needing to change any parameters - and let the server do the work. 0RTT lo= oks very similar. It doesn't seem wise to let cipher text manipulators = take as many cracks at the whip as they'd like.=C2=A0

The third challenge is that the 0RTT plaintext data = itself may not be safe to replay; that is that it might trigger some kind o= f non-idempotent action. Idempotence is really really hard, it isn't sa= fe to simply plug in a replayable section to existing protocols. There's also a huge difference between being to= lerant to a small number of replays, and a large unbounded number. For exam= ple: a large unbounded number may be used to generate DOS attacks against = =C2=A0throttles and quotas.=C2=A0

=C2=A0

Yes, detecting and preventing replays by default wou= ld be good.

However, I wouldn=E2=80=99t tie this in with the ses= sion mechanism.=C2=A0

Wouldn=E2=80=99t we want to prevent replay of DH 0-R= TT requests?

=C2=A0

Best,

Karthik

=C2=A0




=C2=A0

The third challenge is that the 0RTT plaintext data = itself may not be safe to replay; that is that it might trigger some kind o= f non-idempotent action. Idempotence is really really hard, it isn't sa= fe to simply plug in a replayable section to existing protocols. There's also a huge difference between being to= lerant to a small number of replays, and a large unbounded number. For exam= ple: a large unbounded number may be used to generate DOS attacks against = =C2=A0throttles and quotas.=C2=A0

=C2=A0

Tying things together

Short of some kind of transactional locking protocol= during TLS handshakes, I don't think there is a scheme that can perfec= tly prevent replay. Bill Cox' analysis is a really good one here. But I= 'd like to observe that the sort of single-use-session-id cache outlined above has a nice property that it makes for a sort of strik= e register. Since the server-side implementor is incentivized to evict entr= ies, or at least mark them as used, so that the slot is available for re-us= e; that can be doubled-up as a "we've seen this already" signal. This reduces the replay window to the time= period for that signal to propagate (e.g. for an eviction to happen from t= he cache).=C2=A0

=C2=A0

So 0RTT data could be encrypted under the resumption= session id. That creates the challenge that the session might not be there= any more, so the server may not be able to decrypt the 0RTT data. I actual= ly think this is a plus, and lines up with a separate important change I think is necessary - the 0RTT data s= houldn't be application data. It should be a separate, optional, stream= . I find it helpful to think of it as a hint, so it could be called "r= eplayable_hint". Instead of breaking apart an existing protocol and putting some of it in the early data and some in = the application data transparently (a disaster in waiting), the client and = server would have to formally agree on the kind of data that could be in a = "replayable_hint". This goes a long way to mitigating many protocol level idempotency concerns, and has no imp= act on the kind of pre-fetching people want to do for HTTP and other protoc= ols. At a bare minimum, I think we should make this change.=C2=A0=

=C2=A0

Lastly, and this is a little crazy but I haven't= let that stop me before ... to guard against the smaller replay window and= idempotency problems at the application levels,clients should occasionally= send duplicate and unrelated hints, just opportunistically. This keeps the server side application "on notice&= quot; that that kind of craziness can occur, and better to have it happen a= little all of the time in a controlled way, than rarely by attackers. =C2= =A0

=C2=A0

Summary

A common theme in the above is that it makes things = more expensive for server-side implementors, and that sucks - but I don'= ;t see another way to avoid some of the pitfalls here; and I'm unhappy = with the state of tickets today. If I'm on my own on that, I'd be interested in what kinds of data people might k= ind convincing. My own impressions come from being an Apache httpd develope= r and assisting people with configurations and running workshops at confere= nces. It's not scientific, but the prevalence of non-rotation is so severe in my sample set that I'm convinced it= 9;s the norm.=C2=A0

=C2=A0

--=C2=A0

Colm

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

=C2=A0


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


--94eb2c0bbf62e5af59052f23213a-- From nobody Mon Mar 28 15:49:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1184012D594 for ; Mon, 28 Mar 2016 15:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nB2YrVF8FH8D for ; Mon, 28 Mar 2016 15:49:54 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E76012D586 for ; Mon, 28 Mar 2016 15:49:50 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id r72so33882223wmg.0 for ; Mon, 28 Mar 2016 15:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=m4M1APwoyKEY7Cb9AO/7uC9SkUifdLNPrzRXV8m6fbM=; b=OR03kO14uLhmeJJ5EEyD7Uo62fxiEdF+m2Q8GutVYVTb0u8j7QaWkWeNRzXNnoED8f g72UBMtq62cTwvDbg6PqpW+w26QBu3fA9Rvhsb0Aep33ILVyAm9NbQ4jniVOvle1GuH8 TFBoCJ+cBdy417cDCaLX57mZXpbJsALOYcy0VsyUMaxZ7UQQRuhG69No5uELPgmm+8nq HNEwpQGdWDQNcLXTpzWClfsEyPJ/vE+rvkzWJi8NPRhi5QwoeJXxm8Qn9THfneWxvRrL 2Ef+NgyMw3/cnciycv3fw+hzo6WOh0Ctive8wqztlrAChKP5Z3MFxCAOhwveobP9whKH jemQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=m4M1APwoyKEY7Cb9AO/7uC9SkUifdLNPrzRXV8m6fbM=; b=PfqsKABjgNX6/UMZrxJ7UsYRNtN7RaDS7r9gpXNAAaEvsvcqBcgbMttIS8w/kvJriA Had418WN2xTzOpPLKKeIil655rUf5wMI+lmWKwESjvR0mRVQ2VnjeFi3Qfgggr+CDxY0 9OK0PDRJUCkjUg8BlJK8eNzv50Tt9Nd1kLg9GZy3uqlmfMt8eJKIrVd4Olcam5ltTFwv +ED/caJkn1tEyAhVtGTO+V7/L8rS2vqaa0SY337Gw10tRF5huylOd3T3ZdX83I3C+MBa w62SjPKkOPhqo6Ycs9mg9HiAkHvVXojSiHQlTCznBEjmn1VKmswe9/VtEOKO7Y3YyPBi fbHw== X-Gm-Message-State: AD7BkJLC+7f8aWo3r2H7E4lwLoASs8Aogf5oDDPcCtaqUzbJziYWn3KidkJg00RGcUcbTThJqmbnfxtCyrtxFJFz MIME-Version: 1.0 X-Received: by 10.28.4.131 with SMTP id 125mr2453194wme.44.1459205389104; Mon, 28 Mar 2016 15:49:49 -0700 (PDT) Received: by 10.28.27.132 with HTTP; Mon, 28 Mar 2016 15:49:48 -0700 (PDT) In-Reply-To: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> Date: Mon, 28 Mar 2016 15:49:48 -0700 Message-ID: From: Ryan Hamilton To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1141e8aedf809c052f23ba31 Archived-At: Cc: "karthik@messengeruser.com" , "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:49:56 -0000 --001a1141e8aedf809c052f23ba31 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2016 at 3:06 PM, Eric Rescorla wrote: > Yes, I believe that this is what people want. > > On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov > wrote: > >> Not sending cookies/authz headers in 0-RTT would solve a part of the >> problem, but will browser vendors go for that? I could be wrong, but the= re >> seems to be considerable interest in 0-RTT Token Binding=E2=80=A6. so fo= lks must be >> planning on sending tokensJ. >> > =E2=80=8BWe (Chrome) definitely want this (sending cookies in 0-RTT request= s), and are doing this today with QUIC (which we can't wait to TLS 1.3-ify). =E2=80= =8B --001a1141e8aedf809c052f23ba31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 28, 2016 at 3:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Yes= , I believe that this is what people want.

On Mon= , Mar 28, 2016 at 2:47 PM, Andrei Popov <Andrei.= Popov@microsoft.com> wrote:

Not sending cookies/authz headers in = 0-RTT would solve a part of the problem, but will browser vendors go for th= at? I could be wrong, but there seems to be considerable interest in 0-RTT Token Binding=E2=80=A6. so folks must be planning on sen= ding tokensJ.


=E2=80=8BWe (Chrome) = definitely want this (sending cookies in 0-RTT requests), and are doing thi= s today with QUIC (which we can't wait to TLS 1.3-ify). =E2=80=8B
=
--001a1141e8aedf809c052f23ba31-- From nobody Mon Mar 28 16:53:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CEF12D0CF for ; Mon, 28 Mar 2016 16:53:54 -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 eQiJg6FZEHu9 for ; Mon, 28 Mar 2016 16:53:52 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FF2127058 for ; Mon, 28 Mar 2016 16:53:52 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id g185so2967050ioa.2 for ; Mon, 28 Mar 2016 16:53:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n8Ky81c0XUTzy87x/T+myq2/ptS+hT8HFNbqc1sSl+g=; b=nISAz/GgZRN6xnYuw5etpXJJtZVss+b5wSAxASFDTyPWdfBorW0w7Xk0fKO34jm2G2 WPuoZ4Iejoan7R9r8QULheaS5rr/LLRAum5kL5lCTi3VeMFRJShKGgVHn0GxTf0DPx+c PQtx8gmkWJ7T75WUEwGFKr+Qi3075mMJ9u2x4VdPzvjCC4g/UbRRVV5K9PCI35ecqe+c 87rSFwJ5smZ1wizsO4nb6nIsbi4hbD8XA6hupkFZb0sMbGtUFi1jZ7DN6T28V4tEuShs GHfZykalhAThocXj7HR/Ed+bPcn7eon3vz4fzwGRuQXz1L/luEVzzqQhi0j6xvakPKQL 2/ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n8Ky81c0XUTzy87x/T+myq2/ptS+hT8HFNbqc1sSl+g=; b=k+uV0BqhyL7HhwVjLgvZcimRPpWwzt2OJPXkQZro4v4qBFlZ7o+ImGOnlwp2EhrOID t3xUYQgOo0CjtbGFlbNvyOVw4UxWYv/ux8QjB4l5rR6R7eFM7ntOiNNjz8qXZYuoFdHp DdsXC1Q/HuJpvYyISaWKckoPOxPcjPWtXQfnbIhjr8A3aT96qAcMV7mMV6WVdPfaPI/d zeDytnTQb7nYIseR8QuUBIhym2iskF55J1HH/5ycH+qbLa/XCZTVnF5RBE8dgBA28KuN 7VkBNQYTTkSSLXLxCcjNk3kFY/sHZdKtmP3cyqbFlIHgEAV4Kb7SjPn6U5+jiBa6Bexo k52g== X-Gm-Message-State: AD7BkJJsVfS+/lI5tMFkLJ7CNLSU+8mA1i+CKRhQ1HkA9wu4qETBVS5PYKJuIvCoPVJxIZbfBkuBhgMCh9XldA== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr12210635ioe.190.1459209231889; Mon, 28 Mar 2016 16:53:51 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Mon, 28 Mar 2016 16:53:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2016 10:53:51 +1100 Message-ID: From: Martin Thomson To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:53:54 -0000 On 29 March 2016 at 08:04, Bill Frantz wrote: >> surely there are very sensitive things in urls, > > > A number of URLs include an authorization token which authorizes access to a > resource. This token is frequently a long "unguessable" number. It must be > kept secret. I think DropBox URLs are one example. The risk to the secrecy of that sort of data is limited. The primary risk is in the traffic analysis that might be performed as a result of replaying. From nobody Mon Mar 28 17:44:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D0312D195 for ; Mon, 28 Mar 2016 17:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 9ASqntoY4OXI for ; Mon, 28 Mar 2016 17:44:21 -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 BDF8912D1BA for ; Mon, 28 Mar 2016 17:44:21 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g3so639844ywa.3 for ; Mon, 28 Mar 2016 17:44:21 -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:date:message-id:subject:from:to :cc; bh=Owa3Ov4FPCCSB6/UcDR3YQNlOLllY2bqke7NKZHmay0=; b=D9l1/hNfVFKLrXSAhMXg87Y6dtb70CWjyu801krbHRHBs6G8IJYzbc5vrEzxzNTgFj d1eCwRBKxC7S6FQiwRYniAbG8w7iyBAqUDcX5MQrYwasNfwBgVN1SAUrYz3nPDjNbtMA meik3xT1HPVptRNT3n/jIlK0ryikqEqlhuiIoZMGveHTqo3rnBqyd9sufONffzDRBJoF 3LKPiS1D5F4NVUld44K6GcfA95udZXsj5H1Ru0EkfL3JLnpkOlJxxNcIaq2HDwYoR4Oe 7wX5jtfChJvG3BcxMRE0Rt7bs1AQtMuFjlijKK+5FFMA/qqO5MnCNQ70aFhWVZCXJMwq wdCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Owa3Ov4FPCCSB6/UcDR3YQNlOLllY2bqke7NKZHmay0=; b=VYmYqNbx5Cay8NVU8Fi7+1/H9KxIIkARWjMz9Rcwy3yObhxGYZh1eHq91GnmDhgR9V rLBqawuOAbgCkHKV9dWrzWOjUQ+Qe/z1k1x63ZoGUBhLZq8SUM9C6Zh4JXm0JoakbEPY 8Nap6n4/W2hgx6v0VUwiVCWZ9CM78cifolsDNSp0gbK+zpapC9IOVb8VT1rYnJ3n9vu2 It/LF+J2lVnVRb3WjhHqNvnsDJmKMjvtSkyWEz5BVx5X2Saodf4q4tc0qZUtzHEEpcHi ZDdLzKZnRNJsEsY+y75wopZr2wD9nOqhFNqGh2pi0fLcwT0q7as8fYyLOgZGEIlhy0rn PNAw== X-Gm-Message-State: AD7BkJKPzfEJFL51NCOK20IXGB2lxwsZ8ohshBooheVPF/KXRZSaU42sXw/Tr1Dl2auFVakL9cwuhPfZfgDSnw== MIME-Version: 1.0 X-Received: by 10.129.155.81 with SMTP id s78mr13961596ywg.24.1459212260592; Mon, 28 Mar 2016 17:44:20 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Mon, 28 Mar 2016 17:44:20 -0700 (PDT) In-Reply-To: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> Date: Mon, 28 Mar 2016 17:44:20 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c0b8e7c721352052f2554c5 Archived-At: Cc: "karthik@messengeruser.com" , "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 00:44:24 -0000 --94eb2c0b8e7c721352052f2554c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton wrote: > > On Mon, Mar 28, 2016 at 3:06 PM, Eric Rescorla wrote: > >> Yes, I believe that this is what people want. >> >> On Mon, Mar 28, 2016 at 2:47 PM, Andrei Popov > > wrote: >> >>> Not sending cookies/authz headers in 0-RTT would solve a part of the >>> problem, but will browser vendors go for that? I could be wrong, but th= ere >>> seems to be considerable interest in 0-RTT Token Binding=E2=80=A6. so f= olks must be >>> planning on sending tokensJ. >>> >> > =E2=80=8BWe (Chrome) definitely want this (sending cookies in 0-RTT reque= sts), and > are doing this today with QUIC (which we can't wait to TLS 1.3-ify). =E2= =80=8B > Let's leave aside all of the parts about resumption tokens for a minute. How big adeal would it be if the early data were like the hints I outlined? Let's say a request pattern looked something like; [ replayable_hint data ] GET /foo/bar/1234 HTTP/1.1 Host: www.example.com Cookie: somedata [ application_data ] GET /foo/bar/1234 HTTP/1.1 Host: www.example.com Cookie: somedata ... Obviously this is trivial for clients to generate and send. On the server side; the server could treat the hint as a signal to start rendering "/foo/bar/1234". Obviously the request and the headers are more or less duplicated here; and that uses some bandwidth, but it seems like a pretty trivial amount. The server can reply with its rendering at the same point as the existing 0-RTT proposal; it needn't even read the duplicate request(s) in the application data section. The benefit is that it makes a lot of idempodence issues go away; if the application protocol has to reason about the types of data explicitly, we can be less worried about the potential impact on the many other kinds of protocol that are layered on top of TLS. Then next; and slightly crazier - what if the browser were to very occasionally connect and send only the hint, and the server just had to deal with it. How big a deal would that be? --=20 Colm --94eb2c0b8e7c721352052f2554c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton <rch@google.com> wrote:

On Mon, Mar 28, 2016 at 3:= 06 PM, Eric Rescorla <ekr@rtfm.com> wrote:
=
Yes, I believe that this is what people want.

On Mon, Mar 28= , 2016 at 2:47 PM, Andrei Popov <Andrei.Popov@microsoft.com&g= t; wrote:

Not sending cookies/authz headers in 0-RTT w= ould solve a part of the problem, but will browser vendors go for that? I c= ould be wrong, but there seems to be considerable interest in 0-RTT Token Binding=E2=80=A6. so folks must be planning on sen= ding tokensJ.


=E2=80=8BWe (Chrome) definitely want thi= s (sending cookies in 0-RTT requests), and are doing this today with QUIC (= which we can't wait to TLS 1.3-ify). =E2=80=8B


Let's leave aside all of the p= arts about resumption tokens for a minute.=C2=A0 How big =C2=A0adeal would = it be if the early data were like the hints I outlined? Let's say a req= uest pattern looked something like;

[ replayable_h= int data ]
GET /foo/bar/1234 HTTP/1.1
Cookie: somedata
[ application_data ]
GET /foo/bar/1234 HTTP/1.1
<= div>Host: www.example.com
= Cookie: somedata
...

Obviously thi= s is trivial for clients to generate and send. On the server side; the serv= er could treat the hint as a signal to start rendering "/foo/bar/1234&= quot;. Obviously the request and the headers are more or less duplicated he= re; and that uses some bandwidth, but it seems like a pretty trivial amount= . The server can reply with its rendering at the same point as the existing= 0-RTT proposal; it needn't even read the duplicate request(s) in the a= pplication data section.=C2=A0

The benefit is that= it makes a lot of idempodence issues go away; if the application protocol = has to reason about the types of data explicitly, we can be less worried ab= out the potential impact on the many other kinds of protocol that are layer= ed on top of TLS.=C2=A0

Then next; and slightly cr= azier - what if the browser were to very occasionally connect and send only= the hint, and the server just had to deal with it. How big a deal would th= at be?

--
Colm=
--94eb2c0b8e7c721352052f2554c5-- From nobody Mon Mar 28 18:23:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2125312D0AC for ; Mon, 28 Mar 2016 18:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yhb3j5UvNK3e for ; Mon, 28 Mar 2016 18:23:15 -0700 (PDT) Received: from vsp2.ballou.se (vsp2.ballou.se [91.189.40.83]) by ietfa.amsl.com (Postfix) with SMTP id 265FE12D0B8 for ; Mon, 28 Mar 2016 18:23:14 -0700 (PDT) X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp2.ballou.se (Halon Mail Gateway) with ESMTP for ; Tue, 29 Mar 2016 03:23:11 +0200 (CEST) Received: from [192.168.0.190] (c-76cbe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.203.118]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 939FAC93DD for ; Tue, 29 Mar 2016 03:23:18 +0200 (CEST) References: <9A043F3CF02CD34C8E74AC1594475C73F4C2374E@uxcn10-tdc05.UoA.auckland.ac.nz> <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <56F9D8FD.8020402@streamsec.se> Date: Tue, 29 Mar 2016 03:23:09 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4C25E6A@uxcn10-tdc05.UoA.auckland.ac.nz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] TLS 1.2 Long-term Support Profile draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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 Mar 2016 01:23:18 -0000 On 2016-03-18 09:57, Peter Gutmann wrote: > Watson Ladd writes: > >> >As written supporting this draft requires adopting the encrypt-then-MAC >> >extension. But there already is a widely implemented secure way to use MACs >> >in TLS: AES-GCM. > This is there as an option if you want it. Since it offers no length hiding, > it's completely unacceptable to some users, for example one protocol uses TLS > to communicate monitoring commands to remote gear, they're very short and > fixed-length, different for each command, so if you use GCM you may as well be > sending plaintext. In addition GCM is incredibly brittle, get the IV handling > wrong and you get a complete, catastrophic loss of both integrity and > confidentiality. The worst that happens with CBC, even with a complete abuse > like using an all-zero IV, is that you drop back to ECB mode. Indeed. For instance, if VM reset attacks are a concern, GCM is arguably a worse option than CBC, in particular if the CBC record IV generation can be made to be random even in the case of a VM reset attack. http://crypto.stackexchange.com/questions/32203/is-tls-secure-against-vm-reset-attacks From nobody Mon Mar 28 18:50:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F412D1CA for ; Mon, 28 Mar 2016 18:50:19 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFMvqSVbUqGT for ; Mon, 28 Mar 2016 18:50:17 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF1212D113 for ; Mon, 28 Mar 2016 18:50:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459216215; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=4GCUiqW+hdbKNtAQDGmK5nQ6QDOlUET4eT0uoPQv/Kk=; b=LTT2/CbuiIJOspIiCXkRuFYlAabADve7xifcpDmQIMziodZq/iszXV0ZR8Yv/LGIE0XXKRReLTKtRa8SFRTIVq/9+0Gqy0R2Gv19hXTjlsJhULaOxeOe33a5+LDWeisFDgntaCkS0s1IYRHBfpz7hQAUe3xP5AoMIAqeooSTSl8= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03308; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=1; SR=0; TI=SMTPD_----4eT2QNI_1459216211; Received: from 10.62.54.32(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Tue, 29 Mar 2016 09:50:14 +0800 User-Agent: Microsoft-MacOutlook/14.6.0.151221 Date: Tue, 29 Mar 2016 09:50:13 +0800 From: "Dacheng Zhang" To: "tls@ietf.org" Message-ID: Thread-Topic: A TLS extension transfering service indication information Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542089817_2482666" Archived-At: Subject: [TLS] A TLS extension transfering service indication information X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:50:19 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3542089817_2482666 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: 7bit Hi, We have proposed an exension for TLS to transfer the information indicating the service the client intends to access. A motivation scenario is the reverse charging. Any comments and suggestions are really appreciated. You can find the draft through the following link: https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extensio n/ In addition, can we get a time slot to present this work in TLS please? Cheers Dacheng --B_3542089817_2482666 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable

Hi, 

We have proposed an exension for TLS to transfer the = information indicating the service the client intends  to access. A mot= ivation scenario is the reverse charging.

Any comme= nts and suggestions are really appreciated.

You can= find the draft through the following link:


In addition, can we get a time slot to = present this work in TLS please?

Cheers
<= br>
Dacheng
--B_3542089817_2482666-- From nobody Mon Mar 28 22:13:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B27C12D52C for ; Mon, 28 Mar 2016 22:13:13 -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 7G7IUpvcV7pc for ; Mon, 28 Mar 2016 22:13:11 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 7096E12D161 for ; Mon, 28 Mar 2016 22:13:11 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id c67so3847604qgc.1 for ; Mon, 28 Mar 2016 22:13:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=1wru0WG6dOaqVOe8m4e3z8Ciy/PWYkml+sm2Z2nxPm0=; b=Qh1WncqKcJy691TonLyPkIx9WionGANk/OrTrWpolB/DcfIVvTRVXv9knWEH7MDbvl A8E4/204hj8P7tJ8ZNDZFz7GhFU/jm0mRzltfnrOzj2pADNYW20VJ4FQfnBVdL9gyImf xX91XffySr1pKOzHTmKYRoTI5n2ecIiCWL1hDdz4lyNrYKMi1IzBj87mpSW9QLGAsEW4 WVjDLWi5thikdYvmt0azjaHy1JMlX9kocchgpzJHQ/Gf4wT4Q2IW7/0aWdjmx5cazKAM Ni5nrKhKeHFPISPLCHdMguoMlA8uqZmQ41yOU/z7AQAEIu+PVDscOutrzKMKJ2Pt9x3n eHoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=1wru0WG6dOaqVOe8m4e3z8Ciy/PWYkml+sm2Z2nxPm0=; b=jbmxWNAmqVeiPSfWEjGH/acpwiHQCR6BklrbD8y40Ss34usOpGoXaczXrT80F8+0+1 1Z8jc7Oero7mrvAclAp/pDFcBkIbp3mS9il/XE/ISsCs48cXLv3QjnjfNODIPBEhGSRl UK8RMDgSPeZeBUcOUP9hLk5v0hebt9HSr73rtviHvDrshn+4bPuxeQSgLGSIXaFHH8lG IeePfMSW0U49xiR/ufCjcCrFfczJjjIQb3Q/21CKA0CZBn8fZvtnxX9Vre+9jhcpqG4H zHabDR2jQPX2+RBXtlxZhF3PbW0kWsNY1/XUFLMwZ53K/29jpgNCz0qUe7oMmnI4LDi7 NF4w== X-Gm-Message-State: AD7BkJIJ1hEdnufXR/UuoJnk+iG1rK0VJoghFEjPCFKEw50CCQUhMrgiF1JKQxAbCJuZdw== X-Received: by 10.140.128.21 with SMTP id 21mr319590qha.59.1459228390678; Mon, 28 Mar 2016 22:13:10 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id x136sm13320011qka.0.2016.03.28.22.13.10 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 28 Mar 2016 22:13:10 -0700 (PDT) From: Dave Garrett To: "Dacheng Zhang" Date: Tue, 29 Mar 2016 01:13:08 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603290113.08796.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A TLS extension transfering service indication information X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:13:13 -0000 On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: > https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/ You really should not use SNI as your abbreviation, as it will just be frequently confused with the server_name extension which is already the dominant use of those initials in TLS. Dave From nobody Mon Mar 28 22:52:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D6612D541 for ; Mon, 28 Mar 2016 22:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sdr_JCJ-AVbV for ; Mon, 28 Mar 2016 22:51:58 -0700 (PDT) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id 40EC912D18C for ; Mon, 28 Mar 2016 22:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459230711; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=YowrWdcY7rEzx/jFCr224oH+FAxsiVI5MpLSYdV0q/M=; b=XQRdpiJA/xcADEPHOWg7MYe85PilON53sh8EsDk5zOLje3Vt2T7/qJ8/o465pPyZDuD0YVbNZZ0e3V1KfDzcbBDo5N8LbL0MTPDVxDdGWPuXjT8N2BtoapuCbblkNPpKRTaKqco9QhGExgGeVZT7UEFAMZs05DHGCDo7pjHe7pA= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03299; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DW; RN=2; SR=0; TI=W4_2715600_10.147.14.73_1459230709590_TP-Processor12578; Received: from WS-web (dacheng.zdc@alibaba-inc.com[182.92.253.23]) by e01l07404.eu6 at Tue, 29 Mar 2016 13:51:49 +0800 Date: Tue, 29 Mar 2016 13:51:49 +0800 From: "Dacheng Zhang" To: "Dave Garrett" Message-ID: X-Mailer: Alimail-Mailagent revision 2715559 MIME-Version: 1.0 References: , 201603290113.08796.davemgarrett@gmail.com In-Reply-To: 201603290113.08796.davemgarrett@gmail.com x-aliyun-mail-creator: W4_2715600_82MTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfOV81KSBBcHBsZVdlYktpdC82MDEuNC40IChLSFRNTCwgbGlrZSBHZWNrbykgVmVyc2lvbi85LjAuMyBTYWZhcmkvNTM3Ljg2LjQ=pd Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_51547_54994940_56fa17f5_bd9ac" Archived-At: Cc: tls Subject: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Dacheng Zhang List-Id: "This is the mailing list 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 Mar 2016 05:52:00 -0000 ------=ALIBOUNDARY_51547_54994940_56fa17f5_bd9ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK=EF=BC=8Cthanks for your comments. Will fix this issue in the next version. ------=ALIBOUNDARY_51547_54994940_56fa17f5_bd9ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK=EF=BC=8Cthanks for your comments. Will fix this issue in the ne= xt version.
-----= -------------------------------------------------------------
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC= =9ADave Garrett <davemgarrett@gmail.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A201= 6=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 13:13
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF= =BC=9A=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1=E4=B9=85) <dacheng.zdc@alibaba-= inc.com>
=E6=8A= =84=E3=80=80=E9=80=81=EF=BC=9Atls <tls@ietf.org>
=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [T= LS] A TLS extension transfering service indication information

On Monday= , March 28, 2016 09:50:13 pm Dacheng Zhang&= nbsp;wrote:
> https://datatracker.ietf.org/doc/draft-zhang-tls-ser= vice-indication-extension/

You really should not = use SNI as your abbreviation, as it will&nb= sp;just be frequently confused with the server_n= ame extension which is already the dominant = ;use of those initials in TLS.


Dave

------=ALIBOUNDARY_51547_54994940_56fa17f5_bd9ac-- From nobody Mon Mar 28 23:52:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C2612D0E3 for ; Mon, 28 Mar 2016 23:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BV2ck-oROe36 for ; Mon, 28 Mar 2016 23:52:19 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 8011112D0A0 for ; Mon, 28 Mar 2016 23:52:19 -0700 (PDT) Received: by mail-qg0-x22d.google.com with SMTP id c67so5019527qgc.1 for ; Mon, 28 Mar 2016 23:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=Vy7YkJHm7EppSGBKy9/xa/CXRzUeAnhfa3z/JTczeW4=; b=oxPIt9Ouv/sU7C8vPIaAhXTbs2aI22iv0Rngi8X+kJ0y024GqOGMYy1xVCRUi2efkK hstaLB5d1FA2so2LaSXRIBjefSsaqA7yuPyG8dXZHbhgPKrnVj1hNS9hlUJu9ct33MlC Z5EGij8EHGQN6RqdBPdhjzoDlFRoe2MYhesDG+4TLW6KFWTkk+E466D2sYksThQqbDXt YVegBqmtDjBXlAzEsBJz9tAaHFOutac/AA18p3GXC1zreT600m7dzNzHLsL4+eCCViSv X1GWj8PHgdiUbokgdbt71irCun9OjG7NAezcC5OO/ExyCU3Eq4jaHDcdndOkUrYptQri wqng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=Vy7YkJHm7EppSGBKy9/xa/CXRzUeAnhfa3z/JTczeW4=; b=HiDnHRVgzf8eaRV1LpSlqiS6ohHzluqxZothKlZf7ffT2seUxJzzhfhp7nsh0sL6bl X2l3aG+y0Fm/oHztzC3j6fc+yJzU1ELJfldH8YHqORqc6JlgwG+qUdBT9Q6VvWaD05/+ QmU/06nzWcIOzKnth3h524bRNjwrTeUa5cuJawr156aAALg1fzXzGL7uLf3cXNoMMxIE 6uq/xoMJrILSEWiFHVIyYUi66y00QTVbKGREsZlhE7lgyQnHuz3lMNtBCUQgduujvd0l AaRMDKYB26vc0IGJtkZith3BHXplGwaCTXxZuy0Ipp9kBGRENXD8YhMICjiKBE9b2kpX Fupg== X-Gm-Message-State: AD7BkJLOxwyBoOkok1OCYMQC64DcAfxL5YGWCXd10pturMJHZg9kSnYKawMEhQGbiR/Peg== X-Received: by 10.140.82.20 with SMTP id g20mr640848qgd.69.1459234338693; Mon, 28 Mar 2016 23:52:18 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id w75sm13406265qka.49.2016.03.28.23.52.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 28 Mar 2016 23:52:18 -0700 (PDT) From: Dave Garrett To: Eric Mill Date: Tue, 29 Mar 2016 02:52:16 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201603290113.08796.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603290252.17003.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] A TLS extension transfering service indication information X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 06:52:21 -0000 On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: > It looks like the abbreviation this draft uses is just "SI". It uses SNI at > the top a few times to refer to Server Name Indication (which it typos as > "service" name extension). > > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett wrote: > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: > > https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/ > > > > You really should not use SNI as your abbreviation, as it will just be > > frequently confused with the server_name extension which is already the > > dominant use of those initials in TLS. You're correct; my mistake. I didn't notice the typo and reading a spec draft whilst tired is not always the best of ideas. ;) CCing back to list and thread starter to make sure my correction is OTR for the list. Fixing that typo in the draft would help to avoid future misreadings. Sticking in a direct reference to RFC6066 on first mention of SNI could add another level of clarification, if desired. Thanks for quickly correcting me. Dave From nobody Tue Mar 29 00:48:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE2712D0F8 for ; Tue, 29 Mar 2016 00:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAijA-Fwf4Fn for ; Tue, 29 Mar 2016 00:48:28 -0700 (PDT) Received: from out4133-50.mail.aliyun.com (out4133-50.mail.aliyun.com [42.120.133.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5D25412D0B6 for ; Tue, 29 Mar 2016 00:48:20 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R461e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03301; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=W4_2715600_10.147.38.219_1459237617622_TP-Processor10754; Received: from WS-web (dacheng.zdc@alibaba-inc.com[182.92.253.23]) by e01l10436.eu6 at Tue, 29 Mar 2016 15:48:15 +0800 Date: Tue, 29 Mar 2016 15:48:15 +0800 From: "Dacheng Zhang" To: "Eric Mill" , "Dave Garrett" Message-ID: <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> X-Mailer: Alimail-Mailagent revision 2715559 MIME-Version: 1.0 References: <201603290113.08796.davemgarrett@gmail.com> , 201603290252.17003.davemgarrett@gmail.com In-Reply-To: 201603290252.17003.davemgarrett@gmail.com x-aliyun-mail-creator: W4_2715600_82MTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfOV81KSBBcHBsZVdlYktpdC82MDEuNC40IChLSFRNTCwgbGlrZSBHZWNrbykgVmVyc2lvbi85LjAuMyBTYWZhcmkvNTM3Ljg2LjQ=pd Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_1634_4e0ef940_56fa333f_c14c9" Archived-At: Cc: tls Subject: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Dacheng Zhang List-Id: "This is the mailing list 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 Mar 2016 07:48:30 -0000 ------=ALIBOUNDARY_1634_4e0ef940_56fa333f_c14c9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi,=0AActually, we refer to the extension as a 'SNI' extension. In this extens= ion, SI(service indication) information is provided. In the next version, we w= ill use 'SI extension' to take place of 'SNI extension'. ^_^=0ACheers=0ADachen= g ------=ALIBOUNDARY_1634_4e0ef940_56fa333f_c14c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,
=

Actually, w= e refer to the extension as a 'SNI' extension. In this extension, SI(service i= ndication) information is provided. In the next version, we will use 'SI exten= sion' to take place of 'SNI extension'. ^_^
<= br >
Cheers
=
Dacheng
-------------------------------------------------------= -----------
=E5=8F= =91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett <davemgarrett@gmail.com>
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4= =BA=8C) 14:52
=E6= =94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill <eric@konklone.com>
=E6=8A=84=E3=80=80=E9=80=81= =EF=BC=9Atls <tls@ietf.org>=EF=BC=8C=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1= =E4=B9=85) <dacheng.zdc@alibaba-inc.com>
=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A = TLS extension transfering service indication information

On Tuesday,&nbs= p;March 29, 2016 01:35:50 am Eric Mill wrot= e:
> It looks like the abbreviation this&= nbsp;draft uses is just "SI". It uses SNI&n= bsp;at
> the top a few times to refe= r to Server Name Indication (which it typos=  as
> "service" name extension).
> 
> On Tue, Mar 29, 2016 at 1:13 AM,=  Dave Garrett <davemgarrett@gmail.com> wrote:
&g= t; > On Monday, March 28, 2016 09:50:13&= nbsp;pm Dacheng Zhang wrote:
> > https://da= tatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/
>&= nbsp;>
> > You really should not us= e SNI as your abbreviation, as it will = ;just be
> > frequently confused with = the server_name extension which is already the> > dominant use of those initials = ;in TLS.

You're correct; my mistake. I = didn't notice the typo and reading a spec&n= bsp;draft whilst tired is not always the be= st of ideas. ;)

CCing back to list = ;and thread starter to make sure my correct= ion is OTR for the list.

Fixing that&nb= sp;typo in the draft would help to avoid&nb= sp;future misreadings. Sticking in a direct refe= rence to RFC6066 on first mention of SNI&nb= sp;could add another level of clarification, if&= nbsp;desired.

Thanks for quickly correcting me.

Dave

------=ALIBOUNDARY_1634_4e0ef940_56fa333f_c14c9-- From nobody Tue Mar 29 01:21:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7B312D562 for ; Tue, 29 Mar 2016 01:21:35 -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 xvCCrzWaFSdn for ; Tue, 29 Mar 2016 01:21:33 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CACF12D564 for ; Tue, 29 Mar 2016 01:21:31 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id 191so41081382wmq.0 for ; Tue, 29 Mar 2016 01:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=MTmDzbh+BWZOM4qRTD7AgtG6UneFvSK4iQFD00l/w50=; b=LYwM87IoPxAGff/nK+3pAnSTXqw1xo26vGWPwC+OGe45CpPvNVQ5li47MWAcL9dI2L Cka4AIFXiOKWSECOMHtHxrFQvSvTKMa204eafPyRHSHVI3RbOvWgCNHOFgvspGSpPsTy mu0fG4nTIuvEC41WGLx39W9VtjdwHPqm+fNYLtcr7VCsZGazxUAqJUR8KCLohumRNyDN n56yrWw72AvqqySngfcQNykpRWRg+jNB5DqBhi3+9En5PjMSlgb/v2xqIUVw1Tnq7PHZ vVkZHx8GWSWUSjAtU1kb8CtGcQiOMPWiwwunsegqkzNYRIl4JANv2YW7PmNZYSfDuqXj rm0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=MTmDzbh+BWZOM4qRTD7AgtG6UneFvSK4iQFD00l/w50=; b=Qv7G3vvfGjX2yZSu5gjpylMrpLrteld9EK+EahXOOV6HkE6DYvHpZyQ0CAQKY0Icfs LpdsarxWAj58zpitsFBMRYa3MpFYXYSqAjnGCKHooSg23Nw80fXAie4dVXS3T2+vdhS7 2p6aoc99z3JcBmc9PZQf+ylUHASD+I0Gz9b8yPp3FOW4Nq69BewKRTRmed4bXgf6mic5 sZPLnzX7AX3ZnSI/hQx6BeMWnZv/zF7NoEZtwaUzZl+x/7jNvJYgNzePHxBiCBgHGmqQ kAI7nFsTBgdUWkBmDTg+ZOeKl9uWsYz6vyR9+McVSMfEb6jUV7qNXH5SQ6dpURcMVxMd aqtA== X-Gm-Message-State: AD7BkJJTsDvYVM2u8hLB0j1laIrtSLXWJrtrajIoI0NaRngNjfYXCu5rkgz3t9hM1nsYdA== X-Received: by 10.28.54.156 with SMTP id y28mr1681949wmh.63.1459239690050; Tue, 29 Mar 2016 01:21:30 -0700 (PDT) Received: from [128.93.82.157] ([128.93.82.157]) by smtp.gmail.com with ESMTPSA id w131sm6697060wmd.17.2016.03.29.01.21.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Mar 2016 01:21:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_790646BA-DFBD-4F98-A39C-3DCAB245A328" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Tue, 29 Mar 2016 10:21:28 +0200 Message-Id: <9A99B4A4-88C9-4CD2-B6E0-0E97AD27BB5C@gmail.com> References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> To: Ryan Hamilton X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 08:21:35 -0000 --Apple-Mail=_790646BA-DFBD-4F98-A39C-3DCAB245A328 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > =E2=80=8BWe (Chrome) definitely want this (sending cookies in 0-RTT = requests), and are doing this today with QUIC (which we can't wait to = TLS 1.3-ify). =E2=80=8B I see. So, it is quite likely that the most common usage of TLS 1.3 = would send sensitive data in 0-RTT. It is unfortunate that the forward secrecy of this data is determined = solely by mechanisms (e.g. tickets, client-side caches)=20 and policies (e.g. ticket encryption key rollover time) that are outside = the scope of TLS. I wonder if it would be better to give more guidance to implementations = to better manage these mechanisms. For example, servers that use ticket only for 1-RTT resumption can set = the ticket expiry and ticket encryption key rollover time as they do for = TLS 1.2. However, servers that support tickets for 0-RTT must use a much shorter = expiry/rollover period to reduce the forward secrecy window. How short should this window be in practice?=20 Note that choosing the expiry/rollover period also determines the replay = window, and it is less obvious whether the two windows should be the = same. E.g. we may be happy with a 1-hour forward secrecy window, but only a = 10-minute replay window? Best, Karthik --Apple-Mail=_790646BA-DFBD-4F98-A39C-3DCAB245A328 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=E2=80=8BWe (Chrome) definitely want this (sending = cookies in 0-RTT requests), and are doing this today with QUIC (which we = can't wait to TLS 1.3-ify). =E2=80=8B

I see. So, it is = quite likely that the most common usage of TLS 1.3 would send sensitive = data in 0-RTT.
It is unfortunate that the forward secrecy of = this data is determined solely by mechanisms (e.g. tickets, client-side = caches) 
and policies (e.g. ticket encryption key = rollover time) that are outside the scope of TLS.

I wonder if it would be better to give more = guidance to implementations to better manage these = mechanisms.
For example, servers that use ticket only for = 1-RTT resumption can set the ticket expiry and ticket encryption key = rollover time as they do for TLS 1.2.
However, servers that = support tickets for 0-RTT must use a much shorter expiry/rollover period = to reduce the forward secrecy window.
How short should this = window be in practice? 


Note that choosing the expiry/rollover period also = determines the replay window, and it is less obvious whether the two = windows should be the same.
E.g. we may be happy with a 1-hour = forward secrecy window, but only a 10-minute replay = window?

Best,
Karthik




= --Apple-Mail=_790646BA-DFBD-4F98-A39C-3DCAB245A328-- From nobody Tue Mar 29 02:58:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E6512D5E9 for ; Tue, 29 Mar 2016 02:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 NAdpX_0D0D09 for ; Tue, 29 Mar 2016 02:57:54 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 3050312D56E for ; Tue, 29 Mar 2016 02:57:54 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id nk17so72092337igb.1 for ; Tue, 29 Mar 2016 02:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=8/TP/hgBHPiil9GDHboT+0dq6Dy9inyfZ5Ee3O6lciI=; b=nNLWN4V5Q8PkR94+EeB+Cb/1VH9uKif7+TSPbbKEn1Ab/+bZNJJILPNvGMUnEcVtGO HbIeWbF2sPk4DytdjGGTXEr5ck4trT3bFrxprwi1Ed6Hiofa4oKpg8gUBdJHFM9Gpnlx VIskhccjujpTirw0m/7dAfM8JqQ1zpfsqgGFQ5jk1nlQsZCGfoNAbHBkxIrHRIEsGKF8 fmG/3E7Tpso3ts+hLkXVu02OzOdEV1o2YIPEwqIAD9qnuBe5b0hjShLRkhhssBhtaDyd cfOzdY/JovQU9YFs9rXnM51Fmi4x9IR6aA7LUuBHt2eesn3cLGWC4djNZ4QZ61Yg3vhY c2Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=8/TP/hgBHPiil9GDHboT+0dq6Dy9inyfZ5Ee3O6lciI=; b=HdoCOr1fO1RbQVmtrEsGCf01eX4OLNVHe66nNweXNrjOWMPvwvLblGermiQcVW6Dqj TLROiDKA35y300H9GfwwucWjeD3xAp12wWSwtNgWXQQEBkNfL+0e7cW6uzkOLV2b4oDL VR3WARnUYOIqp1gyCNVx5XmXlZGr2AGIjmtkxH3LI/PvSX1mQtSGjNaxbrgJA03feh4D L0654uBDNJGg31elG9pcROkrLVPURzIRuB0AkpxgLZXqW47EnQ5ZfgvPV1+jgy/x0pOJ HKCD9F4ExEIr9eTQFkQCAXmBKfwJ1OaL0cQ0MOz+otW8/Z8JjfYGkfz2bo7OdNArB7If 5M6g== X-Gm-Message-State: AD7BkJKEctJneahfJLuWEefr+kzAKp3zQa16bvUW+7NrQ63SIKnecgJhtc2msKMn4YQwRnLuQkMb+mnDelqHOA== MIME-Version: 1.0 X-Received: by 10.50.43.226 with SMTP id z2mr1829709igl.94.1459245473442; Tue, 29 Mar 2016 02:57:53 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 02:57:53 -0700 (PDT) In-Reply-To: <9A99B4A4-88C9-4CD2-B6E0-0E97AD27BB5C@gmail.com> References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> <9A99B4A4-88C9-4CD2-B6E0-0E97AD27BB5C@gmail.com> Date: Tue, 29 Mar 2016 20:57:53 +1100 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:57:58 -0000 On 29 March 2016 at 19:21, Karthikeyan Bhargavan wrote: > Note that choosing the expiry/rollover period also determines the replay > window, I think that we can fix that one easily, as I suggested in an earlier mail. I plan to open a PR that does that. From nobody Tue Mar 29 03:29:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524B512D645 for ; Tue, 29 Mar 2016 03:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 dQxQAPIQRqiN for ; Tue, 29 Mar 2016 03:29:12 -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 B767C12D648 for ; Tue, 29 Mar 2016 03:29:11 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id g185so16277721ioa.2 for ; Tue, 29 Mar 2016 03:29:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=kkxwAf19iG/TrvMPxpduTFKpDwsYunbewVSHUMKL/vY=; b=UzcB4NfjGA17KtMfTcFGY5L6GBk8IWmw97JmNseTHTwtZoB6UrhM2aFh1CUFo3SWLx rri0ReNLzbcS7cBPSBYGv9iKlbwPXiwEDtRSEdCzZ4t8bB92pJe6hNIu2hoKsMb42u1D XSIP6m7TWnqs+eY++XGvgEssUFY3QaaoYiJZnkqYCcmlGnjZdmohp20aJwRfc6nLkm0B TxV2Vyd0x22UsStowKlkykTAJKxmm0Edq1cvMRS9F0thuceHRWtVVSyEvHlXbYjMoQHr 1x+IXuM3qy6bO2H8tVg/JXAT7rH+VtWlyCqsQ4VxOc8N4s6zmMoZsMGISwedjihoLlSo hVww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=kkxwAf19iG/TrvMPxpduTFKpDwsYunbewVSHUMKL/vY=; b=YXN80Py2Wj5ME62Q9sQeVgYQsQgoDHpDzg6I3YRHMPfyEs+Sb66E9V0FYKOAvR6Vcf eiddQ4w0i24droXVVqVE30tpFMovMiDir5B9+KVP2N/cvbnrRqDnKkkMdQs3SXTGS1Zz gSxnCtz7foKFrZnY0AZp3/TZaIAuc2xPC/M6F4mawgIH7KVXyrMIBfoFfSPvFP7xiBgH 0XxL6zAipGILo2hH0XCTskFfHgLnj4kjvKgFAhGbfA6b7T9keFyH8AIKXrwecPD1zLNY lqIIxth6De7Fne9HXj/GabcCoaEwGxmUuLadKl+7BV7H7iR39m/l2yM6/HJWiE51q1eh 24bg== X-Gm-Message-State: AD7BkJKs3rSTq1Xvi+CCCpX7XFOpEQ0PXV6YM4fR3yi0XAAwhNxpIjduNbvWxv78aJAWiDbJV4eVdkJ/uQdFjg== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr1891132ioe.190.1459247351006; Tue, 29 Mar 2016 03:29:11 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 03:29:10 -0700 (PDT) Date: Tue, 29 Mar 2016 21:29:10 +1100 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 10:29:14 -0000 https://github.com/tlswg/tls13-spec/pull/437 In short, have the client report the time since it received the configuration. Then have the server reject early data if the time doesn't match. I think that this is a relatively easy change to make. Now, your exposure to replay is much less. It's not ironclad, since the server needs to account for a round trip, but I think that would could probably get the window down to single-digit seconds. From nobody Tue Mar 29 04:15:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C9312D6BF for ; Tue, 29 Mar 2016 04:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 RJRvVpaaMOG9 for ; Tue, 29 Mar 2016 04:15:56 -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 3E84C12D6C0 for ; Tue, 29 Mar 2016 04:15:54 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 0622F85542; Tue, 29 Mar 2016 11:15:54 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2TBFqgO024540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2016 07:15:53 -0400 From: Hubert Kario To: tls@ietf.org Date: Tue, 29 Mar 2016 13:15:52 +0200 Message-ID: <11075453.M4K0yuo7Mx@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.6-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <14986FB4-9764-4A6A-B5E2-21DD15FB402A@gmail.com> References: <14986FB4-9764-4A6A-B5E2-21DD15FB402A@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1860692.7vfHi4jea5"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Subject: Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:15:58 -0000 --nextPart1860692.7vfHi4jea5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Friday 25 March 2016 22:07:02 Yoav Nir wrote: > > On 25 Mar 2016, at 8:16 PM, Yuhong Bao > > wrote: > >=20 > > I wonder if it would be possible to publish > > draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC= > > 6101). It would start with > > https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 ,= > > but the ciphersuites 0x60 and 0x61 would be added also as they were= > > implemented in OpenSSL. > >=20 > > Yuhong Bao >=20 > Hi >=20 > It would be possible but I=E2=80=99m wondering some things: >=20 > 1. Are the original authors interested, or are there alternative > authors willing to take this on? >=20 > 2. What is the point? All of the ciphersuites in there have been > deprecated by some diediedie document or another, and no sane > document author (here or elsewhere) would include any of these 56-bit= > ciphers in any profile for TLS that is intended to provide security. > So what is the benefit? 1. Showing why the code points are reserved. 2. Having official list of code points which must not be enabled (so=20= that scanners can be complete) =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 99/71, 612 45, Brno, Czech Republi= c --nextPart1860692.7vfHi4jea5 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 iQIcBAABCgAGBQJW+mPoAAoJEJKo0bgB0vX1JLAP/1hB3hngYlmr3aJHPOY13xdq nNI+Tb2YGKGxDtnuEaLWmBWepF+hUTu8P3w3G2WKAUtiFDMEVjO2wGb1effPjuWd MQ0kJ4+Qof/GXAN7GEXiDHLKRo7NxfKyVKxGma7jaWpczeORkBwGPZprVmVuDNKV iURKiN5xJ9vmQE/ueOEpjsizE0LUtDoq1POy1qtEJ1cc94ZN0jQ594GC442ZDDKN gNyAteMhmjCU56v5dtqkJtspVYAfO3jHlw5gcc6lTnv+iTFhltGBAYH6jiahpepE Y1ziFymCCW4m8TB6HhriyVYClMhaCjQQwJ2aotcvpISku/1J8pRtohCAcYz5Pqes xUHz8Ni1EGhZyxag4ULfKzsHDi6rImgL8H4iGcq/ilGnEMTyt02Rqpm24Hwijf0W TZ3EEKSLqVyG3GObp2o3SaIkzZv2bTtsK5Gtt7pvcEduZpGq2AUEAppfCoJGNM/p pf3bYlH91emem2+TMDDCw3Qu3L3tA8Vg8DdX6AHKAXeyCZG3t4xC+SzconnyQ3SY /zwX/vquQA+zOniBadO0POFHyBH+LLVnSCScahajiWmH0Bvz+NCryHX33GnVx5ux tyKervZmA1wHm72BhBpSjee7SidoLjb01atSJ9Sl3c6qLJWdjIWfIhEg/AiZYqqV 4pqiegvHEabME6Mm9j7l =x+TN -----END PGP SIGNATURE----- --nextPart1860692.7vfHi4jea5-- From nobody Tue Mar 29 04:33:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CA712D705 for ; Tue, 29 Mar 2016 04:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 1x1tq_GXOtUT for ; Tue, 29 Mar 2016 04:33:31 -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 A60BB12D6F3 for ; Tue, 29 Mar 2016 04:32:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 01F27BE39; Tue, 29 Mar 2016 12:32:11 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HZj_7iKBIBnC; Tue, 29 Mar 2016 12:32:10 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 4A26DBE2F; Tue, 29 Mar 2016 12:32:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459251130; bh=M6XaMtqUCXKrM0f3C4MN0L45piZqr4J6VR1k5iybAS8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=YGxHxBYL/lNT4VwIY1NxzGc+BYL3n+vEr0Hb1HbGavg5pGyCBzqrQ0rimdzkRSXc6 lAS1Pu9owiXAdxLaJXCdGAdtIn+cqOoQcnDZbmusqVNhiHXmuuCQ/w94t0jXq3hgbn FH3GCMXRtG1bQTKLUnlMZhCY5l+kOoWixH3se6VM= To: Martin Thomson , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56FA67B9.6040307@cs.tcd.ie> Date: Tue, 29 Mar 2016 12:32:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070604080002040203080102" Archived-At: Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:33:34 -0000 This is a cryptographically signed message in MIME format. --------------ms070604080002040203080102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29/03/16 11:29, Martin Thomson wrote: > https://github.com/tlswg/tls13-spec/pull/437 >=20 > In short, have the client report the time since it received the > configuration. Then have the server reject early data if the time > doesn't match. >=20 > I think that this is a relatively easy change to make. Now, your > exposure to replay is much less. >=20 > It's not ironclad, since the server needs to account for a round trip, > but I think that would could probably get the window down to > single-digit seconds. In an offlist exchange with Martin, I suggested allowing finer granularity than 1s, e.g. 1ms. I'm not sure how practically useful that would be, but I don't think it'd constitute much of a new fingerprinting risk (as the ticket bytes identify all the genuine 0rtt requests from the same client anyway) and it might provide some clients and servers with a way to reduce the possible harm even more. Cheers, S. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms070604080002040203080102 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMjkx MTMyMDlaMC8GCSqGSIb3DQEJBDEiBCCDG6PsKtBjPVH9Fa2hA7J3YkBJHDk+rx4jI6K+GyJZ 1DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBJSSwlOkDbEH1VZb9jUiU0iTgs+VoGlkyDB4uBzIw7V3GITadG5Zvr nAdJ/K8jwZsGeVrXYzdVJOFXxaJjMVuuCnkFe0d6O3Trxv+aW8rTJwgoNuT7bN5lXLyhunDM w7YeFfegrMiT70QUrym/DaT88GLb2Dlugh27SWnKejZo+cQZoZMFGfI6oorsqJLiTEFleh8W 6J7E9bFCnlsGFUDf5cMGarmF9GCEarSqbdX/g8eLFz6M/WtpTlcgenIM0pLgskxql+EdhS48 mULB1jDn4NLN9++XNQTjaj69lezus4zTPxJoVaLfAzkfBC1E3d/Lx4Y0lONCSCUElV6hYTU8 AAAAAAAA --------------ms070604080002040203080102-- From nobody Tue Mar 29 04:55:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6312712D725 for ; Tue, 29 Mar 2016 04:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viw85v51qG5b for ; Tue, 29 Mar 2016 04:55:41 -0700 (PDT) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8CCB12D714 for ; Tue, 29 Mar 2016 04:55:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1459252540; x=1490788540; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cGIlSsO2hHbm6STcKtCKzsmT95EW8taQsvROwDSXO5A=; b=kkzji6FXDZpJpHRwNW7yQfhDolF6UceuQ0GOecggoduMhXHfcVhMOFOA o2+ftNDa0l0CklGuuE/mjnhSh1kOnNJoKaIcPnpSwvdllip/mL9ZYy+zg fRVzyfnX0m88o+zVIPCK7WfVIxJonM2fTlk1lYi1w6XG6raKelTFY0w8I vNVMt97U9x3/ycnS0HQfWdKuQyTjj8DU2BKeBu3pWF0FYdnCx7gxR4itG OaLQcW3RFb2Iwgs3v5rjGruFmeGPTvZte/vfMkLY5550ZlL8lV/XXg2yH llCXchqHZwZzEok+JFe7lDLHKXc8rRYyTOT4guO94JX3JuLiJ1BDL9CmD g==; X-IronPort-AV: E=Sophos;i="5.24,410,1454929200"; d="scan'208";a="76855663" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 30 Mar 2016 00:55:38 +1300 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.241]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Wed, 30 Mar 2016 00:55:37 +1300 From: Peter Gutmann To: Bill Cox , Maarten Bodewes Thread-Topic: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets Thread-Index: AQHRiQq1dTdCf45MpkuvAb6y4KP8j59uK7+AgAIl3iQ= Date: Tue, 29 Mar 2016 11:55:37 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4C3090C@uxcn10-tdc05.UoA.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.6.3.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Diffie-Hellman: value of Z - the shared secret - without leading zero octets X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:55:46 -0000 Bill Cox writes:=0A= =0A= >I spent 2 weeks last year tracking down a flaky bug that only occurs once = in=0A= >every 256 connection: the leading 0 byte was no longer being stripped in a= =0A= >code change I ported from OpenSSL master, and only Maria DB ran random tes= ts=0A= >enough to trigger this condition.=0A= =0A= My self-test code includes 1K iterations of various PKC ops in mechanisms t= hat=0A= are sensitive to leading-zero truncation (PGP springs to mind) to detect th= is.=0A= Without this, it's mostly blind luck as to whether your self-test hits the= =0A= 1/256 one that triggers the problem. Having to design coverage tests is ha= rd=0A= enough, but when you need to iterate them to find problems...=0A= =0A= Peter.= From nobody Tue Mar 29 05:09:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A41CE12D726 for ; Tue, 29 Mar 2016 05:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugU3_R1GTAj0 for ; Tue, 29 Mar 2016 05:09:22 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8F212D714 for ; Tue, 29 Mar 2016 05:09:22 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id 127so56010797wmu.1 for ; Tue, 29 Mar 2016 05:09:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=GFCm2PBWAQLA6cS//iU8F+j34U7YX92JbmjTu8NkQCQ=; b=CxswNX7XJAIM74ROMXqljGLosmVuzOe2pJKe4D7Z8HJ1x/BwAyp9cKijBLYo8ga8jX 74MFk6Zbx+fhEIgvKZO71Xbt9KQ5SWkZeoigEfqdrB7D5F2X1GEek5ApGbhamMK3vfGZ Rj6yUlPH5o00YKyAHpFi8Z6RnGPxi3kdWykWVg5gSCtexlmXRuQkQMsYPLo0sgRUrIHb rjd2A9+NdPFOpLH4rFOilBLTy7viIb+neLVtBL3c9K5fE39oWAAQuDe47yizcCQ1fgHR 7uZE0uyrTqnN8yVZA8AC1HYRT/uh1J/Vv42wrEBbBCrDNQcu11Edd2jCwM+7EiXo7POK BF4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=GFCm2PBWAQLA6cS//iU8F+j34U7YX92JbmjTu8NkQCQ=; b=QadNS+STTt92blzHSqlc61Seg3ndk5Nr0KxbRrt6Ha4G66X/FsxTvnVn9sPqg6iMEW YzhiyK1MXIyIDYemXzIQcV7b7zElZCwCRTnBVob4yoV9RH22vHAdkxsoq0l1KCW2njG3 dUxHAizZuSJKfV1BTlwiD+bSR1+Ws5629+k42hlcs+7594sXYVxpuD46Mjt2iRCj2LVe XM267wTnhC31ihgKwQg4DIQeKuIKNXKHN7oW1xCahGS6O0E3YT5jbXg6+Q1sV1YEXcG4 IlGzpNRFZ8+d2gP0dTTeO+M73WAEWZ3QDjB0REdsSY1mhO/76yFLWUwXFRxgX1C9PT8M NgSg== X-Gm-Message-State: AD7BkJIZYuqYAGcwshlECefY2dfu4kJfQKp9EahgO7nRXWYIW0VyA+W7v42eNbn/nl/NFw== X-Received: by 10.194.203.5 with SMTP id km5mr2607493wjc.172.1459253361098; Tue, 29 Mar 2016 05:09:21 -0700 (PDT) Received: from [172.24.251.104] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id ks5sm29006876wjb.13.2016.03.29.05.09.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Mar 2016 05:09:20 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_F5AF4EE5-8CE8-4F9A-AF2B-4D0B7EC20302"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <11075453.M4K0yuo7Mx@pintsize.usersys.redhat.com> Date: Tue, 29 Mar 2016 15:09:16 +0300 Message-Id: <4B35E9BC-5424-4C92-A538-D5BC1C1D033D@gmail.com> References: <14986FB4-9764-4A6A-B5E2-21DD15FB402A@gmail.com> <11075453.M4K0yuo7Mx@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:09:24 -0000 --Apple-Mail=_F5AF4EE5-8CE8-4F9A-AF2B-4D0B7EC20302 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote: >=20 > On Friday 25 March 2016 22:07:02 Yoav Nir wrote: >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao >>> wrote: >>>=20 >>> I wonder if it would be possible to publish >>> draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC >>> 6101). It would start with >>> https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 , >>> but the ciphersuites 0x60 and 0x61 would be added also as they were >>> implemented in OpenSSL. >>>=20 >>> Yuhong Bao >>=20 >> Hi >>=20 >> It would be possible but I=E2=80=99m wondering some things: >>=20 >> 1. Are the original authors interested, or are there alternative >> authors willing to take this on? >>=20 >> 2. What is the point? All of the ciphersuites in there have been >> deprecated by some diediedie document or another, and no sane >> document author (here or elsewhere) would include any of these 56-bit >> ciphers in any profile for TLS that is intended to provide security. >> So what is the benefit? >=20 > 1. Showing why the code points are reserved. > 2. Having official list of code points which must not be enabled (so > that scanners can be complete) Right. But this draft does not include RC4, RC2, and a number of other = bad IDEAs (pun intended), so it=E2=80=99s not a comprehensive list of = things you shouldn=E2=80=99t be doing. Yoav --Apple-Mail=_F5AF4EE5-8CE8-4F9A-AF2B-4D0B7EC20302 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW+nBtAAoJECXR4BOacZZUvz4H/3hS5n4vo6Mqj8Jl7tTNGztQ wZGnFUg8gbBXLwX3PCh7+bAeKVTNac3Nz+iNQeDEoQqHolIcWoMm3C3hJBlTzdj0 WXJQ7Z6i2F/EKBERw/5QmVehtkf/s7QJX+ofywROk7fZNActLaAyN5bkCNNX5WeG +EqjERp9TYPG45pcMH2F2PS2ja6mHgrHxvGhn1jWCOwQqmJ0/lICZsMQd65VChFB GU/5ol0Cy3nUoUXUpRVOOxccM80REcjEzeCn+2JFHX12djjyRUbm/p0lBvZQl29R wy9VXUiq7XGOstXSQ0yQLCO9DKcISnVdOBZca/9qkEfC1iwbe5qc//CJPqNvSzQ= =e8ff -----END PGP SIGNATURE----- --Apple-Mail=_F5AF4EE5-8CE8-4F9A-AF2B-4D0B7EC20302-- From nobody Tue Mar 29 05:59:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63D5A12D7C4 for ; Tue, 29 Mar 2016 05:59:29 -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 (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 uKrY-rSI_U77 for ; Tue, 29 Mar 2016 05:59:28 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCCCE12D7C1 for ; Tue, 29 Mar 2016 05:59:27 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id s5so5379743qkd.0 for ; Tue, 29 Mar 2016 05:59:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=7i1YMq9CK9wHZAOti+ZjOatXgXgkxDo9BIG6XUZ+J88=; b=jbeC7kKgKrsKMJwDTpZlWNiG3P4z74d1cba9NObVl0HVhueKhxjG+3MAoEzKrwdHGu xXl7I7/6FQmFWm830GPMZ/xECwyeu7SjkkY5tLNIy9rN9jRG2FVHIjm2H1RpEXADRvqY 1ggNWpjhEF8mpC73qYeGqjFqlUh7JQt7SoZUQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=7i1YMq9CK9wHZAOti+ZjOatXgXgkxDo9BIG6XUZ+J88=; b=k/INn7qtmGn2KRTRTxdZlZIDJym/3pIoSfrWsRMFzm+1PtTDcDZ9dZCmG9usO2C6Qy 2+V4Zyv9GuTbzW4ZACGygTSBbXe/3OIMTiFqFkDOXrxqxZoO2rBRfsrDJrva5eFL3oUu DfNUU7ph6bTed8YTdg+6KyR/N7El04Oo33dHkkMdmDu4oH98GZodN3R5nlzRgQxCNlVQ VL/uvfxLllvl9gZnkmibXFkvlSw/X7vNvUWPGf/NEJbApPfWrrcbZ5z9IDXtxnYc/MSf g6bk/ieQsvHI1hYEh7IEsiUqwOjw4dqt27QzYvcetVTx0d3ZR3fQtcb3CkVqNUa9qurU Q0pQ== X-Gm-Message-State: AD7BkJK54nHAL1iyvq8yONUyft3rdX0bHL4eBPtwO9t0alpZlJIZjIgjZ7WKe2HaD8IlXQ== X-Received: by 10.55.78.11 with SMTP id c11mr2412639qkb.89.1459256366891; Tue, 29 Mar 2016 05:59:26 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id b6sm14018328qkh.12.2016.03.29.05.59.25 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 05:59:26 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 29 Mar 2016 08:59:24 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:59:29 -0000 All, To make sure we=E2=80=99ve got a clear way forward coming out of our BA = sessions, we need to make sure there=E2=80=99s consensus on a couple of = outstanding issues. So... It seems that there is a clear consensus not to support 0-RTT client = authentication in TLS 1.3 at this time. If you think 0-RTT client = authentication needs to be supported please indicate so now and provide = your rationale. J&S= From nobody Tue Mar 29 06:11:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE612D7E1 for ; Tue, 29 Mar 2016 06:11:24 -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 bbsI1m-qOj8r for ; Tue, 29 Mar 2016 06:11:22 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::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 886F312D7C4 for ; Tue, 29 Mar 2016 06:11:19 -0700 (PDT) Received: by mail-qg0-x22f.google.com with SMTP id y89so11194214qge.2 for ; Tue, 29 Mar 2016 06:11:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=GSibHKC/mi7s4Lf3n9Tj/Fa5gHaepfBXQx/HksjTR3M=; b=EynxI1F0nRJZ1QkivXkPkPac1k2T6oahrwmtVtfFB9w14OaE6+lwYbk6xEe26D8hoQ kwSGH8SHhgatxb51dW1BFLBKpVRmvANnlqjKCuHFHRpUcx0BheCYDY/7pg65aYVwkHNT aK+TROo+AjOzTu6uGtZOAXlzFT9oJJSPXPUA8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=GSibHKC/mi7s4Lf3n9Tj/Fa5gHaepfBXQx/HksjTR3M=; b=N5abZ6XL8ZFHGW2kVQZBsfvkFf5b5MfiahcnI9DaMsx5xD8sVPgQikixBaKAUx76C6 ouJnqks/ItTOqAIKV88H6kgkxbZmwKzXaK4RA9jtENBamu5gz7kF4Jrap7dAMo2BYlrv rBvttDRNn7Ox64IRo5tw2afQrA1JRkkEV+tbzKDhJ817k6Pu5uQ3k94Np+4GL7TRFobE 9JI6ZF8Nxe0YgS8q0WnEhi/SMACtKDySuYpCe/JsB06vndMCTmvUh9xYnfpP8lK5P54y +/YznEKSusF8h5tQJNNANE6Qa3tdJpQk9A3jzCOliibGzYUg6FOSvqipdr7LjBJo4M2w 6r8g== X-Gm-Message-State: AD7BkJJlKrb9by6K4VL8YKRYdoSnXJvbhJcQGmSwuIjfGq/IpYeirW4c9PcjLynMwTb86A== X-Received: by 10.140.217.202 with SMTP id n193mr2708889qhb.101.1459257078596; Tue, 29 Mar 2016 06:11:18 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id a91sm13853765qga.29.2016.03.29.06.11.17 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 06:11:18 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Tue, 29 Mar 2016 09:11:16 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:11:25 -0000 All, To make sure we=E2=80=99ve got a clear way forward coming out of our BA = sessions, we need to make sure there=E2=80=99s consensus on a couple of = outstanding issues. So... There also seems to be (rougher) consensus not to support 0-RTT via DHE = (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode as PSK. The security properties of PSK-based 0-RTT and DHE-based = 0-RTT are almost identical, but 0-RTT PSK has better performance = properties and is simpler to specify and implement. Note that this does = not permanently preclude supporting DHE-based 0-RTT in a future = extension, but it would not be in the initial TLS 1.3 RFC. If you think that we should keep DHE-based 0-RTT please indicate so now = and provide your rationale. J&S From nobody Tue Mar 29 07:42:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B7A12D88D for ; Tue, 29 Mar 2016 07:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.932 X-Spam-Level: X-Spam-Status: No, score=-6.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gtMsRlP_p2bL for ; Tue, 29 Mar 2016 07:42:43 -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 CAB9B12D890 for ; Tue, 29 Mar 2016 07:42:42 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6643150F52; Tue, 29 Mar 2016 14:42:42 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-138.brq.redhat.com [10.34.0.138]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2TEgf4P019266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Mar 2016 10:42:42 -0400 From: Hubert Kario To: Yoav Nir Date: Tue, 29 Mar 2016 16:42:34 +0200 Message-ID: <5569054.lGeIxtRpgH@pintsize.usersys.redhat.com> User-Agent: KMail/4.14.10 (Linux/4.4.6-200.fc22.x86_64; KDE/4.14.17; x86_64; ; ) In-Reply-To: <4B35E9BC-5424-4C92-A538-D5BC1C1D033D@gmail.com> References: <11075453.M4K0yuo7Mx@pintsize.usersys.redhat.com> <4B35E9BC-5424-4C92-A538-D5BC1C1D033D@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart11601976.l2prCztfQB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:42:45 -0000 --nextPart11601976.l2prCztfQB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote: > > On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote:= > >=20 > > On Friday 25 March 2016 22:07:02 Yoav Nir wrote: > >>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao > >>> wrote: > >>>=20 > >>> I wonder if it would be possible to publish > >>> draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of > >>> RFC > >>> 6101). It would start with > >>> https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01= > >>> , > >>> but the ciphersuites 0x60 and 0x61 would be added also as they > >>> were > >>> implemented in OpenSSL. > >>>=20 > >>> Yuhong Bao > >>=20 > >> Hi > >>=20 > >> It would be possible but I=E2=80=99m wondering some things: > >>=20 > >> 1. Are the original authors interested, or are there alternative > >> authors willing to take this on? > >>=20 > >> 2. What is the point? All of the ciphersuites in there have been > >> deprecated by some diediedie document or another, and no sane > >> document author (here or elsewhere) would include any of these > >> 56-bit > >> ciphers in any profile for TLS that is intended to provide > >> security. > >> So what is the benefit? > >=20 > > 1. Showing why the code points are reserved. > > 2. Having official list of code points which must not be enabled (s= o > >=20 > > that scanners can be complete) >=20 > Right. But this draft does not include RC4, RC2, and a number of othe= r > bad IDEAs (pun intended), so it=E2=80=99s not a comprehensive list of= things > you shouldn=E2=80=99t be doing. it's not a die-die-die document. It's a document that will add the IDs=20= to https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml= 0x00,0x62 has no intrinsic meaning. TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA= =20 has. What to do with them is second step. =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 99/71, 612 45, Brno, Czech Republi= c --nextPart11601976.l2prCztfQB 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 iQIcBAABCgAGBQJW+pRaAAoJEJKo0bgB0vX1vBsP/0Aa2R2gksy1bIR9ow4iB0sx +v1A+7dL/mrHJwOT/kD6pJXntY9GxPOaVuz6WxUTMMIDQWFRK1Qbt8638GsJ2aOg cgH8CEJLkO92IG/PVc5tsgbBfVzYmtAIoIvyAnb9usC5pZleMS8sdSF0cfYUQYeP wyfW2lOAlRYp3HV13w7GmjBt5m9oogDXo+JSFvV2SVeZ6cZjEx8DbeLe1iOQHdUe 4IQ3PT9ibEn0qbUg4jwN9qxz5BKlztwGzu1NnPcdwUq4UHUIQDjv6neof29kbFRs tzEkaIgbc3hkzgV/vebzXuCh9gDYvgt0oj07wh3Z7x3CNOUR8wwN6Tj5KH8AABHY b8FSZHoFlmneDNlM7s7cGM6hBpdb/wSthudRwMhlxQ3CE7Pu13Yq9H6dmXLmQpcA 3q4Llo3FgT1ongqD5wr1/8Uf8oqPpruwwqdTz7cYLNMrLVLjdC+FivpCfMeQdKu8 +SSUhIn51VrC/nl/sBfnKdO8IqQEXMusSFasSJ0Ikb0uqGDnzPRnJGusXyFLEH6c ImfGvY7HDYeM2Gg9VNmiw8EWiPCVRG1phT71F3j6BfufmyH9S0K4Cw8JFWf5cSgZ gzGv8CUNZzHfIdWH4XE1fAEsvBKs3CNtrjYHwHNPSDGGAkpb0IQiy3Wfe+rpIIBK Gefc/bQtu10qTNVpRb2w =AOwc -----END PGP SIGNATURE----- --nextPart11601976.l2prCztfQB-- From nobody Tue Mar 29 07:45:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48E112D8B2 for ; Tue, 29 Mar 2016 07:45:34 -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 uI32wJ8twOv0 for ; Tue, 29 Mar 2016 07:45:33 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C2512D8B7 for ; Tue, 29 Mar 2016 07:45:29 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id 191so53653451wmq.0 for ; Tue, 29 Mar 2016 07:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=q4xQhwFqFFsVYeJoqjrTD2FWKZ1wBKitl4jiYPaZbAw=; b=zX/xHr9PjYbbDTuGFWEySS4fP8D6mw7nexhOFbXas1gJ5FWGva3qgWaNdC/rGWvN1V rnXPX5HWyLloeGVcVq+gmZufC/AGZ1lLBAOxJPjb0/rsDvpmjtIJJPqecWsPemkhFE1k EpjbR+hdkCEEoaZR2VrI0jSZTEfxlFPMqiSr41jiztxL4UzYrysmzrQTVAmbal0DjaX1 mK3wdcfKJoMBxEG6DPY6XTRb2smcMZ3r1uT0lR+YMTr7mtxvHmEuFnjmXr047vjhRlZ0 5tzSKh51pmZAPIZWoX4oAMlFPX9PQlIO30NkgbzK2VvDXtshYttjddOfXDLFYNumV+Fd 8AuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=q4xQhwFqFFsVYeJoqjrTD2FWKZ1wBKitl4jiYPaZbAw=; b=dqOqfcpzWRh4mrJ3LzzPWmOnaa9oQ8cWyJlvEbsU63psG2bs6cqOQ6Y6ZXuUC+20rd cBs1pldCCGI9wb5oiaP0sjjDGxvA4Norrg7G4FOVlNXvV5GfDSqimPJZqvss4q7cW8o7 IOsk7UzhK/7ESBFEgXMid3PUpLQRKfz4QLA0T+A8hzPJo7phj+9Ff7rh62Mp9niPdoP5 AdSJy6wrDg5IZ4mkbatJ2C+aFLZXRr6ajTPALtrFww76inlbYv18N0vqy6JHcl+QWVWh 1lZ+ceD0yHbIlsAzm41UpM/9jeePt71KFLkbefQEIgEt4y4jCx8ovikTrqr0oWS6/8n2 uuKw== X-Gm-Message-State: AD7BkJK/9hU7o/3305kTMkby1QWDbtUa5wWtTyuXVE6aFV5Gnoq+o0QygLHKlB+zyx3t9g== X-Received: by 10.194.236.198 with SMTP id uw6mr3227781wjc.42.1459262728296; Tue, 29 Mar 2016 07:45:28 -0700 (PDT) Received: from [172.24.251.104] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id u16sm15143008wmd.5.2016.03.29.07.45.27 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Mar 2016 07:45:27 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CD8E95F4-FAD7-40F3-97CB-AE8E299187E2"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <5569054.lGeIxtRpgH@pintsize.usersys.redhat.com> Date: Tue, 29 Mar 2016 17:45:25 +0300 Message-Id: References: <11075453.M4K0yuo7Mx@pintsize.usersys.redhat.com> <4B35E9BC-5424-4C92-A538-D5BC1C1D033D@gmail.com> <5569054.lGeIxtRpgH@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3124) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:45:35 -0000 --Apple-Mail=_CD8E95F4-FAD7-40F3-97CB-AE8E299187E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 29 Mar 2016, at 5:42 PM, Hubert Kario wrote: > On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote: >>> On 29 Mar 2016, at 2:15 PM, Hubert Kario wrote: >>>=20 >>> On Friday 25 March 2016 22:07:02 Yoav Nir wrote: >>>>> On 25 Mar 2016, at 8:16 PM, Yuhong Bao >>>>> wrote: >>>>>=20 >>>>> I wonder if it would be possible to publish >>>>> draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of >>>>> RFC >>>>> 6101). It would start with >>>>> https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 >>>>> , >>>>> but the ciphersuites 0x60 and 0x61 would be added also as they >>>>> were >>>>> implemented in OpenSSL. >>>>>=20 >>>>> Yuhong Bao >>>>=20 >>>> Hi >>>>=20 >>>> It would be possible but I=E2=80=99m wondering some things: >>>>=20 >>>> 1. Are the original authors interested, or are there alternative >>>> authors willing to take this on? >>>>=20 >>>> 2. What is the point? All of the ciphersuites in there have been >>>> deprecated by some diediedie document or another, and no sane >>>> document author (here or elsewhere) would include any of these >>>> 56-bit >>>> ciphers in any profile for TLS that is intended to provide >>>> security. >>>> So what is the benefit? >>>=20 >>> 1. Showing why the code points are reserved. >>> 2. Having official list of code points which must not be enabled (so >>>=20 >>> that scanners can be complete) >>=20 >> Right. But this draft does not include RC4, RC2, and a number of = other >> bad IDEAs (pun intended), so it=E2=80=99s not a comprehensive list of = things >> you shouldn=E2=80=99t be doing. >=20 > it's not a die-die-die document. It's a document that will add the IDs > to = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml >=20 > 0x00,0x62 has no intrinsic meaning. = TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA > has. >=20 > What to do with them is second step. Oh, sorry. I hadn=E2=80=99t realized those were not in the registry. Yoav --Apple-Mail=_CD8E95F4-FAD7-40F3-97CB-AE8E299187E2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW+pUGAAoJECXR4BOacZZUX/YH/1hau812ZdeZjJxOBqphHpt8 N78plwaJ98rZB5/42+24+nL4AYgySaRdLwwZ9Wcrjfa/aKojRKGxW9b5NYbPbvz+ rFfTPhFMKTDe3vRoo7noihIcr9BOyQ7bWCw0BvtWTQ6x0NiG3yIZc2Yre+5Z8ZC+ 1+E7oRbGUQAGLgcEaRl/7sH5uLIC+3Fiuyn6seJb3NP+sPlFETH+KoHVZ2epebiX LX2RUCVWsIcctDJ5DGNWJdXSvETnXdwUqC2qM0Stxj4v7aJ06BM7waEoXNwZg6TW yCf6WV6S2MRQjSWxSfT6yR48MtKHtknBG7zdlF4M487aTq9jQZX9IlraPa1p8Kk= =wJ0I -----END PGP SIGNATURE----- --Apple-Mail=_CD8E95F4-FAD7-40F3-97CB-AE8E299187E2-- From nobody Tue Mar 29 09:18:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C665B12DAAA for ; Tue, 29 Mar 2016 09:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 AaIQuAX93adl for ; Tue, 29 Mar 2016 09:18:34 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 9CCB212DA35 for ; Tue, 29 Mar 2016 09:13:58 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id e6so24842985vkh.2 for ; Tue, 29 Mar 2016 09:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gwMmXzezMSbdamsRXQUl7/X5tgXoEubBnPeLqxzs+LU=; b=BufDN5Es7xv6Pl6EXGppqlun0RPWGMh6CzRazL+REFmJ5RhR9wRm/JJCnm5JFTCPei HOpe27XLQfvgnGwIFkugPpJ+AqOy78luA9GkFuj0jkXQgn3IATOeb70dTdjNsemasLnS FrRlV1v9c/lhgFd/vdu3z4hmMGIV2HshXFqsAycHoezi50nnryNQuPuEhy9tHoc2N06Z DhG8yXhlUADO+HzIkZCg0TzcDgzuS4P8CQEDcm9tvXKjRy7eDRUU7BV+ZemWTjWG6Gbi PAaOdLkKxUuscmA80BzF+j25lbYrTbrQhE+oJO9dVv5D8jroXqrnSBJ8GXsJcx3+VfKj 6k7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gwMmXzezMSbdamsRXQUl7/X5tgXoEubBnPeLqxzs+LU=; b=UBk8mgK5j/dwr7qhpQvauFdf5J+DVwXkij+MVO34ca/epmOi1jD8j4f61CUP7jCIgr yGN3MlJyprxCo0szVmtKL/0m8cQTg1uZzbLk+RnsA5XBrL2J8Pj5cgh9RVrCjldrBmdj 4L7C6siAdOfe+zAonMF4F3xuI/Mn3XStTmKvkWqRP8/Ysi+5aSDaSAmlnAr45KFfYFWa c4PSwX/G5Ze/gg2EykPqdUUGy4N4DkOBxgmb3mT+GJ+804oIfOHxO6fdcmhMEsMKvJBe RNRRzP+hS+D5UPzXyCvPt8qQdXf1sr/vTws0mgCoVXuRe4GbWgSiU63wjc18H5bkb2HI 9nGw== X-Gm-Message-State: AD7BkJLfNeVXqNOn1me+efvXCsnvdFbRVyaq+PqhW3x1z4iAElCrfnKv3BGVmCzlAfNeHUPkL4ZdcHIGwzmWQ2/Q MIME-Version: 1.0 X-Received: by 10.31.134.71 with SMTP id i68mr1828766vkd.46.1459268037589; Tue, 29 Mar 2016 09:13:57 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Tue, 29 Mar 2016 09:13:57 -0700 (PDT) In-Reply-To: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Tue, 29 Mar 2016 09:13:57 -0700 Message-ID: From: Bill Cox To: Sean Turner Content-Type: multipart/alternative; boundary=001a11458eb4038c0a052f325114 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:18:38 -0000 --001a11458eb4038c0a052f325114 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable qualified +1 Qualifications: I'm speaking for me, not Google. However, please be sure that the final spec supports both companies that prefer stateless PSK 0-RTT, as well as stateful PSK 0-RTT, such as emulating session-caches. As most people on this list know, stateful PSK 0-RTT can be more secure than any scheme possible with DHE 0-RTT, stateful or not. It is not true that the security properties of PSK-based 0-RTT and DHE-based 0-RTT are almost identical unless comparing stateless schemes. Stateful PSK 0-RTT can negotiate security properties over a 1-RTT connection and remember the results. For example, client certificates do not work properly over stateless 0-RTT because a proof of possession is not possible over 0-RTT connections. Further, full PFS _requires_ server-side state. The security of session-cache emulation based PSK 0-RTT can be nearly the same as TLS 1.2 security for HTTPS, but with full PFS due to the new RMS (session caches broke this in TLS 1.2). I am implying nothing about Google's preference when I say that some large companies may prefer the scalability of stateless 0-RTT, while smaller companies may prefer the imrpoved security of stateful schemes. Make sure both schemes remain supported as we cut out DHE 0-RTT functionality. Bill On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > All, > > To make sure we=E2=80=99ve got a clear way forward coming out of our BA s= essions, > we need to make sure there=E2=80=99s consensus on a couple of outstanding= issues. > So... > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mo= de > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT ar= e > almost identical, but 0-RTT PSK has better performance properties and is > simpler to specify and implement. Note that this does not permanently > preclude supporting DHE-based 0-RTT in a future extension, but it would n= ot > be in the initial TLS 1.3 RFC. > > If you think that we should keep DHE-based 0-RTT please indicate so now > and provide your rationale. > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11458eb4038c0a052f325114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
qualified +1

Qualifications: I'm sp= eaking for me, not Google.=C2=A0 However, please be sure that the final spe= c supports both companies that prefer stateless PSK 0-RTT, as well as state= ful PSK 0-RTT, such as emulating session-caches.

A= s most people on this list know, stateful PSK 0-RTT can be more secure than= any scheme possible with DHE 0-RTT, stateful or not.=C2=A0 It is not true = that the security properties of PSK-based 0-RTT and DHE-based 0-RTT are alm= ost identical unless comparing stateless schemes.

= Stateful PSK 0-RTT can negotiate security properties over a 1-RTT connectio= n and remember the results.=C2=A0 For example, client certificates do not w= ork properly over stateless 0-RTT because a proof of possession is not poss= ible over 0-RTT connections.=C2=A0 Further, full PFS _requires_ server-side= state.=C2=A0 The security of session-cache emulation based PSK 0-RTT can b= e nearly the same as TLS 1.2 security for HTTPS, but with full PFS due to t= he new RMS (session caches broke this in TLS 1.2).

I am implying nothing about Google's preference when I say that some l= arge companies may prefer the scalability of stateless 0-RTT, while smaller= companies may prefer the imrpoved security of stateful schemes.=C2=A0 Make= sure both schemes remain supported as we cut out DHE 0-RTT functionality.<= /div>

Bill

On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <sean@sn= 3rd.com> wrote:
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

There also seems to be (rougher) consensus not to support 0-RTT via DHE=C2= =A0 (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT= are almost identical, but 0-RTT PSK has better performance properties and = is simpler to specify and implement. Note that this does not permanently pr= eclude supporting DHE-based 0-RTT in a future extension, but it would not b= e in the initial TLS 1.3 RFC.

If you think that we should keep DHE-based 0-RTT please indicate so now and= provide your rationale.

J&S

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

--001a11458eb4038c0a052f325114-- From nobody Tue Mar 29 09:24:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB9B12DAA7 for ; Tue, 29 Mar 2016 09:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 wmwtWGx6I2_5 for ; Tue, 29 Mar 2016 09:24:44 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 DD82012DA46 for ; Tue, 29 Mar 2016 09:19:19 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id e6so25055481vkh.2 for ; Tue, 29 Mar 2016 09:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tVBwa9+fPO8axOMWLJ+8oLb/tjIIxaJ1E6tV/q3m9X4=; b=YJnUp56YN0SCJHqBpVKf6gRoPGz+qgz9D1FV8BbKe+W4i51HeY0VZwZ2g96e+Gku9B rl+gquh3oaDqopuy9Kp0e8aO27wQEuHwpB5ZusFYJIe8/s3pz/XPbhVwRzq+Ea+m0CRz LlkHFRYqdfyg3Bwj0RLzH6JAOC0NNsItFB7PDx0iXp+XzF9BA2o5CDYCLEHEgUAL9om2 KZcZv4OHtWqdmBn9w0e/FlPt/wd/fA1EkiWjcrpRw4EkzksK6nnUIZG6zxO/f3LGvc+o kE9JgvYn50Pho3s6ZTDeVHd4hmEerM6uaEa4hfathT4Wed4kmmUSaSGuwi3XtnxtZX5H CUNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tVBwa9+fPO8axOMWLJ+8oLb/tjIIxaJ1E6tV/q3m9X4=; b=iuGkFWbjJkUxDGgGxgkFrQa33IO20gz+dyYKZkYHY7IpYRzi4wUOy9y0BoGl6IMdGe CkiZ2V84fQ+n+wuX8Hz6R5VKr1QnX5CIyKmkjByWLIlFSw/qOLYo/3tJ3n/CWLSuTKSn t5EiZfqji1uiknbpNzzNCL7cI0YZkDF+n38A36+9Iudrzp+xwvPxy3lIcjaJKhXeJn+/ yjQJQBeM2e+OQBPLFeQLkkt3BE26bLjdGK6OD4RDsAWVamHueuMgihlZkrnU4H10XYBL YbMYGXQLQ6OY6LzSdoIE4u6kOlFwyljakQHLNgwYtrRGvNxtuBrtCN3Z+bOSCl+yByNl QreA== X-Gm-Message-State: AD7BkJKmfk7CjlSaExZYsR/A9qZmZmwnhgmMKXa8TuSgeo6E740pb/2+DjbvgC418WhZ1VDW2UsbIOvpbwpHcUGe MIME-Version: 1.0 X-Received: by 10.159.38.116 with SMTP id 107mr1826935uag.155.1459268358848; Tue, 29 Mar 2016 09:19:18 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Tue, 29 Mar 2016 09:19:18 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2016 09:19:18 -0700 Message-ID: From: Bill Cox To: Sean Turner Content-Type: multipart/alternative; boundary=001a1140a81c299cc5052f32641f Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:24:46 -0000 --001a1140a81c299cc5052f32641f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 Again, I am not speaking for Google. However, in this case, I am confident we are right about this for just about every application. Bill On Tue, Mar 29, 2016 at 5:59 AM, Sean Turner wrote: > All, > > To make sure we=E2=80=99ve got a clear way forward coming out of our BA s= essions, > we need to make sure there=E2=80=99s consensus on a couple of outstanding= issues. > So... > > It seems that there is a clear consensus not to support 0-RTT client > authentication in TLS 1.3 at this time. If you think 0-RTT client > authentication needs to be supported please indicate so now and provide > your rationale. > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1140a81c299cc5052f32641f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

Again, I am not speaking for Google.= =C2=A0 However, in this case, I am confident we are right about this for ju= st about every application.

Bill

On Tue, Mar 29, 2016 at= 5:59 AM, Sean Turner <sean@sn3rd.com> wrote:
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

It seems that there is a clear consensus not to support 0-RTT client authen= tication in TLS 1.3 at this time.=C2=A0 If you think 0-RTT client authentic= ation needs to be supported please indicate so now and provide your rationa= le.

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

--001a1140a81c299cc5052f32641f-- From nobody Tue Mar 29 09:57:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E9712DB74 for ; Tue, 29 Mar 2016 09:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igVqbzxW0DVB for ; Tue, 29 Mar 2016 09:57:29 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9DA812DBC9 for ; Tue, 29 Mar 2016 09:48:54 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2TGJp3L012005 for ; Tue, 29 Mar 2016 09:48:46 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=/kDJVWVbeo8cq2N7fgDm5zg/sd5DqZ/cq8uoKnoOEK0=; b=RQ+b7pe38Obft8JPY3rBs3LBv7TdNWBd2tKPhNr5V0a1bELXwz07ZtngWpAaPrw4L6pZ w8P4VSeIdwmaJhTPdl0ASy673JUdK+2/oE2iRgueUSzrDvJFa8SZGVe01NfsHH6Ul8f9 gV7brsly91wJgo9oPI0xGEMkKfpCehmmC4w= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 21yuu5gmmr-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 29 Mar 2016 09:48:46 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB09.TheFacebook.com ([fe80::b128:36fa:e69b:a338%12]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 09:48:13 -0700 From: Subodh Iyengar To: "tls@ietf.org" Thread-Topic: Tickets and cross protocol attacks Thread-Index: AdGJ2hy6RRaBdpbjRFKOvt6QZ8JoPA== Date: Tue, 29 Mar 2016 16:48:13 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564FE17B@PRN-MBX01-4.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99564FE17BPRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-29_06:, , signatures=0 Archived-At: Subject: [TLS] Tickets and cross protocol attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:57:31 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99564FE17BPRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that a= ttacks on previous version of TLS can be used to attack new version of TLS. One thing that is not mandated by TLS 1.3 is separation of session tickets = and session ids between TLS protocols. For example a client could use a tic= ket negotiated with a previous version of TLS with TLS1.3. This could resul= t in interesting situations: 1. Bypassing client auth If a server restricts a super-secure resource only over TLS1.3 with client = auth and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker h= as a SLOTH client impersonation attack against TLS1.2, they can get a TLS t= icket from TLS1.2 connection issued by a server. The ticket would have the = original client auth encrypted in it. The attacker could then use the ticke= t with TLS1.3 PSK resumption and authenticate as the original client. 2. PSK 0-RTT If the client agrees to use the ticket negotiated over a previous TLS1.2 co= nnection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An attacker= that has a SLOTH attack for server impersonation could inject their own TL= S ticket into the connection with a client in a TLS1.2 handshake. The 0-RTT= data would be encrypted with an attacker known key and they could decrypt = the 0-RTT data. If the connection continues to use PSK, the attacker can de= crypt more data, however if the connection uses PSK + (EC)DHE then the atta= ckers capability will be limited to decrypting the 0-RTT data. 3. Using DROWN style attacks The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0 -= TLS1.2 handshake. This might cause interesting new attacks to open up wher= e a TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server. Even if a server enforces strict key separation between different TLS versi= ons (which is very difficult), if tickets or session ids are reusable acros= s TLS versions either on the client or the server, I believe these types of= attacks remain possible. We could consider adding a section detailing the requirements for tickets f= or security. Even though there is a recommended construction, we could requ= ire a few things for the security of TLS 1.3: 1. Adding original TLS version to the ticket, so that TLS1.3 server can rej= ect tickets issued by previous versions to prevent client authentication fo= rgeries 2. Restricting 0-RTT data to only be encrypted with PSKs issued during a pr= evious TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted 3. If a PSK is set via a ticket or session id, PSK modes for both normal PS= K as well as 0-RTT should be only used with the protocol it was first negot= iated with and prevent fallback. For example if a client received a PSK fro= m TLS1.3, it should not allow either 0-RTT or resumed handshakes using that= ticket to fallback back to lower protocols. Before a client knows that a server supports TLS1.3 and if a client allows = TLS1.2 fallbacks, I don't think there's anything we can do to prevent that = downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently), howe= ver once TLS1.3 is negotiated, the above things will prevent downgrade to T= LS1.2. Cheers, Subodh Iyengar --_000_974CF78E8475CD4CA398B1FCA21C8E99564FE17BPRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown= that attacks on previous version of TLS can be used to attack new version = of TLS.

One thing that is not mandated by TLS 1.3 is separation of session tickets = and session ids between TLS protocols. For example a client could use a tic= ket negotiated with a previous version of TLS with TLS1.3. This could resul= t in interesting situations:

1. Bypassing client auth
If a server restricts a super-secure resource only over TLS1.3 with client = auth and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker h= as a SLOTH client impersonation attack against TLS1.2, they can get a TLS t= icket from TLS1.2 connection issued by a server. The ticket would have the original client auth encrypted in i= t. The attacker could then use the ticket with TLS1.3 PSK resumption and au= thenticate as the original client.

2. PSK 0-RTT
If the client agrees to use the ticket negotiated over a previous TLS1.2 co= nnection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An attacker= that has a SLOTH attack for server impersonation could inject their own TL= S ticket into the connection with a client in a TLS1.2 handshake. The 0-RTT data would be encrypted with an = attacker known key and they could decrypt the 0-RTT data. If the connection= continues to use PSK, the attacker can decrypt more data, however if the c= onnection uses PSK + (EC)DHE then the attackers capability will be limited to decrypting the 0-RTT data.

3. Using DROWN style attacks
The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0 -= TLS1.2 handshake. This might cause interesting new attacks to open up wher= e a TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server.

Even if a server enforces strict key separation between different TLS versi= ons (which is very difficult), if tickets or session ids are reusable acros= s TLS versions either on the client or the server, I believe these types of= attacks remain possible. 

We could consider adding a section detailing the requirements for tickets f= or security. Even though there is a recommended construction, we could requ= ire a few things for the security of TLS 1.3:
1. Adding original TLS version to the ticket, so that TLS1.3 server can rej= ect tickets issued by previous versions to prevent client authentication fo= rgeries
2. Restricting 0-RTT data to only be encrypted with PSKs issued during a pr= evious TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted<= br> 3. If a PSK is set via a ticket or session id, PSK modes for both normal PS= K as well as 0-RTT should be only used with the protocol it was first negot= iated with and prevent fallback. For example if a client received a PSK fro= m TLS1.3, it should not allow either 0-RTT or resumed handshakes using that ticket to fallback back to lower pr= otocols.

Before a client knows that a server supports TLS1.3 and if a client allows = TLS1.2 fallbacks, I don't think there's anything we can do to prevent that = downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently), howe= ver once TLS1.3 is negotiated, the above things will prevent downgrade to TLS1.2.

Cheers,
Subodh Iyengar
--_000_974CF78E8475CD4CA398B1FCA21C8E99564FE17BPRNMBX014TheFac_-- From nobody Tue Mar 29 10:26:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F2512DA79 for ; Tue, 29 Mar 2016 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] 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 mgvlaZr3XCfU for ; Tue, 29 Mar 2016 10:26:23 -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 A391312DBFE for ; Tue, 29 Mar 2016 10:14:35 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h129so27167835ywb.1 for ; Tue, 29 Mar 2016 10:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/67NKsUVQdiYqPHyMB6d7Rc3WyiRbk8OV8G+sookWgE=; b=D64Gye7DCTcl5Z35j4YNSNrLDMGxfOs+cBmYfxlO0GpgH8orCJhKXDUknzvfT1LhVw vrx7dxel9XWgiC+YJ34SXHMQ1a+n19dYqlpS8Cv+ENWJj910v/Eiy95OYVEohidJO25a 3vMFZyM6jJOf9KQi0lO5r4r0c6KTa713Z1z7kVOr+ALD9QBdjqXfJu4NQMA02QUiiImI N+/7bIwUtCXGan8mLDU1JCDmtzLCHQvmM0MJdMsmYtiMwmc2kAFm0ubEk7hWMp49s5wC UA+3/HJ7Wh8GlqpkfvlFobOfsB80a812I63A7A3wLThHbiMU8fSRGjabOyXGtng/tz2q NFSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/67NKsUVQdiYqPHyMB6d7Rc3WyiRbk8OV8G+sookWgE=; b=V93Pc+XDTiYCy7q+SclL2cR17UXCJsWj7ZrRIoZEPRod2unnRo1SI/mT9Vm8xKYF++ l7LTmC0GgKFwQ6PPAv7HIvm5cr6C7fV4H4hbqGUlvRWsLtFW/ky6dmdlh6sm8H5Pnyjs ocB1MhO6AiFeaEP+bVDC2OJVFz+GpgjRYCyf6BY6B1qrZ4EtPBMz3+pRx748CnJN+Crl 8bc6/tOXjSZmMaGFdxJn+WZG0hh+rWFPO4PmrAeQxQIApRwok69Lv56F8MGGIMmwicld KD4SYWGtrb4HZLM7lDyYZlNFDYTxy3vCwtH+Sn5Q46+BMOcKer3Xf44wYCXrePCtpBB1 Abxg== X-Gm-Message-State: AD7BkJJV8itkeLPQMe4SajVZ/Pp4AiBx/u+yn0CyJW3qwulljjTpVwRrPmG8MV1Kp078DTbwyhb8wFnqxEIfr57i MIME-Version: 1.0 X-Received: by 10.129.102.8 with SMTP id a8mr1727943ywc.332.1459271674833; Tue, 29 Mar 2016 10:14:34 -0700 (PDT) Received: by 10.37.113.67 with HTTP; Tue, 29 Mar 2016 10:14:33 -0700 (PDT) In-Reply-To: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Tue, 29 Mar 2016 10:14:33 -0700 Message-ID: From: Wan-Teh Chang To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:26:25 -0000 On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mode > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT > are almost identical, but 0-RTT PSK has better performance properties and > is simpler to specify and implement. Note that this does not permanently > preclude supporting DHE-based 0-RTT in a future extension, but it would > not be in the initial TLS 1.3 RFC. This will remove a feature from the QUIC protocol, so I'd be interested in hearing the QUIC team's opinion. Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm not sure if "simplier to specify" should be an important factor. However, "simpler to implement" is an important consideration. I am curious to know how we concluded that 0-RTT PSK is simpler to implement. Did anyone implement both 0-RTT modes and can compare the difficulties? As for 0-RTT PSK having better performance, that comes at the cost of a previous full handshake with the server. Also, TLS 1.3 clients that want to do 0-RTT PSK across an application shutdown will need to deal with the harder problem of storing PSKs persistently. Wan-Teh Chang From nobody Tue Mar 29 11:10:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8ED712E0E3 for ; Tue, 29 Mar 2016 11:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1_IKo3c7FXe for ; Tue, 29 Mar 2016 11:10:19 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D227212DFD9 for ; Tue, 29 Mar 2016 10:45:22 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2THdH2c010008; Tue, 29 Mar 2016 10:45:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=eSReZMGc8+L0x19bgWHJ4dXwqxB9tlEOGJiKS2T3nSg=; b=FnTivUM/fUN2eHEgrkQfuOIPHr9qKidiLXCrivsosABRe0PrOW/H3OR3SHFc0Gl2OwHu I3u+Rg9S1EDjlTX27+QZQ5NLhpU5RHUewfz7b3ID019C/IcSp60CUT4rlSEzMAjVKB5r uDkD1rQvFrwKpXKI8FPWMERGzWLM1+Ck0uE= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 21yuu5gy92-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 10:45:14 -0700 Received: from PRN-MBX02-1.TheFacebook.com ([169.254.2.203]) by PRN-CHUB16.TheFacebook.com ([fe80::7948:a494:45d7:3dd9%12]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 10:45:09 -0700 From: Kyle Nekritz To: Martin Thomson , "tls@ietf.org" Thread-Topic: [TLS] Narrowing the replay window Thread-Index: AQHRiaXeceDcrO60S02txmAC1DtII59wsA/w Date: Tue, 29 Mar 2016 17:45:08 +0000 Message-ID: <8A79BFEDF6986C46996566F91BB63C860D66E592@PRN-MBX02-1.TheFacebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-29_06:, , signatures=0 Archived-At: Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:10:21 -0000 I think this will better account for the round trip delay if the elapsed_ti= me is defined on the client as the time since the request for the session t= icket (in other words, the time since the client hello was sent). That way = both the server computed time and the client reported time will include 1 r= ound trip. -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, March 29, 2016 6:29 AM To: tls@ietf.org Subject: [TLS] Narrowing the replay window https://github.com/tlswg/tls13-spec/pull/437 In short, have the client report the time since it received the configurati= on. Then have the server reject early data if the time doesn't match. I think that this is a relatively easy change to make. Now, your exposure = to replay is much less. It's not ironclad, since the server needs to account for a round trip, but = I think that would could probably get the window down to single-digit secon= ds. _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dl2j4BjkO0Lc3u4CH2z7= jPw&m=3DyV13qQWQtVr_en1cI1kcs4zRx07qsOQ4PNkMQFvEIQw&s=3DXQHs_Zge-MaIU6aeUJx= O3PTm-2SGhf8O-AAoRKk_vws&e=3D=20 From nobody Tue Mar 29 11:38:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284C912DB19 for ; Tue, 29 Mar 2016 11:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaQFtNzBheHj for ; Tue, 29 Mar 2016 11:38:36 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 E378312DF42 for ; Tue, 29 Mar 2016 11:09:17 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id l20so21690501igf.0 for ; Tue, 29 Mar 2016 11:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=XBKQ4i/kfvu1jjBuu7LjAIVjJooYnc03DVoqWzTigO4=; b=gmD06cS1TCr1zirIYKAiCTxeHFuxZaxLM9QIY2GY8Adm3N5RG8YmNkCQDcugNVfZNA UmZuqL26Mh/GWUJPGH9eqYjT8tSSH+ObDv6Z3vIsECfyv2x5Lnq+48aSm+x7hRsVDjS6 R4v7noR/ejwcscjCEXoJvcCMs1P16sUAaBGq4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=XBKQ4i/kfvu1jjBuu7LjAIVjJooYnc03DVoqWzTigO4=; b=ElY5Gsfn4b1yjr4Meife/ii4fae6fGZBrsa2OwPTbd8PBhuGG27USKjFqvoRfwGb38 KGWyBKwBaFVwbrJGlwZANclJLjYtyD1yP82Aag9mZUtWFkgwk1fvah7cju5ZFwePQvgu HX5RWsPbio0hIpJU0JmQNJPZ1NmIbc92QaIU6K/UfrUpCWlcEpVsqoDpug61GbtoybNP dFAKWsTgTcXB2SC6wmOk2DJ8wLRy1uXN2usUSz0HLHFJhXD69pR89H0Nnm6DC7Ux4LXy jyLt5XD6DA4ntMrMMKKKDQGcv7kwPSTI6pute0ATTEHi/1J7E8N5WNWOAnFDrKWV+mKw JD0A== X-Gm-Message-State: AD7BkJLO/RGC0pqw9fh2OwB7Lyags3sKT6P0/eO+egjVJvoKPLxlYMU4gn94ewHwPPViylGXZRQ2XAl8A3H37zM+ X-Received: by 10.50.30.73 with SMTP id q9mr18111326igh.77.1459274466562; Tue, 29 Mar 2016 11:01:06 -0700 (PDT) MIME-Version: 1.0 References: <974CF78E8475CD4CA398B1FCA21C8E99564FE17B@PRN-MBX01-4.TheFacebook.com> In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99564FE17B@PRN-MBX01-4.TheFacebook.com> From: David Benjamin Date: Tue, 29 Mar 2016 18:00:56 +0000 Message-ID: To: Subodh Iyengar , "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bdc0a8435e489052f33d034 Archived-At: Subject: Re: [TLS] Tickets and cross protocol attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:38:40 -0000 --047d7bdc0a8435e489052f33d034 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar wrote: > Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that > attacks on previous version of TLS can be used to attack new version of > TLS. > > One thing that is not mandated by TLS 1.3 is separation of session tickets > and session ids between TLS protocols. For example a client could use a > ticket negotiated with a previous version of TLS with TLS1.3. This could > result in interesting situations: > I agree that the spec should clearly forbid cross-version resumption. I filed https://github.com/tlswg/tls13-spec/issues/136 some time ago about this. It got closed since session resumption was reworked for 1.3, but it doesn't look like the clarifications on matching versions ever happened, just the removal of the bad client advice. On the server, OpenSSL already includes the version in the SSL_SESSION structure, and recent enough versions of it will not accept sessions at the wrong version: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9e189b9dc10786c755919e6792e923c584c918a1 No client implementation which I tested allowed a server to do this either. They treated it as a fatal connection error. (Which also means there is no reason for a server to do it because it will not work anyway.) > 1. Bypassing client auth > If a server restricts a super-secure resource only over TLS1.3 with client > auth and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker > has a SLOTH client impersonation attack against TLS1.2, they can get a TLS > ticket from TLS1.2 connection issued by a server. The ticket would have the > original client auth encrypted in it. The attacker could then use the > ticket with TLS1.3 PSK resumption and authenticate as the original client. > > 2. PSK 0-RTT > If the client agrees to use the ticket negotiated over a previous TLS1.2 > connection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An > attacker that has a SLOTH attack for server impersonation could inject > their own TLS ticket into the connection with a client in a TLS1.2 > handshake. The 0-RTT data would be encrypted with an attacker known key and > they could decrypt the 0-RTT data. If the connection continues to use PSK, > the attacker can decrypt more data, however if the connection uses PSK + > (EC)DHE then the attackers capability will be limited to decrypting the > 0-RTT data. > > 3. Using DROWN style attacks > The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0 > - TLS1.2 handshake. This might cause interesting new attacks to open up > where a TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server. > > Even if a server enforces strict key separation between different TLS > versions (which is very difficult), if tickets or session ids are reusable > across TLS versions either on the client or the server, I believe these > types of attacks remain possible. > > We could consider adding a section detailing the requirements for tickets > for security. Even though there is a recommended construction, we could > require a few things for the security of TLS 1.3: > 1. Adding original TLS version to the ticket, so that TLS1.3 server can > reject tickets issued by previous versions to prevent client authentication > forgeries > 2. Restricting 0-RTT data to only be encrypted with PSKs issued during a > previous TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted > 3. If a PSK is set via a ticket or session id, PSK modes for both normal > PSK as well as 0-RTT should be only used with the protocol it was first > negotiated with and prevent fallback. For example if a client received a > PSK from TLS1.3, it should not allow either 0-RTT or resumed handshakes > using that ticket to fallback back to lower protocols. > > Before a client knows that a server supports TLS1.3 and if a client allows > TLS1.2 fallbacks, I don't think there's anything we can do to prevent that > downgrade to TLS1.2 (apart from naming TLS 1.3 resources differently), > however once TLS1.3 is negotiated, the above things will prevent downgrade > to TLS1.2. > I disagree with point #3 and think the "prevent fallback" portion would be a mistake. Possession of a TLS 1.3 session to offer should not disable TLS 1.2 if the client would have accepted this without that session. It's the same as my complaint about RFC 5246 E.1's paragraph in the bug linked earlier. While it is enticing to do away with TLS 1.2 this way, the reality is deployments are messy and can be heterogeneous. The service may be in the middle of deploying (or rolling back!) a change across many machines. Or perhaps it's not as well-managed and simply has two completely different machines behind it. We've seen problems in Chrome due to version-locking behavior in OpenSSL against real services with, say, one TLS 1.0 machine and one TLS 1.2 machine. They did not cross-resume sessions, but it doesn't matter. By the time you find that out, the version has been locked. (This prompted a rewrite in BoringSSL. The problem has also recently been fixed on OpenSSL master.) TLS client session caches are caches. Entries may be dropped from them at any point. It would be a mistake to use this kind of volatile state for downgrade protection. Further, some implementations will drop sessions on fatal alerts ("Upon transmission or receipt of a fatal alert message, both parties immediately close the connection. Servers and clients MUST forget any session-identifiers, keys, and secrets associated with a failed connection. Thus, any connection terminated with a fatal alert MUST NOT be resumed."), so this could easily be bypassed. Instead, TLS 1.3 adds this mechanism which I think is much preferable: https://github.com/tlswg/tls13-spec/pull/284 David > Cheers, > Subodh Iyengar > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bdc0a8435e489052f33d034 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 29, 2016 at 12:57 PM Subodh Iyengar <<= a href=3D"mailto:subodh@fb.com">subodh@fb.com> wrote:
=
Recent attacks like SLOTH, DROWN, PCKS1.5 padding oracles have shown that= attacks on previous version of TLS can be used to attack new version of TL= S.

One thing that is not mandated by TLS 1.3 is separation of session tickets = and session ids between TLS protocols. For example a client could use a tic= ket negotiated with a previous version of TLS with TLS1.3. This could resul= t in interesting situations:

I agree that the spec should clearly forbid cross-version resumption= . I filed https:= //github.com/tlswg/tls13-spec/issues/136 some time ago about this. It g= ot closed since session resumption was reworked for 1.3, but it doesn't= look like the clarifications on matching versions ever happened, just the = removal of the bad client advice.

On the server, O= penSSL already includes the version in the SSL_SESSION structure, and recen= t enough versions of it will not accept sessions at the wrong version:

No client implementation which I tested allow= ed a server to do this either. They treated it as a fatal connection error.= (Which also means there is no reason for a server to do it because it will= not work anyway.)
=C2=A0
1. Bypassing client auth
If a server restricts a super-secure resource only over TLS1.3 with client = auth and also shares ticket keys across TLS1.2 and TLS1.3. If an attacker h= as a SLOTH client impersonation attack against TLS1.2, they can get a TLS t= icket from TLS1.2 connection issued by a server. The ticket would have the original client auth encrypted in i= t. The attacker could then use the ticket with TLS1.3 PSK resumption and au= thenticate as the original client.

2. PSK 0-RTT
If the client agrees to use the ticket negotiated over a previous TLS1.2 co= nnection in a subsequent handshake as the PSK for 0-RTT TLS1.3. An attacker= that has a SLOTH attack for server impersonation could inject their own TL= S ticket into the connection with a client in a TLS1.2 handshake. The 0-RTT data would be encrypted with an = attacker known key and they could decrypt the 0-RTT data. If the connection= continues to use PSK, the attacker can decrypt more data, however if the c= onnection uses PSK + (EC)DHE then the attackers capability will be limited to decrypting the 0-RTT data.

3. Using DROWN style attacks
The ticket from a TLS1.3 handshake can be used in the context of a TLS1.0 -= TLS1.2 handshake. This might cause interesting new attacks to open up wher= e a TLS1.3 ticket is forwarded to a TLS1.0 - TLS1.2 server.

Even if a server enforces strict key separation between different TLS versi= ons (which is very difficult), if tickets or session ids are reusable acros= s TLS versions either on the client or the server, I believe these types of= attacks remain possible.=C2=A0

We could consider adding a section detailing the requirements for tickets f= or security. Even though there is a recommended construction, we could requ= ire a few things for the security of TLS 1.3:
1. Adding original TLS version to the ticket, so that TLS1.3 server can rej= ect tickets issued by previous versions to prevent client authentication fo= rgeries
2. Restricting 0-RTT data to only be encrypted with PSKs issued during a pr= evious TLS 1.3 handshake, so that 0-RTT and other data cannot be decrypted<= br> 3. If a PSK is set via a ticket or session id, PSK modes for both normal PS= K as well as 0-RTT should be only used with the protocol it was first negot= iated with and prevent fallback. For example if a client received a PSK fro= m TLS1.3, it should not allow either 0-RTT or resumed handshakes using that ticket to fallback back to lower pr= otocols.

Before a client knows that a server supp= orts TLS1.3 and if a client allows TLS1.2 fallbacks, I don't think ther= e's anything we can do to prevent that downgrade to TLS1.2 (apart from = naming TLS 1.3 resources differently), however once TLS1.3 is negotiated, t= he above things will prevent downgrade to TLS1.2.

I disagree with point #3 and think the "pr= event fallback" portion would be a mistake. Possession of a TLS 1.3 se= ssion to offer should not disable TLS 1.2 if the client would have accepted= this without that session.

It's the same as m= y complaint about RFC 5246 E.1's paragraph in the bug linked earlier. W= hile it is enticing to do away with TLS 1.2 this way, the reality is deploy= ments are messy and can be heterogeneous. The service may be in the middle = of deploying (or rolling back!) a change across many machines. Or perhaps i= t's not as well-managed and simply has two completely different machine= s behind it.

We've seen problems in Chrome due= to version-locking behavior in OpenSSL against real services with, say, on= e TLS 1.0 machine and one TLS 1.2 machine. They did not cross-resume sessio= ns, but it doesn't matter. By the time you find that out, the version h= as been locked. (This prompted a rewrite in BoringSSL. The problem has also= recently been fixed on OpenSSL master.)

TLS clien= t session caches are caches. Entries may be dropped from them at any point.= It would be a mistake to use this kind of volatile state for downgrade pro= tection. Further, some implementations will drop sessions on fatal alerts (= "Upon transmission or receipt of a fatal alert message, both parties i= mmediately close the connection. Servers and clients MUST forget any sessio= n-identifiers, keys, and secrets associated with a failed connection. Thus,= any connection terminated with a fatal alert MUST NOT be resumed."), = so this could easily be bypassed.

Instead, TLS 1.3= adds this mechanism which I think is much preferable:

David
=C2=A0
Cheers,
Subodh Iyengar
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--047d7bdc0a8435e489052f33d034-- From nobody Tue Mar 29 11:45:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EEF12E103 for ; Tue, 29 Mar 2016 11:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 zacJExSRYEd3 for ; Tue, 29 Mar 2016 11:45:02 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038DD12E07E for ; Tue, 29 Mar 2016 11:13:15 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p65so39109376wmp.0 for ; Tue, 29 Mar 2016 11:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=GZNPo+qA97WkAVcpgrZV29OkOwEPb7635EZOrSxmkOU=; b=DsywfrAvxtRCgaeur3nxrv/XGcVorChsQ8TI8ihjL+Oc/Pc7rCwVQPMw3wQ+Vh6lqa mqmSniApt8prKi5o2xjYVObRIcuQHZShXNjlsmYObSy1w5XzvKJLpy/eRYgD8OIXtPt+ NoLkVu/E1dTSWEyzuHGnyAHvqXkA6tuRx34tnxuDnYb7KOWZY2GsqbRaPXSmt+QqsegX yWqTGQTnePbfPLlJJXEOyUMTECLVHKVm/YDO20wLAk78lS+QoyC/alEt9VMduTna6u1c buuf86K0TxqQC5uN4Br/4uuo1Kkkczm3A4X9U5/kEM09zZg7n3jBSE57dG3D/ixvEmmv IM7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GZNPo+qA97WkAVcpgrZV29OkOwEPb7635EZOrSxmkOU=; b=kaRTSquZCB4T7vhNye6GUKFAVrrCtWmQu4Y6d0Od+8iFZxzmMJtmfAAjVpthbdBW46 WIdndBLGDNC0k+jehAIkxWkHTKku//xnsnPcZvP0DbQ4CBC5rMO+WA8C5bT2PAZScizK puLoGo0Bnr9mU4mlX0UWBmqsfc8stK1hreBkoPz9FQBJB3ut0fwdfyrrxktNI9j0qGOt 9H+HFAe28f/ioroYbQ5yyNfcZZ10AWl5JJ+mI3R4i906jmSXSXGUcTVhmEv7LfT5m/oT iP7Pyt065D2+XKj5pvMUfZss8ZnkPhob7/FkTscUJc/F84LJIvZ1TyUKaUShoxSH7AtI KNlg== X-Gm-Message-State: AD7BkJJFyo+kEz0+SKB9Mtba38br5+fz5rXkVHpPWH7ggOL6BLhaArw3tINY7GIrxRcs9+l42QiYcoNtLb8F7Wm1 MIME-Version: 1.0 X-Received: by 10.194.116.9 with SMTP id js9mr4836270wjb.112.1459275193425; Tue, 29 Mar 2016 11:13:13 -0700 (PDT) Received: by 10.28.27.132 with HTTP; Tue, 29 Mar 2016 11:13:13 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Tue, 29 Mar 2016 11:13:13 -0700 Message-ID: From: Ryan Hamilton To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=001a1130d2188906c2052f33fb51 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:45:05 -0000 --001a1130d2188906c2052f33fb51 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote: > On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > > > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT > mode > > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT > > are almost identical, but 0-RTT PSK has better performance properties a= nd > > is simpler to specify and implement. Note that this does not permanentl= y > > preclude supporting DHE-based 0-RTT in a future extension, but it would > > not be in the initial TLS 1.3 RFC. > > This will remove a feature from the QUIC protocol, so I'd be > interested in hearing the QUIC team's opinion. > > Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm > not sure if "simplier to specify" should be an important factor. > However, "simpler to implement" is an important consideration. I am > curious to know how we concluded that 0-RTT PSK is simpler to > implement. Did anyone implement both 0-RTT modes and can compare the > difficulties? > > As for 0-RTT PSK having better performance, that comes at the cost of > a previous full handshake with the server. Also, TLS 1.3 clients that > want to do 0-RTT PSK across an application shutdown will need to deal > with the harder problem of storing PSKs persistently. > =E2=80=8BWe've talked about losing DHE 0-RTT within the team, and have conc= luded that PSK resumption should be an acceptable alternative. As you suspected however, we have not implemented =E2=80=8BPSK resumption and are instead wa= iting until we have a TLS 1.3 implementation which supports it which we will use in QUIC. Since Chrome does not persist the TLS session resumption cache to disk, we will likely lose 0-RTT across browser restarts, which is a bit of a bummer. It's probably not too bad, but it does likely suggest we'll need to come up with something more complex for mobile. --001a1130d2188906c2052f33fb51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 2= 9, 2016 at 10:14 AM, Wan-Teh Chang <wtc@google.com> wrote:
On = Tue, Mar 29, 2016 at 6:11 AM, Sean Turner <sean@sn3rd.com> wrote:
>
> There also seems to be (rougher) consensus not= to support 0-RTT via DHE
> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT= mode
> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT=
> are almost identical, but 0-RTT PSK has better performance properties = and
> is simpler to specify and implement. Note that this does not permanent= ly
> preclude supporting DHE-based 0-RTT in a future extension, but it woul= d
> not be in the initial TLS 1.3 RFC.

This will remove a feature from the QUIC protocol, so I'd be
interested in hearing the QUIC team's opinion.

Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm not sure if "simplier to specify" should be an important factor.<= br> However, "simpler to implement" is an important consideration. I = am
curious to know how we concluded that 0-RTT PSK is simpler to
implement. Did anyone implement both 0-RTT modes and can compare the
difficulties?

As for 0-RTT PSK having better performance, that comes at the cost of
a previous full handshake with the server. Also, TLS 1.3 clients that
want to do 0-RTT PSK across an application shutdown will need to deal
with the harder problem of storing PSKs persistently.
=
=E2=80=8BWe've talked about losing DHE 0-RTT w= ithin the team, and have concluded that PSK resumption should be an accepta= ble alternative. As you suspected however, we have not implemented =E2=80= =8BPSK resumption and are instead waiting until we have a TLS 1.3 implement= ation which supports it which we will use in QUIC.

Since Chrome does not persist the TLS session resumption cache t= o disk, we will likely lose 0-RTT across browser restarts, which is a bit o= f a bummer. It's probably not too bad, but it does likely suggest we= 9;ll need to come up with something more complex for mobile.

--001a1130d2188906c2052f33fb51-- From nobody Tue Mar 29 12:04:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4FE12D9C1 for ; Tue, 29 Mar 2016 12:04:08 -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 lfE7cF3pZ_NC for ; Tue, 29 Mar 2016 12:04:01 -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 B208612DAA3 for ; Tue, 29 Mar 2016 11:29:02 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id h65so29933780ywe.0 for ; Tue, 29 Mar 2016 11:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jhJpBn6Dk/GH9QOk12jt3gb4Cw+6HvD1+s+f4E8WgaQ=; b=mvigb3z/0Vy/U//EIt0G12MMoTwBqpQMeAjHhqfU1vZvWTkvmAVNxTomjOeXLbSQ4W Ozedzsg9q/RsRfIU0sLBinZwywG5fyFOqbUTxeQ4S1PmdidLyMfAIof1sRsMEbg7iGEx xx8HmhWifh7+WJarWmK26INq1E+QHH+hozLNYmENwF2QjvSALfjTzF6HkK1bhebtuKtW zFtxc7GvKnVqVONBJBMhUDh6mgbB42ZXzlryb+R4xZ2+Rq/GrSE6ktI0cDlsgbV/kfip tDs3Mj8rMHJ0jVDdoW4UGrO6XwbGeBifiZE+k8NxtCykkNQIeGkfgPqu6C2PHWSNsQmw IodA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jhJpBn6Dk/GH9QOk12jt3gb4Cw+6HvD1+s+f4E8WgaQ=; b=NV1g33ikX5qHCr/sw9zIeT6lbKkhGF6HPWc9DkxUn5rcbxKCbgL1NUuGBAzNPqmtpK jz9uB752s/D768G4x+dLj3g31CEETKbuLdUvCQWGOz3Jz3U6Vy7NR4We9O4TcHdu6+pT Au0CpRtEhs2FFPiL+91o4aSCsUWMidl5/f+WZJxdNsN1MY3GrxzlLO/vlKBV1cvkARnM y/zI/VqrROqBbmxdn4VKhcZrE7ubw0zlLaL84xVzlno8f8cXmx9J7/kOk3rOQGMoF9xy Vg4Foz3mvS1pGJG/py+qNCyhm1wckIANYfh6JWcQCnsaEQpyemOhk1Qib2yCXY5NUgPz BnCA== X-Gm-Message-State: AD7BkJJv/gIQFIu2VXZGpNx917AuKLB3dgbTcWhSc9aMHm+12IvyTe/Ow5JdSlBa6R9kpQUwm9E1szqQp69JAw== X-Received: by 10.37.231.71 with SMTP id e68mr1907045ybh.57.1459274295380; Tue, 29 Mar 2016 10:58:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 29 Mar 2016 10:57:35 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> From: Eric Rescorla Date: Tue, 29 Mar 2016 10:57:35 -0700 Message-ID: To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=94eb2c0a8c9a01bc8a052f33c6b9 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:04:08 -0000 --94eb2c0a8c9a01bc8a052f33c6b9 Content-Type: text/plain; charset=UTF-8 On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote: > On Tue, Mar 29, 2016 at 6:11 AM, Sean Turner wrote: > > > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT > mode > > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT > > are almost identical, but 0-RTT PSK has better performance properties and > > is simpler to specify and implement. Note that this does not permanently > > preclude supporting DHE-based 0-RTT in a future extension, but it would > > not be in the initial TLS 1.3 RFC. > > This will remove a feature from the QUIC protocol, so I'd be > interested in hearing the QUIC team's opinion. > I agree that this would be valuable. Since DHE-based 0-RTT is already specified in the TLS 1.3 draft, I'm > not sure if "simplier to specify" should be an important factor. > However, "simpler to implement" is an important consideration. I am > curious to know how we concluded that 0-RTT PSK is simpler to > implement. Did anyone implement both 0-RTT modes and can compare the > difficulties? > We have a prototype 0-RTT PSK implementation and have looked at but not yet implemented 0-RTT DHE in NSS. Based on that, my sense is that the cost of doing any 0-RTT is the bulk of the additional effort, but that if you have PSK already, which you probably want for ordinary resumption, then the incremental cost of 0-RTT with PSK is less than with DHE. As for 0-RTT PSK having better performance, that comes at the cost of > a previous full handshake with the server. Yes, this is correct. However, that's the current design of 0-RTT DHE in TLS 1.3 as well. > Also, TLS 1.3 clients that > want to do 0-RTT PSK across an application shutdown will need to deal > with the harder problem of storing PSKs persistently. > Yes, that's the major delta. -Ekr > > Wan-Teh Chang > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a8c9a01bc8a052f33c6b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang <<= a href=3D"mailto:wtc@google.com" target=3D"_blank">wtc@google.com> wrote:
On Tue, Mar= 29, 2016 at 6:11 AM, Sean Turner <sea= n@sn3rd.com> wrote:
>
> There also seems to be (rougher) consensus not= to support 0-RTT via DHE
> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT= mode
> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT=
> are almost identical, but 0-RTT PSK has better performance properties = and
> is simpler to specify and implement. Note that this does not permanent= ly
> preclude supporting DHE-based 0-RTT in a future extension, but it woul= d
> not be in the initial TLS 1.3 RFC.

This will remove a feature from the QUIC protocol, so I'd be
interested in hearing the QUIC team's opinion.
I agree that this would be valuable.

<= br>
Since DHE-based 0-RTT is already sp= ecified in the TLS 1.3 draft, I'm
not sure if "simplier to specify" should be an important factor.<= br> However, "simpler to implement" is an important consideration. I = am
curious to know how we concluded that 0-RTT PSK is simpler to
implement. Did anyone implement both 0-RTT modes and can compare the
difficulties?

We have a prototype 0-RTT= PSK implementation and have looked at but not yet implemented 0-RTT DHE in= NSS. Based on that, my sense is that the cost of doing any 0-RTT is the bu= lk of the additional effort, but that if you have PSK already, which you pr= obably want for ordinary resumption, then the incremental cost of 0-RTT wit= h PSK is less than with DHE.


As for 0-RTT PSK having better performance, that comes at the cost of
a previous full handshake with the server.

= Yes, this is correct. However, that's the current design of 0-RTT DHE i= n TLS 1.3 as well.

=C2=A0
Also, TLS 1.3 clients that
want to do 0-RTT PSK across an application shutdown will need to deal
with the harder problem of storing PSKs persistently.
=
Yes, that's the major delta.

-E= kr
=C2=A0

Wan-Teh Chang

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

--94eb2c0a8c9a01bc8a052f33c6b9-- From nobody Tue Mar 29 12:23:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 141E412E1A3 for ; Tue, 29 Mar 2016 12:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 cZSiJXYuB6xk for ; Tue, 29 Mar 2016 12:23:23 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id C41D512E1A1 for ; Tue, 29 Mar 2016 11:49:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id B1DB04849; Tue, 29 Mar 2016 21:49:17 +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 nnzDpgSQd6j2; Tue, 29 Mar 2016 21:49:17 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 524E5C4; Tue, 29 Mar 2016 21:49:17 +0300 (EEST) Date: Tue, 29 Mar 2016 21:49:16 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160329184916.GA28150@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:23:26 -0000 On Tue, Mar 29, 2016 at 09:29:10PM +1100, Martin Thomson wrote: > https://github.com/tlswg/tls13-spec/pull/437 > > In short, have the client report the time since it received the > configuration. Then have the server reject early data if the time > doesn't match. > > I think that this is a relatively easy change to make. Now, your > exposure to replay is much less. > > It's not ironclad, since the server needs to account for a round trip, > but I think that would could probably get the window down to > single-digit seconds. Is this intended to be somehow compatible with off-band configurations? I recall off-band configurations were stated as reason for having absolute instead of relative time in configurations. -Ilari From nobody Tue Mar 29 12:47:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9343A12DF3C for ; Tue, 29 Mar 2016 12:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 od5GQsIPtzdA for ; Tue, 29 Mar 2016 12:47:13 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 785DD12E3BB for ; Tue, 29 Mar 2016 12:11:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 89D93498B; Tue, 29 Mar 2016 22:11:07 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id ph5yogyR0Wif; Tue, 29 Mar 2016 22:11:07 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4BFBD21C; Tue, 29 Mar 2016 22:11:07 +0300 (EEST) Date: Tue, 29 Mar 2016 22:11:07 +0300 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160329191107.GB28150@LK-Perkele-V2.elisa-laajakaista.fi> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:47:15 -0000 On Tue, Mar 29, 2016 at 09:13:57AM -0700, Bill Cox wrote: > As most people on this list know, stateful PSK 0-RTT can be more secure > than any scheme possible with DHE 0-RTT, stateful or not. I disagree with this. Both PSK and DHE can with server-side state archive best possible security (relative to any possible scheme). Of course, currently DHE mode is cryptographically busted. And I really dislike seeing such modes. But the proposal for 0-RTT contexts would fix that. -Ilari From nobody Tue Mar 29 13:30:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19D8C12DB76 for ; Tue, 29 Mar 2016 13:30:35 -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=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 NXoyVR7jq1Qa for ; Tue, 29 Mar 2016 13:30:33 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA2B912DBED for ; Tue, 29 Mar 2016 12:53:39 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id g127so32592387ywf.2 for ; Tue, 29 Mar 2016 12:53:39 -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:date:message-id:subject:from:to :cc; bh=bsOw6X0tfP4uULinLY2F0dnrtxpJFQq+QiqYU+Y9oW8=; b=FZ/+ynu1CB5tk2I4L+Hu9sGas7AGWCQw8YepcdxnIkdRE4Rf35u5NnZRALhNm2mE8M QJ8eXDl08021I6ruPJ8AXPklp/W7XAq+LWsicBcEIr7lcZ8PtZlKQEMgFltxv3mI6rux kmLUaTy9hUeBohGtIkSkrqRvI/7Hd0enx8VsUUCOl27Ow/TBPGZNAxGNeVrqroQy/wxe RC/sE9ox9QQ5YQ9TppV7H9WmqJTXKa6cl0W7TRU9lJIVrlv9Zrxprq5cBjTK7D4Lmm5g MYlka96KLvZUc9icpptGr+ebyush4yq8nZL/qkpa0Md0IO+zDSU1ulATLhQC84fSMFkw P0Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bsOw6X0tfP4uULinLY2F0dnrtxpJFQq+QiqYU+Y9oW8=; b=dsip/YonApZDb4RAS5nB4djIFznT5OgkedXVsxh10Y9Rt8Jybp2LauoyfvSsMXA8KA kysh9khCxp36EC2ocliWsFXUbC4lOG79cTii9MHNZS0keyRYrvtWqeCwJugt/wGrwmK4 6OBwCyrbuI7K8fAVDBGep7hA3mtYZA0aAwHuO2Sn0sV8C9Q7lSY1POXBsLgKZHWifsLa /8hGOGzPMYN49lc/bWsRKXQvwRjhGrwk0sl2jgk8x7uTHWe/fliClRs3+ZABmirr8w7w z/9bbDxEB4MDQ6Nf+N4MX8R2d+NJg23BkpbynMm6BrF0WFz8/g+hNoUHGCNen7BhDcpX mBRw== X-Gm-Message-State: AD7BkJJTVkG4PsQsrB6mwqr4wIpuYNd0g1AaQgIEpcgD0WUVtlnmaVoyzhmOlkfQu9wZbu4QCb5JUNA8vhDg1A== MIME-Version: 1.0 X-Received: by 10.37.94.138 with SMTP id s132mr2206178ybb.85.1459281218848; Tue, 29 Mar 2016 12:53:38 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Tue, 29 Mar 2016 12:53:38 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2016 12:53:38 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11422e16ad9f50052f3562ea Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:30:35 -0000 --001a11422e16ad9f50052f3562ea Content-Type: text/plain; charset=UTF-8 On Tue, Mar 29, 2016 at 3:29 AM, Martin Thomson wrote: > https://github.com/tlswg/tls13-spec/pull/437 > > In short, have the client report the time since it received the > configuration. Then have the server reject early data if the time > doesn't match. > > I think that this is a relatively easy change to make. Now, your > exposure to replay is much less. > > It's not ironclad, since the server needs to account for a round trip, > but I think that would could probably get the window down to > single-digit seconds. > It's likely I'm misunderstanding, but I'll ask to clear it up. Does this proposal imply that a 0RTT section can only be sent within a very tight time limit of when the server provided a resumption ticket/configuration? If so - is that really useful? over that kind of time length, wouldn't it be especially beneficial to simply keep the original connection open for a bit longer? I thought that an intent of 0RTT is that it can save time even when you're connecting to a server maybe hours (days?) after you originally did. Separately; is there a mechanism to prevent an attacker from changing the elapsed time value? -- Colm --001a11422e16ad9f50052f3562ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 29, 2016 at 3:29 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
https://github.com/tlswg/tls13-spec/pull/437

In short, have the client report the time since it received the
configuration.=C2=A0 Then have the server reject early data if the time
doesn't match.

I think that this is a relatively easy change to make.=C2=A0 Now, your
exposure to replay is much less.

It's not ironclad, since the server needs to account for a round trip,<= br> but I think that would could probably get the window down to
single-digit seconds.


It= 's likely I'm misunderstanding, but I'll ask to clear it up. Do= es this proposal imply that a 0RTT section can only be sent within a very t= ight time limit of when the server provided a resumption ticket/configurati= on? If so - is that really useful? over that kind of time length, wouldn= 9;t it be especially beneficial to simply keep the original connection open= for a bit longer? I thought that an intent of 0RTT is that it can save tim= e even when you're connecting to a server maybe hours (days?) after you= originally did.=C2=A0

Separately; is there a mech= anism to prevent an attacker from changing the elapsed time value?

--
Colm
--001a11422e16ad9f50052f3562ea-- From nobody Tue Mar 29 14:15:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B900F12DA4F for ; Tue, 29 Mar 2016 14:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eng.ucsd.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2BnJ9g3kb2h for ; Tue, 29 Mar 2016 14:15:27 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::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 5EB9512DDE1 for ; Tue, 29 Mar 2016 13:50:48 -0700 (PDT) Received: by mail-pa0-x22e.google.com with SMTP id tt10so22714749pab.3 for ; Tue, 29 Mar 2016 13:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eng.ucsd.edu; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=lB+5JPg2UIOc1jj4s/3opkrHsD1SZyuElMQuBQ2UvgI=; b=BYlh6YEeFoX5S0iDzRZqDDaceUYtR/Aml/T5WGi+izcB6SFOAyo95LnhERZtzCjRN2 WR+WtmLi8uYZeKUKveTkcr8axyxkir/MT/CHhdxEisH3+NjhnLBjVUcoe3gGB7fZNkyj VwOCpsVYvQii8Co5uDYqlmj9ls3S2Ovg6/UMM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=lB+5JPg2UIOc1jj4s/3opkrHsD1SZyuElMQuBQ2UvgI=; b=Ip0QEXjSuvw0StjTwwv+oEiN7Hqo9IsS2YO4hdI6lvLKCzQd69mjLwd8k2MxHq9Uj3 Lx5RIroBUuoqI/pT1/vLZeX0sPm4YQLFE4UJP2vFEkJ6cI2oRQ+MIK9LU1VzTM778yC0 tw3sXNLRjO7FWPwqMe5ZChEYiFcSsNE1IZoW/ERKQW5mmxKapFDOvB9BOkYq6XJHlIsD BWUavTT4+w41ido8qFJKdJ+Xb9LgFX5nmKnM8bIh9KFvzLesDNqxCVDQOJNKwV0bjhyS /yFJUbqMfIxUAXw8ymHbOQ0DSVfOvI0wqwBXOV5YnBBwnwxUMo9a8JdTwGu6MmnlwEZh hbHw== X-Gm-Message-State: AD7BkJJdhyCgCc2qDGzxMCfFKmhPDmDisIWLWPmRYQ9dczVwD7WA37bt3Qdy5qnIKj02nmZu X-Received: by 10.66.237.173 with SMTP id vd13mr6759762pac.24.1459284648133; Tue, 29 Mar 2016 13:50:48 -0700 (PDT) Received: from ?IPv6:2607:f720:f00:4042:e88e:25a6:646e:da52? ([2607:f720:f00:4042:e88e:25a6:646e:da52]) by smtp.gmail.com with ESMTPSA id 19sm408511pfp.66.2016.03.29.13.50.47 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Mar 2016 13:50:47 -0700 (PDT) From: =?utf-8?Q?Bj=C3=B6rn_Tackmann?= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Tue, 29 Mar 2016 13:50:46 -0700 To: tls@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Key separation and privacy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:15:29 -0000 Dear TLS Working Group, this message relates mostly to (real-world) privacy, so I'd be = particularly grateful for comments from people concerned with that. The TRON workshop [1] re-initiated a discussion about the handling of = keys among cryptography researchers involved with TLS. Although there is = no unanimous opinion on this matter, I think it is fair to say that the = majority of cryptographers support the principle of key separation, that = is, using each cryptographic key derived within the protocol (only) for = its specific purpose. (This simplifies the analysis significantly, but = it also helps to avoid unintended interactions between different = protocol parts and to keep things nice and modular.) We are particularly = concerned with the traffic keys used for handshake and for application = data. The current TLS 1.3 draft is somewhat inconsistent here. While the = ordinary handshake messages are encrypted under a handshake traffic key = HTK, "late" handshake messages (NewSessionTicket and post-handshake = client authentication) are intermixed with application data messages and = encrypted under the application traffic key ATK. Encrypting late = handshake messages with HTK instead of ATK would cause the problem that = the receiver must know which key to use for decrypting a received = message; the somewhat most straightforward way would be to make the = messages clearly distinguishable, another way would be to do trial = decryption for each incoming message with ATK and, in case of failure, = decrypt with HTK. This key HTK could be the very same key as the one = used for encrypting the messages during the initial handshake. The plain "record type" field has been retired when the new padding = mechanism was introduced, with the idea of better protecting privacy. So = the main question here is: how important is it to make handshake and = application data messages indistinguishable? And is it realistic? - The late handshake messages are "new ticket," "late client auth," and = "key update." I guess the most sensitive of them is "late client auth?" = Is it important that this be hidden within application data? Are "new = ticket" and "key update" also considered privacy-sensitive? - Beyond the plain record type, the message may also be identifiable by = other traffic characteristics such as length or timing. While the length = can be hidden using padding, this requires co-operation with the = application layer, because TLS can hardly know what the characteristic = traffic pattern of the particular application is. Is this, = realistically, ever going to happen in a way that will significantly = cover the characteristic pattern of the handshake messages? In a nutshell, three possibilities for this are: (a) Do not separate keys, i.e., set HTK =3D ATK. This makes = cryptographic analysis harder and renders the protocol less modular, but = it may have privacy advantages. (b) Separate keys, set HTK !=3D ATK, and resurrect the =E2=80=9Crecord = type=E2=80=9D field to the extent that it allows to differentiate = HTK-encrypted packets from ATK-encrypted packets. This seems the = cryptographically cleanest way but may come with worse privacy = guarantees. (c) Separate keys, set HTK !=3D ATK, leave =E2=80=9Crecord type=E2=80=9D = field disabled, and trial-decrypt. This is messier than both of the = above, but seems a possible compromise between modularity and privacy. What do you think? Thanks & best, Bj=C3=B6rn [1] = http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-= not-tron-workshop-programme -- Bj=C3=B6rn Tackmann Postdoctoral Research Scholar Computer Science & Engineering, UC San Diego From nobody Tue Mar 29 16:22:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C824112DAE9 for ; Tue, 29 Mar 2016 16:22:08 -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 NoIt7XVlT8Sm for ; Tue, 29 Mar 2016 16:22:05 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FFAA12DAE8 for ; Tue, 29 Mar 2016 16:21:48 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g127so38172360ywf.2 for ; Tue, 29 Mar 2016 16:21:48 -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=uD0Nsql0Z2cGUPxFuv9rCDg9TAMC8ZlFO0lmgBrTyiY=; b=qGKMu4U6Z4sZpy5k/2lmFOXGtqGmcdvMMtJ6PSBY0wxAiTvZwuWWjLlVb3pdkyrkOp 3VbEasaTbK3UAQ2o7tPwc0iIkUnP54CRr16fUnhxDvhyDEF58Ku6wMO+EPKqSVr7u5zM b4vohI2kDjFvAELe/wLiG8YOJsy7Lc8WdboTgfXIUpFpUbl4lA9/bqzzD7vLQgmFpStH SatKa7lB/SG7l9rgwh3I2QBUYcCK6x9jaynDMkNzkGp5w6IuzSEWrHonQDKJop4IKuxB rLwVqx0eyG2AfrwPAeQnMFZ6ORkt/RCPJL3H866jc8bRgPe83JWUfiH4r+c95rRyw0xh Z0ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uD0Nsql0Z2cGUPxFuv9rCDg9TAMC8ZlFO0lmgBrTyiY=; b=FEkvS4V+4IIqEoJdhFI9uQRUvfEtrWRVNRQD+iNJTjmp9xu1SoBxYoFdRTNaYEHUCc dGncj51PUO42lNpQsV2bDrVvm0OUMcoG+pNBx6dkgChqPPJkl81Drl5EAPwcL6uau1VB 66CjYmMvyzMM7c7CJMTqpqzubgYjQuKHGleRyUqB0SNab+rfmQpyS5H9h+diIWtnQUs7 rI+dGKXN7LJhdfJXFeH9nEaHLyddUks+BKqRaSWSQMLkiTFX7TpMOzzDMc+snUxOf2bq pv8cPoNztWKrrlHkFqXujFMI2t9aMnRri5QFGM9RoRY7scSR0uj1lcsPJoQ7rBFNO9rp 7Now== X-Gm-Message-State: AD7BkJLRi2IzlBkJonIWe5f5CE5f7od4w5LXOfIcLLuZ+jmQjfI0xIUhURnenc20DaNzC5ky1KxmQo9Ia1s3GQ== X-Received: by 10.129.79.141 with SMTP id d135mr2405776ywb.115.1459293707875; Tue, 29 Mar 2016 16:21:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 29 Mar 2016 16:21:08 -0700 (PDT) In-Reply-To: <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> From: Eric Rescorla Date: Tue, 29 Mar 2016 16:21:08 -0700 Message-ID: To: Dacheng Zhang Content-Type: multipart/alternative; boundary=001a114db176152c1e052f384bed Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:22:09 -0000 --001a114db176152c1e052f384bed Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have taken an initial look at this document, but I find myself confused about the security model. Specifically, you say that you can't use SNI because customers will lie and insert the SNI for service A in the ClientHello when going to service B. However, I don't see how this token stops that, since all it represents is a bare assertion of where you are going that is authenticated with a MAC shared between the client, the ICP, and the ISP. What stops the client from doing the same thing, i.e., injecting the token for service A into a connection destined for service B? B can just ignore the SI token, right? Second if the tokens are client specific, what stops an attacker from copying my token and then replaying it in a separate connection, thus potentially causing the system to charge me or at least to use my rates for the attacker? In short, this document needs a threat model (see RFC 3552) and an analysis of why this solution meets that threat model. Finally, why am I seeing what appears to be a MAC algorithm definition in Section 2.1. Is there a reason you can't just use/cite HMAC? -Ekr On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang wrote: > Hi, > > Actually, we refer to the extension as a 'SNI' extension. In this > extension, SI(service indication) information is provided. In the next > version, we will use 'SI extension' to take place of 'SNI extension'. ^_^ > > Cheers > > Dacheng > > ------------------------------------------------------------------ > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6= =97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52 > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill > =E6=8A=84 =E9=80=81=EF=BC=9Atls =EF=BC=8C=E5=BC=A0=E5=A4=A7= =E6=88=90(=E6=B7=A1=E4=B9=85) > =E4=B8=BB =E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfering service= indication information > > On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: > > > It looks like the abbreviation this draft uses is just "SI". It uses SN= I at > > the top a few times to refer to Server Name Indication (which it typos = as > > "service" name extension). > > > > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett > wrote: > > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: > > > > https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-exten= sion/ > > > > > > You really should not use SNI as your abbreviation, as it will just b= e > > > frequently confused with the server_name extension which is already t= he > > > dominant use of those initials in TLS. > > > You're correct; my mistake. I didn't notice the typo and reading a spec d= raft whilst tired is not always the best of ideas. ;) > > > CCing back to list and thread starter to make sure my correction is OTR f= or the list. > > > Fixing that typo in the draft would help to avoid future misreadings. Sti= cking in a direct reference to RFC6066 on first mention of SNI could add an= other level of clarification, if desired. > > Thanks for quickly correcting me. > > > Dave > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114db176152c1e052f384bed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have taken an initial look at= this document, but I find myself confused about the security
model.

Specifically, you say that you can't use SNI becaus= e customers will lie and insert
the SNI for= service A in the ClientHello when going to service B. However, I don't=
see how this token stops that, since all i= t represents is a bare assertion of where
y= ou are going that is authenticated with a MAC shared between the client, th= e
ICP, and the ISP. What stops the client f= rom doing the same thing, i.e., injecting
t= he token for service A into a connection destined for service B? B can just= ignore
the SI token, right?

Second if the tokens= are client specific, what stops an attacker from copying my
token and then replaying it in a separate connection, thu= s potentially causing
the system to charge = me or at least to use my rates for the attacker?

In short, this document needs a = threat model (see RFC 3552) and an analysis
of why this solution meets that threat model.

Finally, why am I seeing what appe= ars to be a MAC algorithm definition in Section
2.1. Is there a reason you can't just use/cite HMAC?

-Ekr








On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang <dache= ng.zdc@alibaba-inc.com> wrote:
Hi,

<= /div>
Actually, we refer to the extension as a = 9;SNI' extension. In this extension, SI(service indication) information= is provided. In the next version, we will use 'SI extension' to ta= ke place of 'SNI extension'. ^_^
Cheers

=
Dacheng
<= span style=3D"font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14px;color:= rgb(0,0,0)">---------------------------------------------------------------= ---
=E5=8F=91=E4=BB=B6= =E4=BA=BA=EF=BC=9ADave Garrett <davemgarrett@gmail.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF= =BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52=
=E6=94=B6=E4=BB=B6=E4= =BA=BA=EF=BC=9AEric Mill <eric@konklone.com>
=E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls <tls@ietf.org>=EF=BC=8C=E5=BC=A0=E5=A4= =A7=E6=88=90(=E6=B7=A1=E4=B9=85) <dacheng.zdc@alibaba-inc.com>
=
=E4=B8=BB=E3=80=80=E9=A2=98=EF= =BC=9ARe: [TLS] A TLS extension transfering service indication information<= /span>

= On=C2=A0Tuesday,=C2=A0March=C2=A029,=C2=A02016=C2=A001:35:50=C2=A0am= =C2=A0Eric=C2=A0Mill=C2=A0wrote:
>=C2=A0It=C2=A0looks=C2=A0like=C2=A0= the=C2=A0abbreviation=C2=A0this=C2=A0draft=C2=A0uses=C2=A0is=C2=A0just=C2= =A0"SI".=C2=A0It=C2=A0uses=C2=A0SNI=C2=A0at
>=C2=A0the=C2= =A0top=C2=A0a=C2=A0few=C2=A0times=C2=A0to=C2=A0refer=C2=A0to=C2=A0Server=C2= =A0Name=C2=A0Indication=C2=A0(which=C2=A0it=C2=A0typos=C2=A0as
>=C2= =A0"service"=C2=A0name=C2=A0extension).
>=C2=A0
>=C2= =A0On=C2=A0Tue,=C2=A0Mar=C2=A029,=C2=A02016=C2=A0at=C2=A01:13=C2=A0AM,=C2= =A0Dave=C2=A0Garrett=C2=A0<davemgarrett@gmail.com>=C2=A0wrote:
&= gt;=C2=A0>=C2=A0On=C2=A0Monday,=C2=A0March=C2=A028,=C2=A02016=C2=A009:50= :13=C2=A0pm=C2=A0Dacheng=C2=A0Zhang=C2=A0wrote:
>=C2=A0>=C2=A0https://datatracker.ietf.org/doc/draft-zhang-= tls-service-indication-extension/
>=C2=A0>
>=C2=A0>= =C2=A0You=C2=A0really=C2=A0should=C2=A0not=C2=A0use=C2=A0SNI=C2=A0as=C2=A0y= our=C2=A0abbreviation,=C2=A0as=C2=A0it=C2=A0will=C2=A0just=C2=A0be
>= =C2=A0>=C2=A0frequently=C2=A0confused=C2=A0with=C2=A0the=C2=A0server_nam= e=C2=A0extension=C2=A0which=C2=A0is=C2=A0already=C2=A0the
>=C2=A0>= =C2=A0dominant=C2=A0use=C2=A0of=C2=A0those=C2=A0initials=C2=A0in=C2=A0TLS.<= br>
You're=C2=A0correct;=C2=A0my=C2=A0mistake.=C2=A0I= =C2=A0didn't=C2=A0notice=C2=A0the=C2=A0typo=C2=A0and=C2=A0reading=C2=A0= a=C2=A0spec=C2=A0draft=C2=A0whilst=C2=A0tired=C2=A0is=C2=A0not=C2=A0always= =C2=A0the=C2=A0best=C2=A0of=C2=A0ideas.=C2=A0;)

CCing=C2=A0back=C2= =A0to=C2=A0list=C2=A0and=C2=A0thread=C2=A0starter=C2=A0to=C2=A0make=C2=A0su= re=C2=A0my=C2=A0correction=C2=A0is=C2=A0OTR=C2=A0for=C2=A0the=C2=A0list.
Fixing=C2=A0that=C2=A0typo=C2=A0in=C2=A0the=C2=A0draft=C2=A0would=C2= =A0help=C2=A0to=C2=A0avoid=C2=A0future=C2=A0misreadings.=C2=A0Sticking=C2= =A0in=C2=A0a=C2=A0direct=C2=A0reference=C2=A0to=C2=A0RFC6066=C2=A0on=C2=A0f= irst=C2=A0mention=C2=A0of=C2=A0SNI=C2=A0could=C2=A0add=C2=A0another=C2=A0le= vel=C2=A0of=C2=A0clarification,=C2=A0if=C2=A0desired.

Thanks=C2=A0fo= r=C2=A0quickly=C2=A0correcting=C2=A0me.


Dave
=


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


--001a114db176152c1e052f384bed-- From nobody Tue Mar 29 16:37:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7249B12D0E6 for ; Tue, 29 Mar 2016 16:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1I_LhP9QTz2 for ; Tue, 29 Mar 2016 16:37:15 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 13E4B12D0BE for ; Tue, 29 Mar 2016 16:37:15 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id l20so28028038igf.0 for ; Tue, 29 Mar 2016 16:37:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=ieLeDFyfO/0AP11YvVgtq2cBi0Qal1UrC4t9go/ItlM=; b=MTQ4cIvfxCM/bijSxTT3kyi6s8cDucWv33O8l8MLP11L4l/m9cJmTsrE3F1J1QAdxz 13wcKwdiUEhsDPbxhHyx0PitsshxjxZz1di2lTwVehsUPG0m77F6F2sODW26CGPEHBBm K0PeiOia7RzynL50fH1Nmn8zaen94EIk1sUDoU/9efe+wu9Jon24Fksvuglnty+NFwsZ Lr2ngiI3xZC9lImKD0aPWFEgIUrdYBBzb9LaeteCMvsBAn4ivUseuRWi+cCX+uWV/Uq7 mGrJktdyi4b46oeRZ0vOFRWhu8JYrPSW0B5priVOVwFhXVe3AMHMbk1AxCBOMW5M6Dt5 2ajg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=ieLeDFyfO/0AP11YvVgtq2cBi0Qal1UrC4t9go/ItlM=; b=CysCTB1v3BEQT9IxySQLXMhF6f4/f6gbvSF0dyOoFfn8lRXZgVuhw6W2Uf/2eODCDY BnMO5wzQMX78Ulqj0cp3r8i10+b5QvNsUrIH9MSV074Qidfu7fBa9rOStA2VDQsKRx8u DGm80jbF2in7PEWjZSmzxjo2cX6D5xM7ZSYULH8ZEjc7lOAXKCpNFjZ+4bt7gtYRiQ2B nVTZMi3yMBCDrsIWphd45AXg0zWr3XF/Cg7aLFlYCX7ZlYLy9PtfApP1VdMbaLEaHi2A aZsQMCQqSp0bRVzvamJ8His49VupTM0n8eswSW0kpa+4J45MeZ6lPYypNbpFmOvH/1pJ XFNA== X-Gm-Message-State: AD7BkJJK7+/Feekyyq4cxAsu/BoN6UGHHJOfOFhGwDFzXxzVK4g6yA4JOctu1mw/DKZheuE0+N57bclker7lSQ== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr19600225igh.94.1459294634448; Tue, 29 Mar 2016 16:37:14 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 16:37:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 10:37:14 +1100 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:37:17 -0000 On 29 March 2016 at 22:32, Stephen Farrell wrot= e: > In an offlist exchange with Martin, I suggested allowing > finer granularity than 1s, e.g. 1ms. I think that this is reasonable. This might allow for tighter tolerance for drift, which means less replay opportunity. On 30 March 2016 at 04:45, Kyle Nekritz wrote: > I think this will better account for the round trip delay if the elapsed_= time is defined on the client as the time since the request for the session= ticket (in other words, the time since the client hello was sent). Unfortunately, there is no client message that solicits the NewSessionTicket. The message can be sent spontaneously by a server at any time. On 30 March 2016 at 05:49, Ilari Liusvaara wrote= : > Is this intended to be somehow compatible with off-band configurations? If an out of band configuration is used, then we would need a rule for establishing the time that elapsed_time starts from and new rules about tolerances. This isn't going to be compatible straight off. On 30 March 2016 at 06:53, Colm MacC=C3=A1rthaigh wrote= : > It's likely I'm misunderstanding, but I'll ask to clear it up. Does this > proposal imply that a 0RTT section can only be sent within a very tight t= ime > limit of when the server provided a resumption ticket/configuration? No. If we accept Stephen's suggestion and go to milliseconds (I will do that), then the maximum age of a ticket is just over 7 weeks. Much longer than the time we allow a resumption ticket to live. From nobody Tue Mar 29 17:30:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7853E12DBC9 for ; Tue, 29 Mar 2016 17:30:36 -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=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 u9VaxwWGeWcg for ; Tue, 29 Mar 2016 17:30:35 -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 D184612DB99 for ; Tue, 29 Mar 2016 17:30:34 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g127so39616532ywf.2 for ; Tue, 29 Mar 2016 17:30:34 -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:date:message-id:subject:from:to :cc; bh=epmM84T35blbhCxXdpsBN+4mwS1R8+WkNPy5X8ZqH+M=; b=N/IgGnSJwj9j1VaY/LQLbJv22AWaHWX660LY++VIPw6bUEOw6WfQCzmfMg+KcgxRjw uzg7qGEP948YzsSCHvvQM125Qe7ahl141zxGPSxOvrjICitz3RB2oPhKbtwjoljCrxUs UT6gSM8zmCSU1CQGB8U6k1+edAfC57xRPF+T1wAX3pDDGAyiHxTrnIozqdy9H84i3KgV DSjm3WonXVB5o829l5lELZY0KnB5ZD9suiFde7qK/p76Zpmrqu4RspW4+6aibniPV5yC ESj/BPhTYRqvn6HvpU2vB+N8vGMqHqpI4yn3ytLyGij70b2vzBWqQZEPeFU2QS1bJ/WZ UEnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=epmM84T35blbhCxXdpsBN+4mwS1R8+WkNPy5X8ZqH+M=; b=WJ0bxtlo+tbCcXX6QMs7pa0ptjB0yyairnB3hKxFSuqRTU4espnnJOYevr7szfEOrI 3rnJToI7y1WAgbuCydJJTbHPjIWfQaa/6FM+mIPEswqvSJs2fOa6PrMyFvBn3+PxU867 HxroALhxftPIL4fP1/v/0VipPxibreKNVdoAioReIuhav5YLWDegEakjuHEEm6bTXFNa BK5+9EvKerovJ9Vw2qXijqAPs+fznmiSiss5r5UO3CKYPm/W80TSYS4dlZfsGCnJDovT qZR207hJeP0mG+ArBy6G4DynbsoBm4zW1PEWJprDbG0hK4LzdCMU80L1F0/zifWZqX65 pHCw== X-Gm-Message-State: AD7BkJKH/GIswiJtrFVJamt8+PjwdgJmSV8hi/sddGEEbf4mt8hjT6//RsK/98o5yY8lmFsjZUqv/qSzG+Sd9g== MIME-Version: 1.0 X-Received: by 10.13.192.5 with SMTP id b5mr2619604ywd.114.1459297834100; Tue, 29 Mar 2016 17:30:34 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Tue, 29 Mar 2016 17:30:34 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2016 17:30:34 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e3f980620bc052f394118 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 00:30:36 -0000 --001a114e3f980620bc052f394118 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson wrote: > On 30 March 2016 at 06:53, Colm MacC=C3=A1rthaigh wro= te: > > It's likely I'm misunderstanding, but I'll ask to clear it up. Does thi= s > > proposal imply that a 0RTT section can only be sent within a very tight > time > > limit of when the server provided a resumption ticket/configuration? > > No. If we accept Stephen's suggestion and go to milliseconds (I will > do that), then the maximum age of a ticket is just over 7 weeks. Much > longer than the time we allow a resumption ticket to live. > i did mis-understand so; I read your PR as suggesting that the server should impose a small limit on the elapsed time itself. But now I think what you're saying is this; the server should check that the same amount of time (modulo an RTT) has elapsed on both the client and the server. A few other questions; * How is the elapsed time on the wire authenticated? can't an attacker modify it and replay? * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I guess) ? * Clock drift; especially on clients, seems like a real problem here - how tight would realistic tolerances be? - Colm --=20 Colm --001a114e3f980620bc052f394118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 29, 2016 at 4:37 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 30 March 2016 at 06:53, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
> It's likely I'm misunderstanding, but I'll ask to clear it= up. Does this
> proposal imply that a 0RTT section can only be sent within a very tigh= t time
> limit of when the server provided a resumption ticket/configuration?
No.=C2=A0 If we accept Stephen's suggestion and go to millisecon= ds (I will
do that), then the maximum age of a ticket is just over 7 weeks.=C2=A0 Much=
longer than the time we allow a resumption ticket to live.

i did mis-understan= d so; I read your PR as suggesting that the server should impose a small li= mit on the elapsed time itself.

<= div class=3D"gmail_extra">But now I think what you're saying is this; t= he server should check that the same amount of time (modulo an RTT) has ela= psed on both the client and the server. A few other questions;

* How is the elaps= ed time on the wire authenticated? can't an attacker modify it and repl= ay?=C2=A0
* Should the difference really be= 1RTT, or 1/2 RTT (well, really "TT" I guess) ?=C2=A0
* Clock drift; especially on clients, seems like a rea= l problem here - how tight would realistic tolerances be?

-
=C2=A0Colm



--
Colm
--001a114e3f980620bc052f394118-- From nobody Tue Mar 29 18:25:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00412DC00 for ; Tue, 29 Mar 2016 18:25: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, 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 SAoRGWVzkgxm for ; Tue, 29 Mar 2016 18:25:48 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 714D812DBD8 for ; Tue, 29 Mar 2016 18:25:48 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id ma7so50430018igc.0 for ; Tue, 29 Mar 2016 18:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=LR4kryuwIqUCspv+Xu0Hq5vV7JVu5lJXUhjbxDfZ5PA=; b=PoRjGy3VuWZ3L9LPYjUCfdOBoMXSVxCg0rWuoHSl+FFAD4JOC9hEm72SCIoiHByXtJ sa9IV/pK9nY50Bk+/Gwyu/vg9Z2bDEorkDy5f66KnutrEc5E2ge8b1+IzSEktzjPistI poVmXOkgxzgmzB++UBXogvaaC0+Sr7AcZ31ec4/vwO6x/dXIv95ICYGHC8kzNz1+gP5p F6ZAb+Wh6VwPmgkutgWzMnZ/auJ7QSM5dXFZ6l6Y0IIXcYCUNuTlQFqnwAjdazbZ9syX D78Tczlyq415bZnHYdDkcnYZ5aEBGgapBhtqqnBoC7VUSseTlbM3HwgVMP2smkxXxAo7 4G+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=LR4kryuwIqUCspv+Xu0Hq5vV7JVu5lJXUhjbxDfZ5PA=; b=cHOD3IQBBUxNzLifnI8Skf4Oz0nUv328FBw+rcKq04ZOwu5H1BtKsZ1HrAsMnXXJNH EjY0GlLYbRi5S5y92tRaUu5O6pqB/gtuo09O5QEzItZpyioum0gmlS8+miELJNMnllKI 5w34Qos1c0Hm1UoCVRUD/kCW/bZchum2HRSlriW9hGRAR0xJcjUfDrp4fp004vn3Z2PL ya66VzhqEyY0LEa5wiB317FzcN71g6THbwJw6m+5bpNGvTG56bI0KNX5a1eSH7Q+SlQ7 YAJte4RJoVU5xUCvIYXa5kjEdATn92b89hxoXehvNOWCPRQh7OmS4lOFa5+h8owaIlb7 LOxw== X-Gm-Message-State: AD7BkJJGFWjmVxeScNm4A44cUbhk9WlN5W9UXrIOw9vi7T5lE9AuH/Vj3JUEwYGm8mQKBHTcjKXJNXJXo54PWw== MIME-Version: 1.0 X-Received: by 10.50.43.226 with SMTP id z2mr6717856igl.94.1459301147814; Tue, 29 Mar 2016 18:25:47 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 18:25:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 12:25:47 +1100 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:25:50 -0000 On 30 March 2016 at 11:30, Colm MacC=C3=A1rthaigh wrote= : > * How is the elapsed time on the wire authenticated? can't an attacker > modify it and replay? It is authenticated by virtue of being part of the session transcript. It will be authenticated by the Finished message included by the client, by the key derivation, and ultimately by the remainder of the 1RTT handshake. > * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I > guess) ? No. The server records the time that it generates the ticket. Then that ticket travels to the client (1/2 RTT). At that point the counter starts. Then, on resumption, the client stops the clock and sends the message to the server (1/2 RTT). > * Clock drift; especially on clients, seems like a real problem here - ho= w > tight would realistic tolerances be? Clock drift over this time frame is a small problem, but one that can be managed by having a small allowance for drift. In my experience, drift is likely to be small enough that errors in RTT measurement are more likely to dominate [47][48]. What is more likely to be a problem is time corrections during that time (via NTP for instance). In any case, these sorts of errors fail soft. You just lose 0-RTT. [47] I have seen drift in the order of seconds per day, but that is rare. Those users will find lower rates of 0-RTT acceptance, or 0-RTT will only work over shorter periods. That's not great, but we can't always win. Most clock errors are simple "I didn't even setup NTP" sort of problems. [48] Users with high round trip variability will suffer too. That's very common in developing countries, and on wireless networks. From nobody Tue Mar 29 18:29:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BC12DC10 for ; Tue, 29 Mar 2016 18:29: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, 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 47YZh3y5Ey7n for ; Tue, 29 Mar 2016 18:29:18 -0700 (PDT) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 F008712DC0F for ; Tue, 29 Mar 2016 18:29:17 -0700 (PDT) Received: by mail-ig0-x235.google.com with SMTP id ui10so19990492igc.1 for ; Tue, 29 Mar 2016 18:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=a3ouRO3ETmsMTAEK7KreKrlCVQQrPm5Le3Iq84TTyMs=; b=aoheFLeFgJUU8sJIvRvQwAq53wsxc9S2tTFGcAxWvgzXEjMFl72Ym0WrFucA7vNiUJ YoGrIHE/wkTUGVqsjdl9D6FX7wfUKyoVs/Ro6kRe0lOc3tJAvL3p6ETXvuR1+5dDUOaq 0BF0prKN7bI39SGnAUu/tmb/g7ZjzIYBQm6m9KqMGctd9mo9MGoMU3B8ZnISOi3jinGU PdulX+rUYEjjMERdlwmd72qrW0AsKc5Op/r8pHZqFxLtj5Y0tcFt0gm4icGKYrlV4YaU HdWRJkSmJUGMhJS70Oq0Kg7kqxO+KcFmrO+PTBUCONDkjJeyhERzZK0WnOH3vBIjIAhu REVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=a3ouRO3ETmsMTAEK7KreKrlCVQQrPm5Le3Iq84TTyMs=; b=GgbQH46Z2kiMZ16fArG9ekMs9zy2dVCHM2wc6AEzB9q14QZ/Mz4JaSo6N/BV4zVRLj 1Q0BjBYwSGP8lKXc+KpDa9iSnq+yK4wr6XCYSWp2RPhF/wjAmKeicEHfsJ/PidrjFRkg /Qdy0EkztLESwjOyRt4OH0E1hmz4AjGONfqaMl0mZIwm7oPFRw4fOupkfgO83lGW+evp /PmxstqlAY3R1W9yM5fEOQHs0hPrROSUU8AFJo0pNd2QE/hzsDnskX6HJpY/OEC5r92e bWBJ8svdxWgfpKQdlO3Pz7uNb6k2quhzNyYA43sP7lAMaZH94f3T5GZlFbku2OL5djhl 5P+g== X-Gm-Message-State: AD7BkJLUMxk6KDKZHl3uoVxlueLUJZ04OJWxeOe+yvGjAubb7OR+SaUnGbrZGqCfQ0anrEGWua8CahmxboHbVw== MIME-Version: 1.0 X-Received: by 10.50.171.130 with SMTP id au2mr19498780igc.58.1459301357356; Tue, 29 Mar 2016 18:29:17 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 18:29:17 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99564FE17B@PRN-MBX01-4.TheFacebook.com> Date: Wed, 30 Mar 2016 12:29:17 +1100 Message-ID: From: Martin Thomson To: David Benjamin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Tickets and cross protocol attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:29:19 -0000 On 30 March 2016 at 05:00, David Benjamin wrote: > On the server, OpenSSL already includes the version in the SSL_SESSION > structure, and recent enough versions of it will not accept sessions at the > wrong version NSS too. This is the right thing, I think. I have no objection to making this a requirement in the spec. From nobody Tue Mar 29 18:42:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF1912DC0F for ; Tue, 29 Mar 2016 18:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3-6rqw0Q8b9 for ; Tue, 29 Mar 2016 18:42:34 -0700 (PDT) Received: from out4133-2.mail.aliyun.com (out4133-2.mail.aliyun.com [42.120.133.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5013B12D183 for ; Tue, 29 Mar 2016 18:42:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459302147; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=iEHCR7Q0G9MELSjUeRbALYuuLv7ZkOL2JzOOPB09c40=; b=rAY7I31khL4NgJk2j5EvpvCYEaH3v1k/Rkn3vFHZtgxtXTS4HzkLMcDlch04JA9QWVxCAPMV66jkW9zb1/u38l3QVn0radzWK7Wok2yQUziC0/kphra08UkgyGDeansjSPaOf4PjbwhjQXmfhtg/aE2zSQB+x5w7EJicCf5zvSM= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R211e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03306; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_----4ehNqqD_1459302141; Received: from 10.62.54.107(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Mar 2016 09:42:25 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Wed, 30 Mar 2016 09:42:21 +0800 From: "Dacheng Zhang" To: Eric Rescorla Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542175745_4542072" Archived-At: Cc: tls Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:42:38 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3542175745_4542072 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, Ekr: Thanks for reviewing the draft and the comments. Please see my reply inline please. =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla =E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=887:21 =E8=87=B3: dacheng de =E6=8A=84=E9=80=81: Eric Mill , Dave Garrett , tls =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension transfering service indication information I have taken an initial look at this document, but I find myself confused about the security model. Specifically, you say that you can't use SNI because customers will lie and insert the SNI for service A in the ClientHello when going to service B. However, = I don't see how this token stops that, since all it represents is a bare assertion of where you are going that is authenticated with a MAC shared between the client, the ICP, and the ISP. What stops the client from doing the same thing, i.e., injecting the token for service A into a connection destined for service B? B can jus= t ignore the SI token, right? Dacheng=EF=BC=9A This is a very good point. How to secure the APPs on the client device (e.g., How to secure client and prevent the message sent out from an APP provided by ICP A from being intercepted by an APP provided by ICP B installed on the same mobile) is a hot topic. Lots of people are working hard to address this issue. For instance, TEE is an attempt of protecting the security of APPS on a mobile. In a TEE, APPs action are controlled and secure channels are provided to distributed keys. So, in our solution, we did not consider the case where the execution environment of APPs is not secure. We assume if an attacker or a malicious has compromise a mobile, it could cause more serious damages. Second if the tokens are client specific, what stops an attacker from copying my token and then replaying it in a separate connection, thus potentially causing the system to charge me or at least to use my rates for the attacker? Dacheng: You are right. Since we use timestamps, there could a window for a= n attacker to perform attacks by replaying or reusing the token. But we have narrow down the attack window and mitigate the problem. But Thank you for this comment. I got an idea. If the HMAC can cover the whole client hello message, it will be harder for the attacker to reuse the token.Thoughts? In short, this document needs a threat model (see RFC 3552) and an analysis of why this solution meets that threat model. Dacheng: Agree! Will do that in the next version. In addition, we will be very happy if you have no problem with the requirement. We found this issue when we tried to widely use TLS to secure the communications between our APPs and our services. If there could be any better idea or solution, we will be very happy to support it. Finally, why am I seeing what appears to be a MAC algorithm definition in Section 2.1. Is there a reason you can't just use/cite HMAC? Dacheng: I reuse this content from my previous drafts. If people don=E2=80=99t li= ke it, we could remove it. ^_^ Thanks a lot for your review, and look forward to further discussions on this topic. ^_^ Cheers Dacheng -Ekr On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang wrote: > Hi, >=20 > Actually, we refer to the extension as a 'SNI' extension. In this extensi= on, > SI(service indication) information is provided. In the next version, we w= ill > use 'SI extension' to take place of 'SNI extension'. ^_^ >=20 > Cheers >=20 > Dacheng >> ------------------------------------------------------------------ >> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52 >> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill >> =E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls =EF=BC=8C=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1=E4=B9=85) >> =E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfering service indication inf= ormation >>=20 >> On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: >>> > It looks like the abbreviation this draft uses is just "SI". It uses = SNI >>> at >>> > the top a few times to refer to Server Name Indication (which it typo= s as >>> > "service" name extension). >>> >=20 >>> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett >>> wrote: >>>> > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: >>>> > >=20 >>>>=20 https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extensi= on/ >>>> > > >>>> > > You really should not use SNI as your abbreviation, as it will jus= t be >>>> > > frequently confused with the server_name extension which is alread= y the >>>> > > dominant use of those initials in TLS. >>=20 >> You're correct; my mistake. I didn't notice the typo and reading a spec = draft >> whilst tired is not always the best of ideas. ;) >>=20 >> CCing back to list and thread starter to make sure my correction is OTR = for >> the list. >>=20 >> Fixing that typo in the draft would help to avoid future misreadings. >> Sticking in a direct reference to RFC6066 on first mention of SNI could = add >> another level of clarification, if desired. >>=20 >> Thanks for quickly correcting me. >>=20 >>=20 >> Dave >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --B_3542175745_4542072 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi, Ekr:
=
Thanks for reviewing the draft and the comments. Please se= e my reply inline please.

=E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla <ekr@r= tfm.com>
=E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C= =8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=887:21
=E8=87=B3: d= acheng de <dacheng.zdc@aliba= ba-inc.com>
=E6=8A=84=E9=80=81: Eric Mi= ll <eric@konklone.com>, Dave Ga= rrett <davemgarrett@gmail.com= >, tls <tls@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension t= ransfering service indication information

I have taken an initial look at this document,= but I find myself confused about the security
model.

Spe= cifically, you say that you can't use SNI because customers will lie and ins= ert
the SNI for service A in the ClientHello w= hen going to service B. However, I don't
see h= ow this token stops that, since all it represents is a bare assertion of whe= re
you are going that is authenticated with a = MAC shared between the client, the
ICP, and th= e ISP. What stops the client from doing the same thing, i.e., injecting
the token for service A into a connection destined= for service B? B can just ignore
the SI token= , right?

Dacheng=EF=BC=9A This is a very good point. How to secu= re the APPs on the client device (e.g., How to secure client and prevent the= message sent out from an APP provided by ICP A from being intercepted by an= APP provided by ICP B installed on the same mobile)= &nbs= p; is a hot topic. Lots of people are working hard to address this issue. Fo= r instance, TEE is an attempt of protecting the security of APPS on a mobile= . In a TEE, APPs action are controlled and secure channels are provided to d= istributed keys. So, in our solution, we did not consider the case where the= execution environment of APPs is not secure. We assume if an attacker or a = malicious has compromise a mobile, it could cause more serious damages.

=

Second if the to= kens are client specific, what stops an attacker from copying my
token and then replaying it in a separate connection, thu= s potentially causing
the system to charge me = or at least to use my rates for the attacker?

=
Dacheng: You are right. Since we use timestamps, there could = a window for an attacker to perform attacks by replaying or reusing the toke= n. But we have narrow down the attack window and mitigate the problem. But T= hank you for this comment. I got an idea. If the HMAC can cover the whole cl= ient hello message, it will be harder for the attacker to reuse the token.Th= oughts?

In short, this documen= t needs a threat model (see RFC 3552) and an analysis
of why this solution meets that threat model.

Dacheng: Agree! Will do that in the next version. In addition, we will be = very happy if you have no problem with the requirement. We found this issue = when we tried to widely use TLS to secure the communications between our APP= s and our services. If there could be any better idea or solution, we will b= e very happy to support it.
<= div dir=3D"ltr">

Fi= nally, why am I seeing what appears to be a MAC algorithm definition in Sect= ion
2.1. Is there a reason you can't just use/= cite HMAC?

Dacheng: I reuse this content from my pre= vious drafts. If people don’t like it, we could remove it. ^_^

=
Thanks a lot for your review, and look forward to further dis= cussions on this topic. ^= _^

Cheers

Dacheng

-Ekr

=






On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang &= lt;dacheng.zdc@= alibaba-inc.com> wrote:
Hi,

Actually, we refer to the extension as a 'SNI' extension. In this= extension, SI(service indication) information is provided. In the next vers= ion, we will use 'SI extension' to take place of 'SNI extension'. ^_^
<= div style=3D"clear:both">
Cheers

Dacheng
-------------------------------------------= -----------------------
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett <davemgarrett@gmail.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) = 14:52
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AE= ric Mill <eric@konklon= e.com>
=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension = transfering service indication information

On Tuesday, = March 29, 2016 01:35:50 am Eric Mill wrot= e:
> It looks like the abbreviation this=  draft uses is just "SI". It uses SN= I at
> the top a few times to = refer to Server Name Indication (which it = ;typos as
> "service" name extension).
>&nbs= p;
> On Tue, Mar 29, 2016 at 1:13&n= bsp;AM, Dave Garrett <davemgarrett@gmail.com> wrote:
> > On Monday, March 28, 2016 09= :50:13 pm Dacheng Zhang wrote:
> > https://datatracker.ietf.org/doc/draft-zhang-tls-= service-indication-extension/
> >
> > Y= ou really should not use SNI as your = ;abbreviation, as it will just be
> >=  frequently confused with the server_name exte= nsion which is already the
> > domina= nt use of those initials in TLS.

You're correct; my mistake. I didn't no= tice the typo and reading a spec draft&nb= sp;whilst tired is not always the best of=  ideas. ;)

CCing back to list and = thread starter to make sure my correction = ;is OTR for the list.

Fixing that typo&= nbsp;in the draft would help to avoid fut= ure misreadings. Sticking in a direct referenc= e to RFC6066 on first mention of SNI = ;could add another level of clarification, if&= nbsp;desired.

Thanks for quickly correcting me.

Dave


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


--B_3542175745_4542072-- From nobody Tue Mar 29 18:46:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E691712DC1D for ; Tue, 29 Mar 2016 18:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWTtO6LV-d6w for ; Tue, 29 Mar 2016 18:46:01 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801E812D183 for ; Tue, 29 Mar 2016 18:46:01 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u2U1haAF028804; Tue, 29 Mar 2016 18:45:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=4S2AYWmnyzymM5Pq75cw11J6FZloMCNB+p8pYk0HyE8=; b=cRQR0QMSbZYoMUyL7escarvyBlx5t2WbaiJn1D0HkMyleWbVe/JEsis/HcV6lRQQ9WHc h1i+UGf+7lPOEqHN4plZu5C8S0wBMcx4UmYgePcShlXIylF9NFCFnMq+Taailf6BAdPz CaOn/es8YEnHRMbUr/wpIZ2kTVfDun16/Y0= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 22037qrgah-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 29 Mar 2016 18:45:53 -0700 Received: from PRN-CHUB20.TheFacebook.com (192.168.16.74) by PRN-CHUB11.TheFacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 29 Mar 2016 18:45:52 -0700 Received: from PRN-MBX02-1.TheFacebook.com ([169.254.2.203]) by PRN-CHUB20.TheFacebook.com ([fe80::3c2d:726b:17c6:f21c%13]) with mapi id 14.03.0248.002; Tue, 29 Mar 2016 18:45:51 -0700 From: Kyle Nekritz To: Martin Thomson , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= Thread-Topic: [TLS] Narrowing the replay window Thread-Index: AQHRiaXeceDcrO60S02txmAC1DtII59xS2wAgAA+eQD//6BlcA== Date: Wed, 30 Mar 2016 01:45:50 +0000 Message-ID: <8A79BFEDF6986C46996566F91BB63C860D66F35D@PRN-MBX02-1.TheFacebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-29_09:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:46:04 -0000 PiBVbmZvcnR1bmF0ZWx5LCB0aGVyZSBpcyBubyBjbGllbnQgbWVzc2FnZSB0aGF0IHNvbGljaXRz IHRoZSBOZXdTZXNzaW9uVGlja2V0LiAgVGhlIG1lc3NhZ2UgY2FuIGJlIHNlbnQgc3BvbnRhbmVv dXNseSBieSBhIHNlcnZlciBhdCBhbnkgdGltZS4NCg0KVGhlIHRpbWUgc2luY2UgdGhlIGNsaWVu dCBoZWxsbyB3YXMgc2VudC9yZWNlaXZlZCBjYW4gc3RpbGwgYmUgdXNlZCBpZiBpdCBpcyBzdG9y ZWQgYWZ0ZXIgb3BlbmluZyB0aGUgY29ubmVjdGlvbi4NCg0KSXQncyBhbHNvIGltcG9ydGFudCBl eGFjdGx5IHdoZXJlIGFuZCB3aGVuIHRoZSBzZXJ2ZXIgY2hlY2tzIHRoZSB0aW1lc3RhbXAuIElm IHRoZSB0aW1lc3RhbXAgaXMgc29sZWx5IGNoZWNrZWQgdXBvbiByZWNlaXB0IG9mIHRoZSBjbGll bnQgaGVsbG8sIGFuIGF0dGFja2VyIGNhbiBzbG93bHkgdHJpY2tsZSByZXBsYXllZCAwLVJUVCBk YXRhIHRvIHRoZSBzZXJ2ZXIsIHdoaWNoIHNvbWV3aGF0IGRlZmVhdHMgdGhlIHBvaW50IG9mIGEg dmVyeSBuYXJyb3cgcmVwbGF5IHdpbmRvdyAod2l0aCBhIDEgc2Vjb25kIHdpbmRvdywgdGhlIGNv bm5lY3Rpb24gbXVzdCBiZSBvcGVuZWQgd2l0aCAxIHNlY29uZCwgYnV0IHRoZSBhcHBsaWNhdGlv biBkYXRhIGNvdWxkIGFjdHVhbGx5IGdldCBkZWxpdmVyZWQgbWludXRlcyBsYXRlcikuDQoNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IFR1ZXNkYXksIE1h cmNoIDI5LCAyMDE2IDc6MzcgUE0NClRvOiBDb2xtIE1hY0PDoXJ0aGFpZ2ggPGNvbG1AYWxsY29z dHMubmV0Pg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIE5hcnJvd2luZyB0 aGUgcmVwbGF5IHdpbmRvdw0KDQpPbiAyOSBNYXJjaCAyMDE2IGF0IDIyOjMyLCBTdGVwaGVuIEZh cnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KPiBJbiBhbiBvZmZsaXN0 IGV4Y2hhbmdlIHdpdGggTWFydGluLCBJIHN1Z2dlc3RlZCBhbGxvd2luZyBmaW5lciANCj4gZ3Jh bnVsYXJpdHkgdGhhbiAxcywgZS5nLiAxbXMuDQoNCkkgdGhpbmsgdGhhdCB0aGlzIGlzIHJlYXNv bmFibGUuICBUaGlzIG1pZ2h0IGFsbG93IGZvciB0aWdodGVyIHRvbGVyYW5jZSBmb3IgZHJpZnQs IHdoaWNoIG1lYW5zIGxlc3MgcmVwbGF5IG9wcG9ydHVuaXR5Lg0KDQoNCk9uIDMwIE1hcmNoIDIw MTYgYXQgMDQ6NDUsIEt5bGUgTmVrcml0eiA8a25la3JpdHpAZmIuY29tPiB3cm90ZToNCj4gSSB0 aGluayB0aGlzIHdpbGwgYmV0dGVyIGFjY291bnQgZm9yIHRoZSByb3VuZCB0cmlwIGRlbGF5IGlm IHRoZSBlbGFwc2VkX3RpbWUgaXMgZGVmaW5lZCBvbiB0aGUgY2xpZW50IGFzIHRoZSB0aW1lIHNp bmNlIHRoZSByZXF1ZXN0IGZvciB0aGUgc2Vzc2lvbiB0aWNrZXQgKGluIG90aGVyIHdvcmRzLCB0 aGUgdGltZSBzaW5jZSB0aGUgY2xpZW50IGhlbGxvIHdhcyBzZW50KS4NCg0KVW5mb3J0dW5hdGVs eSwgdGhlcmUgaXMgbm8gY2xpZW50IG1lc3NhZ2UgdGhhdCBzb2xpY2l0cyB0aGUgTmV3U2Vzc2lv blRpY2tldC4gIFRoZSBtZXNzYWdlIGNhbiBiZSBzZW50IHNwb250YW5lb3VzbHkgYnkgYSBzZXJ2 ZXIgYXQgYW55IHRpbWUuDQoNCg0KT24gMzAgTWFyY2ggMjAxNiBhdCAwNTo0OSwgSWxhcmkgTGl1 c3ZhYXJhIDxpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20+IHdyb3RlOg0KPiBJcyB0aGlzIGludGVu ZGVkIHRvIGJlIHNvbWVob3cgY29tcGF0aWJsZSB3aXRoIG9mZi1iYW5kIGNvbmZpZ3VyYXRpb25z Pw0KDQpJZiBhbiBvdXQgb2YgYmFuZCBjb25maWd1cmF0aW9uIGlzIHVzZWQsIHRoZW4gd2Ugd291 bGQgbmVlZCBhIHJ1bGUgZm9yIGVzdGFibGlzaGluZyB0aGUgdGltZSB0aGF0IGVsYXBzZWRfdGlt ZSBzdGFydHMgZnJvbSBhbmQgbmV3IHJ1bGVzIGFib3V0IHRvbGVyYW5jZXMuICBUaGlzIGlzbid0 IGdvaW5nIHRvIGJlIGNvbXBhdGlibGUgc3RyYWlnaHQgb2ZmLg0KDQoNCk9uIDMwIE1hcmNoIDIw MTYgYXQgMDY6NTMsIENvbG0gTWFjQ8OhcnRoYWlnaCA8Y29sbUBhbGxjb3N0cy5uZXQ+IHdyb3Rl Og0KPiBJdCdzIGxpa2VseSBJJ20gbWlzdW5kZXJzdGFuZGluZywgYnV0IEknbGwgYXNrIHRvIGNs ZWFyIGl0IHVwLiBEb2VzIA0KPiB0aGlzIHByb3Bvc2FsIGltcGx5IHRoYXQgYSAwUlRUIHNlY3Rp b24gY2FuIG9ubHkgYmUgc2VudCB3aXRoaW4gYSB2ZXJ5IA0KPiB0aWdodCB0aW1lIGxpbWl0IG9m IHdoZW4gdGhlIHNlcnZlciBwcm92aWRlZCBhIHJlc3VtcHRpb24gdGlja2V0L2NvbmZpZ3VyYXRp b24/DQoNCk5vLiAgSWYgd2UgYWNjZXB0IFN0ZXBoZW4ncyBzdWdnZXN0aW9uIGFuZCBnbyB0byBt aWxsaXNlY29uZHMgKEkgd2lsbCBkbyB0aGF0KSwgdGhlbiB0aGUgbWF4aW11bSBhZ2Ugb2YgYSB0 aWNrZXQgaXMganVzdCBvdmVyIDcgd2Vla3MuICBNdWNoIGxvbmdlciB0aGFuIHRoZSB0aW1lIHdl IGFsbG93IGEgcmVzdW1wdGlvbiB0aWNrZXQgdG8gbGl2ZS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRm Lm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb190bHMmZD1Dd0lHYVEmYz01VkQwUlR0TmxU aDN5Y2Q0MWIzTVV3JnI9bDJqNEJqa08wTGMzdTRDSDJ6N2pQdyZtPUk5djlFV2lKT0ZnVF9hdHNi c1BhX3BzaWJ4dVc2R2RzTFZFak4xTUx2Zlkmcz02bFZhQkFUeUVvY2hKcE5TZlUtb0JtUEtOU2ls N010SWtsS0ZiS3FKZk04JmU9IA0K From nobody Tue Mar 29 18:48:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F1112DB5F for ; Tue, 29 Mar 2016 18:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYDBNpryOozO for ; Tue, 29 Mar 2016 18:48:24 -0700 (PDT) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001: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 01D6912D183 for ; Tue, 29 Mar 2016 18:48:24 -0700 (PDT) Received: by mail-ig0-x22b.google.com with SMTP id ma7so50786692igc.0 for ; Tue, 29 Mar 2016 18:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=6MWsj5XbfqUH/nEtf2CqInNJyoWiDpunRL6l9tshZGY=; b=OI9WJulpAWFGjWTV0RQw4FGsZM2LIXWAqwVi8+pmgeZZO8Bhx/2eSGxQh94Ca44BQR wnxzVaFdftVNcdQvN1cwpUtfj8I/rtl+owGCmb1RRobknWYvJ2T9oKslowKnM9KLsCdb qj1d4J9MJUXQX5spfIMRVsZg9tuo6fzqJdzQ///lixXGAnFlSOqJ4qNV0vOnVmFw4M/V M1QX8wKyBd2RhBZBecu4zMishtSvwXdRE4pAIQOAOza74v6mpPzi3cPxDXJStAXVm1xB /aHl0mR+IwW+kc4dpT1i+KNVo6U6ZcNt/MRY+9Mu7ouhvr1VxjHBcp9u7uIfKNWmOo7/ uKoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=6MWsj5XbfqUH/nEtf2CqInNJyoWiDpunRL6l9tshZGY=; b=EWWV7toU5bQXG+nxAm8W5Q76dxI+eDCROnqvsxUx2HbyQU9Y8RkcjEkoicRo7uTocR Al7dZnTK8Hpf2rS1KvvTk9/Tg+eFAf4Tst9W8rylrCJQKXSwGlkafoYcO9SKJWa9MbYT cry5FF19sHpjN/PBuj/uy+byTDcWfh+l1I4g6y9gDc5BbYSKN51ODINPN4JRt0sJEz/8 oQyBregmlteqOpiwz3QVJ8F/0G9YxgRbgJppMsyfcbc7rcHBG/1tIPGq6sSAw0+3CuwT 4YZSpjtxXz77/DuLD15ha4Odh61LokmHJuTswK3dfmWz0pviwW5sGt8HL3R+VjmojGdW 5FUg== X-Gm-Message-State: AD7BkJLxt3+77s37NV9/PyCUle3zAnmzWjahqk9yQrf7WYY5BUbRlGmzKg9BQ1NpdL+F8s8yPh4uLAkpDrUnug== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr20111719igh.94.1459302503406; Tue, 29 Mar 2016 18:48:23 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 18:48:23 -0700 (PDT) In-Reply-To: <8A79BFEDF6986C46996566F91BB63C860D66F35D@PRN-MBX02-1.TheFacebook.com> References: <8A79BFEDF6986C46996566F91BB63C860D66F35D@PRN-MBX02-1.TheFacebook.com> Date: Wed, 30 Mar 2016 12:48:23 +1100 Message-ID: From: Martin Thomson To: Kyle Nekritz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:48:25 -0000 On 30 March 2016 at 12:45, Kyle Nekritz wrote: > The time since the client hello was sent/received can still be used if it= is stored after opening the connection. Only if we introduce an inconsistency by asking for different handling in different circumstances. I agree that in many cases, NewSessionTicket is generated in response to something in the client's first flight, but that's not a guarantee. > It's also important exactly where and when the server checks the timestam= p. If the timestamp is solely checked upon receipt of the client hello, an = attacker can slowly trickle replayed 0-RTT data to the server, which somewh= at defeats the point of a very narrow replay window (with a 1 second window= , the connection must be opened with 1 second, but the application data cou= ld actually get delivered minutes later). If you want to handle the pathological cases, feel free to propose mitigati= on. From nobody Tue Mar 29 18:49:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6FE12DB5F for ; Tue, 29 Mar 2016 18:49:30 -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=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 os8LfRuIc9PC for ; Tue, 29 Mar 2016 18:49:29 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4636C12D183 for ; Tue, 29 Mar 2016 18:49:29 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g3so41443075ywa.3 for ; Tue, 29 Mar 2016 18:49:29 -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:date:message-id:subject:from:to :cc; bh=ZIQS2TWXowCnGPgQhq2Xs/B2T0kKVSYGoS57cDUEAf0=; b=WGLINGoT19V0zNCx+Vh9s1mhhp+HW1mFtfDheMi1wmo8OZkHiMvrNKx8dbm3dn4ljo /G5ZDzA1MOCB/QwHSuRR47/wsdzSS9X2JA7lnR/mbsmarSX1qsKcbZNNIjmBOPHDMHbz XKktjSBCrzmOFLzm0L306NJWuoFwZpNw9Pgqy8SoA1Zz0oEgSXaY6S9VIfEx/IFVuarO IcCHlWTFjxZI5Nqx3uiilJkXWyr+BxI7gpAbaU46NRD0ipHeXBCBMwlVaZu7zH7Y09vq gDnTVV2xKoRArdlI64obVX2FAZCHiHGMxlpbSbWACn+1/TgcQ2Tf4DKdTorQEtuNfQzo MH0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=ZIQS2TWXowCnGPgQhq2Xs/B2T0kKVSYGoS57cDUEAf0=; b=OmZ/wJMkvthYBg+ldDZ8F8pen/X5wzb89vQ8dll5KkQR9TL35OnuweHnbLj5PkP1HL 1hEwNnqOvlP6jAxluwM90+MLrUhB+yhkwjGhecPpHdCj5DCt/Q3iMii/apWd+bSJQtYV 32tVBsHVb3uGdE5JuO/gpnNPs//7+ctkMjxy+7I+/Xki1APOBMYGVuIcPYX2qfUPsb6B NKPCosSs/emikQ2s+VjDPDEXh5Ab9qLYhdiR6RFO7dhFv3MXxencF9YijehFcxR/OqS9 cBTRC61GXsPmdVl8PPGVQeDn9dIXC73q5iqXQXR5Wx3iPdWYNsaxZhp5ZGKlpPmnqwW7 BZLQ== X-Gm-Message-State: AD7BkJK/lxVrmykxjxewczEycq67z2O0h3Ty+bY+6MShS5Lq1oQ13SD/Y/QcmcqeOqdfVw83ruHvfVVgXwTYRQ== MIME-Version: 1.0 X-Received: by 10.37.78.193 with SMTP id c184mr2842849ybb.155.1459302568473; Tue, 29 Mar 2016 18:49:28 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Tue, 29 Mar 2016 18:49:28 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2016 18:49:28 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11467ba63770f8052f3a5b64 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:49:31 -0000 --001a11467ba63770f8052f3a5b64 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 6:25 PM, Martin Thomson wrote: > On 30 March 2016 at 11:30, Colm MacC=C3=A1rthaigh wro= te: > > * How is the elapsed time on the wire authenticated? can't an attacker > > modify it and replay? > > It is authenticated by virtue of being part of the session transcript. > It will be authenticated by the Finished message included by the > client, by the key derivation, and ultimately by the remainder of the > 1RTT handshake. > But isn't that too late? If you have to wait for the client finished message before you can even decrypt the 0RTT section; what's the benefit? it's not "0RTT" any more. > > > * Should the difference really be 1RTT, or 1/2 RTT (well, really "TT" I > > guess) ? > > No. The server records the time that it generates the ticket. Then > that ticket travels to the client (1/2 RTT). At that point the > counter starts. Then, on resumption, the client stops the clock and > sends the message to the server (1/2 RTT). > Makes sense! --=20 Colm --001a11467ba63770f8052f3a5b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 29, 2016 at 6:25 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 30 March 2016 at 11:30, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
> * How is the elapsed time on the wire authenticated? can't an atta= cker
> modify it and replay?

It is authenticated by virtue of being part of the session transcrip= t.
It will be authenticated by the Finished message included by the
client, by the key derivation, and ultimately by the remainder of the
1RTT handshake.

But isn't that too = late? If you have to wait for the client finished message before you can ev= en decrypt the 0RTT section; what's the benefit? it's not "0RT= T" any more.=C2=A0

> * Should the difference really be 1RTT, or 1/2 RTT (well, really "= ;TT" I
> guess) ?

No.=C2=A0 The server records the time that it generates the ticket.= =C2=A0 Then
that ticket travels to the client (1/2 RTT).=C2=A0 At that point the
counter starts.=C2=A0 Then, on resumption, the client stops the clock and sends the message to the server (1/2 RTT).

<= div>Makes sense!


--
Colm
--001a11467ba63770f8052f3a5b64-- From nobody Tue Mar 29 18:52:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09E2412DC12 for ; Tue, 29 Mar 2016 18:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVRWqO66K7HJ for ; Tue, 29 Mar 2016 18:52:24 -0700 (PDT) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001: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 0AB0212D183 for ; Tue, 29 Mar 2016 18:52:24 -0700 (PDT) Received: by mail-ig0-x233.google.com with SMTP id sy18so19137024igc.1 for ; Tue, 29 Mar 2016 18:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=/Gr7/r4wnWkOVXadmpoc5KAWlM/D7+I7oK+1+XWtJPo=; b=Ptv2MIB7IZEw0eckkcZk1ZLqzgi1WJsr0DtL64DpkuYxj2cNeUW7XS7reKNfbKFUmU Y4KeNk3mgW2x+3gaySfvB1+WzXIPsJFtzAXR04sf/HZNUUp262Dz5/+bfJot1SkeT9s4 PK3JccKAv5cflPDDDK+S3ahJG48NeR++lLvexL88oRXFhQOLHOZOtush47ej9OSOw6BX dRW8Vx3LWHr5xmxib8p7WRQOUKnrmQSLkLeqwjT8wlnFEUEKKTaACse3xBZyMrYtUWu2 rRkb2P7GAN3xVMvPeq9+lA+c7YaZHHT9FZeiA4wt+/NsQbIbSQifY7rm64CBj4T2oDrw 1r6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=/Gr7/r4wnWkOVXadmpoc5KAWlM/D7+I7oK+1+XWtJPo=; b=B2bleGUeqfssVeSg1VOIwGZpAfag+0tUgIc8DgD8JE1EF/XanSwwlJRUydg4RBKB6f b1xRX4+q5niCDVGnsVjWY/SWdVXlL2Btf9z2SZ2g8z3yizWgna04Cbrot9TSApXjkANv Pc1cPTjnYl5M7Wm80afbb3SJTrJPEK8Msbc4yyet6Cqnx46HiPrpnJcl/LRghsi6qI+h K52J3lAxBH+93QTl7gkGO7TLRNmtHxXiiHBlN3qj5eDfTJxSajqERRJE71tn7B7lVta7 KR9GyxMIthSZQorHaaOK8XS88uh1mkGiyFZnBA5bPHrR54QeecDUPbeoRf9fs6yuoZhv 9Q1w== X-Gm-Message-State: AD7BkJIz1cCV9jtO6PuYJwFXR3Jo67sRJfT2o2a6WrhGH/Qt7Js+AE2NQdHoqTgSX4L1x1mosPOff+OxxOkw/g== MIME-Version: 1.0 X-Received: by 10.50.43.226 with SMTP id z2mr6826162igl.94.1459302743481; Tue, 29 Mar 2016 18:52:23 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 18:52:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 12:52:23 +1100 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:52:26 -0000 On 30 March 2016 at 12:49, Colm MacC=C3=A1rthaigh wrote= : > But isn't that too late? If you have to wait for the client finished mess= age > before you can even decrypt the 0RTT section; what's the benefit? it's no= t > "0RTT" any more. There is a Finished message in the client's first flight. It's before the early data. https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 From nobody Tue Mar 29 18:53:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC912DC33 for ; Tue, 29 Mar 2016 18:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 WYDaXk_7hK9M for ; Tue, 29 Mar 2016 18:53:17 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::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 AE97F12D183 for ; Tue, 29 Mar 2016 18:53:17 -0700 (PDT) Received: by mail-qg0-x22e.google.com with SMTP id n34so19691620qge.1 for ; Tue, 29 Mar 2016 18:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=GNxu3t9WN1q91CIpwsRxPpPk7zVMQt5bDVIGeZIHnjo=; b=JJefd1ch74TRnkfcssW/8+NYOEyAz82hlaN/Cmyc9d7fTHVLqkUA3IlqVwjiU9phus 9BgPvPS6sSFqRFI61rflgJpRf6PYzLuAw8cBlxeMMLlaD9sAJ4lxR+Lulfe97hVb/ZXf HQLsgVxPyz+cv+nCzxc2CUMVkethB0uFv5obM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=GNxu3t9WN1q91CIpwsRxPpPk7zVMQt5bDVIGeZIHnjo=; b=MlDaiBSUseqs23ca0ELYrBBc0GRYNGdeIh5etcWaW21/Rzl0C97AN5WXhDElmc2aqi EFmpwQT23mGt8dA2rlUaPykKV+KLmifP3ijuP+jFv1/TPFs481dg2ZMvR1CEW6nvav/e QsDjoEzxtxX8SFt4cOVvTMdTkw+2fqXkU7mq9aELmBrQuXhNjvv657mB1jiW59F7fGaR HyFyn4JPstvaedV8MXZjM4StrBsFA8H1I0pRnpCFVqgFNFPuvb/TsNZTiSOa4oE0P6Mm 6g/XUaykJu4rCj+DN9eKDpiFxjdokU8du1PwfxHCjdj+k65dsbVWHBPBETv73sP3lUR7 xsOQ== X-Gm-Message-State: AD7BkJLq+SF6o8sND36VGrj4QcIvl1zwctckqmXdz/Gzd84PBjKQDVvyuDyVVjdsHW6cFQ== X-Received: by 10.141.1.87 with SMTP id c84mr7129539qhd.1.1459302796734; Tue, 29 Mar 2016 18:53:16 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id v65sm765162qhc.6.2016.03.29.18.53.15 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 29 Mar 2016 18:53:16 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Date: Tue, 29 Mar 2016 21:53:13 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:53:19 -0000 Hi! In Yokohama, we discussed changing the IANA registry assignment rules = for cipher suites to allow anyone with a stable, publicly available, = peer reviewed reference document to request and get a code point and to = add an =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This = change is motivated by the large # of requests received for code points = [0], the need to alter the incorrect perception that getting a code = point somehow legitimizes the suite/algorithm, and to help implementers = out. We need to determine whether we have consensus on this plan, which = follows: 1. The IANA registry rules for the TLS cipher suite registry [1] will be = changed to specification required. 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with = two values: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D. Y and N have = the following meaning: Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus = on and are reasonably expected to be supported by widely used implementations such as open-source libraries. The IETF takes no position on the cipher suites marked with an =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but = can) mean that the ciphers are not cryptographically sound (i.e., are bad). Cipher suites can be recategorized from N to Y (e.g., Curve448) and vice versa. 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to = those who don=E2=80=99t read the IANA considerations section of the RFC. Please indicate whether or not you could support this plan. Thanks, J&S [0] In the last year, the chairs have received requests for: PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt JPAKE: not sure they got around to publishing a draft. [1] = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 From nobody Tue Mar 29 20:18:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E57012DA7C for ; Tue, 29 Mar 2016 20:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 iT32YXyY_YZM for ; Tue, 29 Mar 2016 20:18:54 -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 A426912DC53 for ; Tue, 29 Mar 2016 20:18:53 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id h129so43299734ywb.1 for ; Tue, 29 Mar 2016 20:18:53 -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:date:message-id:subject:from:to :cc; bh=70okDRnrUemYOqNECOCGsDvFHrJp80FGjIuuBiFIRMY=; b=hYS1mDEIhDer3D5pYjUpPOSQx0WPoHWEFwDXkWtY0Lx5rqrm1jmYpp0GOtaqgWflqk evEv93xGTb4HejPSiwFaUyDj9TsOrvN7mo++l8DsKfKxCsPwf7akfWiQf5SIqqbUxNnF VjMzfZVQkTxw3+SthL9TwQufYHA0tYSbQWXyL8JPkUM2tSTCSFlZ0e/TGsRgRUaAOPhF bxb8TCkB0HnB7stSiEypOZfgnNuQAjxZpkFJTlXnR0WT6KRv4piGElmSM28mKEOE8kfQ 0L2y9JPFWdqTiAlkteD6gzD0bH69SuVr7BPRl2IuaM54X+GsUq8mvbAO6E1I7ym/R2PR eAOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=70okDRnrUemYOqNECOCGsDvFHrJp80FGjIuuBiFIRMY=; b=K7Do6y9xw5ILJaA0Uv3RejffF43b1YPnZTB6EQAGWv/L+wNkjZRWcw4cEm0r/xgOgq IAlbCieBxoVn+ThtBJsbKst2cNzQjN25rv4w+VHI3P6fIpH06UAF73sEFGogWl6uYkQo Q5lGJbVUQXUgADgYncilfcaI6mglaQp64vt8+4NctXJbRFa8OoBqKZ476huAe9yRbxtk fRo56EjveKLxapxwIETBC9dRE4vjRnldpL91irlUjcz9z/mAALIQKsvii0WtKcD6Wqvi pZqWgH6XiW3mz7YvuhCU+M/koKBS3r1+LeqJSun6B096WU+RHSppDFByAq7WLkwrxpm1 rlqQ== X-Gm-Message-State: AD7BkJK8wgkQzm02ClGO51VJUWuhF9oYcQCBGDiiGwd38EUGolZIrkHXeLdkeL2MNZv3KSBWv4dh9W1TQany8A== MIME-Version: 1.0 X-Received: by 10.13.192.5 with SMTP id b5mr2869446ywd.114.1459307932874; Tue, 29 Mar 2016 20:18:52 -0700 (PDT) Received: by 10.129.88.137 with HTTP; Tue, 29 Mar 2016 20:18:52 -0700 (PDT) In-Reply-To: References: Date: Tue, 29 Mar 2016 20:18:52 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e3f98f53c58052f3b9aaf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:18:56 -0000 --001a114e3f98f53c58052f3b9aaf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson wrote: > On 30 March 2016 at 12:49, Colm MacC=C3=A1rthaigh wro= te: > > But isn't that too late? If you have to wait for the client finished > message > > before you can even decrypt the 0RTT section; what's the benefit? it's > not > > "0RTT" any more. > > There is a Finished message in the client's first flight. It's before > the early data. > > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 Sorry, I thought that Finished message disappeared due to concerns over not including any server data. That makes more sense of it; though I'll note that it relies on basically a Mac-Then-Encrypt construction. --=20 Colm --001a114e3f98f53c58052f3b9aaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 29, 2016 at 6:52 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 30 March 2016 at 12:49, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
> But isn't that too late? If you have to wait for the client finish= ed message
> before you can even decrypt the 0RTT section; what's the benefit? = it's not
> "0RTT" any more.

There is a Finished message in the client's first flight.=C2=A0 = It's before
the early data.

https://tlswg.github.io/tls13-spec/#rfc.section= .6.2.2

Sorry, I thought that Finished m= essage disappeared due to concerns over not including any server data. That= makes more sense of it; though I'll note that it relies on basically a= Mac-Then-Encrypt construction. =C2=A0



--
Colm
--001a114e3f98f53c58052f3b9aaf-- From nobody Tue Mar 29 20:20:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564D912DA7C for ; Tue, 29 Mar 2016 20:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 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] 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 AwLQy7dx3DxQ for ; Tue, 29 Mar 2016 20:20:05 -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 9778912D9F6 for ; Tue, 29 Mar 2016 20:20:05 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g3so43277109ywa.3 for ; Tue, 29 Mar 2016 20:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jb+PothDvdv5KM3JI6Ikm7+sG+qDcELgfhzbzsZFawk=; b=180atWkCSbfiMYf6pCV/87w4LRu1pv2Cg7uN+SBW9tegg3OUMHxTfEg32TrQHdtlOy wsDEyUBplmbWghZvzXgTCyJ1pzJ3vSHEZLVSCGP8ELfYh0TDhpR1xSZM9Jtjf4jO4Nob hg1tVQ9R0COhqBzGPaVKO58LwNzy9gZ6qdpGl5rwmduvvPw+6/tCz8D8hjJx8wjvMAYo J7S5sAUxfpYEOFqe1Ur3V5DKY/JIDqPcp46cqQX3dU0Z4+5rUOgJmdpDjVw639V/6WSb thj3WSEEGmq94euXPqDJDxTdZnnuVw587b+2SLrYEPtel9VQct33gKH6r2Hdlr7e0TFN XgFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jb+PothDvdv5KM3JI6Ikm7+sG+qDcELgfhzbzsZFawk=; b=C4dE6iA0BGIB4bLUwMZvVBLd3Vih9WnDpV8970Fl1Sj7C2dynKjifMaXwGhTtnobEG eIZmc+HJfEOcpa7G3P5S7CKJr6Hc8Jc4G+PyOc5hnj7JO8Mdp/hAT7dFszAP5xOrDfCH erDocDUxwhQ1dYofs5fwC/9ecJBHE/XZ7zTRkALH4A0VSYxRl7wEm6dMVqtBMAMn0OUa SJgNzoLuRA/Mr5Sli4+POsQ1NxB3lEqCK1LjYY8iv/OuI4s4LApFnWvVlOoWEH2m4EqX DXa9UGphHGDRIQnSAOMnKpAOXgCo37m3kYn+3rFZe40CNqEcYBo4rXCO0v4w7/SH53lT sYtQ== X-Gm-Message-State: AD7BkJLd66hsBPf1qyqT1HMRgjUvyB3ERnhBPRChYwOPJcvvKBy3Z1MpQWzAN6w+/QSE8LT6e+NyZNZbL+hJ2w== X-Received: by 10.13.218.198 with SMTP id c189mr3126634ywe.165.1459308004779; Tue, 29 Mar 2016 20:20:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 29 Mar 2016 20:19:25 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> From: Eric Rescorla Date: Tue, 29 Mar 2016 20:19:25 -0700 Message-ID: To: Dacheng Zhang Content-Type: multipart/alternative; boundary=94eb2c08192a3e5946052f3b9fcd Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:20:08 -0000 --94eb2c08192a3e5946052f3b9fcd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang wrote: > Hi, Ekr: > > Thanks for reviewing the draft and the comments. Please see my reply > inline please. > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla > =E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F= =E4=B8=89 =E4=B8=8A=E5=8D=887:21 > =E8=87=B3: dacheng de > =E6=8A=84=E9=80=81: Eric Mill , Dave Garrett , > tls > =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension= transfering service indication > information > > I have taken an initial look at this document, but I find myself confused > about the security > model. > > Specifically, you say that you can't use SNI because customers will lie > and insert > the SNI for service A in the ClientHello when going to service B. However= , > I don't > see how this token stops that, since all it represents is a bare assertio= n > of where > you are going that is authenticated with a MAC shared between the client, > the > ICP, and the ISP. What stops the client from doing the same thing, i.e., > injecting > the token for service A into a connection destined for service B? B can > just ignore > the SI token, right? > > Dacheng=EF=BC=9A This is a very good point. How to secure the APPs on the= client > device (e.g., How to secure client and prevent the message sent out from = an > APP provided by ICP A from being intercepted by an APP provided by ICP B > installed on the same mobile) is a hot topic. Lots of people are working > hard to address this issue. For instance, TEE is an attempt of protecting > the security of APPS on a mobile. In a TEE, APPs action are controlled an= d > secure channels are provided to distributed keys. So, in our solution, we > did not consider the case where the execution environment of APPs is not > secure. We assume if an attacker or a malicious has compromise a mobile, = it > could cause more serious damages. > I'm not following. If you trust the device, then why do you need any kind of cryptographic authentication on the token. > Second if the tokens are client specific, what stops an attacker from > copying my > token and then replaying it in a separate connection, thus potentially > causing > the system to charge me or at least to use my rates for the attacker? > > Dacheng: You are right. Since we use timestamps, there could a window for > an attacker to perform attacks by replaying or reusing the token. But we > have narrow down the attack window and mitigate the problem. But Thank yo= u > for this comment. I got an idea. If the HMAC can cover the whole client > hello message, it will be harder for the attacker to reuse the > token.Thoughts? > That wouldn't work with TLS 1.2 but would work with TLS 1.2. > > In short, this document needs a threat model (see RFC 3552) and an analys= is > of why this solution meets that threat model. > > Dacheng: Agree! Will do that in the next version. In addition, we will be > very happy if you have no problem with the requirement. > Hmm... I'm not at all sure that TLS should address this problem. However, my review was directed to whether your proposed solution even works on its own terms. -Ekr > We found this issue when we tried to widely use TLS to secure the > communications between our APPs and our services. If there could be any > better idea or solution, we will be very happy to support it. > > Finally, why am I seeing what appears to be a MAC algorithm definition in > Section > 2.1. Is there a reason you can't just use/cite HMAC? > > Dacheng: I reuse this content from my previous drafts. If people don=E2= =80=99t > like it, we could remove it. ^_^ > > Thanks a lot for your review, and look forward to further discussions on > this topic. ^_^ > > Cheers > > Dacheng > > -Ekr > > > > > > > > > On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang < > dacheng.zdc@alibaba-inc.com> wrote: > >> Hi, >> >> Actually, we refer to the extension as a 'SNI' extension. In this >> extension, SI(service indication) information is provided. In the next >> version, we will use 'SI extension' to take place of 'SNI extension'. ^_= ^ >> >> Cheers >> >> Dacheng >> >> ------------------------------------------------------------------ >> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett >> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829= =E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52 >> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill >> =E6=8A=84 =E9=80=81=EF=BC=9Atls =EF=BC=8C=E5=BC=A0=E5=A4= =A7=E6=88=90(=E6=B7=A1=E4=B9=85) >> =E4=B8=BB =E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfering servic= e indication information >> >> On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: >> >> > It looks like the abbreviation this draft uses is just "SI". It uses S= NI at >> >> > the top a few times to refer to Server Name Indication (which it typos= as >> > "service" name extension). >> > >> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett > > wrote: >> > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: >> > > >> https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-exte= nsion/ >> > > >> > > You really should not use SNI as your abbreviation, as it will just = be >> >> > > frequently confused with the server_name extension which is already = the >> > > dominant use of those initials in TLS. >> >> >> You're correct; my mistake. I didn't notice the typo and reading a spec = draft whilst tired is not always the best of ideas. ;) >> >> >> CCing back to list and thread starter to make sure my correction is OTR = for the list. >> >> >> Fixing that typo in the draft would help to avoid future misreadings. St= icking in a direct reference to RFC6066 on first mention of SNI could add a= nother level of clarification, if desired. >> >> Thanks for quickly correcting me. >> >> >> Dave >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --94eb2c08192a3e5946052f3b9fcd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang <dacheng.zdc@= alibaba-inc.com> wrote:
Hi, Ekr:

Thanks for reviewing the draft and the comments. P= lease see my reply inline please.

=E5=8F=91= =E4=BB=B6=E4=BA=BA: Eric Rescorla <ekr@rtfm.com>
=E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F= =E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=887:21
=E8=87=B3: dacheng de <dacheng.zdc@alibaba-inc.com>
=E6=8A=84=E9=80=81: Eric Mill <eric@konklone.com>, = Dave Garrett <davemgarrett@gmail.com>, tls <tls@ietf.org>
= =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS ext= ension transfering service indication information

I have taken an= initial look at this document, but I find myself confused about the securi= ty
model.
<= br>
Specifically, you say that you can'= t use SNI because customers will lie and insert
the SNI for service A in the ClientHello when going to service B. Howe= ver, I don't
see how this token stops t= hat, since all it represents is a bare assertion of where
you are going that is authenticated with a MAC shared betw= een the client, the
ICP, and the ISP. What = stops the client from doing the same thing, i.e., injecting
the token for service A into a connection destined for ser= vice B? B can just ignore
the SI token, rig= ht?

Dacheng=EF=BC=9A This i= s a very good point. How to secure the APPs on the client device (e.g., How= to secure client and prevent the message sent out from an APP provided by = ICP A from being intercepted by an APP provided by ICP B installed on=C2=A0= the same=C2=A0mobile)=C2=A0 is a hot topic. Lots of peop= le are working hard to address this issue. For instance, TEE is an attempt = of protecting the security of APPS on a mobile. In a TEE, APPs action are c= ontrolled and secure channels are provided to distributed keys. So, in our = solution, we did not consider the case where the execution environment of A= PPs is not secure. We assume if an attacker or a malicious has compromise a= mobile, it could cause more serious damages.

I'm not following. If you trust the device, then = why do you need any kind of cryptographic
authentication on the t= oken.


Second if the tokens are client s= pecific, what stops an attacker from copying my
token and then replaying it in a separate connection, thus potentially= causing
the system to charge me or at leas= t to use my rates for the attacker?

Dacheng: You are right. Since we use timesta= mps, there could a window for an attacker to perform attacks by replaying o= r reusing the token. But we have narrow down the attack window and mitigate= the problem. But Thank you for this comment. I got an idea. If the HMAC ca= n cover the whole client hello message, it will be harder for the attacker = to reuse the token.Thoughts?

=
That wouldn't work with TLS 1.2 but would work with TLS 1.2.
=

=C2=A0

In short, this document nee= ds a threat model (see RFC 3552) and an analysis
of why this solution meets that threat model.

Dacheng: Agree! Will do that in the next vers= ion. In addition, we will be very happy if you have no problem with the req= uirement.

Hmm... I'= m not at all sure that TLS should address this problem. However, my review<= /div>
was directed to whether your proposed solution even works on its = own terms.

-Ekr


=C2=A0
We found this issue when we tried to widely use TLS to sec= ure the communications between our APPs and our services. If there could be= any better idea or solution, we will be very happy to support it.

Finally, why am I seeing what app= ears to be a MAC algorithm definition in Section
2.1. Is there a reason you can't just use/cite HMAC?
<= /span>

Dacheng: I reuse this content from= my previous drafts. If people don=E2=80=99t like it, we could remove it.= =C2=A0^_^

Thanks a lot for your re= view, and look forward to further discussions on this topic.=C2=A0^_^
Cheers

Dacheng

-Ekr








On Tue, Mar 29, 2016 at 12:= 48 AM, Dacheng Zhang <dacheng.zdc@alibaba-inc.com>= wrote:
Hi= ,

Actual= ly, we refer to the extension as a 'SNI' extension. In this extensi= on, SI(service indication) information is provided. In the next version, we= will use 'SI extension' to take place of 'SNI extension'. = ^_^

Chee= rs

Dache= ng
-------------------------= -----------------------------------------
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett <davemgarrett@gmail.= com>
=E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97= =A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill <eric@konklone.com>
=E6=8A=84=E3=80=80=E9=80=81= =EF=BC=9Atls <tls@ietf= .org>=EF=BC=8C=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1=E4=B9=85) <dacheng.zdc@= alibaba-inc.com>
=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfe= ring service indication information
<= span style=3D"font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14px;color:= rgb(0,0,0)">
On=C2=A0Tuesday,=C2=A0March=C2=A0= 29,=C2=A02016=C2=A001:35:50=C2=A0am=C2=A0Eric=C2=A0Mill=C2=A0wrote:
>= =C2=A0It=C2=A0looks=C2=A0like=C2=A0the=C2=A0abbreviation=C2=A0this=C2=A0dra= ft=C2=A0uses=C2=A0is=C2=A0just=C2=A0"SI".=C2=A0It=C2=A0uses=C2=A0= SNI=C2=A0at
>=C2=A0the=C2=A0top=C2=A0a=C2=A0few=C2=A0times=C2=A0to=C2= =A0refer=C2=A0to=C2=A0Server=C2=A0Name=C2=A0Indication=C2=A0(which=C2=A0it= =C2=A0typos=C2=A0as
>=C2=A0"service"=C2=A0name=C2=A0extensi= on).
>=C2=A0
>=C2=A0On=C2=A0Tue,=C2=A0Mar=C2=A029,=C2=A02016=C2= =A0at=C2=A01:13=C2=A0AM,=C2=A0Dave=C2=A0Garrett=C2=A0<davemgarrett@gmail.com>=C2= =A0wrote:
>=C2=A0>=C2=A0On=C2=A0Monday,=C2=A0March=C2= =A028,=C2=A02016=C2=A009:50:13=C2=A0pm=C2=A0Dacheng=C2=A0Zhang=C2=A0wrote:<= br>>=C2=A0>=C2=A0https://datatracke= r.ietf.org/doc/draft-zhang-tls-service-indication-extension/
>=C2= =A0>
>=C2=A0>=C2=A0You=C2=A0really=C2=A0should=C2=A0not=C2=A0us= e=C2=A0SNI=C2=A0as=C2=A0your=C2=A0abbreviation,=C2=A0as=C2=A0it=C2=A0will= =C2=A0just=C2=A0be
>=C2=A0>=C2=A0frequently=C2=A0confused=C2=A0wit= h=C2=A0the=C2=A0server_name=C2=A0extension=C2=A0which=C2=A0is=C2=A0already= =C2=A0the
>=C2=A0>=C2=A0dominant=C2=A0use=C2=A0of=C2=A0those=C2=A0= initials=C2=A0in=C2=A0TLS.

You're=C2=A0correct;=C2= =A0my=C2=A0mistake.=C2=A0I=C2=A0didn't=C2=A0notice=C2=A0the=C2=A0typo= =C2=A0and=C2=A0reading=C2=A0a=C2=A0spec=C2=A0draft=C2=A0whilst=C2=A0tired= =C2=A0is=C2=A0not=C2=A0always=C2=A0the=C2=A0best=C2=A0of=C2=A0ideas.=C2=A0;= )

CCing=C2=A0back=C2=A0to=C2=A0list=C2=A0and=C2=A0thread=C2=A0starte= r=C2=A0to=C2=A0make=C2=A0sure=C2=A0my=C2=A0correction=C2=A0is=C2=A0OTR=C2= =A0for=C2=A0the=C2=A0list.

Fixing=C2=A0that=C2=A0typo=C2=A0in=C2=A0t= he=C2=A0draft=C2=A0would=C2=A0help=C2=A0to=C2=A0avoid=C2=A0future=C2=A0misr= eadings.=C2=A0Sticking=C2=A0in=C2=A0a=C2=A0direct=C2=A0reference=C2=A0to=C2= =A0RFC6066=C2=A0on=C2=A0first=C2=A0mention=C2=A0of=C2=A0SNI=C2=A0could=C2= =A0add=C2=A0another=C2=A0level=C2=A0of=C2=A0clarification,=C2=A0if=C2=A0des= ired.

Thanks=C2=A0for=C2=A0quickly=C2=A0correcting=C2=A0me.

<= br>Dave


_______________________= ________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/tls



--94eb2c08192a3e5946052f3b9fcd-- From nobody Tue Mar 29 20:52:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDA612D0A6 for ; Tue, 29 Mar 2016 20:52:22 -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 weYHqSOCNh9n for ; Tue, 29 Mar 2016 20:52:20 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A453912D099 for ; Tue, 29 Mar 2016 20:52:20 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id a129so48646377ioe.0 for ; Tue, 29 Mar 2016 20:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=G0EQ/eHwgR/crIBMYY2ti8zAmAx/sUJaYvDV79APVXI=; b=Q+w4/+0nOGXAkslpsvhjVnbA7QyTsVjpZ6g+NG+nCZk+0yLHl97QPGyYxbZK667Cql swUDSewwN8E6elTM6GBm6a1Rtr3YDuwz+0LnHoDJ/IZY1zszsEuS0QPv1EZRuo7DoWQb jkip5cHCqitOvMcWb6tSdlmnHZAPXYSCJ0qj0g2EkKuCIs68I3xyio0EllOs+oQ9xjnc 0VlqY4gJG9udFMXKvsqeO8dXhaNCksJHx23Iy5Dgu+GXDMxToLX8hYSAf3gfzh7JPtdq 2T5zJL4jRS/RfNuxbr3k5P56nABMVu6dxBoAgSOj3sJ68k+4W8WIUok4ZWZu8H1Ca/1Y hvaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=G0EQ/eHwgR/crIBMYY2ti8zAmAx/sUJaYvDV79APVXI=; b=WwVwEoAPOyibytP1yv/gg3xRwQ2Xv7HnbUWJpj5J4x8+z0mZRqtUtJMzJqITYwsTKN /dXx6NYj8gdx6qeDrKamopdmyO0lRM6aGUPp5bAI0MNxsNVg2mhzsq2bXvEUj6qWm0KF SkdFv9mmwAYsCFx36nrB9kf+46dJuF+75oF/E4bta3iwA1vvvDZywUbt+MlRg4oO2pUB 60KAHMDp/sailPWncPhSWoK1l5o2NjEQy/jBaASgYUpXgFDZsCwFmCABax+FCY+QWiW+ 4m6F2813jrogMm6Y3lEJ8Om3lYh4VgyoOWmRN1lmQe6W5mY9KsYGJlksjpPs+vwKNKIU JUCA== X-Gm-Message-State: AD7BkJIGiBwIcjx4o+8r8PcDfbbOIeKTsALebGVwAWM90rtbkK8L8S0eZJpjblv9sDhJQEN2/sp4MUQuJiwg+Q== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr7079970ioe.190.1459309939974; Tue, 29 Mar 2016 20:52:19 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 20:52:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 14:52:19 +1100 Message-ID: From: Martin Thomson To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:52:22 -0000 On 30 March 2016 at 14:18, Colm MacC=C3=A1rthaigh wrote= : > though I'll note that it relies on basically a Mac-Then-Encrypt > construction. I don't think that the right term to apply here. This isn't record protection. The MAC authenticates the handshake here, then we use AEAD for record protection afterwards. Same as TLS has always done. It's basic SIGMA. From nobody Tue Mar 29 20:53:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E415112D099 for ; Tue, 29 Mar 2016 20:53: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 XftrJQj5YEho for ; Tue, 29 Mar 2016 20:53:50 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20C612D0A6 for ; Tue, 29 Mar 2016 20:53:50 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id e3so50849776ioa.1 for ; Tue, 29 Mar 2016 20:53:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ve9QEAhVF9Hit8cO/pFOSZhq786yUJk2bILkA3QhIFg=; b=hJ7nbWu5dLmyHVlzNjoefRZOWAVzCEnveWynUcZ25r++fyJxYS4/9mCBKDAXPS31YC Gd2n7GlInf+OfCt5V08iK+KGrghZ85oFyoyiM7xujONSYD2uBH8ppwGa+Cje1BK0yI7b 4jl3iBjxortmx+Qy7sf6u5yLR/Uzrb+PGNggUlyX1i+lhufKaf8rUqZfJ+TQeoFn4LSt 3ASnVcPl5VwnLAto8t/KdnHendOask0UQNyBxQdsg4nd5NTkhQG7YZ5nkofukVblaiLS s7A0IMDf8RgdukdQd5aiWRct/iz7eGPPdxyuVT8JhMo8mOc8rt1+Vrg9vOzRFaHsI5GA ltoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ve9QEAhVF9Hit8cO/pFOSZhq786yUJk2bILkA3QhIFg=; b=ZzBKbXj9ifhfulS3CfCZMj74V7zIJL9t0WyXDrpBlwTAfENuZbC7S8/CK5CHlNEKCB /i7K7RcusDz0mIbpXyMPnYsCUmD+oIuXmWaq3oOnjF9lrIltEMOHgH5i29uMEM+FtZ3k MzpLigBYPS+LZef/j4VDV6Igww/7sKYGptNJs9sp7KTTpRBw0m3tkJL5B+smOsIFbdpk KTVaACHJd4+hgOiN1j//ZP+4sTUcctShZ/jYHy3NCZuQ9NzezHupl973q+vjw8TAV7j8 CbhAwnhYpNqDtEkYRHA1EApdPvdy+z4ZbIvZyG4zEgV1gMa+kvkJsS9zVUjXhUAcYzAl mulg== X-Gm-Message-State: AD7BkJIGAZxX2P9uNjnL1UD8ariChOn6fvxOJk4hdqi7tzk2wfE/FzYmkJbRu3TVwMFb1Z7aafrPT26UdC97Pw== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr6316175ioi.108.1459310030008; Tue, 29 Mar 2016 20:53:50 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 20:53:49 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> Date: Wed, 30 Mar 2016 14:53:49 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:53:52 -0000 On 30 March 2016 at 14:19, Eric Rescorla wrote: > That wouldn't work with TLS 1.2 but would work with TLS 1.2. I think that you meant that it would work with TLS 1.2 and extended master secret, or TLS 1.3. From nobody Tue Mar 29 21:00:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2912DC53 for ; Tue, 29 Mar 2016 21:00:00 -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 sglbvdlANtyK for ; Tue, 29 Mar 2016 20:59:59 -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 58B3312D0B3 for ; Tue, 29 Mar 2016 20:59:59 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id g127so43823966ywf.2 for ; Tue, 29 Mar 2016 20:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ssrBW88a2G0rTLPVZ50ImYAz+beF1MhzIQ8Sv8/fs+M=; b=GZ6QoahmP2kTX9j+pM+x4autwH9NuEaNfKQzreTwwCO9huQc6Hbqfz+5enel+9Xo3r dukR6u0hucJ1J6qwFoTFP5P+rwx1SYz6PBVjSfERO091fbKYAPtEmeyDuAbgi6YMmQOa H8qucuI9FRdPFz6r0ragwal3Dwnfpms9kR4xCx+j5UGPoSu2W2Bc8XZ6ZVOnAV4JT5bz VpYC0jtwZ70TTAkD8+XeetJ2nTN8qbXiW2IgtySTJHbnw0OIoF0qmR33RvA0Vo2XECzx HjXkZH5kTDBZHA2e5JHpf5sDXU5suB0hIlxPjl9bmkrSA8iFbzMKzcWHsTDxUYe6VoBI ColQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ssrBW88a2G0rTLPVZ50ImYAz+beF1MhzIQ8Sv8/fs+M=; b=F+q5jbUNMMe5O+z4+B/3XccmML07dKKznHd7x83JP/1dALqkso4LKTKkybWsqEbuke ya3BG97LDszLytgW6eVaNhN4oTZekTsssSAlVT2A0+UQjvIzJ1Rimc1CsNpg+DA8KpyE /KJauL4I7mkGXNrFl3yEn+FnG28ArZIimWoFX19akQM86GeNCF7cTI68Pq7/Qvc3x44I oxXw1aaSZ6tFxTnPIKnyqlDFPDOmNgRinY+22Y3l6UY8NjhVkcoghEZuljWUc813gVl9 SlmECRh5ibfHIKM7iRDxyEE+HLSJWA/Q6fBhvbu/aARym1UOLAHpnTUZqEvAkJ6G+WYQ M48g== X-Gm-Message-State: AD7BkJKGFAilMugsLn0kgQPJSpM0gJzNE0oV3LTq2Z67tGL4K82FFjG88qYnCgZnKloltHAMwyV7MpvuOtsaeQ== X-Received: by 10.129.80.69 with SMTP id e66mr3307658ywb.231.1459310398603; Tue, 29 Mar 2016 20:59:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 29 Mar 2016 20:59:19 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> From: Eric Rescorla Date: Tue, 29 Mar 2016 20:59:19 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1147f078ed315b052f3c2dbf Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:00:00 -0000 --001a1147f078ed315b052f3c2dbf Content-Type: text/plain; charset=UTF-8 I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.2 even with EMS because (even with the MAC) the SI extension is bound to the ClientHello which is replayable in 1.2 because it contains public information, with the only non-fixed information being the random. However in 1.3 it contains the DH key share, which the attacker doesn't know the corresponding private value for. -Ekr On Tue, Mar 29, 2016 at 8:53 PM, Martin Thomson wrote: > On 30 March 2016 at 14:19, Eric Rescorla wrote: > > That wouldn't work with TLS 1.2 but would work with TLS 1.2. > > I think that you meant that it would work with TLS 1.2 and extended > master secret, or TLS 1.3. > --001a1147f078ed315b052f3c2dbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I meant "would work with TLS 1.3". I don= 9;t believe it will work with TLS 1.2 even
with EMS because (even= with the MAC) the SI extension is bound to the ClientHello
which= is replayable in 1.2 because it contains public information, with the
only non-fixed information being the random. However in 1.3 it contai= ns the DH
key share, which the attacker doesn't know the corr= esponding private value
for.

-Ekr
<= div>

On Tue, Mar 29, 2016 at 8:53 PM, Martin Thomson <martin.thomson@= gmail.com> wrote:
On 30 March 2016 at 14:19, Eric Rescorla <ekr@rtfm.com> wrote:
> That wouldn't work with TLS 1.2 but would work with TLS 1.2.

I think that you meant that it would work with TLS 1.2 and extended<= br> master secret, or TLS 1.3.

--001a1147f078ed315b052f3c2dbf-- From nobody Tue Mar 29 21:01:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EC612DCB3 for ; Tue, 29 Mar 2016 21:01:28 -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 OLqxeDyCRCjD for ; Tue, 29 Mar 2016 21:01:27 -0700 (PDT) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 5404F12DC53 for ; Tue, 29 Mar 2016 21:01:27 -0700 (PDT) Received: by mail-ig0-x22a.google.com with SMTP id ui10so21987738igc.1 for ; Tue, 29 Mar 2016 21:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=y23xe3y7xuXyFVd7ioAk10U5jcyURx+D8WMF94yz0L0=; b=jBXz9pRg2/a8eszZiVe805Pf0EgidxR0uQzpvlPPpJEq0z10r7TvR633YUPIgcSbyA cA+QA7FA9HbGFYou+hyhlzTwuAGo46qo5cX18uSQwawah+pwtBVgrVwsly6QPC3W0wmc 9xK8SP9MzP2/hKoTiz3t4RnEEA4dN75WdqRyRUHgqGVlv9uXTMlKPmV+3FSmgcbbIZHP jrskKavzEQo3iglBcsaBJGc1xHMTc+5jJdlkYOBKj17YIWryANKHgjtTPVOOLt3hoI7L OHEuMiTA2o1jGmN1tcth58MlyNQCH5Ftio0MeoYvG2wow/q6HtjW72Xzg9a92NDVYIev +hnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=y23xe3y7xuXyFVd7ioAk10U5jcyURx+D8WMF94yz0L0=; b=i2OsH5HyM+EHw37/4P6m9po8eEt5532ZE4r5BZn6fploulugsSjDzOZN96rw71xXHf GCL/ORZ7J35DdaWVVMEE+Fq3wl38s2gITKLE13fkSYM6XK0SGSIJKJLky4oDsLiotsee ot6RYzT8UBsyxoP2Bg9ClOXCEjHH0cDz7FgywLCLaDtEqlv5pe0nZ2I40DRXuKs+08ZN UpFiictntaBQChSaiyNjl8UZ4ugqfTVwn0k1txcfLReSvEFyolNNxKcQCEdLDYRt5c7q lVr8baeZEiS3hab4v1c9as+/bQe36WURj8rD9kMaMpqQulhZGMnOWkCA/RCxro0C0LGL qiNw== X-Gm-Message-State: AD7BkJLRIAPZecB3srVu9JCdqrJQzPlK38cfj9GOZ77LNeWxL5CJDhtIs4NyqHQvd05/b8btkEErKcKc6yYseg== MIME-Version: 1.0 X-Received: by 10.50.43.226 with SMTP id z2mr7380162igl.94.1459310486743; Tue, 29 Mar 2016 21:01:26 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 21:01:26 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> Date: Wed, 30 Mar 2016 15:01:26 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:01:28 -0000 On 30 March 2016 at 14:59, Eric Rescorla wrote: > I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.2 > even > with EMS because (even with the MAC) the SI extension is bound to the > ClientHello > which is replayable in 1.2 because it contains public information, with the > only non-fixed information being the random. However in 1.3 it contains the > DH > key share, which the attacker doesn't know the corresponding private value > for. Right. Score one for TLS 1.3. From nobody Tue Mar 29 21:04:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA6412DC53 for ; Tue, 29 Mar 2016 21:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UaNQSZAOvOfg for ; Tue, 29 Mar 2016 21:04:47 -0700 (PDT) Received: from out4133-18.mail.aliyun.com (out4133-18.mail.aliyun.com [42.120.133.18]) by ietfa.amsl.com (Postfix) with ESMTP id 5248812D0B3 for ; Tue, 29 Mar 2016 21:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459310683; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=gNdYE7+jhU+Jal9e/vCP1Cne7R73Wh6bBwHmI6Hq7S8=; b=ihjBURhU6HoQxyKfslQHZgPXMrZxRX3qNz6k2YMoAXx8u3caZIaas/oxPnWt1Sof/lSu/HqCtynCnbb65a4H5X+fYgZDfOyxGgURu82vBOZY/Iv3gNz1HwWeV53KGBVl0fVpsdc1cnAFKxLT0+0c8FFpuX6qst7xAxiBdP5QB1o= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03302; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_----4ehNzSS_1459310674; Received: from 10.62.54.107(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Mar 2016 12:04:38 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Wed, 30 Mar 2016 12:04:32 +0800 From: "Dacheng Zhang" To: Eric Rescorla Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542184278_243609" Archived-At: Cc: tls , =?GBK?B?wfW088X0KMX0s8kp?= Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:04:50 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3542184278_243609 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi, Erk: My reply inline please. Cheers Dacheng =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla =E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=8811:19 =E8=87=B3: dacheng de =E6=8A=84=E9=80=81: Eric Mill , Dave Garrett , tls =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension transfering service indication information On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang wrote: > Hi, Ekr: >=20 > Thanks for reviewing the draft and the comments. Please see my reply inli= ne > please. >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla > =E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=887:21 > =E8=87=B3: dacheng de > =E6=8A=84=E9=80=81: Eric Mill , Dave Garrett , tls > > =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension transfering service indicati= on information >=20 > I have taken an initial look at this document, but I find myself confused > about the security > model. >=20 > Specifically, you say that you can't use SNI because customers will lie a= nd > insert > the SNI for service A in the ClientHello when going to service B. However= , I > don't > see how this token stops that, since all it represents is a bare assertio= n of > where > you are going that is authenticated with a MAC shared between the client,= the > ICP, and the ISP. What stops the client from doing the same thing, i.e., > injecting > the token for service A into a connection destined for service B? B can j= ust > ignore > the SI token, right? >=20 > Dacheng=EF=BC=9A This is a very good point. How to secure the APPs on the clien= t > device (e.g., How to secure client and prevent the message sent out from = an > APP provided by ICP A from being intercepted by an APP provided by ICP B > installed on the same mobile) is a hot topic. Lots of people are working= hard > to address this issue. For instance, TEE is an attempt of protecting the > security of APPS on a mobile. In a TEE, APPs action are controlled and se= cure > channels are provided to distributed keys. So, in our solution, we did no= t > consider the case where the execution environment of APPs is not secure. = We > assume if an attacker or a malicious has compromise a mobile, it could ca= use > more serious damages. I'm not following. If you trust the device, then why do you need any kind o= f cryptographic authentication on the token. Dacheng=EF=BC=9ALet assume we trust the device. But the APP use a SNI to indicate the service that the APP intends to access. Because the SNI is static which may not be changed for months, it is easier for attackers who monitor the network to get the SNI and use it to gain benefit. We need a securer solution. As I have mentioned in my previous email, this solution will make such attacks more difficult. By the way, SNI is not designed for this purpose, we need to do some additional work to address this issue, right? >=20 > Second if the tokens are client specific, what stops an attacker from cop= ying > my > token and then replaying it in a separate connection, thus potentially ca= using > the system to charge me or at least to use my rates for the attacker? >=20 > Dacheng: You are right. Since we use timestamps, there could a window for= an > attacker to perform attacks by replaying or reusing the token. But we hav= e > narrow down the attack window and mitigate the problem. But Thank you for= this > comment. I got an idea. If the HMAC can cover the whole client hello mess= age, > it will be harder for the attacker to reuse the token.Thoughts? That wouldn't work with TLS 1.2 but would work with TLS 1.2. =20 >=20 > In short, this document needs a threat model (see RFC 3552) and an analys= is > of why this solution meets that threat model. >=20 > Dacheng: Agree! Will do that in the next version. In addition, we will be= very > happy if you have no problem with the requirement. Hmm... I'm not at all sure that TLS should address this problem. However, m= y review was directed to whether your proposed solution even works on its own terms. Dacheng: That is why we need to raise the discussion here. It would be grea= t if this issue could be considered by TLS WG. -Ekr =20 > We found this issue when we tried to widely use TLS to secure the > communications between our APPs and our services. If there could be any b= etter > idea or solution, we will be very happy to support it. >=20 > Finally, why am I seeing what appears to be a MAC algorithm definition in > Section > 2.1. Is there a reason you can't just use/cite HMAC? >=20 > Dacheng: I reuse this content from my previous drafts. If people don=E2=80=99t = like > it, we could remove it. ^_^ >=20 > Thanks a lot for your review, and look forward to further discussions on = this > topic. ^_^ >=20 > Cheers >=20 > Dacheng >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang > wrote: >> Hi, >>=20 >> Actually, we refer to the extension as a 'SNI' extension. In this extens= ion, >> SI(service indication) information is provided. In the next version, we = will >> use 'SI extension' to take place of 'SNI extension'. ^_^ >>=20 >> Cheers >>=20 >> Dacheng >>> ------------------------------------------------------------------ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill >>> =E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls =EF=BC=8C=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1=E4=B9=85) >>> =E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfering service indication in= formation >>>=20 >>> On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: >>>> > It looks like the abbreviation this draft uses is just "SI". It uses= SNI >>>> at >>>> > the top a few times to refer to Server Name Indication (which it typ= os as >>>> > "service" name extension). >>>> >=20 >>>> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett >>>> wrote: >>>>> > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: >>>>> > >=20 >>>>>=20 https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extens>= >>>> ion/ >>>>> > > >>>>> > > You really should not use SNI as your abbreviation, as it will ju= st be >>>>> > > frequently confused with the server_name extension which is alrea= dy the >>>>> > > dominant use of those initials in TLS. >>>=20 >>> You're correct; my mistake. I didn't notice the typo and reading a spec >>> draft whilst tired is not always the best of ideas. ;) >>>=20 >>> CCing back to list and thread starter to make sure my correction is OTR= for >>> the list. >>>=20 >>> Fixing that typo in the draft would help to avoid future misreadings. >>> Sticking in a direct reference to RFC6066 on first mention of SNI could= add >>> another level of clarification, if desired. >>>=20 >>> Thanks for quickly correcting me. >>>=20 >>>=20 >>> Dave >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 --B_3542184278_243609 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable
Hi, Erk:
=
My reply inline please.

Che= ers

Dacheng

=E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla <ekr@rtfm.com>
=E6=97=A5=E6=9C=9F: <= /span> 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=8811:19
=E8=87=B3: dacheng de <dacheng.zdc@alibaba-inc.com>
=E6=8A=84=E9=80= =81: Eric Mill <eric@konklone.co= m>, Dave Garrett <davemgar= rett@gmail.com>, tls <tls@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A= A TLS extension transfering service indication information


On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang <dacheng.zdc@alibaba= -inc.com> wrote:
Hi, Ekr:

Thanks for reviewing the draft and th= e comments. Please see my reply inline please.

=E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Resco= rla <ekr@rtfm.com>=E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 = =E4=B8=8A=E5=8D=887:21
=E8=87=B3: dacheng de <dacheng.zdc@alibab= a-inc.com>
=E6=8A=84=E9=80=81: Eric Mil= l <eric@konklone.com>, Dave Garrett <davemgarrett@gmail.com>, tls <tls@ietf.org>
=E4=B8=BB=E9=A2=98= : Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension transfering service indication= information

I have taken an initial look at this document, but I find my= self confused about the security
model.
<= div class=3D"gmail_extra">
Specifically, you= say that you can't use SNI because customers will lie and insert
the SNI for service A in the ClientHello when going to s= ervice B. However, I don't
see how this token = stops that, since all it represents is a bare assertion of where
you are going that is authenticated with a MAC shared bet= ween the client, the
ICP, and the ISP. What st= ops the client from doing the same thing, i.e., injecting
the token for service A into a connection destined for service B= ? B can just ignore
the SI token, right?
=

Dacheng=EF=BC=9A This is a very good point. How to secure the APPs on t= he client device (e.g., How to secure client and prevent the message sent ou= t from an APP provided by ICP A from being intercepted by an APP provided by= ICP B installed on the same mobile)  is a hot topi= c. Lots of people are working hard to address this issue. For instance, TEE = is an attempt of protecting the security of APPS on a mobile. In a TEE, APPs= action are controlled and secure channels are provided to distributed keys.= So, in our solution, we did not consider the case where the execution envir= onment of APPs is not secure. We assume if an attacker or a malicious has co= mpromise a mobile, it could cause more serious damages.

I'm not following. If you trust the device, t= hen why do you need any kind of cryptographic
authentication on th= e token.

Dacheng=EF=BC=9ALet assume we trust the dev= ice. But the APP use a SNI to indicate the service that the APP intends to a= ccess. Because the SNI is static which may not be changed for months, it is = easier for attackers who monitor the network to get the SNI and use it to ga= in benefit. We need a securer solution. As I have mentioned in my previ= ous email, this solution will make such attacks more difficult. By the way, = SNI is not designed for this purpose, we need to do some additional work to = address this issue, right?
<= br>

Second if the tokens are client specific, what stops an attacker from copyi= ng my
token and then replaying it in a separat= e connection, thus potentially causing
the sys= tem to charge me or at least to use my rates for the attacker?

Dacheng: You are right. Since we use timestamps, th= ere could a window for an attacker to perform attacks by replaying or reusin= g the token. But we have narrow down the attack window and mitigate the prob= lem. But Thank you for this comment. I got an idea. If the HMAC can cover th= e whole client hello message, it will be harder for the attacker to reuse th= e token.Thoughts?

That wo= uldn't work with TLS 1.2 but would work with TLS 1.2.

 
<= span style=3D"font-family: =E5=AE=8B=E4=BD=93, sans-serif; font-size: 14px; color: rgb(0, = 0, 0);">

In short, this document needs a threat model (see RFC 3552) and an an= alysis
of why this solution meets that threat = model.

Dacheng: Agree! Will do that in the next version= . In addition, we will be very happy if you have no problem with the require= ment.

Hmm... I'm not at = all sure that TLS should address this problem. However, my review
= was directed to whether your proposed solution even works on its own terms.<= /div>

Dacheng: That is why we need to raise th= e discussion here. It would be great if this issue could be considered by TL= S WG.

-Ekr


 
We found this issue when we tried to widely use TLS to secur= e the communications between our APPs and our services. If there could be an= y better idea or solution, we will be very happy to support it.
=

Finally, why am I seeing what appears to be a MAC alg= orithm definition in Section
2.1. Is there a r= eason you can't just use/cite HMAC?

Dacheng: I reuse th= is content from my previous drafts. If people don’t like it, we could = remove it. ^_^

Thanks a lot for your review, and look forward to fur= ther discussions on this topic. ^_^

Cheers

Dacheng
<= /font>

-Ekr



<= /div>


<= div class=3D"gmail_extra">


On Tue, Mar 29, 2016 at 12:48= AM, Dacheng Zhang <dacheng.zdc@alibaba-inc.com> wrote:
Hi,

Actually, we refer to the ext= ension as a 'SNI' extension. In this extension, SI(service indication) infor= mation is provided. In the next version, we will use 'SI extension' to take = place of 'SNI extension'. ^_^

Cheers

Dacheng
-------= -----------------------------------------------------------
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett <davemgarrett@gmail.com= >
=E5=8F=91=E9=80=81=E6= =97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill <eric@konklone.com>
=E6=8A=84=E3=80=80=E9=80=81=EF=BC=9Atls <tls@ietf.org>=EF=BC=8C=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1=E4=B9=85) <dacheng.zdc@alibaba-inc.c= om>
=E4=B8= =BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfering service indication informati= on

On Tuesday, March 29, 2016 01:35:50&n= bsp;am Eric Mill wrote:
> It looks like&= nbsp;the abbreviation this draft uses is just&= nbsp;"SI". It uses SNI at
> the top = ;a few times to refer to Server Name = ;Indication (which it typos as
> "service"&nb= sp;name extension).
> 
> On Tue, Mar&nb= sp;29, 2016 at 1:13 AM, Dave Garrett <= davemgarrett@gmail.c= om> wrote:
> > On Monday,&n= bsp;March 28, 2016 09:50:13 pm Dacheng Zhang&n= bsp;wrote:
> > https://datat= racker.ietf.org/doc/draft-zhang-tls-service-indication-extension/
>= ; >
> > You really should not = ;use SNI as your abbreviation, as it will=  just be
> > frequently confused with=  the server_name extension which is already&nb= sp;the
> > dominant use of those init= ials in TLS.

You're correct; my = ;mistake. I didn't notice the typo and re= ading a spec draft whilst tired is not&nb= sp;always the best of ideas. ;)

CCing b= ack to list and thread starter to make&nb= sp;sure my correction is OTR for the list= .

Fixing that typo in the draft would&n= bsp;help to avoid future misreadings. Sticking = ;in a direct reference to RFC6066 on firs= t mention of SNI could add another level&= nbsp;of clarification, if desired.

Thanks for&nbs= p;quickly correcting me.


Dave
<= br>

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


=
--B_3542184278_243609-- From nobody Tue Mar 29 21:06:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5E3512DCB3 for ; Tue, 29 Mar 2016 21:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyL6RFtS7rYV for ; Tue, 29 Mar 2016 21:06:28 -0700 (PDT) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86FD212DC53 for ; Tue, 29 Mar 2016 21:06:28 -0700 (PDT) Received: by mail-ig0-x234.google.com with SMTP id nk17so92117710igb.1 for ; Tue, 29 Mar 2016 21:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=ZzWjzTkcxrVdFXdoFA4JWRI80gDYFLETqqjlAmrpPWA=; b=Gw+vm79ljd09m7D0mZJBgX4jfg7jUYW8NGSjLyLsuTk1YWNgYQ/47vK+DuWLHjiAaT IeJPbNEGXivHkuSOxmzvthmGi5lNGKcats5MfhxsAnseF/o0KDH/VJRenTnr40IQ5N6o 7pZxW91mFPmAfaq5HeeoeDV4BNwjjkAf80PvIQUnE9l8vbBu7aS6s7jkCpgxCVe7P01f /Q74KbaoMv5+oAcCqzfga9Ufd2t0v8G14bI+sdLiajWWTrtS3Lm+D4Qc2bQZRH0Skybj 0446UhVLhaY3poQ/baFShHr160+Nb3qa717B01bgpmADzdb4wlYmaY+YyhRusi3obVYb Ec5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=ZzWjzTkcxrVdFXdoFA4JWRI80gDYFLETqqjlAmrpPWA=; b=kcCFPH5OM4gBLyxK+vvjVNVTsyWWvs04XvckgbinybPJW50xIlv7CSNTVzRwIp21Bs 1ypQ+G9LC9fQmYB0mt3qpYAcaloX2GtuWITJy/6Z9JlmUEDVnNiGc3HsRoUQzt7GQXpA Kgh5/EPtdIFfSsDSxScOKQYU/8rfCPwCG3gDBPyCrQ6i9Rzap205gTkagsAkA7pObgNi 6RDvDj85iJnAsrqV4Ak+dHsas9ICdCmD1KLGKVupZjrb15zxpkC/YDvHs0TmdcXbK0Jb y445T9u4Ee2uYYKs2BkcGErXJpjwkZvzGAK9LHFoU9QiJbD40HbOWzv5fGPezeRfB03n 5PVQ== X-Gm-Message-State: AD7BkJIFY+gpDhSoPhYUhlEMLx2c4xK3pP2zqDTFmDDHoFA7W1wqA5/tv6jmYBYILjR5g+MSUGjzlwQcBkhQhw== MIME-Version: 1.0 X-Received: by 10.50.221.67 with SMTP id qc3mr7463019igc.77.1459310787861; Tue, 29 Mar 2016 21:06:27 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 21:06:27 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> Date: Wed, 30 Mar 2016 15:06:27 +1100 Message-ID: From: Martin Thomson To: Dacheng Zhang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= , tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:06:30 -0000 On 30 March 2016 at 15:04, Dacheng Zhang wrot= e: > Dacheng=EF=BC=9ALet assume we trust the device. But the APP use a SNI to = indicate > the service that the APP intends to access. Because the SNI is static whi= ch > may not be changed for months, it is easier for attackers who monitor the > network to get the SNI and use it to gain benefit. We need a securer > solution. As I have mentioned in my previous email, this solution will ma= ke > such attacks more difficult. By the way, SNI is not designed for this > purpose, we need to do some additional work to address this issue, right? What is wrong with client authentication? From nobody Tue Mar 29 21:08:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65BB812DCB3 for ; Tue, 29 Mar 2016 21:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPqQ7zhf09d2 for ; Tue, 29 Mar 2016 21:08:33 -0700 (PDT) Received: from out4133-66.mail.aliyun.com (out4133-66.mail.aliyun.com [42.120.133.66]) by ietfa.amsl.com (Postfix) with ESMTP id 92F2F12DCA9 for ; Tue, 29 Mar 2016 21:08:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459310911; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=MuJFANWDUJG05mdclOAywNc+FGlsnEMrJT2MelKaUEI=; b=hHNqT7tJgVby1wFcuFZ+QfDyzTGlUZAPpp0URumE4PPSfrDfELFJzp7czy9mWBk0peDPdz8L06tJoWi4NAD/m+1pO18gaNoH0KY+rhCf610RKH/jyFc67p0bSNfw0G/bDEoTWHs8rRaPV29+4b4j/R4Ez7XhvROTh1jmKx8x9Xw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R181e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03308; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=3; SR=0; TI=SMTPD_----4eiYJA8_1459310906; Received: from 10.62.54.107(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Mar 2016 12:08:29 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Wed, 30 Mar 2016 12:08:24 +0800 From: "Dacheng Zhang" To: Eric Rescorla , Martin Thomson Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542184509_279600" Archived-At: Cc: tls Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:08:34 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3542184509_279600 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Right. When we design this solution, we assume it will work with TLS1.3. Th= e TLS WG has stopped working on the extensions for TLS 1.2, right? =B7=A2=BC=FE=C8=CB: Eric Rescorla =C8=D5=C6=DA: 2016=C4=EA3=D4=C230=C8=D5 =D0=C7=C6=DA=C8=FD =C9=CF=CE=E711:59 =D6=C1: Martin Thomson =B3=AD=CB=CD: dacheng de , tls =D6=F7=CC=E2: Re: [TLS] =BB=D8=B8=B4=A3=BA A TLS extension transfering service indication information I meant "would work with TLS 1.3". I don't believe it will work with TLS 1.= 2 even with EMS because (even with the MAC) the SI extension is bound to the ClientHello which is replayable in 1.2 because it contains public information, with the only non-fixed information being the random. However in 1.3 it contains the DH key share, which the attacker doesn't know the corresponding private value for. -Ekr On Tue, Mar 29, 2016 at 8:53 PM, Martin Thomson wrote: > On 30 March 2016 at 14:19, Eric Rescorla wrote: >> > That wouldn't work with TLS 1.2 but would work with TLS 1.2. >=20 > I think that you meant that it would work with TLS 1.2 and extended > master secret, or TLS 1.3. --B_3542184509_279600 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Right. When we design this solut= ion, we assume it will work with TLS1.3. The TLS WG has stopped working on t= he extensions for TLS 1.2, right? 

=B7=A2=BC=FE=C8=CB: Eric Rescorla <= ekr@rtfm.com>
=C8=D5=C6=DA: 2016=C4=EA3= =D4=C230=C8=D5 =D0=C7=C6=DA=C8=FD =C9=CF=CE=E711:59
=D6=C1: Martin= Thomson <martin.thomson@gmail.= com>
=B3=AD=CB=CD: dacheng de <<= a href=3D"mailto:dacheng.zdc@alibaba-inc.com">dacheng.zdc@alibaba-inc.com&= gt;, tls <tls@ietf.org>
=D6=F7=CC=E2: Re: [TLS] =BB=D8=B8=B4=A3=BA A TLS extension transfe= ring service indication information

<= div>I meant "would work with TLS 1.3". I don't believe it will work with TLS= 1.2 even
with EMS because (even with the MAC) the SI extension is= bound to the ClientHello
which is replayable in 1.2 because it co= ntains public information, with the
only non-fixed information bei= ng the random. However in 1.3 it contains the DH
key share, which = the attacker doesn't know the corresponding private value
for.

-Ekr


On Tue, Mar 29, 2016 at 8:53 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
On 30 March 2016 at 14:19, Eric Rescorla <ekr@rtfm.com> wrote:
> That wouldn't work with TLS 1.2 but would work with TLS 1.2.

I think that you meant that it would work with TLS 1.2 and extended
= master secret, or TLS 1.3.

 --B_3542184509_279600-- From nobody Tue Mar 29 21:12:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B512DCE1 for ; Tue, 29 Mar 2016 21:12:47 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6T67dgZD3Dux for ; Tue, 29 Mar 2016 21:12:46 -0700 (PDT) Received: from out4133-34.mail.aliyun.com (out4133-34.mail.aliyun.com [42.120.133.34]) by ietfa.amsl.com (Postfix) with ESMTP id A4B4512DCDE for ; Tue, 29 Mar 2016 21:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459311164; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=x3sejg/Pe/0hCvR96SNV8oezpyHHKN0KFFoUnzMpuKI=; b=Ee9jr8rQT3W4OI1rJsQDfp+Jv2Ojt8xX2+5E8IbrsTecQ4kx61qZoKyH5IzuWwko5Pln16HqBrSwscRQG4iHIAFay7KiO+MTg4LlYRjyEQVHVk6L9buIPcqs92cbkouu1u9NK5QcgnrvQjhXLtxzx44ITDuVXxC+kijwta6e9QI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R151e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03312; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_----4elEBOr_1459311159; Received: from 10.62.54.107(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Mar 2016 12:12:42 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Wed, 30 Mar 2016 12:12:37 +0800 From: "Dacheng Zhang" To: Martin Thomson Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: =?GBK?B?wfW088X0KMX0s8kp?= , tls Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:12:48 -0000 The charging GW will not authenticate the client, it only needs to be informed how the following traffics will be charged, in a trusted way. That is why we will do this work. For secure reasons, we intend to use TLS to secure the traffics to or from our APP. So, we need to provide such information in some way to the charging GW of ISP. =D4=DA 16-3-30 =CF=C2=CE=E712:06=A3=AC "Martin Thomson" =D0=B4=C8=EB: >On 30 March 2016 at 15:04, Dacheng Zhang >wrote: >> Dacheng=A3=BALet assume we trust the device. But the APP use a SNI to >>indicate >> the service that the APP intends to access. Because the SNI is static >>which >> may not be changed for months, it is easier for attackers who monitor >>the >> network to get the SNI and use it to gain benefit. We need a securer >> solution. As I have mentioned in my previous email, this solution will >>make >> such attacks more difficult. By the way, SNI is not designed for this >> purpose, we need to do some additional work to address this issue, >>right? > > >What is wrong with client authentication? From nobody Tue Mar 29 21:17:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978F712DCAF for ; Tue, 29 Mar 2016 21:17:04 -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 hqQ9lQhgSzi3 for ; Tue, 29 Mar 2016 21:17:02 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 A782012DCF0 for ; Tue, 29 Mar 2016 21:17:01 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id 4so31597731pfd.0 for ; Tue, 29 Mar 2016 21:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=1cQcKBGmJgg6lVSD+T9j8tRTiDH6hzV+z96H0EGMMKI=; b=GLcV+odiwGFKeWU5YmAvJOoXhadq6pJOg5KToJcWImnrPLWfUU4bUwBgwBuTigw65c lbytbUvcts72inYB+prRRzQCiNDANMlVWdwDyqVB1DHYjWM9v2ZEVobQpgrD11UWLCSd lwfyyY8XrhFin7i+PsPL6RTQ8JZdUmy+6qztWsQGpnrIpUMBkRc2ttMqdAW3IIeape/R mvp8GXAP/Z55ffUo1O6gw4/QSFDslVYqYGK5hGGZWTzbBkzfwZ/M/oExoU6W0zGIUXkW L+4RjYrBXmgKG2YJ7CrDVviFtcBxMfD/6hdS4/u7KhRKeUTghCfVrHiBJ+x0LkJKD3er PUOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=1cQcKBGmJgg6lVSD+T9j8tRTiDH6hzV+z96H0EGMMKI=; b=QjvITlglfqgrw6Jcwh+GMscNgybsGz+ZsNZrZZORGA5NipWfigKZvSTcZhYayYxmGa 71KfY2DY7YiNTubkQNJxdPqESB16C6sIooOlzzQymTQ2o8L5baQF5KGzpOy+xG45O5y0 zbyN3VvqvHeNE4WGcAXAzTqK5spodXR09VrQMsxnCum8EZERPvwwMOpRG4c1cyquqAkj 6N4Db0uVm/iBbrEasAs9zZFofEq4iEtsTpY4tK9dTgkFON98DySNVJtB9KpRMBiHYhme mmk2HGKs9IjSLCTOx3cG3ZOaZ1fLGw4mzYzrxWF3COGA8fVopbsLX9yDqe5rvGrYh8ro NWiw== X-Gm-Message-State: AD7BkJI+mj6XTRCMTMNe8TQGwoFBh5AvWSmyZHyaJRrRJFKiV1H3PRW45I6LipipSld2ts3Fo0ofDmepUKYBkQ== MIME-Version: 1.0 X-Received: by 10.98.71.92 with SMTP id u89mr9487208pfa.100.1459311421244; Tue, 29 Mar 2016 21:17:01 -0700 (PDT) Received: by 10.66.83.229 with HTTP; Tue, 29 Mar 2016 21:17:01 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> Date: Tue, 29 Mar 2016 21:17:01 -0700 Message-ID: From: Peter Bowen To: Dacheng Zhang Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= , tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:17:04 -0000 It doesn't seem to be clearly spelled out: is the "charging GW" a system that can read data passing between the client and server but cannot modify it? If so, do I have it right that you are trying to design an extension that allows the client to send a message that can be observed but not tampered? On Tue, Mar 29, 2016 at 9:12 PM, Dacheng Zhang wrote: > The charging GW will not authenticate the client, it only needs to be > informed how the following traffics will be charged, in a trusted way. > That is why we will do this work. For secure reasons, we intend to use TL= S > to secure the traffics to or from our APP. So, we need to provide such > information in some way to the charging GW of ISP. > > =E5=9C=A8 16-3-30 =E4=B8=8B=E5=8D=8812:06=EF=BC=8C "Martin Thomson" =E5=86=99=E5=85=A5: > >>On 30 March 2016 at 15:04, Dacheng Zhang >>wrote: >>> Dacheng=EF=BC=9ALet assume we trust the device. But the APP use a SNI t= o >>>indicate >>> the service that the APP intends to access. Because the SNI is static >>>which >>> may not be changed for months, it is easier for attackers who monitor >>>the >>> network to get the SNI and use it to gain benefit. We need a securer >>> solution. As I have mentioned in my previous email, this solution will >>>make >>> such attacks more difficult. By the way, SNI is not designed for this >>> purpose, we need to do some additional work to address this issue, >>>right? >> >> >>What is wrong with client authentication? > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 29 21:17:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874FA12DCF5 for ; Tue, 29 Mar 2016 21:17:11 -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 y-_-pV4knwa4 for ; Tue, 29 Mar 2016 21:17:06 -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 C1AD912DCF0 for ; Tue, 29 Mar 2016 21:17:06 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id a129so49138036ioe.0 for ; Tue, 29 Mar 2016 21:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fgcXI0M64PHdRiCLn1igQeOrwJucPGjPvf15jIcUlko=; b=PY33dEbd7/qPbi1JVTS1wqkuj6P2PT6CCgqOZNfY0bnWdmcyHinQInBjw+g7127y6f d5UQN/LDeglJORUyMoeVIbbO8qcPS1sVImjfSoBbsPE2T8QeAKdBNX8SqQsdnxTwLxcx VZc848O+QOBltwf/vu6Uve9Ck90gZ5TMWAs0d7PgApePeNTRInJ6v+g3hyAwhDaW4yBI ZkqvvHISXh7sNNMi1GUKiPfXE/ZGRl07mldVT4aZzFnrvo500Ss68FQIsqgrcRlzCh8n Vj04l+UNKnH29EqXFAnZ+9BLO8Mz5pcnwcB1Xv7N1wi6EZIOkh4eaezFM1CLuoG1pXJF qgaw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fgcXI0M64PHdRiCLn1igQeOrwJucPGjPvf15jIcUlko=; b=B67fTpEzINw6dvJP2vDhD5DWmRTDyAsGB9klphDAxt3fAarRlM+VY/Z2dHgn1dzB+G JLD6lpEX9wm3TldviGI/Hh+Q57ac8V7Zp/chGCnq6sM2JvoXFza41piYLU7cuK+wnKN7 nrl0G63fb3IEhwXjKipe9VDIbSikpUZGTCB599bj/zlny8RFvVdqTSUjaqACAhoxL8dP JngUDXiOiGFKoDn04j+eAaSJKntj9sIxCEqYurHmn8L4SLmO1xfc9giZYRcswzlEMMP0 VUKIaL+nwOvBwCZVMx/mHAog5FMZo4jvaP4GCWw0XUIr/eHFrpWV9lo4DZeK0R4Xdxz7 7MBA== X-Gm-Message-State: AD7BkJK5BGX9F6So//jGbTO/3M7xed9CaVG2GSWrEwMOsBwXHdv0VY9lwgJsg0x6aKURK1bT4WffyVr/8EtMzA== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr7191061ioe.190.1459311426188; Tue, 29 Mar 2016 21:17:06 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Tue, 29 Mar 2016 21:17:06 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> Date: Wed, 30 Mar 2016 15:17:06 +1100 Message-ID: From: Martin Thomson To: Dacheng Zhang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= , tls Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:17:11 -0000 On 30 March 2016 at 15:12, Dacheng Zhang wrote: > The charging GW will not authenticate the client, it only needs to be > informed how the following traffics will be charged, in a trusted way. We've seen this request before. It's not an easy question to answer. In short, you want to make information about a flow (meta-information) available to on-path intermediaries. I believe that there is work ongoing in this area. draft-you-tsvwg-latency-loss-tradeoff, see https://mailarchive.ietf.org/arch/msg/accord/Jsbz-Iatb3WJTuFuvOzkdRrK-uI And the upcoming accord BOF. From nobody Tue Mar 29 21:27:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD26E12DCAF for ; Tue, 29 Mar 2016 21:27:40 -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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGauIHtIhtAS for ; Tue, 29 Mar 2016 21:27:38 -0700 (PDT) Received: from out4133-82.mail.aliyun.com (out4133-82.mail.aliyun.com [42.120.133.82]) by ietfa.amsl.com (Postfix) with ESMTP id C384C12D0A9 for ; Tue, 29 Mar 2016 21:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459312056; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=OwDRHgZ7/4f4qWSyZF7ZPpqiz2GjOBn6q4JgHGvnk+g=; b=eG7vC413wVp3/6TTbAsy6A0UaUCnNNfuQBbwOfj82mXe+RSfVuc0LQuJz6H2Um2F1hJtwdcWCSLIUDDGqHK1BhV0ica2D1WkA0Z2w/E6IDud92RWFTreZ9yifjfwsE5TdWR0OTczQLA9YeG/sMXei3kb02cxDfAng3eqzoRIBSw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03310; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_----4elI.Zx_1459312050; Received: from 10.62.54.107(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Mar 2016 12:27:34 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Wed, 30 Mar 2016 12:27:29 +0800 From: "Dacheng Zhang" To: Martin Thomson Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: =?GBK?B?wfW088X0KMX0s8kp?= , tls Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:27:41 -0000 Hi, Martin: We are following the progress of that work. But in principle, any extension to TLS should be done in this group, that is why we raised the discussion in the TLS list. ^_^ Cheers Dacheng =D4=DA 16-3-30 =CF=C2=CE=E712:17=A3=AC "Martin Thomson" =D0=B4=C8=EB: >On 30 March 2016 at 15:12, Dacheng Zhang >wrote: >> The charging GW will not authenticate the client, it only needs to be >> informed how the following traffics will be charged, in a trusted way. > > >We've seen this request before. It's not an easy question to answer. > >In short, you want to make information about a flow (meta-information) >available to on-path intermediaries. > >I believe that there is work ongoing in this area. > >draft-you-tsvwg-latency-loss-tradeoff, see >https://mailarchive.ietf.org/arch/msg/accord/Jsbz-Iatb3WJTuFuvOzkdRrK-uI > >And the upcoming accord BOF. From nobody Tue Mar 29 22:06:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E170312DD02 for ; Tue, 29 Mar 2016 22:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 5HDjngqF0K83 for ; Tue, 29 Mar 2016 22:06:17 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 7683F12D19A for ; Tue, 29 Mar 2016 22:06:17 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 749E942371E; Wed, 30 Mar 2016 05:06:16 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5EBC3423707; Wed, 30 Mar 2016 05:06:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459314376; bh=q3VH4uNoNnaE+6XVAXZ1o8P7pUzYDImbPXjSYzUxVBI=; l=34; h=From:To:Date:References:In-Reply-To:From; b=ISBV5eEuu/Nk07PE16HCwi2QNJictxMmPl3yUca0c83T2pieQxjaQveUGPAis4etM mBngMXg8i+4pBPqGxsjjC7rIgZcIwk0TN+B2fz+2rudrU/8tNyO1kRUNhtTXPoTDZW 8Mcy3ghdIIERlQIbQm9OjM+achK6bTSHQyFMat7o= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 5C0531FC88; Wed, 30 Mar 2016 05:06:16 +0000 (GMT) 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.1130.7; Wed, 30 Mar 2016 01:06:15 -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.1130.005; Wed, 30 Mar 2016 01:06:15 -0400 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRiibxXcCY6Z2h2UmtDPejo+Tixp9xb3IQ Date: Wed, 30 Mar 2016 05:06:15 +0000 Message-ID: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> 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.114.157] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:06:19 -0000 U3Ryb25nbHkgc3VwcG9ydCB0aGlzLg0K From nobody Tue Mar 29 22:14:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0EE12D978 for ; Tue, 29 Mar 2016 22:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtsAV2gXDPIh for ; Tue, 29 Mar 2016 22:14:42 -0700 (PDT) Received: from out4133-98.mail.aliyun.com (out4133-98.mail.aliyun.com [42.120.133.98]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEC512D0F6 for ; Tue, 29 Mar 2016 22:14:42 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R141e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03281; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=4; SR=0; TI=SMTPD_----4ehOOvt_1459314873; Received: from 10.62.54.107(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Wed, 30 Mar 2016 13:14:39 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Wed, 30 Mar 2016 13:14:31 +0800 From: "Dacheng Zhang" To: Peter Bowen Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Archived-At: Cc: =?GBK?B?wfW088X0KMX0s8kp?= , tls Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:14:44 -0000 =D4=DA 16-3-30 =CF=C2=CE=E712:17=A3=AC "Peter Bowen" =D0=B4=C8=EB: >It doesn't seem to be clearly spelled out: is the "charging GW" a >system that can read data passing between the client and server but >cannot modify it? If so, do I have it right that you are trying to >design an extension that allows the client to send a message that can >be observed but not tampered? We translate that term from Chinese directly, and sorry for the confusion caused. You are right, we trying to do this work in a standard way. There could be hundreds of millions APP in use. The solution should be scalable and light weight. Cheers Dacheng > >On Tue, Mar 29, 2016 at 9:12 PM, Dacheng Zhang > wrote: >> The charging GW will not authenticate the client, it only needs to be >> informed how the following traffics will be charged, in a trusted way. >> That is why we will do this work. For secure reasons, we intend to use >>TLS >> to secure the traffics to or from our APP. So, we need to provide such >> information in some way to the charging GW of ISP. >> >> =D4=DA 16-3-30 =CF=C2=CE=E712:06=A3=AC "Martin Thomson" =D0=B4=C8=EB: >> >>>On 30 March 2016 at 15:04, Dacheng Zhang >>>wrote: >>>> Dacheng=A3=BALet assume we trust the device. But the APP use a SNI to >>>>indicate >>>> the service that the APP intends to access. Because the SNI is static >>>>which >>>> may not be changed for months, it is easier for attackers who monitor >>>>the >>>> network to get the SNI and use it to gain benefit. We need a securer >>>> solution. As I have mentioned in my previous email, this solution will >>>>make >>>> such attacks more difficult. By the way, SNI is not designed for this >>>> purpose, we need to do some additional work to address this issue, >>>>right? >>> >>> >>>What is wrong with client authentication? >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 29 22:16:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401B312D978 for ; Tue, 29 Mar 2016 22:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 wVlJGsNpG6x7 for ; Tue, 29 Mar 2016 22:15:57 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBD12D0F6 for ; Tue, 29 Mar 2016 22:15:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1F42B28D7; Wed, 30 Mar 2016 08:15:55 +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 muw3SWlbeYjh; Wed, 30 Mar 2016 08:15:54 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A21142310; Wed, 30 Mar 2016 08:15:54 +0300 (EEST) Date: Wed, 30 Mar 2016 08:15:54 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160330051554.GA28336@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:15:59 -0000 On Wed, Mar 30, 2016 at 12:52:23PM +1100, Martin Thomson wrote: > On 30 March 2016 at 12:49, Colm MacCárthaigh wrote: > > But isn't that too late? If you have to wait for the client finished message > > before you can even decrypt the 0RTT section; what's the benefit? it's not > > "0RTT" any more. > > There is a Finished message in the client's first flight. It's before > the early data. Only if using 0-RTT auth, which seems is going to be removed (yay). However, one still can't tamper with timestamp in ClientHello: The ClientHello affects the 0-RTT encryption keys and 0-RTT decrypt failure (as opposed to not being able to derive 0-RTT keys) is a fatal error (no fallback). -Ilari From nobody Tue Mar 29 22:18:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F1612D978 for ; Tue, 29 Mar 2016 22:18:49 -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 gkQHUuhe5pWt for ; Tue, 29 Mar 2016 22:18:48 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B3612D198 for ; Tue, 29 Mar 2016 22:18:47 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id q128so51731164iof.3 for ; Tue, 29 Mar 2016 22:18:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kRwqS8sYce/8a10SfsN+EtMD3ZbP5Poq8X4PfrADCmU=; b=B7KP+yMc0PAzY6G8iE6YdyLWfm7C9L2GS6hHuI2YKIOFHft1WQjFEDuOf9jZCElefv dqQZv2ZLyZaKquAI4BVXMy/vzOy5zSS0LxVczAgzROrLpmD+2ie1JDak3tww20tLcWlo vMbNC0W9Hg6VtoYWCiZV2Y/n5qLrVxfZYC89dYfVYbHEUFSOrspwGYF+9dl02dJMHjUS pq/gDKL18PL/IIqQZKkiuYWvy9dsGGAuM2W5G1MfDHMa/bcWwleouJDF2spxdjgBmDTF emPFXj5m1D1e0znG08M3QiGoofP/7yBr/Cpf149SEHRI4iuAAC0EMq+cbhf22l0H07sJ 62QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kRwqS8sYce/8a10SfsN+EtMD3ZbP5Poq8X4PfrADCmU=; b=GtaSxSp/Qsqso/vvSmLC9IMKm1Ks2/COep/nBCdGK6mMey0AXC6GK4u2HihPFP3viB 5hDlpiWfvsmRTB3eNO7wF8+w7+tGC12XnHOE124ulWZ8BVUNg7+jtfoEhNxHDKkIq+ZG Y40gNOfXKFyYiyscwpPBvYvJNOK4U0UVc1nY6ZGtMILf9s3TEjQpd+RQmOpOzRD/Oxwp CxrjdeSk/cLRs7ObMx4wqHkTCcm1QNE1f6Q6o1v4HWB4dK0sDDhXVyOw5PPKMYoFcfQe hhjqV6JbsG60T7EMAyxRA0b8EyyAKHLu1W4sMoO+D6ee8dJ52WgFMi35dXMGOiFZZI5A VnsQ== X-Gm-Message-State: AD7BkJK5aBrY+vNslIot6lvOUfN4Mne+/Y5E22vWBky3IJ3fThYjpXZYE6AxAdYg1ZFxu5bqDg3+RmgVMH3NuA== X-Received: by 10.107.164.84 with SMTP id n81mr7161972ioe.25.1459315127307; Tue, 29 Mar 2016 22:18:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.132.4 with HTTP; Tue, 29 Mar 2016 22:18:27 -0700 (PDT) In-Reply-To: References: <7B4301E9-0282-47A3-8824-5ACC2C61910F@gmail.com> <535576C4-F808-4937-946C-B53661F0645D@gmail.com> From: Tony Arcieri Date: Tue, 29 Mar 2016 22:18:27 -0700 Message-ID: To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a11421b9ec7be8c052f3d4793 Archived-At: Cc: "karthik@messengeruser.com" , "tls@ietf.org" Subject: Re: [TLS] Resumption and Forward Secrecy, 0-RTT and Safety X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:18:49 -0000 --001a11421b9ec7be8c052f3d4793 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Mar 28, 2016 at 3:49 PM, Ryan Hamilton wrote: > =E2=80=8BWe (Chrome) definitely want this (sending cookies in 0-RTT reque= sts), and > are doing this today with QUIC (which we can't wait to TLS 1.3-ify). =E2= =80=8B > I went to RealWorldCrypto 2016 and saw the TLS track and all of the analysis TLS 1.3 has received, and while it wasn't TRON, I can sympathize with why you might want TLS 1.3, namely the extensive analysis it is receiving as an up and coming cryptographic standard which is a clear choice for academic researchers to focus on. That said, I really don't understand Google's excitement to switch from QUIC's crypto to TLS 1.3. QUIC crypto seems like a much simpler and cleaner protocol which fulfills many of the same goals as TLS, and while it hasn't received as much scrutiny as TLS 1.3, it seems like it doesn't need as much by design due to its relative simplicity. I also understand Facebook is adding QUIC-crypto-over-TCP support to proxygen (there was also a talk at RWC2016) for use in their mobile apps as a stopgap for doing 0-RTT until such a time as 0-RTT ships in TLS 1.3. Can you speak to specific reasons why the Chrome team "can't wait to TLS 1.3-ify" over QUIC, specifically reasons different from the ones I have already highlighted above? --=20 Tony Arcieri --001a11421b9ec7be8c052f3d4793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Mar 28, 2016 at 3:49 PM, Ryan Hamilton <rch@google.com> wro= te:
=E2=80= =8BWe (Chrome) definitely want this (sending cookies in 0-RTT requests), an= d are doing this today with QUIC (which we can't wait to TLS 1.3-ify). = =E2=80=8B

I went to RealW= orldCrypto 2016 and saw the TLS track and all of the analysis TLS 1.3 has r= eceived, and while it wasn't TRON, I can sympathize with why you might = want TLS 1.3, namely the extensive analysis it is receiving as an up and co= ming cryptographic standard which is a clear choice for academic researcher= s to focus on.

That said, I really don't under= stand Google's excitement to switch from QUIC's crypto to TLS 1.3. = QUIC crypto seems like a much simpler and cleaner protocol which fulfills m= any of the same goals as TLS, and while it hasn't received as much scru= tiny as TLS 1.3, it seems like it doesn't need as much by design due to= its relative simplicity.

I also understand Facebo= ok is adding QUIC-crypto-over-TCP support to proxygen (there was also a tal= k at RWC2016) for use in their mobile apps as a stopgap for doing 0-RTT unt= il such a time as 0-RTT ships in TLS 1.3.

Can you = speak to specific reasons why the Chrome team "can't wait to TLS 1= .3-ify" over QUIC, specifically reasons different from the ones I have= already highlighted above?

--
Tony Arcieri
--001a11421b9ec7be8c052f3d4793-- From nobody Tue Mar 29 22:29:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3233212D1BE for ; Tue, 29 Mar 2016 22:29: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, 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 rMweP9Ibkwjh for ; Tue, 29 Mar 2016 22:29:47 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 102BE12D0AE for ; Tue, 29 Mar 2016 22:29:47 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id p65so166732113wmp.1 for ; Tue, 29 Mar 2016 22:29:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DhdkD0m4CT18jWDPNXab5yQZlba4O7DSB0gF5Bq8948=; b=WsFd4P7jmilHQfjwWoYN4Es/m8P6QlmRSZU4NBjoKOANt/TMh18P5n8yhnawlkFdN0 bL09pvKKr0aS0PzqrxeSfcr9n8DgwC7JxOf9nUj/vsrjQhM0YZWBGOb7/2DrWgMrkHBN RhPtT3FqfyqqgAyeygEOHVKc+72iAx1pluZ+OM+a3Fu/J0HPi6iJkN+gSo5p+LutFHsH mdvWsQVdmKAs48KOFIhhe1Yov1mhf/PCHIO5rp+UilEEScCxuf5Vq1G5QW2zFLYBEQeP pf35cEIzR27fjMWCYuVS/Bcu8BC07GB9wfITrOG24cIKLZ+cSfSsqG8aBNYI+LDMHvx9 R+mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DhdkD0m4CT18jWDPNXab5yQZlba4O7DSB0gF5Bq8948=; b=EwwTjico7EtcYmc9ZIWumwfVfcDhIEvuUwnbq13RmnvqFY9SK5F6NZXduF1z+UfCLk lxoqlYWAJpzc5A/U0MpV2bXzduB1Zi8icflJGwq4ACAUyQEvzQ/N+51CUmq+CcopEGkD IhI6YWr0mWwE2zoqkpHf8ka2UuueC42PVVWISB4QyrbS1LSbUtd5x/duyl7eocwMDv6X E8UWBJ5WEgAtvO16nfn/RRnBWgfQk5lg8PK7KtJdrFImuZ1VztNkBEkVofRyCSDPWrJZ x3AQrY2hbFiF192tLQISFTVUssN5WBDXy1RTuLVT/TOaXqYDq36j5y1Viz0noFsGnN5M ShcQ== X-Gm-Message-State: AD7BkJLksInTI1qCprC5xt9TGjD9J9itlp/XV+WjYQ2y/5itNvx0ISrpzcSeK770SQVSyQ== X-Received: by 10.28.145.196 with SMTP id t187mr7308927wmd.81.1459315785590; Tue, 29 Mar 2016 22:29:45 -0700 (PDT) Received: from [192.168.137.59] ([109.253.199.81]) by smtp.gmail.com with ESMTPSA id da6sm1969162wjb.24.2016.03.29.22.29.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 29 Mar 2016 22:29:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Date: Wed, 30 Mar 2016 08:29:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <3F32A6CE-DE7F-4230-8077-AE2CC1161235@gmail.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:29:50 -0000 Hi Sean I also strongly support this. I=E2=80=99m just wondering how we plan to = enforce the "stable, publicly available, peer reviewed reference=E2=80=9D = part. As your examples below show, the reference tends to be an I-D. = That=E2=80=99s stable and publicly available, but we have no idea if = it=E2=80=99s peer reviewed or who the author=E2=80=99s peers are. One other thing, in some of the links you pasted below you give a = specific draft version (like = https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while = for the others you give the generic version (like = https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/). The former is = stable but the latter is not. Are the authors free to keep modifying the = specification after getting the code point? Yoav > On 30 Mar 2016, at 4:53 AM, Sean Turner wrote: >=20 > Hi! >=20 > In Yokohama, we discussed changing the IANA registry assignment rules = for cipher suites to allow anyone with a stable, publicly available, = peer reviewed reference document to request and get a code point and to = add an =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This = change is motivated by the large # of requests received for code points = [0], the need to alter the incorrect perception that getting a code = point somehow legitimizes the suite/algorithm, and to help implementers = out. We need to determine whether we have consensus on this plan, which = follows: >=20 > 1. The IANA registry rules for the TLS cipher suite registry [1] will = be changed to specification required. >=20 > 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with = two values: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D. Y and N have = the following meaning: >=20 > Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus = on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but = can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. >=20 > 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to = those who don=E2=80=99t read the IANA considerations section of the RFC. >=20 > Please indicate whether or not you could support this plan. >=20 > Thanks, >=20 > J&S >=20 > [0] In the last year, the chairs have received requests for: >=20 > PSK: = https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: = https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: = https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. >=20 > [1] = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Mar 29 23:23:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ED412DCE5 for ; Tue, 29 Mar 2016 23:23:31 -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 JD9o4MlYT1NV for ; Tue, 29 Mar 2016 23:23:29 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id A041812DC73 for ; Tue, 29 Mar 2016 23:23:29 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id D7857F997; Wed, 30 Mar 2016 02:23:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 353DA21040; Wed, 30 Mar 2016 02:23:27 -0400 (EDT) From: Daniel Kahn Gillmor To: Sean Turner , "\" In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 30 Mar 2016 02:23:27 -0400 Message-ID: <87d1qczdpc.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 06:23:31 -0000 On Tue 2016-03-29 21:53:13 -0400, Sean Turner wrote: > 1. The IANA registry rules for the TLS cipher suite registry [1] will be changed to specification required. > > 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”. Y and N have the following meaning: > > Cipher suites marked with a “Y” the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > “N”. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that matches the above so that the same information is available to those who don’t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. I support this plan. --dkg From nobody Wed Mar 30 02:35:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AF512E08F for ; Wed, 30 Mar 2016 02:35:34 -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 HSqCo5TCBIKq for ; Wed, 30 Mar 2016 02:35:32 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 719B112E07B for ; Wed, 30 Mar 2016 02:35:32 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g185so59255194ioa.2 for ; Wed, 30 Mar 2016 02:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=E7WvT8Ea6xDxV8w+tuY/8kHAqzF07eYKIxYRpPotIKQ=; b=owZ/we4PIZXhD+UX+anwTziIz3DANEcY+6ByrG9AVD3AoJhNBrgaA4yS2oQH+ZeOY6 j+5/d7vsAuv913liqKboFpzaN4f5tsPLm7crS7kGOFYH27zw0QTau3xTpe038tS9VRtk i0s53kpvHqlXhutxrJuegqI5UrsiIWZYLqbDm83VbiDvP5J2BJwK4d4EjQbE+D2jRazD BwWFQHcElJ9g49V/LwNWpbyPqVS9N2OaDeZChPZ8OnaFPCOPSXAJuw0B3sz1BG3yBYTi VXQqmZIFpgo06h+xQkSbftlcgT47w5HUfZRGyDQvxBbN7CU/jhUzXb+AWbGKy+rOXkKQ 34BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=E7WvT8Ea6xDxV8w+tuY/8kHAqzF07eYKIxYRpPotIKQ=; b=guj+xsj3lnX8U1PvGKLG4O+6Haj8HljfSctqpK+dwY48vC1x8VHIjp5H8qGZX/NyF2 BLyuh6N9sm+PuCcmmlFfEb4+2b8UwvU98Hipzu4CG1UCqXV5h7w2pLAUab0Z/31cz9lO C0UpC3MD7Ocl9URXg/LzxjwKcdnlleu3GumiXdxjegb9a1fGfR3K3TBlmOK7mnQV5mxA pto3Nrwzx23FAfpryancQuixcgPqdaf/oPScrZ801C4ifSYsyywHXnEOJapAI/Dh9Chp q4tvUhnddapv+4IT8p6RT10EIxRSwhEEvQgq5N6ZFiKsH9HB9FRw+FvnfleD7N4S8kVZ r+XA== X-Gm-Message-State: AD7BkJKaM4/4jKJdf5aJFUEv96b1fSIMGxSojBSQJLxUG8FQAilWBxxhhYXG7TihrXxxvmpgVdEr8mU6Oa7Tdw== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr8407884ioe.190.1459330531902; Wed, 30 Mar 2016 02:35:31 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 02:35:31 -0700 (PDT) In-Reply-To: <20160330051554.GA28336@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160330051554.GA28336@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 30 Mar 2016 20:35:31 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:35:34 -0000 On 30 March 2016 at 16:15, Ilari Liusvaara wrote: > Only if using 0-RTT auth, which seems is going to be removed (yay). My reading is that Finished is always present. That is, the authentication messages are always sent, with Certificate+CertificateVerify being omitted if there is no certificate. From nobody Wed Mar 30 02:47:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D9312D5AB for ; Wed, 30 Mar 2016 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 QIkjhoS05liM for ; Wed, 30 Mar 2016 02:47:01 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 DDC6012D5A1 for ; Wed, 30 Mar 2016 02:46:56 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id e6so53497620vkh.2 for ; Wed, 30 Mar 2016 02:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=BmqbJBhqhD5iYkjyGovgc7wXTyHcHpmL9z56AdBW5S0=; b=c7uHWcWtihuu5QzfNfvHX85CrteB/8gZ0PiGl/n3heGQIYNHixvyXkfZWOSHowcIbv Jr5LQMavivMYpdWzrBdy2law0N3B4+X/yC3GJF9piMwendD0cEEcQjoav7KvB7rH8cST I1wP0/Zb4jDXGKBwiqCtCSHEgKp5rG2o6vC4ZVivqANo5CFYgTqS20KIHn4Xicp5QQ7W en4J8jfSEcCjp4Jq5kuXp1WsREjATyJGOndBhGpgO+pyNHwtGm1WdvAI2RqANEv7r7nd pLuWBz2giXBY/voRbNHvD9xZH2Ki92nozRmCOsRxJlkBi1mNGs9jOvvCYBLrqheO8Sh3 KlBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=BmqbJBhqhD5iYkjyGovgc7wXTyHcHpmL9z56AdBW5S0=; b=IFS9krO4adXmv5dT2kOW9er5QU6uKQGdGEbcJpgrDDs8OTQSWlcre3HfstDgldX75t jnLPZYPtkppUDaMT+/XgfC0XKUW4uHlFtnQwWqFs+aAKHXP5deGsfhVqxLJBu4YoM9LM vxOiz4VEjOUu03eY6PTSROPQ44LiWEel7gVxixCOsS09F1Hq1HlnJ4ez8cHT4lPU8W+p kI4dnjj3JSBUQx5Uj1+/ttwCA/5mEeAA+oEuFcizKFCsDY9V4X5xBeM/Uhp/XFYJOgbC sybe7BF38oNcXul2ISUpC1404BSMK9Qge1QhM7bdGjE5BHbUZLBzR5rWgygAevp3bWma 3M3g== X-Gm-Message-State: AD7BkJLohetPViWyYhE0ENRSd1qP+kuckSWOYXidrvO4sAFc4IpIkuZjK1I4MDtZH+EGrcbjB49YtZHcozUsHF2l MIME-Version: 1.0 X-Received: by 10.159.37.104 with SMTP id 95mr4388736uaz.85.1459331215675; Wed, 30 Mar 2016 02:46:55 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 30 Mar 2016 02:46:55 -0700 (PDT) Date: Wed, 30 Mar 2016 02:46:55 -0700 Message-ID: From: Bill Cox To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c123022b8af07052f4106f2 Archived-At: Subject: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 09:47:03 -0000 --94eb2c123022b8af07052f4106f2 Content-Type: text/plain; charset=UTF-8 IIRC, TLS 1.3 will not offer big companies the ability to create short-lived sub-certificates specific to remote satellite locations. This forces companies to choose between good physical security for their signing certs, or having fast connection times. Am I recalling correctly that TLS 1.3 has this problem? I thought we fixed this in QUIC crypto. Thanks, Bill --94eb2c123022b8af07052f4106f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
IIRC, TLS 1.3 will not offer big companies the ability to = create short-lived sub-certificates specific to remote satellite locations.= =C2=A0 This forces companies to choose between good physical security for t= heir signing certs, or having fast connection times.=C2=A0 Am I recalling c= orrectly that TLS 1.3 has this problem?=C2=A0 I thought we fixed this in QU= IC crypto.

Thanks,
Bill
--94eb2c123022b8af07052f4106f2-- From nobody Wed Mar 30 04:28:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608BA12D1D9 for ; Wed, 30 Mar 2016 04:28:02 -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, 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 FvO9sjrK_Y7q for ; Wed, 30 Mar 2016 04:28:00 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::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 89D8612D640 for ; Wed, 30 Mar 2016 04:27:59 -0700 (PDT) Received: by mail-lb0-x229.google.com with SMTP id u8so29613333lbk.0 for ; Wed, 30 Mar 2016 04:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=4ryGt/1x+cCtW9l7dLHhldKM9B5xjJ58Sdi3AW8iEf8=; b=i6XnrzyiiGBtl1B375OZBVgRjOB6oQjISI59A+pVxx3fWkTOAGQq7i1kf2nbUmiBVr 3qVwUmwgufpVzCGrxqMYquTLm/f56VxUMVcjOwtR8o7A8XL8xa2F8X5B2u09J8iRdteZ xHCMR+5qjAIUhuuWjfbmLUIuE7QO5Q1m15DZexbIJuL8IxbSEsG8B9rq2By//42BOrzq S+0t+I2QaO9oWPcM/YI+gt32OToGMketlXwuHR6L1lGgdH53pg3W8f77z+zrv1eNt72I KNrJst11RA88lbijYZbWKqnqZqSOQmjSAqFNOByIxL2rVAloGy4Td4hSUgcAIECnLfAd vKYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=4ryGt/1x+cCtW9l7dLHhldKM9B5xjJ58Sdi3AW8iEf8=; b=N+9+blBnQsV6Nf0pj/M1zjIdE66g0VFXwT+rfhuYc6lh9H6FG35H0HMPQQr80NDCJD TAEDOJUwaHy2vsKPiy+7lrHyyC/1UxQf6jowW4PF0YNc0qgV75wz4y/+O+iZ3r49Zggs SFLg4Dw4obZy0xoZ+pitZ4JERfLV+OdgP/Oaui07f4MPvMASKOsh3KN/PZ47w2a5bgq9 Va6vLn0txMx4sGUqhIMSeDjJY6u5IvOXdvWNfXqb25Iy1bXbMALtEJPyv3WNxypuKsM4 BJ79xx+AwYN8BozcGcTdbmG8IdLjrcrtq0DSs7pLoo2rbvGbXLsdaap3bJEMhgULkch9 hSzg== X-Gm-Message-State: AD7BkJI1PZD4+4bHLzzF82/wOu/uttkIk2GVUQ/O/G++JJ64zUE+g2/LEsyoEtSzw72M9+cm4CRFh0z9RV0Xyw== MIME-Version: 1.0 X-Received: by 10.112.54.132 with SMTP id j4mr3640428lbp.3.1459337277779; Wed, 30 Mar 2016 04:27:57 -0700 (PDT) Received: by 10.25.214.195 with HTTP; Wed, 30 Mar 2016 04:27:57 -0700 (PDT) In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Date: Wed, 30 Mar 2016 14:27:57 +0300 Message-ID: From: Dmitry Belyavsky To: Sean Turner Content-Type: multipart/alternative; boundary=001a11c3a9c80cb4bc052f42706c Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 11:28:03 -0000 --001a11c3a9c80cb4bc052f42706c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Sean, I support the plan in general, but I think that we need to separately indicate that a particular algorithm/ciphersuite is not just "Not recommended" but found insecure. Thank you! On Wed, Mar 30, 2016 at 4:53 AM, Sean Turner wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for > cipher suites to allow anyone with a stable, publicly available, peer > reviewed reference document to request and get a code point and to add an > =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This change i= s motivated by the > large # of requests received for code points [0], the need to alter the > incorrect perception that getting a code point somehow legitimizes the > suite/algorithm, and to help implementers out. We need to determine > whether we have consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be > changed to specification required. > > 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with two= values: =E2=80=9CY=E2=80=9D or > =E2=80=9CN=E2=80=9D. Y and N have the following meaning: > > Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus o= n > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but can= ) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on [0]= ) that > matches the above so that the same information is available to those who > don=E2=80=99t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > > Thanks, > > J&S > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-= parameters-4 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 SY, Dmitry Belyavsky --001a11c3a9c80cb4bc052f42706c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Sean,

I support the plan in g= eneral, but I think that we need to separately indicate
that a particul= ar algorithm/ciphersuite is not just "Not recommended" but found = insecure.

Thank you!

=
On Wed, Mar 30, 2016 at 4:53 AM, Sean Turner <sean= @sn3rd.com> wrote:
Hi!

In Yokohama, we discussed changing the IANA registry assignment rules for c= ipher suites to allow anyone with a stable, publicly available, peer review= ed reference document to request and get a code point and to add an =E2=80= =9CIETF Recommended=E2=80=9D column to the registry.=C2=A0 This change is m= otivated by the large # of requests received for code points [0], the need = to alter the incorrect perception that getting a code point somehow legitim= izes the suite/algorithm, and to help implementers out.=C2=A0 We need to de= termine whether we have consensus on this plan, which follows:

1. The IANA registry rules for the TLS cipher suite registry [1] will be ch= anged to specification required.

2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with two v= alues: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D.=C2=A0 Y and N have the f= ollowing meaning:

=C2=A0Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensu= s on
=C2=A0and are reasonably expected to be supported by widely
=C2=A0used implementations such as open-source libraries.=C2=A0 The
=C2=A0IETF takes no position on the cipher suites marked with an
=C2=A0=E2=80=9CN=E2=80=9D.=C2=A0 Not IETF recommended does not necessarily = (but can)
=C2=A0mean that the ciphers are not cryptographically sound (i.e.,
=C2=A0are bad).=C2=A0 Cipher suites can be recategorized from N to Y
=C2=A0(e.g., Curve448) and vice versa.

3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to th= ose who don=E2=80=99t read the IANA considerations section of the RFC.

Please indicate whether or not you could support this plan.

Thanks,

J&S

[0] In the last year, the chairs have received requests for:

PSK: https://datatracker.ietf.org/= doc/draft-mattsson-tls-ecdhe-psk-aead/
AES-OCB: https://www.ietf.org/arc= hive/id/draft-zauner-tls-aes-ocb-03.txt
Kcipher2: https://datatracker.ietf.org/= doc/draft-kiyomoto-kcipher2-tls/
dragonfly: https://datatracker.ietf.org/doc/draf= t-ietf-tls-pwd/
NTRU:=C2=A0 http://www.ietf.org/id/draft-whyte-qs= h-tls12-01.txt
JPAKE: not sure they got around to publishing a draft.

[1] https://www= .iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4<= /a>


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



--
SY, Dmitry Belyavsky
--001a11c3a9c80cb4bc052f42706c-- From nobody Wed Mar 30 04:40:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969FD12D661 for ; Wed, 30 Mar 2016 04:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 A6UMg0wYaxla for ; Wed, 30 Mar 2016 04:40:44 -0700 (PDT) Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id EDFD312D652 for ; Wed, 30 Mar 2016 04:40:42 -0700 (PDT) X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon Mail Gateway) with ESMTP for ; Wed, 30 Mar 2016 13:40:39 +0200 (CEST) Received: from [192.168.0.190] (c-76cbe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.203.118]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 9A93BC93DE for ; Wed, 30 Mar 2016 13:40:39 +0200 (CEST) References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <56FBBB28.4010902@streamsec.se> Date: Wed, 30 Mar 2016 13:40:24 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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 Mar 2016 11:40:46 -0000 On 2016-03-30 13:27, Dmitry Belyavsky wrote: > Dear Sean, > > I support the plan in general, but I think that we need to separately > indicate > that a particular algorithm/ciphersuite is not just "Not recommended" > but found insecure. This does indeed sound reasonable. From nobody Wed Mar 30 08:22:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1C712D760 for ; Wed, 30 Mar 2016 08:22:57 -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 eYtQsoFTh5xH for ; Wed, 30 Mar 2016 08:22:55 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E04012D756 for ; Wed, 30 Mar 2016 08:22:55 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h65so62541670ywe.0 for ; Wed, 30 Mar 2016 08:22:55 -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=TAVmMKffSl1aDyQ7OBWrKSKJ3StjHyQeSNYcmKxmbIQ=; b=NvJpErNsDPQoi7TEfa6v62tKCB/eq5VX3VHH+5dEzhDxKhsyBxKwTKMktidHXn3tSP KfDoY6j7PhQjds5Ix4nk7pySPP8M1A2PkdlXfHBlLtdpE+y+06lVOBptO3BA9oVFwWJv uRlAUPfYPZyQ57CNEN4Krex8/+ulsVsNeioylnRKY9bSHuuqoOU5hJQCqn93KZRg8itH bKt0cimstjCCMNPiMVvRlXyzyJtTCiW6k+j6mOQBWaYPIpVsSu28wYXGEQYzaW6zm6ZH TlLFEBMjb39rwITeQJNa+DX1IBjdDwV/oG3nMkzhxekSOaf09KBGvSji/uNu6yf55O8w qdGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TAVmMKffSl1aDyQ7OBWrKSKJ3StjHyQeSNYcmKxmbIQ=; b=hqmgfKPtOkD5xwBOB3EQm0zhN1YYYNNwiLbMHwOViL/VnjqgtAIEl8SjpibkZn0MWO imZysLWH9C+oHjKZJ2zQV2QbmL9zRKSG2u2ODdeZqFHpcHG1xBgb18LpyF5jNH/uyYA2 tjeYOJhxwRoKiaD9F14GJGcHsSEYFsil13aS/KYOyh37NiMfH3UIyDHfhkOBF/5ulmRY FpOhFJ1SnrAeUZPWJtP+8yXu8nu/df86BLUwFHD3IYY4yoGjbbRfAh6XQtB9vdTj0Sqw KyH6VlkSfx2T63T5+ppxqML3x1tFqbFDhhSmt7T3BOra5oznTbzRQus5RWl0rj0HeDRU fonA== X-Gm-Message-State: AD7BkJLAP3Ljb5MCR4dXxwbjMFrOie1exRdF7iJcFk2vSqtf+ydyOEeseDHbzYkFMbv7zY2jYksJePisyu4qww== X-Received: by 10.129.119.9 with SMTP id s9mr379395ywc.115.1459351374552; Wed, 30 Mar 2016 08:22:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 08:22:15 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 30 Mar 2016 08:22:15 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a1141c59448e3cd052f45b8be Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:22:58 -0000 --001a1141c59448e3cd052f45b8be Content-Type: text/plain; charset=UTF-8 This got a lot of discussion early in the design process and the consensus was that the risk of having the default mode (with existing certs) allow the creation of a long-term delegation was too high. See, for instance, the relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and QUIC. With that said, I think this would be a good feature to look at in future and the right way to do it is to: 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to PKIX. 2. Add a subcert extension to TLS 1.3. Best, -Ekr [0] https://www.nds.rub.de/media/nds/.../2015/08/21/*Tls13Quic*Attacks.pdf On Wed, Mar 30, 2016 at 2:46 AM, Bill Cox wrote: > IIRC, TLS 1.3 will not offer big companies the ability to create > short-lived sub-certificates specific to remote satellite locations. This > forces companies to choose between good physical security for their signing > certs, or having fast connection times. Am I recalling correctly that TLS > 1.3 has this problem? I thought we fixed this in QUIC crypto. > > Thanks, > Bill > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1141c59448e3cd052f45b8be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This got a lot of discussion early in the design process a= nd the consensus
was that the risk of having the default mode (with exi= sting certs) allow the
creation of a long-term delegation was too= high. See, for instance, the
relative impact of the recent paper= by Jager at al. [0] on TLS 1.3 and
QUIC.

With that said, I think this would be a good feature to look at in future=
and the right way to do it is to:

1. Ad= d a "this is only usable for TLS 1.3 [or for subcerts]" extension= to
PKIX.
2. Add a subcert extension to TLS 1.3.
<= div>
Best,
-Ekr
=C2=A0
[0] =C2= =A0https://www.nds.rub.de/media/nds/.../2015/08/21/Tls13Q= uicAttacks.pdf

On Wed, Mar 30, 2016 at 2:46 AM, Bill Cox <= span dir=3D"ltr"><waywardgeek@google.com> wrote:
IIRC, TLS 1.3 will not offer big companies the a= bility to create short-lived sub-certificates specific to remote satellite = locations.=C2=A0 This forces companies to choose between good physical secu= rity for their signing certs, or having fast connection times.=C2=A0 Am I r= ecalling correctly that TLS 1.3 has this problem?=C2=A0 I thought we fixed = this in QUIC crypto.

Thanks,
Bill

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


--001a1141c59448e3cd052f45b8be-- From nobody Wed Mar 30 08:33:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B3112D794 for ; Wed, 30 Mar 2016 08:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 gV1AISi-wEEv for ; Wed, 30 Mar 2016 08:33:12 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E890712D744 for ; Wed, 30 Mar 2016 08:33:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1460F43355C; Wed, 30 Mar 2016 15:33:10 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id EFD6A43354D; Wed, 30 Mar 2016 15:33:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459351989; bh=4qkxIjh74E8j26U62GmIOnX9DDTmxNMY3B+1mwksgE0=; l=2135; h=To:References:From:Date:In-Reply-To:From; b=V6Jv+zGVv1Hk5wB8VMMVWTJrdh0RJZyMNtR4m3JqQGo3hgQY+1puzxUSLr0+tL4Fm YfwUeam7hE0pvTOH9eYfHsNBq5g/0V7wV+wusYEQcEzxMPvxLIhc23SQpOZ6/XxPuy gmSoZyHnrjTWKtvY4rLGkTazl/Ul8xFKHTSjD1gU= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id C4D3E1FC88; Wed, 30 Mar 2016 15:33:09 +0000 (GMT) To: Sean Turner , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> From: Benjamin Kaduk Message-ID: <56FBF1B5.8030906@akamai.com> Date: Wed, 30 Mar 2016 10:33:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:33:18 -0000 On 03/29/2016 08:53 PM, Sean Turner wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for cipher suites to allow anyone with a stable, publicly available, peer reviewed reference document to request and get a code point and to add an “IETF Recommended” column to the registry. This change is motivated by the large # of requests received for code points [0], the need to alter the incorrect perception that getting a code point somehow legitimizes the suite/algorithm, and to help implementers out. We need to determine whether we have consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be changed to specification required. > > 2. A new “IETF Recommended” column will be added with two values: “Y” or “N”. Y and N have the following meaning: > > Cipher suites marked with a “Y” the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > “N”. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a “Note" to the IANA registry itself (i.e., on [0]) that matches the above so that the same information is available to those who don’t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > I support this plan (with the expectation that the IANA "specification required" rules take precedence over the informal text in this mail about a "stable, publicly available, peer reviewed reference document", as Yoav noted as a potential issue). I am not sure that we want to be in the business of explicitly marking things as insecure other than our own RFCs, though -- there could be an implication of more review than is actually the case, which is what this proposal is trying to get rid of. -Ben From nobody Wed Mar 30 08:33:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C7A12D7A4 for ; Wed, 30 Mar 2016 08:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 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] 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 B634dTlOBj5u for ; Wed, 30 Mar 2016 08:33:22 -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 5927812D78D for ; Wed, 30 Mar 2016 08:33:16 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id h65so62931330ywe.0 for ; Wed, 30 Mar 2016 08:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kKCjuBPZqWeYMQBt/Ube+eJhqRFuqZY+1GvTV2ZDTYs=; b=UGgEwcpyZsNz3r29yJlPOjudLY0X60XaQ3dPks94qTlQRFQ3JlJYfrVlo4CFPeRrsY C9DEWjhkRaq80682rMGDacRozndQhAiJ+Z0nlKoZd9wLvu+FNnkaVMmn90Yb8nIQIgsf pVQk9mUiiiXnNQGukH5yPLaOmInkmwjKSl8cERabJDP8cR6H21Sdm80QucS3v/uSqHER gXS+WYMN8oZAMwCqP3c3aqlTVufayyhyZMbDD6/Qz3khB2OKGp9HTDGUTsfR2s+t0DXY XXc9dM3PqMRiVBWDBii4OXvSD+bkbsGi3YJWouTYx40P63/1gvLupZrNKooFNLoufyEn SJgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kKCjuBPZqWeYMQBt/Ube+eJhqRFuqZY+1GvTV2ZDTYs=; b=XGkNQLK5huEKYNJk+l3mZyMV8BrnUwPkDIruSNPc0wYU4HgZkuPzqIFWpTjSYmB8Ja uRzm5GvaOZHpNHEOdKFsxCWPLiqCg8L4eK98gwjPc/E/oQ3zuRq7TeGQH3qYiErV9/x4 NMzSP3BTDM8PstM3ZFg4iIfK/jFA68V+knv12nkhjjsox1n/3gPG3P6N6KCwn1IVSGlF fI4phsy77kK3VHc8SI20j3QQ3YJYx3Fd+RAcDyqTYgQRkEpNruBndKmetu+uw6vXiwXk GZonIMki+aLYWCagqP1L9q6v0xTLLSz+g+qLXa1JREOP/wB6FPSkLvZa84Ks9/Yr6hd/ IbvA== X-Gm-Message-State: AD7BkJKeZybgr8zH634rAc6LhcirNivEBUgjshdeyEAzEh/VUhI501rAncJuIHBUaHGql6f5h5BYlyvSt7uO1w== X-Received: by 10.37.44.85 with SMTP id s82mr4155684ybs.82.1459351995575; Wed, 30 Mar 2016 08:33:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 08:32:36 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> From: Eric Rescorla Date: Wed, 30 Mar 2016 08:32:36 -0700 Message-ID: To: Dacheng Zhang Content-Type: multipart/alternative; boundary=001a114321544ca206052f45dd89 Archived-At: Cc: tls , =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:33:38 -0000 --001a114321544ca206052f45dd89 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 9:04 PM, Dacheng Zhang wrote: > Hi, Erk: > > My reply inline please. > > Cheers > > Dacheng > > =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla > =E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F= =E4=B8=89 =E4=B8=8A=E5=8D=8811:19 > =E8=87=B3: dacheng de > =E6=8A=84=E9=80=81: Eric Mill , Dave Garrett , > tls > =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension= transfering service indication > information > > > > On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang < > dacheng.zdc@alibaba-inc.com> wrote: > >> Hi, Ekr: >> >> Thanks for reviewing the draft and the comments. Please see my reply >> inline please. >> >> =E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla >> =E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C= =9F=E4=B8=89 =E4=B8=8A=E5=8D=887:21 >> =E8=87=B3: dacheng de >> =E6=8A=84=E9=80=81: Eric Mill , Dave Garrett , >> tls >> =E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extensio= n transfering service indication >> information >> >> I have taken an initial look at this document, but I find myself confuse= d >> about the security >> model. >> >> Specifically, you say that you can't use SNI because customers will lie >> and insert >> the SNI for service A in the ClientHello when going to service B. >> However, I don't >> see how this token stops that, since all it represents is a bare >> assertion of where >> you are going that is authenticated with a MAC shared between the client= , >> the >> ICP, and the ISP. What stops the client from doing the same thing, i.e., >> injecting >> the token for service A into a connection destined for service B? B can >> just ignore >> the SI token, right? >> >> Dacheng=EF=BC=9A This is a very good point. How to secure the APPs on th= e client >> device (e.g., How to secure client and prevent the message sent out from= an >> APP provided by ICP A from being intercepted by an APP provided by ICP B >> installed on the same mobile) is a hot topic. Lots of people are >> working hard to address this issue. For instance, TEE is an attempt of >> protecting the security of APPS on a mobile. In a TEE, APPs action are >> controlled and secure channels are provided to distributed keys. So, in = our >> solution, we did not consider the case where the execution environment o= f >> APPs is not secure. We assume if an attacker or a malicious has compromi= se >> a mobile, it could cause more serious damages. >> > > I'm not following. If you trust the device, then why do you need any kind > of cryptographic > authentication on the token. > > Dacheng=EF=BC=9ALet assume we trust the device. But the APP use a SNI to = indicate > the service that the APP intends to access. Because the SNI is static whi= ch > may not be changed for months, it is easier for attackers who monitor the > network to get the SNI and use it to gain benefit. We need a securer > solution. As I have mentioned in my previous email, this solution will ma= ke > such attacks more difficult. By the way, SNI is not designed for this > purpose, we need to do some additional work to address this issue, right? > Again, you need a threat model. It sounds like you both do and do not trust the client > Hmm... I'm not at all sure that TLS should address this problem. However, > my review > was directed to whether your proposed solution even works on its own term= s. > > Dacheng: That is why we need to raise the discussion here. It would be > great if this issue could be considered by TLS WG. > I don't find this to be a very compelling use case and I don't think it's really appropriate to try to solve it at the TLS layer. If you want to have secure flow identification you should do it at the IP or TCP layers. -Ekr > > > > >> We found this issue when we tried to widely use TLS to secure the >> communications between our APPs and our services. If there could be any >> better idea or solution, we will be very happy to support it. >> >> Finally, why am I seeing what appears to be a MAC algorithm definition i= n >> Section >> 2.1. Is there a reason you can't just use/cite HMAC? >> >> Dacheng: I reuse this content from my previous drafts. If people don=E2= =80=99t >> like it, we could remove it. ^_^ >> >> Thanks a lot for your review, and look forward to further discussions on >> this topic. ^_^ >> >> Cheers >> >> Dacheng >> >> -Ekr >> >> >> >> >> >> >> >> >> On Tue, Mar 29, 2016 at 12:48 AM, Dacheng Zhang < >> dacheng.zdc@alibaba-inc.com> wrote: >> >>> Hi, >>> >>> Actually, we refer to the extension as a 'SNI' extension. In this >>> extension, SI(service indication) information is provided. In the next >>> version, we will use 'SI extension' to take place of 'SNI extension'. ^= _^ >>> >>> Cheers >>> >>> Dacheng >>> >>> ------------------------------------------------------------------ >>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garrett >>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=8829= =E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52 >>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill >>> =E6=8A=84 =E9=80=81=EF=BC=9Atls =EF=BC=8C=E5=BC=A0=E5=A4= =A7=E6=88=90(=E6=B7=A1=E4=B9=85) >>> =E4=B8=BB =E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension transfering servi= ce indication information >>> >>> On Tuesday, March 29, 2016 01:35:50 am Eric Mill wrote: >>> >>> > It looks like the abbreviation this draft uses is just "SI". It uses = SNI at >>> >>> > the top a few times to refer to Server Name Indication (which it typo= s as >>> > "service" name extension). >>> > >>> > On Tue, Mar 29, 2016 at 1:13 AM, Dave Garrett >> > wrote: >>> > > On Monday, March 28, 2016 09:50:13 pm Dacheng Zhang wrote: >>> > > >>> https://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-ext= ension/ >>> > > >>> >>> > > You really should not use SNI as your abbreviation, as it will just= be >>> >>> > > frequently confused with the server_name extension which is already= the >>> > > dominant use of those initials in TLS. >>> >>> >>> You're correct; my mistake. I didn't notice the typo and reading a spec= draft whilst tired is not always the best of ideas. ;) >>> >>> >>> CCing back to list and thread starter to make sure my correction is OTR= for the list. >>> >>> >>> Fixing that typo in the draft would help to avoid future misreadings. S= ticking in a direct reference to RFC6066 on first mention of SNI could add = another level of clarification, if desired. >>> >>> Thanks for quickly correcting me. >>> >>> >>> Dave >>> >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --001a114321544ca206052f45dd89 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Mar 29, 2016 at 9:04 PM, Dacheng Zhang <dacheng.zdc@= alibaba-inc.com> wrote:
Hi, Erk:

My reply inline please.

Cheers

Dacheng<= /div>

=E5=8F=91=E4=BB=B6=E4=BA=BA: Eric Resc= orla <ekr@rtfm.com= >
=E6=97=A5=E6=9C=9F: 2016= =E5=B9=B43=E6=9C=8830=E6=97=A5 =E6=98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D= =8811:19
=E8=87=B3: dacheng de <dacheng.zdc@alibaba-inc.com>
=E6=8A=84=E9=80=81: Eric Mill <eric@konklone.com>, Dave Garrett <= davemgarrett@gm= ail.com>, tls <= tls@ietf.org>
=E4=B8=BB=E9=A2=98= : Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS extension transfering= service indication information

<= /div>


On Tue, Mar 29, 2016 at 6:42 PM, Dacheng Zhang &= lt;dacheng= .zdc@alibaba-inc.com> wrote:
Hi, Ekr:

Thanks for reviewing the draft and the comme= nts. Please see my reply inline please.

=E5= =8F=91=E4=BB=B6=E4=BA=BA: Eric Rescorla <ekr@rtfm.com>
=E6=97=A5=E6=9C=9F: 2016=E5=B9=B43=E6=9C=8830=E6=97=A5 =E6= =98=9F=E6=9C=9F=E4=B8=89 =E4=B8=8A=E5=8D=887:21
=E8=87=B3: dacheng de <dacheng.zdc@alibaba-inc.com>
=E6=8A=84=E9=80=81: Eric Mill <eric@konklone.com&g= t;, Dave Garrett <davemgarrett@gmail.com>, tls <tls@ietf.org>
=E4=B8=BB=E9=A2=98: Re: [TLS] =E5=9B=9E=E5=A4=8D=EF=BC=9A A TLS = extension transfering service indication information
I have taken an initial= look at this document, but I find myself confused about the security
=
model.

Specifically, you say that you can't use SN= I because customers will lie and insert
the= SNI for service A in the ClientHello when going to service B. However, I d= on't
see how this token stops that, sin= ce all it represents is a bare assertion of where
you are going that is authenticated with a MAC shared between the cl= ient, the
ICP, and the ISP. What stops the = client from doing the same thing, i.e., injecting
the token for service A into a connection destined for service B? B = can just ignore
the SI token, right?
<= /div>

Dacheng=EF=BC=9A This is a very g= ood point. How to secure the APPs on the client device (e.g., How to secure= client and prevent the message sent out from an APP provided by ICP A from= being intercepted by an APP provided by ICP B installed on=C2=A0the same= =C2=A0mobile)=C2=A0 is a hot topic. Lots of people are wo= rking hard to address this issue. For instance, TEE is an attempt of protec= ting the security of APPS on a mobile. In a TEE, APPs action are controlled= and secure channels are provided to distributed keys. So, in our solution,= we did not consider the case where the execution environment of APPs is no= t secure. We assume if an attacker or a malicious has compromise a mobile, = it could cause more serious damages.
I'm not following. If you trust the device, then why do yo= u need any kind of cryptographic
authentication on the token.

Dacheng=EF=BC=9AL= et assume we trust the device. But the APP use a SNI to indicate the servic= e that the APP intends to access. Because the SNI is static which may not b= e changed for months, it is easier for attackers who monitor the network to= get the SNI and use it to gain benefit. We need a securer solution. As=C2= =A0I have mentioned in my previous email, this solution will make such atta= cks more difficult. By the way, SNI is not designed for this purpose, we ne= ed to do some additional work to address this issue, right?

Again, you need a threat model. = It sounds like you both do and do not trust the client

=


Hmm... I'm not a= t all sure that TLS should address this problem. However, my review
was directed to whether your proposed solution even works on its own ter= ms.

Dache= ng: That is why we need to raise the discussion here. It would be great if = this issue could be considered by TLS WG.

I don't find this to be a very compelling use case an= d I don't think it's really appropriate to
try to solve i= t at the TLS layer. If you want to have secure flow identification you shou= ld
do it at the IP or TCP layers.

-Ekr


=C2=A0
We found this issue when we tried to widely use TLS to secure the commun= ications between our APPs and our services. If there could be any better id= ea or solution, we will be very happy to support it.

Finally, why am I seeing what appears to be a MAC algorith= m definition in Section
2.1. Is there a rea= son you can't just use/cite HMAC?

Dacheng: I reuse this content from my previous drafts. If p= eople don=E2=80=99t like it, we could remove it.=C2=A0^_^

= Thanks a lot for your review, and look forward to f= urther discussions on this topic.=C2=A0^_^

Cheers

Dacheng
=

-Ekr







=

On Tue, Mar 29, 2= 016 at 12:48 AM, Dacheng Zhang <dacheng.zdc@alibaba-inc.com&= gt; wrote:
Hi,

Actually, we refer to the extension as a 'SNI' extension. In th= is extension, SI(service indication) information is provided. In the next v= ersion, we will use 'SI extension' to take place of 'SNI extens= ion'. ^_^

Cheers

Dacheng
---------------= ---------------------------------------------------
=E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9ADave Garre= tt <davemgar= rett@gmail.com>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2016=E5=B9=B43=E6=9C=882= 9=E6=97=A5(=E6=98=9F=E6=9C=9F=E4=BA=8C) 14:52
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9AEric Mill <eric@konklone.com&g= t;
=E6=8A=84=E3=80=80=E9= =80=81=EF=BC=9Atls <tl= s@ietf.org>=EF=BC=8C=E5=BC=A0=E5=A4=A7=E6=88=90(=E6=B7=A1=E4=B9=85) = <dachen= g.zdc@alibaba-inc.com>
<= span style=3D"font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14px;color:= rgb(0,0,0)">=E4=B8=BB=E3=80=80=E9=A2=98=EF=BC=9ARe: [TLS] A TLS extension t= ransfering service indication information

On=C2=A0Tuesday,=C2=A0March= =C2=A029,=C2=A02016=C2=A001:35:50=C2=A0am=C2=A0Eric=C2=A0Mill=C2=A0wrote:>=C2=A0It=C2=A0looks=C2=A0like=C2=A0the=C2=A0abbreviation=C2=A0this=C2= =A0draft=C2=A0uses=C2=A0is=C2=A0just=C2=A0"SI".=C2=A0It=C2=A0uses= =C2=A0SNI=C2=A0at
>=C2=A0the=C2=A0top=C2=A0a=C2=A0few=C2=A0times=C2= =A0to=C2=A0refer=C2=A0to=C2=A0Server=C2=A0Name=C2=A0Indication=C2=A0(which= =C2=A0it=C2=A0typos=C2=A0as
>=C2=A0"service"=C2=A0name=C2= =A0extension).
>=C2=A0
>=C2=A0On=C2=A0Tue,=C2=A0Mar=C2=A029,=C2= =A02016=C2=A0at=C2=A01:13=C2=A0AM,=C2=A0Dave=C2=A0Garrett=C2=A0<davemgarrett@gmail.com= >=C2=A0wrote:
>=C2=A0>=C2=A0On=C2=A0Monday,=C2= =A0March=C2=A028,=C2=A02016=C2=A009:50:13=C2=A0pm=C2=A0Dacheng=C2=A0Zhang= =C2=A0wrote:
>=C2=A0>=C2=A0https= ://datatracker.ietf.org/doc/draft-zhang-tls-service-indication-extension/
>=C2=A0>
>=C2=A0>=C2=A0You=C2=A0really=C2=A0should=C2= =A0not=C2=A0use=C2=A0SNI=C2=A0as=C2=A0your=C2=A0abbreviation,=C2=A0as=C2=A0= it=C2=A0will=C2=A0just=C2=A0be
>=C2=A0>=C2=A0frequently=C2=A0confu= sed=C2=A0with=C2=A0the=C2=A0server_name=C2=A0extension=C2=A0which=C2=A0is= =C2=A0already=C2=A0the
>=C2=A0>=C2=A0dominant=C2=A0use=C2=A0of=C2= =A0those=C2=A0initials=C2=A0in=C2=A0TLS.

You're=C2= =A0correct;=C2=A0my=C2=A0mistake.=C2=A0I=C2=A0didn't=C2=A0notice=C2=A0t= he=C2=A0typo=C2=A0and=C2=A0reading=C2=A0a=C2=A0spec=C2=A0draft=C2=A0whilst= =C2=A0tired=C2=A0is=C2=A0not=C2=A0always=C2=A0the=C2=A0best=C2=A0of=C2=A0id= eas.=C2=A0;)

CCing=C2=A0back=C2=A0to=C2=A0list=C2=A0and=C2=A0thread= =C2=A0starter=C2=A0to=C2=A0make=C2=A0sure=C2=A0my=C2=A0correction=C2=A0is= =C2=A0OTR=C2=A0for=C2=A0the=C2=A0list.

Fixing=C2=A0that=C2=A0typo=C2= =A0in=C2=A0the=C2=A0draft=C2=A0would=C2=A0help=C2=A0to=C2=A0avoid=C2=A0futu= re=C2=A0misreadings.=C2=A0Sticking=C2=A0in=C2=A0a=C2=A0direct=C2=A0referenc= e=C2=A0to=C2=A0RFC6066=C2=A0on=C2=A0first=C2=A0mention=C2=A0of=C2=A0SNI=C2= =A0could=C2=A0add=C2=A0another=C2=A0level=C2=A0of=C2=A0clarification,=C2=A0= if=C2=A0desired.

Thanks=C2=A0for=C2=A0quickly=C2=A0correcting=C2=A0m= e.


Dave


____________= ___________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/tls




--001a114321544ca206052f45dd89-- From nobody Wed Mar 30 08:37:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5C9B12D0E2 for ; Wed, 30 Mar 2016 08:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 GIlxOonvMM2e for ; Wed, 30 Mar 2016 08:37:49 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 BB64512D0B6 for ; Wed, 30 Mar 2016 08:37:48 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z68so66043478vkg.3 for ; Wed, 30 Mar 2016 08:37:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=OlFdgdbWVPj3ptfPyXVDNoZt7+zoCg+kEoC+2/Krfh4=; b=IFe8Nmp2s26A9qLi+FUQzCRUjGMXM1qi79rpQa/6n3uaVmn1Vh8xK1ROp2vtNiXLP3 WP+H797mJQdb+JgT90YdQOyp7IBkuXfYQBarS5Lw2TiayQExJPRUruWsyHL8U70wC0jW 4Dn9PJDC2IOSA5wpfq1vllhQvTpV2WDLqb8ugui3yLnuhplyr9E8/W9yO5o1ras4yTyu PtUJ9gCpX01GdWRlZQ1DTaQ21PYoEPoyNZ/oKommRzdqcJ4RwDUDjE0KwcFfEGiDM/Ix aDrdqwHYkxinYq2eqFsQpdaNFqKbm0hV/SoQJWSnhChLDsIFGAC7XdwmHfn8nhDCb6AV GWYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=OlFdgdbWVPj3ptfPyXVDNoZt7+zoCg+kEoC+2/Krfh4=; b=KKuvdP+Y4VsYPI60yIGuH9SKPw6v0dhZ5pwnhUBnw+rMtWqYN0bykIOJHgmyxxCmWe q27TlGIWk0baxYnocfcE7jTjhzJ6x4a6fTXEoXn4R0Y3JAe0uz8RqDs7kbWGPjvOLxoA bxjWBM8zXcgLI7e+nFzRyN9ou3mX+5yuWXGfQosOYRVUw2F808SitPu//076zFnZnYs6 LEh0D1qVQElcZj8+v99OXN/JKb8Ad/thBeb1ZIIpH07qeB2E6Nb5xu4luzpils6Ppzy+ dATEKdfwMg6is9LJ2P6Rg1jJx2zIap6O3GJhL0Unp52y7fLbjpaGFLo6cAseGEvGFR3g rB2A== X-Gm-Message-State: AD7BkJJU0inFqif7IPTR1AXURxlalqHskj7bXhxsmYJ3LGHrLr8RE/mgPEg6wKLWMgzKyCuC1FUlu/8XkXv0XhmJ MIME-Version: 1.0 X-Received: by 10.176.3.110 with SMTP id 101mr5522678uat.34.1459352267288; Wed, 30 Mar 2016 08:37:47 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Wed, 30 Mar 2016 08:37:47 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2016 08:37:47 -0700 Message-ID: From: Bill Cox To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c15a0c8038ec052f45ed4f Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:37:52 -0000 --001a11c15a0c8038ec052f45ed4f Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 8:22 AM, Eric Rescorla wrote: > This got a lot of discussion early in the design process and the consensus > was that the risk of having the default mode (with existing certs) allow > the > creation of a long-term delegation was too high. See, for instance, the > relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and > QUIC. > > With that said, I think this would be a good feature to look at in future > and the right way to do it is to: > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > PKIX. > 2. Add a subcert extension to TLS 1.3. > OK, awesome. Is it too early to volunteer for this effort? Do you know who the right person is to contact? Thanks again, Bill --001a11c15a0c8038ec052f45ed4f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Mar 30, 2016 at 8:22 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
This got a lot of discus= sion early in the design process and the consensus
was that the risk of= having the default mode (with existing certs) allow the
creation= of a long-term delegation was too high. See, for instance, the
r= elative impact of the recent paper by Jager at al. [0] on TLS 1.3 and
=
QUIC.

With that said, I think this would be a= good feature to look at in future
and the right way to do it is = to:

1. Add a "this is only usable for TLS 1.3= [or for subcerts]" extension to
PKIX.
2. Add a su= bcert extension to TLS 1.3.

OK,= awesome.=C2=A0 Is it too early to volunteer for this effort?=C2=A0 Do you = know who the right person is to contact?

Thanks ag= ain,
Bill=C2=A0
--001a11c15a0c8038ec052f45ed4f-- From nobody Wed Mar 30 08:38:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370A12D77F for ; Wed, 30 Mar 2016 08:38:18 -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 7upjHXIKpRPG for ; Wed, 30 Mar 2016 08:38:13 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4848C12D19F for ; Wed, 30 Mar 2016 08:38:13 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id h129so63193718ywb.1 for ; Wed, 30 Mar 2016 08:38:13 -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=HonN9YBzqjafVZia6k71s64kje3QgKaUd/g7S2ldRi4=; b=EeXFeHHz46MR1m5uXP7NGlxukv7uS+9DjqP+W+LiznmxU4pPRarMU2n9TUcll8GBJL IUkdodaQlEYxqj/qSdetS+gJ668PHAQpT34rme/RLau4Sz/Ld4Q1g8xSvTN7eKXQlMzy GtSq27RYrnspZ7keTrgBQigkTJiJV56Xp7/BOXqdDlSmThopzbqZadrosXQ/RyMfGOGS loFzfEaMuV/2iyuGsbQBm16SnvnRVp8S3lcb5RphqBhX36RrJlUhlahpUn2ji5+fG3e+ xIDFqe5cY9inMt+2Df5WAqLXGhIMpBle3G7VPM8NRi0dUJbmTdS9JFidmOw6DEJ1nK8l Qg3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HonN9YBzqjafVZia6k71s64kje3QgKaUd/g7S2ldRi4=; b=Gm5OeWAtx+/r5ek2mXarZCQ/1PjoQLkQ9E6nhL1vE1G45GmFye8bT4Eh81F5mX9rSm e9g/d3XzDtc2R18/jd38KX4/D+UJizsYWfr5bz+AaEfLU8ndbAlQLe/CmyqYQAdJYSC5 AqlBIPa+CRosUMzgH/dSXgYN2y6OWEgXX4u/vSkZkXPFWiqzap3KsnF+k1YPHtot9Waq 8Y2EfCWQ8d5PpZe391ppsiclKcHofeIRtw/DK/iILtXKF2lPtgfVerLyUhUiqHgR3GZt UtHtAxme1bBswIIb8CLD9zztWO2KWqTxU3K3lOuUjZcfvW2nRQJF9B/MjcZflV0T/xNe yM6A== X-Gm-Message-State: AD7BkJJsrJ1BKYFvI9rVYygwy0iVYZsDeA4HzRWOH/JIJsKmAafhklJt8WQr/mU/fvDSbCwSCOD56ErE/3041g== X-Received: by 10.37.231.71 with SMTP id e68mr4610625ybh.57.1459352292555; Wed, 30 Mar 2016 08:38:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 08:37:33 -0700 (PDT) In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> From: Eric Rescorla Date: Wed, 30 Mar 2016 08:37:33 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=94eb2c0a8c9a002d04052f45ef75 Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:38:18 -0000 --94eb2c0a8c9a002d04052f45ef75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I am in favor of this. On Tue, Mar 29, 2016 at 6:53 PM, Sean Turner wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for > cipher suites to allow anyone with a stable, publicly available, peer > reviewed reference document to request and get a code point and to add an > =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This change i= s motivated by the > large # of requests received for code points [0], the need to alter the > incorrect perception that getting a code point somehow legitimizes the > suite/algorithm, and to help implementers out. We need to determine > whether we have consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be > changed to specification required. > > 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with two= values: =E2=80=9CY=E2=80=9D or > =E2=80=9CN=E2=80=9D. Y and N have the following meaning: > > Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus o= n > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but can= ) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on [0]= ) that > matches the above so that the same information is available to those who > don=E2=80=99t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > > Thanks, > > J&S > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-= parameters-4 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a8c9a002d04052f45ef75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am in favor of this.
On Tue, Mar 29, 2016 at 6:53 PM, Sean Turner <sea= n@sn3rd.com> wrote:
Hi!

In Yokohama, we discussed changing the IANA registry assignment rules for c= ipher suites to allow anyone with a stable, publicly available, peer review= ed reference document to request and get a code point and to add an =E2=80= =9CIETF Recommended=E2=80=9D column to the registry.=C2=A0 This change is m= otivated by the large # of requests received for code points [0], the need = to alter the incorrect perception that getting a code point somehow legitim= izes the suite/algorithm, and to help implementers out.=C2=A0 We need to de= termine whether we have consensus on this plan, which follows:

1. The IANA registry rules for the TLS cipher suite registry [1] will be ch= anged to specification required.

2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with two v= alues: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D.=C2=A0 Y and N have the f= ollowing meaning:

=C2=A0Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensu= s on
=C2=A0and are reasonably expected to be supported by widely
=C2=A0used implementations such as open-source libraries.=C2=A0 The
=C2=A0IETF takes no position on the cipher suites marked with an
=C2=A0=E2=80=9CN=E2=80=9D.=C2=A0 Not IETF recommended does not necessarily = (but can)
=C2=A0mean that the ciphers are not cryptographically sound (i.e.,
=C2=A0are bad).=C2=A0 Cipher suites can be recategorized from N to Y
=C2=A0(e.g., Curve448) and vice versa.

3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to th= ose who don=E2=80=99t read the IANA considerations section of the RFC.

Please indicate whether or not you could support this plan.

Thanks,

J&S

[0] In the last year, the chairs have received requests for:

PSK: https://datatracker.ietf.org/= doc/draft-mattsson-tls-ecdhe-psk-aead/
AES-OCB: https://www.ietf.org/arc= hive/id/draft-zauner-tls-aes-ocb-03.txt
Kcipher2: https://datatracker.ietf.org/= doc/draft-kiyomoto-kcipher2-tls/
dragonfly: https://datatracker.ietf.org/doc/draf= t-ietf-tls-pwd/
NTRU:=C2=A0 http://www.ietf.org/id/draft-whyte-qs= h-tls12-01.txt
JPAKE: not sure they got around to publishing a draft.

[1] https://www= .iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4<= /a>


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

--94eb2c0a8c9a002d04052f45ef75-- From nobody Wed Mar 30 08:45:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4624412D760 for ; Wed, 30 Mar 2016 08:45:31 -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 usgiBKk_Fbxr for ; Wed, 30 Mar 2016 08:45:29 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A58E012D68F for ; Wed, 30 Mar 2016 08:45:29 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id g127so63231495ywf.2 for ; Wed, 30 Mar 2016 08:45: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=uddBug+DEAc9cWt6bscWriuuXT6wlXoo/lUn006rWbk=; b=w09o25beWbd4OY/s594/gikT3UdWlvDJ2QtDUAwX9mv9kkBQRO/4AMekZWuyZ3JVyR YaseIRX+PJ72nYoKgyXLPXnnHBZs9z8KMqdt81q3BPxmGmT18lKeptwMnY4FzeLuN5l5 vwllXmqn1hfRXD0G/qYyakrlwDDUBHI5O45L8w7otmAMDm/r1mYYmRlJKmOUCjc4S4a2 0iLIpKHh1Nml4iULsympXpyXhaKJ7YR967i9j8N/DgYffFaOmMcpdLncEjIh27QzAZrH XG9x3tS43qn7HgqGx5SNwwIfMEoRiCnHtf2UInn2EJ9Hx2sZBmKunlIg0OEhLvzt1IT7 22Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uddBug+DEAc9cWt6bscWriuuXT6wlXoo/lUn006rWbk=; b=FxM7HZnkGN8l91PjWE0tK6qQ4ZP85zYmbfPDRIP32QUYUW3qUO2iWR0Yp1SW8FRBm8 M6vomo8tZPyIVXHQv/UNJk2RM57G2wYahF4H4p3euwCzKUpQqCxUzQFcX90ck0IAhZwJ su6Lrm7Ddq+NNFUISjhiVR0oXS0AurqitDupduZ/05ziWvzFGprBxAwzoAqNZv/1jV9P aYm4EJfqClk91iafj3tpnNrGf7Kd4WOKFVUb4pD7PzAO3xB3N13YaH6/u9kZQw//Vulg ngbrWyfNHaew93mVQ3EuIkemuhp4RZ01NwjxqX73W9p4jvy/DgJDF9EN59HDX8I1N2BP CEwA== X-Gm-Message-State: AD7BkJLpgDs+zyZnkRbysxuJlY++pEKHLkV3mZkOz9S4kN3FrpdiEDfiaviXrVeTHYHHZ1qFVqY+DmRUwYX6uQ== X-Received: by 10.129.119.9 with SMTP id s9mr444065ywc.115.1459352728855; Wed, 30 Mar 2016 08:45:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.44.2 with HTTP; Wed, 30 Mar 2016 08:44:47 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 30 Mar 2016 08:44:47 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a1141c594018aa8052f460977 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:45:31 -0000 --001a1141c594018aa8052f460977 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 8:37 AM, Bill Cox wrote: > On Wed, Mar 30, 2016 at 8:22 AM, Eric Rescorla wrote: > >> This got a lot of discussion early in the design process and the consensus >> was that the risk of having the default mode (with existing certs) allow >> the >> creation of a long-term delegation was too high. See, for instance, the >> relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and >> QUIC. >> >> With that said, I think this would be a good feature to look at in future >> and the right way to do it is to: >> >> 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to >> PKIX. >> 2. Add a subcert extension to TLS 1.3. >> > > OK, awesome. Is it too early to volunteer for this effort? > No! > Do you know who the right person is to contact? > Shoot me an email offline and I can walk you through what I think would be required to get this going. -Ekr > > Thanks again, > Bill > --001a1141c594018aa8052f460977 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 8:37 AM, Bill Cox <waywardgeek@google.com= > wrote:
<= div class=3D"gmail_extra">
On We= d, Mar 30, 2016 at 8:22 AM, Eric Rescorla <ekr@rtfm.com> wrote:
This got a lot of discuss= ion early in the design process and the consensus
was that the risk of = having the default mode (with existing certs) allow the
creation = of a long-term delegation was too high. See, for instance, the
re= lative impact of the recent paper by Jager at al. [0] on TLS 1.3 and
<= div>QUIC.

With that said, I think this would be a = good feature to look at in future
and the right way to do it is t= o:

1. Add a "this is only usable for TLS 1.3 = [or for subcerts]" extension to
PKIX.
2. Add a sub= cert extension to TLS 1.3.

OK, awesome.=C2=A0 Is it too early to volunteer for this effort?

No!

=C2=A0
=C2=A0 Do you know who the= right person is to contact?

<= /div>
Shoot me an email offline and I can walk you through what I think= would be required
to get this going.

-E= kr
=C2=A0

Tha= nks again,
Bill=C2=A0

--001a1141c594018aa8052f460977-- From nobody Wed Mar 30 09:02:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF2012D161 for ; Wed, 30 Mar 2016 09:02:58 -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 jisTazpC_3Ms for ; Wed, 30 Mar 2016 09:02:47 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5B712D79E for ; Wed, 30 Mar 2016 09:02:47 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 50472F997; Wed, 30 Mar 2016 12:02:45 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 61C112009C; Wed, 30 Mar 2016 12:02:45 -0400 (EDT) From: Daniel Kahn Gillmor To: Eric Rescorla , Bill Cox In-Reply-To: References: User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 30 Mar 2016 12:02:45 -0400 Message-ID: <8760w4ymvu.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:02:58 -0000 On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote: > This got a lot of discussion early in the design process and the consensus > was that the risk of having the default mode (with existing certs) allow the > creation of a long-term delegation was too high. See, for instance, the > relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and > QUIC. > > With that said, I think this would be a good feature to look at in future > and the right way to do it is to: > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > PKIX. this would need to be a critical extension, since the goal is to have it be unusable by existing endpoints, right? do we have tests about how well existing endpoints will fail closed in the face of unknown critical extensions? > 2. Add a subcert extension to TLS 1.3. This would be necessary for clients to signal that it's ok to use such a delegated cert or subcert. we need to think clearly about how to limit the scope of such a delegation to make it safe. --dkg From nobody Wed Mar 30 09:03:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4406E12D73C for ; Wed, 30 Mar 2016 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Tmee4To6x8L0 for ; Wed, 30 Mar 2016 09:03:43 -0700 (PDT) Received: from vsp1.ballou.se (vsp1.ballou.se [91.189.40.82]) by ietfa.amsl.com (Postfix) with SMTP id B734912D7B6 for ; Wed, 30 Mar 2016 09:03:39 -0700 (PDT) X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp1.ballou.se (Halon Mail Gateway) with ESMTP for ; Wed, 30 Mar 2016 18:03:37 +0200 (CEST) Received: from [192.168.0.190] (c-76cbe555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.203.118]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 7472CC93F1 for ; Wed, 30 Mar 2016 18:03:36 +0200 (CEST) References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: <56FBF8C9.5050103@streamsec.se> Date: Wed, 30 Mar 2016 18:03:21 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56FBF1B5.8030906@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: henrick@streamsec.se List-Id: "This is the mailing list 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 Mar 2016 16:03:49 -0000 On 2016-03-30 17:33, Benjamin Kaduk wrote: > I am not sure that we want to be in the business of explicitly marking > things as insecure other than our own RFCs, though -- there could be an > implication of more review than is actually the case, which is what this > proposal is trying to get rid of. So how about explicitly marking things as "obsolete" instead? From nobody Wed Mar 30 09:05:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFF012D5E2 for ; Wed, 30 Mar 2016 09:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fPFPUuSbh83H for ; Wed, 30 Mar 2016 09:05:33 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2685A12D7B9 for ; Wed, 30 Mar 2016 09:05:32 -0700 (PDT) Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 2F9DAF997; Wed, 30 Mar 2016 12:05:26 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 4E3AA200A9; Wed, 30 Mar 2016 12:05:26 -0400 (EDT) From: Daniel Kahn Gillmor To: Benjamin Kaduk , Sean Turner , "\" In-Reply-To: <56FBF1B5.8030906@akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 30 Mar 2016 12:05:26 -0400 Message-ID: <8737r8ymrd.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:05:35 -0000 On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > I am not sure that we want to be in the business of explicitly marking > things as insecure other than our own RFCs, though -- there could be an > implication of more review than is actually the case, which is what this > proposal is trying to get rid of. I think i agree with Ben here: if we have a tri-state: approved/not-approved/known-bad, then the people will infer that the not-approved ciphersuites are better than the known-bad ones, which isn't necessarily the case. I think i'd rather see it stay at "approved/not-approved" --dkg From nobody Wed Mar 30 09:08:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA42D12D161 for ; Wed, 30 Mar 2016 09:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 Dj0_dVimD0XF for ; Wed, 30 Mar 2016 09:08:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13B12D52E for ; Wed, 30 Mar 2016 09:08:33 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A67FA43346E; Wed, 30 Mar 2016 16:08:32 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 8E67743346B; Wed, 30 Mar 2016 16:08:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459354112; bh=iJON0Z4Htrpu7m84gFUFDon/3cjP0G/z4GE2AwyINeY=; l=249; h=From:To:Date:References:In-Reply-To:From; b=HVgf0GfXGsh9k54FH9dtlhyDLlfEgJZV9rUhB0A7/62/iLf6NLMjZ+nQiWjsXKlK+ AJJqJFNlxZemRjqv/kgqIbwm94kuuQfCgVRStcNoMF5ZbpWZRY9lEobHNRHEMrHcf/ HZ5jucDBEHRNlVNPYUMLuQrPHplnR/Rk6Ns1JKwY= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 876831FC86; Wed, 30 Mar 2016 16:08:32 +0000 (GMT) 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.1130.7; Wed, 30 Mar 2016 12:08:32 -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.1130.005; Wed, 30 Mar 2016 12:08:32 -0400 From: "Salz, Rich" To: Daniel Kahn Gillmor , "Kaduk, Ben" , Sean Turner , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRipmQi4OpUGce3UupQ9LKK53UB59yacwA//+9f3A= Date: Wed, 30 Mar 2016 16:08:31 +0000 Message-ID: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> In-Reply-To: <8737r8ymrd.fsf@alice.fifthhorseman.net> 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.119.59] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:08:35 -0000 > I think i'd rather see it stay at "approved/not-approved" There is also the concern that various parties (e.g., national crypto) can = get upset by this kind of thing. Which is why I prefer "approved/no-commen= t" as the dividing line.=20 From nobody Wed Mar 30 09:29:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1671912D7CD for ; Wed, 30 Mar 2016 09:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE9x8-A6MgEO for ; Wed, 30 Mar 2016 09:29:17 -0700 (PDT) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63D7412D54C for ; Wed, 30 Mar 2016 09:29:17 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u2UGQ1hR007802; Wed, 30 Mar 2016 09:29:09 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=Zldy6onYTlr1d1lF58GEFkF//nEO9xhZlMi9RCF6DYw=; b=nZ6zrCEW6aob++FFGH/CmdRDowH7hMjWC2qX7gJ7NOgudFhrsBZ6jN7nIf7u90c03pJ/ pxRH7CnS5I3p1x270H+MRs9X6Y0jVmzis8ulpsQzHwYxG41EtEKssZNT+xt5DKCw3RUR PD9RAFuDfNIbTztCM5ZW4SM4iEdpmOPtIT4= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 22037dpv7g-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 Mar 2016 09:29:09 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB07.TheFacebook.com ([fe80::d38:43fc:554e:146a%12]) with mapi id 14.03.0248.002; Wed, 30 Mar 2016 09:29:08 -0700 From: Subodh Iyengar To: Martin Thomson , David Benjamin Thread-Topic: [TLS] Tickets and cross protocol attacks Thread-Index: AdGJ2hy6RRaBdpbjRFKOvt6QZ8JoPAARYCsAAA+okIAAEGGXgA== Date: Wed, 30 Mar 2016 16:29:07 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564FE916@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99564FE17B@PRN-MBX01-4.TheFacebook.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-03-30_09:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Tickets and cross protocol attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:29:19 -0000 >I disagree with point #3 and think the "prevent fallback" portion would be= a mistake. Possession of a TLS 1.3 session to offer should not disable TLS= 1.2 if the client would have accepted this without that session.=0A= =0A= @David, for #3, I'm referring to fallback in 0-RTT mode. In the normal oper= ation case I don't think fallbacks work at all in this mode, so it should b= e fine to reject it to prevent attacks like I mentioned below.=0A= =0A= For example let's say a client sends a 0-RTT packet and the server only sup= ports TLS1.2, the server will return a server hello with TLS1.2. However wh= en it reads data from the session buffer expecting a ClientKeyExchange mess= age, it will start getting the 0-RTT data. =0A= =0A= In a case where the server is smart enough to discard all this data (maybe = its a special TLS1.2 + TLS1.3 server), the behavior when this happens on t= he client side is unspecified, should the client supply the data again in t= he normal TLS stream? should it not resend that data?=0A= =0A= It's probably better to reject this fallback when the client has chosen to = explicitly use a TLS 1.3 feature with 0-RTT in general.=0A= =0A= Subodh=0A= ________________________________________=0A= From: Martin Thomson [martin.thomson@gmail.com]=0A= Sent: Tuesday, March 29, 2016 6:29 PM=0A= To: David Benjamin=0A= Cc: Subodh Iyengar; tls@ietf.org=0A= Subject: Re: [TLS] Tickets and cross protocol attacks=0A= =0A= On 30 March 2016 at 05:00, David Benjamin wrote:=0A= > On the server, OpenSSL already includes the version in the SSL_SESSION=0A= > structure, and recent enough versions of it will not accept sessions at t= he=0A= > wrong version=0A= =0A= =0A= NSS too. This is the right thing, I think.=0A= =0A= I have no objection to making this a requirement in the spec.=0A= From nobody Wed Mar 30 09:33:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC6012D673 for ; Wed, 30 Mar 2016 09:33:04 -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 b3rAzjARwPxi for ; Wed, 30 Mar 2016 09:33:03 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67A8512D7C5 for ; Wed, 30 Mar 2016 09:32:59 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id p65so79670065wmp.0 for ; Wed, 30 Mar 2016 09:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWm0Z/hcGHYkN+d8VzjMkfVWiaCTa4IWpvTXL17/wNY=; b=r2osficLiilFRnrB5QbPDVGH3svQD5TL/quULHKIKuhcCq1qhv48n7YFs+5PiEwm5h SyFFxP8M26lPgdlxv1AhlQeIGkCcOj+EiZWU5XAr90PhJUsD5jQSqTFlYDdO2JvZYXE7 8VPbD2Booc6Th5/rLjTBc6Lg70fu538pACY/M8FZfOI0jfc+L0OJ1THwnhQP5JA+24Zi opw/NsZ0SZTUSlVkyWtpiAzrlQpOJVicOZcxvaJClIc3cgI3xssck3xmugFRtRPiyH0w iJJ1+pNwO6azhlQxy4XR9+N8gbL4Fm3FDEnKJ8YV/Jrro189Mi4CzFhv04TLN6munfYg z89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hWm0Z/hcGHYkN+d8VzjMkfVWiaCTa4IWpvTXL17/wNY=; b=ca253LBo90sF4nSRv/YjNnEf6I7xSE+lIEmPlwgJPrXg0HHRX3JL4BEFvwXGdx+TNo V+oMwwPXn8JjSSFF5dzMwC6WzpDcYfYIGqEf+8/Y9OVe0lfmIkFQh+xIIxO04heg/qc6 kLWltv2jdbBgXtRrPSlX+Ca+k4KxU75vs5jH6PgztYRhTyG8UYPH6XKcuNTgKGeYENUZ XN3dbeZxDgJvuKmhA9tVHrAWLN+642TuYxnwMiq6UMnDqOgxPpQa3wmv9/MbS+Huq7VX kPUFLkBYmc3dTA2iQaRwHN0KcFNEPXr7FBjyHM0+M39KxpkbAuawrQkIcZjkI81N6WTv mR9g== X-Gm-Message-State: AD7BkJJNya+meCwZ5nfevWe81m9YOwl7iaZZBdRHdqZqcxMpa547Lvhf82CPcZuMallv3Q== X-Received: by 10.194.187.71 with SMTP id fq7mr10179371wjc.97.1459355577880; Wed, 30 Mar 2016 09:32:57 -0700 (PDT) Received: from yoavs-mbp-2.mshome.net ([176.13.20.215]) by smtp.gmail.com with ESMTPSA id y72sm5214724wmh.21.2016.03.30.09.32.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 09:32:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: <8737r8ymrd.fsf@alice.fifthhorseman.net> Date: Wed, 30 Mar 2016 19:32:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <12F5A3D4-D99A-4D5B-B589-27CD8EBC98CF@gmail.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:33:05 -0000 > On 30 Mar 2016, at 7:05 PM, Daniel Kahn Gillmor = wrote: >=20 > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: >> I am not sure that we want to be in the business of explicitly = marking >> things as insecure other than our own RFCs, though -- there could be = an >> implication of more review than is actually the case, which is what = this >> proposal is trying to get rid of. >=20 > I think i agree with Ben here: if we have a tri-state: > approved/not-approved/known-bad, then the people will infer that the > not-approved ciphersuites are better than the known-bad ones, which > isn't necessarily the case. >=20 > I think i'd rather see it stay at "approved/not-approved=E2=80=9D +1 Nothing will ever be marked as known-bad unless it=E2=80=99s in = widespread use. Nobody=E2=80=99s ever going to write a die-die-die = document for some homebrew cipher or even for a national cipher unless = something really spectacular happens. I=E2=80=99d rather not have them = marked as =E2=80=9Cneutral=E2=80=9D, which implies they are better than = RC4=E2=80=99s =E2=80=9Cknown-bad=E2=80=9D.=20 Besides, what about 3DES? For limited amounts of data it works perfectly = fine if you follow all the CBC caveats, but with high-speed high-volume = connections, you=E2=80=99ll have to rekey often. And there are faster, = better alternatives. Do we mark it as =E2=80=9Cknown-bad=E2=80=9D? = It=E2=80=99s certainly not broken the way RC4 is. I=E2=80=99d rather we = not go there. Yoav From nobody Wed Mar 30 10:54:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED49812D841 for ; Wed, 30 Mar 2016 10:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRIEHOg3ImB6 for ; Wed, 30 Mar 2016 10:54: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 56A7112D82B for ; Wed, 30 Mar 2016 10:54:18 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id g185so84608182ioa.2 for ; Wed, 30 Mar 2016 10:54:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fCPzKtXNxWZGzmas6JroTg+0bYDVq1IRAPbqrKTxeYY=; b=me59AVQheQozP2pQOBjVjYPJA0H9bpl/GCb7pweZdIvXQuDqtFY+j2nRHbT2gSmgSZ 6hdsa31aSwgudEnmz7GIOUgp3StPr5BOikRLYjnN04zLA8P8n+2UO/coO9Dzfp+Dp9wu 5pKyHSgjiics80wK6k24pRIFr4YCFLCylNNHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fCPzKtXNxWZGzmas6JroTg+0bYDVq1IRAPbqrKTxeYY=; b=dUGvp1aI3VW5TG2oF4S513EZFET+faJBb/RAHOjitXLssB6VG/hegbScevo46mCZKH TesATvuvItS0n6lZUEXHAeAGUegZJP0zHGmwb2KO3cAPLBXRv16guoiLVITzH1M1Y4O6 tWsRSS732Zx9znQBmLLyKZ2PZEkHEuVGydMTAF4R6DYv2NI8TDX7/ymMc4r5fGa15h+0 qAqGxFdN8t3Rx4kCrvX5JnhXWY6rOCmt79bxIKarEuac1xXM8doGNm2xZWXk4+QZxNwo 2mfCz9RY4E0AknkNYeWiBuzqTnouY4qMyluJQPBWpCvIZVDhGvCRPryZxZ64rS7lVKYh 6tcg== X-Gm-Message-State: AD7BkJK7AQOCcTAXjX5DfZsBhEzcVF9Fucz+wfIlxisCMUtPmTV/uAOHcfsWZcB1BilEGQE5YQC/wwfLpcKoIurV X-Received: by 10.107.34.16 with SMTP id i16mr10856164ioi.166.1459360457428; Wed, 30 Mar 2016 10:54:17 -0700 (PDT) MIME-Version: 1.0 References: <974CF78E8475CD4CA398B1FCA21C8E99564FE17B@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99564FE916@PRN-MBX01-4.TheFacebook.com> In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99564FE916@PRN-MBX01-4.TheFacebook.com> From: David Benjamin Date: Wed, 30 Mar 2016 17:54:07 +0000 Message-ID: To: Subodh Iyengar , Martin Thomson Content-Type: multipart/alternative; boundary=001a1140c1acaa57bc052f47d5ab Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Tickets and cross protocol attacks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:54:21 -0000 --001a1140c1acaa57bc052f47d5ab Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 12:29 PM Subodh Iyengar wrote: > >I disagree with point #3 and think the "prevent fallback" portion would > be a mistake. Possession of a TLS 1.3 session to offer should not disable > TLS 1.2 if the client would have accepted this without that session. > > @David, for #3, I'm referring to fallback in 0-RTT mode. In the normal > operation case I don't think fallbacks work at all in this mode, so it > should be fine to reject it to prevent attacks like I mentioned below. > > For example let's say a client sends a 0-RTT packet and the server only > supports TLS1.2, the server will return a server hello with TLS1.2. However > when it reads data from the session buffer expecting a ClientKeyExchange > message, it will start getting the 0-RTT data. > Oh, I see. Yeah, that TLS 1.3 is backwards incompatible here is unfortunate, for the same heterogeneous-deployment reasons as session resumption. As things stand, enabling 0-RTT on one machine in a fleet is a promise that *all* machines have deployed TLS 1.3 and that TLS 1.3 will *never* be rolled back (unless turn off 0-RTT on all machines and then wait for things to expire first, but typically one needs to roll something back because it is broken and needs attention). Deployments that just ship pre-packaged server software will not get this right. TLS 1.3 should not require TLS experts guiding deployment. (I understand that this backwards incompatibility is necessary for TLS 1.3 clients to stream 0-RTT data. I think this is a mistake for TLS over TCP (though it is, of course, fine for other profiles like QUIC or DTLS), but I've probably lost that one.) > In a case where the server is smart enough to discard all this data (maybe > its a special TLS1.2 + TLS1.3 server), the behavior when this happens on > the client side is unspecified, should the client supply the data again in > the normal TLS stream? should it not resend that data? > If the server responds with a != TLS 1.3 ServerHello with an indication that it accepted the early data then, agreed, that should be a fatal error. This is for the same reasons as forbidding cross-version session resumption. If the server responds with a < TLS 1.3 ServerHello and *doesn't* indicate early data, that's a different question. If the client does accept it, the client should supply the data again, as it would have with TLS 1.3. But, actually, I think I may buy this too should be a fatal error, but not for security reasons. I think trying to use this as version downgrade protection in so narrow of a scope does not make sense. Rather, because TLS 1.3 0-RTT is currently backwards-incompatible, TLS 1.3 forces a connection retry fallback[0]. Clients offering 0-RTT need to retry without 0-RTT enabled[1]. Using "server sent a < TLS 1.3 ServerHello to a ClientHello with 0-RTT data" as a fallback trigger is at least a reliable one. If we must have a fallback (I would rather we didn't), it shouldn't be a flaky one. David [0] We seem to have several meanings of the word "fallback" here. :-) One to mean where we accept a ServerHello at lower version than the ClientHello, and another to mean when you start a connection over from the top with different parameters, akin to the insecure TLS version fallback browsers do/did. I'm referring to the second one. [1] Without lowering the ClientHello version, of course. Though TLS 1.3 intolerance, sadly, seems to exist, so that might also happen again independently. > It's probably better to reject this fallback when the client has chosen to > explicitly use a TLS 1.3 feature with 0-RTT in general. > > Subodh > ________________________________________ > From: Martin Thomson [martin.thomson@gmail.com] > Sent: Tuesday, March 29, 2016 6:29 PM > To: David Benjamin > Cc: Subodh Iyengar; tls@ietf.org > Subject: Re: [TLS] Tickets and cross protocol attacks > > On 30 March 2016 at 05:00, David Benjamin wrote: > > On the server, OpenSSL already includes the version in the SSL_SESSION > > structure, and recent enough versions of it will not accept sessions at > the > > wrong version > > > NSS too. This is the right thing, I think. > > I have no objection to making this a requirement in the spec. > --001a1140c1acaa57bc052f47d5ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 30= , 2016 at 12:29 PM Subodh Iyengar <subo= dh@fb.com> wrote:
>I di= sagree with point #3 and think the "prevent fallback" portion wou= ld be a mistake. Possession of a TLS 1.3 session to offer should not disabl= e TLS 1.2 if the client would have accepted this without that session.

@David, for #3, I'm referring to fallback in 0-RTT mode. In the normal = operation case I don't think fallbacks work at all in this mode, so it = should be fine to reject it to prevent attacks like I mentioned below.

For example let's say a client sends a 0-RTT packet and the server only= supports TLS1.2, the server will return a server hello with TLS1.2. Howeve= r when it reads data from the session buffer expecting a ClientKeyExchange = message, it will start getting the 0-RTT data.

Oh, I see. Yeah, that TLS 1.3 is backwards incompatible here i= s unfortunate, for the same heterogeneous-deployment reasons as session res= umption. As things stand, enabling 0-RTT on one machine in a fleet is a pro= mise that *all* machines have deployed TLS 1.3 and that TLS 1.3 will *never= * be rolled back (unless turn off 0-RTT on all machines and then wait for t= hings to expire first, but typically one needs to roll something back becau= se it is broken and needs attention). Deployments that just ship pre-packag= ed server software will not get this right. TLS 1.3 should not require TLS = experts guiding deployment.

(I understand that thi= s backwards incompatibility is necessary for TLS 1.3 clients to stream 0-RT= T data. I think this is a mistake for TLS over TCP (though it is, of course= , fine for other profiles like QUIC or DTLS), but I've probably lost th= at one.)
=C2=A0
In a case where the server is smart enough to discard all this data (maybe = its a special TLS1.2=C2=A0 + TLS1.3 server), the behavior when this happens= on the client side is unspecified, should the client supply the data again= in the normal TLS stream? should it not resend that data?
=

If the server responds with a !=3D TLS 1.3 ServerHello = with an indication that it accepted the early data then, agreed, that shoul= d be a fatal error. This is for the same reasons as forbidding cross-versio= n session resumption.

If the server responds with = a < TLS 1.3 ServerHello and *doesn't* indicate early data, that'= s a different question. If the client does accept it, the client should sup= ply the data again, as it would have with TLS 1.3. But, actually, I think I= may buy this too should be a fatal error, but not for security reasons. I = think trying to use this as version downgrade protection in so narrow of a = scope does not make sense.

Rather, because TLS 1.3= 0-RTT is currently backwards-incompatible, TLS 1.3 forces a connection ret= ry fallback[0]. Clients offering 0-RTT need to retry without 0-RTT enabled[= 1]. Using "server sent a < TLS 1.3 ServerHello to a ClientHello wit= h 0-RTT data" as a fallback trigger is at least a reliable one. If we = must have a fallback (I would rather we didn't), it shouldn't be a = flaky one.

David

[0] We s= eem to have several meanings of the word "fallback" here. :-) One= to mean where we accept a ServerHello at lower version than the ClientHell= o, and another to mean when you start a connection over from the top with d= ifferent parameters, akin to the insecure TLS version fallback browsers do/= did. I'm referring to the second one.

[1] With= out lowering the ClientHello version, of course. Though TLS 1.3 intolerance= , sadly, seems to exist, so that might also happen again independently.
=C2=A0
It's probably better to reject this fallback when the client has chosen= to explicitly use a TLS 1.3 feature with 0-RTT in general.



=C2=A0
Subodh
________________________________________
From: Martin Thomson [martin.thomson@gmail.com]
Sent: Tuesday, March 29, 2016 6:29 PM
To: David Benjamin
Cc: Subodh Iyengar; tls@i= etf.org
Subject: Re: [TLS] Tickets and cross protocol attacks

On 30 March 2016 at 05:00, David Benjamin <davidben@chromium.org> wrote:
> On the server, OpenSSL already includes the version in the SSL_SESSION=
> structure, and recent enough versions of it will not accept sessions a= t the
> wrong version


NSS too.=C2=A0 This is the right thing, I think.

I have no objection to making this a requirement in the spec.
--001a1140c1acaa57bc052f47d5ab-- From nobody Wed Mar 30 11:03:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09C512D826 for ; Wed, 30 Mar 2016 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 cVkf6vjCAbhS for ; Wed, 30 Mar 2016 11:03:43 -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 E1E7112D844 for ; Wed, 30 Mar 2016 11:03:42 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id i4so22977252qkc.3 for ; Wed, 30 Mar 2016 11:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M4AIvapvuGeaX1oG2M5g97Gkvav0tdIvC1AaLP9pEzk=; b=eEFN21BWGdgnKvhVR54KjMaQdLYR9wy3XXwn8FzSBTqcDQQnnqkW2Ib9ph93k4t8l4 liVYb8jE1hI9Oz29+4tpJqmF1s/Ex/eQ8eEDBCYe/PryADZUVoWjeH+ux9mA2giyytqq yW/+xF7UobfUZykccHSfHZOhERL6R9TQxKXU4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=M4AIvapvuGeaX1oG2M5g97Gkvav0tdIvC1AaLP9pEzk=; b=QRRKr7GCvIaq9tPmPmKAACd7rZE0NMAyqzNGyjYVrKe8evqzi0yShUpiKIOV8AiBxk 004IliGNW2MWDb6qUaaGAnNbDo8Ztu+gYtQ3UbZiaLr8UEAZBcsk8wSfBcJR51zVswwL UoqK0wpYEfyEZTaRKk5WPd+zdmt6YdrvmcsuPDzA1Iy0omrf1wqrvOAYpwEI3pDcow3k y7e79tmFpvIZ5LFj0FyQnEx+kLvVNuEsZ07jzURN8maxHAPD/lNTNslHVg0EbI5d/tYv LvxPowj+ROe9ygGinVLKayCGxXYbPCciFB2QrgWRSkpB4V/pUrit7i2ayb7PMBvxlSuh wx2g== X-Gm-Message-State: AD7BkJKHuCbtURW2W4BykwUdgLqO57QaCxxWlBrsFPkRBmiZChhlofuu4zZCVo5kEQwkXg== X-Received: by 10.55.41.16 with SMTP id p16mr11507811qkh.86.1459361021918; Wed, 30 Mar 2016 11:03:41 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id b69sm2310281qka.2.2016.03.30.11.03.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 11:03:41 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <3F32A6CE-DE7F-4230-8077-AE2CC1161235@gmail.com> Date: Wed, 30 Mar 2016 14:03:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <3F32A6CE-DE7F-4230-8077-AE2CC1161235@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:03:45 -0000 I apologize in advance; this is about process so it=E2=80=99s long. On Mar 30, 2016, at 01:29, Yoav Nir wrote: >=20 > Hi Sean >=20 > I also strongly support this. I=E2=80=99m just wondering how we plan = to enforce the "stable, publicly available, peer reviewed reference=E2=80=9D= part. As your examples below show, the reference tends to be an I-D. = That=E2=80=99s stable and publicly available, but we have no idea if = it=E2=80=99s peer reviewed or who the author=E2=80=99s peers are. Note that I think both the cipher suite assignment specification and the = algorithm specification need to be "stable, publicly available, peer = reviewed reference.=E2=80=9D Normally, the former informatively refers = to the latter. [0] The algorithm specification is not always an RFC, = but the cipher suite assignment specifications have been; this plan = changes that under certain circumstances (see below). As far as stable and publicly available are concerned, these are part of = the process now, as specified in [1] (and if the update ever gets done = in [2]): Values and their meanings must be documented in a permanent and readily available public specification, in sufficient detail so that interoperability between independent implementations is possible. When used, Specification Required also implies use of a Designated Expert, who will review the public specification and evaluate whether it is sufficiently clear to allow interoperable implementations. The intention behind "permanent and readily available" is that a document can reasonably be expected to be findable and retrievable long after IANA assignment of the requested value. Publication of an RFC is an ideal means of achieving this requirement, but Specification Required is intended to also cover the case of a document published outside of the RFC path. This definition gives power/discretion to the designated expert (it=E2=80=99= s ekr btw). We can: a) defer to the expert's judgement (some of what they are to do is in = [1][2]), or b) write some rules for the IANA considerations section that they=E2=80=99= ll follow. I think that a) has worked in the past and would continue to work in the = future, but b) couldn=E2=80=99t hurt. If we go for a) then if the expert = is ever unsure, they can just ask the AD/WG chair/community for guidance = [3][4]. Beware that the text for b) will be like a bright light for = process moths [5]. As far as peer review, this is where the silent =E2=80=9Cc=E2=80=9D in = team comes to play (c is for community). If the expert is not sure, = then they'd ask the AD/WG chair/community for guidance. We could also = use b) to provide some rules, which could include references to BCP 61 = [6] (and for MTI algs [7]). > One other thing, in some of the links you pasted below you give a = specific draft version (like = https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt) while = for the others you give the generic version (like = https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/). The former is = stable but the latter is not. Are the authors free to keep modifying the = specification after getting the code point? Sorry I wasn=E2=80=99t clear. The references I listed were not supposed = to imply stability they were just the list of cipher suites Joe and I = have received requests from over the past year. I don=E2=80=99t think = that authors are free to keep modifying their specification after = getting a code point, because of the Specification Required definition = [8]. Some other things we should be clear on: 1. All of the drafts referenced and the future drafts requesting code = points do *not* need to come through the WG. But, I do think drafts = that want a =E2=80=9CY=E2=80=9D need to come through, and we shouldn=E2=80= =99t kid ourselves most folks will want the =E2=80=9CY=E2=80=9D. How = does this sound (here I assume the algorithms are already published = elsewhere i.e., this is just for the assignments): a) For MTI and =E2=80=9CY=E2=80=9D requests, a.1) requester=E2=80=99s publish individual draft, a.2) requester=E2=80=99s ask for wg adoption, a.3) wg chairs do adoption call, a.4) wg does its thing on wg draft, a.5) ietf does its thing, and a.6) iana (assigns #s) & rfc editor (publishes) do their things. b) For all others:=20 b.1) request is submitted to IANA, WG, WG chair, AD, b.2) request is redirected to designated expert, b.3) designated experts reviews request: -- if good-to-go designated expert tells IANA to assign code point (goto = b.4) -- if not-good-to-go for an obvious reasons the designated expert = rejects the request with some rationale (and probably lets the sec ADs = know about it) -- if not-good-to-go for all other reasons the designated expert asks = (expert's choice depending on the situation) AD/WG chairs/community for = guidance b.4) iana makes assignment and includes the cipher suite assignment = specification reference in the registry (and possibly the rfc editor = does their thing if an RFC is being published) Early assignment rules can still apply to a) and b). 2. As far as draft-ietf-tls-pwd, we need to decide whether it should = continue as a WG draft or free Dan to pursue other publication avenues. 3. We should avoid a long list of =E2=80=9Cupdates=E2=80=9D to TLS1.3 = RFC#-to-be when new cipher suites get added. Drafts should only include = an =E2=80=9Cupdates=E2=80=9D header if we=E2=80=99re modifying the MTIs = or we=E2=80=99re adding a new =E2=80=9CY=E2=80=9D cipher suite because = we only expect all implementations to support these cases. 4. WRT language - I=E2=80=99m assuming we=E2=80=99d continue to have = English versions of the algorithm specification. spt [0] One reason is that the CFRG doesn=E2=80=99t publish standards track = RFC so the references to algorithm specifications that come through the = CFRG need to be informative. [1] https://datatracker.ietf.org/doc/rfc5226/ [2] https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ [3] No worries - there is of course process to replace rouge experts, = for experts to appeal said decision [3a], etc. [3a] Section 6.5.1 of https://datatracker.ietf.org/doc/rfc2026/ [4] If history is any guide, I doubt the TLS mailing list is going to go = away even if the WG closes (e.g., mailing lists for stalwarts like PKIX, = SMIME, SSH are still around). [5] Note that I very much want to avoid the following very deep and very = dark rat hole: establishing an IANA registry of approved reference = organizations/sites/etc. that the expert can refer to for a =E2=80=9Cfree = pass=E2=80=9D org/sites/etc. {rant: [~5~]} [~5~] { rant: If we do go down this rat hole, I=E2=80=99ve got some = specific organizations in mind that we should ban from ever being = included in this list until they publicly state that they=E2=80=99ll = allow normative references to IETF RFCs in their = documents/standards/etc. And, now that I think about it maybe we=E2=80=99d= include some country=E2=80=99s too. (I warned you it was a rant) } [6] https://datatracker.ietf.org/doc/rfc3365/ [7] https://datatracker.ietf.org/doc/draft-rsalz-drbg-speck-wap-wep/ [8] I=E2=80=99m sure this rule has been broken at some point in the = past, but it=E2=80=99s not one I=E2=80=99m advocating that we break it = on a regular basis. > Yoav >=20 >> On 30 Mar 2016, at 4:53 AM, Sean Turner wrote: >>=20 >> Hi! >>=20 >> In Yokohama, we discussed changing the IANA registry assignment rules = for cipher suites to allow anyone with a stable, publicly available, = peer reviewed reference document to request and get a code point and to = add an =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This = change is motivated by the large # of requests received for code points = [0], the need to alter the incorrect perception that getting a code = point somehow legitimizes the suite/algorithm, and to help implementers = out. We need to determine whether we have consensus on this plan, which = follows: >>=20 >> 1. The IANA registry rules for the TLS cipher suite registry [1] will = be changed to specification required. >>=20 >> 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with = two values: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D. Y and N have = the following meaning: >>=20 >> Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has = consensus on >> and are reasonably expected to be supported by widely >> used implementations such as open-source libraries. The >> IETF takes no position on the cipher suites marked with an >> =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but = can) >> mean that the ciphers are not cryptographically sound (i.e., >> are bad). Cipher suites can be recategorized from N to Y >> (e.g., Curve448) and vice versa. >>=20 >> 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on = [0]) that matches the above so that the same information is available to = those who don=E2=80=99t read the IANA considerations section of the RFC. >>=20 >> Please indicate whether or not you could support this plan. >>=20 >> Thanks, >>=20 >> J&S >>=20 >> [0] In the last year, the chairs have received requests for: >>=20 >> PSK: = https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ >> AES-OCB: = https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt >> Kcipher2: = https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ >> dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ >> NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt >> JPAKE: not sure they got around to publishing a draft. >>=20 >> [1] = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-4 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From nobody Wed Mar 30 11:06:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9561412D7DD for ; Wed, 30 Mar 2016 11:06:58 -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 Ax12pbg1BE8d for ; Wed, 30 Mar 2016 11:06:56 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3D212D7D2 for ; Wed, 30 Mar 2016 11:06:56 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id o6so23039986qkc.2 for ; Wed, 30 Mar 2016 11:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F+rHTuywVYt5vER0Urllbt37ztXElZLR37osAEXiMRk=; b=LdQ1OxPbrKhBn8Mv1Z9fV05hNKvesFNgNof9Pon9AgAaObptxowWhAuxoYrJi1XLV3 ovGcNT88pFDetG6i4Lj1UIlEWm6Lk20NKCGNWn46NnqY0+90CUODcpxXZVg+EGs0BpC8 gMiyVYttkixUg+wH+z+K1B/ShfnmqoWBZ1X9U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=F+rHTuywVYt5vER0Urllbt37ztXElZLR37osAEXiMRk=; b=Rd6W+2VNko5iNlNSBSPXLvtCe8aFDJxrkagqmQRY0m0aUvUx2eyRsYi5+XOBZKoqYB ibl+ejW4Vk5CjUgdp3dEJMbW4LrPQX+ffQW8KrLyhktZv2sLNPOWM8AduwFZXv6fy4Lc ly+oNILWqxNkjbOd234fATnMtZERQnYq95yKusWdVvPXdwvTj/IHcLeCJ6+Oq1oNnPO7 tzaqTlTM0eCtsXnOMD7wUnmhmOg3PxZQ1SEIXNLnydCeZsEU8Xi7955b1+hlvR10jyAH QoniV+zPnCCeCL9S62c48r4cg+DVRGyIWCOaaDaMNw65suX/RHv8rbh13pLL1D60G1l7 KAGw== X-Gm-Message-State: AD7BkJJI+5JJMZX+mBtMRm32jOcIp41b/uSrqhmFEZWXen8T/KqMjNI+F7tvtLUTrP5gkg== X-Received: by 10.55.77.4 with SMTP id a4mr11647993qkb.57.1459361215717; Wed, 30 Mar 2016 11:06:55 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id g64sm2270967qkb.44.2016.03.30.11.06.54 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2016 11:06:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <56FBF1B5.8030906@akamai.com> Date: Wed, 30 Mar 2016 14:06:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <31C2E102-65F5-4149-9041-4814D48BC6CA@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:06:58 -0000 On Mar 30, 2016, at 11:33, Benjamin Kaduk wrote: >=20 > I support this plan (with the expectation that the IANA "specification > required" rules take precedence over the informal text in this mail > about a "stable, publicly available, peer reviewed reference = document", > as Yoav noted as a potential issue). Technically, the =E2=80=9Cspecification required=E2=80=9D rules are the = IETF=E2=80=99s [0][1], but yeah these rules win over this email thread = all day everyday. spt [0] https://datatracker.ietf.org/doc/rfc5226/ [1] https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ From nobody Wed Mar 30 11:56:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249AF12D8C5 for ; Wed, 30 Mar 2016 11:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 7rI0uMG77dwL for ; Wed, 30 Mar 2016 11:56:35 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id BF59C12D8C6 for ; Wed, 30 Mar 2016 11:56:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 9464B5235; Wed, 30 Mar 2016 21:56:33 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id x8s_vIA5JfML; Wed, 30 Mar 2016 21:56:33 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 535E82315; Wed, 30 Mar 2016 21:56:33 +0300 (EEST) Date: Wed, 30 Mar 2016 21:56:32 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160330185632.GA771@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160330051554.GA28336@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Narrowing the replay window X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:56:38 -0000 On Wed, Mar 30, 2016 at 08:35:31PM +1100, Martin Thomson wrote: > On 30 March 2016 at 16:15, Ilari Liusvaara wrote: > > Only if using 0-RTT auth, which seems is going to be removed (yay). > > My reading is that Finished is always present. That is, the > authentication messages are always sent, with > Certificate+CertificateVerify being omitted if there is no > certificate. Oh, yeah, looks like there is always Finished. Does not simplify implementation in any way (just makes implementation even more complex). Then on topic of 0-RTT, how does 0-RTT key hashes behave if handshake is restarted (main handshake hash continues, but 0-RTT hash context currently needs to be separate from the main context)? -Ilari From nobody Wed Mar 30 12:20:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2346012D8EB for ; Wed, 30 Mar 2016 12:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 T-gpt2Btw7-W for ; Wed, 30 Mar 2016 12:20:13 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id CF9D512D8DC for ; Wed, 30 Mar 2016 12:20:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2E78E489A; Wed, 30 Mar 2016 22:20:09 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id GzkyUs5J2hvm; Wed, 30 Mar 2016 22:20:08 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id EBEF3287; Wed, 30 Mar 2016 22:20:08 +0300 (EEST) Date: Wed, 30 Mar 2016 22:20:08 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8737r8ymrd.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:20:15 -0000 On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > I am not sure that we want to be in the business of explicitly marking > > things as insecure other than our own RFCs, though -- there could be an > > implication of more review than is actually the case, which is what this > > proposal is trying to get rid of. > > I think i agree with Ben here: if we have a tri-state: > approved/not-approved/known-bad, then the people will infer that the > not-approved ciphersuites are better than the known-bad ones, which > isn't necessarily the case. > > I think i'd rather see it stay at "approved/not-approved" Then how should ciphersuites with explicit diediedie RFCs (currently RC4) be presented? -Ilari From nobody Wed Mar 30 12:45:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E09512D8F6 for ; Wed, 30 Mar 2016 12:45:17 -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 DbjvX96CVoXi for ; Wed, 30 Mar 2016 12:45:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 4B74712D7F8 for ; Wed, 30 Mar 2016 12:45:15 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 02D43F997; Wed, 30 Mar 2016 15:45:02 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 0257F2003D; Wed, 30 Mar 2016 15:45:02 -0400 (EDT) From: Daniel Kahn Gillmor To: Ilari Liusvaara In-Reply-To: <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 30 Mar 2016 15:44:59 -0400 Message-ID: <87egarbvic.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 19:45:17 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote: > On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: >> > I am not sure that we want to be in the business of explicitly marking >> > things as insecure other than our own RFCs, though -- there could be an >> > implication of more review than is actually the case, which is what th= is >> > proposal is trying to get rid of. >>=20 >> I think i agree with Ben here: if we have a tri-state: >> approved/not-approved/known-bad, then the people will infer that the >> not-approved ciphersuites are better than the known-bad ones, which >> isn't necessarily the case. >>=20 >> I think i'd rather see it stay at "approved/not-approved" > > Then how should ciphersuites with explicit diediedie RFCs (currently > RC4) be presented? i'd say that they are "not-approved", clearly. :) We don't represent those RFCs in any way at all right now, and yet they seem to have some kind of social impact. I observe that we have a "notes" column in the ciphersuite registry currently, which indicates one or more RFCs related to the ciphersuite in question: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-= parameters-4 I'm a little disappointed that RFC 7465 ("Prohibiting RC4 ciphersuites") isn't listed in the Notes column for all ciphersuites using RC4. Perhaps that change needs to be made as well? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJW/Cy7XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKQRkP/3Ub1VybsrFYrV4CHYIGGqQY koYgudXoGDVGO9CJ247A2VnGFHw21hXeN75XPI09NOdVZQ3trd1q6afuA2nhtwEX IocWvmCshDr4clDGNWLaWAoLEAWyAWzMjCaWg1pef64uJg5b/iFzj0utOgVpvXn4 g68q82ObJnmjBRx2Rj8//uyYG+Ua+rWF05twdV7cflIrrtiezVlHV5pV+hfwwbSF BOGK/vbwxwWnU/mjvp0IPKeaapoVab9A31z7FMW0FUvkGHFdVodenT7odvLi8wgO V5kgOHEO7YwHiaUbzHAJk9hLha1PeyxiMHMeDZCa6JQz0ovTgzaLbzCL9UAA2fuK maVJyX6G0kHymO6nkOg4RgHg9rsGof/kzeaJlMqpAS4Zwh7/x+pl9VFZbLgQ3gAM SAIXt9DUvl18r/Mxr1WxYOHKS7rLtbEJX8CpZ+P6shDIDWl3bjxpb6L/iDkczFoz VZRTsrfNzTpo+mG0veZcQguKVWk4QdOnew+8rHbIt+T8AFRZM2CEuXI3XMS6Fos3 x4A6gL5yvBmJAFl2s8NOfP+p1JI2HgSBx2PVSbP3I4bGSdVXYapqsPtgJFQ2UiRj +oEcPVBrVc5R7wsZQ18/NNxL2WChHNFFMi0qXsXyoRRVAq+dqeBJ05u/6wVnUbnF mjPClGlAINTskfW/tzA0 =7eyZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Mar 30 13:24:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1912D97A for ; Wed, 30 Mar 2016 13:24: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, 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 bInBGv89zofX for ; Wed, 30 Mar 2016 13:24:15 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::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 688AB12D965 for ; Wed, 30 Mar 2016 13:23:55 -0700 (PDT) Received: by mail-qg0-x235.google.com with SMTP id j35so49503340qge.0 for ; Wed, 30 Mar 2016 13:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=7oZYvtg/DfKmQY3a0LFDpQaMY9BjLXsATSo7NEvC3kA=; b=cHPBgzeSPe7u/Hs6CMcSQhXjBQ4mNrdRPxhGyKHgh8herGImpV0mQhZhb8ShpIvxl4 b7/uY5B3r1N5Gu+EWPhCHE9QB6CAcIyxdFH9tX6lJ6oi1Bl5CcBLkaT6yQbdt8+liJKs 3j4g9JFEVfDoccwFul5AjhtLZNQJea9eKDbsKUXtF+G5wag2xBel+XDVFzw19V1xoaHj Fbw03gbh63rbWbGj39ORPSnwTnEwGUdMfgUK83YS3YDF8zfxAgfhvHGlOzFR3b6KlJzj HrF1+sDV4pwxhrTRJO8Q+s1RrRBDG8xsYfz+TGBdcVj6Xxrrok16YIzz5oaKvMFPkFor sYpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=7oZYvtg/DfKmQY3a0LFDpQaMY9BjLXsATSo7NEvC3kA=; b=WFIgDP9NI5hX7WaHtMgpJ/hCqIt9H6/kXzaAYzeoWBlJssvuf+PcvwDUPn3UodD0QS 2ckJiSFHSskdv4rP4cQ/Y38qJtYI/QyuW0YJbwy2CMchXYRtN9nQNZos0PSh1308tX1V HY8vMjUGso6EpSsNTM5+FpfCLj+vd82Zh26/G7UJrqvBPr4oEUg71zqImHuNFGLcVzAL 3weuFDQibwnT/Up4NCCkg4pPkPlUyxy58gxAnU2IVhmRCz2Zum7vWPQH17JzWcsgXqSc G1MYoLfD4TCSj7D28q4C0PwCVTIyoP2VwxTTF8j6lAMbyxeXH9eyOP8yYyp3ZGsXa7q2 2Srg== X-Gm-Message-State: AD7BkJL+e3jUgJbUrOB6t+N4wTxF2nhk87WQW/5uPdLIlgfYblKQbBGY5aFerTuQ1NlgbQ== X-Received: by 10.140.237.204 with SMTP id i195mr13264597qhc.55.1459369434520; Wed, 30 Mar 2016 13:23:54 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id z62sm2558530qka.26.2016.03.30.13.23.53 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:23:53 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 30 Mar 2016 16:23:52 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201603301623.52658.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:24:19 -0000 On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > PKIX. Adding a PKIX extension to mandate a minimum threshold of security configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS <1.2) would also be great to have. In fact, if an intermediate could also set such a requirement and have that be required for all end-entity certs signed by it, that'd be a great way to protect against downgrades. Dave From nobody Wed Mar 30 13:28:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D362612D832 for ; Wed, 30 Mar 2016 13:28: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 zm3WYJ2GqckX for ; Wed, 30 Mar 2016 13:28:34 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332F012D92A for ; Wed, 30 Mar 2016 13:26:54 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id 20so86556087wmh.1 for ; Wed, 30 Mar 2016 13:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=ovoUtamn+oeUq0zend3bqF5whZ2dBdZR+h3qKBB1RTo=; b=oj5hkQHfQldCQssQ+WVqtpKTqI5UN8BQqZaWdvsxy34lFkhV1jdoFC5iHALk976oCo rYt8b3pkv8RzHxd7rVFomp8Qoks7wVKP+LkcBkVjrqijPFNW81TDPtsuxuFBIvtAPXEb pcsaqjU5mTbEIDVa3sD1G9iVx8YD3RXUNKzUmBODMEW/FBWkZOMcjumxtkjBCvli3D2e dimA5jxllow/hypm1Dbiu3lAB7dJ7t3eT5GpF42ljvX9nHDcbU9bhBo1cBS+D/IWpveW KDQUzBeOSc5sP/xZfjN/BIrJUg5SgyqXkulCymrOWXM/4cwEz6Fr8+m7KOmzb+BNJ2mg o3Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=ovoUtamn+oeUq0zend3bqF5whZ2dBdZR+h3qKBB1RTo=; b=ASrMGHJ4nKPtj7/jJ37NDvWEu+Cbhf2A/CB8YxJWXYlSZUiUCkJknPSZCY6gbYXa4Q 2Y+z2A/cE7XcXofsVBEJFSl3B8VWek+rJExgvmnjugfQI0iRna+9KNNH3JxxWsfnEw1j ya5dU7eFHriXSbBiNgtrlSscjGWI8FDVki2N1/bFB5Pvt82MLq1Gf9dZuEMvKEbxnB0w iZ2WYaraWg6/5NN44lfpoYtdV5OTBSku/ERUAL9RoCBZglMugaIRDQZrvVP82kU2oN8Q y8lFKx/q4EOIUuJWtrAVxSF8GttOKWmMGB++kpiDS1GGIUEB6D0cq6uQq06IEOiVyeRz PShg== X-Gm-Message-State: AD7BkJIScudBTADhzkXWR8t0+1Gu15TJwcynoGETsWM3AINPP5XdjKyVlUXPcmucxcEmHQ== X-Received: by 10.28.35.86 with SMTP id j83mr3715429wmj.25.1459369612728; Wed, 30 Mar 2016 13:26:52 -0700 (PDT) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ls5sm5570756wjb.33.2016.03.30.13.26.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:26:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DAE46F9A-20AD-4A90-BFE2-D76009571257"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <87egarbvic.fsf@alice.fifthhorseman.net> Date: Wed, 30 Mar 2016 23:26:10 +0300 Message-Id: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> <87egarbvic.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:28:36 -0000 --Apple-Mail=_DAE46F9A-20AD-4A90-BFE2-D76009571257 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 30 Mar 2016, at 10:44 PM, Daniel Kahn Gillmor = wrote: >=20 > On Wed 2016-03-30 15:20:08 -0400, Ilari Liusvaara wrote: >> On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: >>> On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: >>>> I am not sure that we want to be in the business of explicitly = marking >>>> things as insecure other than our own RFCs, though -- there could = be an >>>> implication of more review than is actually the case, which is what = this >>>> proposal is trying to get rid of. >>>=20 >>> I think i agree with Ben here: if we have a tri-state: >>> approved/not-approved/known-bad, then the people will infer that the >>> not-approved ciphersuites are better than the known-bad ones, which >>> isn't necessarily the case. >>>=20 >>> I think i'd rather see it stay at "approved/not-approved" >>=20 >> Then how should ciphersuites with explicit diediedie RFCs (currently >> RC4) be presented? >=20 > i'd say that they are "not-approved", clearly. :) That brings up another question. How do things move from =E2=80=9Capproved= =E2=80=9D to =E2=80=9Cnot-approved=E2=80=9D? Does it require a diediedie = document? What happens when we decide that 3DES is just too limited and = there=E2=80=99s not good reason to use it, but there=E2=80=99s really no = security issue with using it? Yoav --Apple-Mail=_DAE46F9A-20AD-4A90-BFE2-D76009571257 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW/DZiAAoJECXR4BOacZZUpWIIAK9UDdGAVbLVuFHfLDYKbi9w e0ZWAPrnEkHVmEZ47vgxbuTPCqGis9eEHgUsxukEor0BbQF8iN3MP9yQ+/4ijWIX XD4v51wOWCYH4q9dG4QpQ27vvXOGch37ErksmX6mhU4dIABqXUmrfM/FE74JlGXH RTeWZLizmSFdSG0FkFOb7ckAxVOqBRHaA7MPO5T1NtelZlHudUQswkFZ37nGrZ4k B5NWSeF+qUp6WQQYsvB6ms4qtPANfyiAq028V9Q0rU6ZLARIVKN6e1MzX9lY5E5x uFHRr9fUrxHJx8vYn12w+FJ8yC80ypKAnHyHVk7qWZy9sTHzUAt55X6K0ElW8rM= =0MXq -----END PGP SIGNATURE----- --Apple-Mail=_DAE46F9A-20AD-4A90-BFE2-D76009571257-- From nobody Wed Mar 30 13:32:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A89812D832 for ; Wed, 30 Mar 2016 13:32:06 -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 FxyLkAjynTsj for ; Wed, 30 Mar 2016 13:32:05 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 C618712D0B0 for ; Wed, 30 Mar 2016 13:32:04 -0700 (PDT) Received: by mail-qg0-x234.google.com with SMTP id j35so49682714qge.0 for ; Wed, 30 Mar 2016 13:32:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=iHeUfSzNsUb4NTjnUY7tWYzlbsowQaPePrHmKpF25Jk=; b=lOvYp0CDq6BJBlzxHSg4ZExLamAid0S9b5Qo0eZH+cUt2CjXu7HHyL3WC63mJie8PB 1CEdcv+loKJq/3KDKmkX5Tjy0S4ds7SJDjdGe9T67pW3Zlz6gpGRk2nMRdsyO41OcDNZ lBHcH+3TOnmervqfkzhzNL0L7x/EqWDQUawF049qURaNmUThaSu787ChJIQVtAp6Y/U+ GAktgTSNzx3ka9LNwxS06sj7d2GOUrAZz0kNvvSLP/Ynk5QvTBX121NeZUIRQhUaREki G2eNfA9jCuk1fAKqRkAtCoGETErCxvfNfAY1exTngLjIQEwaOdf4T9QqgWsu53T7lMGV qRlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=iHeUfSzNsUb4NTjnUY7tWYzlbsowQaPePrHmKpF25Jk=; b=hnjX0RXPl21ZeCcmTHHcuYhwvUiUyNp3RQRRUBD9dVhg/FF4Ij4v9GtplT+2qSY7Th pPPReamc09Jt9tXWv4QYFzrBSkbjCXT3mf+2tgsxYCo+XDs/vvEHQ0QPx+phBIo8Otlq x83fokebx8LsWGHjh6gu5ebCtMI3eMP+OER8BtKUxC8123Jk9oFMx1qEbnAMFKs3aJL8 ytVjGhUjWBrLSroEfNluoWue9A5xLP8/sWYiLVAeYFO2E4E0R9kxaXtbIh2SGbLJtmra eJRtQp+4XNtdupQcsUFDUTEkSXx7l5UZ+RkxEosTl2c0FGSHJotc7HvjSQ9rMbANGVqb AhCQ== X-Gm-Message-State: AD7BkJKH+TJ+KzkYMUoPGoyjhtFG5Dn6+McKpkeBFhC/yQ3RSGZPCgwLFuBz4LTVGgtBkw== X-Received: by 10.140.32.245 with SMTP id h108mr12330819qgh.50.1459369923863; Wed, 30 Mar 2016 13:32:03 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id 139sm2574372qho.2.2016.03.30.13.32.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 30 Mar 2016 13:32:03 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 30 Mar 2016 16:32:02 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201603301632.02431.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:32:06 -0000 On Wednesday, March 30, 2016 03:20:08 pm Ilari Liusvaara wrote: > On Wed, Mar 30, 2016 at 12:05:26PM -0400, Daniel Kahn Gillmor wrote: > > On Wed 2016-03-30 11:33:09 -0400, Benjamin Kaduk wrote: > > > I am not sure that we want to be in the business of explicitly marking > > > things as insecure other than our own RFCs, though -- there could be an > > > implication of more review than is actually the case, which is what this > > > proposal is trying to get rid of. > > > > I think i agree with Ben here: if we have a tri-state: > > approved/not-approved/known-bad, then the people will infer that the > > not-approved ciphersuites are better than the known-bad ones, which > > isn't necessarily the case. > > > > I think i'd rather see it stay at "approved/not-approved" > > Then how should ciphersuites with explicit diediedie RFCs (currently > RC4) be presented? A tri-state that might be more acceptable would be approved/not-approved/amended, where "amended" indicates an RFC released after the initial specification that is considered mandatory. This would be both diediedie RFCs as well as any sort of less severe update, without as much implication that "not-approved" automatically implies safety. Dave From nobody Wed Mar 30 13:33:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5104812D971 for ; Wed, 30 Mar 2016 13:33:45 -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 N9BTaIcqizd6 for ; Wed, 30 Mar 2016 13:33:43 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 E146112D92A for ; Wed, 30 Mar 2016 13:33:42 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id z68so76963539vkg.3 for ; Wed, 30 Mar 2016 13:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lujZlxsfkS6DJbJW/HmnxuPs97bKiKsis5LDyaCdFdk=; b=B2HzrxMrC5gdwDVsH0fRLndhLfCrenl4rtJs1ZtQfXhRBmVFIZwZMfOn1fAXF27236 7//xOI+duFTkgbazYqbx5z27KhqnJ4r/RyP8cbtcVzp/Ijk6XOCGzci/fvWtEdEsBg7E lHc/4fnC+Fwtgclcrvq7qRv61q3PgwVP0zjzNExK5AOeekM/8NqhstJBZGU88lD+8HDo i95E91xC/s9KYALA+frCSMrkEfxWtxGJ/Til2951p3g3HhxNouEosP/puKoeYjNwnAXy hbRmehrTGiTVHnPJSATxtfrdmBmmwsIcZJjIBLHYwbBl13GGyB/YIp+GtW5oVAdphRhP 9znw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lujZlxsfkS6DJbJW/HmnxuPs97bKiKsis5LDyaCdFdk=; b=jvZXcxJhIVaO/DOiLLwHRvC9y/l0cj5ZPXDSDV3Y7MdHadtrOlaZMs7hCCHCGVlUpd lxOxQEeVMLL8gV02TtSzBsJneyvgt4GK52hZkZirhzUwDjlfgLutbI9cZfWY8M5isoMF 2vl/xhi9RV6fNtk68nxPRdzXsh60muylgOUafs65iHw1nLmLwQA/0ZBEj6VL7vwWiUzs fP4fFHDqQr7WWxhmNSnKpRcOSGwr8cyRaU0HWru/qLdOgfIGvtRM7pJXW998Gbrx74Hr v+ExZJkPKG+xq02DUpqY4QWHUIWYDjeW2CeMf+OdyaBy6IRhp7RIDfe1xhnGkNkUoqQ9 MGaA== X-Gm-Message-State: AD7BkJKJJHcGBX1icWpPnuzg2fsohYShbumAi+EYQ8G7P5h2LMRzlT5318JEhXl7vvBortUQ0xUoNUpH8McB+g== MIME-Version: 1.0 X-Received: by 10.31.54.134 with SMTP id d128mr6173548vka.26.1459370021963; Wed, 30 Mar 2016 13:33:41 -0700 (PDT) Received: by 10.176.1.208 with HTTP; Wed, 30 Mar 2016 13:33:41 -0700 (PDT) Received: by 10.176.1.208 with HTTP; Wed, 30 Mar 2016 13:33:41 -0700 (PDT) In-Reply-To: <8760w4ymvu.fsf@alice.fifthhorseman.net> References: <8760w4ymvu.fsf@alice.fifthhorseman.net> Date: Wed, 30 Mar 2016 13:33:41 -0700 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a11438ee8c14ca1052f4a0fe9 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:33:45 -0000 --001a11438ee8c14ca1052f4a0fe9 Content-Type: text/plain; charset=UTF-8 On Mar 30, 2016 9:03 AM, "Daniel Kahn Gillmor" wrote: > > On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote: > > This got a lot of discussion early in the design process and the consensus > > was that the risk of having the default mode (with existing certs) allow the > > creation of a long-term delegation was too high. See, for instance, the > > relative impact of the recent paper by Jager at al. [0] on TLS 1.3 and > > QUIC. > > > > With that said, I think this would be a good feature to look at in future > > and the right way to do it is to: > > > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > > PKIX. > > this would need to be a critical extension, since the goal is to have it > be unusable by existing endpoints, right? do we have tests about how > well existing endpoints will fail closed in the face of unknown critical > extensions? This won't work to protect against a server misconfigured to use the RSA EE certificate for Bleichenbacher vulnerable handshakes. We would need to limit to ECDSA certs and ensure that the subcert cannot be gamed into being something else that might get signed by a TLS server. > > > 2. Add a subcert extension to TLS 1.3. > > This would be necessary for clients to signal that it's ok to use such a > delegated cert or subcert. we need to think clearly about how to limit > the scope of such a delegation to make it safe. > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a11438ee8c14ca1052f4a0fe9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mar 30, 2016 9:03 AM, "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> wrote:
>
> On Wed 2016-03-30 11:22:15 -0400, Eric Rescorla wrote:
> > This got a lot of discussion early in the design process and the = consensus
> > was that the risk of having the default mode (with existing certs= ) allow the
> > creation of a long-term delegation was too high. See, for instanc= e, the
> > relative impact of the recent paper by Jager at al. [0] on TLS 1.= 3 and
> > QUIC.
> >
> > With that said, I think this would be a good feature to look at i= n future
> > and the right way to do it is to:
> >
> > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]&= quot; extension to
> > PKIX.
>
> this would need to be a critical extension, since the goal is to have = it
> be unusable by existing endpoints, right?=C2=A0 do we have tests about= how
> well existing endpoints will fail closed in the face of unknown critic= al
> extensions?

This won't work to protect against a server misconfigure= d to use the RSA EE certificate for Bleichenbacher vulnerable handshakes. W= e would need to limit to ECDSA certs and ensure that the subcert cannot be = gamed into being something else that might get signed by a TLS server.

>
> > 2. Add a subcert extension to TLS 1.3.
>
> This would be necessary for clients to signal that it's ok to use = such a
> delegated cert or subcert.=C2=A0 we need to think clearly about how to= limit
> the scope of such a delegation to make it safe.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a11438ee8c14ca1052f4a0fe9-- From nobody Wed Mar 30 13:34:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D1E12D989 for ; Wed, 30 Mar 2016 13:34:45 -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 qdmE3YnAEWSl for ; Wed, 30 Mar 2016 13:34:44 -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 23B5812D97D for ; Wed, 30 Mar 2016 13:34:38 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id g3so73226051ywa.3 for ; Wed, 30 Mar 2016 13:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AjZ7TKE99TxQUGdHssmnORhNMdxalAjeJaFF7FtugjE=; b=xRnSFuOn8PkSwa39bla15FWduaqqQ/0yyiMTISPHJNrJdGRsZeZFpLdwyq6S7gxGOi U0IZyrWZeFi25zSTOX+mWe//i7z9E/PUBS5oSC/334Njprn6qcucQ/aB/AfDUwKgqPHW zKhljCVGH3iWKdGu+A4A2uSF+UTzx4DZQ/yw4tgKw9rfVTxkp5SGmwL9Cqb8/Xoiae9j 39CXTqwoOgJSIz5tJyY9V9rl7J+hvFh/I5ilLF9VfAiR3GO3TbMtkMSdW+QZSvWdEZxn Se3aak/1aMTyhkh0tjJW9+mQqh/N/9+oTi+3FzpUUGtVaPI4RotgDzUkfJQGYi+LuKwF bYJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AjZ7TKE99TxQUGdHssmnORhNMdxalAjeJaFF7FtugjE=; b=VtnJtfFEaYSIhuMUgWHR5KAYjPMeFLkmxGEI/H/uE0l9tpwr0RwcpJ4Vfm+xwH1gVF c7ZWUknNRP9y6UbNPwTmnKXv1Fpd/VHpa7XXXbHSUuZIaYLnTYML+tv50mK4O2PXxn1U 61rK3TYmdrTs51h84eisbNVlHWIcbQxgRptatSNklurx08X0eUaYGKXXO+dQxA01z33A HWJEhNIWDSk1n+XijwURdKCnGf564iwCpkkmEzUU90Usek69Ub1jhLr2rnYzMryIZpcn ouywqNO1FvftzYepa8D141hRs+TkUN4SL5Dtibwcyn7/2tokxorVbxhTCNZQtW0mpNe3 EJag== X-Gm-Message-State: AD7BkJIiSfzljijFkK3s6L8amIiRR5OvsFGn2iVHDzwL33Kklykx3lYpiXCa41iEM6pdIfL/T2frYu8l5NWvuw== X-Received: by 10.129.80.69 with SMTP id e66mr5959900ywb.231.1459370077399; Wed, 30 Mar 2016 13:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 13:33:57 -0700 (PDT) In-Reply-To: <201603301623.52658.davemgarrett@gmail.com> References: <201603301623.52658.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 30 Mar 2016 13:33:57 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a1147f0780fc8b3052f4a13f1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 20:34:45 -0000 --001a1147f0780fc8b3052f4a13f1 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett wrote: > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > > PKIX. > > Adding a PKIX extension to mandate a minimum threshold of security > configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS > <1.2) would also be great to have This seems like a fairly blunt instrument. Better to make sure that TLS's negotiaton mechanisms are reliable and trustworthy. -Ekr > . In fact, if an intermediate could also set such a requirement and have > that be required for all end-entity certs signed by it, that'd be a great > way to protect against downgrades. > > > Dave > --001a1147f0780fc8b3052f4a13f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> 1. Add a "this is only usable for TLS 1.3 [or for subcerts]"= extension to
> PKIX.

Adding a PKIX extension to mandate a minimum threshold of security c= onfiguration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS &= lt;1.2) would also be great to have

This se= ems like a fairly blunt instrument. Better to make sure that TLS's nego= tiaton
mechanisms are reliable and trustworthy.

-Ekr


=C2=A0
. In fact, if an intermediate could also set such a re= quirement and have that be required for all end-entity certs signed by it, = that'd be a great way to protect against downgrades.


Dave

--001a1147f0780fc8b3052f4a13f1-- From nobody Wed Mar 30 14:11:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD74512D95E for ; Wed, 30 Mar 2016 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 jCJnDYg4B6Q5 for ; Wed, 30 Mar 2016 14:11:39 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E92A812D959 for ; Wed, 30 Mar 2016 14:11:38 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 352E143347E; Wed, 30 Mar 2016 21:11:38 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 157A043347A; Wed, 30 Mar 2016 21:11:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459372298; bh=UZkYbsi526XKUYtToUeSQ9lXTcNNxnXbFbO8r1i7tDE=; l=3601; h=To:References:Cc:From:Date:In-Reply-To:From; b=xbNmE2Kek6PqV2UNnJlGM44F7BlYNSpkCtAiOhpEl8qg0m+zZmqnQuRL8Qg4J834V bn6F3GrL/E56/YgvddaNf6BlN1DSP0Z9zQmw5KV5Z34jW48TMFck+HZekmKWppAKTM KqZ4MxhHOEAwhNM4+ZVPeeb6EZialwTHR+/DCdyw= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 909911FC88; Wed, 30 Mar 2016 21:11:37 +0000 (GMT) To: Sean Turner , Yoav Nir References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <3F32A6CE-DE7F-4230-8077-AE2CC1161235@gmail.com> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <56FC4109.7060600@akamai.com> Date: Wed, 30 Mar 2016 16:11:37 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:11:42 -0000 On 03/30/2016 01:03 PM, Sean Turner wrote: > I apologize in advance; this is about process so it’s long. > It seems correct and reasonably comprehensive. > This definition gives power/discretion to the designated expert (it’s ekr btw). We can: > > a) defer to the expert's judgement (some of what they are to do is in [1][2]), or > b) write some rules for the IANA considerations section that they’ll follow. > > I think that a) has worked in the past and would continue to work in the future, but b) couldn’t hurt. If we go for a) then if the expert is ever unsure, they can just ask the AD/WG chair/community for guidance [3][4]. Beware that the text for b) will be like a bright light for process moths [5]. > I feel like (b) will probably result in a lot of time on the list getting the text "just so"; perhaps that time would be better spent elsewhere. That said, I'm happy to help with the editing of such text... > > > Some other things we should be clear on: > > 1. All of the drafts referenced and the future drafts requesting code points do *not* need to come through the WG. But, I do think drafts that want a “Y” need to come through, and we shouldn’t kid ourselves most folks will want the “Y”. How does this sound (here I assume the algorithms are already published elsewhere i.e., this is just for the assignments): I agree ... the chairs should use their power to turn things away judiciously :) > a) For MTI and “Y” requests, > a.1) requester’s publish individual draft, > a.2) requester’s ask for wg adoption, > a.3) wg chairs do adoption call, > a.4) wg does its thing on wg draft, > a.5) ietf does its thing, and > a.6) iana (assigns #s) & rfc editor (publishes) do their things. > > b) For all others: > b.1) request is submitted to IANA, WG, WG chair, AD, That's "one of the above", I presume? > b.2) request is redirected to designated expert, > b.3) designated experts reviews request: > -- if good-to-go designated expert tells IANA to assign code point (goto b.4) > -- if not-good-to-go for an obvious reasons the designated expert rejects the request with some rationale (and probably lets the sec ADs know about it) > -- if not-good-to-go for all other reasons the designated expert asks (expert's choice depending on the situation) AD/WG chairs/community for guidance > b.4) iana makes assignment and includes the cipher suite assignment specification reference in the registry (and possibly the rfc editor does their thing if an RFC is being published) > > Early assignment rules can still apply to a) and b). Sounds good to me. > 2. As far as draft-ietf-tls-pwd, we need to decide whether it should continue as a WG draft or free Dan to pursue other publication avenues. No opinion at present. > 3. We should avoid a long list of “updates” to TLS1.3 RFC#-to-be when new cipher suites get added. Drafts should only include an “updates” header if we’re modifying the MTIs or we’re adding a new “Y” cipher suite because we only expect all implementations to support these cases. I support this, yes -- long "updates" lists can be annoying for the reader. > 4. WRT language - I’m assuming we’d continue to have English versions of the algorithm specification. > If we are using IANA as a service for the global Internet, it is not entirely clear to me that we need to insist on English versions of the "specification required" document ... though the capabilities of the designated expert might affect what would in practice get approved. -Ben From nobody Wed Mar 30 14:43:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B23112D954 for ; Wed, 30 Mar 2016 14:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 mu_mpBpjDmHM for ; Wed, 30 Mar 2016 14:43:30 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 59F2612D95F for ; Wed, 30 Mar 2016 14:43:28 -0700 (PDT) Received: from [173.75.83.83] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1alNtL-0004TK-US; Wed, 30 Mar 2016 17:43:08 -0400 Date: Wed, 30 Mar 2016 14:42:57 -0700 From: Bill Frantz To: Yoav Nir X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec793116b42bf211ea62bc098f0e50ebac75350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.83 Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:43:32 -0000 +1 for the change. On 3/30/16 at 1:26 PM, ynir.ietf@gmail.com (Yoav Nir) wrote: >That brings up another question. How do things move from=20 >=E2=80=9Capproved=E2=80=9D to =E2=80=9Cnot-approved=E2=80=9D? Does it requ= ire a=20 >diediedie document? What happens when we decide that 3DES is=20 >just too limited and there=E2=80=99s not good reason to use it, but=20 >there=E2=80=99s really no security issue with using it? Certainly for downgrading any widely deployed algorithm, e.g.=20 RC4, there needs to be a IETF process. The RFC process works, so=20 we don't need to invent a new wheel. Therefore a diediedie RFC=20 seems the logical choice. I hope algorithms don't get on the approved list unless they are=20 likely to be widely deployed. (But I expect to see counter-arguments.) Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345=20 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos,=20 CA 95032 From nobody Wed Mar 30 14:47:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B325C12D0C2 for ; Wed, 30 Mar 2016 14:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 jgZLfHkZdYya for ; Wed, 30 Mar 2016 14:47:10 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 9506A12D0A2 for ; Wed, 30 Mar 2016 14:47:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 81C0E2EEE; Thu, 31 Mar 2016 00:47:09 +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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id Ck5XnmokIBcH; Thu, 31 Mar 2016 00:47:09 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 3EEDA28B; Thu, 31 Mar 2016 00:47:09 +0300 (EEST) Date: Thu, 31 Mar 2016 00:47:08 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160330214708.GA873@LK-Perkele-V2.elisa-laajakaista.fi> References: <201603301623.52658.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:47:12 -0000 On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote: > On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett > wrote: > > > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" extension to > > > PKIX. > > > > Adding a PKIX extension to mandate a minimum threshold of security > > configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for TLS > > <1.2) would also be great to have > > > This seems like a fairly blunt instrument. Better to make sure that TLS's > negotiaton > mechanisms are reliable and trustworthy. Unfortunately, there's the broken key exchanges, which fundamentally compromise any version negotiation. Yes, one could set RSA KeyUsage to just DigitalSignature, which would nominally disable those broken key exchanges. Unfortunately: - Many clients don't enforce that. - That kind of certificates are listed as SHOULD NOT issue. -Ilari From nobody Wed Mar 30 14:58:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A34412D535 for ; Wed, 30 Mar 2016 14:58:22 -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 7b41UJAQ6GZs for ; Wed, 30 Mar 2016 14:58:20 -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 B02BD12D50B for ; Wed, 30 Mar 2016 14:58:20 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h129so75703199ywb.1 for ; Wed, 30 Mar 2016 14:58:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wBcItHCB4/3ET01InkWMMqdKzTgDpAntNEGiB69wjVw=; b=pgaDGMDjo5ZuxSdX7r9VYayvsr1fMP3pbB3ZgeewVmRxc2DMc1/Lx4wojeFeTTIPm+ coL1rXUYObnDt8tEm0D2A7Ee2EsN2i7AebPBVL2vaJ/j6LPDBupFTBIwkxjG8HLw61Z+ XJ4Aie2AWwZUgmmcYkPxkP4EM2MvTFAEhQZ+X4mhOnIRHrxCViQmPDaBJVMMYQVrIwxe jzGxha1jKydSUf7JBHlFE6/JxghTm+lxKwtAS7rFSXO0+eOE6EyT7FiNpUn2+UovCHtz E7zcc1LLlWyzQ+/8gE5OjQQVltVU0h+OE0NQ22K//lH7Iz1GNpyte6WvfNkCqf8Lt7BU 40xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wBcItHCB4/3ET01InkWMMqdKzTgDpAntNEGiB69wjVw=; b=hF3pgZ7BrKj+K3lWDa22ujkAdfF6G24fxSz17Czg9TSkRHRY0/y+AInUgGvC3Ssk5L zSfJZQ7A/oMGkY3pm7/KTBd74djUgT917NKO9qiHQ/vHoLSBZHXssDN84O5kJTEFoTCF 6KvfT59xmCIO/kgJ1K/5JeN99hUtWpSMA3W5diPy3WpvDUlroZitXknrMdlwEuNUobp8 KUUoCNoq81s6X+y27dT9l2iqU27OWk06bwshljBCIkCX3sJ+ymfL2vaCZPdzxZ9e7YjF oHHNcm4Her8OKzD9vvR+eYtFgCXVOsiV0mLKns7y7IhdPAiTYR4BHyDaZbs6spX+Ka9Z EscA== X-Gm-Message-State: AD7BkJKVv23PqKHPRF0/0sHLxyY9oAhoI3SLPFMeRvMqrME9XNjGbjrQh2IsVU1+hi5e9/2mmHCjxXOAydZg1w== X-Received: by 10.129.92.132 with SMTP id q126mr5471772ywb.155.1459375099879; Wed, 30 Mar 2016 14:58:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 14:57:40 -0700 (PDT) In-Reply-To: <20160330214708.GA873@LK-Perkele-V2.elisa-laajakaista.fi> References: <201603301623.52658.davemgarrett@gmail.com> <20160330214708.GA873@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Wed, 30 Mar 2016 14:57:40 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114d85d66c5628052f4b3e52 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Why again can't we use TLS signing certs to create short-lived sub-certs? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 21:58:22 -0000 --001a114d85d66c5628052f4b3e52 Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 2:47 PM, Ilari Liusvaara wrote: > On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote: > > On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett > > wrote: > > > > > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote: > > > > 1. Add a "this is only usable for TLS 1.3 [or for subcerts]" > extension to > > > > PKIX. > > > > > > Adding a PKIX extension to mandate a minimum threshold of security > > > configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any support for > TLS > > > <1.2) would also be great to have > > > > > > This seems like a fairly blunt instrument. Better to make sure that TLS's > > negotiaton > > mechanisms are reliable and trustworthy. > > Unfortunately, there's the broken key exchanges, which fundamentally > compromise any version negotiation. > > > Yes, one could set RSA KeyUsage to just DigitalSignature, which would > nominally disable those broken key exchanges. Why is this necessary in this case? If you're a server which won't do static RSA, why isn't it enough to just refuse to negotiate those cipher suites? -Ekr Unfortunately: > > - Many clients don't enforce that. > - That kind of certificates are listed as SHOULD NOT issue. > > > -Ilari > --001a114d85d66c5628052f4b3e52 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 2:47 PM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Wed, Mar 30, 2016 at 01:33:57PM -0700, Eric Rescorla wrote: > On Wed, Mar 30, 2016 at 1:23 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
>
> > On Wednesday, March 30, 2016 11:22:15 am Eric Rescorla wrote:
> > > 1. Add a "this is only usable for TLS 1.3 [or for subce= rts]" extension to
> > > PKIX.
> >
> > Adding a PKIX extension to mandate a minimum threshold of securit= y
> > configuration (e.g. PFS+AEAD w/o resumption or SHA1 or any suppor= t for TLS
> > <1.2) would also be great to have
>
>
> This seems like a fairly blunt instrument. Better to make sure that TL= S's
> negotiaton
> mechanisms are reliable and trustworthy.

Unfortunately, there's the broken key exchanges, which fundament= ally
compromise any version negotiation.


Yes, one could set RSA KeyUsage to just DigitalSignature, which would
nominally disable those broken key exchanges.

Why is this necessary in this case? If you're a server which won'= ;t do static
RSA, why isn't it enough to just refuse to negot= iate those cipher suites?

-Ekr

Unfortunately:

- Many clients don't enforce that.
- That kind of certificates are listed as SHOULD NOT issue.


-Ilari

--001a114d85d66c5628052f4b3e52-- From nobody Wed Mar 30 15:50:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BCE12D1B2 for ; Wed, 30 Mar 2016 15:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 V4zYU5Wv06Fi for ; Wed, 30 Mar 2016 15:50:34 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BE7412D1CA for ; Wed, 30 Mar 2016 15:50:33 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id cNpl1s00410HQrX01Npm08; Thu, 31 Mar 2016 00:49:46 +0200 Message-ID: <56FC5807.20106@openfortress.nl> Date: Thu, 31 Mar 2016 00:49:43 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:50:36 -0000 Hello, > In Yokohama, we discussed changing the IANA registry assignment rules > for cipher suites Has a similar thing been discussed for TLS Extensions as well? That list now requires "IETF Consensus", and it doesn't even have Private and Experimental allocations, let alone a portion with "Specification Required". It can be difficult to get enough traction on this busy list for an extension that is only useful in a niche (which could be said of my draft-vanrein-tls-symmetry that gained no response at all) that is however very interesting in such a niche. -Rick From nobody Wed Mar 30 15:57:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB9C12D10E for ; Wed, 30 Mar 2016 15:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BECaSj14-dvA for ; Wed, 30 Mar 2016 15:57:52 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 75A5F12D0FF for ; Wed, 30 Mar 2016 15:57:52 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id a129so86165999ioe.0 for ; Wed, 30 Mar 2016 15:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=NQ0QHsf/jKN0710p0fZTrM5FDVL3l3jPHYSdRmYQ+z4=; b=sAjWW/cM764EoW6b0fm75P1y5WebZD5gQE6sSTZHw013fNskDUHkLVCmbtDsWrbKl2 L8+4U8U/vYn2QkBP5dBu9aU5cyZ8TVWaspzySVdpzpeJ6MIblZ6iUJFkHu6WvIlkLpoQ ZVYrE7LZ7gyVxBmWzt/qGEBJOGPF9lftgtFvvK80/Rbxluvph5YAWU2/fQ7eXMAQ8vXi pG5OHV772p/uG73I3r11RAAwdo98724OexFs21/r+TMz1PRaM3UXY5RlhXzN1stYBZus 8AHF10VVa9cBl/BomI5fYkfFiv3uFa9zVhXQumWpwP/y+fnLhfk15bSBLOjF1UaS8Vz6 8EXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=NQ0QHsf/jKN0710p0fZTrM5FDVL3l3jPHYSdRmYQ+z4=; b=J09MGcG/D+YlRpW0o+f63qs3R/W4QMF2GWAWjHruwnqV3fICjMmCme+5WoV2nLDtkp KG2aSwFVEUdFqVYJIkC0+HmVwBNE8mR/GzfmCLvuatke+AEV3VqWEdMksiay6zS6rW07 flPvrlXxfpKxO36EeStxydP3pGI0IAqxA+Zdv7gyA3kUEl4JiPz0D5C6fNguL+O2OcbP WN4kAQvzoGet8nUBsLG6NvYUf6YiezB+wa/MKasBffeTlyzuQNar6Wr7+DsP+98vA+mc m3CaidLN44jcx9rytne++U6ZFKJ+39uFZ4kvfCvKpQ3oGLQc9U57Xa1WHV/b/aYplxfO gz2A== X-Gm-Message-State: AD7BkJLlRqvIHz6aSk7tkFiKC7pi+z66qsUBM2bTqFaXF/Ts8dgMbxz6ayO5GQJJFWTCamTUsaNVCAt5CXbfNg== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr11482031ioi.108.1459378671879; Wed, 30 Mar 2016 15:57:51 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 15:57:51 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 15:57:51 -0700 (PDT) Date: Thu, 31 Mar 2016 09:57:51 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11402b2454ad14052f4c13a4 Archived-At: Cc: tls@ietf.org Subject: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:57:54 -0000 --001a11402b2454ad14052f4c13a4 Content-Type: text/plain; charset=UTF-8 On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" wrote: > Then on topic of 0-RTT, how does 0-RTT key hashes behave if > handshake is restarted (main handshake hash continues, but > 0-RTT hash context currently needs to be separate from the > main context)? Good question. I don't recall that being discussed. I see three options : 1. Continue the hash, just like in 1-RTT 2. Treat HelloRetryRequest as a denial of the entire first flight. 3. Signal the choice. Option 2 suits best if we consider HelloRetryRequest to be a DoS feature exclusively or at least primarily. But we have other reasons for it and I don't think that DoS mitigation is a big factor for TCP. I think that option 1 is easy enough, since both sides have to extend the hash in any case. 3 is just complexity. --001a11402b2454ad14052f4c13a4 Content-Type: text/html; charset=UTF-8

On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:
> Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> handshake is restarted (main handshake hash continues, but
> 0-RTT hash context currently needs to be separate from the
> main context)?

Good question. I don't recall that being discussed. I see three options :

1. Continue the hash, just like in 1-RTT

2. Treat HelloRetryRequest as a denial of the entire first flight.

3. Signal the choice.

Option 2 suits best if we consider HelloRetryRequest to be a DoS feature exclusively or at least primarily. But we have other reasons for it and I don't think that DoS mitigation is a big factor for TCP.

I think that option 1 is easy enough, since both sides have to extend the hash in any case. 3 is just complexity.

--001a11402b2454ad14052f4c13a4-- From nobody Wed Mar 30 15:59:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E67712D118 for ; Wed, 30 Mar 2016 15:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 1C7w-s0U2rMo for ; Wed, 30 Mar 2016 15:59:48 -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 9452512D11A for ; Wed, 30 Mar 2016 15:59:48 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g3so77114872ywa.3 for ; Wed, 30 Mar 2016 15:59:48 -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=uZ3yRViYjre2YHfJE4jkZf7FiNmVm+BBvq+mGNUcgCs=; b=0km/tflcUbYDh+8RgiPAKJEfl695EA1aSSX9NYC2aGnQHcR8gqQnTfbTy54tQrwiRz z3UsPVBdgn0vz51BAgUkBLNcgQQQEBjadzXomtV66zFLr3MbNCxQB/jDpUIs0g3Mb9GS 0wjoSBN1XAZYbsoEnqDp5O4tqCuCF1ayHRB9Vp7HAANI+APTRLAq+DpazL0LMXPOo6Hk nQ1Zidg0kMbaAGSseDlY/X+Bekq8lNjiT4YmospOT5AGogFvjjZtyaqCBxsK/z39KWYG cmyAHYDkU7vxsfBIHPE/YJzyPDRUkmTCD2v/snuinrFXcA7oCqbRkj9436ey5XfET9ER QDPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uZ3yRViYjre2YHfJE4jkZf7FiNmVm+BBvq+mGNUcgCs=; b=XVQbW/r+L+vZdtHNZe3k+K7wuyL3LacLnFAPZQKPiIY5R9qHIxWWM72JaA0X80th7h ONBB8RTGdO7taP4PBWhCYCacsJMENiOYoc7fLzbiZJr+tmvyf0mvC7jsyi4nuZ+l5HFE t3A4lr9RWzjJqt+bLFsIBwPGdgPbWM+e6O1D0GUwZGSWm07P/GEjqZ5i0l8j01NykaBg rTJILPYb9Azsqe+ZoUFuSDJmx1Yyh9+ddiIEasmr0aD8ccw7nALBzE2hrRoJ6X4t5LBb fC0Bao8OKLzaVT+H/xCOyxBTZaCw/ylMQ3gQHBjkolYE9y1+5f6Y4L3098DFTQAIgcCd Eh8A== X-Gm-Message-State: AD7BkJKRMoslGjbtNW9k9C6iCcpF42tN0dOUj6Y4MT/KYF+OubUbe/2q2psEKkKmTHDjsZuyjsfLOGFHHiaFHA== X-Received: by 10.13.193.4 with SMTP id c4mr6359135ywd.192.1459378787860; Wed, 30 Mar 2016 15:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 15:59:08 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 30 Mar 2016 15:59:08 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114caa9e3e72ee052f4c1a0a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 22:59:50 -0000 --001a114caa9e3e72ee052f4c1a0a Content-Type: text/plain; charset=UTF-8 On Wed, Mar 30, 2016 at 3:57 PM, Martin Thomson wrote: > On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" > wrote: > > Then on topic of 0-RTT, how does 0-RTT key hashes behave if > > handshake is restarted (main handshake hash continues, but > > 0-RTT hash context currently needs to be separate from the > > main context)? > > Good question. I don't recall that being discussed. I see three options : > > 1. Continue the hash, just like in 1-RTT > > 2. Treat HelloRetryRequest as a denial of the entire first flight. > > 3. Signal the choice. > > Option 2 suits best if we consider HelloRetryRequest to be a DoS feature > exclusively or at least primarily. But we have other reasons for it and I > don't think that DoS mitigation is a big factor for TCP. > I believe Option #2 is simplest. -Ekr I think that option 1 is easy enough, since both sides have to extend the > hash in any case. 3 is just complexity. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114caa9e3e72ee052f4c1a0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 3:57 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" <ilariliusvaara@welho.co= m> wrote:
> Then on topic of 0-RTT, how does 0-RTT key hashes behave if
> handshake is restarted (main handshake hash continues, but
> 0-RTT hash context currently needs to be separate from the
> main context)?

Good question. I don't recall that being discussed. I se= e three options :

1. Continue the hash, just like in 1-RTT

2. Treat HelloRetryRequest as a denial of the entire first f= light.

3. Signal the choice.

Option 2 suits best if we consider HelloRetryRequest to be a= DoS feature exclusively or at least primarily. But we have other reasons f= or it and I don't think that DoS mitigation is a big factor for TCP.


I believe Option #2 is simplest.

-Ekr

I think that option 1 is easy enough, since both sides have = to extend the hash in any case. 3 is just complexity.


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


--001a114caa9e3e72ee052f4c1a0a-- From nobody Wed Mar 30 16:16:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBA812D0FF for ; Wed, 30 Mar 2016 16:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 BeXQ-_h29gbu for ; Wed, 30 Mar 2016 16:16:53 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 870FC12D0E1 for ; Wed, 30 Mar 2016 16:16:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9D03DBE2F; Thu, 31 Mar 2016 00:16:50 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmdxaKrtd1xp; Thu, 31 Mar 2016 00:16:49 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.30.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F1380BE29; Thu, 31 Mar 2016 00:16:48 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459379809; bh=7unE4q5zQAi2fjy3252kJ1nVE1wwABfkO2YOmySp9Cg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=gEXeo+rSpH6pithXHye7inOeQYSvvSLbmsrLKHB8e5qyHx4cb+htA5SXPzOBLVyDm ZgTIwUqh1LFvI1yvKyRO/4FSewilX34bi03v77MRXJ2+OEV03alf/VS9IKQliSA514 areaqzisfCEfAftoxRCw8I81SP+zblypY+U7HwO8= To: Yoav Nir , Daniel Kahn Gillmor References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> <87egarbvic.fsf@alice.fifthhorseman.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56FC5E60.7070203@cs.tcd.ie> Date: Thu, 31 Mar 2016 00:16:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cshOmn4mfNeLx4VbhL6CWhlp91dJabKj1" Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:16:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cshOmn4mfNeLx4VbhL6CWhlp91dJabKj1 Content-Type: multipart/mixed; boundary="6XerPJv5wUE99qRUaXreb9dbCvxBUQrEp" From: Stephen Farrell To: Yoav Nir , Daniel Kahn Gillmor Cc: "" Message-ID: <56FC5E60.7070203@cs.tcd.ie> Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> <87egarbvic.fsf@alice.fifthhorseman.net> In-Reply-To: --6XerPJv5wUE99qRUaXreb9dbCvxBUQrEp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (with no hats, except the one irritated with loadsa ciphersuites:-) On 30/03/16 21:26, Yoav Nir wrote: > That brings up another question. How do things move from =E2=80=9Cappro= ved=E2=80=9D=20 > to =E2=80=9Cnot-approved=E2=80=9D? Does it require a diediedie document= ? What > happens when we decide that 3DES is just too limited and there=E2=80=99= s not > good reason to use it, but there=E2=80=99s really no security issue wit= h > using it? How about starting from the smallest possible set with "Y" in the IETF recommended column? And then focus on keeping that set as small as possible and actively not letting it grow. Let's *pretty please* take this opportunity to prune the stupid list of nearly 350 all ostensibly but so not equal ciphersuites down to the smallest list that can reasonably be recommended. Measurements seem to have indicated that just a handful is all that really needs to be very widely supported. That will require folks here to not mess about and to resist the set of people who want ciphersuite foo because it's important to just them and a few others. Remember: Sean's proposed text, is to limit the "Y" to stuff that we do expect to, and want to, see widely or very widely implemented and deployed. If this WG fail to take this opportunity to fix the 350 ciphersuite stupidity then that'll be a pretty clear fail in which we'll all (me included) have sadly partaken. Let's fix that eh? S. --6XerPJv5wUE99qRUaXreb9dbCvxBUQrEp-- --cshOmn4mfNeLx4VbhL6CWhlp91dJabKj1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW/F5gAAoJEC88hzaAX42iBm4H/iZt7/NMNxhLkKSKxdbKZWCT Q6OS7RT348TH0iZQDkXUic1fVuusqMT2mX+dWhapMmARvduXIC9Exgb1TD6HVqGW xxmmf6cIA0MQbqQDG4mirrIyk/Du7FY/EC6ooTZtEdMJOl5HppOqNjj+cceS5/cI MnU02Pn2t5PkHRyxuJsBZR/FmfGJqTKGTAJlp6nDcBpjz81nvepdO7aAV/6/c9Zv GWfGiq9LuGqmXy7HfU8tBoonKkaThYj4egys5nNICquMcJvlMu7uTJBoRnAIa2VS Vq3vrSL4wuTr3m1A6/zbdeTfZOmS6D/g67xkI7S9+u+lcuTgDcUeDEV4RE/UNns= =V8xF -----END PGP SIGNATURE----- --cshOmn4mfNeLx4VbhL6CWhlp91dJabKj1-- From nobody Wed Mar 30 16:23:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6084212D1C9 for ; Wed, 30 Mar 2016 16:23:39 -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 yhWLjDF93ncg for ; Wed, 30 Mar 2016 16:23:37 -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 481D812D0FF for ; Wed, 30 Mar 2016 16:23:37 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g127so77491591ywf.2 for ; Wed, 30 Mar 2016 16:23:37 -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=8xw2eG5WaLCg3wfo9ZeAD4mu7u0/AV+PBnLzrh5Esms=; b=pBqUI4H0fsnDRCg6dKRoq9hGAET3WsQ0GNkv2h3SYMyeDHDAntWHucfwiA0gUUgf7E fRJ8C0drvDH21295JEyjXPSazXf1pTwa+vqPfm/RpsCqBhwcAHUGY8LuFGzUY1DdPmun a8Fv7Pnrs1B04loOIgAdbLkfAbZNxYJrHNuoeXfDER12faSuNKXW8wUkG6hCkYg098nf 8L7kcW2DNrDZxC64CEeUGHYMMwUyOOhsZfNZsqjUPVvrXMUPE1/jApBPYu14Onj/xevl Zx1rdUCW5Ez5gL1L+DAwnzpc67MXoFxqKee60czPUwTbcoeWE3Dl5DTExuPk5nNEUoVm aecg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8xw2eG5WaLCg3wfo9ZeAD4mu7u0/AV+PBnLzrh5Esms=; b=igS9lVexHvOmgqaTTjWAuspoROJpvCdYqdYFNciwxhY3dzEWuKcjpmj6tWFltMbvAJ SntyT9/MeC/mAo2KjWZ7S4v0qXb2J0MK29g0ffrv/flvvnG4lYpR500Q+phSYMIy3rAl ZeMMhhxJImiZCJLfb6H6mfkkrUnEdBEDRoYsHpZ22dv9FiinEPJLU6K/EH3lKEbiUAnQ FzUPTnpZ3mc+3O5qFRGOE3Gx+xjAdRxqfJx35+R2o/yF7ENmsXejeFMY07GJfuF4/L28 3xr8NZhHLBvJfFwps48XXREEZtBnTJWtfSM9i9ek6Dx+4rvVdMcthUS2mMnUpR8ToHLI hOMg== X-Gm-Message-State: AD7BkJJPgjQ1RIwKkc5ZgDtf92oZ0UjA7E00eAgtVMo2Zk8KN5awsWuDgYYS6UgPGRdyi70AdQFbZSqw0g07Uw== X-Received: by 10.129.80.69 with SMTP id e66mr6432928ywb.231.1459380216505; Wed, 30 Mar 2016 16:23:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 30 Mar 2016 16:22:56 -0700 (PDT) In-Reply-To: <56FC5E60.7070203@cs.tcd.ie> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> <87egarbvic.fsf@alice.fifthhorseman.net> <56FC5E60.7070203@cs.tcd.ie> From: Eric Rescorla Date: Wed, 30 Mar 2016 16:22:56 -0700 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a1147f07865f38a052f4c6f77 Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:23:39 -0000 --001a1147f07865f38a052f4c6f77 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2016 at 4:16 PM, Stephen Farrell wrote: > > (with no hats, except the one irritated with loadsa ciphersuites:-) > > On 30/03/16 21:26, Yoav Nir wrote: > > That brings up another question. How do things move from =E2=80=9Cappro= ved=E2=80=9D > > to =E2=80=9Cnot-approved=E2=80=9D? Does it require a diediedie document= ? What > > happens when we decide that 3DES is just too limited and there=E2=80=99= s not > > good reason to use it, but there=E2=80=99s really no security issue wit= h > > using it? > > How about starting from the smallest possible set with "Y" in > the IETF recommended column? And then focus on keeping that set > as small as possible and actively not letting it grow. > > Let's *pretty please* take this opportunity to prune the stupid > list of nearly 350 all ostensibly but so not equal ciphersuites > down to the smallest list that can reasonably be recommended. > Measurements seem to have indicated that just a handful is all > that really needs to be very widely supported. > We already have a proposal for this. Please see: http://tlswg.github.io/tls13-spec/#iana-considerations -Ekr That will require folks here to not mess about and to resist the > set of people who want ciphersuite foo because it's important to > just them and a few others. > > Remember: Sean's proposed text, is to limit the "Y" to stuff that > we do expect to, and want to, see widely or very widely implemented > and deployed. > > If this WG fail to take this opportunity to fix the 350 ciphersuite > stupidity then that'll be a pretty clear fail in which we'll all > (me included) have sadly partaken. Let's fix that eh? > > S. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1147f07865f38a052f4c6f77 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 4:16 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

(with no hats, except the one irritated with loadsa ciphersuites:-)

On 30/03/16 21:26, Yoav Nir wrote:
> That brings up another question. How do things move from =E2=80=9Cappr= oved=E2=80=9D
> to =E2=80=9Cnot-approved=E2=80=9D? Does it require a diediedie documen= t? What
> happens when we decide that 3DES is just too limited and there=E2=80= =99s not
> good reason to use it, but there=E2=80=99s really no security issue wi= th
> using it?

How about starting from the smallest possible set with "Y"= in
the IETF recommended column? And then focus on keeping that set
as small as possible and actively not letting it grow.

Let's *pretty please* take this opportunity to prune the stupid
list of nearly 350 all ostensibly but so not equal ciphersuites
down to the smallest list that can reasonably be recommended.
Measurements seem to have indicated that just a handful is all
that really needs to be very widely supported.

We already have a proposal for this. Please see:

-E= kr




That will require folks here to not mess about and to resist the
set of people who want ciphersuite foo because it's important to
just them and a few others.

Remember: Sean's proposed text, is to limit the "Y" to stuff = that
we do expect to, and want to, see widely or very widely implemented
and deployed.

If this WG fail to take this opportunity to fix the 350 ciphersuite
stupidity then that'll be a pretty clear fail in which we'll all (me included) have sadly partaken. Let's fix that eh?

S.



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


--001a1147f07865f38a052f4c6f77-- From nobody Wed Mar 30 16:26:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8417812D1E4 for ; Wed, 30 Mar 2016 16:26:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 TUGha6S3nfuI for ; Wed, 30 Mar 2016 16:26:36 -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 0981712D1DF for ; Wed, 30 Mar 2016 16:26:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B5B1CBE32; Thu, 31 Mar 2016 00:26:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfuGLOX8fzPl; Thu, 31 Mar 2016 00:26:33 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.30.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D1CC2BE2F; Thu, 31 Mar 2016 00:26:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459380393; bh=Gi4GE8t19y7VbHp/6Rbsp5CN+BetpYam4SgvXEYkdSU=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=jHyTAyQPFzNwDTDuju6qNseveqMIGJ4zCIv7xTPNgRuV6XedX0SMCvwgsb75A5gAu TecKJcElo/rsdAFLCPPC9awIapnGtG2vnWsPm2wcgU6R5zJEUe5RVuyNGCWo15q7KM RszFGm4vapXVk/1pH1rIZKXl1zTCaq4kxS04r0Bc= To: Eric Rescorla References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FBF1B5.8030906@akamai.com> <8737r8ymrd.fsf@alice.fifthhorseman.net> <20160330192008.GB771@LK-Perkele-V2.elisa-laajakaista.fi> <87egarbvic.fsf@alice.fifthhorseman.net> <56FC5E60.7070203@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56FC60A8.20006@cs.tcd.ie> Date: Thu, 31 Mar 2016 00:26:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080506050805050601080905" Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 23:26:37 -0000 This is a cryptographically signed message in MIME format. --------------ms080506050805050601080905 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 31/03/16 00:22, Eric Rescorla wrote: > We already have a proposal for this. Please see: > http://tlswg.github.io/tls13-spec/#iana-considerations I like, support and will buy that a beer:-) Thanks, S. --------------ms080506050805050601080905 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAzMzAy MzI2MzJaMC8GCSqGSIb3DQEJBDEiBCDomqSdgR4e+hSLBW5jWC9ljZeiY/7TaQie2uG/aIRX +jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCw7O/Nzud/r8pklpBANZ5fbUq//uJVOwfw5Ht8YsMbb6JJ4eix0Qpu L3DmqAFCmpPL4zgT//UM4e6pj6PMdGM98t7pZ2MvXLCeJclssvDZU6kkxON6chgnRMAZUTwC RpwfqRQAIKogZHm0eS7qPhKJvFysvy3YD3NBi2wb5dQduRLkOWTnPY/el/aG1/N7GMfzs57H up7YcqsFk5Lgw1vpe255dYYIEFrbZ6dzuV4PKo/0SA/FaRjlmRlKOtUbHPNnDuJaG/quS8EE PPkDg2IMDatyVjuP2bVAb13bMxGJJT+h5wFOh4HjTCycjVXNeiAjNyO81FC5J+KLm0VOyJFn AAAAAAAA --------------ms080506050805050601080905-- From nobody Wed Mar 30 18:09:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C7D12D160 for ; Wed, 30 Mar 2016 18:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KswTtxUQyxIm for ; Wed, 30 Mar 2016 18:09:33 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 1A84612D0BE for ; Wed, 30 Mar 2016 18:09:33 -0700 (PDT) Received: (qmail 11058 invoked by uid 0); 31 Mar 2016 01:09:29 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 31 Mar 2016 01:09:29 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id cR9N1s00i2UhLwi01R9R7w; Wed, 30 Mar 2016 19:09:28 -0600 X-Authority-Analysis: v=2.1 cv=Nal1iQz4 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=7OsogOcEt9IA:10 a=48vgC7mUAAAA:8 a=QTDDpOMU1WFs76DruTsA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:To:From:Subject:Date:Message-ID; bh=Nh+GaoRaGUuHpmV0K2k72ywyFOC9rJSAr2AecDeci2E=; b=i0N/OdUxFghN3py9LSRE1gcB7h RwdSB8lgJa5V7fV23AxIBCV2gh7Ud48xq8arR4X84i4cdub7RiE5/o/urYbVAZkMB+HL0lNR/2HnP CHM+fNjfdQF8dleqS3kh6k35k; Received: from [127.0.0.1] (port=42669 helo=box514.bluehost.com) by box514.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1alR6y-0006zx-Oe for tls@ietf.org; Wed, 30 Mar 2016 19:09:24 -0600 Received: from 73.202.80.238 ([73.202.80.238]) (SquirrelMail authenticated user jeff.hodges@kingsmountain.com) by box514.bluehost.com with HTTP; Wed, 30 Mar 2016 19:09:24 -0600 Message-ID: Date: Wed, 30 Mar 2016 19:09:24 -0600 From: jeff.hodges@kingsmountain.com To: tls@ietf.org User-Agent: SquirrelMail/1.4.23 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} Archived-At: Subject: [TLS] updating RFC5929 channel bindings (was: Deprecating tls-unique for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:09:35 -0000 [ resurrecting ancient thread ] Andrei said on November 4, 2015.. > So perhaps the simplest fix is to update RFC 5929 to say that tls-unique > is deprecated and EKM should be used instead, with certain recommended > parameters. This does mean that any protocols that rely on tls-unique > will need to negotiate a new revision. There are three distinct channel binding mechanisms in https://tools.ietf.org/html/rfc5929.. 3. The 'tls-unique' Channel Binding Type ...........................3 3.1. Description ................................................3 3.2. Registration ...............................................4 4. The 'tls-server-end-point' Channel Binding Type .................5 4.1. Description ................................................5 4.2. Registration ...............................................6 5. The 'tls-unique-for-telnet' Channel Binding Type ................6 5.1. Description ................................................7 5.2. Registration ...............................................7 ..is the proposal to update RFC 5929 to say that both tls-unique and tls-unique-for-telnet are deprecated and leave tls-server-end-point as is? Are there any known updates that ought to be applied to tls-server-end-point? Perhaps the allowed cipher suite list in S 6 ? Should an updated tls-unique-for-telnet based on RFC5705 EKM be defined in the proposed 5929bis draft? Or it could be left as a separate exercise for those who care about telnet I suppose. HTH, =JeffH From nobody Wed Mar 30 18:18:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9400912D160 for ; Wed, 30 Mar 2016 18:18:47 -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 tFgSYTc3pxVu for ; Wed, 30 Mar 2016 18:18:46 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001: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 D3FD612D0BE for ; Wed, 30 Mar 2016 18:18:45 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id q128so94745388iof.3 for ; Wed, 30 Mar 2016 18:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=lFQs5+nLlIRDP4NM+olH0sAWX1/IPeFXV9hieG9OVT0=; b=n2n/DOD7i5PVx4/ilCOQs9GhzueHRC31YZeJB2HFOhohMqGXxK9z1cL0Uu33TMy6cK CC5gItjWnAGcRgo0Qjbgk2EeyFKXGC9JYB3VxOl8ca+FPHauTR4Ht7h6W2IK9+X/YZCv xY1OdEIbnx1dYkgac0eOjwiHqn2g3DTRYqkgM7BBGpkP5w8f31r8c/btZYE37uIJY7gp +HsW/UCCMBpPcZDkjb6jcCVTpkYXa/NSQ5amqASMBujyqpDEgD3e+C6xLI1QxOsVZuc5 Tqrg2aM7orzgvNd8yGmeKrZun2niSXWWgCOHfXBQJ0EK+8IbA9q96hhZpoANXRqgxYeG XKdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=lFQs5+nLlIRDP4NM+olH0sAWX1/IPeFXV9hieG9OVT0=; b=QDVBD8OM9ilr3dfYDtlUGAeXXxxioFSq1TPsXKfuDW0F1Xp5eJj4vKHNSPZnCW8uFU tVbmKe3Ug7sXtbyHkw8ImBMeHwHiEDhd+hrQa8WzP1HQhW5vy7VUaVI2FDknCc1NZ5ag TDnQolTGx4EZVMbl1EvN9MRWIM2MVfLktdtGjRCK5csjialv2w7E7CXL0zZAgrOHhoqz CO4u3ykITGp87dF94Bm0McHp1tShhcwsh0BQtnJtL6Q+UfdrnyUu41JDew59CNLeGdKX pqGF4S5wukPkylWAx7XGX0ma4S0+VPH6X5ZGmBBbRqub4JIMZHMqhnGU8Zo3laxyfOxn MRYQ== X-Gm-Message-State: AD7BkJJ9ttDtEOB9WrQNqsyxodUDsDwNCFCb2fg7coa47cF+UbN7RUZzmNbGH6NImjMBH7M1XiA+LX085BvaEg== MIME-Version: 1.0 X-Received: by 10.107.161.140 with SMTP id k134mr13279612ioe.190.1459387125174; Wed, 30 Mar 2016 18:18:45 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 18:18:45 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2016 12:18:45 +1100 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:18:47 -0000 On 31 March 2016 at 09:59, Eric Rescorla wrote: >> Option 2 suits best if we consider HelloRetryRequest to be a DoS feature >> exclusively or at least primarily. But we have other reasons for it and I >> don't think that DoS mitigation is a big factor for TCP. > > > I believe Option #2 is simplest. I didn't mention this because I was composing on a phone at the time, but we have to decide whether to allow a second attempt at 0-RTT. If we do, then the effect is a two round trip setback. I think that the odds of this happening are small, so I'm OK with it, but I wanted to highlight that. From nobody Wed Mar 30 18:22:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65C0D12D0CF for ; Wed, 30 Mar 2016 18:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnSxEh9Sgn6I for ; Wed, 30 Mar 2016 18:22:22 -0700 (PDT) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001: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 B254F12D0CC for ; Wed, 30 Mar 2016 18:22:22 -0700 (PDT) Received: by mail-ig0-x22e.google.com with SMTP id cl4so115934972igb.0 for ; Wed, 30 Mar 2016 18:22:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=u7miffiH5meNlH4N0HTrUhNO1IDWXki2crbXig1QlII=; b=AQ4c2UaQDj9YEmxdCxnvbsW3iBf4EnGoXysH8MkBBudUsYDXBuOskIabHnfnOxEyNr HqG61ac8PNTqy++9ahM1hQOXPK120E/kgqTrAdurv+U459KZfFTAcwVYUM+K7a7HAdsZ XZi9hmzbWi+QjEcqTBjYI2g9cZ4QvM6ZWVuk6CZAZtenrX8zoKjMEE9yP2ORi79xBcT4 4/fOwNJL9AYEDrpJl1aOfK0gSdJfH5WHluy2BB6gO2K3mkLNfwnhM+178amW1R32exZR z2nU4dijZhUauwlT+bHQ9RkzoJzWoijsSKcqLZfhT+liarfQtUdBoDh7q//oKZupuJ2f 4LQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=u7miffiH5meNlH4N0HTrUhNO1IDWXki2crbXig1QlII=; b=N3xOiEj2FTAYs+fZq5nr7QB+mXPjkOs7YjZBoazuz60jaOCEtp0syrWcxucGl5iIHD DWhjaVs7tkhoJwiTNWjSXe8O5uKUZTu/zfWNtY2IE+t8FVNpuiyjLZyXfYN4Dz4hZuAY lt1A1ByG5CgpUPs0f0xdBzwUw2Py9SnxTFwPZFdIMVSuUNYDPwcvDCHTOiNZF3wQCK/W ngjFa27VeK6N6OKhmzwDh8IWiQIe88B7U9Ee5+d/k3sPHiDMJiR0TIRX0QI6H1SrFWCg XA+1CBC23953r52CXoAV3Pa1I4PFJaJ3fX7aasiRSljzDpArW4NhM0HLObBb4U7FAy5y B7Yw== X-Gm-Message-State: AD7BkJKaOPXK9bshU9lH+GeLjvtGMzoVKGqcl2JF8QEx/xf+udHJyoQbZWBbATlkPbPwijdMW/FtterPL8M6UQ== MIME-Version: 1.0 X-Received: by 10.50.43.226 with SMTP id z2mr1662166igl.94.1459387342118; Wed, 30 Mar 2016 18:22:22 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 18:22:21 -0700 (PDT) In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Date: Thu, 31 Mar 2016 12:22:21 +1100 Message-ID: From: Martin Thomson To: Sean Turner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:22:24 -0000 On 30 March 2016 at 12:53, Sean Turner wrote: > Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus on As long as that consensus is for the "Y", then this is a great plan. I think that there's consensus on a lot of "N" entries too. However, if there is any dispute or doubt, it's still "N". From nobody Wed Mar 30 18:42:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F77612D1AC for ; Wed, 30 Mar 2016 18:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] 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 cH5mFbEb_tJ6 for ; Wed, 30 Mar 2016 18:41:59 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E38F12D0CF for ; Wed, 30 Mar 2016 18:41:59 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id g127so80523135ywf.2 for ; Wed, 30 Mar 2016 18:41:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=rh/nP7zxm+8kIwEVnaMRbZ/dCxbYJI5QDrF8PFxRtr0=; b=PWvLkPzyiWzOO1ewCobko93DtsDUuwf3Jyf2DAb/VO93Q1BbYmPrOOUOrfvz6aTJvE 9uqHswbZLJIucY4pHzKv5DYrcQYR32eXMIyatLzaRqptixMlCQI6TebRfLb9bu+Do9FE FFCjCWRP+H6MA2Qc9wvRLb8g51Rf0J6+PVOFdfKrYxcu5ywXgjiMF6qvseHX7d9U4l6u PLJF+/z6sFVYa8p/B61CTsXcbUNVsmiMZHcq2tZXBDiIA5n4SsAU+fn7MoWu/Ky2luPn SdVRHBm1Lz9DGl/fZbdB7NiIKs7g0sbWj7NG6O1c5ogGY/H+moUO/kCbLLFqyCwCq2/V r2iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=rh/nP7zxm+8kIwEVnaMRbZ/dCxbYJI5QDrF8PFxRtr0=; b=ODWmpNJc+AjIUi8lqfPRhS/3HPcFoArkMVNE5f+qArGyAM0exRsqQjhZR7+L8kFuwv wEDwNdJfbUV3SVE0h67sx68SHFfvMzDXQtH9Em3V+uRKxKdNki+7OvqlOl6vtKfuoMDE pPO+exBHL84f4pJTwhhNmRmIEJgW3FWj4Lxqkiu9pZ8Bnw6ynYSJLm3ZiQ94yjt4r8Qd dkt/uwCwFwsEYuRLVRQ1x+83YI+GuLn93AbSwwvmXifm/8+dJZNfsTvDZyHj0AUjqSYv odG5A779wWvvG/iKTRwI5WvOSaBG4T/wy/RWE9ipLxZE+pcmc1pf155CerycRUCeuenR lsdw== X-Gm-Message-State: AD7BkJLolsn89B1phNxlaNGcztWpKpJsyB18a9uPI7NS0lNJUlVes2fKLPu64eZA3VVU7HiCDzfAZ/hGRu6Bfb1D MIME-Version: 1.0 X-Received: by 10.37.88.134 with SMTP id m128mr6105673ybb.43.1459388518234; Wed, 30 Mar 2016 18:41:58 -0700 (PDT) Received: by 10.37.113.67 with HTTP; Wed, 30 Mar 2016 18:41:58 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Wed, 30 Mar 2016 18:41:58 -0700 Message-ID: From: Wan-Teh Chang To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 01:42:01 -0000 Hi Eric, Thank you for the reply. On Tue, Mar 29, 2016 at 10:57 AM, Eric Rescorla wrote: > > On Tue, Mar 29, 2016 at 10:14 AM, Wan-Teh Chang wrote: >> >> [...] I am curious to know how we concluded that 0-RTT PSK is simpler to >> implement. Did anyone implement both 0-RTT modes and can compare the >> difficulties? > > We have a prototype 0-RTT PSK implementation and have looked at but not yet > implemented 0-RTT DHE in NSS. Based on that, my sense is that the cost of > doing any 0-RTT is the bulk of the additional effort, but that if you have > PSK already, which you probably want for ordinary resumption, then the > incremental cost of 0-RTT with PSK is less than with DHE. By analyzing Sections 7.1 and 7.3 of draft-ietf-tls-tls13-12. I think I understand what you meant. For convenience I reproduce the table at the top of page 74: +-----------------+------------------------+------------------------+ | Key Exchange | Static Secret (SS) | Ephemeral Secret (ES) | +-----------------+------------------------+------------------------+ | (EC)DHE (full | Client ephemeral w/ | Client ephemeral w/ | | handshake) | server ephemeral | server ephemeral | | | | | | (EC)DHE (w/ | Client ephemeral w/ | Client ephemeral w/ | | 0-RTT) | server static | server ephemeral | | | | | | PSK | Pre-Shared Key | Pre-shared key | | | | | | PSK + (EC)DHE | Pre-Shared Key | Client ephemeral w/ | | | | server ephemeral | +-----------------+------------------------+------------------------+ In a PSK session resumption handshake, we always use the same (third) row, with or without 0-RTT. On the other hand, in a full handshake, without 0-RTT we use the first row, and with 0-RTT we use the second row. Is this what you meant? But if you already implemented the first row, which is a must, the incremental effort to implement the second row seems small -- you just need to use server static instead of server ephemeral for SS. Wan-Teh Chang From nobody Wed Mar 30 20:33:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D9D12D529 for ; Wed, 30 Mar 2016 20:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C7Um7hoBKPhA for ; Wed, 30 Mar 2016 20:33:30 -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 EE79512D524 for ; Wed, 30 Mar 2016 20:33:29 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id a129so91871366ioe.0 for ; Wed, 30 Mar 2016 20:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/74gMCwL0lPRSbICF2DgVz7hMYNwXzqqWRMIuDuTnE8=; b=CdbhF1/X+1h/YFvyxqT3TRCNhSMBMwjgRhrFyHI2/YhB+aI7OKn0hJsEU9cY+8RFKa Y56vMswpfZrBulp2Pn6psY2IAQtjnqCBxKw2a507gBDyv/dTN0Puw8Vk8AhTthYk9bm8 zKtiRw7Eg4tJRtd1cJwHnQTsfcnFK0MXZdZKyMpRlqI1GWDEaFEn3MBb8wL3dIm4N1cu eDrriOB93xGLTkmsi8daByJXZUyRHdy1tSKAZc9743dycfE6oNPRaIAMQwK4ZZPkT2iJ olR+db7aRq9dJ6zTqeVpHm5LMZ0mHR0A2XbG9erxHACsw3JXI5kILBs8fJTpfr5gqBv+ 4rJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/74gMCwL0lPRSbICF2DgVz7hMYNwXzqqWRMIuDuTnE8=; b=SmtMPF4sjmJZcPDMCX8/1MBKYFlsUTBiD5kfQRuANCuXsqA4EFpsxj4EPkeZiu+NQh S260MQkULVYYG0DHdHYbEefI2PDId2GL+HYqAjUhW0zeWsY4gjpTb7RkTT9c2ZLVJ/GP OA0tmPwtKp2WcQgiZ3zPqE4lfaajK1Fw/67dEgRvVFdFNH4VM2k/X0wzpI0jLVMp5GC+ XjCQSl7Ta6EIG+EusqOeYdF9TvV0RBCL5td6alwyTXa+z2AO5pcOMWyffDA8ln34owYA P5nMTDuklEswYOtKftS8BlvSn117q8KfhiE2CICJpvVAQ5io/dkU0AbBfjjnoJIJ+rwe GjWA== X-Gm-Message-State: AD7BkJJeIFtXogVBhL2boE3P45Qrnr16zVNtXf2zcfP9PUR2UxxJ6Zrhhk0npFvRdb5xsoQd6dNpgtFIr2LhXw== MIME-Version: 1.0 X-Received: by 10.107.137.100 with SMTP id l97mr2736973iod.100.1459395209338; Wed, 30 Mar 2016 20:33:29 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 20:33:29 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Thu, 31 Mar 2016 14:33:29 +1100 Message-ID: From: Martin Thomson To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 03:33:31 -0000 On 31 March 2016 at 12:41, Wan-Teh Chang wrote: > But if you already implemented the first row, which is a must, the > incremental effort to implement the second row seems small -- you just > need to use server static instead of server ephemeral for SS. Someone recently suggested that handling the SSLv2-compatible ClientHello was similarly easy. It wasn't by any measure simple or straightforward. Sure, the request was entirely reasonable, but I now wish I had pushed back harder. This involves a different session transcript as input, all the machinery involved with the ServerConfiguration message, and all the switching logic associated with a new mode. I'd rather reduce this to the modes that we know that we need now, particularly since we know how we could retrofit a DH-based 0-RTT into a PSK-based protocol. From nobody Wed Mar 30 21:52:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD36412D990 for ; Wed, 30 Mar 2016 21:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 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, T_RP_MATCHES_RCVD=-0.01] 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 kfwLYds-pJOv for ; Wed, 30 Mar 2016 21:52:18 -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 3CC8B12D0B4 for ; Wed, 30 Mar 2016 21:52:18 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id h65so84538971ywe.0 for ; Wed, 30 Mar 2016 21:52:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=eILbEw2k1uRDrISfCiJQ9Y+SQaXWAw27i9JuVG52OTU=; b=RtFN6sfAfzby5gABDFR32FfkT0w1KDUUh9pt6saxaCam83lnFk/tUhrVkkRQCLsnjF Iwvc0X+z9uEFdXOMl6Qm1OadmzCkXBTT4N12tMHHAlewP5GJFNQLMWfwejpfyG1e9wWU 1eocRxM6lrt/bj9HY3s7I2EpNlvWS2x83n/uZC/85Xm73HLrmnnLN2IIUm99h3mYnoMc eq2lrIWIHx5D2HZw1jGk2P5zMB5IRGfUnCiv8GFkgzMVq7h9La9hnuxBVek710rOTs7K 6xgxfh/H/kYwvWl3dCaLpDgKYhx/039gjBv2jta4pCScHQ7o2c7faGKtSpEjap77crgV 2QUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=eILbEw2k1uRDrISfCiJQ9Y+SQaXWAw27i9JuVG52OTU=; b=WR2lSx/mA3INMw3jmplDn66Jr3B8cCOuzM13/Cmu+3IenAcxcZ0wIE7y9/6W3HxeYG 29MMsTL/JgSkJ8xnxawdHNKnD0Dri+LmeV0d+CRC1HUSU4SSjuvuSc+/4FJfpXYSL3MI QbyRrvK4KvI7v83uwDxHTfC5lL+VX0BbROetqyR8JHXk2+xh34Qo9aZ4kDBOrcO/2Jrc O6CAU9qT73zjg9NoUcByGQhsUhVrubc4pMO64CvqLqDpQVBRV0ZR8baA5hyOCDi94a/r XdSQiEuZNtbZhg9E5AlexguVfCWekxnAbzPPhKJBz/icQBiqsnYhPd3+4VTLlFvvKWx4 MyDQ== X-Gm-Message-State: AD7BkJJUMlv622mjp80aZxOKz9rS15Y2Nf84lXBw9WmYF49fbWQOfUftB9kFjppRzxpwVCTAN4kFBDGarSvV8U2B MIME-Version: 1.0 X-Received: by 10.129.147.5 with SMTP id k5mr6399233ywg.206.1459399937433; Wed, 30 Mar 2016 21:52:17 -0700 (PDT) Received: by 10.37.113.67 with HTTP; Wed, 30 Mar 2016 21:52:17 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Date: Wed, 30 Mar 2016 21:52:17 -0700 Message-ID: From: Wan-Teh Chang To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 04:52:20 -0000 Hi Martin, On Wed, Mar 30, 2016 at 8:33 PM, Martin Thomson wrote: > On 31 March 2016 at 12:41, Wan-Teh Chang wrote: >> But if you already implemented the first row, which is a must, the >> incremental effort to implement the second row seems small -- you just >> need to use server static instead of server ephemeral for SS. > [...] > This involves a different session transcript as input, all the > machinery involved with the ServerConfiguration message, and all the > switching logic associated with a new mode. By "session transcript", did you mean what is now called the Handshake Context in draft-ietf-tls-tls13-12? For convenience, I reproduce two tables about Handshake Context from draft-ietf-tls-tls13-12. >From page 64: +----------------+-----------------------------------------+--------+ | Mode | Handshake Context | Base | | | | Key | +----------------+-----------------------------------------+--------+ | 0-RTT | ClientHello + ServerConfiguration + | xSS | | | Server Certificate + CertificateRequest | | | | (where ServerConfiguration, etc. are | | | | from the previous handshake) | | | | | | | 1-RTT (Server) | ClientHello ... ServerConfiguration | master | | | | secret | | | | | | 1-RTT (Client) | ClientHello ... ServerFinished | master | | | | secret | | | | | | Post-Handshake | ClientHello ... ClientFinished + | master | | | CertificateRequest | secret | +----------------+-----------------------------------------+--------+ >From page 77: +-------------+---------+-----------------+-------------------------+ | Record Type | Secret | Phase | Handshake Context | +-------------+---------+-----------------+-------------------------+ | 0-RTT | xSS | "early | ClientHello + | | Handshake | | handshake key | ServerConfiguration + | | | | expansion" | Server Certificate | | | | | | | 0-RTT | xSS | "early | ClientHello + | | Application | | application | ServerConfiguration + | | | | data key | Server Certificate | | | | expansion" | | | | | | | | Handshake | xES | "handshake key | ClientHello... | | | | expansion" | ServerHello | | | | | | | Application | traffic | "application | ClientHello... Server | | Data | secret | data key | Finished | | | | expansion" | | +-------------+---------+-----------------+-------------------------+ The info is these two tables is exactly the same for DHE-based 0-RTT and PSK-based 0-RTT. So, between the two kinds of 0-RTT, I only see a small difference in the complexity of the key derivation process as shown in the table at the top of page 74. Wan-Teh Chang From nobody Wed Mar 30 22:09:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C02712D9A1 for ; Wed, 30 Mar 2016 22:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 eyoy1oS-hG0c for ; Wed, 30 Mar 2016 22:09:30 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 5671312D0BF for ; Wed, 30 Mar 2016 22:09:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 462FB2E56; Thu, 31 Mar 2016 08:09:29 +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 96-djDbWQpJF; Thu, 31 Mar 2016 08:09:29 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 01C032313; Thu, 31 Mar 2016 08:09:29 +0300 (EEST) Date: Thu, 31 Mar 2016 08:09:28 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160331050928.GA1138@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:09:32 -0000 On Thu, Mar 31, 2016 at 09:57:51AM +1100, Martin Thomson wrote: > On 31 Mar 2016 5:56 AM, "Ilari Liusvaara" wrote: > > Then on topic of 0-RTT, how does 0-RTT key hashes behave if > > handshake is restarted (main handshake hash continues, but > > 0-RTT hash context currently needs to be separate from the > > main context)? > > Good question. I don't recall that being discussed. I see three options : > > 1. Continue the hash, just like in 1-RTT > > 2. Treat HelloRetryRequest as a denial of the entire first flight. > > 3. Signal the choice. > > Option 2 suits best if we consider HelloRetryRequest to be a DoS feature > exclusively or at least primarily. But we have other reasons for it and I > don't think that DoS mitigation is a big factor for TCP. > > I think that option 1 is easy enough, since both sides have to extend the > hash in any case. 3 is just complexity. Yeah, I agree 3 is just complexity. Except I disagree that currently option 1 is easy enough, since the hash going to creating 0-RTT keys is not tapped from the main hash (if it was, then continuing would be the simplest). Relatedly, the proposal for "contexts" dropped the extra messages that caused the difference between 0-RTT hash and 1-RTT hash. -Ilari From nobody Wed Mar 30 22:30:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5284B12D0B5 for ; Wed, 30 Mar 2016 22:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 o0l2cSQOU47Q for ; Wed, 30 Mar 2016 22:30:13 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECC3112D0A9 for ; Wed, 30 Mar 2016 22:30:12 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id q128so99714015iof.3 for ; Wed, 30 Mar 2016 22:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tkuj2IEigf1ZuQn3AhYIL9CA8Kl5q3YyBtmML3ehtaw=; b=GOKh/Qh2bEx6TNLI5q8aDPPcUvt633QugyQRFWeQsvVNmb3P3BkjFEgNhzhRtBciCN /plOrARKWoxcWGA9jaPEpvSfH7lLh+68viu+rcQSt5zXh74jzdGNzIebgFZYwsfocd9s G16L3355erbh7V3NTrDZZJjdHMZdhQ4T3acKJOCFPVpRqhAeEpsBou5Wmj1R6mLiyMUH 59CLf3VVIqqRsPDKO/cp0qkvjrHBzI5QjA750K9b6c0uNbmoUZVuszneNUcSgSbZ9cfm nzGWXEJ3n9rfPm3MiplzHMD1UsDsO+BSDycMSdYPfN8StaQru9DFc3pKB5O6W8LjOPQ4 +9wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=tkuj2IEigf1ZuQn3AhYIL9CA8Kl5q3YyBtmML3ehtaw=; b=IePFP81sq20Gx3poJ/VqBMn7Sa7ixuSb0EusZvWMIuI/w2wcuPmwdOkPOACpvVKtbV kQzPFnqt2AOQFD9Tce/+fQ3iu2wtqKa13ywyWKxWVGJyhihhdtV60mlo8nIyX9pgh7Nm 8lAcJwNvYI8r+HPLvcZTm0dmAYnBzUeKqMJMZsCnjNZGw0pefcuzEjqe1TBYVqXV9hVi 6SPXuFDtpeShOclOImg81J1PJG1Wkdp+WDKkwX4Ehd+U8AO03h+fhQzGZXOAl7IYBaKg 1RWtRgUWGhUU9D/IOId5aezwJ962lhV0nNM/difnGoQbERjPqXOptAoO11X8v66NiAVr NpIQ== X-Gm-Message-State: AD7BkJLFAQm403Fu0yjyiGK8UXLGJj3W4Ci1znBvuPsYfot2jL+Wwoa94xSCXlxMR3EOrPzQm0bxW/7uMGp/vg== MIME-Version: 1.0 X-Received: by 10.107.137.100 with SMTP id l97mr3035391iod.100.1459402212397; Wed, 30 Mar 2016 22:30:12 -0700 (PDT) Received: by 10.36.43.142 with HTTP; Wed, 30 Mar 2016 22:30:12 -0700 (PDT) In-Reply-To: <20160331050928.GA1138@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160331050928.GA1138@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 31 Mar 2016 16:30:12 +1100 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:30:14 -0000 On 31 March 2016 at 16:09, Ilari Liusvaara wrote: >> I think that option 1 is easy enough, since both sides have to extend the >> hash in any case. 3 is just complexity. > > Yeah, I agree 3 is just complexity. Except I disagree that currently > option 1 is easy enough, since the hash going to creating 0-RTT keys > is not tapped from the main hash (if it was, then continuing would be > the simplest). Yeah, I should get this straight in my own mind as well. I was assuming that we were going to take something akin to Karthik's "contexts" proposal and that would eliminate the differences in hashes. From nobody Wed Mar 30 22:41:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F86412D0A9 for ; Wed, 30 Mar 2016 22:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2MRInG3wN0w for ; Wed, 30 Mar 2016 22:41:14 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3682A12D17B for ; Wed, 30 Mar 2016 22:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459402867; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=A1eq2Gwdwu1ZiExurEJXLQ26pRcNV0wKjumejwJq2uI=; b=Xgfn8KIPpPmFkiCq8wD+W4pTyt9lsBYNYkDZrY2kf7zNUagGkEZbl5N8fFhauVjUfSaHJHKy5fU2KA5Q3H6PVfXMl2wywfGKMzbaRci+FdNQ5i5OZLGb1zI8CVN0keyDj5ncogQu4+f7i+DIr41N9EVPiCVrXGnQBHMLmLqhnAs= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R121e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03294; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_----4ezWiGX_1459402856; Received: from 10.62.54.60(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.23) by smtp.aliyun-inc.com(127.0.0.1); Thu, 31 Mar 2016 13:40:59 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Thu, 31 Mar 2016 13:40:55 +0800 From: "Dacheng Zhang" To: Eric Rescorla Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542276459_874106" Archived-At: Cc: tls , =?GBK?B?wfW088X0KMX0s8kp?= Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 05:41:16 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3542276459_874106 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Thanks again for your comments. See my reply inline please. ^_^ >=20 > I'm not following. If you trust the device, then why do you need any kind= of > cryptographic > authentication on the token. >=20 > Dacheng=A3=BALet assume we trust the device. But the APP use a SNI to indicat= e the > service that the APP intends to access. Because the SNI is static which m= ay > not be changed for months, it is easier for attackers who monitor the net= work > to get the SNI and use it to gain benefit. We need a securer solution. As= I > have mentioned in my previous email, this solution will make such attacks= more > difficult. By the way, SNI is not designed for this purpose, we need to d= o > some additional work to address this issue, right? Again, you need a threat model. It sounds like you both do and do not trust the client Dacheng: Threat model will be provided. Actually=A3=ACwe don=A1=AFt try to protect against the compromise of client. Or the scenario where an APP against another one on the same device. This solution is used to protect against th= e attackers who are able to monitoring the communication between the client and the server. >=20 > Hmm... I'm not at all sure that TLS should address this problem. However,= my > review > was directed to whether your proposed solution even works on its own term= s. >=20 > Dacheng: That is why we need to raise the discussion here. It would be gr= eat > if this issue could be considered by TLS WG. I don't find this to be a very compelling use case and I don't think it's really appropriate to try to solve it at the TLS layer. If you want to have secure flow identification you should do it at the IP or TCP layers. Dacheng:Ok, this requirement is quite strong. We need a solution to address this issue if we want to use TLS to secure our APPs deployed on hundreds o millions o mobile devices. Also=A3=ACChina mobile and Huawei are working with = us on this issue. Could you please tell me why it is better to address this issue at the IP o= r TCP layer. To the best of my knowledge. There is no space in IPv4 herders t= o insert any extensions. There are length limit in TCP options. In addition, TCP is implemented in kernel mode. It will cost more if we try to address this issue at the TCP or IP layer. Look forward to more discussions. ^_^ Cheers Dacheng >>>=20 >>>=20 >>=20 >=20 --B_3542276459_874106 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable
Thanks again for your comments. See my re= ply inline please. ^_^

I'm not following. If you trust the device, t= hen why do you need any kind of cryptographic
authentication on th= e token.

Dacheng=A3=BALet assume we trust the device. But the AP= P use a SNI to indicate the service that the APP intends to access. Because = the SNI is static which may not be changed for months, it is easier for atta= ckers who monitor the network to get the SNI and use it to gain benefit. We = need a securer solution. As I have mentioned in my previous email, this= solution will make such attacks more difficult. By the way, SNI is not desi= gned for this purpose, we need to do some additional work to address this is= sue, right?

Again,= you need a threat model. It sounds like you both do and do not trust the cl= ient

Dacheng: Threat model will be provided. Actually=A3=ACwe= don’t try to protect against the compromise of client. Or the scenari= o where an APP against another one on the same device. This solution is used= to protect against the attackers who are able to monitoring the communicati= on between the client and the server.

<= br>

Hmm... I'm not at all sure that TLS should address this problem. Howe= ver, my review
was directed to whether your proposed solution even= works on its own terms.

Dacheng: That is why we need to raise the disc= ussion here. It would be great if this issue could be considered by TLS WG.<= /font>

I don't find this to be a= very compelling use case and I don't think it's really appropriate to
=
try to solve it at the TLS layer. If you want to have secure flow ident= ification you should
do it at the IP or TCP layers.

Dache= ng:Ok, this requirement is quite strong. We need a solution to address this = issue if we want to use TLS to secure our APPs deployed on hundreds o millions o mobile devices.  Also=A3=ACCh= ina mobile and Huawei are working with us on this issue.

= Could you please tell me why it is better to address t= his issue at the IP or TCP layer. To the best of my knowledge. There is no s= pace in IPv4 herders to insert any extensions. There are length limit in TCP= options. In addition, TCP is implemented in kernel mode. It will cost more = if we try to address this issue at the TCP or IP layer. 

Look fo= rward to more discussions. ^_^

Cheers
<= div>
Dacheng





 --B_3542276459_874106-- From nobody Thu Mar 31 05:17:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 187FC12D59C for ; Thu, 31 Mar 2016 05:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mLoHB_3byNWJ for ; Thu, 31 Mar 2016 05:17:17 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1530212D15F for ; Thu, 31 Mar 2016 05:17:16 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M0QAP-1ZrRVk1lXR-00ubpP; Thu, 31 Mar 2016 14:17:14 +0200 To: Sean Turner , "" References: From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56FD154D.1030300@gmx.net> Date: Thu, 31 Mar 2016 14:17:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Ekqut6E5pNhPL0J2QMTqMqM9LVNO3jDr9" X-Provags-ID: V03:K0:y3CCmswmwn1+phyDuI6cpLA8xQZY72qeaUwWXTuXJAFE0IKu9k0 2HvjAVZnW4G/lSJc1C+BHbVvRa9L7b7H1twM8ZIfJF7FnfuKBAaT5mKDtmNOFRXiRDgZ43P oiHqEqy3fjzn/GTNPwkyOMSybAZR5ELBTtaW25ghZCUPPWlRRAayVArhauLkmrvzvVfymFj +Hu1MwGZE7Y7jWVtf2qeg== X-UI-Out-Filterresults: notjunk:1;V01:K0:xal/R3hbGYs=:JhsgmvPsV9AuWUazt7Aoni i6IH1G+cbGB/YKTluLPgxkwV7H0kDMDYMYzePhzjmpXxWff/M/g4NvSxzVQBSR8SjvpTZiQbA rZmdjfXIH8gSRQnBu5XoX0b1ec1N0LmuEFkrr1J8jevB4DyBI5U3W2EbG5638xbrpbwc+1BR0 hK3fna7JEebuxPQKuBiW8J5PMOlSKGETKC6t3noym2EEIwkoDY79Q7QOjJbObhSQ43RGQ0uGL fJYaMfq0cV6kl/tP8qAK16dNilj3g2qRHq45X6w2H3Z8k1uoLfVqWE3JWZjNuSVIpAqH7Kfy0 qcXWRB6g/z4ppoR6NxcNzjfAsYF9WHPntUwHX0XIp1Sw5s/NxhgC9YPpU7LhgIM1+KznKjvfx hxEtEJfiP6px04txUH2+ul8oDKxjEYs5DE93iP6L49uRyNz5j+DU4p/+CHsd2DQG5Qij1yc+E 97drQdSRJXA/zOunLPJlaIrwWdTcmnpjYdHBogcuGjwq6LWn32jtTN65Jamgw4FjayVUkkhd1 BEiDI1dv+fR7quD5AqVvW49tSPHA/qmAPD2DGaFj9ufITqk8zVsd6zvgZ/WtYT++2Ibcp4igZ CWdqDtjys0gnq6ppla89bF68X78XKEQpVcbgt3/D0fJLOlHyzTyL9JZoPh4rW+jtlbWPVae4b 8lSRaJsPOTv6XCC54Qg4WfQr1zRnnmUQdXjLXqH32h3we5Em1OZkd67c9lnXPFtfAbm2LqT4w Qp37upJpfF4SCTVrdKOpdMMOHtj9dPFD+dZQ9YjcwHrx9R9aE8rq3mQOkEY= Archived-At: Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:17:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ekqut6E5pNhPL0J2QMTqMqM9LVNO3jDr9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sean, we at ARM would find it somewhat unfortunate to remove the client authentication feature from the 0-RTT exchange since this is one of the features that could speed up the exchange quite significantly and would make a big difference compared to TLS 1.2. For the IoT use cases we need client authentication; I understand that the situation may be somewhat different in the Web space. So, I am not happy with the proposed change! Ciao Hannes On 03/29/2016 02:59 PM, Sean Turner wrote: > All, >=20 > To make sure we=E2=80=99ve got a clear way forward coming out of our BA= > sessions, we need to make sure there=E2=80=99s consensus on a couple of= > outstanding issues. So... >=20 > It seems that there is a clear consensus not to support 0-RTT client > authentication in TLS 1.3 at this time. If you think 0-RTT client > authentication needs to be supported please indicate so now and > provide your rationale. >=20 > J&S _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --Ekqut6E5pNhPL0J2QMTqMqM9LVNO3jDr9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/RVNAAoJEGhJURNOOiAtcBAH/2qaIHFwCam/fu+8Hc/d2eNi XFdZ3f3ijufQRMMnQzpVbODfOVZd0usYMQKqTP5cxlpJSb41lQb462PpNqvH/Wmp g4MTrFuJfG+fzJ3Z0Awhz656WFAS03T/s519oGmg6BUbizwfy4PuJUWIherggCBj qPJn6Ft08Snrhp9XSJMhXTvB9JtBeGoOOEvvz6yTCX9pKbR5ep5Dlh7wbRnKQNrI 2tIBrmjGbNT+7bvU/l+TndvcxhmKnpzXPQpPy2bqWUoY8s6lundo9dTg9FlG+ZxH nEEdqG4BbycJF0+E6gnm/G0sDLVYOt8ct4B8nZwEPv+4MSsVDw7ZwvdbrmGwp4o= =oanb -----END PGP SIGNATURE----- --Ekqut6E5pNhPL0J2QMTqMqM9LVNO3jDr9-- From nobody Thu Mar 31 05:20:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B777512D615 for ; Thu, 31 Mar 2016 05:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TCfuw-9IF4jN for ; Thu, 31 Mar 2016 05:20:06 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C65112D610 for ; Thu, 31 Mar 2016 05:20:06 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M2tKM-1ZuShA1WcQ-00sfds; Thu, 31 Mar 2016 14:20:03 +0200 To: Sean Turner , "" References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56FD15F6.30305@gmx.net> Date: Thu, 31 Mar 2016 14:20:06 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="63ev8nVSdbcVn2T19DtuQnaXti4o6ECjv" X-Provags-ID: V03:K0:njBZ7jlwWknIUHvM6TSDTxMmIaxcnlcsOrQCbyin2E5Zu17gmMf SlrFbsIteqnApKnkRkCGm/yMb/pcFxvqEEom9ptk7uBVDSvgPwD7vu0X9XkPzB696DGcfOv xuVYVi7Amg9l0jYHV/NUD+maQxLrwG7lEEHe6GZmxDZxZgDKtYiFHiknLnPFunrv1XGOwfq n0ZJfS7k2SC4TgOh3G0Dg== X-UI-Out-Filterresults: notjunk:1;V01:K0:nbDD+cM9ErI=:57NP79ejFDZP3JSlNQXH0t xYmO5PhTvhE4edI6LnjND//8vWgLoYh2mjFUSEANAHvYKbb1peNaagJu2o8XmlpCPid5o6EGJ gY77cbE7om40NeQT8hgPcnD1ffg9I+GnE9+pz7sPBBfAvaoCyBZcbnsMkZZB+2Tpv7h4u3rTX NzYIrLeCowHWce96nETkvOAE+HUjK7DG6xUCEvrvrELfw0bT00I0m84Nu3QTIl2pojn0ChQhM wetcx+yul6mpMIwT8eAyS7F8QUWAZGU1BJJOmhedvzctmAzzXbuBW9MZpSvFMtDhaInnJTgnm fUhf018lxoM3E+46GATdNw/0FewViWsQrjbxQ/lvc2HUdGMdN4omBanC6jk1zBq4xkoiSVBjl 2MhIwDX4mG8M9814e3CttNnvuDTPJHLhvLZcueTw5cS2RRp+PFHAbXKscJAxMi/1OykI0LwNJ bufxIMqCFk0Bl1rwvn1QVZBD8V1F3W0YwqiKjShOuUsM0wJFd3fUHUal8Owc4vDfzHDZcE4i2 XhkfplWiPW5kvGnwu0Fj29Sz3ZeQ9++kj42DdtWv/6xXAlTRRxamj1SaMt7dQhTOxlZCz4c2a fq8Qx+p+WWP8HPCxi+O0IMA0GyEDXEf0lA5TVS8Sh44S7xCLVcGAyXNUmVzMn7CoX2P7PkFJ/ +nmKVP2L0LpwdnWRGTc+5wJMFZMjJ40MFKqksQ4PMkGJdTiW5AOLABh9HyRNtU6chwcpGjXOn +adr/lzrZjx1j/o5l2XzrlOASg4SODmum0eReYJSZscSgErhpPCuYhGPAfE= Archived-At: Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 12:20:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --63ev8nVSdbcVn2T19DtuQnaXti4o6ECjv Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sean, just to make sure that I properly understand the question: You are suggesting to remove the DHE support but not the ECDHE support from the 0-RTT exchange. Removing the DHE support is fine for us (at ARM) since we are focused on ECDHE for IoT devices. The DTLS/TLS profile and other IETF specifications very much focused on ECDHE and do not consider the use of DHE. Ciao Hannes On 03/29/2016 03:11 PM, Sean Turner wrote: > All, >=20 > To make sure we=E2=80=99ve got a clear way forward coming out of our BA= > sessions, we need to make sure there=E2=80=99s consensus on a couple of= > outstanding issues. So... >=20 > There also seems to be (rougher) consensus not to support 0-RTT via > DHE (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better > performance properties and is simpler to specify and implement. Note > that this does not permanently preclude supporting DHE-based 0-RTT in > a future extension, but it would not be in the initial TLS 1.3 RFC. >=20 > If you think that we should keep DHE-based 0-RTT please indicate so > now and provide your rationale. >=20 > J&S >=20 > _______________________________________________ TLS mailing list=20 > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >=20 --63ev8nVSdbcVn2T19DtuQnaXti4o6ECjv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/RX2AAoJEGhJURNOOiAty3sIAKffmlSmVpFAXofUo8Cc3P/B OA0JF6geJdE8uOGzEQL9PQAhJ4+7zUq9C8XjQD+sItnHsWaUF1GcvynDjrRpIFE6 kb6XKAfIj9A1snt74rSm8t0p82GrgzjYS5aa3yOKr9ge+PR3jT6+61FkdTKAQ3+X o1jN18sqp4oE7TJrSo2g6IX2z7k9WG0/lG7n4Dzqq/ewxmZrd59AA+l9Q0s5QLl5 fdiqzKYs3ZJZum9F8HzWrC7mcvAbyPWFrLgHL0EqINgd6rTvhLlkgw3iLfhhRIyQ VJZiJOGERabuSI34MKW7+aWPbpAEuQvqGwrzu8qZsnVW2ya0GDtGat2Jp3Y8HPI= =uc2M -----END PGP SIGNATURE----- --63ev8nVSdbcVn2T19DtuQnaXti4o6ECjv-- From nobody Thu Mar 31 06:45:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54C12D0EF for ; Thu, 31 Mar 2016 06:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TiFOKxD9h_km for ; Thu, 31 Mar 2016 06:45:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D1612D150 for ; Thu, 31 Mar 2016 06:45:49 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MbsV8-1aTY6R0UaM-00JKyh; Thu, 31 Mar 2016 15:45:46 +0200 To: Sean Turner , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FD2A0A.1050607@gmx.net> Date: Thu, 31 Mar 2016 15:45:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jsPC9EieQSB3iPRegBtggPiqJo7a3TwnR" X-Provags-ID: V03:K0:KD3jagg9TnkKB51GPzmMWNgn9EBHAQ1v5jla+raHclItyWfNfU/ inPE/d3Et3i3m23NZO2IXbJyLAuiAhhs6IvGIPE/krd/pXCzwmcvQi5oWEcqcHljgF1Dxbt 9qCZtItnWBXgndh5gLdjKlvc+78CfGgMRDdHe41tW0CEspGDrLMDDPWpa6S6k87SIqjf1Hm ZNq6/8z+1XWYDOQO6R2dg== X-UI-Out-Filterresults: notjunk:1;V01:K0:tz90H3aEpdM=:5C/TK4SLtACSBPKR8OhhEd sh1g1GuTCb4dexWQikBd0qQ4kOHdrac7AewsMUDMiVxvHXQ8bjCjkhs96ySzZy6zPgEPkxsPG o4vtm8zpbYs9DKT+KtvpailOZ8DwuiGgXd/oC6BC4h0BVxv5qgVQyqvzeh3frJ162/veNEjjH bsfcFrkEl3E60JGr3U1NPZOZc0vLbSwln2m36jSzJl0E+vs66qqM/fwe+0UC4D4WANUjtikgD vLL277MuXSveEekiRx2PofcRq5v0jcq01T5VR96RXFbkyegNNsxJN2/aae3BXvTcX8kbK1yDr dkpuETQF0dvA9FDwikBzinafpn20dgCNaKa0z0y0jarjN6W/rha5zt3m7koA83BoHPsfm6vkB jzOhdfELqWKdl0w2YXowPtLDV3htzzmrp6tI7hUt9Pl9TPpTtijl5YmuUrAvYQd81grCla/8L g1OwCGDKiT2bUA5QQd8akNEN4XU+eaGwkDyRnYWXiK674f9xnBHXTl45r9oLFCwtR4mYis9sS G9v8RFgml+I7dYg1MMNn2UiuwNrAkYZ7sd6nwEjELlmbMDzMCJAPJHakdYzLWDHOq4ea60Vy6 oRZQqlD31Xl3Szp4JR+6Z6VMlGTjZFnKz8Qjpm9iOxrKRRziHLyLgcJkoL70pTXa35knwGLgt b0ghU31ZPzMjKH5agLP3m8H/TwSPbZXBtCvmtUUKfCWmkyzun0kLtmz7bWj7K4iNO8EN1KJ7E qgin1lPSEtsjj+GDxpZBveJcQr4ivTlLexBuFpJGjvs+u1WYAPJWak5cyDY= Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:45:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jsPC9EieQSB3iPRegBtggPiqJo7a3TwnR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Sean, What is the requirement for adding a spec to the list with the value IETF Recommended =3D "Y" (or to change an entry from "Y" to "N")? You mention two conditions: * IETF has consensus * Are reasonably expected to be supported by widely used implementations such as open-source libraries Of course, with all our work we expect them to be supported by widely used implementations. The future is unpredicable and therefore not a good item for making a judgement. I realy find document authors who have less interest to get their stuff deployed. Getting IETF consensus on specifications has turned to be easier than most people expect and the IETF published RFCs that have not received a lot of review. Large amount of review is not a pre-condition for consensu= s. While your idea sounds good it suffers from practical issues. I am worried that the process will not be too fair and may favor a certain type of community. Ciao Hannes On 03/30/2016 03:53 AM, Sean Turner wrote: > Hi! >=20 > In Yokohama, we discussed changing the IANA registry assignment rules f= or cipher suites to allow anyone with a stable, publicly available, peer = reviewed reference document to request and get a code point and to add an= =E2=80=9CIETF Recommended=E2=80=9D column to the registry. This change = is motivated by the large # of requests received for code points [0], the= need to alter the incorrect perception that getting a code point somehow= legitimizes the suite/algorithm, and to help implementers out. We need = to determine whether we have consensus on this plan, which follows: >=20 > 1. The IANA registry rules for the TLS cipher suite registry [1] will b= e changed to specification required. >=20 > 2. A new =E2=80=9CIETF Recommended=E2=80=9D column will be added with t= wo values: =E2=80=9CY=E2=80=9D or =E2=80=9CN=E2=80=9D. Y and N have the = following meaning: >=20 > Cipher suites marked with a =E2=80=9CY=E2=80=9D the IETF has consensus= on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =E2=80=9CN=E2=80=9D. Not IETF recommended does not necessarily (but c= an) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. >=20 > 3. We will add a =E2=80=9CNote" to the IANA registry itself (i.e., on [= 0]) that matches the above so that the same information is available to t= hose who don=E2=80=99t read the IANA considerations section of the RFC. >=20 > Please indicate whether or not you could support this plan. >=20 > Thanks, >=20 > J&S >=20 > [0] In the last year, the chairs have received requests for: >=20 > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead= / > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.tx= t > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/= > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. >=20 > [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtm= l#tls-parameters-4 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --jsPC9EieQSB3iPRegBtggPiqJo7a3TwnR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/SoKAAoJEGhJURNOOiAtoD8H/jRiw4mpUuFthKkGkSDph+ud INI/Vo/bPsbG3J+TvoWLEZFU+CUYCDhtfAG2Uyekv61E4kaSjWjSu/msRYdul+BV 3LBXbqK/RI1Fvqiv4lYhrCjFxBBULdKh3jY7RIU3VyBsTleGRceIt0pi9QQ7jQ/G 0aiN3h8guRPsBcy0DyQ0B+Gr8nA0UYvczT6eJuYCvTvok1x3w/sdzXIh3EI9YnVi jHooga66umQw7k8dvcXNhx59MBeXM2eH6pT0eqZSKHImlRv3nV92NDnNBU+WQQ4U /AC1tK0lCIjBlReUmoQG4Lgis0+xQb2o5r/iTckIF7naGQjuvX6+FMLasXfiSWw= =Thcf -----END PGP SIGNATURE----- --jsPC9EieQSB3iPRegBtggPiqJo7a3TwnR-- From nobody Thu Mar 31 06:56:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBA12D153 for ; Thu, 31 Mar 2016 06:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 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] 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 dHuop_vxPQUO for ; Thu, 31 Mar 2016 06:56:09 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251BE12D6C1 for ; Thu, 31 Mar 2016 06:55:33 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id h65so98187798ywe.0 for ; Thu, 31 Mar 2016 06:55:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v3t2zlhYTVxsIIvq4TqdwppLiKvBc6FNs1I7uHm/2g8=; b=AJsBqcMkOW/YjthE84QY8C2Z+dPlljMybXz4frTb7Kgbq/nFg2hXpcLVQ6TMykRTnE 8D0xaMQZjnb2WfYDJ5ovNlulFpYriHQ1L4yF11N4Tj8Vk5Dg3t5ZpzmzM6o4w7Z3Flpo SXqmeEtsHrKiMczw51l2KhbHqq4LcrrutokgS2d3+YN7Rusx0haI8l+jOWJNnK0a1JDx uipC1bfN0VEs4YDSct/KavMSdCuGYSyRViEkMkmt+VSgd9vxzbiKd5k0nx2dOExtSUnK 56lI5AfaJwkMoa2iUlYbgSlbtguACdGOIo8dhr7+1GmLVp+YjBUY/oKSmZB9E6dGyvNs /t9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v3t2zlhYTVxsIIvq4TqdwppLiKvBc6FNs1I7uHm/2g8=; b=bLpl6nWltxtd/7el1hguGTfA9jKA+msqXmOdU1WYMmO3ZNIVlDcpVWDRvsZ1HMH6Ps iNtdoJFHpZDSBDsLPMaWP7PZ26tvhNr8MDWURxcOdvL27bCQ7rdpwuO+P7Bd0cEPNn8F HaRSFpfm4e9yRDrF0gHfhAoKTzqS6w08NaUW5tH5PDV8drF8snPNmORqyBIMVUbda5AB 8qdFm6mIEBnhE3IIoryR+BtIbzvixvemd1bpt90tc99AvHNhiuZIaghL0RPSq4SAonGB aVMP7NMmePej0XKL6u1EyB9KjeE99gUQelO6domDpXWQI0fywhwP0FFYTTQjZWsov5KA LMcw== X-Gm-Message-State: AD7BkJL2lkh/Z+/mfaDlddN/1/6Pshwem4ezGzvuNvTGeW1ZbqH4NSDAdmIMl85lrPrJvRFU+e7FeBRaZJt/hA== X-Received: by 10.37.231.216 with SMTP id e207mr7858610ybh.130.1459432532374; Thu, 31 Mar 2016 06:55:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 06:54:52 -0700 (PDT) In-Reply-To: References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> From: Eric Rescorla Date: Thu, 31 Mar 2016 06:54:52 -0700 Message-ID: To: Dacheng Zhang Content-Type: multipart/alternative; boundary=94eb2c0b11d0aaa4f0052f589d60 Archived-At: Cc: tls , =?UTF-8?B?5YiY5aSn6bmPKOm5j+aIkCk=?= Subject: Re: [TLS] =?utf-8?b?5Zue5aSN77yaIEEgVExTIGV4dGVuc2lvbiB0cmFuc2Zlcmlu?= =?utf-8?q?g_service_indication_information?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 13:56:16 -0000 --94eb2c0b11d0aaa4f0052f589d60 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang wrote: > Thanks again for your comments. See my reply inline please. ^_^ > >> >> I'm not following. If you trust the device, then why do you need any kin= d >> of cryptographic >> authentication on the token. >> >> Dacheng=EF=BC=9ALet assume we trust the device. But the APP use a SNI to= indicate >> the service that the APP intends to access. Because the SNI is static wh= ich >> may not be changed for months, it is easier for attackers who monitor th= e >> network to get the SNI and use it to gain benefit. We need a securer >> solution. As I have mentioned in my previous email, this solution will m= ake >> such attacks more difficult. By the way, SNI is not designed for this >> purpose, we need to do some additional work to address this issue, right= ? >> > > Again, you need a threat model. It sounds like you both do and do not > trust the client > > Dacheng: Threat model will be provided. Actually=EF=BC=8Cwe don=E2=80=99t= try to protect > against the compromise of client. Or the scenario where an APP against > another one on the same device. This solution is used to protect against > the attackers who are able to monitoring the communication between the > client and the server > I'll await this. > > >> Hmm... I'm not at all sure that TLS should address this problem. However= , >> my review >> was directed to whether your proposed solution even works on its own >> terms. >> >> Dacheng: That is why we need to raise the discussion here. It would be >> great if this issue could be considered by TLS WG. >> > > I don't find this to be a very compelling use case and I don't think it's > really appropriate to > try to solve it at the TLS layer. If you want to have secure flow > identification you should > do it at the IP or TCP layers. > > Dacheng:Ok, this requirement is quite strong. We need a solution to > address this issue if we want to use TLS to secure our APPs deployed on > hundreds o millions o mobile devices. Also=EF=BC=8CChina mobile and Huaw= ei are working > with us on this issue. > No, you only need it if you want to use a specific charging model. Could you please tell me why it is better to address this issue at the IP > or TCP layer. To the best of my knowledge. There is no space in IPv4 > herders to insert any extensions. There are length limit in TCP options. = In > addition, TCP is implemented in kernel mode. It will cost more if we try = to > address this issue at the TCP or IP layer. > I think the architectural reasons here are pretty clear. IP is the common network transport layer, not TLS. Also, IPv6 has extension headers. -Ekr Look forward to more discussions. ^_^ > > Cheers > > Dacheng > >> >>>> >>>> >>> >> > --94eb2c0b11d0aaa4f0052f589d60 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang <<= a href=3D"mailto:dacheng.zdc@alibaba-inc.com" target=3D"_blank">dacheng.zdc= @alibaba-inc.com> wrote:
Thanks again for your comments. See my rep= ly inline please. ^_^

I'm not followin= g. If you trust the device, then why do you need any kind of cryptographic<= /div>
authentication on the token.
=
Dacheng=EF=BC=9ALet assume we trust the device. But the APP use a = SNI to indicate the service that the APP intends to access. Because the SNI= is static which may not be changed for months, it is easier for attackers = who monitor the network to get the SNI and use it to gain benefit. We need = a securer solution. As=C2=A0I have mentioned in my previous email, this sol= ution will make such attacks more difficult. By the way, SNI is not designe= d for this purpose, we need to do some additional work to address this issu= e, right?

Again, = you need a threat model. It sounds like you both do and do not trust the cl= ient

Dacheng: Threat mo= del will be provided. Actually=EF=BC=8Cwe don=E2=80=99t try to protect agai= nst the compromise of client. Or the scenario where an APP against another = one on the same device. This solution is used to protect against the attack= ers who are able to monitoring the communication between the client and the= server

I'll await t= his.

=C2=A0


Hmm... I'm not at all sure that TLS should address this problem. Howev= er, my review
was directed to whether your proposed solution even= works on its own terms.

Dacheng: That i= s why we need to raise the discussion here. It would be great if this issue= could be considered by TLS WG.

I don't find this to be a very compelling use case and I don= 9;t think it's really appropriate to
try to solve it at the T= LS layer. If you want to have secure flow identification you should
do it at the IP or TCP layers.

<= /span>
Dacheng:Ok, this requirement is quite strong. We need a solution to ad= dress this issue if we want to use TLS to secure our APPs deployed on hundreds o millions o=C2= =A0mobile devices.=C2=A0 Also=EF=BC=8CChina mobile and Huawei are=C2=A0working with us on this issue.
<= div>
No, you only need it if you want to use a specific charg= ing model.


Could yo= u please tell me why it is better to address this issue at the IP or TCP la= yer. To the best of my knowledge. There is no space in IPv4 herders to inse= rt any extensions. There are length limit in TCP options. In addition, TCP = is implemented in kernel mode. It will cost more if we try to address this = issue at the TCP or IP layer.=C2=A0
I think the architectural reasons here are pretty clear. IP is = the common network transport
layer, not TLS. Also, IPv6 has exten= sion headers.

-Ekr


Look forward to more discussions. ^_^
=

Cheers

Dacheng



=



--94eb2c0b11d0aaa4f0052f589d60-- From nobody Thu Mar 31 07:49:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF6F12D162 for ; Thu, 31 Mar 2016 07:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 ut4FLese9eAx for ; Thu, 31 Mar 2016 07:49:30 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0635F12D17C for ; Thu, 31 Mar 2016 07:49:29 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 197F1423742; Thu, 31 Mar 2016 14:49:29 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id EDC03423736; Thu, 31 Mar 2016 14:49:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459435768; bh=HHFi5KA7BNNlD8qPQwt98g5I/JTzw3lDjLq0kdDE/UU=; l=366; h=From:To:Date:References:In-Reply-To:From; b=rIZfSAFPINDUF2OrmciGa2rsjGOBajfqiloTkhN6LY27oZZvLqaY9oBczLMHQIgH4 Dj5B4EaqZGGsZEOsZwTsgKtXkHnuTwkSwI807bRKWzXbsXyi08PiSKmddsQYugG3me QCUljIgVQYRdhF2nrjYs1In6kM0z6Yewc0+/soN8= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id DC1291FCA5; Thu, 31 Mar 2016 14:49:28 +0000 (GMT) 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.1130.7; Thu, 31 Mar 2016 10:49:28 -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.1130.005; Thu, 31 Mar 2016 10:49:28 -0400 From: "Salz, Rich" To: Hannes Tschofenig , Sean Turner , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1Oq2gkcA0SHxUGmL9jZ8Js6tp9zojdQ Date: Thu, 31 Mar 2016 14:49:28 +0000 Message-ID: <523f778cfc3740bfa6952255c26d8f3f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> In-Reply-To: <56FD2A0A.1050607@gmx.net> 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.116.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:49:32 -0000 DQo+IFdoYXQgaXMgdGhlIHJlcXVpcmVtZW50IGZvciBhZGRpbmcgYSBzcGVjIHRvIHRoZSBsaXN0 IHdpdGggdGhlIHZhbHVlIElFVEYNCj4gUmVjb21tZW5kZWQgPSAiWSIgKG9yIHRvIGNoYW5nZSBh biBlbnRyeSBmcm9tICJZIiB0byAiTiIpPw0KDQpJIGJlbGlldmUgdGhlIHByaW1hcnkgY29uY2Vy biBpcyAqbm90KiB0byBhZGRyZXNzIElFVEYgcHJvZHVjdHMsIGJ1dCByYXRoZXIgbm9uLUlFVEYg b3JnYW5pemF0aW9ucyB0aGF0IHdhbnQgYSBjb2RlcG9pbnQuDQo= From nobody Thu Mar 31 07:54:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362CF12D1EA for ; Thu, 31 Mar 2016 07:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.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 Wexe2y-9Pq2M for ; Thu, 31 Mar 2016 07:54:50 -0700 (PDT) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0118.outbound.protection.outlook.com [23.103.200.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C120B12D1A3 for ; Thu, 31 Mar 2016 07:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bXYybmL5BU3FXomp3ivtOHUAvskBuI+6cSk9CHkdCpo=; b=QGEi4z+hxiq4qNcsIoMuCO1WmbbQzydnTIeKSpWFKN6+YbNgZyy8S9BSQPTrfpREey1JEXR7om3C3RPoe66PSoF/hMbv1jC6zdwajBX10fyEgbMGPeNOk5r5TxUWYH2QsMQULMemGUGRnqmbjnIKz+laWviEKMf7+Wsn43uMJR4= Received: from BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) by BN1PR09MB124.namprd09.prod.outlook.com (10.255.200.27) with Microsoft SMTP Server (TLS) id 15.1.434.16; Thu, 31 Mar 2016 14:54:47 +0000 Received: from BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) by BN1PR09MB124.namprd09.prod.outlook.com ([10.255.200.27]) with mapi id 15.01.0434.023; Thu, 31 Mar 2016 14:54:47 +0000 From: "Dang, Quynh (Fed)" To: Hannes Tschofenig , Sean Turner , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1Owi0D04/+DE0+p53p0UyUeQJ9zoync Date: Thu, 31 Mar 2016 14:54:46 +0000 Message-ID: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com>, <56FD2A0A.1050607@gmx.net> In-Reply-To: <56FD2A0A.1050607@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmx.net; dkim=none (message not signed) header.d=none;gmx.net; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.105.150] x-ms-office365-filtering-correlation-id: d1c7fad6-25e1-42d8-4f25-08d359746717 x-microsoft-exchange-diagnostics: 1; BN1PR09MB124; 5:ghsNWgDB3nMqSFACsj4Z8MeF5LDs+3GR77cfbyhovwakKu/MgPY5oTimt6YrrNCW8OcaYHFhCOTBVu6+PUtvE4dVu/82umO4csnk2pyiKtdbvOic4OvwEPaWm6hqPW+ojuOg5L+FdzHdwGhGX892iA==; 24:tArco740c3t/Cvw++EER9mg8xh9rHcEI8JDXZh9Rco1srdFPfGTqmAyaGlX+5BuoA+UwQgGGYdh6G9rdkFMkDMLy8EKi+YFZjhhCojUzBqk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB124; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN1PR09MB124; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB124; x-forefront-prvs: 0898A6E028 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(164054003)(50986999)(54356999)(5008740100001)(99286002)(2950100001)(87936001)(3280700002)(106116001)(15975445007)(3660700001)(3900700001)(76176999)(77096005)(66066001)(2906002)(2900100001)(11100500001)(92566002)(189998001)(1220700001)(74316001)(81166005)(107886002)(6116002)(5001770100001)(86362001)(1096002)(102836003)(3846002)(19580405001)(586003)(122556002)(5003600100002)(19580395003)(33656002)(76576001)(10400500002)(5004730100002)(5002640100001)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB124; H:BN1PR09MB124.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 14:54:46.7687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB124 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 14:54:56 -0000 Hi Sean and all, I support the first condition: A spec gets a "Y" when it has the IETF conse= nsus. Regards, Quynh.=20 ________________________________________ From: TLS on behalf of Hannes Tschofenig Sent: Thursday, March 31, 2016 9:45 AM To: Sean Turner; Subject: Re: [TLS] call for consensus: changes to IANA registry rules for c= ipher suites Hi Sean, What is the requirement for adding a spec to the list with the value IETF Recommended =3D "Y" (or to change an entry from "Y" to "N")? You mention two conditions: * IETF has consensus * Are reasonably expected to be supported by widely used implementations such as open-source libraries Of course, with all our work we expect them to be supported by widely used implementations. The future is unpredicable and therefore not a good item for making a judgement. I realy find document authors who have less interest to get their stuff deployed. Getting IETF consensus on specifications has turned to be easier than most people expect and the IETF published RFCs that have not received a lot of review. Large amount of review is not a pre-condition for consensus. While your idea sounds good it suffers from practical issues. I am worried that the process will not be too fair and may favor a certain type of community. Ciao Hannes On 03/30/2016 03:53 AM, Sean Turner wrote: > Hi! > > In Yokohama, we discussed changing the IANA registry assignment rules for= cipher suites to allow anyone with a stable, publicly available, peer revi= ewed reference document to request and get a code point and to add an =93IE= TF Recommended=94 column to the registry. This change is motivated by the = large # of requests received for code points [0], the need to alter the inc= orrect perception that getting a code point somehow legitimizes the suite/a= lgorithm, and to help implementers out. We need to determine whether we ha= ve consensus on this plan, which follows: > > 1. The IANA registry rules for the TLS cipher suite registry [1] will be = changed to specification required. > > 2. A new =93IETF Recommended=94 column will be added with two values: =93= Y=94 or =93N=94. Y and N have the following meaning: > > Cipher suites marked with a =93Y=94 the IETF has consensus on > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. The > IETF takes no position on the cipher suites marked with an > =93N=94. Not IETF recommended does not necessarily (but can) > mean that the ciphers are not cryptographically sound (i.e., > are bad). Cipher suites can be recategorized from N to Y > (e.g., Curve448) and vice versa. > > 3. We will add a =93Note" to the IANA registry itself (i.e., on [0]) that= matches the above so that the same information is available to those who d= on=92t read the IANA considerations section of the RFC. > > Please indicate whether or not you could support this plan. > > Thanks, > > J&S > > [0] In the last year, the chairs have received requests for: > > PSK: https://datatracker.ietf.org/doc/draft-mattsson-tls-ecdhe-psk-aead/ > AES-OCB: https://www.ietf.org/archive/id/draft-zauner-tls-aes-ocb-03.txt > Kcipher2: https://datatracker.ietf.org/doc/draft-kiyomoto-kcipher2-tls/ > dragonfly: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > NTRU: http://www.ietf.org/id/draft-whyte-qsh-tls12-01.txt > JPAKE: not sure they got around to publishing a draft. > > [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#= tls-parameters-4 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Mar 31 08:06:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CDC12D150 for ; Thu, 31 Mar 2016 08:06:51 -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 2wYT1r7BcJdF for ; Thu, 31 Mar 2016 08:06:49 -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 3EB2912D577 for ; Thu, 31 Mar 2016 08:06:01 -0700 (PDT) Received: by mail-yw0-x22a.google.com with SMTP id h65so100862869ywe.0 for ; Thu, 31 Mar 2016 08:06: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=jujnblnmS+vekU6ViUEAgyR1gGY9dIFFhpy16WmlMqo=; b=Yj9fbqflyAw4fxfqMxPXjhXLyLl/EzNeyfD+zASHIzIPMkL0bHUlBjwvFlvdk+UjTj xKy0SlHBzSsVKHlfrUmLNThG0Uz//17QjgLGSAfJlFlFtdEFD/Rw2yHx2fe9LHny19Jx FzIvDX1oGs8OMaSIAm2BhLbr8oKYu4iyjkyjMW/Ext9JJD3KW3aOJYtxSYAYCsMumKQO YFIGiNaPC39zgPxGQ1NLu0qt5qrQ5QlNnRdt/c4UVy//CcKIiapDCAxWWc7Qrn5GDlFo Qm15FLdGQT5wLIxTOtrjlwXSNIFqHPYtYwGr2t2DL74MvV1+DAu9z8ibJXkVrNZAENpu 0L6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jujnblnmS+vekU6ViUEAgyR1gGY9dIFFhpy16WmlMqo=; b=KiYN2ZXNzVvm892/YuXFCqBnKJn9RZwd+tLz2FXd8vg8xQB+UDXDKaGUKRAvauSKHj owImGl4+NjshoKuDoj3xPeBXSWBTxkq1RK77GhdNUbd4/YhkuHt4TQOnpk9kwMaJRNXt Q2uu8OI85uhkB3IhLMouxBmRAFVIGCnLn47P3IrihUec5RD+iyJbTThTOAK08xWrzNpB q3vPxBOOHga8uRSrm5ulkgH39dUF2IImRHzHlL/XLHhPuy5znP+Mx6N4qX3zLR8ZIrHy Srrj2/+onONTHLkyFV4nTa1Sldvnn7iHge9ewjoiN1jNSA8tXCta4aFCovAjYEuWwdBJ XpfA== X-Gm-Message-State: AD7BkJI/zXq2CAtT8L31syDNCH27DCO8VuL/AKrj4ITvrSNm8P3vMfOdxWqorHfoHTHaYaVQ+qMukgdaPLYMNQ== X-Received: by 10.129.152.10 with SMTP id p10mr7537055ywg.129.1459436760391; Thu, 31 Mar 2016 08:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 08:05:20 -0700 (PDT) In-Reply-To: <56FD15F6.30305@gmx.net> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> <56FD15F6.30305@gmx.net> From: Eric Rescorla Date: Thu, 31 Mar 2016 08:05:20 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=94eb2c0bbf62ad12b8052f5999c6 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:06:51 -0000 --94eb2c0bbf62ad12b8052f5999c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hannes, No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. The only way to do 0-RTT would be with a PSK (in both PSK and PSK-(EC)DHE modes). However, this would include PSKs established via a previous session, i.e., resumption-PSK. -Ekr On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Sean, > > just to make sure that I properly understand the question: You are > suggesting to remove the DHE support but not the ECDHE support from the > 0-RTT exchange. > > Removing the DHE support is fine for us (at ARM) since we are focused on > ECDHE for IoT devices. The DTLS/TLS profile and other IETF > specifications very much focused on ECDHE and do not consider the use of > DHE. > > Ciao > Hannes > > > On 03/29/2016 03:11 PM, Sean Turner wrote: > > All, > > > > To make sure we=E2=80=99ve got a clear way forward coming out of our BA > > sessions, we need to make sure there=E2=80=99s consensus on a couple of > > outstanding issues. So... > > > > There also seems to be (rougher) consensus not to support 0-RTT via > > DHE (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only > > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and > > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better > > performance properties and is simpler to specify and implement. Note > > that this does not permanently preclude supporting DHE-based 0-RTT in > > a future extension, but it would not be in the initial TLS 1.3 RFC. > > > > If you think that we should keep DHE-based 0-RTT please indicate so > > now and provide your rationale. > > > > J&S > > > > _______________________________________________ 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 > > --94eb2c0bbf62ad12b8052f5999c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hannes,

No, the proposal is to remove b= oth EC and non-EC DHE 0-RTT profiles.

The only way= to do 0-RTT would be with a PSK (in both PSK and PSK-(EC)DHE modes).
=
However, this would include PSKs established via a previous session, i= .e., resumption-PSK.

-Ekr


On Thu, Mar 31,= 2016 at 5:20 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net= > wrote:
Hi Sean,

just to make sure that I properly understand the question: You are
suggesting to remove the DHE support but not the ECDHE support from the
0-RTT exchange.

Removing the DHE support is fine for us (at ARM) since we are focused on ECDHE for IoT devices. The DTLS/TLS profile and other IETF
specifications very much focused on ECDHE and do not consider the use of DHE.

Ciao
Hannes


On 03/29/2016 03:11 PM, Sean Turner wrote:
> All,
>
> To make sure we=E2=80=99ve got a clear way forward coming out of our B= A
> sessions, we need to make sure there=E2=80=99s consensus on a couple o= f
> outstanding issues.=C2=A0 So...
>
> There also seems to be (rougher) consensus not to support 0-RTT via > DHE=C2=A0 (i.e., semi-static DHE) in TLS 1.3 at this time leaving the = only
> 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and
> DHE-based 0-RTT are almost identical, but 0-RTT PSK has better
> performance properties and is simpler to specify and implement. Note > that this does not permanently preclude supporting DHE-based 0-RTT in<= br> > a future extension, but it would not be in the initial TLS 1.3 RFC. >
> If you think that we should keep DHE-based 0-RTT please indicate so > now and provide your rationale.
>
> J&S
>
> _______________________________________________ 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


--94eb2c0bbf62ad12b8052f5999c6-- From nobody Thu Mar 31 08:26:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AFBC12D1A3 for ; Thu, 31 Mar 2016 08:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 orrZK7KO24eS for ; Thu, 31 Mar 2016 08:26:10 -0700 (PDT) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF3F12D19D for ; Thu, 31 Mar 2016 08:26:09 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud6.xs4all.net with ESMTP id cfS51s01R10HQrX01fS7he; Thu, 31 Mar 2016 17:26:07 +0200 Message-ID: <56FD418C.1010709@openfortress.nl> Date: Thu, 31 Mar 2016 17:26:04 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Sean Turner References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> In-Reply-To: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:26:17 -0000 Hi, In general I think this is a good form of relaxation. However, > > Cipher suites marked with a “Y” the IETF has consensus on An alternative could be to mark the entry with the RFC 5226 level of the documentation, and indicate what levels are acceptable. A black/white distinction will probably lead to a lot of discussion, and different implementation purposes could call for more subtlety. > and are reasonably expected to be supported by widely > used implementations such as open-source libraries. This is a vague one, and may unleash more discussion than it saves. Also, this should not turn into a suggestion of using implementations rather than specifications as leading. I've seen a lot of that around Kerberos, where sane changes can get bogged down because there is (or may be) an implementation that couldn't live with it. > > Please indicate whether or not you could support this plan. > Yes, in broad lines, but I have the noted concerns / suggestions. -Rick From nobody Thu Mar 31 08:33:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8252112D571 for ; Thu, 31 Mar 2016 08:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 j2QVNVV-vHnt for ; Thu, 31 Mar 2016 08:33:55 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C908612D1EA for ; Thu, 31 Mar 2016 08:33:54 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MdK8t-1aUG2n2bBL-00IWKB; Thu, 31 Mar 2016 17:33:51 +0200 To: Eric Rescorla References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> <56FD15F6.30305@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FD4360.7010100@gmx.net> Date: Thu, 31 Mar 2016 17:33:52 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uSvagITv4md5VxMhw2bhAwfvRoJ4cQPEC" X-Provags-ID: V03:K0:C6U+t8aI0UH+X6QhvI9jxX4PwPiMB+Z2PXPoOK+Am9ON4yr+mdv z9RO/5qoWpzbnkkUr+KkzvNvFSLW0q8j1LET1Z4mcVKggb6B84Q2NK2xJ35ka0q5ot6bo3H zeVeFu4Yg9mYRDMt7APJ5X2EsAe9jk7J05inMxxdnkysPAKf1tG71qCpee3XGri0wWfzjlq gHpSqoadtGYX6gQfUcHCg== X-UI-Out-Filterresults: notjunk:1;V01:K0:XgSF5pCA37w=:+K6mKc5QjIB4h5k3e6B4Cg H7Hkq5fqAjhrpRdAgKpxnlKoqn2uS1gRXd5EGu9bGw1K+JwLcFo8Mw6fzVFs90alJZKys6M4M uo8FBgrqML3P5BCk5IkCUDIWFpjSRJ5/mcJnw6KbFFpjC7hKry4j7sM4uUg3ddE3XW9Kh0/9T U4pX9UhTkCSDD02lpARNDPOS2zCgGeA0tY7l8amXQQeIbHfO1jk56kN7uKj0a0HntD5P78cM3 H9S20BKg5CIFGrzbiQSLCpkoZt9VI+52OfWVwFUtSWKdlzHhS5Y82Z6vo2NnhLQeep63TGqfi lVR+HmECioHQIjVR/nMEjJLF6+1roLOiBJuLjTZm0p7kJVXIVLRmvnjNKvdsH5a1YYMCnjEKT To34+Nw4Z1AVtUBiETZQLt15kVL1M+CGWPMTc27l3N37ZOzCq7IkVN1EvkazFhxffYkjN82ZD 7jq3+584qvhtPbat+3EOkuCcoXtoouK9JdqNG2q9TdZG8y/OyKA7DlngbONnd2jcK0OaLyuUn hxNhKs0OmiGG8EaTqrkpwSvu0viGA6B5l1rKmWfHC6fgJLO0k78Sbp95SpNg5mNHULLBvt8T+ 2n4gb790ccxoe0Kizh7QxfAKqwEIZSzpL+2tkunVsELRN9fSB/OtWBKu49BamURQ2fWFBXzwh 1JugLF90j9ZbuunJBc1nG6K9yz9eJpY8RfS9osidKFRzztYv4zcwhpSTFmmVIYQs4ykY+w7Ku JeAEh9j22LD8WQGzp8fcRr+ZFTyf6bjL1y8fho6oXTjrr/cOaxt7g2ja/jQ= Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:33:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uSvagITv4md5VxMhw2bhAwfvRoJ4cQPEC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, On 03/31/2016 05:05 PM, Eric Rescorla wrote: > Hannes, >=20 > No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. >=20 > The only way to do 0-RTT would be with a PSK (in both PSK and > PSK-(EC)DHE modes). I see. This is, of course, a bit unfortunate. > However, this would include PSKs established via a previous session, > i.e., resumption-PSK. Only established in previous sessions or also distributed out-of-band (as it would be done with PSKs normally). The way you phrased it sounds like you want to exclude the out-of-band case and I wonder why. Ciao Hannes >=20 > -Ekr >=20 >=20 > On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig > > wrote: >=20 > Hi Sean, >=20 > just to make sure that I properly understand the question: You are > suggesting to remove the DHE support but not the ECDHE support from= the > 0-RTT exchange. >=20 > Removing the DHE support is fine for us (at ARM) since we are focus= ed on > ECDHE for IoT devices. The DTLS/TLS profile and other IETF > specifications very much focused on ECDHE and do not consider the u= se of > DHE. >=20 > Ciao > Hannes >=20 >=20 > On 03/29/2016 03:11 PM, Sean Turner wrote: > > All, > > > > To make sure we=E2=80=99ve got a clear way forward coming out of = our BA > > sessions, we need to make sure there=E2=80=99s consensus on a cou= ple of > > outstanding issues. So... > > > > There also seems to be (rougher) consensus not to support 0-RTT v= ia > > DHE (i.e., semi-static DHE) in TLS 1.3 at this time leaving the = only > > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and= > > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better > > performance properties and is simpler to specify and implement. N= ote > > that this does not permanently preclude supporting DHE-based 0-RT= T in > > a future extension, but it would not be in the initial TLS 1.3 RF= C. > > > > If you think that we should keep DHE-based 0-RTT please indicate = so > > now and provide your rationale. > > > > J&S > > > > _______________________________________________ TLS mailing list > > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 --uSvagITv4md5VxMhw2bhAwfvRoJ4cQPEC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/UNgAAoJEGhJURNOOiAteGkIAKUfBzGgWM7lloVlYXHhDb+v Iw0BaEyf1uJwY/eZl03e3/PxSVMsKvpWGFooHXbdrDVu/d/KgMqbWe9BmJdgTMtD gZD2L96zwdKOfJkIBdiBNSN+J+bKxhiFoQfxGT2rakc8IDmkNQ2UxCBqvg5wAJOa qnYxGK/vhYCFOwykQtyC3EpcmQm1touC1bse1DlOUZSzvQI7z44hBWUGGATPV2OA Mci0Dsxw3+I2A6GZGkLYeyL27RlxDRGwX30mkkaF3IS4oXzVWEM4b/+ZqfUXC7N4 UjZAKQCQdXjTEGXzoMdEYe28QrQog5bqNc7NOi4GC8r7gYoKDqWQp6Mq5TOrdMI= =D7sE -----END PGP SIGNATURE----- --uSvagITv4md5VxMhw2bhAwfvRoJ4cQPEC-- From nobody Thu Mar 31 08:49:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6F1D12D1EA for ; Thu, 31 Mar 2016 08:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 q671BNH7k4z5 for ; Thu, 31 Mar 2016 08:49:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id B6C1412D565 for ; Thu, 31 Mar 2016 08:49:47 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D51BD43344D; Thu, 31 Mar 2016 15:49:46 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BC910433410; Thu, 31 Mar 2016 15:49:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459439386; bh=i0rjgw4PBhsO8L3OTUrfBluyODFnKuKGYSJkWfE/KoY=; l=464; h=From:To:CC:Date:References:In-Reply-To:From; b=RXLur0Ni96ndGLwlEm+F8NiR5sgvDqFB/n9PAblIrnqSymmrFQJ8wXbyFJX9eooQW QVK78O+tBU298C3P0b0gum10TSRi4isKs1uhjitZpHCy2Cprk8wWotkUGGO8A8nwjZ 0627zXnIOv7c0sc/4huX/yTsNJGJQsk9WdTQO5tI= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B60601FC8D; Thu, 31 Mar 2016 15:49:46 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 31 Mar 2016 11:49:46 -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.1130.005; Thu, 31 Mar 2016 11:49:46 -0400 From: "Salz, Rich" To: Rick van Rein , Sean Turner Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi2G5K3IN+ITpNk6iG38opOLYmp9zstpw Date: Thu, 31 Mar 2016 15:49:45 +0000 Message-ID: <6d1f59f2d91944ffbdc0325504fa61b1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD418C.1010709@openfortress.nl> In-Reply-To: <56FD418C.1010709@openfortress.nl> 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.116.85] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 15:49:49 -0000 DQo+IEEgYmxhY2svd2hpdGUNCj4gZGlzdGluY3Rpb24gd2lsbCBwcm9iYWJseSBsZWFkIHRvIGEg bG90IG9mIGRpc2N1c3Npb24sIGFuZCBkaWZmZXJlbnQNCj4gaW1wbGVtZW50YXRpb24gcHVycG9z ZXMgY291bGQgY2FsbCBmb3IgbW9yZSBzdWJ0bGV0eS4NCg0KSSBzdHJvbmdseSB0aGluZyBpdCdz IHRoZSBleGFjdCBvcHBvc2l0ZS4gIEEgc2ltcGxlICJ5ZXMgYW4gSUVURiBXRyBjYW1lIHRvIGNv bnNlbnN1cyBvbiB0aGlzIiBpcyBtdWNoIHNpbXBsZXIgdGhhbiB0cnlpbmcgdG8gZGViYXRlIHZh cmlvdXMgc2hhZGVzIG9mIGdyZXkuICBPciBncmF5LiAgKFNlZSB3aGF0IEkgbWVhbj86KQ0K From nobody Thu Mar 31 09:03:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3975112D565 for ; Thu, 31 Mar 2016 09:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 YQg3p6P124cZ for ; Thu, 31 Mar 2016 09:03:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 491EB12D553 for ; Thu, 31 Mar 2016 09:03:16 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6B4584334DB; Thu, 31 Mar 2016 16:03:15 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 54C264334D7; Thu, 31 Mar 2016 16:03:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459440195; bh=OUToVs5b7j+9+9PwjsRWwoIQAc6FjPelCMmb13CGBmk=; l=2247; h=To:References:From:Date:In-Reply-To:From; b=CdKiMVfD39Wk2ThOJZ1WcbWVv8fi6j+E7WEwVJOPtgUQua2y0YxREBcdeh8tKaqkb vKYYQAKAJQ/iSEuZuWOJg48HBR3KQta8VmFm47s6bIVd89QbU+Oad7GRJgs+nPgwci w7EqCpuMU+/FdS6IQ3qyRy3DJNN2Wy7JwyItecCo= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 1C35D1FC8D; Thu, 31 Mar 2016 16:03:15 +0000 (GMT) To: Hannes Tschofenig , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <56FD4A42.2080100@akamai.com> Date: Thu, 31 Mar 2016 11:03:14 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD2A0A.1050607@gmx.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:03:18 -0000 On 03/31/2016 08:45 AM, Hannes Tschofenig wrote: > Hi Sean, > > What is the requirement for adding a spec to the list with the value > IETF Recommended = "Y" (or to change an entry from "Y" to "N")? > > You mention two conditions: > > * IETF has consensus > * Are reasonably expected to be supported by widely used > implementations such as open-source libraries > > Of course, with all our work we expect them to be supported by widely > used implementations. The future is unpredicable and therefore not a I don't think it's universally true that we expect all our work to be supported by widely used implementations. Sometimes we standardize things that are kind of niche cases and not expected to be widely used. (This also somewhat relates to the question, already raised, of how to turn a 'Y' back to a 'N' for things we decide we don't like any more.) > good item for making a judgement. I realy find document authors who have > less interest to get their stuff deployed. ...but I do agree that predictions of the future do not make good criteria here. > Getting IETF consensus on specifications has turned to be easier than > most people expect and the IETF published RFCs that have not received a > lot of review. Large amount of review is not a pre-condition for consensus. I think that documents introducing things that get a 'Y' should explicitly say that in the IANA considerations, so the IETF consensus explicitly includes support for the 'Y', and not all documents published with IETF consensus need to go for the 'Y'. Which is not to say that putting in such an IANA considerations section will magically cause people to read the document at IETF last call, of course, but I do have confidence that the IESG (if no one else) will ask whether the TLS working group has been consulted for something trying to set the 'Y' column. > While your idea sounds good it suffers from practical issues. I am > worried that the process will not be too fair and may favor a certain > type of community. > At the risk of making predictions of the future, it's not clear to me that the proposal will be any less fair than the current state of affairs (which is not perfect, either). -Ben From nobody Thu Mar 31 09:20:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB92D12D67C for ; Thu, 31 Mar 2016 09:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FzZhgSoGvJVS for ; Thu, 31 Mar 2016 09:20:08 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF0C12D639 for ; Thu, 31 Mar 2016 09:20:07 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LZz01-1a0FoA2F25-00llzS; Thu, 31 Mar 2016 18:20:00 +0200 To: Benjamin Kaduk , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FD4E32.5060409@gmx.net> Date: Thu, 31 Mar 2016 18:20:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD4A42.2080100@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JxQjiEjuuu7Isjh9bT6neN0cfJcUUqN7B" X-Provags-ID: V03:K0:YgfHgcSKI3mWCJsPheiJjCPYekENBhFrx9ihdcgXSHkRnwnS3fO eRnpXYuW5kZj/tmGRga/dWGl69krWxXIjKdcu5XesylkYiQe+Fa7nzXpSl2XHc9Lw0ymkh1 Rfa+7+fsvU3EK+Yurun6sZprpcJSJaaC3l4tlyM1D/qd4GNhhaKCu2PqPMW2xExC6mvojSX x6FHiT6lx3km7oMKkFEBw== X-UI-Out-Filterresults: notjunk:1;V01:K0:2SOHlQdjWoQ=:qI5Utk3mnVuj+voLocVxy6 l+pXmV8JcqBbw5r8VJLfS4xg4G+5kKwdYy/7urq3rZIT7Ok9NmPQfpHryfV4kfGiD6Oarny3Z g4Wy+abC76B9FB1NthfAjpcwMJmVlHopj1FYbJc+LuJ4psXRV8Sd+eMPrRC8cMWJk2qkPtSxM 5VQExWv0S7CcAi9sXMyQ5dsrQ3+11VNqoSBBwv1MVC6LPMygCwczRNy7qYojL/oe2iP1K7yeH AVw4581ytTYODKtvbzMCrWgNJmREqpBIbL5EXJDuQ+M7XxY6dLYiWP5oEJ6PuqfkxhansO8ba XlysEAllETWUPPXYvTMfgKmlkI/AlXieWonEer5uTolgtS5qUfi8o8SWT6OSSbCuqbwAImJfc hd9sKYt+fG1RKsj3405pILWoxdWr3R9EPb7YkwCEsoUQOzYJTA/I+xBrbxCK6NiGfSxArX6qV OJOGfDkCA4w+TWBLpjyVxROz0y2VsFEiCnK4ZSuFQvDAnypQJU7RDnx7X1IBgkknS8XDSFSU+ Th9s2Ukna+TLdsozT0j8o4Nf7gNVGlpNbvEJFlJbixbvTREdJSGA7mKVz3e7ujcs5Jwko4NCs Z5j/elGNNcECixmvHHbtOnG8cyaVQf5jWFWRcIReTzbiroVI4VvwlCRJ1NQ/MEZUd7okw2NVj OfovEZioBq0mpwAPbLQ5/jRMAAltZoOpjSvK8TMhEYCIFzLDXVJ+FEfiWuNYfKYFUrqlOso9Q 0BtjQ5TqQ8fdPqduYQlbl3qRyF97yRBpNQ2708lUu+HF2AZCkFgAsd8iXjE= Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:20:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JxQjiEjuuu7Isjh9bT6neN0cfJcUUqN7B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Ben, just think about the mentioned JPAKE extension: what type of deployment can you expect? It is something that Thread decided to use. Will Thread, as a mesh networking technology, be successful and widely be deployed? We don't know yet but if it becomes a technology of choice for use with IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I am sure the authors of the Thread specifications (and the members of the Thread consortium) expect their stuff to be widely used (in IoT -- not on the Web). Is this something that is good enough for this group? Web guys will hardly care about it. A large part of the TLS group is focused on the Web use only (at least that's my impression). =46rom the descriptions provided by Sean I don't know whether this is something that would be a "Y" blessing or not. This is what I call "sounds nice but ...". Ciao Hannes On 03/31/2016 06:03 PM, Benjamin Kaduk wrote: > On 03/31/2016 08:45 AM, Hannes Tschofenig wrote: >> Hi Sean, >> >> What is the requirement for adding a spec to the list with the value >> IETF Recommended =3D "Y" (or to change an entry from "Y" to "N")? >> >> You mention two conditions: >> >> * IETF has consensus >> * Are reasonably expected to be supported by widely used >> implementations such as open-source libraries >> >> Of course, with all our work we expect them to be supported by widely >> used implementations. The future is unpredicable and therefore not a >=20 > I don't think it's universally true that we expect all our work to be > supported by widely used implementations. Sometimes we standardize > things that are kind of niche cases and not expected to be widely used.= =20 > (This also somewhat relates to the question, already raised, of how to > turn a 'Y' back to a 'N' for things we decide we don't like any more.) >=20 >> good item for making a judgement. I realy find document authors who ha= ve >> less interest to get their stuff deployed. >=20 > ...but I do agree that predictions of the future do not make good > criteria here. >=20 >> Getting IETF consensus on specifications has turned to be easier than >> most people expect and the IETF published RFCs that have not received = a >> lot of review. Large amount of review is not a pre-condition for conse= nsus. >=20 > I think that documents introducing things that get a 'Y' should > explicitly say that in the IANA considerations, so the IETF consensus > explicitly includes support for the 'Y', and not all documents publishe= d > with IETF consensus need to go for the 'Y'. Which is not to say that > putting in such an IANA considerations section will magically cause > people to read the document at IETF last call, of course, but I do have= > confidence that the IESG (if no one else) will ask whether the TLS > working group has been consulted for something trying to set the 'Y' co= lumn. >=20 >> While your idea sounds good it suffers from practical issues. I am >> worried that the process will not be too fair and may favor a certain >> type of community. >> >=20 > At the risk of making predictions of the future, it's not clear to me > that the proposal will be any less fair than the current state of > affairs (which is not perfect, either). >=20 > -Ben >=20 --JxQjiEjuuu7Isjh9bT6neN0cfJcUUqN7B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/U4yAAoJEGhJURNOOiAtrLkH+gPe1g8jtERibJRBVAHOLVlk 6IiT5YofRdNgTcBO0rb4rc0JutUeTf0L4t8rB5cknGyCK14hKtJeVm0yDnTOn2P6 QHT14gjhQ27WyM+0oFvRhVPO+Nxj6JeWZ/P/6RS+yfzTTX952S4Z6UFvwD/kMGVi EgX1BvI173Zq0EivwJ7iZNMLcZp75M9Fgj1ztzGGuEKuc9ZzPVCtHLVNBuATdDJP 0kE1hyZpCfAbbBfBjBb5FMWJo2zCbyGb8tztKoiuAew3kijMK4AZnPnPdfQcLqXQ Si4nAZETZxnmmxIh29YO5TACGdDqW8iFgJADzypnvP+wp4NATsY8ZpyH2k9SjY4= =8xMl -----END PGP SIGNATURE----- --JxQjiEjuuu7Isjh9bT6neN0cfJcUUqN7B-- From nobody Thu Mar 31 09:27:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFF812D1AB for ; Thu, 31 Mar 2016 09:27:30 -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 G15ZlOl--86H for ; Thu, 31 Mar 2016 09:27:28 -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 7928812D621 for ; Thu, 31 Mar 2016 09:27:28 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h129so103910353ywb.1 for ; Thu, 31 Mar 2016 09:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rRoDeB+Qby+33pU9iJhxR6w9NeiE0MmLcoG8HkEBh2A=; b=AZ6zN7e3FHuENFeX0Qai0aNNurI1oRnuTem88GhABqPYnkF/j1m7eHxe4bOdl9EPW9 Cbp+5DXyPrPW+V92x/HCrex1FxdBj1LJo8S3Dvi6Vha1wgNRALdJ5SqcJDpJKYNr28/V /iRt4wnMHF21NQqtut+UIg6w4MNY5UceLCM95y7cM6EOxfsmCz9S+jvZiVI9VctooxNM fYSAr0xEeGl0UQPzg80C/TojBaZDEkW9QhdqAyXSmKb8EEqt4w59cfrvVcmHYANSLDl/ Hw0OdUTRxXjH4raBbRkTKBH+tyUF3ksFQ/CSllCaIDglRFPf7xqXE+ZpzLUfL/FIPnG6 NmtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rRoDeB+Qby+33pU9iJhxR6w9NeiE0MmLcoG8HkEBh2A=; b=Z5IAk/35x/jx/GI6K1n2PoYtHRjbQHks+eDbq+yq9d3RnbdJby8YzvYGxMkt6dAC5Q Pq/cVmxQ9NYzQwjjYHkhsyE/iWXdHkkJge/2kat3Hev7WQKLpLO6+zGLA6YIQdiati9m s1hhd4+70FzFdXWibTrPURwdQQC3MZPJOkumTpBCBLT4k68wQvPpvwbTpmU48Ly0W1/p IWRM/Y7EqYQfK5BuEmZBfBGJ/y3xGIUm+4dCyJzk78CxIMv9aUMMY8sbtzwJs58/BAuO ZTz9ecja3MS1K9OWORNRT6kzcTI0aZpY8kLEh6pnbfo5YwI2sLhvYcKswf6PU8BJFg5j 6qPA== X-Gm-Message-State: AD7BkJJSGzwlZ7O+eaKj8YvoBY2/gC4zdlnQL+tfWAjlEvhVSUyWYQNetPX2dmKfeQzrhcXQeo0qWi07awTn3w== X-Received: by 10.129.152.10 with SMTP id p10mr7808645ywg.129.1459441647430; Thu, 31 Mar 2016 09:27:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 09:26:47 -0700 (PDT) In-Reply-To: <56FD4360.7010100@gmx.net> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> <56FD15F6.30305@gmx.net> <56FD4360.7010100@gmx.net> From: Eric Rescorla Date: Thu, 31 Mar 2016 09:26:47 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=94eb2c0bbf62f762e4052f5abcd2 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:27:30 -0000 --94eb2c0bbf62f762e4052f5abcd2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2016 at 8:33 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Ekr, > > > On 03/31/2016 05:05 PM, Eric Rescorla wrote: > > Hannes, > > > > No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. > > > > The only way to do 0-RTT would be with a PSK (in both PSK and > > PSK-(EC)DHE modes). > > I see. This is, of course, a bit unfortunate. > Can you expand on why? The general sense of the discussion was that they offered similar properties. > > > However, this would include PSKs established via a previous session, > > i.e., resumption-PSK. > > Only established in previous sessions or also distributed out-of-band > (as it would be done with PSKs normally). The way you phrased it sounds > like you want to exclude the out-of-band case and I wonder why. > No, the out-of-band case is fine. -Ekr > > Ciao > Hannes > > > > > -Ekr > > > > > > On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig > > > wrote: > > > > Hi Sean, > > > > just to make sure that I properly understand the question: You are > > suggesting to remove the DHE support but not the ECDHE support from > the > > 0-RTT exchange. > > > > Removing the DHE support is fine for us (at ARM) since we are > focused on > > ECDHE for IoT devices. The DTLS/TLS profile and other IETF > > specifications very much focused on ECDHE and do not consider the > use of > > DHE. > > > > Ciao > > Hannes > > > > > > On 03/29/2016 03:11 PM, Sean Turner wrote: > > > All, > > > > > > To make sure we=E2=80=99ve got a clear way forward coming out of = our BA > > > sessions, we need to make sure there=E2=80=99s consensus on a cou= ple of > > > outstanding issues. So... > > > > > > There also seems to be (rougher) consensus not to support 0-RTT v= ia > > > DHE (i.e., semi-static DHE) in TLS 1.3 at this time leaving the > only > > > 0-RTT mode as PSK. The security properties of PSK-based 0-RTT and > > > DHE-based 0-RTT are almost identical, but 0-RTT PSK has better > > > performance properties and is simpler to specify and implement. > Note > > > that this does not permanently preclude supporting DHE-based 0-RT= T > in > > > a future extension, but it would not be in the initial TLS 1.3 RF= C. > > > > > > If you think that we should keep DHE-based 0-RTT please indicate = so > > > now and provide your rationale. > > > > > > J&S > > > > > > _______________________________________________ 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 > > > > > > --94eb2c0bbf62f762e4052f5abcd2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2016 at 8:33 AM, Hannes Tschofenig &l= t;hannes.tsc= hofenig@gmx.net> wrote:
Hi = Ekr,


On 03/31/2016 05:05 PM, Eric Rescorla wrote:
> Hannes,
>
> No, the proposal is to remove both EC and non-EC DHE 0-RTT profiles. >
> The only way to do 0-RTT would be with a PSK (in both PSK and
> PSK-(EC)DHE modes).

I see. This is, of course, a bit unfortunate.
<= br>
Can you expand on why? The general sense of the discussion wa= s that they
offered similar properties.
=C2=A0

> However, this would include PSKs established via a previous session, > i.e., resumption-PSK.

Only established in previous sessions or also distributed out-of-ban= d
(as it would be done with PSKs normally). The way you phrased it sounds
like you want to exclude the out-of-band case and I wonder why.

No, the out-of-band case is fine.

-Ekr
=C2=A0

Ciao
Hannes

>
> -Ekr
>
>
> On Thu, Mar 31, 2016 at 5:20 AM, Hannes Tschofenig
> <hannes.tschofenig@gmx.net <mailto:hannes.tschofenig@gmx.net>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Hi Sean,
>
>=C2=A0 =C2=A0 =C2=A0just to make sure that I properly understand the qu= estion: You are
>=C2=A0 =C2=A0 =C2=A0suggesting to remove the DHE support but not the EC= DHE support from the
>=C2=A0 =C2=A0 =C2=A00-RTT exchange.
>
>=C2=A0 =C2=A0 =C2=A0Removing the DHE support is fine for us (at ARM) si= nce we are focused on
>=C2=A0 =C2=A0 =C2=A0ECDHE for IoT devices. The DTLS/TLS profile and oth= er IETF
>=C2=A0 =C2=A0 =C2=A0specifications very much focused on ECDHE and do no= t consider the use of
>=C2=A0 =C2=A0 =C2=A0DHE.
>
>=C2=A0 =C2=A0 =C2=A0Ciao
>=C2=A0 =C2=A0 =C2=A0Hannes
>
>
>=C2=A0 =C2=A0 =C2=A0On 03/29/2016 03:11 PM, Sean Turner wrote:
>=C2=A0 =C2=A0 =C2=A0> All,
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> To make sure we=E2=80=99ve got a clear way for= ward coming out of our BA
>=C2=A0 =C2=A0 =C2=A0> sessions, we need to make sure there=E2=80=99s= consensus on a couple of
>=C2=A0 =C2=A0 =C2=A0> outstanding issues.=C2=A0 So...
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> There also seems to be (rougher) consensus not= to support 0-RTT via
>=C2=A0 =C2=A0 =C2=A0> DHE=C2=A0 (i.e., semi-static DHE) in TLS 1.3 a= t this time leaving the only
>=C2=A0 =C2=A0 =C2=A0> 0-RTT mode as PSK. The security properties of = PSK-based 0-RTT and
>=C2=A0 =C2=A0 =C2=A0> DHE-based 0-RTT are almost identical, but 0-RT= T PSK has better
>=C2=A0 =C2=A0 =C2=A0> performance properties and is simpler to speci= fy and implement. Note
>=C2=A0 =C2=A0 =C2=A0> that this does not permanently preclude suppor= ting DHE-based 0-RTT in
>=C2=A0 =C2=A0 =C2=A0> a future extension, but it would not be in the= initial TLS 1.3 RFC.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> If you think that we should keep DHE-based 0-R= TT please indicate so
>=C2=A0 =C2=A0 =C2=A0> now and provide your rationale.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> J&S
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ______________________________________________= _ TLS mailing list
>=C2=A0 =C2=A0 =C2=A0> TL= S@ietf.org <mailto:TLS@ietf.org&= gt;
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.o= rg/mailman/listinfo/tls
>=C2=A0 =C2=A0 =C2=A0>
>
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0TLS mailing list
>=C2=A0 =C2=A0 =C2=A0TLS@ietf.org= <mailto:TLS@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/tls
>
>


--94eb2c0bbf62f762e4052f5abcd2-- From nobody Thu Mar 31 09:27:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287212D679 for ; Thu, 31 Mar 2016 09:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 lBfPRkvUXfqj for ; Thu, 31 Mar 2016 09:27:33 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9B12D667 for ; Thu, 31 Mar 2016 09:27:33 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 72E133F40BE; Thu, 31 Mar 2016 16:27:32 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5CC783F4048; Thu, 31 Mar 2016 16:27:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459441652; bh=8TVc6Yezfr/hliWPwvuGSZeUc4XWBfXmPYmE8gvVKQ4=; l=773; h=From:To:Date:References:In-Reply-To:From; b=taHhPo8NkK1q+AC49HkALmqSFpcuUe79vM2eYsOvUd+klknhE2h20HCa4yxtgrnNC /PqjhTrRTLl9QFETSLzrs9eoFXkokuv2s5esLM2tUjfEAifDby+gQMqGBx5wE8OuNC AapRH7nY3wEdWm4izr5ibX2UDO5iMF+tcw48RE6U= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 594AB1FC92; Thu, 31 Mar 2016 16:27:32 +0000 (GMT) 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.1130.7; Thu, 31 Mar 2016 12:27:31 -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.1130.005; Thu, 31 Mar 2016 12:27:31 -0400 From: "Salz, Rich" To: Hannes Tschofenig , "Kaduk, Ben" , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1Oq2gkcA0SHxUGmL9jZ8Js6tp9z+g8AgAAEsgD//74zIA== Date: Thu, 31 Mar 2016 16:27:31 +0000 Message-ID: <8ee14c8bd7cf40fd865d561e041f2e23@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> In-Reply-To: <56FD4E32.5060409@gmx.net> 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.116.85] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:27:37 -0000 > 802.15.4 then it will be fairly widely used in the IoT sector. I am sure = the > authors of the Thread specifications (and the members of the Thread > consortium) expect their stuff to be widely used (in IoT -- not on the We= b). They can get a code-point but not a Y since there is no IETF consensus/WG a= greement. Is this a problem? How and why? Will a non-approval from IETF really hampe= r the acceptance and deployment since it's already on-track to be widely us= ed? I can't see why that would be true. The only possible practical impact I can see is that someone like OpenSSL m= ight not provide it. But a Y doesn't guarantee we will, either. /r$=20 -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Mar 31 09:46:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8145512D68E for ; Thu, 31 Mar 2016 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 JMX3sc9sLih1 for ; Thu, 31 Mar 2016 09:46:11 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1CB12D67C for ; Thu, 31 Mar 2016 09:46:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id D57112666; Thu, 31 Mar 2016 19:46:09 +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 3dPEczv6hr2w; Thu, 31 Mar 2016 19:46:09 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-143-35.bb.dnainternet.fi [87.100.143.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 50CB9C4; Thu, 31 Mar 2016 19:46:09 +0300 (EEST) Date: Thu, 31 Mar 2016 19:46:08 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160331164608.GA4279@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT and HelloRetryRequest (Re: Narrowing the replay window) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:46:13 -0000 On Thu, Mar 31, 2016 at 12:18:45PM +1100, Martin Thomson wrote: > On 31 March 2016 at 09:59, Eric Rescorla wrote: > >> Option 2 suits best if we consider HelloRetryRequest to be a DoS feature > >> exclusively or at least primarily. But we have other reasons for it and I > >> don't think that DoS mitigation is a big factor for TCP. > > > > > > I believe Option #2 is simplest. > > I didn't mention this because I was composing on a phone at the time, > but we have to decide whether to allow a second attempt at 0-RTT. If > we do, then the effect is a two round trip setback. I think that the > odds of this happening are small, so I'm OK with it, but I wanted to > highlight that. Not taking it could mix poorly with DTLS, as DTLS rejects need to be stateless from server POV. -Ilari From nobody Thu Mar 31 09:52:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568BA12D536 for ; Thu, 31 Mar 2016 09:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 okp1GD-xvTge for ; Thu, 31 Mar 2016 09:52:53 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3303812D19F for ; Thu, 31 Mar 2016 09:52:53 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 58752433499; Thu, 31 Mar 2016 16:52:52 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 427F143340B; Thu, 31 Mar 2016 16:52:52 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459443172; bh=tX50wnYsuVavV5UeGjO+/COxlIZYiWSVIeAwucO4MDU=; l=1523; h=To:References:From:Date:In-Reply-To:From; b=MHZ/hwNsoPt+9fWMSZnurA4FzMrCT6bP0oajmFOhSzRnGp9Yj1b91iIO6tyxvfOki Gm2ORdaxKgcHPa3w9PCEGs7dB4YnL9Yzxi1C7RIXLdPpGkA6TkFPV3pbUB84DUTp0Z QoDD/BMpcg7CHO5Glafoi9dJM1HkW3Hb0lTNtghQ= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 0C5CA1FCA4; Thu, 31 Mar 2016 16:52:51 +0000 (GMT) To: Hannes Tschofenig , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> From: Benjamin Kaduk Message-ID: <56FD55E3.9060605@akamai.com> Date: Thu, 31 Mar 2016 11:52:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD4E32.5060409@gmx.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 16:52:55 -0000 On 03/31/2016 11:20 AM, Hannes Tschofenig wrote: > Hi Ben, > > just think about the mentioned JPAKE extension: what type of deployment > can you expect? It is something that Thread decided to use. Will Thread, > as a mesh networking technology, be successful and widely be deployed? > We don't know yet but if it becomes a technology of choice for use with > IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I am > sure the authors of the Thread specifications (and the members of the > Thread consortium) expect their stuff to be widely used (in IoT -- not > on the Web). Well, for JPAKE in particular, my thoughts focus on my perception that PAKE of any form is not really central to what TLS does. Given that, I personally would not advocate for a 'Y' for it, even knowing that it might see wide use in IoT. > Is this something that is good enough for this group? Web guys will > hardly care about it. A large part of the TLS group is focused on the > Web use only (at least that's my impression). > > From the descriptions provided by Sean I don't know whether this is > something that would be a "Y" blessing or not. This is what I call > "sounds nice but ...". > Well, I would expect the authors to put the 'Y' in their IANA considerations text and see if anyone complained during the last calls. I further expect that some of the web-centric folks on this list would complain and probably get the 'Y' removed, but I am not seeing why this is problematic. -Ben From nobody Thu Mar 31 10:02:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B18E12D667 for ; Thu, 31 Mar 2016 10:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 aqCe1glWSLEG for ; Thu, 31 Mar 2016 10:02:42 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA79312D09C for ; Thu, 31 Mar 2016 10:02:42 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id k1so111452117vkb.0 for ; Thu, 31 Mar 2016 10:02:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vrF5uui7HuWDe7xLvbLnmbUGuMnTKD5pwseHkPrVKEM=; b=TDTVech3OJ8jcdgKZm3RrML2yBZ/kEI0nINBMIejyHLe06dorz8kKclahcosCYRkwF QtnBXcbIh0L3J9UrEkM40FetPjt/rD7KZ36LFzwOTd+CqlE5jvLu7NMtob7ibrYJR+D8 zLC46EuUKuv+rsk4ioe5yulke+bUT53Qw+S67G6NkO8QSdYlJYAf9o4fwSwJZ5kUgN5N h8XKKLwu54ELBNzOLQDI2U/qAWPAt3R2tmN3jLyIdLHF1RcJxg/bYLKwhL90XML0+j+r z5SoOXaKbZJeyGKlqhjXghfzyJYdRZnzBcCWg72ny1ooT5sMpN8hevjySaSLeaRSJ4MG Ih2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vrF5uui7HuWDe7xLvbLnmbUGuMnTKD5pwseHkPrVKEM=; b=LjD4JYI/+tS+WiiUKkrhMnGvF0uaV0qdW1FzeONdaEWW9sppK+dkScjvgJ2JUZN1jP j49RQA+e3BU/ZY0o3xH0Bhr59Z/gb42U9f8EAjoAOFf+OAx0+jEXfyT6cVgTFE7NDyr8 cdY8/b3afD+xF7pCj8bW4uWR4v/riCDTKwroFFTWXvuOflD2QRcUTBqq8ZvqMpvJmlt0 +wbPaRiQNAzj6RRTdteFnxcVzph3CnTZF7qbtAcfTAMEu+anWlx7ttpvTgqPhhUf5muD aca2kOuCkhq/DRoAc64igz7hvKzvyMuAPLONnF0rY95+kph5je3BoCUXBl+8g0q2E7is VZxw== X-Gm-Message-State: AD7BkJLhiQx5iQ1jgh7b0jSxslUdPV4dlO4Qdcf50lLRGLBJ0MJwwFfQW4r+csTuZ/v+WZmeD48raH04b5gJq88O MIME-Version: 1.0 X-Received: by 10.31.134.71 with SMTP id i68mr952628vkd.46.1459443761700; Thu, 31 Mar 2016 10:02:41 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 31 Mar 2016 10:02:41 -0700 (PDT) In-Reply-To: <56FD154D.1030300@gmx.net> References: <56FD154D.1030300@gmx.net> Date: Thu, 31 Mar 2016 10:02:41 -0700 Message-ID: From: Bill Cox To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=001a11458eb4fcb1fe052f5b3a83 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:02:44 -0000 --001a11458eb4fcb1fe052f5b3a83 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > Hi Sean, > > we at ARM would find it somewhat unfortunate to remove the client > authentication feature from the 0-RTT exchange since this is one of the > features that could speed up the exchange quite significantly and would > make a big difference compared to TLS 1.2. > Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake. it is up to the client to ensure that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert. The simplest way to explain how the server should work in this case is to just say you need to emulate a session cache. This is both more secure and faster than the current spec, where client certs are sent during a 0-RTT resume. The root security problem is that the client cannot prove it possesses the private key in a 0-RTT handshake. So, it is going to be a bit more work, but it will be fast and should be secure. Bill --001a11458eb4fcb1fe052f5b3a83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@= gmx.net> wrote:
Hi Sean,
we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

<= div>Client certs can still be used with PSK 0-RTT, but only on the initial = 1-RTT handshake. =C2=A0it is up to the client to ensure that the security o= f the resumption master secret (RMS) is solid enough to warrant doing 0-RTT= session resumption without re-verification of the client cert.=C2=A0 The s= implest way to explain how the server should work in this case is to just s= ay you need to emulate a session cache.

This is bo= th more secure and faster than the current spec, where client certs are sen= t during a 0-RTT resume.=C2=A0 The root security problem is that the client= cannot prove it possesses the private key in a 0-RTT handshake.
=
So, it is going to be a bit more work, but it will be fast a= nd should be secure.

Bill
--001a11458eb4fcb1fe052f5b3a83-- From nobody Thu Mar 31 10:08:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB86D12D550 for ; Thu, 31 Mar 2016 10:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 5yW7rmx-vPUS for ; Thu, 31 Mar 2016 10:08:10 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8882B12D19F for ; Thu, 31 Mar 2016 10:08:09 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 39089433499; Thu, 31 Mar 2016 17:08:09 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 195BB43340B; Thu, 31 Mar 2016 17:08:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459444089; bh=Y2KTe8dVAnb5qF5R6VEN5WjX+Axz+zm8VcvZgqIx0Gc=; l=3573; h=To:References:Cc:From:Date:In-Reply-To:From; b=nD0ZpngQLMcmuX5UH0FsIg2qJc6zAaAeT70xkXHKn367akF5v7xJeUGUJQ/sWsYhx b43GFGVqcuwYCM7zU1QW3O0sGZIEsds+g/iK+MSSl8qPYBcmxL0AWUdL+y//nY+FCq E1ErO4ndCjTMKM4HQn4p772pVUJyOVKWAWgR4sFk= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CF0191FCA4; Thu, 31 Mar 2016 17:08:08 +0000 (GMT) To: Bill Cox References: <56FD154D.1030300@gmx.net> From: Benjamin Kaduk Message-ID: <56FD5978.3040401@akamai.com> Date: Thu, 31 Mar 2016 12:08:08 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------080905050300060908070701" Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:08:11 -0000 This is a multi-part message in MIME format. --------------080905050300060908070701 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/31/2016 12:02 PM, Bill Cox wrote: > On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig > > wrote: > > Hi Sean, > > we at ARM would find it somewhat unfortunate to remove the client > authentication feature from the 0-RTT exchange since this is one > of the > features that could speed up the exchange quite significantly and > would > make a big difference compared to TLS 1.2. > > > Client certs can still be used with PSK 0-RTT, but only on the initial > 1-RTT handshake. it is up to the client to ensure that the security > of the resumption master secret (RMS) is solid enough to warrant doing > 0-RTT session resumption without re-verification of the client cert. That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly. -Ben > The simplest way to explain how the server should work in this case is > to just say you need to emulate a session cache. > --------------080905050300060908070701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 03/31/2016 12:02 PM, Bill Cox wrote:
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake. it is up to the client to ensure that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert.

That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly.

-Ben

The simplest way to explain how the server should work in this case is to just say you need to emulate a session cache.


--------------080905050300060908070701-- From nobody Thu Mar 31 10:08:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B912D699 for ; Thu, 31 Mar 2016 10:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tV7wYoKdZG0f for ; Thu, 31 Mar 2016 10:08:50 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18F4512D690 for ; Thu, 31 Mar 2016 10:08:48 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MbOoG-1aSumT3km4-00Imp7; Thu, 31 Mar 2016 19:08:42 +0200 To: Benjamin Kaduk , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56FD599D.2040206@gmx.net> Date: Thu, 31 Mar 2016 19:08:45 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD55E3.9060605@akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VxIPfexktEw8nIVpgh5an1maIdd9seCX9" X-Provags-ID: V03:K0:yWnWGV4Gqw7ne/1ArQKrrqZSFS9XKRpFgdKgH+NNGhELdDYA2Y/ vHoyHL+2xu2fWHE8rOgeg7ETUyVaCdixY6a4V0l+nd4b42ceWfCn5dzTQUz1C1S7OTZcCOq WSYrR+i3lOtgrNSxFTFJreG75Lphkb6BFg7IGMS3fB7DQ48Q5lusBg54rHIKITVNYylm5ZS AouyYpI4wboTFv53j8grA== X-UI-Out-Filterresults: notjunk:1;V01:K0:bqZ2749/1X4=:uByybO8LlcVcYyU3V4HWCB rrUKEvEPBr0YjnoJacewu9+ftwHrDKKcIcIGGgLMoZksqH7pbyn6L4s7gf0BJcTdoCw5ALm1h 3FUGz/wo33PEDajLCyEzDuDxGhiLSSPxmPiw76yac5K2rj0ElLMexuaqgtRu7qiBRTVazTbbe ohX/AIoTX9HjgvGJ44vB/z0nrChWhwKtRwgXqDUwCioYyTlkpp+7VASRCljL2y9u+4ohiaZI7 ubCSEOLP1sZO7uDllCiMRjeYkrySnLLAG96ILuF+FVfSMbFitetVXz6QPGnmU8plL/O/1I3rt sJl/pGt43ZRhQ8UEcBbT8/DPjKiZnpMrcUycQvwHw03KQIUry0Qpe5toVH/FlD0sDgg4ODGaP 1aCFzMzBiArmySLsI2PMHbFe82Jewdcb3GCGtGcY8cfrxiF7HUdk6I272UjSRfQQS3vkpfqnr K2LPiyfokeZhI885cOpHs2VjoRBaWNL/3zfr/DKshw060VNa9XlcfKePyqRpAq/oE7611Jubg 3QZzK2rWNji5Z86/aOJm/eUTrsWNjcqF6GSNfmvIHQE0nqYGyv2aoVCS95JMul9agXTw+L2jF BzbIUGyIm4TYV+cnMsx1zbU1tD18rGjXjsM+QNSTzSjKh/lu8fhLZjilCDCh+mdbZq8dNPtCU E3vTmVUtTVCmyCR/Bn9DDo7uT5sbSILoZm4loWnZ25gNuZ0Bb6dzO1KABMQjd0D22KHwrQgKQ hl4GBYCaZcRTNTO5xbvbzcOdpnH9/twYAji7fudjSW9lE6Dck6dAH9ibhxU= Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:08:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VxIPfexktEw8nIVpgh5an1maIdd9seCX9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In essence you are saying that most people are not going to care about the Y/N in the IANA table anyway. Somewhat similar to people not understanding the difference between the different types of RFCs. That sounds pragmatic. Ciao Hannes On 03/31/2016 06:52 PM, Benjamin Kaduk wrote: > On 03/31/2016 11:20 AM, Hannes Tschofenig wrote: >> Hi Ben, >> >> just think about the mentioned JPAKE extension: what type of deploymen= t >> can you expect? It is something that Thread decided to use. Will Threa= d, >> as a mesh networking technology, be successful and widely be deployed?= >> We don't know yet but if it becomes a technology of choice for use wit= h >> IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I = am >> sure the authors of the Thread specifications (and the members of the >> Thread consortium) expect their stuff to be widely used (in IoT -- not= >> on the Web). >=20 > Well, for JPAKE in particular, my thoughts focus on my perception that > PAKE of any form is not really central to what TLS does. Given that, I= > personally would not advocate for a 'Y' for it, even knowing that it > might see wide use in IoT. >=20 >> Is this something that is good enough for this group? Web guys will >> hardly care about it. A large part of the TLS group is focused on the >> Web use only (at least that's my impression). >> >> From the descriptions provided by Sean I don't know whether this is >> something that would be a "Y" blessing or not. This is what I call >> "sounds nice but ...". >> >=20 > Well, I would expect the authors to put the 'Y' in their IANA > considerations text and see if anyone complained during the last calls.= =20 > I further expect that some of the web-centric folks on this list would > complain and probably get the 'Y' removed, but I am not seeing why this= > is problematic. >=20 > -Ben >=20 --VxIPfexktEw8nIVpgh5an1maIdd9seCX9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/VmdAAoJEGhJURNOOiAtF6IH+wd9n+KRoAs2AZh0dCrFXQ2D GTbaGbTj1C5Ut/KtFZTqmqosTaMWiDe6CI5pWYJrlmsaqgaXj6913AKhXGei4PeF eI1dWTfPhSxhiqRHLWDlurjhPdfWA9TL6d9v2BANMQuFdrnxdFifZ2ueA3NWyArV 0yVrptcH6nnzd/SlGd/xS/r5WQ61wIiqwoOAVh2TdXx4UljRxhfgm03ycbK4bz/1 wWZ5AvuAfwEPKX2f+/PAdLYecSqrKhvmG5XITtUg71E6Duy0gvYkGqlllDwRZySm zeeNiLjU2De6lFsMwoQ8KSBMOTWwqO61MKBYpqLvirxoCl1LFzJx2Yr1rzFbwgs= =Mzc/ -----END PGP SIGNATURE----- --VxIPfexktEw8nIVpgh5an1maIdd9seCX9-- From nobody Thu Mar 31 10:14:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C4512D09C for ; Thu, 31 Mar 2016 10:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 VQJB785n2d19 for ; Thu, 31 Mar 2016 10:14:39 -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 ABFCE12D550 for ; Thu, 31 Mar 2016 10:14:39 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id g127so105711001ywf.2 for ; Thu, 31 Mar 2016 10:14: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=fTO/9FA2hpOQWekvv3znedl5HR86ZkcyitlS9chwAz0=; b=mqK4Fn0VMSRv5NIhdhmGcB9o4idkgAhZ5ghP1mlCuKGqYNa5Jfoyps0SbjiFl1lUEM YSfQhBYV5i+Wh7lS4TZPVpyG/tP7Iaf6Qe7QJS4mgPcxpPDdOT40y3LNdrkuKBxot5Ho URRzJXE+ezzIIHIwaPMJyjjLWRHFvWHZYvT555/d/8GnFRq1tFdN6AWITgURe3FO+4yy s8iWvmNz6IB0oyPNs5H+ZL6PTTPmKPlp76m/gRJj9iAeuI5gsF294rc9+KQEnC7IG3bq xRjXBjrLC75MjPruG/FnyXfqI2CJgx9QG9Js3hTh2e2qXQ/bDWco1vq6Q7CRKQmsP0bA f56Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fTO/9FA2hpOQWekvv3znedl5HR86ZkcyitlS9chwAz0=; b=e2Bg8Fg1jYDBwmqnQ5sKaPsxfe3onaecFa8y7IWEJ3dKpnolt3CFpJK3WD+/J2d9As kAeycwRctslpQSVIOZaQ25Bg8GuTGT2AwCOuJpTZEbVoWhRuGS48/7sycKE86N1hZiW3 ao2bIIb/45gLEhPLj5DS5zfJU2pVR5V/WC7BuiI5HvQzKZ3v2KdZwUsuSnDBqvIFyB/D EovhTSS8GRyWZUlf4irp7hQagUndVtL0Ln2Ms/cH78HgZqvYIyPWO3nl5i0PhVGhxxoT Tjm0mNSHtsTSkOMf9QAMG2lsGhvJRMWbQM/yHqFdjxKBvZ6zJZ6OmpAHWoSrf5N3Dk8K /oeQ== X-Gm-Message-State: AD7BkJLjTETz6MUx1/N92efPIrxcdYpjnR/D95+77pjatQto1uxG7gVjCpCflt7On4zouVrKNsTEiSL8jk6f2Q== X-Received: by 10.129.152.10 with SMTP id p10mr36470ywg.129.1459444478959; Thu, 31 Mar 2016 10:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 10:13:59 -0700 (PDT) In-Reply-To: <56FD5978.3040401@akamai.com> References: <56FD154D.1030300@gmx.net> <56FD5978.3040401@akamai.com> From: Eric Rescorla Date: Thu, 31 Mar 2016 10:13:59 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c0bbf62bd27f8052f5b650e Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:14:43 -0000 --94eb2c0bbf62bd27f8052f5b650e Content-Type: text/plain; charset=UTF-8 On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk wrote: > On 03/31/2016 12:02 PM, Bill Cox wrote: > > On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi Sean, >> >> we at ARM would find it somewhat unfortunate to remove the client >> authentication feature from the 0-RTT exchange since this is one of the >> features that could speed up the exchange quite significantly and would >> make a big difference compared to TLS 1.2. >> > > Client certs can still be used with PSK 0-RTT, but only on the initial > 1-RTT handshake. it is up to the client to ensure that the security of the > resumption master secret (RMS) is solid enough to warrant doing 0-RTT > session resumption without re-verification of the client cert. > > > That seems to rule out most corporate uses of client certs [for 0-RTT > client authentication], since I doubt anyone will be interested in trusting > that the client does so properly. > Do those servers generally carry over client auth through resumption? -Ekr > > -Ben > > The simplest way to explain how the server should work in this case is to > just say you need to emulate a session cache. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0bbf62bd27f8052f5b650e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <= bkaduk@akamai.com> wrote:
=20 =20 =20
On 03/31/2016 12:02 PM, Bill Cox wrote:
=20
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake. =C2=A0it is up to the client = to ensure that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert.=C2=A0 =

That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly.

Do those servers generally carry over client au= th through resumption?

-Ekr
=C2=A0
=

-Ben

The simplest way to explain how the server should work in this case is to just say you need to emulate a session cache.



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


--94eb2c0bbf62bd27f8052f5b650e-- From nobody Thu Mar 31 10:14:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF44612D09C for ; Thu, 31 Mar 2016 10:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 oBli8flfXMP3 for ; Thu, 31 Mar 2016 10:14:42 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1047D12D52E for ; Thu, 31 Mar 2016 10:14:42 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5E9AD3F406A; Thu, 31 Mar 2016 17:14:41 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 45B7B3F402E; Thu, 31 Mar 2016 17:14:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459444481; bh=4EhfvluIKQMvPPkz/eIa0JQGbK6tCJNS/Hv5IzK4exA=; l=2279; h=To:References:From:Date:In-Reply-To:From; b=e1RZnBsTq8Tmo/VksP8hrdZcDecbknMQjF8Jw9pb7bPBzAdhOWntrXP0rQDQnXhTX //sor74XHySqXWzFzFeyZSDHK9SFqyi+IWdfWTUJqYnYkoWS8jIIEmWIj6RRQWhBRm itiEQXm3D5fwuXBf67Ecks2PL0/H80AT6a8lEri0= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 096701FC94; Thu, 31 Mar 2016 17:14:40 +0000 (GMT) To: Hannes Tschofenig , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> From: Benjamin Kaduk Message-ID: <56FD5B00.3090007@akamai.com> Date: Thu, 31 Mar 2016 12:14:40 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD599D.2040206@gmx.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:14:45 -0000 Well, "most people [in the world" do not care about any documents the IETF puts out. I am not sure what population of people you are actually trying to make a statement about. I am not confident that adding this column will actually have a useful impact, but I think the experiment is worth performing. -Ben On 03/31/2016 12:08 PM, Hannes Tschofenig wrote: > In essence you are saying that most people are not going to care about > the Y/N in the IANA table anyway. Somewhat similar to people not > understanding the difference between the different types of RFCs. > > That sounds pragmatic. > > Ciao > Hannes > > On 03/31/2016 06:52 PM, Benjamin Kaduk wrote: >> On 03/31/2016 11:20 AM, Hannes Tschofenig wrote: >>> Hi Ben, >>> >>> just think about the mentioned JPAKE extension: what type of deployment >>> can you expect? It is something that Thread decided to use. Will Thread, >>> as a mesh networking technology, be successful and widely be deployed? >>> We don't know yet but if it becomes a technology of choice for use with >>> IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I am >>> sure the authors of the Thread specifications (and the members of the >>> Thread consortium) expect their stuff to be widely used (in IoT -- not >>> on the Web). >> Well, for JPAKE in particular, my thoughts focus on my perception that >> PAKE of any form is not really central to what TLS does. Given that, I >> personally would not advocate for a 'Y' for it, even knowing that it >> might see wide use in IoT. >> >>> Is this something that is good enough for this group? Web guys will >>> hardly care about it. A large part of the TLS group is focused on the >>> Web use only (at least that's my impression). >>> >>> From the descriptions provided by Sean I don't know whether this is >>> something that would be a "Y" blessing or not. This is what I call >>> "sounds nice but ...". >>> >> Well, I would expect the authors to put the 'Y' in their IANA >> considerations text and see if anyone complained during the last calls. >> I further expect that some of the web-centric folks on this list would >> complain and probably get the 'Y' removed, but I am not seeing why this >> is problematic. >> >> -Ben >> From nobody Thu Mar 31 10:17:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5B1C12D65D for ; Thu, 31 Mar 2016 10:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 zVrsh93Ib2-C for ; Thu, 31 Mar 2016 10:17:48 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 92C1212D652 for ; Thu, 31 Mar 2016 10:17:48 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3C25B3F407F; Thu, 31 Mar 2016 17:17:48 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 251B73F406A; Thu, 31 Mar 2016 17:17:48 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459444668; bh=ta18u1Dt/lo4w1ZOQkDel+zPrL7L+U7wvs4C9KtcB6U=; l=408; h=From:To:Date:References:In-Reply-To:From; b=AUveH/fq/EuwzBTtZ8VSM6/hWUq84q6xIOLVD+GdmHVvNpsHFrVhFFtQSz1K642J9 qkLGoWisfjgCKE3XokLTkeT6C1JulW5nc+sCc8ZQkDvK9w87ZIT2hoUqsi55FC/bWd U2BmQUz0D5str4MT/wFLskCVw/LkqmmmMxgtvKL8= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 216CA1FC8B; Thu, 31 Mar 2016 17:17:48 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 31 Mar 2016 13:17:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 31 Mar 2016 13:17:47 -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.1130.005; Thu, 31 Mar 2016 13:17:47 -0400 From: "Salz, Rich" To: "Kaduk, Ben" , Hannes Tschofenig , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1Oq2gkcA0SHxUGmL9jZ8Js6tp9z+g8AgAAEsgCAAAkrgIAABHKAgAABpwD//72DwA== Date: Thu, 31 Mar 2016 17:17:46 +0000 Message-ID: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> In-Reply-To: <56FD5B00.3090007@akamai.com> 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.116.85] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:17:50 -0000 > I am not confident that adding this column will actually have a useful im= pact, > but I think the experiment is worth performing. I am very confident it will help. For example, it now becomes a reasonable= position for most TLS stacks to include only Y ciphersuites in their defau= lt source or build or deploy methods. It will also have an effect on reduc= ing clientHello cipher list sizes. From nobody Thu Mar 31 10:18:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0560412D698 for ; Thu, 31 Mar 2016 10:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 jD8DGGEkyW34 for ; Thu, 31 Mar 2016 10:17:56 -0700 (PDT) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 F245B12D6AC for ; Thu, 31 Mar 2016 10:17:54 -0700 (PDT) Received: by mail-vk0-x22c.google.com with SMTP id z68so111868822vkg.3 for ; Thu, 31 Mar 2016 10:17:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=gy3L0z6TRKOyEZRP+Sw/UMfrUf+bwiXzQtPaAT8f4f0=; b=CvNTjw+0Wz7JcoEef5iHrb+1p/AOwS8g2zVII/towolpXL9XMEtm891ppgHXrWdNfJ Kiv+Ck9o7zRsDtJ4cCvAyzNOz6OK91Q1Smi4QfIa7KGEePUZu/Jn+/ld/ClQCo+/DJpl 4CbuMycP38CC0tztHQzjtp1+2cHChmKR29UxG1k5yIi5KpKiMyOTvH7j3wYGFa+E2f/N DAeCVjia6BL44R60WYaFNn/+xLAZCCYsPPnGR6SIzQmy2u7kGVwe7vXo1crqaxcetxMx 4HyaUpCHR59/jhpaA9mzIa2Zx6jhZzQXNsytwbYxx7XoxNxP7Qk69uxRhrlb/9pPNari Ju6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=gy3L0z6TRKOyEZRP+Sw/UMfrUf+bwiXzQtPaAT8f4f0=; b=bOwPo2TgADBo4aYWwyRJe+6UiaGiqXqEDz8QEKEH14uWxm+vfvN5jYzmaoKCJgk+Hx T5eYklORj1yvxP5M5JR3zj3Wmn4tp6ApFofpMcV0bVl5Qgos9wWdDz1/c6fKN1HuxbKf 3Ysp6YqbwWFaV+bZr/6r6s7a1VEsQWjoj0VqvFpLNyU625MvA/oQ1PcUTeJT/m9KDacS qxtq4rrxOj/Drx8U8p1iaT42LeW0G23fwkbn8XIDscdAz3XO8NP12lCeAOtx+e2xvMIU /9vDbmmngLySFuOgc/dCNZaJMpRLGdpq/iZENjVlqWhkeVww1c1PZyyd+W7jIHM2abcT PHLw== X-Gm-Message-State: AD7BkJKmHrgoNFbFVAlkYQr8DhJQ+TBSbtJ4YV8ooqyHZpgMc2cvi/v7pb23Dl6iXKsE9lG4ylc8s6HcPUILz85B MIME-Version: 1.0 X-Received: by 10.31.150.215 with SMTP id y206mr237286vkd.63.1459444673895; Thu, 31 Mar 2016 10:17:53 -0700 (PDT) Received: by 10.31.179.1 with HTTP; Thu, 31 Mar 2016 10:17:53 -0700 (PDT) In-Reply-To: <56FD5978.3040401@akamai.com> References: <56FD154D.1030300@gmx.net> <56FD5978.3040401@akamai.com> Date: Thu, 31 Mar 2016 10:17:53 -0700 Message-ID: From: Bill Cox To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a1140fdd85c07c3052f5b717b Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:18:00 -0000 --001a1140fdd85c07c3052f5b717b Content-Type: text/plain; charset=UTF-8 On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk wrote: > On 03/31/2016 12:02 PM, Bill Cox wrote: > > On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig < > hannes.tschofenig@gmx.net> wrote: > >> Hi Sean, >> >> we at ARM would find it somewhat unfortunate to remove the client >> authentication feature from the 0-RTT exchange since this is one of the >> features that could speed up the exchange quite significantly and would >> make a big difference compared to TLS 1.2. >> > > Client certs can still be used with PSK 0-RTT, but only on the initial > 1-RTT handshake. it is up to the client to ensure that the security of the > resumption master secret (RMS) is solid enough to warrant doing 0-RTT > session resumption without re-verification of the client cert. > > > That seems to rule out most corporate uses of client certs [for 0-RTT > client authentication], since I doubt anyone will be interested in trusting > that the client does so properly. > > -Ben > You would think so, but in TLS 1.2, the client only proves possession of the certificate key on the initial connection, and not again on resumption, so corporations are already trusting the client to maintain the security of their resumption tickets and cache. This seem like a significant security issue that is not well known. Bill --001a1140fdd85c07c3052f5b717b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
On 03/31/2016 12:02 PM, Bill Cox wrote:
=20
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake. =C2=A0it is up to the client = to ensure that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert.=C2=A0 =

That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly.

-Ben

You would think so, but in T= LS 1.2, the client only proves possession of the certificate key on the ini= tial connection, and not again on resumption, so corporations are already t= rusting the client to maintain the security of their resumption tickets and= cache.=C2=A0 This seem like a significant security issue that is not well = known.

Bill=C2=A0
--001a1140fdd85c07c3052f5b717b-- From nobody Thu Mar 31 10:18:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB81512D09C for ; Thu, 31 Mar 2016 10:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 GJwFLgDhB1pF for ; Thu, 31 Mar 2016 10:18:00 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AB25912D6A1 for ; Thu, 31 Mar 2016 10:17:56 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5E0BD4334A2; Thu, 31 Mar 2016 17:17:56 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 47B6B43344D; Thu, 31 Mar 2016 17:17:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459444676; bh=MYbuHLmt6HIdlot4rKA/WvWdSXTUfxdog6xoGs5EnIE=; l=4578; h=To:References:Cc:From:Date:In-Reply-To:From; b=Gq+7hYXuuEoswLUq9kRsCmXIkeag5G0srPpp/rLsgNFsCqYVcTu3m7sFeGFGBreTx Hsvf9SXZNWeJdwba/zk3kV/bfYIzsGG8uHsQYSGMyDHzkgd5V09LL7J6UQMe2a0Q4j yFt0ZENOY07RkihytkovzTE68Uklht+wlMQ2MqwY= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 0F74D1FCA4; Thu, 31 Mar 2016 17:17:56 +0000 (GMT) To: Eric Rescorla References: <56FD154D.1030300@gmx.net> <56FD5978.3040401@akamai.com> From: Benjamin Kaduk Message-ID: <56FD5BC3.5060103@akamai.com> Date: Thu, 31 Mar 2016 12:17:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020704060407070008030002" Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:18:02 -0000 This is a multi-part message in MIME format. --------------020704060407070008030002 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/31/2016 12:13 PM, Eric Rescorla wrote: > > > On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk > wrote: > > On 03/31/2016 12:02 PM, Bill Cox wrote: >> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig >> > wrote: >> >> Hi Sean, >> >> we at ARM would find it somewhat unfortunate to remove the client >> authentication feature from the 0-RTT exchange since this is >> one of the >> features that could speed up the exchange quite significantly >> and would >> make a big difference compared to TLS 1.2. >> >> >> Client certs can still be used with PSK 0-RTT, but only on the >> initial 1-RTT handshake. it is up to the client to ensure that >> the security of the resumption master secret (RMS) is solid >> enough to warrant doing 0-RTT session resumption without >> re-verification of the client cert. > > That seems to rule out most corporate uses of client certs [for > 0-RTT client authentication], since I doubt anyone will be > interested in trusting that the client does so properly. > > > Do those servers generally carry over client auth through resumption? > I don't know, offhand. I just wanted to point out that for one sizeable use case for client certs in general (not considering 0RTT), this proposed scheme does not seem useful. It may still be useful in other use cases, of course. -Ben --------------020704060407070008030002 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 03/31/2016 12:13 PM, Eric Rescorla wrote:


On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 03/31/2016 12:02 PM, Bill Cox wrote:
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake.  it is up to the client to ensure that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert. 

That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly.

Do those servers generally carry over client auth through resumption?


I don't know, offhand.  I just wanted to point out that for one sizeable use case for client certs in general (not considering 0RTT), this proposed scheme does not seem useful.  It may still be useful in other use cases, of course.

-Ben
--------------020704060407070008030002-- From nobody Thu Mar 31 10:18:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBE812D69E for ; Thu, 31 Mar 2016 10:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofLlw9Hpf2nL for ; Thu, 31 Mar 2016 10:18: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 248D812D6A2 for ; Thu, 31 Mar 2016 10:18:38 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id h65so106062694ywe.0 for ; Thu, 31 Mar 2016 10:18:37 -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=RKfNaul6gxNxUq4yUAIyMEa8kQ9N6P80J5JSsornQic=; b=e4mUA2Cai0A1ik13LIAUKn/rhQOUzyrgBbP/qvzUix7zIH+s48ST95elBQrmjqgSms boqMOS2RaQo9fd8+eCed3ZllSPofwTp3C4ZHl7hW/2TE+GscS3YUr4SNoddp90tLcKvP Vr1F0B5E09CmwgVl1kTd59fWWPwR0f11DqEqAUK5ASTCW95XH/s8B/UxVDFzKxTyVahJ MuHhSWCgPaTiJCdHL9BApd5EYacC2r60qQHS0WboJrBq8oOL1W6yJWyrib0iUghZBTjk WfRsy4FWQHPxxGpQs6ZGgfCoxj2gY3bkGgWodJRkBcOU3qbQivSl2qk12SuCq+QSqscw LfBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RKfNaul6gxNxUq4yUAIyMEa8kQ9N6P80J5JSsornQic=; b=gZ6ZOjYgGWslQwBE2q1A8EukmeCQC0r7dcfQh/qdnrMLLdx+BUQvvv3I3ZkwmWU0ZT rknzjysipzXrGq5Q5NwEvAxH+zqpIfQhOLFDxbNy+MCCzBRL+lckGnhfDtyXkgCo4gGv NCiQj3YSH7QVtDX/zcDysN66CKAE+iQm82wpjgdbJOR5HqroNKNIDe/EiWMwDTf2pbD3 kSGhdn+714xXzQVyl1GKFAjFb8AkwEmE1k14CjdiFjNFHpXacq0SD15BKL+kwfakuw6z Oc36ymZS4jajGnSIAghg5YJJmu/Sm26tMe7IswWqf8eAlpcIpzPD2bMlpRPBRclpxg/r 1Lhw== X-Gm-Message-State: AD7BkJLjdLXl8qxW4iF5C5zLXw38nlcbJb+9mte2RURtmsOOG/FOE+r9yYkILJqn/7BqFBzNz/mMD3+eoSQeXQ== X-Received: by 10.129.80.69 with SMTP id e66mr9215972ywb.231.1459444717293; Thu, 31 Mar 2016 10:18:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 10:17:57 -0700 (PDT) In-Reply-To: <56FD5B00.3090007@akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> From: Eric Rescorla Date: Thu, 31 Mar 2016 10:17:57 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a1147f078f1c0dd052f5b73a0 Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:18:42 -0000 --001a1147f078f1c0dd052f5b73a0 Content-Type: text/plain; charset=UTF-8 The primary purpose of this compromise is to unjam the many requests for code points that otherwise clog the WG and expert review process. I believe it will at least do that. -Ekr On Thu, Mar 31, 2016 at 10:14 AM, Benjamin Kaduk wrote: > Well, "most people [in the world" do not care about any documents the > IETF puts out. I am not sure what population of people you are actually > trying to make a statement about. > > I am not confident that adding this column will actually have a useful > impact, but I think the experiment is worth performing. > > -Ben > > On 03/31/2016 12:08 PM, Hannes Tschofenig wrote: > > In essence you are saying that most people are not going to care about > > the Y/N in the IANA table anyway. Somewhat similar to people not > > understanding the difference between the different types of RFCs. > > > > That sounds pragmatic. > > > > Ciao > > Hannes > > > > On 03/31/2016 06:52 PM, Benjamin Kaduk wrote: > >> On 03/31/2016 11:20 AM, Hannes Tschofenig wrote: > >>> Hi Ben, > >>> > >>> just think about the mentioned JPAKE extension: what type of deployment > >>> can you expect? It is something that Thread decided to use. Will > Thread, > >>> as a mesh networking technology, be successful and widely be deployed? > >>> We don't know yet but if it becomes a technology of choice for use with > >>> IEEE 802.15.4 then it will be fairly widely used in the IoT sector. I > am > >>> sure the authors of the Thread specifications (and the members of the > >>> Thread consortium) expect their stuff to be widely used (in IoT -- not > >>> on the Web). > >> Well, for JPAKE in particular, my thoughts focus on my perception that > >> PAKE of any form is not really central to what TLS does. Given that, I > >> personally would not advocate for a 'Y' for it, even knowing that it > >> might see wide use in IoT. > >> > >>> Is this something that is good enough for this group? Web guys will > >>> hardly care about it. A large part of the TLS group is focused on the > >>> Web use only (at least that's my impression). > >>> > >>> From the descriptions provided by Sean I don't know whether this is > >>> something that would be a "Y" blessing or not. This is what I call > >>> "sounds nice but ...". > >>> > >> Well, I would expect the authors to put the 'Y' in their IANA > >> considerations text and see if anyone complained during the last calls. > >> I further expect that some of the web-centric folks on this list would > >> complain and probably get the 'Y' removed, but I am not seeing why this > >> is problematic. > >> > >> -Ben > >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1147f078f1c0dd052f5b73a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The primary purpose of this compromise is to unjam the man= y requests for code
points that otherwise clog the WG and expert review= process. I believe it will at
least do that.

-Ekr


On Thu, Mar 31, 2016 at 10:14 AM, Benjamin Kaduk <bkad= uk@akamai.com> wrote:
Well,= "most people [in the world" do not care about any documents the<= br> IETF puts out.=C2=A0 I am not sure what population of people you are actual= ly
trying to make a statement about.

I am not confident that adding this column will actually have a useful
impact, but I think the experiment is worth performing.

-Ben

On 03/31/2016 12:08 PM, Hannes Tschofenig wrote:
> In essence you are saying that most people are not going to care about=
> the Y/N in the IANA table anyway. Somewhat similar to people not
> understanding the difference between the different types of RFCs.
>
> That sounds pragmatic.
>
> Ciao
> Hannes
>
> On 03/31/2016 06:52 PM, Benjamin Kaduk wrote:
>> On 03/31/2016 11:20 AM, Hannes Tschofenig wrote:
>>> Hi Ben,
>>>
>>> just think about the mentioned JPAKE extension: what type of d= eployment
>>> can you expect? It is something that Thread decided to use. Wi= ll Thread,
>>> as a mesh networking technology, be successful and widely be d= eployed?
>>> We don't know yet but if it becomes a technology of choice= for use with
>>> IEEE 802.15.4 then it will be fairly widely used in the IoT se= ctor. I am
>>> sure the authors of the Thread specifications (and the members= of the
>>> Thread consortium) expect their stuff to be widely used (in Io= T -- not
>>> on the Web).
>> Well, for JPAKE in particular, my thoughts focus on my perception = that
>> PAKE of any form is not really central to what TLS does.=C2=A0 Giv= en that, I
>> personally would not advocate for a 'Y' for it, even knowi= ng that it
>> might see wide use in IoT.
>>
>>> Is this something that is good enough for this group? Web guys= will
>>> hardly care about it. A large part of the TLS group is focused= on the
>>> Web use only (at least that's my impression).
>>>
>>> From the descriptions provided by Sean I don't know whethe= r this is
>>> something that would be a "Y" blessing or not. This = is what I call
>>> "sounds nice but ...".
>>>
>> Well, I would expect the authors to put the 'Y' in their I= ANA
>> considerations text and see if anyone complained during the last c= alls.
>> I further expect that some of the web-centric folks on this list w= ould
>> complain and probably get the 'Y' removed, but I am not se= eing why this
>> is problematic.
>>
>> -Ben
>>

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

--001a1147f078f1c0dd052f5b73a0-- From nobody Thu Mar 31 10:18:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC42812D6BD for ; Thu, 31 Mar 2016 10:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 l_-jgRHgingW for ; Thu, 31 Mar 2016 10:18:44 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98BB212D69E for ; Thu, 31 Mar 2016 10:18:43 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MRjd7-1aIlLb3oyn-00T0KC; Thu, 31 Mar 2016 19:18:39 +0200 To: Eric Rescorla References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> <56FD15F6.30305@gmx.net> <56FD4360.7010100@gmx.net> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FD5BF2.20809@gmx.net> Date: Thu, 31 Mar 2016 19:18:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="RftbGcg9hr4EPKuM3pGXNOHOsQIG6gcVb" X-Provags-ID: V03:K0:LihfC5HxymHc1oh6INTNnl4Igm3wzSRecoZ17VuHQ3Adx36V9hm bT1JQntBpT7XODRzKlOLTyV4kVrCI04ONYgipNk/9Ev2iCKpGO/fl29kX6lYE8patLQXYf3 mTajrNkRtjwlEg25IHcqAnjc+N1tjMOBlcAau38+8gPQYnxQMct0WL5HsYPJY9WVZLiWrrj 20TBWY3/NhVa3srB4TAdA== X-UI-Out-Filterresults: notjunk:1;V01:K0:523ax/lFsr0=:UtdYPdo2E12voxta+1GWQk UW3MAdiqcvIVsR+4Fc0y5O3uwV3ZV1w+U2hIpqhjxk7mWI82nu3gr97zNoZMDwb3XIx2O5BFi MjIt0IxqTTebP19GmGKGl7BFAZgv7qBqV5dKtzOWi9GRtv4qdu4whqC5voVxDrhIL2E/pcF5X ilP3eGdGeiMwYh88boqKuhUUUhbMO90gLovJP7qwJjHqLG3nHldhFQMaB6hPnJAGqwJYpvfPP MaXJMlLDSX2QvrI/YBrOcOMAI0eeA4SttxKIs46Da4kzp1DJif0AEqqe2R0dMjBELmz1CoVha nJWXXKl8iCJr3l0XRASdQ6S7Ixuy5n7lwY4kDi3YhH/icCTqnuGv5I/+TDkiWboRQuz2zxxw5 pc89LqOpMxybU6YHKOHmRzN37K8iX4R33vp+/+dBEFhxiEEMncJR0z4izqjDpOQQqXc3mHRa6 l1fs8a9qi7Tw2YsuZz4a6cPipwYfcJEOUjiX77UzORXubfu7umkkum7ngySkliowJqrADaYAt 9puQoRJG1UOm3Ixda35KGmAPvEIoUyAskzU5PLzhUJiPrKxhkFDOSb1mSuxs+tIdU2UWZy63Q HIIxRjYtYC0GeQbUht/OiO808xJCyyEuy7rRLkQrWFF7Ezj0HeqfahYJd56dFeKZipOGLePcK owyFOzEcgEIoEZvz5GhIl7yUcYDSf2p579MewvjXRtUkFkbQY8U8wiTkc4wI3UovrltdiabYv +v4E5NpVQeVOWU87Wpunc96qf+dSji0kDcQx2LvCKQTK7oMaKnDWcxe439g= Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:18:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RftbGcg9hr4EPKuM3pGXNOHOsQIG6gcVb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ekr, > > The only way to do 0-RTT would be with a PSK (in both PSK and > > PSK-(EC)DHE modes). >=20 > I see. This is, of course, a bit unfortunate. >=20 >=20 > Can you expand on why? The general sense of the discussion was that the= y > offered similar properties. > =20 The PSK-ECDHE mode is less useful for the IoT space because you get the overhead of the public key crypto without actually most of the benefits. If you already go that step then I would recommend to use raw public keys instead. But since you clarified the question about the use of out-of-band provisioned PSKs below it just means that someone using public key-based authentication will have more roundtrips (compared to the PSK case). >=20 >=20 > > However, this would include PSKs established via a previous sessi= on, > > i.e., resumption-PSK. >=20 > Only established in previous sessions or also distributed out-of-ba= nd > (as it would be done with PSKs normally). The way you phrased it so= unds > like you want to exclude the out-of-band case and I wonder why. >=20 >=20 > No, the out-of-band case is fine. Ok. Good. >=20 > -Ekr Ciao Hannes --RftbGcg9hr4EPKuM3pGXNOHOsQIG6gcVb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/VvyAAoJEGhJURNOOiAt/HMH/jMEroNoG1d0TTS86mUXOjLB h0bDc+/5jnZMhYiiOMfra9SldvXP2JHSgAT7U4KC+C1pfc4H6YFIQGRCFcbl8IT3 3Wkm6NY/qvnOU/Cq5Ta4LyV7juo9nbmHg0BrhMxNXfzhYZzfyjvZKD0ZqG/moDFG LeGtsoOEA3JHoMCYtXMbkiKbr1O8WIyaJY4hPUEeWSZiGiRiqkA+PbLbS7RjOEBK 7R+K2ZegfSk1Iywp7bLZ2VUNeP+tn5ezzhDz+cPTBwIjUuuTeC+nkkWa+d38cr/o aN/nBF3Z2Y3e9sIx3rwuqgi9RX0Cepe0h9oYXTjwUSA9NDaR8zHkWnnsJTvhyms= =jhXR -----END PGP SIGNATURE----- --RftbGcg9hr4EPKuM3pGXNOHOsQIG6gcVb-- From nobody Thu Mar 31 10:22:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E62612D6CB for ; Thu, 31 Mar 2016 10:22:08 -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 NLvk3zeK6SUy for ; Thu, 31 Mar 2016 10:22:06 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E1B712D6B0 for ; Thu, 31 Mar 2016 10:22:06 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h65so106181118ywe.0 for ; Thu, 31 Mar 2016 10:22: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=1ch5qBfZo8qczc/LfyQloe4C/LnqljDJW06sEAwAZFc=; b=VRPkEv4m+ZrFjreVqwQNO9SMxncQOGY1INGkmc2DcYCRiPbNtlG530/cIqzGOpd6lm b/uSgaNWrgJHBe6hO20tq3idAZCUev2w9bO10Ih7BL9YAb0nNN2WA2tJ0TUL+VJn3FIU 86RY6PFKYOynYlyvJongs0TdQmcyrsCVAWs2O1aoR3+Rucn9MOY+yGQSaVg+GLGsoEsZ VV2MfYBgOWR/P8fWOx875sBgRjnNjAk+QSn7Eq82waHWVuGOj+Z/8oNeABw940m7KApQ +s78T+ZbxmgJHiYUi5ICFdI+xq568DWUIvjqa9c//osazB6ZfW4Ods0z/2XmB3BnPmA5 sMlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1ch5qBfZo8qczc/LfyQloe4C/LnqljDJW06sEAwAZFc=; b=XpDQde2ZqmP8M2rf2qkIUSuGOfoxlKR+QYz7oG/ErJNtkRmfxHfKMtNe+EHR/n0bRr uxmLB8nDOQaoNgYH7XzMqjZwheR0VSMN/Wg2FzhgvPGaxSJeK0b7UryF1Pzz8f026qJ3 0SMDQX7gcoG6PUbYKgezQe/pPuTTaWyeWEVjIh4FJZuw994TOPZEraWjroveV8WE+AA9 c7N2Fs9/KkFU10mQebI4UPs180P43G7exPiKAXz1YGjqHlZW0Po0IlkIf56td5vbyw4S 8QoFNCWMDwStzyRpJZ27GXHl8TF/kNTBLiVIJmRcTA+bZ0lWZ5mxXETvaO9SsArTEeyq qjJQ== X-Gm-Message-State: AD7BkJIRl1Bbs5yOytvb/DtgDpkxDSINydZRYBJLmtkeMGxTXGya008eAnFX9WeVSn4/tIvGdsT5ySYfjdL9tg== X-Received: by 10.37.231.216 with SMTP id e207mr8631181ybh.130.1459444925249; Thu, 31 Mar 2016 10:22:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 10:21:25 -0700 (PDT) In-Reply-To: <56FD5BC3.5060103@akamai.com> References: <56FD154D.1030300@gmx.net> <56FD5978.3040401@akamai.com> <56FD5BC3.5060103@akamai.com> From: Eric Rescorla Date: Thu, 31 Mar 2016 10:21:25 -0700 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c0b11d0574414052f5b80fd Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:22:09 -0000 --94eb2c0b11d0574414052f5b80fd Content-Type: text/plain; charset=UTF-8 On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk wrote: > On 03/31/2016 12:13 PM, Eric Rescorla wrote: > > > > On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk < > bkaduk@akamai.com> wrote: > >> On 03/31/2016 12:02 PM, Bill Cox wrote: >> >> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig < >> hannes.tschofenig@gmx.net> wrote: >> >>> Hi Sean, >>> >>> we at ARM would find it somewhat unfortunate to remove the client >>> authentication feature from the 0-RTT exchange since this is one of the >>> features that could speed up the exchange quite significantly and would >>> make a big difference compared to TLS 1.2. >>> >> >> Client certs can still be used with PSK 0-RTT, but only on the initial >> 1-RTT handshake. it is up to the client to ensure that the security of the >> resumption master secret (RMS) is solid enough to warrant doing 0-RTT >> session resumption without re-verification of the client cert. >> >> >> That seems to rule out most corporate uses of client certs [for 0-RTT >> client authentication], since I doubt anyone will be interested in trusting >> that the client does so properly. >> > > Do those servers generally carry over client auth through resumption? > > > I don't know, offhand. I just wanted to point out that for one sizeable > use case for client certs in general (not considering 0RTT), this proposed > scheme does not seem useful. It may still be useful in other use cases, of > course. > I'm really not following you here. My point is that for TLS 1.2 there are two categories of servers that do client auth: - Those which carry over client auth through resumption - Those which do not The former should be equally happy (modulo all the concerns about replay, etc.) to carry over client auth through 0-RTT resumption. The latter will presumably not be but can do 1-RTT. The question then becomes how large the two populations are. -Ekr > > -Ben > --94eb2c0b11d0574414052f5b80fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk <= bkaduk@akamai.com> wrote:
=20 =20 =20
On 03/31/2016 12:13 PM, Eric Rescorla wrote:
=20


On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 03/31/2016 12:02 PM, Bill Cox wrote:
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <= hannes.tschofenig@g= mx.net> wrote:
Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake. =C2=A0it is up to the client to ensu= re that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert.=C2=A0

That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly.

Do those servers generally carry over client auth through resumption?


I don't know, offhand.=C2=A0 I just wanted to point out that for on= e sizeable use case for client certs in general (not considering 0RTT), this proposed scheme does not seem useful.=C2=A0 It may still be useful in other use cases, of course.

I'm really not following you here.

My= point is that for TLS 1.2 there are two categories of servers that do clie= nt auth:

- Those which carry over client auth thro= ugh resumption
- Those which do not

The = former should be equally happy (modulo all the concerns about replay, etc.)= to carry over
client auth through 0-RTT resumption. The latter w= ill presumably not be but can do 1-RTT.
The question then becomes= how large the two populations are.

-Ekr
=C2=A0

-Ben

--94eb2c0b11d0574414052f5b80fd-- From nobody Thu Mar 31 10:23:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96B012D6C6 for ; Thu, 31 Mar 2016 10:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VmPQqiKpvTFW for ; Thu, 31 Mar 2016 10:23:15 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4F412D6B0 for ; Thu, 31 Mar 2016 10:23:13 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LdHeL-1a3a7E1Ooj-00iT0U; Thu, 31 Mar 2016 19:23:07 +0200 To: "Salz, Rich" , "Kaduk, Ben" , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <56FD5CFC.8090508@gmx.net> Date: Thu, 31 Mar 2016 19:23:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tKKUjFsALkrDj6ErQFP32n8eBeigX9LLQ" X-Provags-ID: V03:K0:bxEso2fRjsp3VO9n9rh+XdwPCwqW3VC++i7ojQvGhwskhdaKs6i IISOsCWj7SdTG8piCxclugaR4eimn1nrqkCgUHiMHvwyE1GSpLGcre1RYqiH0gpxtB0zh7X l+qaz4ELq8XitZIE0/b7f18Gar7xQRcuiAbMQL4RChBAKbMFCEB8gw9+uKzo2rRAfacV8BZ WEqwEeAb5fi+hVRPOwOhA== X-UI-Out-Filterresults: notjunk:1;V01:K0:K0K4Y4niJ/A=:Cesrdz6FcxDNofjfYvgPi4 rLuktQF8+8R001dxj/y3IEeIZF6NcxZo3mWpWesqKJs1YfPEYZm+F7Qhr63mnpek8WfWy9Zn6 9jbaSYJV6FLhod4dOq4IL+FNrSc4CWBXKyYGQ0CcAWljnt9dxAN6sZWoL4wyhLWXW8DeFP+Sr CfY8brUuzqQoICOmhnOAd9FB8pswZjs9q3xjFizQVk7sy3Xh7YYS18E7i+xJ4ubf1I2yCWfIe SsgYYDn7eWRoni6M1huh07nNrrTtBBQfFOOpp/BYf/61+2h5AfTTdGHFCCZNJxUryM9JMzvSQ wOEwg9MYPB9OX+kfnD5k4LeS28X4LMmPu3fHTQQF/x8n/VmqSpKOmJEI/wcy/upHvcQ4PyFJk QKBzEWXkoMPgYWftjjQNCIAqyJIX9Y937sAqL7fMGRV9PLgt7uOzY/T8XaaHCyQeUJNf/OnV7 OMpQ1Ovw3/H4jgIJqPgbObDJGp3lVs/pm8qKg1opDXnU5A0M7bNNbHwuHTQUVi5HaL12txEPY cPmI0WEj6E2h3QEEd/01585HL1VGEp+Nwhe9eDT1J5xi+z9HdKYNWeHO0GU21Ja4B/qwh9nZT QeGO2oX8yOyjgo+jQGyeDSTWMtg7C9IVIHkjJP5Fxv7E8ROLFBJJXAqERpaxxTVDB9zkX74vV iNcrPpU4Kv0rOJ2QEhYyUy2rXNqE0m7ASNuSbldsSGd8/CPhl7SpcSf4hRCjdM5aBfXNG+O+X FYfSYYd2rc/LzOpd2xZjATd1kPYeGDn6SOJpiyM+iWxoyBvbCzS9yLSvn2E= Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:23:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tKKUjFsALkrDj6ErQFP32n8eBeigX9LLQ Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rich, On 03/31/2016 07:17 PM, Salz, Rich wrote: > I am very confident it will help. For example, it now becomes a > reasonable position for most TLS stacks to include only Y > ciphersuites in their default source or build or deploy methods. It > will also have an effect on reducing clientHello cipher list sizes. Interesting idea. You see this IANA registry more as the mandatory to implement algorithm list (for Web apps). Ciao Hannes --tKKUjFsALkrDj6ErQFP32n8eBeigX9LLQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/Vz8AAoJEGhJURNOOiAt3s0IAJt2LaSKLVu5Ku/zzw9Bmerw 802W0+cdhkXLB+bPaAgAd+ScGrm9BPA7iiVJa7umcVg8YUZu/WK9SrURB3dZNNuF DAOKLZ7P1oyysRqCu0exQLP92b1TjpJxchhZejGD0zTBwmGLE5kPACw1ajYIJaUY KPAoCKP+Q1E5kAJfSF3mmSByiDrICSUQ+aeTWzOYYp9epjbtqb1ML1tvqdbyE/IM WjJO42AIfHxBukRpXGJ8WhIjwh8uGC7eFP8cDN2gopQVRLI6/YztQoEae3rxquA7 7cA1LO8WysOETpsqwsnEPqttJ92fsd2Ac/O7cALbU/zD+O1bpLV7ME4wkT+Hhi0= =f2HI -----END PGP SIGNATURE----- --tKKUjFsALkrDj6ErQFP32n8eBeigX9LLQ-- From nobody Thu Mar 31 10:25:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69A612D6CB for ; Thu, 31 Mar 2016 10:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.731 X-Spam-Level: X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 WEO7HW76A6ov for ; Thu, 31 Mar 2016 10:25:46 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 68CB612D6CA for ; Thu, 31 Mar 2016 10:25:46 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A49E616C8EE; Thu, 31 Mar 2016 17:25:45 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 8F11416BFE2; Thu, 31 Mar 2016 17:25:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459445145; bh=rmZBjcUNWWNZMN2K7PKPITfFlSo44G5VhZEMX1nXJ6g=; l=398; h=From:To:Date:References:In-Reply-To:From; b=GkeWdBi38VMnNns6gRQcfZLZldxjH47WFuD72U7P9aTIX0aeT1yazJxjeO2zEaCpy RTxzeEFiC9sMo/oSwJ4wYn91SSewKj/oeB//NTS7azzNlNdR0ub3Y+iMnD8HDU9jww iJZkQeA15ul1fd3hSY6wGl4psD2PfZLPjo+xPRdo= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 7686798082; Thu, 31 Mar 2016 17:25:45 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 31 Mar 2016 10:25:45 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Thu, 31 Mar 2016 13:25:44 -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.1130.005; Thu, 31 Mar 2016 13:25:44 -0400 From: "Salz, Rich" To: Hannes Tschofenig , "Kaduk, Ben" , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1Oq2gkcA0SHxUGmL9jZ8Js6tp9z+g8AgAAEsgCAAAkrgIAABHKAgAABpwD//72DwIAARNoA//+9DnA= Date: Thu, 31 Mar 2016 17:25:44 +0000 Message-ID: <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> In-Reply-To: <56FD5CFC.8090508@gmx.net> 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.116.85] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:25:49 -0000 > Interesting idea. You see this IANA registry more as the mandatory to > implement algorithm list (for Web apps). I don't. But lots of outsiders do, and I know they exert pressure on vario= us projects and TLS/AD "leadership". I've only had a little bit of it via = openssl compared to those folks. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Mar 31 10:40:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B89B12D6F9 for ; Thu, 31 Mar 2016 10:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ZFSQZPgY9fWK for ; Thu, 31 Mar 2016 10:40:34 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A972112D6F4 for ; Thu, 31 Mar 2016 10:40:33 -0700 (PDT) Received: from [192.168.10.140] ([200.89.69.175]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Le69A-1Zw7gl1kT6-00psXf; Thu, 31 Mar 2016 19:40:28 +0200 To: "Salz, Rich" , "Kaduk, Ben" , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 X-Enigmail-Draft-Status: N1110 Message-ID: <56FD610F.10301@gmx.net> Date: Thu, 31 Mar 2016 19:40:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="OXH4NSG6kl7UuJSXnP8MuCxhlIlugRcqB" X-Provags-ID: V03:K0:OlKJfiiEd0kVzKcHGcgorXPYAPscv9+NcPMZR/xh6EK2UVmlqAk NqdeMmm7gj4iAAV8r6jJrvOswuS9DP0tU1dSgcSqGK2aTmkM4qPDiKO3ROy00hV7a8rd9eL P7uADSJ4avbHTsN2Sfb1dbJcIP4wWfZDOj6pkfbW87HaN0m7ftoNa0i2fZWEiCj16BGXy6h sAKq33/1rnryz90rNPGrQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:1yJhEZeWWMU=:XxkEaHLyMI6Sp2TMq1v6QD xN2RBn1jvTk49IdtMxvX38ZQDL8KOZjkJxITWn9zF3mfE0wpL7NKrfbbz551u/qT0ES+05+UH DNhDphDZOgkB5Js7esBqvhJXQ4+tRBcpErLo3AMbrFYKUfOuMLyGPUox3xSROB29SK4En+KVt fgNiFtUTssRcFLplhPPewL/4MftrcdkkFcEwIqUo6HSraCTWGaeRgdLqtpXeGXn2qY1s2RVEt mDDQczVNTu1W0TweFqcmZChleQg+2VHhOdsTufGQROZTiZUe7gV/NDrsO7xaQxwqsdCaXm6Uy mRhWUMvbbmY3mPBiNFTEBO+oJ79CV6KA9OB+oM1+hwQ7wy499DzNXDr0TaTewco891c4on9ge h/krLwabYywpVskYkRn9nosZ2p62lKQynX1BVQPL5ioZyWIKWBLzqG+dz6q6Btoo6+NWLEpBR 9qKNNAv/DjBTWZ0DeQi++8SEgcxyVoh9UghqHEnin3icypGHRC0Xh4XD3HaSJp855OjqHaqwx fDr5wWFViIWheVbqs4TpjwSn6erlfIOdHrTOPDbhQUDOfMebEVERIbLFGuKbkkq9uYFnFUFNz c138DmcUHx3oWgBTRjTyhmDM6FysSUAXBnEVaTJX4uRRMxCpXiCzOvaQNEv9Ux45cc726yQFl 7eo/34wo6vi45xQuHBCrsZp20PXEillDE4Rrdf0Pqu8ZC6dadj6/zBEFfE84m1zRcN6B1LNWK 1ER+A4zu9RFafoULLPqF9ZWSa1oxugLt5BaaHXZkKxaH+8uaTd4Wp0wwEBg= Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:40:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --OXH4NSG6kl7UuJSXnP8MuCxhlIlugRcqB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I can see some value in having this IANA registry list for ciphersuites in the way being proposed (even if it may be interpreted differently by different audiences). There have been, of course, too many algorithms used only in specific countries and those substantially increased the ciphersuite list. I am just a little bit worried that everything developed for the IoT enviroment is quite likely labled as not recommended by the IETF in this registry because of the Web focus in this group. The JPAKE is the item that we are currently interested in because we have contributed to the standardization work related to Thread and the stack we had implemented. Of course, the remark that JPAKE might not be a good fit for TLS 1.3 may be correct. Ciao Hannes On 03/31/2016 07:25 PM, Salz, Rich wrote: >> Interesting idea. You see this IANA registry more as the mandatory to >> implement algorithm list (for Web apps). >=20 > I don't. But lots of outsiders do, and I know they exert pressure on v= arious projects and TLS/AD "leadership". I've only had a little bit of i= t via openssl compared to those folks. >=20 > -- =20 > Senior Architect, Akamai Technologies > IM: richsalz@jabber.at Twitter: RichSalz >=20 >=20 --OXH4NSG6kl7UuJSXnP8MuCxhlIlugRcqB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJW/WEPAAoJEGhJURNOOiAtjMYH/0poDuw9Gdi7Nnpp2sQlAzoi 9CtMgB87lgpCoLsD5oie4DE9qxYPxWPDxKhGQwPDYnYLeyCPvRQnz3tFNzupl8pp daSiMgNTdbma0amADPIpwF7kBfzpZDgeAmEEA+zm2uwrmgYJT32duftOiA4wcgVE /EzoDnFTpfCeuvf70twHyLlEUTl2fXadYAWguwBue3fE0v6cMLinijtwqjZW1VPj bKrUHlq9H1rLaI6sXGmFrEAJP3qizB0CyacYLw5BbA8hGwGrU8dWTeuFnksTQ2Nm HFVzd8eQBPhW43JvJ+1DZLUmh1pkSaLk1+7CcDl2NmslJsex7tzq8lOj4ygkjfY= =1Ek0 -----END PGP SIGNATURE----- --OXH4NSG6kl7UuJSXnP8MuCxhlIlugRcqB-- From nobody Thu Mar 31 10:43:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7B112D6A7 for ; Thu, 31 Mar 2016 10:43:35 -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 a_Oo2uNKfdEc for ; Thu, 31 Mar 2016 10:43:34 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 347D512D690 for ; Thu, 31 Mar 2016 10:43:33 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id h129so106973823ywb.1 for ; Thu, 31 Mar 2016 10:43:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=34MMFO2bmyKUFvH6W3TkM7rDaTwOKT4zewmWEzuWtC4=; b=iAHOFlAiJWkm2tmRT3RsvdJkuxcqdQq90m9wln7QkERJwFSFElub5vI/IVnOPfswva /zeW2IuWN06QgCKxtgF2VQppvnqkPZRETtFBjFX/QTOHRqY9MPtyVH+OmrZrGUkFZPad jffwTOURGoVFuON72qy1Y1FthzVhfL6uq3UBrYFQrkDZTCNzlUtNzumKPB74uwX1/U0t UjSg5Za3zEVz5mdJekEQUBsuFCRPEFmduanDKY80Rd8qf92l5ruph+hyWwk+6YJwnefN hjnU2fAbrlFksEneW6haQE2CsnYL/sohfQAPKAbSPTf23t3RCXXLwUUUKsuP+XH1hVTu 3e9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=34MMFO2bmyKUFvH6W3TkM7rDaTwOKT4zewmWEzuWtC4=; b=kUPEP1FeO+HIDR3+9a0esbc/Yo/gpFNA6O8BwRyqwQ4uxkfY6O4NBCicyZ37B5ALym 1Qw+vXJLU0s7oUL1xSBZproR95JuUX4vVAsBRJ8dmtMGkO53RNQXv++SPUyBzHpkJBj6 /deiQ9hiN0zXaNiCv5Z06bJuAZOv26iDHjIf06pEppsL5SW00DHrmQ0LOWBON3zWxd75 hDIdYVNpxmcx6Q0bM8pGEBX8VuVnGi1/fS/PidIlqnSJys982TB7rABGNQeiDvD4Zg+F t252XfdXRikpRihmfWmvbwkPAqEsp4wm8/5xBrKBnjfO6t46OHiio/Z5gwdj3+UXa9vE Ttww== X-Gm-Message-State: AD7BkJLMdvWIdb1iNMh3c8HNOP5vyoSoJ7kKMi21Xxrk4UFkTxkTtFArojQUqTSCvnMjAvP+AVDA9RE8EAdy5Q== X-Received: by 10.129.152.10 with SMTP id p10mr115630ywg.129.1459446212410; Thu, 31 Mar 2016 10:43:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 10:42:52 -0700 (PDT) In-Reply-To: <56FD610F.10301@gmx.net> References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> From: Eric Rescorla Date: Thu, 31 Mar 2016 10:42:52 -0700 Message-ID: To: Hannes Tschofenig Content-Type: multipart/alternative; boundary=94eb2c0bbf620fa056052f5bcd86 Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:43:36 -0000 --94eb2c0bbf620fa056052f5bcd86 Content-Type: text/plain; charset=UTF-8 Hannes, Aside from JPAKE, which algorithms are you concerned about? -Ekr On Thu, Mar 31, 2016 at 10:40 AM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > I can see some value in having this IANA registry list for ciphersuites > in the way being proposed (even if it may be interpreted differently by > different audiences). There have been, of course, too many algorithms > used only in specific countries and those substantially increased the > ciphersuite list. > > I am just a little bit worried that everything developed for the IoT > enviroment is quite likely labled as not recommended by the IETF in this > registry because of the Web focus in this group. > > The JPAKE is the item that we are currently interested in because we > have contributed to the standardization work related to Thread and the > stack we had implemented. Of course, the remark that JPAKE might not be > a good fit for TLS 1.3 may be correct. > > Ciao > Hannes > > On 03/31/2016 07:25 PM, Salz, Rich wrote: > >> Interesting idea. You see this IANA registry more as the mandatory to > >> implement algorithm list (for Web apps). > > > > I don't. But lots of outsiders do, and I know they exert pressure on > various projects and TLS/AD "leadership". I've only had a little bit of it > via openssl compared to those folks. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0bbf620fa056052f5bcd86 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hannes,

Aside from JPAKE, which algorit= hms are you concerned about?

-Ekr


On Thu,= Mar 31, 2016 at 10:40 AM, Hannes Tschofenig <hannes.tschofenig@g= mx.net> wrote:
I can see so= me value in having this IANA registry list for ciphersuites
in the way being proposed (even if it may be interpreted differently by
different audiences). There have been, of course, too many algorithms
used only in specific countries and those substantially increased the
ciphersuite list.

I am just a little bit worried that everything developed for the IoT
enviroment is quite likely labled as not recommended by the IETF in this registry because of the Web focus in this group.

The JPAKE is the item that we are currently interested in because we
have contributed to the standardization work related to Thread and the
stack we had implemented. Of course, the remark that JPAKE might not be
a good fit for TLS 1.3 may be correct.

Ciao
Hannes

On 03/31/2016 07:25 PM, Salz, Rich wrote:
>> Interesting idea. You see this IANA registry more as the mandatory= to
>> implement algorithm list (for Web apps).
>
> I don't.=C2=A0 But lots of outsiders do, and I know they exert pre= ssure on various projects and TLS/AD "leadership".=C2=A0 I've= only had a little bit of it via openssl compared to those folks.
>
> --
> Senior Architect, Akamai Technologies
> IM: richsalz@jabber.at Twitt= er: RichSalz
>
>


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


--94eb2c0bbf620fa056052f5bcd86-- From nobody Thu Mar 31 10:51:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45B612D5D2 for ; Thu, 31 Mar 2016 10:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, T_RP_MATCHES_RCVD=-0.01] 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 AQG4iVX8tPIP for ; Thu, 31 Mar 2016 10:51:50 -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 DFA5E12D142 for ; Thu, 31 Mar 2016 10:51:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0B545BE3F; Thu, 31 Mar 2016 18:51:47 +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 8dkS1H1mlNna; Thu, 31 Mar 2016 18:51:45 +0100 (IST) Received: from [10.87.49.100] (unknown [86.46.30.32]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EC6D3BE2D; Thu, 31 Mar 2016 18:51:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1459446705; bh=W3wh3HzL5uM7k/QXzdOy8+OLparFzOyMCPbZo6mltB0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=RFae/DeT3nhkKU/OgR3EF5HIwbgW7Q8kf9lEgled2xIQs8i8D2DmyQw1xZn1fNVVl +lZ+GLzZlLiHAjMZt0az3z0uhMJavu+NMT6vIkjXYnjiHjJ+YbQX+btihJ4qhC8gOc 91Fknixfl9Ahq4X8a1AoCAu0UuuKFX7s4gaolUSU= To: Hannes Tschofenig , "Salz, Rich" , "Kaduk, Ben" , "" References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56FD63B0.2070205@cs.tcd.ie> Date: Thu, 31 Mar 2016 18:51:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56FD610F.10301@gmx.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QdkEhdxaqrHMIh5m0Pumf1CsEISX3p4r9" Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 17:51:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QdkEhdxaqrHMIh5m0Pumf1CsEISX3p4r9 Content-Type: multipart/mixed; boundary="81muXsuvfqACOIdihmvs2wgVO1Q5Iitrl" From: Stephen Farrell To: Hannes Tschofenig , "Salz, Rich" , "Kaduk, Ben" , "" Message-ID: <56FD63B0.2070205@cs.tcd.ie> Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> In-Reply-To: <56FD610F.10301@gmx.net> --81muXsuvfqACOIdihmvs2wgVO1Q5Iitrl Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If smaller devices don't use algorithms that can be used to talk to random servers on the Internet, then they are choosing to not try to get interop. That seems like a shame to me, unless there's a really good reason and IMO, mostly there isn't, at the ciphersuite level. I would hope we all won't make the GCM/CCM mistake again for example (that "we" being roughly some combination of IETF/IEEE folks). So I think the proposed change here, if it leads to fewer but more ubiquitously deployed ciphersuites, will help smaller devices. And I do think the IETF recommended column might lead us some way in that direction. Cheers, S. On 31/03/16 18:40, Hannes Tschofenig wrote: > I can see some value in having this IANA registry list for ciphersuites= > in the way being proposed (even if it may be interpreted differently by= > different audiences). There have been, of course, too many algorithms > used only in specific countries and those substantially increased the > ciphersuite list. >=20 > I am just a little bit worried that everything developed for the IoT > enviroment is quite likely labled as not recommended by the IETF in thi= s > registry because of the Web focus in this group. >=20 > The JPAKE is the item that we are currently interested in because we > have contributed to the standardization work related to Thread and the > stack we had implemented. Of course, the remark that JPAKE might not be= > a good fit for TLS 1.3 may be correct. >=20 > Ciao > Hannes >=20 > On 03/31/2016 07:25 PM, Salz, Rich wrote: >>> Interesting idea. You see this IANA registry more as the mandatory to= >>> implement algorithm list (for Web apps). >> >> I don't. But lots of outsiders do, and I know they exert pressure on = various projects and TLS/AD "leadership". I've only had a little bit of = it via openssl compared to those folks. >> >> -- =20 >> Senior Architect, Akamai Technologies >> IM: richsalz@jabber.at Twitter: RichSalz >> >> >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --81muXsuvfqACOIdihmvs2wgVO1Q5Iitrl-- --QdkEhdxaqrHMIh5m0Pumf1CsEISX3p4r9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJW/WOwAAoJEC88hzaAX42iMggH/Aog91duL4A313SgnWos8QJn UDSyQRHs2b3lo+3afBYiF8InR0mmr1Q5Sa/QtglFPugZCk+owmz2dhm1ttkB5spU QDmmCG8y5za9ihzp3yggvRSF3CoULt70FV0KHw8y7hXt0jMyp4+ukX2IG22ian2w djX+cKoj9K4T87aDYQuSdRwKG6tO7dR58B1+4iKThiPdMGdDaKkltr4Jo4d2eC+i nCDU2TMCQ0JNHPrDU37imEk5mOCFYMVDy6kai/d+dfTDeQLcvm89V3qV8OBNAqIY xCdrzhAoVxenHa39Zf0SFOJ4U8XHYpLZ0M+JHwLzDn3tehv5WNAuaqLXEPR+Z38= =6Mu1 -----END PGP SIGNATURE----- --QdkEhdxaqrHMIh5m0Pumf1CsEISX3p4r9-- From nobody Thu Mar 31 11:17:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4778712D71D for ; Thu, 31 Mar 2016 11:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] 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 66XHrWkjRYUc for ; Thu, 31 Mar 2016 11:17:01 -0700 (PDT) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B8412D722 for ; Thu, 31 Mar 2016 11:17:00 -0700 (PDT) Received: from airhead.local ([83.161.146.46]) by smtp-cloud3.xs4all.net with ESMTP id ciGv1s00r10HQrX01iGwCw; Thu, 31 Mar 2016 20:16:57 +0200 Message-ID: <56FD6996.1010207@openfortress.nl> Date: Thu, 31 Mar 2016 20:16:54 +0200 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Hannes Tschofenig References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> In-Reply-To: <56FD610F.10301@gmx.net> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:17:08 -0000 Hi, > I am just a little bit worried that everything developed for the IoT > enviroment is quite likely labled as not recommended by the IETF in this > registry because of the Web focus in this group. > RFC 5246 speaks of "Application Profiles" and it seems like this discussion that started to simplify the WG load is now getting mixed with that idea: In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the definition). The worry about IoT above makes me suspect there might be a use for an IoT application profile, presumably geared towards simplicity and compactness. Such a profile could make its own choices, possibly as a subset from the Y markers and possibly enhanced with industry-driven desires. -Rick From nobody Thu Mar 31 11:28:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC13612D723 for ; Thu, 31 Mar 2016 11:28:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 FprEUGXoVPgQ for ; Thu, 31 Mar 2016 11:28:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0102.outbound.protection.outlook.com [65.55.169.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6316D12D732 for ; Thu, 31 Mar 2016 11:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mEDHvb8oFFkAFXQvNitpDvPZm6ScLanwyftM8QI1reE=; b=Y0/IJCsXXXbGcph401LgTKNlKypJ0vPJxm3Ih9+xEkAPNJKr4NLpc6yhq9MrZsTvcNEzBb+xD7Zhc1uDxevV3CTjv5AQTvWHE756f07f1oiujnpUo4l6yzAazeEzSymRthiLWRSM2pM7bafET798S0GydgmAKe8A3kVIvVSOHjA= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.447.15; Thu, 31 Mar 2016 18:28:21 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0447.024; Thu, 31 Mar 2016 18:28:21 +0000 From: Andrei Popov To: Stephen Farrell , Hannes Tschofenig , "Salz, Rich" , "Kaduk, Ben" , "" Thread-Topic: [TLS] call for consensus: changes to IANA registry rules for cipher suites Thread-Index: AQHRi1OtnDhSFiyjlECabVgyoehPf59ztwEAgAAEsgCAAAkrgIAABHGAgAABqACAAADdAIAAAYAAgAAAugCAAAQigIAAAyIAgAAIlhA= Date: Thu, 31 Mar 2016 18:28:21 +0000 Message-ID: References: <20DDE657-E1A9-4705-936D-40673294C4EB@sn3rd.com> <56FD2A0A.1050607@gmx.net> <56FD4A42.2080100@akamai.com> <56FD4E32.5060409@gmx.net> <56FD55E3.9060605@akamai.com> <56FD599D.2040206@gmx.net> <56FD5B00.3090007@akamai.com> <56FD5CFC.8090508@gmx.net> <9ed6f4205baf4602857b3c4539fc1941@usma1ex-dag1mb1.msg.corp.akamai.com> <56FD610F.10301@gmx.net> <56FD63B0.2070205@cs.tcd.ie> In-Reply-To: <56FD63B0.2070205@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 0ca86a60-7764-4e0c-fba0-08d359923d1e x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:aZ86X48wtQfDjR1U6Cx8A9lxr/I6PyjIdp+UB2R5tOY6GLOAkwk3BMR96DH/GB6UhtOsMuMEuikDKXpp2V/2YPcdKvK/1QJmLV2I9FfE9NBgyI1cqvRBWuKiqflyJNgoIwfqobR6n6rmtiq4n+H+nA==; 24:/r6Tbr/ksrBsDG/M5qo8r5LcZDHyODTRAn+s30xiWsgxO3ynDooFdLcab2Mcq2XVO6k2V+v3/9HZPGHkbaRR6x3i6qQMbb0iCTPD8Iui8Ps= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 0898A6E028 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(24454002)(377454003)(561944003)(19580395003)(189998001)(107886002)(2950100001)(86362001)(5001770100001)(19580405001)(93886004)(2900100001)(33656002)(5004730100002)(575784001)(87936001)(76176999)(54356999)(76576001)(86612001)(10090500001)(50986999)(15975445007)(81166005)(106116001)(10290500002)(10400500002)(8990500004)(5005710100001)(77096005)(99286002)(5008740100001)(2906002)(3660700001)(3280700002)(74316001)(5003600100002)(1096002)(92566002)(586003)(6116002)(122556002)(102836003)(1220700001)(5002640100001)(11100500001)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2016 18:28:21.3191 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Subject: Re: [TLS] call for consensus: changes to IANA registry rules for cipher suites X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:28:28 -0000 SSdtIGluIGZhdm9yIG9mIHRoaXMgY2hhbmdlLCBhcyBsb25nIGFzIGl0J3MgYSBiaW5hcnkgWS9O LiBJIGJlbGlldmUgdGhhdCAiWSIgY2FuIG9ubHkgcG9zc2libHkgbWVhbiB0aGF0IHRoZXJlIGlz IHJvdWdoIElFVEYgY29uc2Vuc3VzIHRvIGFkb3B0LiAiWSIgY2Fubm90IG1lYW4gdGhhdCB0aGlz IGNpcGhlciBpcyAiY3J5cHRvZ3JhcGhpY2FsbHkgc291bmQiIG9yICJzZWN1cmUiLCBub3IgY2Fu IGl0IG1lYW4gdGhhdCB0aGUgIlkiIGNpcGhlciBzdWl0ZXMgYXJlIE1USS4NCg0KVGhlIHJlYXNv biBJJ20gaW4gZmF2b3IgaXMgYmVjYXVzZSB3ZSBjYW4nIGJsb2NrIHRoZSB3b3JsZCBmcm9tIGlt cGxlbWVudGluZyB0aGUgY2lwaGVyIHN1aXRlcyB0aGV5IHdhbnQsIGV2ZW4gaWYgd2UgZG9uJ3Qg bGlrZSB3aGF0IHRoZXkgd2FudCBvciBkb24ndCBoYXZlIHRoZSBiYW5kd2lkdGgvbW90aXZhdGlv biB0byBhbmFseXplIGV2ZXJ5IHByb3Bvc2FsLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6IFRodXJzZGF5LCBNYXJj aCAzMSwgMjAxNiAxMDo1MiBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxoYW5uZXMudHNjaG9m ZW5pZ0BnbXgubmV0PjsgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT47IEthZHVrLCBCZW4g PGJrYWR1a0Bha2FtYWkuY29tPjsgPHRsc0BpZXRmLm9yZz4gPHRsc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbVExTXSBjYWxsIGZvciBjb25zZW5zdXM6IGNoYW5nZXMgdG8gSUFOQSByZWdpc3Ry eSBydWxlcyBmb3IgY2lwaGVyIHN1aXRlcw0KDQoNCklmIHNtYWxsZXIgZGV2aWNlcyBkb24ndCB1 c2UgYWxnb3JpdGhtcyB0aGF0IGNhbiBiZSB1c2VkIHRvIHRhbGsgdG8gcmFuZG9tIHNlcnZlcnMg b24gdGhlIEludGVybmV0LCB0aGVuIHRoZXkgYXJlIGNob29zaW5nIHRvIG5vdCB0cnkgdG8gZ2V0 IGludGVyb3AuIFRoYXQgc2VlbXMgbGlrZSBhIHNoYW1lIHRvIG1lLCB1bmxlc3MgdGhlcmUncyBh IHJlYWxseSBnb29kIHJlYXNvbiBhbmQgSU1PLCBtb3N0bHkgdGhlcmUgaXNuJ3QsIGF0IHRoZSBj aXBoZXJzdWl0ZSBsZXZlbC4gSSB3b3VsZCBob3BlIHdlIGFsbCB3b24ndCBtYWtlIHRoZSBHQ00v Q0NNIG1pc3Rha2UgYWdhaW4gZm9yIGV4YW1wbGUgKHRoYXQgIndlIiBiZWluZyByb3VnaGx5IHNv bWUgY29tYmluYXRpb24gb2YgSUVURi9JRUVFIGZvbGtzKS4NCg0KU28gSSB0aGluayB0aGUgcHJv cG9zZWQgY2hhbmdlIGhlcmUsIGlmIGl0IGxlYWRzIHRvIGZld2VyIGJ1dCBtb3JlIHViaXF1aXRv dXNseSBkZXBsb3llZCBjaXBoZXJzdWl0ZXMsIHdpbGwgaGVscCBzbWFsbGVyIGRldmljZXMuIEFu ZCBJIGRvIHRoaW5rIHRoZSBJRVRGIHJlY29tbWVuZGVkIGNvbHVtbiBtaWdodCBsZWFkIHVzIHNv bWUgd2F5IGluIHRoYXQgZGlyZWN0aW9uLg0KDQpDaGVlcnMsDQpTLg0KDQpPbiAzMS8wMy8xNiAx ODo0MCwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+IEkgY2FuIHNlZSBzb21lIHZhbHVlIGlu IGhhdmluZyB0aGlzIElBTkEgcmVnaXN0cnkgbGlzdCBmb3IgDQo+IGNpcGhlcnN1aXRlcyBpbiB0 aGUgd2F5IGJlaW5nIHByb3Bvc2VkIChldmVuIGlmIGl0IG1heSBiZSBpbnRlcnByZXRlZCANCj4g ZGlmZmVyZW50bHkgYnkgZGlmZmVyZW50IGF1ZGllbmNlcykuIFRoZXJlIGhhdmUgYmVlbiwgb2Yg Y291cnNlLCB0b28gDQo+IG1hbnkgYWxnb3JpdGhtcyB1c2VkIG9ubHkgaW4gc3BlY2lmaWMgY291 bnRyaWVzIGFuZCB0aG9zZSANCj4gc3Vic3RhbnRpYWxseSBpbmNyZWFzZWQgdGhlIGNpcGhlcnN1 aXRlIGxpc3QuDQo+IA0KPiBJIGFtIGp1c3QgYSBsaXR0bGUgYml0IHdvcnJpZWQgdGhhdCBldmVy eXRoaW5nIGRldmVsb3BlZCBmb3IgdGhlIElvVCANCj4gZW52aXJvbWVudCBpcyBxdWl0ZSBsaWtl bHkgbGFibGVkIGFzIG5vdCByZWNvbW1lbmRlZCBieSB0aGUgSUVURiBpbiANCj4gdGhpcyByZWdp c3RyeSBiZWNhdXNlIG9mIHRoZSBXZWIgZm9jdXMgaW4gdGhpcyBncm91cC4NCj4gDQo+IFRoZSBK UEFLRSBpcyB0aGUgaXRlbSB0aGF0IHdlIGFyZSBjdXJyZW50bHkgaW50ZXJlc3RlZCBpbiBiZWNh dXNlIHdlIA0KPiBoYXZlIGNvbnRyaWJ1dGVkIHRvIHRoZSBzdGFuZGFyZGl6YXRpb24gd29yayBy ZWxhdGVkIHRvIFRocmVhZCBhbmQgdGhlIA0KPiBzdGFjayB3ZSBoYWQgaW1wbGVtZW50ZWQuIE9m IGNvdXJzZSwgdGhlIHJlbWFyayB0aGF0IEpQQUtFIG1pZ2h0IG5vdCANCj4gYmUgYSBnb29kIGZp dCBmb3IgVExTIDEuMyBtYXkgYmUgY29ycmVjdC4NCj4gDQo+IENpYW8NCj4gSGFubmVzDQo+IA0K PiBPbiAwMy8zMS8yMDE2IDA3OjI1IFBNLCBTYWx6LCBSaWNoIHdyb3RlOg0KPj4+IEludGVyZXN0 aW5nIGlkZWEuIFlvdSBzZWUgdGhpcyBJQU5BIHJlZ2lzdHJ5IG1vcmUgYXMgdGhlIG1hbmRhdG9y eSANCj4+PiB0byBpbXBsZW1lbnQgYWxnb3JpdGhtIGxpc3QgKGZvciBXZWIgYXBwcykuDQo+Pg0K Pj4gSSBkb24ndC4gIEJ1dCBsb3RzIG9mIG91dHNpZGVycyBkbywgYW5kIEkga25vdyB0aGV5IGV4 ZXJ0IHByZXNzdXJlIG9uIHZhcmlvdXMgcHJvamVjdHMgYW5kIFRMUy9BRCAibGVhZGVyc2hpcCIu ICBJJ3ZlIG9ubHkgaGFkIGEgbGl0dGxlIGJpdCBvZiBpdCB2aWEgb3BlbnNzbCBjb21wYXJlZCB0 byB0aG9zZSBmb2xrcy4NCj4+DQo+PiAtLQ0KPj4gU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRl Y2hub2xvZ2llcw0KPj4gSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0K Pj4NCj4+DQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4gVExTQGlldGYub3JnDQo+IGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJm JTJmd3d3LmkNCj4gZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZkYXRhPTAxJTdj MDElN2NBbmRyZWkuUG9wb3YlNDBtaWNybw0KPiBzb2Z0LmNvbSU3Y2YzMmQyZTVhYzI5ZTQ5YzJk NDkzMDhkMzU5OGQyYWQzJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjDQo+IGQwMTFkYjQ3JTdj MSZzZGF0YT0lMmJxcG80Zld4TFhBaHhFWkhodjdBOUExQnZBNjBxWVVJWDBEczNHV243V0ElM2QN Cj4gDQoNCg== From nobody Thu Mar 31 11:46:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08612D6CB for ; Thu, 31 Mar 2016 11:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.73 X-Spam-Level: X-Spam-Status: No, score=-2.73 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-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 pAfrygtUFXju for ; Thu, 31 Mar 2016 11:46:00 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 38DBB12D6BF for ; Thu, 31 Mar 2016 11:46:00 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9B8D342377D; Thu, 31 Mar 2016 18:45:59 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 85561423754; Thu, 31 Mar 2016 18:45:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1459449959; bh=688XAxsCWJmVe1KWZqkrh/e+kJxZ1GfZnxHrWtUkYHQ=; l=7354; h=To:References:Cc:From:Date:In-Reply-To:From; b=u5joB6jhDEPWeSzn6hzk8blPI+0DhDVDekHutMeof/WgNAoQsAbBy8BaUzIT9d0XE BiZ6D8Afe2ZjBBfn1pdChPfhMM+2HFzDNsP6OVUs03JJxSGLfgQANBW1LxMdHBx0mT EusfjgQp40fE1EDmWdRWgqiiFnJYnSSfV7ieZQzs= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 347FE1FCA4; Thu, 31 Mar 2016 18:45:59 +0000 (GMT) To: Eric Rescorla References: <56FD154D.1030300@gmx.net> <56FD5978.3040401@akamai.com> <56FD5BC3.5060103@akamai.com> From: Benjamin Kaduk Message-ID: <56FD7066.5010006@akamai.com> Date: Thu, 31 Mar 2016 13:45:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020406050003090803080902" Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Mar 2016 18:46:02 -0000 This is a multi-part message in MIME format. --------------020406050003090803080902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/31/2016 12:21 PM, Eric Rescorla wrote: > > > On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk > wrote: > > On 03/31/2016 12:13 PM, Eric Rescorla wrote: >> >> >> On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk >> > wrote: >> >> On 03/31/2016 12:02 PM, Bill Cox wrote: >>> On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig >>> >> > wrote: >>> >>> Hi Sean, >>> >>> we at ARM would find it somewhat unfortunate to remove >>> the client >>> authentication feature from the 0-RTT exchange since >>> this is one of the >>> features that could speed up the exchange quite >>> significantly and would >>> make a big difference compared to TLS 1.2. >>> >>> >>> Client certs can still be used with PSK 0-RTT, but only on >>> the initial 1-RTT handshake. it is up to the client to >>> ensure that the security of the resumption master secret >>> (RMS) is solid enough to warrant doing 0-RTT session >>> resumption without re-verification of the client cert. >> >> That seems to rule out most corporate uses of client certs >> [for 0-RTT client authentication], since I doubt anyone will >> be interested in trusting that the client does so properly. >> >> >> Do those servers generally carry over client auth through resumption? >> > > I don't know, offhand. I just wanted to point out that for one > sizeable use case for client certs in general (not considering > 0RTT), this proposed scheme does not seem useful. It may still be > useful in other use cases, of course. > > > I'm really not following you here. > Sorry. I did not really make a very clear point. > My point is that for TLS 1.2 there are two categories of servers that > do client auth: > > - Those which carry over client auth through resumption > - Those which do not > > The former should be equally happy (modulo all the concerns about > replay, etc.) to carry over > client auth through 0-RTT resumption. The latter will presumably not > be but can do 1-RTT. > The question then becomes how large the two populations are. > I guess I was thinking about the latter, and trying to note (but not actually doing so) that they would have to do 1-RTT. I think this subthread has outlived its useful existence... -Ben --------------020406050003090803080902 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 03/31/2016 12:21 PM, Eric Rescorla wrote:


On Thu, Mar 31, 2016 at 10:17 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 03/31/2016 12:13 PM, Eric Rescorla wrote:


On Thu, Mar 31, 2016 at 10:08 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
On 03/31/2016 12:02 PM, Bill Cox wrote:
On Thu, Mar 31, 2016 at 5:17 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
Hi Sean,

we at ARM would find it somewhat unfortunate to remove the client
authentication feature from the 0-RTT exchange since this is one of the
features that could speed up the exchange quite significantly and would
make a big difference compared to TLS 1.2.

Client certs can still be used with PSK 0-RTT, but only on the initial 1-RTT handshake.  it is up to the client to ensure that the security of the resumption master secret (RMS) is solid enough to warrant doing 0-RTT session resumption without re-verification of the client cert. 

That seems to rule out most corporate uses of client certs [for 0-RTT client authentication], since I doubt anyone will be interested in trusting that the client does so properly.

Do those servers generally carry over client auth through resumption?


 I don't know, offhand.  I just wanted to point out that for one sizeable use case for client certs in general (not considering 0RTT), this proposed scheme does not seem useful.  It may still be useful in other use cases, of course.

I'm really not following you here.


Sorry.  I did not really make a very clear point.

My point is that for TLS 1.2 there are two categories of servers that do client auth:

- Those which carry over client auth through resumption
- Those which do not

The former should be equally happy (modulo all the concerns about replay, etc.) to carry over
client auth through 0-RTT resumption. The latter will presumably not be but can do 1-RTT.
The question then becomes how large the two populations are.


I guess I was thinking about the latter, and trying to note (but not actually doing so) that they would have to do 1-RTT.

I think this subthread has outlived its useful existence...

-Ben
--------------020406050003090803080902-- From nobody Thu Mar 31 18:19:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8D512D92E for ; Thu, 31 Mar 2016 18:19: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=unavailable 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 3z37JO7OrQBe for ; Thu, 31 Mar 2016 18:19:42 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::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 239F712D944 for ; Thu, 31 Mar 2016 18:19:41 -0700 (PDT) Received: by mail-qg0-x22c.google.com with SMTP id y89so83519457qge.2 for ; Thu, 31 Mar 2016 18:19:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DSC3Y2WaUHrR4rAd93gCF5Nvv+I4LZZ7ytohctiDb/Y=; b=Y8mdX+oWYnKc5xmLC65qVNf8o4UOwbDsAwkrXXm/+N/yRYdc0IzSF2AGGYVj7GPN5R LWkPpEztP11D+Mb6YHeLQNGnZaG13I3YlKKwxECVOznSRwf7ydRl0NC3Iv0pnWbjXuk3 m2lrT8LhdC9nFcsxWnOH8O8YmWu3d5+ag7g3g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DSC3Y2WaUHrR4rAd93gCF5Nvv+I4LZZ7ytohctiDb/Y=; b=Q3N8w72AxLCdMrx61FNUbl0CY4NzsgEBA/uUONaSwgCfmaDIvpSjQNBw/GcU6YYHo6 28oG9FLRWsGFg1oQkEguZskdChuX/VKdFVIzKr76zRwMYAjbYCJZPqVO/9XZ+01GtKDw DKCuEy3NJMEhYEcCPV3j69ONMuJqcx2zRQgTtDT8lOK8Pnxz4BccgPhroiF/r6eZO+ya FdFxh1mDnzsUj48cG2ZCQTudPvBI5A3jMxXFFMNfnCY+gOliVfAlBtXW7CBEqC8L46lo 3mND7Us2RvuPfVx9pbR90PSAfVjknodNId7+9Z5XphMdt1uizFkzXPdjheFR1h8JdYWE Uwow== X-Gm-Message-State: AD7BkJK4tW8AlgOYzdZYoenxWRFafzrSFRl2Z0kIWVgMy2upgbHtLdyzaoKpJJl4rfHfuw== X-Received: by 10.140.81.51 with SMTP id e48mr20874606qgd.27.1459473581021; Thu, 31 Mar 2016 18:19:41 -0700 (PDT) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id y16sm5070073qhb.39.2016.03.31.18.19.39 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 18:19:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <56F3B9CC.8050305@cs.tcd.ie> Date: Thu, 31 Mar 2016 21:19:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56F2B2E7.1060809@cs.tcd.ie> <56F3B9CC.8050305@cs.tcd.ie> To: Stephen Farrell , "" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Apr 2016 01:19:45 -0000 On Mar 24, 2016, at 05:56, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > Thanks for the speedy response... >=20 > Again #3 below is what I care about, the other stuff isn't > a big deal. >=20 > On 24/03/16 00:38, Bodo Moeller wrote: >> "Stephen Farrell" : >>=20 >>> (1) Why experimental? Wouldn't this be better as info >>> and documented as "here's a spec for a thing that's >>> widely deployed." I fear we may get questions like >>> "what's the experiment?", "where's this going in >>> future?" if this aims for experimental, and info may >>> avoid that esp if we really want people to move to >>> TLS1.3. I also didn't see list discussion about what >>> kind of RFC to aim for, but maybe it was discussed at >>> a meeting or interim? (Apologies if I missed that in >>> my scan of the list.) >>=20 >> I'm myself torn between "Experimental" and "Informational" (certainly = not >> "Historic" because the spec has not been superseded by a more recent = one >> and is not obsolete for any other reason [ >> https://tools.ietf.org/html/rfc2026#section-4.2.4], unless we somehow >> manage to complete TLS 1.3 standardization before this). Taking into >> account how False Start is actually deployed (and taking into >=20 > Right. TLS1.3 will hopefully make this historic, so we could just > park this in the RFC editor queue and have both RFCs emerge on the > same day with this one as Historic. With did that with DKIM (4871) > and DomainKeys (4870, Historic) for example. Note that I'm not arguing > for doing that, just raising the option if that's what the WG want > and if the list hasn't discussed it. I assume though that the WG > don't want to take this route so no need to discuss it more in that > case. >=20 >> account that >> we expect it to eventually be replaced by a TLS 1.3 mechanism) and = how our >> I-D is cited in research papers on TLS, "Experimental" sounds right = to me: >> the spec really is part of a research and development effort [ >> https://tools.ietf.org/html/rfc2026#section-4.2.4]. "Informational" >> wouldn't be wrong either. >=20 > I think the latter matches much better myself, as there really is > no experiment being done here and we're not gonna develop this any > more once TLS1.3 is done, but whatever - I'm ok with saying that > the WG just wanted experimental. But you'll likely get asked this > again and again. At least we can now point at this thread and say > that it was discussed on the list though. (Which was partly why I > asked:-) >=20 > It'd be no harm though if a couple of others chimed in on this > just to there's recorded opinion from more than just the AD and > an author. >=20 > We can change to informational at the end of LC if need be, i.e., > there's no need to hold stuff up for that and such a change then > doesn't add any delay. This draft started out as Informational and then we switched it = Experimental. The WG has not considered whether we should publish this = should go Historic now, be held and publish as Historic later, etc. How do folks feel about Historic vs Experimental vs Informational? If we=E2=80=99re going to move it to Historic, then we=E2=80=99ve got a = couple of options: 0) As described above: Get it approved by the IESG, hold it in RFC = editor=E2=80=99s queue, and publish it as historic at the same time TLS = 1.3 is published. 1) Approve it, get it published, and then make it Historic with another = draft. 2) Approve it, get it published, and then make it Historic with an IESG = initiated Protocol Action, which is a message that the IESG initiates = requesting the status be changed similar to an IETF but requires no = draft. (there=E2=80=99s probably some other options like an adding an IESG = note/new section that says =E2=80=9Cthis goes to historic when TLS 1.3 = is published, but I think the above three options seem more realistic.) Option 0 is probably the least amount of work. We just hold it, but in = some sense I kind of tend to think that we=E2=80=99re punishing the = authors. There=E2=80=99s nothing they=E2=80=99ve really got to do, but = it feels somehow like we=E2=80=99re hitting them upside the head with = the process two-by-four. Option 1 would be a total PITA. People say that we can get a draft = published quickly if we (the royal we) really want to, but my experience = is otherwise. Option 2 is something that I don't think we had in our toolkit when DKIM = was being worked on. The draft gets published the authors can move on = and we (the process moths) can make sure the draft gets moved to = Historic. =20 What do the WG members think about the options of moving to historic? = Personally, I=E2=80=99d advocate option 2 because it keeps the work load = on the chairs/AD :) ~snipped 2~ >>=20 >>> (3) Why is there no description of the reasons for all >>> the MUST only use whitelisted and for the choices >>> that are whitelisted? Wouldn't omitting that tend to >>> lead people to use this more badly? >>=20 >> Well, I tried to capture the general reasoning in the spec -- but not = the >> detailed reasons for the specific choices suggested, because that = again >> would just go stale quickly. >=20 > Where are those general reasons stated? I don't see =E2=80=98em. The whitelisted options are described in the bullets in s4 and those = point to s5.* It=E2=80=99s stuff like don=E2=80=99t use suspect symmetric ciphers. >> In particular, I think this is an important observation in the I-D: >>=20 >> "If heuristically a small list of cipher suites and a single protocol >> version is found to be sufficient for the majority of TLS handshakes = in >> practice, it could make sense to forego False Start for any handshake = that >> does not match this expected pattern, even if there is no concrete = reason >> to assume a cryptographic weakness." >=20 > That may be important but it doesn't address the issue about which > I'm asking. >=20 >>=20 >> So the whitelists should have algorithms that are actually used in = practice >> and that don't have critical weaknesses, but why exactly those = particular >> algorithms happen to get used in practice is mostly out of scope = here. >=20 > Why is the logic behind such security relevant choices out of scope? > That makes no sense to me. Let's imagine a new ciphersuite is invented > and folks start to wonder whether or not it's ok to whitelist that for > false-start - wouldn't they expect this document to explain (maybe > mostly via references) why some ciphersuites are not good enough to > whitelist? I would expect that to be clear. >=20 > And to be clear, I'm not asking for an essay, but more like some text > in the intro saying "False start is not safe for a ciphersuite that > has properties such as because of . See > [refs] for full details." >=20 > For added clarity it'd also be good to have something like: > "Ciphersuites MUST have to be safe to > whitelist for false-start." >=20 > If figuring out text for the above is very hard, then I do think that > would indicate a real issue with this spec. If figuring that out is > just a minor bit of tedium, then I think it's worthwhile so that > future readers of the RFC can understand what's going on here, which > I don't think is the case from the current text. I think this text is already present: Clients MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a symmetric cipher that is considered cryptographically strong. In the key exchange algorithms and client certificate type security = considerations, there=E2=80=99s: The recommended whitelists are such that if cryptographic algorithms suitable for forward secrecy would possibly be negotiated, no False Start will take place if the current handshake fails to provide forward secrecy. .. and .. Forward secrecy can be achieved using ephemeral Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman ... If we summarize these in the Introduction we=E2=80=99re good? spt > Cheers, > S. >=20 >=20 >>=20 >> Bodo >>=20 >>> That could be done >>> with some explanatory text and using some of the >>> references below maybe. Or, if we don't really want new >>> folks to implement this (do we?) then just saying that >>> might mean it's ok to not explain the "why." (And then >>> you could also address #1 above then by issuing this >>> as an historic RFC too if you wanted.) >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Mar 31 18:46:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53CD12D120 for ; Thu, 31 Mar 2016 18:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChvEZexYVG-b for ; Thu, 31 Mar 2016 18:46:00 -0700 (PDT) Received: from out4133-146.mail.aliyun.com (out4133-146.mail.aliyun.com [42.120.133.146]) by ietfa.amsl.com (Postfix) with ESMTP id 5F47C12D0B8 for ; Thu, 31 Mar 2016 18:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1459475157; h=Date:Subject:From:To:Message-ID:Mime-version:Content-type; bh=m3xZ/aTsF3CZm3S0ndgbFRM5cYfa5gUAWOk8n/al9vc=; b=YJ/P92SvNoFHw/hyOA1ne9bIR+kqcvBftO7BN3FD+1DwncGaK5f+bomlYwNXmStaFUvjLn0NrlVH1WMcsGPAAQLu2spypJPoNM5i3PVNONsgvePZ5WTkTB22iaYF2Szvh/wq6bwN627zHzPkhqmDWVqH8RLtwlJ3n7ir2UNdxwU= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R171e4; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03296; MF=dacheng.zdc@alibaba-inc.com; NM=1; PH=DS; RN=5; SR=0; TI=SMTPD_----4f3vrAK_1459475149; Received: from 10.32.179.17(mailfrom:dacheng.zdc@alibaba-inc.com ip:182.92.253.16) by smtp.aliyun-inc.com(127.0.0.1); Fri, 01 Apr 2016 09:45:53 +0800 User-Agent: Microsoft-MacOutlook/14.6.2.160219 Date: Fri, 01 Apr 2016 09:45:48 +0800 From: "Dacheng Zhang" To: Eric Rescorla Message-ID: Thread-Topic: [TLS] =?GB2312?B?u9i4tKO6?= A TLS extension transfering service indication information References: <201603290113.08796.davemgarrett@gmail.com> <6bd0acd9-9567-4e0b-91f1-9e48dee15d1c.dacheng.zdc@alibaba-inc.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3542348754_426101" Archived-At: Cc: tls , =?GBK?B?wfW088X0KMX0s8kp?= Subject: Re: [TLS] =?gb2312?b?u9i4tKO6IEEgVExTIGV4dGVuc2lvbiB0cmFuc2ZlcmluZyBz?= =?gb2312?b?ZXJ2aWNlIGluZGljYXRpb24gaW5mb3JtYXRpb24=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Apr 2016 01:46:03 -0000 > ʼʹ MIME ʽʼĶʶ ˸ʽˣ޷ʶʼķֲ򲿷ݡ --B_3542348754_426101 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable =B7=A2=BC=FE=C8=CB: Eric Rescorla =C8=D5=C6=DA: 2016=C4=EA3=D4=C231=C8=D5 =D0=C7=C6=DA=CB=C4 =CF=C2=CE=E79:54 =D6=C1: dacheng de =B3=AD=CB=CD: Eric Mill , Dave Garrett = , tls , "=C1=F5=B4=F3=C5=F4(=C5=F4=B3=C9)" =D6=F7=CC=E2: Re: [TLS] =BB=D8=B8=B4=A3=BA A TLS extension transfering service indication information On Wed, Mar 30, 2016 at 10:40 PM, Dacheng Zhang wrote: > Thanks again for your comments. See my reply inline please. ^_^ >>=20 >> I'm not following. If you trust the device, then why do you need any kin= d of >> cryptographic >> authentication on the token. >>=20 >> Dacheng=A3=BALet assume we trust the device. But the APP use a SNI to indica= te the >> service that the APP intends to access. Because the SNI is static which = may >> not be changed for months, it is easier for attackers who monitor the ne= twork >> to get the SNI and use it to gain benefit. We need a securer solution. A= s I >> have mentioned in my previous email, this solution will make such attack= s >> more difficult. By the way, SNI is not designed for this purpose, we nee= d to >> do some additional work to address this issue, right? >=20 > Again, you need a threat model. It sounds like you both do and do not tru= st > the client >=20 > Dacheng: Threat model will be provided. Actually=A3=ACwe don=A1=AFt try to protec= t > against the compromise of client. Or the scenario where an APP against an= other > one on the same device. This solution is used to protect against the atta= ckers > who are able to monitoring the communication between the client and the s= erver I'll await this. =20 >=20 >>=20 >> Hmm... I'm not at all sure that TLS should address this problem. However= , my >> review >> was directed to whether your proposed solution even works on its own ter= ms. >>=20 >> Dacheng: That is why we need to raise the discussion here. It would be g= reat >> if this issue could be considered by TLS WG. >=20 > I don't find this to be a very compelling use case and I don't think it's > really appropriate to > try to solve it at the TLS layer. If you want to have secure flow > identification you should > do it at the IP or TCP layers. >=20 > Dacheng:Ok, this requirement is quite strong. We need a solution to addre= ss > this issue if we want to use TLS to secure our APPs deployed on hundreds = o > millions o mobile devices. Also=A3=ACChina mobile and Huawei are working wit= h us > on this issue. No, you only need it if you want to use a specific charging model. Dacheng This is an important business model which will benefit both customers and ICPs. But we cannot support it for the moment when we use TLS to secure the traffic. > Could you please tell me why it is better to address this issue at the IP= or > TCP layer. To the best of my knowledge. There is no space in IPv4 herders= to > insert any extensions. There are length limit in TCP options. In addition= , TCP > is implemented in kernel mode. It will cost more if we try to address thi= s > issue at the TCP or IP layer. I think the architectural reasons here are pretty clear. IP is the common network transport layer, not TLS. Also, IPv6 has extension headers. Dacheng: I consulted this to a lot of people. It seems they think in a different way. The deployment of changes in TCP or IP are much more difficiult. Currently, IPv4 rather than IPv6 is being used. This means our online system still not be able to support this charging model for multiple years. In addition, IP is at network layer protocol=A3=ACwhile this work is abo= ut providing information which indicate how to charge a flow. The work related with a flow should be done at the transport layer or higher. Please correct me if I am wrong.This issue is raised because the widely usage of TLS. If Ipsec will be used to secure the communication between mobile and cloud. We need to address it at the IP layer. ^_^ -Ekr > Look forward to more discussions. ^_^ >=20 > Cheers >=20 > Dacheng >>>>=20 >>>>=20 >>>=20 >>=20 >=20 --B_3542348754_426101 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable


=B7=A2=BC=FE=C8=CB: Eric Rescorla <e= kr@rtfm.com>
=C8=D5=C6=DA: 2016=C4=EA3=D4= =C231=C8=D5 =D0=C7=C6=DA=CB=C4 =CF=C2=CE=E79:54
=D6=C1: dacheng = de <dacheng.zdc@alibaba-inc.= com>
=B3=AD=CB=CD: Eric Mill <eric@konklone.com>, Dave Garrett <= ;davemgarrett@gmail.com>, tls= <tls@ietf.org>, "=C1=F5=B4=F3=C5=F4(=C5=F4=B3=C9)" <= max.ldp@alibaba-inc.com>
= =D6=F7=CC=E2: Re: [TLS] =BB=D8=B8=B4=A3=BA A TLS extensio= n transfering service indication information



On Wed, Ma= r 30, 2016 at 10:40 PM, Dacheng Zhang <dacheng.zdc@alibaba-inc.com&g= t; wrote:
Thanks again f= or your comments. See my reply inline please. ^_^
<= div class=3D"gmail_extra">
<= div style=3D"word-wrap:break-word">

I'm not following. If you trust the device, t= hen why do you need any kind of cryptographic
authentication on th= e token.

Dacheng=A3=BALet assume we trust the device. But the APP use a= SNI to indicate the service that the APP intends to access. Because the SNI= is static which may not be changed for months, it is easier for attackers w= ho monitor the network to get the SNI and use it to gain benefit. We need a = securer solution. As I have mentioned in my previous email, this soluti= on will make such attacks more difficult. By the way, SNI is not designed fo= r this purpose, we need to do some additional work to address this issue, ri= ght?

Again, you ne= ed a threat model. It sounds like you both do and do not trust the client

Dacheng: Threat model will be provided. Actually=A3=ACwe don’= ;t try to protect against the compromise of client. Or the scenario where an= APP against another one on the same device. This solution is used to protec= t against the attackers who are able to monitoring the communication between= the client and the server

I'll await this.

 

<= div style=3D"word-wrap:break-word">

Hmm... I'm not at all sure that TLS sh= ould address this problem. However, my review
was directed to whet= her your proposed solution even works on its own terms.

Dacheng: That is why = we need to raise the discussion here. It would be great if this issue could = be considered by TLS WG.

= I don't find this to be a very compelling use case and I don't think it's re= ally appropriate to
try to solve it at the TLS layer. If you want = to have secure flow identification you should
do it at the IP or T= CP layers.

Dacheng:Ok, this requirement is quite strong. We need a = solution to address this issue if we want to use TLS to secure our APPs deployed on hundreds o millions o mobil= e devices.  Also=A3=ACChina mobile and Huawei are working with u= s on this issue.

No, you = only need it if you want to use a specific charging model.
=

Dacheng This is an important business model which will benefit both = customers and ICPs. But we cannot support it for the moment when we use TLS = to secure the traffic. 


Could you please tel= l me why it is better to address this issue at the IP or TCP layer. To the b= est of my knowledge. There is no space in IPv4 herders to insert any extensi= ons. There are length limit in TCP options. In addition, TCP is implemented = in kernel mode. It will cost more if we try to address this issue at the TCP= or IP layer. 

I thi= nk the architectural reasons here are pretty clear. IP is the common network= transport
layer, not TLS. Also, IPv6 has extension headers.
=

Dacheng: I consulted this to a lot of people. It seems t= hey think in a different way. The deployment of changes in TCP or IP are muc= h more difficiult. Currently, IPv4 rather than IPv6 is being used. This mean= s our online system still not be able to support this charging model for mul= tiple years. In addition, IP is at network layer protocol=A3=ACwhile this work i= s about providing information which indicate how to charge a flow. The work = related with a flow should be done at the transport layer or higher. Please = correct me if I am wrong.This = issue is raised because the widely usage of TLS. If Ipsec will be used to se= cure the communication between mobile and cloud. We need to  address it= at the IP layer. ^_^

-Ekr


Look forward to more discussions. ^_^

Che= ers

Dacheng




<= /div>


= --B_3542348754_426101-- From nobody Thu Mar 31 20:40:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFC412D533 for ; Thu, 31 Mar 2016 20:40:16 -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 QyvPHfJu1jYh for ; Thu, 31 Mar 2016 20:40:14 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 75B1C12D520 for ; Thu, 31 Mar 2016 20:40:13 -0700 (PDT) Received: by mail-lb0-x22a.google.com with SMTP id bc4so64131527lbc.2 for ; Thu, 31 Mar 2016 20:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=c1SKFWdjwan3oI++IiM7irBpgNKdl42EXW+N6Nj2osk=; b=FsPzBaFPPTm+KPkcxHgCQKQu22LsWQRERapQMMKcAxMK7pL9R8JhgQhegxmCW/za24 s6Uq1L+K4uNGMgo8jlI5t4V7y0rRQeSpntmqePccuXuGtY3PKZrfBruFKHKi5hK/6Dbv aSqmOgvl0hCmqZNuB0YI1NfJ5VWsbxrBjQJnjpyLSAAm6U6PczOkr/6bP8EQCIqLYSmn hg+SzyuYUCQ8knngPB7zToheDieUS95yg6e9Jg3mNApcXCTY17OaeC35EbCft8JCgikf 8X7BNLC/Ee6mfqJL4uY0GW9aJxLNI3QwUzbMaJdg3DOmVS0S0A65OIAP2U/gqfP1Gemh IyIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=c1SKFWdjwan3oI++IiM7irBpgNKdl42EXW+N6Nj2osk=; b=EqdhQ4gG8LprBIBK75MvlhJmq8vvNw6oU/P2TF+7UH/VOQZ8GUgmqyjvYvNezttXcK dkL0dYEJA00WR/B/+KOFC0qK+k7yKnDzKlO2F53ugZKihlsc5wmrXkUGYpVXovcc8EZV OegHsWK7tAHkGE7FamEtdJFl5WdydcjmKLTH0lMM1F8OfsIHsLbH31kKWG4vAIrvh6w3 MZVoXSV3wxU9hDxqd9nkxW7tEBTCCBRWYJzSfw0dCOmChvzYQrzgWWMer5po65d1krWu hPJ2l8ERtlc4D7ZZVoq05qLYjKUxqu+0PtmCSZ23pdMZbeFLKuIISoiV2PMue9xkkDfL 8dAQ== X-Gm-Message-State: AD7BkJKfxC2nGQBK4OctkgCgCA1khhMmdMisGeMNhaYGFZAX5z7J7Oc/3GegHx4oCHz7tBz8RiwAMvBNuROaAA== X-Received: by 10.112.181.38 with SMTP id dt6mr863428lbc.114.1459482011524; Thu, 31 Mar 2016 20:40:11 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.6 with HTTP; Thu, 31 Mar 2016 20:39:42 -0700 (PDT) In-Reply-To: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> From: Hugo Krawczyk Date: Thu, 31 Mar 2016 23:39:42 -0400 X-Google-Sender-Auth: d5hnWszyyQ_7CrSi4b29-yD1Scs Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a11361298da6568052f6422ba Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Apr 2016 03:40:17 -0000 --001a11361298da6568052f6422ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote: > All, > > To make sure we=E2=80=99ve got a clear way forward coming out of our BA s= essions, > we need to make sure there=E2=80=99s consensus on a couple of outstanding= issues. > So... > > There also seems to be (rougher) consensus not to support 0-RTT via DHE > (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT mo= de > as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT ar= e > almost identical, =E2=80=8BI am not offering an opinion about what the WG should decide regar= ding keeping DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that the above claim "The security properties of PSK-based 0-RTT and DHE-based 0-RTT are almost identical" is not quite right (nothing I say here is new, I just fel= t that I had to "object" to this statement as written). There are some significant differences - in some cases even "fundamental differences" - between keeping secret state (in the PSK case) and keeping non-secret state (in the DHE case) or even not keeping state at all (in the DHE case) and retrieving the server key g^s from some external source (with integrity but not secrecy). In addition, using DHE 0-RTT would require the client to send a key share g^x leading to a PFS 1-RTT exchange while with PSK it may be "tempting" to omit PFS. Moreover, if the server's configuration key g^s is refreshed often (say each 5 minutes) then the g^xs key used by the client to protect its 0-RTT data already has some good level of forward secrecy (the attacker has a 5 minute window to find s and after that forwar= d security is guaranteed). The latter point touches on an important aspect which is the key management complexity of ticket encryption/decryption keys (as needed in the PSK case) vs managing secret DH key s (in the DHE case). I am not sure what would be done better (more secure) in practice. But really it seems that the discussion boils down to identifying cases of enough interest where avoiding the original 1-RTT trip for establishing a session ticket is important. I am puzzled by the fact that the Google team seems ok with something that essentially voids the main feature and design basis of of QUIC. Hugo=E2=80=8B =E2=80=8B=E2=80=8B > but 0-RTT PSK has better performance properties and is simpler to specify > and implement. Note that this does not permanently preclude supporting > DHE-based 0-RTT in a future extension, but it would not be in the initial > TLS 1.3 RFC. > > If you think that we should keep DHE-based 0-RTT please indicate so now > and provide your rationale. > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11361298da6568052f6422ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=

O= n Tue, Mar 29, 2016 at 9:11 AM, Sean Turner <sean@sn3rd.com> = wrote:
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

There also seems to be (rougher) consensus not to support 0-RTT via DHE=C2= =A0 (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT= are almost identical,

=E2=80= =8BI am not offering an opinion about what the WG should decide regarding k= eeping
DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note that= the
above claim "The security properties of PSK-based 0-RTT and DHE-= based 0-RTT are
almost identical" is not quite right (nothing I say h= ere is new, I just felt
that I had to "object" to this statement= as written).

There are some significant differences - in some cases= even "fundamental
differences" - between keeping secret state (= in the PSK case) and keeping
non-secret state (in the DHE case) or even no= t keeping state at all (in the
DHE case) and retrieving the server key g^s= from some external source (with
<= font face=3D"verdana, sans-serif">integrity but not secrecy).=C2=A0 In addi= tion, using DHE 0-RTT would require the
client to send a key share g^x lea= ding to a PFS 1-RTT exchange while with PSK
it may be "tempting"= to omit PFS.=C2=A0 Moreover, =C2=A0if the server's configuration
key = g^s is refreshed often (say each 5 minutes) then the g^xs key used by the
= client to protect its 0-RTT data already has some good level of forward
se= crecy (the attacker has a 5 minute window to find s and after that forward<= /font>
security is guaranteed).=C2=A0 The latter point touches on an important as= pect
which is the key management complexity of ticket encryption/decryptio= n keys
(as needed in the PSK case) vs managing secret DH key s (in the DHE= case).=C2=A0
I am not sure what would be done better (more secure) in pra= ctice. =C2=A0

But really it seems that the discussion boils down to = identifying cases of
enough interest where avoiding the original 1-RTT tri= p for establishing a
session ticket is important. I am puzzled by the fact= that the Google team
seems ok with something that essentially voids the= main feature and design
basis of of QUIC.

Hug= o=E2=80=8B

=E2=80=8B=E2=80=8B
but 0-RTT PSK has better performance properties and is simpler to specif= y and implement. Note that this does not permanently preclude supporting DH= E-based 0-RTT in a future extension, but it would not be in the initial TLS= 1.3 RFC.

If you think that we should keep DHE-based 0-RTT please indicate so now and= provide your rationale.

J&S

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

--001a11361298da6568052f6422ba-- From nobody Thu Mar 31 20:49:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1785812D1AC for ; Thu, 31 Mar 2016 20:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 X2pqkkTkm-PW for ; Thu, 31 Mar 2016 20:49:47 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B54BE12D19B for ; Thu, 31 Mar 2016 20:49:47 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id h129so131709738ywb.1 for ; Thu, 31 Mar 2016 20:49: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=t0zF2BW5CRGls9IhmaWdjbqgjzqvI2xf42cRLVBMYRQ=; b=iWh7TuZh758FLrof5qZqoAcpwEi4tomyH0BtwiFlgpMJJ76wqlS+ampdlud0k38/pz hyUt+7dEBC0E26Pezka/ut4Ib1uqCWtiHNfg6YlYqGL0EHfWMkniBX/yYIk6qjF/apSW +DQ7QyLnr2l3e0LChwlHDwax/2c0i2fedE9kJ1U7SLriDfy1ezhk2wQK2c5B/FpQHzGv ry4czZCLNocMtQ8GRceLkZ9dnQcYnIi7BwSGetBX8jIh180kX/WFkKNtt5eSla46SM+j uNyRdAAwIu9+44HWqdTQ5BxX+oCkYHJr/DkoZidHsiNTBDPpyJwg4AGFGQUOdp4ze1v1 YNlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t0zF2BW5CRGls9IhmaWdjbqgjzqvI2xf42cRLVBMYRQ=; b=QPe3GK43A37Ttt/k8sc/1ANOr1CpT5OW+EVtM95zMRRfHWl0R/NYSJcf+tmqpDLksl OXoX4f4JMVS2gxJfddReadcJSmwTp9ailejBL6M9px3W8wUf6fqhAWD6QEe21zV6pj1b mjoahMDXdr/HCPreBLVGOQW+lgOvCzNZkr0ZESXQ4ELok8jgw4xe98jJcHXNq7COkb6D K4SHs4xsIP26xZNR2j/7sIwd6GkiiGU4r/hqcenh7HZ/1gnQYjYv+e9Qp1TDUjXsiDbE LTMbN2hPyZyr7YaNEyfizgmWlGzn5opuG9dfrug3mZYVdNgaOWXk0al82sU50ANa4+FF Cweg== X-Gm-Message-State: AD7BkJL69Q1vrHhOCyZDnOBpQPB6xKFhh5hUh8/XiV6lLM5XmtVd1vJccJAUmWX7D1aBKOpM7/FAkD6JqZHvKg== X-Received: by 10.129.92.132 with SMTP id q126mr1501935ywb.155.1459482586948; Thu, 31 Mar 2016 20:49:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 31 Mar 2016 20:49:07 -0700 (PDT) In-Reply-To: References: <063B3B0B-B141-459C-890F-9E001655936F@sn3rd.com> From: Eric Rescorla Date: Thu, 31 Mar 2016 20:49:07 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a114d85d626d820052f6445f1 Archived-At: Cc: "" Subject: Re: [TLS] Call for consensus: Removing DHE-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Apr 2016 03:49:50 -0000 --001a114d85d626d820052f6445f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk wrote: > > > On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner wrote: > >> All, >> >> To make sure we=E2=80=99ve got a clear way forward coming out of our BA = sessions, >> we need to make sure there=E2=80=99s consensus on a couple of outstandin= g issues. >> So... >> >> There also seems to be (rougher) consensus not to support 0-RTT via DHE >> (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT m= ode >> as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT a= re >> almost identical, > > > =E2=80=8BI am not offering an opinion about what the WG should decide reg= arding > keeping > DHE-based 0-RTT in the base TLS 1.3 document, but just wanted to note tha= t > the > above claim "The security properties of PSK-based 0-RTT and DHE-based > 0-RTT are > almost identical" is not quite right (nothing I say here is new, I just > felt > that I had to "object" to this statement as written). > > There are some significant differences - in some cases even "fundamental > differences" - between keeping secret state (in the PSK case) and keeping > non-secret state (in the DHE case) or even not keeping state at all (in t= he > DHE case) and retrieving the server key g^s from some external source (wi= th > integrity but not secrecy). In addition, using DHE 0-RTT would require t= he > client to send a key share g^x leading to a PFS 1-RTT exchange while with > PSK > it may be "tempting" to omit PFS. > The current plan of record is to allow the server to specify which cipher suites it is willing to accept, so it could refuse this Moreover, if the server's configuration > key g^s is refreshed often (say each 5 minutes) then the g^xs key used by > the > client to protect its 0-RTT data already has some good level of forward > secrecy (the attacker has a 5 minute window to find s and after that > forward > security is guaranteed). The latter point touches on an important aspect > which is the key management complexity of ticket encryption/decryption ke= ys > (as needed in the PSK case) vs managing secret DH key s (in the DHE case)= . > I am not sure what would be done better (more secure) in practice. > Can you expand on the difference here? Say that the server implements tickets by storing a DH private key and then encrypting the ticket under the corresponding public key. How does this provide different PFS properties? -Ekr > But really it seems that the discussion boils down to identifying cases o= f > enough interest where avoiding the original 1-RTT trip for establishing a > session ticket is important. I am puzzled by the fact that the Google tea= m > seems ok with something that essentially voids the main feature and desig= n > basis of of QUIC. > > Hugo=E2=80=8B > > =E2=80=8B=E2=80=8B > >> but 0-RTT PSK has better performance properties and is simpler to specif= y >> and implement. Note that this does not permanently preclude supporting >> DHE-based 0-RTT in a future extension, but it would not be in the initia= l >> TLS 1.3 RFC. >> >> If you think that we should keep DHE-based 0-RTT please indicate so now >> and provide your rationale. >> >> J&S >> >> _______________________________________________ >> 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 > > --001a114d85d626d820052f6445f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Mar 31, 2016 at 8:39 PM, Hugo Krawczyk <hugo@ee.technion.= ac.il> wrote:


On Tue, Mar 29, 2016 at 9:11 AM, Sean Turner = <s= ean@sn3rd.com> wrote:
All,

To make sure we=E2=80=99ve got a clear way forward coming out of our BA ses= sions, we need to make sure there=E2=80=99s consensus on a couple of outsta= nding issues.=C2=A0 So...

There also seems to be (rougher) consensus not to support 0-RTT via DHE=C2= =A0 (i.e., semi-static DHE) in TLS 1.3 at this time leaving the only 0-RTT = mode as PSK. The security properties of PSK-based 0-RTT and DHE-based 0-RTT= are almost identical,

=E2=80=8BI am not offer= ing an opinion about what the WG should decide regarding keeping
= DHE-based 0-RTT in the base TLS 1.3 docu= ment, but just wanted to note that the
above claim "The security properties of PSK-based 0-RT= T and DHE-based 0-RTT are
almost identical" is not quite right (nothing I say here is new, I = just felt
that I had to= "object" to this statement as written).

There are some significant differences - in some cases even "= ;fundamental
difference= s" - between keeping secret state (in the PSK case) and keeping=
non-secret state (in the DHE = case) or even not keeping state at all (in the
DHE case) and retrieving the server key g^s from s= ome external source (with
integrity but not secrecy).=C2=A0 In addition, using DHE 0-RTT would req= uire the
client to send= a key share g^x leading to a PFS 1-RTT exchange while with PSK
it may be "tempting" to = omit PFS.=C2=A0

<= /div>
The current plan of record is to allow the server to specify whic= h cipher suites it is
willing to accept, so it could refuse this<= /div>



Moreover, =C2=A0if the serv= er's configuration
= key g^s is refreshed often (say each 5 minutes) then the g^xs key used by t= he
client to protect it= s 0-RTT data already has some good level of forward
secrecy (the attacker has a 5 minute window to= find s and after that forward
security is guaranteed).=C2=A0 The latter point touches on an impor= tant aspect
which is th= e key management complexity of ticket encryption/decryption keys
(as needed in the PSK case) vs ma= naging secret DH key s (in the DHE case).=C2=A0
I am not sure what would be done better (more secu= re) in practice. =C2=A0

Can you expand on the difference here? Say that the serve= r implements tickets
by storing a DH private key and then encrypt= ing the ticket under the corresponding
public key. How does this = provide different PFS properties?

-Ekr
<= br>

But really i= t seems that the discussion boils down to identifying cases of
=
enough interest where avoiding the = original 1-RTT trip for establishing a
session ticket is important. I am puzzled by the fact that = the Google team
seems o= k with something that essentially voids the main feature and design<= /div>
basis of of QUIC.
=

Hugo=E2=80=8B

=
=E2=80=8B=E2= =80=8B
but 0-RTT PSK has better performance propertie= s and is simpler to specify and implement. Note that this does not permanen= tly preclude supporting DHE-based 0-RTT in a future extension, but it would= not be in the initial TLS 1.3 RFC.

If you think that we should keep DHE-based 0-RTT please indicate so now and= provide your rationale.

J&S

_______________________________________________
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


--001a114d85d626d820052f6445f1-- From nobody Thu Mar 31 22:07:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BBB12D106; Thu, 31 Mar 2016 22: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 LmFN-LE8ZVsC; Thu, 31 Mar 2016 22:07:54 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 8F2E312D0BA; Thu, 31 Mar 2016 22:07:54 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id y89so87301681qge.2; Thu, 31 Mar 2016 22:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=FFPjQXSiCDkgIO3lxcxqE2XRYLJD/wbJzbG7kPdy8uw=; b=aq8IufrbBCoVsmsm1rFVbwDFrVWyfQXcT2FsuL2NHXRW9vZaE0QDtPN7WOtDnOAHX1 htd+aEmo+B1csyveECMfFxIShVMA7Y7VvzKep32iVVIhpkpOh4Guhqg9+vW0ZKp7TVbt +gIYVFAuXlXEuQLQHNhVLS6NJ01Vd8zTd2MyZDBNTZ6eEmoaTN5LxPyXNn25+g25XLFB Zz/5AVo1rIOnROwnZJFFOdsbiYbI1aMYaePUWgYADPSZ/j7juLn9yFRgN90Qi6CqcGMg LV/qoJqf58aCvxGNdQd1Uy1/spzM8g4p+lq7uGi/Obl884rE5sT6ZDpCqDppyOrblNBp 8rHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=FFPjQXSiCDkgIO3lxcxqE2XRYLJD/wbJzbG7kPdy8uw=; b=VGu8RgKTjPiNtN1r/B9onE+CX+2GQX+qkkQbrpQ8wWgx1HtRarDUtWzwnp3+l8F3gh XW4xDLloBXils+1R9wH/MVl9k78M1ib6I8YUeub7yWhRQXR4Bo7FQh9d7L8V8JTi3T0Z bdN1llEGWpV6V88ia1n4tcWLr6iXNVk62peoUP3NP32LBb9FpfURX+IyNQO5Shk9X1AQ rEhh3MJkaOlZTE1+KHSQnYCmo0aEfuM0GgDz/Dt5JgfJ+NRPU1e+xIT7x2TBE2Kk6GV8 iKPdpq1h5WexdSCL2qcXQJr7ng9cjNZwHGojw47dIovxjM/6YkQoKNzMHVpWeksAdyk1 Pj2A== X-Gm-Message-State: AD7BkJLMCd/GGKDouSLpGtLkGyfKBx1vyEwbrk3zIDK+cFqk5vBy96G7A2yQP8IK4ageTA== X-Received: by 10.140.241.74 with SMTP id m71mr4402055qhc.36.1459487273768; Thu, 31 Mar 2016 22:07:53 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id a129sm5421092qkb.45.2016.03.31.22.07.53 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 31 Mar 2016 22:07:53 -0700 (PDT) From: Dave Garrett To: Sean Turner Date: Fri, 1 Apr 2016 01:07:51 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56F2B2E7.1060809@cs.tcd.ie> <56F3B9CC.8050305@cs.tcd.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201604010107.51996.davemgarrett@gmail.com> Archived-At: Cc: draft-ietf-tls-falsestart@ietf.org, tls@ietf.org Subject: Re: [TLS] AD review of draft-ietf-tls-falsestart-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Apr 2016 05:07:56 -0000 On Thursday, March 31, 2016 09:19:37 pm Sean Turner wrote: > (there=E2=80=99s probably some other options like an adding an IESG note/= new section that says =E2=80=9Cthis goes to historic when TLS 1.3 is publis= hed, but I think the above three options seem more realistic.) What looks simplest to me, would be to publish initially as experimental, t= hen have the TLS 1.3 specification obsolete it and contain language that ex= plicitly changes its status to historic without additional action. Consensu= s to change status would be considered a part of the required consensus to = publish TLS 1.3 as an RFC. The current TLS 1.3 draft already handwaves an i= nformational RFC to standards track (RFC5289: ECC AES GCM), so adding anoth= er handwave to change another RFC's status like this seems to make the most= sense. Dave