From nobody Sun Aug 3 10:09:08 2014 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 0CD481A0AED for ; Sun, 3 Aug 2014 10:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=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 TJe9rX7N7j6l for ; Sun, 3 Aug 2014 10:09:02 -0700 (PDT) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1DF1A0AEA for ; Sun, 3 Aug 2014 10:09:02 -0700 (PDT) Received: by mail-yh0-f42.google.com with SMTP id a41so3717289yho.15 for ; Sun, 03 Aug 2014 10:09:01 -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:content-type; bh=Z/SOquxGxMsh70BmOlKj28kfvNa1f3Yiqvbl1WFvml0=; b=m4X8g08nn46eqMPmzAeq9SJJVGeoQ4x60bRuxE+OtbNKTXkk+psw+chfnFdx2+/CDU SlbbLRmcQJOA6+kpANH9Sr8WPp/AMsK633ITQ8D4BxsJ7lUQnF72AwIx0X9K2r/BiaOb gGXSxOnuJVxVR9rVHQl5IDVPsMy376DedxEVpCwM+FIay2KuarY/X/5XrV5R96QDWu4l fRWpCjWvr1seE84TneVPR8cVnU+abNSOzxjs0dH8RkmG0TGC9jGZS0XFgm0u6Vb4jv0X JPsvUX+VXlj907Mn783/LrlfWD0/VzUJ0ffpb16AFnkmDYY/TRmjy9nzHkzsRyPnMpDM AbKQ== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr30533364yhl.65.1407085741551; Sun, 03 Aug 2014 10:09:01 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 3 Aug 2014 10:09:01 -0700 (PDT) Date: Sun, 3 Aug 2014 10:09:01 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yTiex20P2nVc-hsz7DG_AhijE0s Subject: [TLS] 0RTT? 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, 03 Aug 2014 17:09:05 -0000 Dear all, I think I came up with a decent idea for handling 0RTT handshakes, namely making resumption 0RTT, and doing a side rekeying. To see this work we assume that the usual resumption ticket gets set in the handshake, and determines the PMS. A resumption looks as follows: -The ticket -An anti-replay nonce: BLAH bytes -A refresh key: since we know what the server wants, we can provide a group it supports The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh key): data encrypted as usual under the old ciphersuite follows. (Note that we may have to include the entire Client Hello hashed: this is probably easier, except that the data goes in the Client Hello when using the current inclusion mechanism) On receiving this a server looks up the anti-replay nonce and checks it is fresh. To make this easier we include UTC time since the epoch ( midnight of 1 January 1970) and mandate some degree of synchronization and a window. To avoid tagging with clock drift we truncate some low order bits after adding a random small offset. If the nonce is not previously seem the server can send Application Data as normal. We now introduce a new handshake type: Rekey Finish, containing a new ticket and server key. CCS follows afterwards. These are sent encrypted. The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)). The big limitation is ticket keys are going to need rotation. This also doesn't address the desire to put extra data in DNS to give some degree of forward secrecy, but I don't think you can change DNS that quickly without some problems. Furthermore, if we want rekeys without renegotiation, we can reuse Rekey Finish and add a Rekey Initiate handshake type that will send the client key. Open questions: how secure is this? We certainly need to hash the anti-replay nonce into the keys: is that all we need? (Not if we want to avoid attackers manipulating which method we use) Does noisy truncation work to prevent fingerprinting while reducing storage requirements? Sincerely, Watson Ladd From nobody Sun Aug 3 10:25:28 2014 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 1FDA41A0AFE for ; Sun, 3 Aug 2014 10:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=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 4OyCgbfwbxt9 for ; Sun, 3 Aug 2014 10:25:24 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AF91A0B00 for ; Sun, 3 Aug 2014 10:25:23 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id v10so5914683qac.26 for ; Sun, 03 Aug 2014 10:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q6jNw9HP1SFIkcxIo2fLgQv8zSUI0eSIEA0E3wBg/ko=; b=izJD69HaxcnvoMpq/WVQOfRAFskbmO3iATk3X/Y/el7l5Glv9OSJ/lBETNi+7e/CEI 3xBC1RPrxBvN9raPYjmr0ITkNAA7+UvjkqWIm076pAORdSiGw+tOp2PJamoNWVei/Sbt xhTP4buQtMLEZqMznhdJL0JllPnEnclOppu1ACX0S2tgn66cJBIAQcDfNzkfCJlnfuWe 4vrzEZh1q1yVtEx4pOWk60fcGUEZKXsoYTKj2KEF+u6jcogI2zqu6Wt0vBNoyWEQlkkt VFC3lYPGvKOSXmqqfl3smlL2thIk3OL2bIojOhk0xYzKa0uyGxKvLm5697O8tG87YYl6 3XHw== X-Received: by 10.229.225.131 with SMTP id is3mr29265959qcb.2.1407086723075; Sun, 03 Aug 2014 10:25:23 -0700 (PDT) Received: from [10.0.1.3] (pool-72-92-130-2.burl.east.myfairpoint.net. [72.92.130.2]) by mx.google.com with ESMTPSA id m20sm26839018qax.25.2014.08.03.10.25.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Aug 2014 10:25:21 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Sun, 3 Aug 2014 13:25:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1F069E66-C658-42F2-B334-AAC72F117F8C@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6IekJXBVk2DasmFCTGCSYuLBPc0 Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 03 Aug 2014 17:25:26 -0000 > The PMS that gets used is PMS_interim=3D HMAC(old_PMS, nonce || = refresh > key): data encrypted as usual under the old ciphersuite follows.=20 I guess I don=92t understand what this means. Is the new application = data encrypted under (a) the old MS? (b) a new MS derived from PMS_interim (and the old = randoms)?=20 >=20 > On receiving this a server looks up the anti-replay nonce and checks > it is fresh. To make this easier we include UTC time since the epoch ( > midnight of 1 January 1970) and mandate some degree of synchronization > and a window. To avoid tagging with clock drift we truncate some low > order bits after adding a random small offset. >=20 > If the nonce is not previously seem the server can send Application > Data as normal. >=20 > We now introduce a new handshake type: Rekey Finish, containing a new > ticket and server key. CCS follows afterwards. These are sent > encrypted. >=20 > The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)). >=20 > The big limitation is ticket keys are going to need rotation. This > also doesn't address the desire to put extra data in DNS to give some > degree of forward secrecy, but I don't think you can change DNS that > quickly without some problems. >=20 > Furthermore, if we want rekeys without renegotiation, we can reuse > Rekey Finish and add a Rekey Initiate handshake type that will send > the client key. >=20 > Open questions: how secure is this? We certainly need to hash the > anti-replay nonce into the keys: is that all we need? (Not if we want > to avoid attackers manipulating which method we use) Does noisy > truncation work to prevent fingerprinting while reducing storage > requirements? >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Aug 3 10:32:35 2014 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 9AB6D1A0AFE for ; Sun, 3 Aug 2014 10:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=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 F98xAgkyIA-b for ; Sun, 3 Aug 2014 10:32:31 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 378A51A0AF7 for ; Sun, 3 Aug 2014 10:32:31 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id t59so3786941yho.11 for ; Sun, 03 Aug 2014 10:32: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:content-type:content-transfer-encoding; bh=KnsSFqexSBwQ4Xk+TfSv/FV02U18pu36whVpDcdU/D4=; b=T9iZWRULugDOppKKGsAUW+mJZnrlkk2lvRJqgUPu1d5xXkinZNNzMpjZoPAiUd/yRK LNxYz2CVCYDumCO4cQFkhYdVZtUCWXUw0SC6aArcjKRuL7tHE42fYxguT6hzf+pVkhhc 1SgKlqIzD4OVfX+qQWz8FnEwFMeSYQT/fSGD8yivLUfR3mm0Ne4qLcLLKn+cNZYSdfyt 58vsR7MkDF5dBn03tl2TztOGmkPEDtIFWT3ppP2edMoe/aPpmeAMxx8wVBczaKOWIUFT njgD5UnEzbwFtorLd2P+BcuT/RB9ie4uttiQBmklZmxq/rZxNokccutst+M3AcbaLBaf mPyQ== MIME-Version: 1.0 X-Received: by 10.236.228.161 with SMTP id f31mr29407697yhq.44.1407087150414; Sun, 03 Aug 2014 10:32:30 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 3 Aug 2014 10:32:30 -0700 (PDT) In-Reply-To: <1F069E66-C658-42F2-B334-AAC72F117F8C@gmail.com> References: <1F069E66-C658-42F2-B334-AAC72F117F8C@gmail.com> Date: Sun, 3 Aug 2014 10:32:30 -0700 Message-ID: From: Watson Ladd To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xB4kdp1-HdTaitOyWc3ah-oJMNU Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 03 Aug 2014 17:32:33 -0000 On Sun, Aug 3, 2014 at 10:25 AM, Karthikeyan Bhargavan wrote: > >> The PMS that gets used is PMS_interim=3D HMAC(old_PMS, nonce || refresh >> key): data encrypted as usual under the old ciphersuite follows. > > I guess I don=E2=80=99t understand what this means. Is the new applicatio= n data encrypted > under (a) the old MS? (b) a new MS derived from PMS_interim (and the old = randoms)? I was thinking new MS. > > >> >> On receiving this a server looks up the anti-replay nonce and checks >> it is fresh. To make this easier we include UTC time since the epoch ( >> midnight of 1 January 1970) and mandate some degree of synchronization >> and a window. To avoid tagging with clock drift we truncate some low >> order bits after adding a random small offset. >> >> If the nonce is not previously seem the server can send Application >> Data as normal. >> >> We now introduce a new handshake type: Rekey Finish, containing a new >> ticket and server key. CCS follows afterwards. These are sent >> encrypted. >> >> The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)). >> >> The big limitation is ticket keys are going to need rotation. This >> also doesn't address the desire to put extra data in DNS to give some >> degree of forward secrecy, but I don't think you can change DNS that >> quickly without some problems. >> >> Furthermore, if we want rekeys without renegotiation, we can reuse >> Rekey Finish and add a Rekey Initiate handshake type that will send >> the client key. >> >> Open questions: how secure is this? We certainly need to hash the >> anti-replay nonce into the keys: is that all we need? (Not if we want >> to avoid attackers manipulating which method we use) Does noisy >> truncation work to prevent fingerprinting while reducing storage >> requirements? >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > --=20 "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Aug 3 13:22:10 2014 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 5ED9A1ABD17 for ; Sun, 3 Aug 2014 13:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=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 Q6_JZn-BykW8 for ; Sun, 3 Aug 2014 13:22:07 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA261A0303 for ; Sun, 3 Aug 2014 13:22:06 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id w62so6694472wes.8 for ; Sun, 03 Aug 2014 13:22: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:content-type; bh=xBMIfHq0O0Gv/AbIb1wUDFL/qnyq2FAm8/P/oZb2aMY=; b=C+w8sBgqxOu+7tNMilpVJ67YmxfRn0dGefHgyg59I4AuJF/lImxSioH7qeDeZCAxwV sWhR4LbKf0R21zE/7n5vzozj51eWW1BdF46a2Sd5VwbqISL8ABQMZt4UaWs0okYntEfD /SiNrrhr6tmi3Zo21IaFJb7zHZKrSIfDYJ0lINdmFLtMKxHXsde0EmgGSXKyNS6Zx0sM gNTgxQPbq3OMQNcGnU80p7dLKdB3eTZo0r410NEY7tD7UBt2V4cAJFUnIi7qsvwzCszH ur3SKQ5y3zTshPO9MoNosWhM2hFAf0CDn0Y99kZibuKFYX2KT95ufKpuBL23FilWJBfP OyMw== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr25853488wjb.59.1407097325197; Sun, 03 Aug 2014 13:22:05 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Sun, 3 Aug 2014 13:22:05 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Aug 2014 13:22:05 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2R2on6Th49vKpMrvttPEYznmP5A Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 03 Aug 2014 20:22:08 -0000 This reads a like a halfway between the proposed 0RTT handshake and resumption. The advantage here I'm guessing being that this is resumption, which means that you bind to a specific previous session. However, I keep hearing that the main benefit of resumption is that it doesn't require a new DH operation. And yes, this is still important even with the higher performance EC provides. This relies on an old session, whereas the proposed 0RTT uses a DH share that is essentially public, so that it can be cached and shared (DNS, signaling). As far as security goes, I don't see any major issues with this. The initial round of application data is going to be as well protected as the previous session was. As long as you aren't able to choose a different cipher suite to what was previously used, and I can't see why you would want to even contemplate allowing that. Why do you need a new message? Since you are using DH, you could just use the remainder of the 1RTT handshake structure with ServerKeyExchange. You could, I suppose eliminate the authentication messages in order to rely on the previous session. If the fallback story when the ticket/nonce/share is bad is the existing regular handshake, then this is quite close to the proposed 0RTT mode. With a few differences in terms of the first flight keys are derived and their lifecycle. On Aug 3, 2014 10:09 AM, "Watson Ladd" wrote: > > Dear all, > > I think I came up with a decent idea for handling 0RTT handshakes, > namely making resumption 0RTT, and doing a side rekeying. > > To see this work we assume that the usual resumption ticket gets set > in the handshake, and determines the PMS. A resumption looks as > follows: > > -The ticket > -An anti-replay nonce: BLAH bytes > -A refresh key: since we know what the server wants, we can provide a > group it supports > > The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh > key): data encrypted as usual under the old ciphersuite follows. (Note > that we may have to include the entire Client Hello hashed: this is > probably easier, except that the data goes in the Client Hello when > using the current inclusion mechanism) > > On receiving this a server looks up the anti-replay nonce and checks > it is fresh. To make this easier we include UTC time since the epoch ( > midnight of 1 January 1970) and mandate some degree of synchronization > and a window. To avoid tagging with clock drift we truncate some low > order bits after adding a random small offset. > > If the nonce is not previously seem the server can send Application > Data as normal. > > We now introduce a new handshake type: Rekey Finish, containing a new > ticket and server key. CCS follows afterwards. These are sent > encrypted. > > The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)). > > The big limitation is ticket keys are going to need rotation. This > also doesn't address the desire to put extra data in DNS to give some > degree of forward secrecy, but I don't think you can change DNS that > quickly without some problems. > > Furthermore, if we want rekeys without renegotiation, we can reuse > Rekey Finish and add a Rekey Initiate handshake type that will send > the client key. > > Open questions: how secure is this? We certainly need to hash the > anti-replay nonce into the keys: is that all we need? (Not if we want > to avoid attackers manipulating which method we use) Does noisy > truncation work to prevent fingerprinting while reducing storage > requirements? > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Sun Aug 3 19:43:23 2014 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 201401B2816 for ; Sun, 3 Aug 2014 19:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_46=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 OJUconVrI1QU for ; Sun, 3 Aug 2014 19:43:20 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C5D1B2815 for ; Sun, 3 Aug 2014 19:43:20 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so3851875ykp.29 for ; Sun, 03 Aug 2014 19:43:19 -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-type; bh=iepItd4wwIuirDzpDGq+58dURBdv7YVVjo47z9UaqR4=; b=ZlD9KUhClBR9JlRqI9k3EPAP8Sbia5VSSYiCLQphlxDfYgaR8evkyHpXbOKm5UrGN6 m4Y4efCNDaCOAzjfo4UzpwxQW25LKcy5KSR+NVYvcL5AlHYqrRhQogrpo6NaEqYR4ttQ D/p3r+Ua7Z2ctATVUeve9gsvFUGEpFFVy3D2jk9hzwMYRJcz0OUZae3IyIcq70r5WjvK UF8WndHLeWqQ1pJ8vuJxUGhO/rVOIOYAzORAsYI5JuspVycmxzIDmAORY34Hpu4bhtQq AHM08q8p8YI7xcS6el2kA95gFT3CPM0fU/xcDrKYB+7oD466tWGVa69ouYwRDGA/EWzA WGcw== MIME-Version: 1.0 X-Received: by 10.236.10.66 with SMTP id 42mr34174107yhu.68.1407120199309; Sun, 03 Aug 2014 19:43:19 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 3 Aug 2014 19:43:19 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Aug 2014 19:43:19 -0700 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QROQGSIrGfXFvlb7IOjCfNIS_Tk Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 04 Aug 2014 02:43:22 -0000 On Sun, Aug 3, 2014 at 1:22 PM, Martin Thomson wrote: > This reads a like a halfway between the proposed 0RTT handshake and > resumption. The advantage here I'm guessing being that this is > resumption, which means that you bind to a specific previous session. > > However, I keep hearing that the main benefit of resumption is that it > doesn't require a new DH operation. And yes, this is still important > even with the higher performance EC provides. So I was going to make rekey optional. This wasn't very clear in my original email. > > This relies on an old session, whereas the proposed 0RTT uses a DH > share that is essentially public, so that it can be cached and shared > (DNS, signaling). That has costs with key rotation and administrative version. Maybe those aren't so bad. But I would like to see resumption be 0RTT also: right now it is 2RTT in TLS 1.2. > > As far as security goes, I don't see any major issues with this. The > initial round of application data is going to be as well protected as > the previous session was. As long as you aren't able to choose a > different cipher suite to what was previously used, and I can't see > why you would want to even contemplate allowing that. I don't think you are qualified to say that, and the reasoning is fallacious. You need to mutter something about PRF distinguishing and collisions, and ideal functionality and simulation. (In particular if I didn't mix in the old PMS, there would be an attack) > > Why do you need a new message? Since you are using DH, you could just > use the remainder of the 1RTT handshake structure with > ServerKeyExchange. You could, I suppose eliminate the authentication > messages in order to rely on the previous session. > > If the fallback story when the ticket/nonce/share is bad is the > existing regular handshake, then this is quite close to the proposed > 0RTT mode. With a few differences in terms of the first flight keys > are derived and their lifecycle. It probably is, but I think I missed the email where that was discussed. The design space is constrained enough I think we are converging on a very similar solution. > > On Aug 3, 2014 10:09 AM, "Watson Ladd" wrote: >> >> Dear all, >> >> I think I came up with a decent idea for handling 0RTT handshakes, >> namely making resumption 0RTT, and doing a side rekeying. >> >> To see this work we assume that the usual resumption ticket gets set >> in the handshake, and determines the PMS. A resumption looks as >> follows: >> >> -The ticket >> -An anti-replay nonce: BLAH bytes >> -A refresh key: since we know what the server wants, we can provide a >> group it supports >> >> The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh >> key): data encrypted as usual under the old ciphersuite follows. (Note >> that we may have to include the entire Client Hello hashed: this is >> probably easier, except that the data goes in the Client Hello when >> using the current inclusion mechanism) >> >> On receiving this a server looks up the anti-replay nonce and checks >> it is fresh. To make this easier we include UTC time since the epoch ( >> midnight of 1 January 1970) and mandate some degree of synchronization >> and a window. To avoid tagging with clock drift we truncate some low >> order bits after adding a random small offset. >> >> If the nonce is not previously seem the server can send Application >> Data as normal. >> >> We now introduce a new handshake type: Rekey Finish, containing a new >> ticket and server key. CCS follows afterwards. These are sent >> encrypted. >> >> The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)). >> >> The big limitation is ticket keys are going to need rotation. This >> also doesn't address the desire to put extra data in DNS to give some >> degree of forward secrecy, but I don't think you can change DNS that >> quickly without some problems. >> >> Furthermore, if we want rekeys without renegotiation, we can reuse >> Rekey Finish and add a Rekey Initiate handshake type that will send >> the client key. >> >> Open questions: how secure is this? We certainly need to hash the >> anti-replay nonce into the keys: is that all we need? (Not if we want >> to avoid attackers manipulating which method we use) Does noisy >> truncation work to prevent fingerprinting while reducing storage >> requirements? >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sun Aug 3 20:11:35 2014 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 021C81A00C2 for ; Sun, 3 Aug 2014 20:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 E7gGuvBwp4hV for ; Sun, 3 Aug 2014 20:11:28 -0700 (PDT) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 909801A00BE for ; Sun, 3 Aug 2014 20:11:27 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so6985913wgh.35 for ; Sun, 03 Aug 2014 20:11:26 -0700 (PDT) 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-type; bh=a+DeVbyDvq7DF89ATpUUVrqL+RGlqOJWuCWMxrhK3Rw=; b=AjOJb26ejsJHfMMh0/NCPncAJ3HyIRj8YYPUmAqfGlmt4oXiUV5d8PasedocXmyN5Y u52z6YUb3N99y3h3QWA5nVxdUM76cqNTdc8hpvSKCSXIqilmn2iQ++YCxQJyp+C2gzif 9QX3oodB+CErtfmPbHMWKlkhSJMc0PSJJFRMo4L8QMyIZaVsbzTuQyU0+WgHBEtWLmN3 kOBq/6NkCJhfuiFODsUS7S3i0FN1xA2X8avDyAyRGfqNuz6Kl85s1zAy16UqJOJ4S4mC l8Q6qa0h08iTJgr809YK/3Fy7PJIN5b1NioQ/geZ45Pm0SnKumnVXi5zXt7Lcghxp/vu 7/vQ== X-Gm-Message-State: ALoCoQkRxTDdrpHzRoorDuIpWw5TE5a/G1jj/0ZpwdA1pZ8AChyYC2kojXgQWHArWaOajDycTtwI X-Received: by 10.180.98.163 with SMTP id ej3mr25143927wib.36.1407121886157; Sun, 03 Aug 2014 20:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 3 Aug 2014 20:10:46 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 3 Aug 2014 20:10:46 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=f46d0442877a2e39cb04ffc51836 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eC0bNfVyKz-CX_VstG1420xxA8M Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 04 Aug 2014 03:11:33 -0000 --f46d0442877a2e39cb04ffc51836 Content-Type: text/plain; charset=UTF-8 Watson, Interesting suggestion. It does seem like a good idea to allow 0-RTT with resumption, assuming we retain resumption but I'm not sure we really want to couple resumption and 0-RTT, since that would mean that there's no way to get 0-RTT first handshakes even when the server has some out-of-band way of publishing his key, such as in DNS or WebRTC SDP (this is a real issue for WebRTC, where we *do* have an out-of-band channel for signaling.) The basic property of 0-RTT is that the client can share a key with the server on the first message and that's compatible with both session resumption and a semi-static server DH key (See, for instance: http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-01#section-6.3, figure 5). It should be possible to design a 0-RTT mechanism that works for both. Also, I would also suggest that we separate out the exact design of the anti-replay mechanism from the question of whether 0-RTT and resumption go together. Generally, these mechanisms have some kind of scoping mechanism (e.g., a server-provided context string and a timestamp, as in Snap Start) and then a client-provided nonce. The details seem like something we can tune separately. It's also worth observing that if you encrypt the scoping values you can significantly reduce their privacy exposure, since only the target server gets them. Best, -Ekr On Sun, Aug 3, 2014 at 10:09 AM, Watson Ladd wrote: > Dear all, > > I think I came up with a decent idea for handling 0RTT handshakes, > namely making resumption 0RTT, and doing a side rekeying. > > To see this work we assume that the usual resumption ticket gets set > in the handshake, and determines the PMS. A resumption looks as > follows: > > -The ticket > -An anti-replay nonce: BLAH bytes > -A refresh key: since we know what the server wants, we can provide a > group it supports > > The PMS that gets used is PMS_interim= HMAC(old_PMS, nonce || refresh > key): data encrypted as usual under the old ciphersuite follows. (Note > that we may have to include the entire Client Hello hashed: this is > probably easier, except that the data goes in the Client Hello when > using the current inclusion mechanism) > > On receiving this a server looks up the anti-replay nonce and checks > it is fresh. To make this easier we include UTC time since the epoch ( > midnight of 1 January 1970) and mandate some degree of synchronization > and a window. To avoid tagging with clock drift we truncate some low > order bits after adding a random small offset. > > If the nonce is not previously seem the server can send Application > Data as normal. > > We now introduce a new handshake type: Rekey Finish, containing a new > ticket and server key. CCS follows afterwards. These are sent > encrypted. > > The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)). > > The big limitation is ticket keys are going to need rotation. This > also doesn't address the desire to put extra data in DNS to give some > degree of forward secrecy, but I don't think you can change DNS that > quickly without some problems. > > Furthermore, if we want rekeys without renegotiation, we can reuse > Rekey Finish and add a Rekey Initiate handshake type that will send > the client key. > > Open questions: how secure is this? We certainly need to hash the > anti-replay nonce into the keys: is that all we need? (Not if we want > to avoid attackers manipulating which method we use) Does noisy > truncation work to prevent fingerprinting while reducing storage > requirements? > > Sincerely, > Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d0442877a2e39cb04ffc51836 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Watson,

Interesting suggestion.

It does seem like a good idea to allow 0-RTT with resumpt= ion, assuming
we retain resumption but I'm not sure we really= want to couple resumption
and 0-RTT, since that would mean that there's no way to get 0-RTT = first
handshakes even when the server has some out-of-band way of= publishing
his key, such as in DNS or WebRTC SDP (this is a real issue for WebRTC= ,
where we *do* have an out-of-band channel for signaling.)
=

The basic property of 0-RTT is that the client can shar= e
a key with the server on the first message and that's compatible
with both session resumption and a semi-static server DH key
=
figure 5). It should be possible to design a 0-RTT mechanism that
works for both.


Also, I would= also suggest that we separate out the exact design of the
anti-replay mechanism from the question of whether 0-RTT and resumptio= n
go together. Generally, these mechanisms have some kind of scop= ing
mechanism (e.g., a server-provided context string and a times= tamp,
as in Snap Start) and then a client-provided nonce. The details seem
like something we can tune separately. It's also worth observi= ng that
if you encrypt the scoping values you can significantly r= educe their
privacy exposure, since only the target server gets them.
Best,
-Ekr




On Sun,= Aug 3, 2014 at 10:09 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear all,

I think I came up with a decent idea for handling 0RTT handshakes,
namely making resumption 0RTT, and doing a side rekeying.

To see this work we assume that the usual resumption ticket gets set
in the handshake, and determines the PMS. A resumption looks as
follows:

-The ticket
-An anti-replay nonce: BLAH bytes
-A refresh key: since we know what the server wants, we can provide a
group it supports

The PMS that gets used is PMS_interim=3D HMAC(old_PMS, nonce || refresh
key): data encrypted as usual under the old ciphersuite follows. (Note
that we may have to include the entire Client Hello hashed: this is
probably easier, except that the data goes in the Client Hello when
using the current inclusion mechanism)

On receiving this a server looks up the anti-replay nonce and checks
it is fresh. To make this easier we include UTC time since the epoch (
midnight of 1 January 1970) and mandate some degree of synchronization
and a window. To avoid tagging with clock drift we truncate some low
order bits after adding a random small offset.

If the nonce is not previously seem the server can send Application
Data as normal.

We now introduce a new handshake type: Rekey Finish, containing a new
ticket and server key. CCS follows afterwards. These are sent
encrypted.

The new PMS will be HMAC(PMS_interim, ECDH(server, client keys)).

The big limitation is ticket keys are going to need rotation. This
also doesn't address the desire to put extra data in DNS to give some degree of forward secrecy, but I don't think you can change DNS that quickly without some problems.

Furthermore, if we want rekeys without renegotiation, we can reuse
Rekey Finish and add a Rekey Initiate handshake type that will send
the client key.

Open questions: how secure is this? We certainly need to hash the
anti-replay nonce into the keys: is that all we need? (Not if we want
to avoid attackers manipulating which method we use) Does noisy
truncation work to prevent fingerprinting while reducing storage
requirements?

Sincerely,
Watson Ladd

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

--f46d0442877a2e39cb04ffc51836-- From nobody Sun Aug 3 20:13:23 2014 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 9B93A1A00BE for ; Sun, 3 Aug 2014 20:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 BzVpXbtVDzkR for ; Sun, 3 Aug 2014 20:13:16 -0700 (PDT) Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 728621A00BB for ; Sun, 3 Aug 2014 20:13:16 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so6951634wes.23 for ; Sun, 03 Aug 2014 20:13:15 -0700 (PDT) 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-type; bh=VC8iqDzLQUr9zkjPdeGz1213jVbdJsjFwDdDQTrJfbE=; b=ldXyVQRwoVHtkjY/rdGtcjWyUtLwMCe0DJThtXuuLjIvB2aPBQZSDaZZTV2xy7FAJO vOxtjaQLlbyU0pPskaAteOkStamT3QFj6O6AVb/Rv8rX3mqcs81xDTDPMstyBRPdR8Hm 336YNw7/3bYbWyVRuAL25rzGCh+wFpjh7MsVlJ5d9jyHAmq85AXGl3hxNNJIdGB7rEGi pVzFHKmWo+dAaY55qlpMmfg4EDyxyKQmsy7Lt7X0mqfJgnHGfnaXkGM//4yopl2xnd9n n60r88fzqrDH/LWtqkOsH0rq6ULx/j37yvcMOZ3jx3onspMPTR8sc/PaJA9m019dcRuw WkXg== X-Gm-Message-State: ALoCoQmoJ+ehcHV1nAww8E3ct711UJtn18QSykOQsacNvJYJe8w18dnvpVcGJqVegCUGADMaeDAQ X-Received: by 10.180.39.34 with SMTP id m2mr25250179wik.80.1407121994972; Sun, 03 Aug 2014 20:13:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 3 Aug 2014 20:12:34 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 3 Aug 2014 20:12:34 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1134b5b8abe0f704ffc51e76 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dzu3FxzW5Kr73nTCo9TVjVNrRu0 Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 04 Aug 2014 03:13:21 -0000 --001a1134b5b8abe0f704ffc51e76 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 3, 2014 at 7:43 PM, Watson Ladd wrote: > On Sun, Aug 3, 2014 at 1:22 PM, Martin Thomson > wrote: > > This reads a like a halfway between the proposed 0RTT handshake and > > resumption. The advantage here I'm guessing being that this is > > resumption, which means that you bind to a specific previous session. > > > > However, I keep hearing that the main benefit of resumption is that it > > doesn't require a new DH operation. And yes, this is still important > > even with the higher performance EC provides. > > So I was going to make rekey optional. This wasn't very clear in my > original email. > > > > > This relies on an old session, whereas the proposed 0RTT uses a DH > > share that is essentially public, so that it can be cached and shared > > (DNS, signaling). > > That has costs with key rotation and administrative version. Maybe > those aren't so bad. But I would like to see resumption be 0RTT also: > right now it is 2RTT in TLS 1.2. In TLS 1.2, I believe it's actually 1 RTT from the client's perspective: Client Server ClientHello --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data The client can send data on its second flight. -Ekr --001a1134b5b8abe0f704ffc51e76 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Aug 3, 2014 at 7:43 PM, Watson Ladd <watsonbladd@gmail.com>= wrote:
On Sun, Aug 3, 2014 at 1:22 PM, Martin Tho= mson <martin.thomson@gmail.c= om> wrote:
> This reads a like a halfway between the proposed 0RTT handshake and > resumption. =C2=A0The advantage here I'm guessing being that this = is
> resumption, which means that you bind to a specific previous session.<= br> >
> However, I keep hearing that the main benefit of resumption is that it=
> doesn't require a new DH operation. =C2=A0And yes, this is still i= mportant
> even with the higher performance EC provides.

So I was going to make rekey optional. This wasn't very clear in = my
original email.

>
> This relies on an old session, whereas the proposed 0RTT uses a DH
> share that is essentially public, so that it can be cached and shared<= br> > (DNS, signaling).

That has costs with key rotation and administrative version. Maybe those aren't so bad. But I would like to see resumption be 0RTT also: right now it is 2RTT in TLS 1.2.

In TLS 1.2= , I believe it's actually 1 RTT from the client's perspective:

=C2=A0 =C2=A0 =C2=A0 Client =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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Se= rver

=C2=A0 =C2=A0 =C2=A0 ClientHello =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=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=A0ServerHello
=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=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 [ChangeCipherSpec]
=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Finished
=C2=A0 =C2=A0 =C2=A0= [ChangeCipherSpec]
=C2=A0 =C2=A0 =C2=A0 Finished =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--------><= /div>
=C2=A0 =C2=A0 =C2=A0 Application Data =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0<-------> =C2=A0 =C2=A0 Application Data

The client can send data on its second flight.

-Ekr


--001a1134b5b8abe0f704ffc51e76-- From nobody Mon Aug 4 08:01:07 2014 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 A76CC1B2B38 for ; Mon, 4 Aug 2014 08:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 mowswMTi5TnM for ; Mon, 4 Aug 2014 08:01:03 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 709DD1B2B2E for ; Mon, 4 Aug 2014 08:01:01 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so5215050wiw.12 for ; Mon, 04 Aug 2014 08:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:date:references:to:message-id :mime-version; bh=9YqtXnvEiJO9ztnSJ8bgu6G79pse0tT0kyMf3PzQYjw=; b=JZAXgGo5zhMqvUST7QivIg+cnD67ZjcmcX4iIjIjgurJ/WV38yK1LE2bxTYiTPDiXC s0v6/Sacv0Od1czKv2ime4zVyMrUWsnrMbxYRoCq4Sz65EQ6RHsWWiq/r92ulMjsiko/ Wlx9RZ4Qks+C5K9fAWkeF7Yih/tZyRbWQMIALcZIr/k3KpqS/m2pa6D/Dz1HEcXudSua LBY0fuEfz2zroCTwWNj3UK9A5OibqQgTgYDI1ytGuLKV09h/we7MQF7F+CksUJi3m6wF dc4UUadAlOmtKqiWSQBeMQNouApnpPvdmD8YtFSU+f+jVeH9gRRHQYT5kQDHZ+4rvvv0 /xxA== X-Received: by 10.194.89.36 with SMTP id bl4mr5087153wjb.126.1407164456562; Mon, 04 Aug 2014 08:00:56 -0700 (PDT) Received: from [172.24.248.227] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id pj6sm44120716wjb.21.2014.08.04.08.00.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Aug 2014 08:00:56 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_0D23D663-7F8D-4B6E-BAC6-8233557527DA" Date: Mon, 4 Aug 2014 18:00:54 +0300 References: <20140804145704.23744.96965.idtracker@ietfa.amsl.com> To: "" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fBpOqpIsToe2EeHuIlCeQdvhZbM Subject: [TLS] Fwd: New Version Notification for draft-nir-tls-rfc4492bis-00.txt 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, 04 Aug 2014 15:01:05 -0000 --Apple-Mail=_0D23D663-7F8D-4B6E-BAC6-8233557527DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi At the meeting in Toronto, I volunteered to write a bis document for RFC = 4492 that will incorporate whatever new curves we decide to standardize = after getting recommendations from CFRG. This is the first effort. The text is almost word for word that of RFC = 4492, except for adding mention of TLS 1.2 and a few editorial changes. Yoav Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-nir-tls-rfc4492bis-00.txt > Date: August 4, 2014 at 5:57:04 PM GMT+3 > To: Yoav Nir , "Yoav Nir" >=20 >=20 > A new version of I-D, draft-nir-tls-rfc4492bis-00.txt > has been successfully submitted by Yoav Nir and posted to the > IETF repository. >=20 > Name: draft-nir-tls-rfc4492bis > Revision: 00 > Title: Elliptic Curve Cryptography (ECC) Cipher Suites = for Transport Layer Security (TLS) Versions 1.2 and Earlier > Document date: 2014-08-04 > Group: Individual Submission > Pages: 32 > URL: = http://www.ietf.org/internet-drafts/draft-nir-tls-rfc4492bis-00.txt > Status: = https://datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/ > Htmlized: http://tools.ietf.org/html/draft-nir-tls-rfc4492bis-00 >=20 >=20 > 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 Elliptic Curve > Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use = of > Elliptic Curve Digital Signature Algorithm (ECDSA) as a new > authentication mechanism. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_0D23D663-7F8D-4B6E-BAC6-8233557527DA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi

At the meeting in Toronto, I = volunteered to write a bis document for RFC 4492 that will incorporate = whatever new curves we decide to standardize after getting = recommendations from CFRG.

This is the first = effort. The text is almost word for word that of RFC 4492, except for = adding mention of TLS 1.2 and a few editorial = changes.

Yoav

Begin forwarded = message:

From: = internet-drafts@ietf.org
<= /span>
Subject: = New Version = Notification for = draft-nir-tls-rfc4492bis-00.txt
Date: August 4, 2014 at 5:57:04 PM = GMT+3
To: = Yoav Nir <ynir.ietf@gmail.com>, "Yoav = Nir" <ynir.ietf@gmail.com>
=


A new version of I-D, = draft-nir-tls-rfc4492bis-00.txt
has been successfully submitted by = Yoav Nir and posted to the
IETF repository.

Name: = draft-nir-tls-rfc4492bis
Revision: 00
Title: Elliptic = Curve Cryptography (ECC) Cipher Suites for Transport Layer Security = (TLS) Versions 1.2 and Earlier
Document date: = 2014-08-04
Group: Individual = Submission
Pages: 32
URL: =            http://www.ietf.org/internet-drafts/draft-nir-tls-rfc4492bis-00.txt=
Status:         https:= //datatracker.ietf.org/doc/draft-nir-tls-rfc4492bis/
Htmlized: =       http://too= ls.ietf.org/html/draft-nir-tls-rfc4492bis-00


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 Elliptic Curve
  Diffie-Hellman = (ECDH) key agreement in a TLS handshake and the use of
=   Elliptic Curve Digital Signature Algorithm (ECDSA) as a = new
  authentication mechanism.




Please = note that it may take a couple of minutes from the time of = submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF = Secretariat


= --Apple-Mail=_0D23D663-7F8D-4B6E-BAC6-8233557527DA-- From nobody Mon Aug 4 10:54:23 2014 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 44AAA1A00AB for ; Mon, 4 Aug 2014 10:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6s3yUEOnDwtp for ; Mon, 4 Aug 2014 10:54:19 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EEA41A00A8 for ; Mon, 4 Aug 2014 10:54:19 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so5531911wiv.13 for ; Mon, 04 Aug 2014 10:54:18 -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-type; bh=WiUTwjMnUCfKA3s+rvxRvpAYMP73VMAH+8yzKuynInQ=; b=CtlH7GNXnOLI3UoTM0zbsYKv4T5v6SdqGpHC1yrmTDOEXe/kVqhJ7Lqb7rn2l4UGfz r9/7OMWKOV3cS1/oumfBt0OgLmc9DBjIZFiQBqPpRy04cfaAsjtpyKrJE0hHJd37vHJr ZUTazbLjvx0p6/h3Cvk5ANWpJc6ruhDqCnP0K02hxG5kWwRiPD2qF9Ii8GkdepicMl7j /dVgX9325EmAwUW/EvtYkxWdLRV6wFJt1dLIKRx5KNr3Ma5xkImELoeJN5ysHxHxOKTO bxW2f7IAoMwswkcSq84KTi/rhn0lYl9KI07cEZE9An4lwhk5lOdQGWZoPt0rrv25aohz veEw== MIME-Version: 1.0 X-Received: by 10.194.185.238 with SMTP id ff14mr34275634wjc.9.1407174857919; Mon, 04 Aug 2014 10:54:17 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Mon, 4 Aug 2014 10:54:17 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Aug 2014 10:54:17 -0700 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r2ehA6JyJy6e4jbHJwDQRI9-mCk Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 04 Aug 2014 17:54:21 -0000 On 3 August 2014 19:43, Watson Ladd wrote: > That has costs with key rotation and administrative version. Maybe > those aren't so bad. But I would like to see resumption be 0RTT also: > right now it is 2RTT in TLS 1.2. One thing I like with your proposal is that it looks a lot like the 0RTT proposal, but with a different key derivation path that avoids the "expensive" operation. If the rekeying is optional it diverges some, but no so badly. I see the following choices for a server that receives a handshake in this form: a. Regarding the data, the server can accept the data or not b. Regarding the keying material, the server can continue to use the indicated "master secret", or it can request that a new DH exchange be completed ** Here we could also enable other options, like having the server offer a backwards reference for authentication, or maybe you can renegotiated ciphersuite... I think that would be unnecessary complexity; if you continue based on the previous session, then I'd prefer not allowing anything to change about the session; if you want to change anything, the server can re-run a full handshake. I think that the choice regarding the data is largely orthogonal to the choice regarding the keying material. These seem to be the most relevant choices: 1. accept the data and keys, continue with the provided keys 2. reject the data, but continue with the provided keys 3. accept the data, but re-run the handshake 4. reject the data and re-run the handshake The two options being what is new here. The proposed 0RTT mode allows the latter options only. The case where the server rejects the data is a little odd, but it might be that the server doesn't want to do nonce-checking; and it is closest to the 1.2 resumption handshake. From nobody Mon Aug 4 14:01:09 2014 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 31DCB1A0320 for ; Mon, 4 Aug 2014 14:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 UfwGQ09wUusV for ; Mon, 4 Aug 2014 14:01:05 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 66BB51A0100 for ; Mon, 4 Aug 2014 14:01:04 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s74L12tY005596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Aug 2014 23:01:02 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Mon, 4 Aug 2014 23:01:02 +0200 (CEST) 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: <20140804210102.706EA1ADEE@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KgFq5h6gcriBCN_ZaUFx_Wly1Ok Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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: Mon, 04 Aug 2014 21:01:08 -0000 Watson Ladd wrote: > > I think I came up with a decent idea for handling 0RTT handshakes, > namely making resumption 0RTT, and doing a side rekeying. These idea(s) seem to based on a number of extremely optimistic assumptions that have zero chance to get airborne in many usage scenarios. The "regular" TLS session resumption means that client announces a TLS session ID in ClientHello and server looks up that session ID in its own cache for a match. If there is no match, a regular TLS full handshake proceeds. 0RTT is a no-go for a huge number of existing apps which do not perform any fancy reconnect fallbacks at the application level (closing the previous connection, opening a new connection and starting a new handshake from scratch while requesting different handshake characteristics this time). For the general case a 1RTT resumption is required, which can successfully perform a full handshake in case that resumption is not possible, without having to go through a connection/handshake failure. > > The big limitation is ticket keys are going to need rotation. This > also doesn't address the desire to put extra data in DNS to give some > degree of forward secrecy, but I don't think you can change DNS that > quickly without some problems. The visibility of data DNS is another bold assumption that doesn't hold for a number of usage scenarios. It is pretty normal for company networks to run their own DNS universe internally, and provide accessibility to servers on the internet only through HTTP CONNECT proxies. In general, only these HTTP proxies have access to both DNS universes (internet and internal). I remember when Java applets became popular for use with online brokers ~17 years ago, and lots of these applets crashed and burned behind HTTP CONNECT proxies. The browser had no problem connecting, but the applets choked on hostnames that didn't resolve. The workaround was to add the brokers web server hostname with an arbitrary ipv4 address (1.2.3.4) to the local host file so that the Java applet would get a(n obviously useless) response from gethostbyname() and be happy. -Martin From nobody Mon Aug 4 18:52:34 2014 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 8ECB61A0AE2 for ; Mon, 4 Aug 2014 18:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1DgD-P_rMW-o for ; Mon, 4 Aug 2014 18:52:31 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E72D21A0AD9 for ; Mon, 4 Aug 2014 18:52:30 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so190937ykq.35 for ; Mon, 04 Aug 2014 18:52: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:content-type; bh=I+nPrODDyjUPmBkWaHJHePb/bAP3EN0pc0EhXogQeXg=; b=IkhyVmhMKxHNF/vbt3BWP/9Qqs8AW0oU7w51JRghXFbvHPKJtf7ozROFPSypqwey6A Jpm83hIrBXB8BE77ArCpk1AuYz0ZDiCh7UW/4wA/wKQKJbpPVnXw+jYXRo/h+Efyc35G dYRWwn3jpuGuaYrfgT2Tci3LhXwvcGKol1V9rMzUPhXbHm4jQV1M1oAr2l7M67vVs9pP DcmrXBUYfN2e4O+bWi8VndTV249hEA0az/e++ze8/3B0qpp6kpTgX5ZKqP80EDrDvgBJ TYyCHUcAYGHKWP5fenvK1Tr2XkHwd9ctRgp4hgiAvvXFiITY/dCVAQc8rR2EKW1R4Z2M D76Q== MIME-Version: 1.0 X-Received: by 10.236.35.198 with SMTP id u46mr954836yha.54.1407203550292; Mon, 04 Aug 2014 18:52:30 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 4 Aug 2014 18:52:30 -0700 (PDT) In-Reply-To: <20140804210102.706EA1ADEE@ld9781.wdf.sap.corp> References: <20140804210102.706EA1ADEE@ld9781.wdf.sap.corp> Date: Mon, 4 Aug 2014 18:52:30 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WQOasVbPOJmirBiunlTitzyWk88 Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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, 05 Aug 2014 01:52:32 -0000 On Mon, Aug 4, 2014 at 2:01 PM, Martin Rex wrote: > Watson Ladd wrote: >> >> I think I came up with a decent idea for handling 0RTT handshakes, >> namely making resumption 0RTT, and doing a side rekeying. > > > These idea(s) seem to based on a number of extremely optimistic > assumptions that have zero chance to get airborne in many usage > scenarios. > > The "regular" TLS session resumption means that client announces > a TLS session ID in ClientHello and server looks up that session ID > in its own cache for a match. If there is no match, a regular > TLS full handshake proceeds. > > 0RTT is a no-go for a huge number of existing apps which do not > perform any fancy reconnect fallbacks at the application level > (closing the previous connection, opening a new connection and > starting a new handshake from scratch while requesting different > handshake characteristics this time). For the general case > a 1RTT resumption is required, which can successfully perform > a full handshake in case that resumption is not possible, > without having to go through a connection/handshake failure. I think we can handle this by thinking about fallback options more carefully. Certainly a resend can be done at the implementation level with the new handshake: this will cost latency, but it can be done. Sincerely, Watson Ladd From nobody Tue Aug 5 05:34:20 2014 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 BB2521A0194 for ; Tue, 5 Aug 2014 05:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 yPJPtcqsXyZi for ; Tue, 5 Aug 2014 05:34:16 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 22CEF1A017C for ; Tue, 5 Aug 2014 05:34:15 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s75CYDeu019037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 5 Aug 2014 14:34:13 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Tue, 5 Aug 2014 14:34:13 +0200 (CEST) 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: <20140805123413.142131ADEF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9H8SZo_2AxiHcflL-rJ8_zCASZ0 Cc: "tls@ietf.org" Subject: Re: [TLS] 0RTT? 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: Tue, 05 Aug 2014 12:34:19 -0000 Watson Ladd wrote: > Martin Rex wrote: > > Watson Ladd wrote: > >> > >> I think I came up with a decent idea for handling 0RTT handshakes, > >> namely making resumption 0RTT, and doing a side rekeying. > > > > > > These idea(s) seem to based on a number of extremely optimistic > > assumptions that have zero chance to get airborne in many usage > > scenarios. > > > > The "regular" TLS session resumption means that client announces > > a TLS session ID in ClientHello and server looks up that session ID > > in its own cache for a match. If there is no match, a regular > > TLS full handshake proceeds. > > > > 0RTT is a no-go for a huge number of existing apps which do not > > perform any fancy reconnect fallbacks at the application level > > (closing the previous connection, opening a new connection and > > starting a new handshake from scratch while requesting different > > handshake characteristics this time). For the general case > > a 1RTT resumption is required, which can successfully perform > > a full handshake in case that resumption is not possible, > > without having to go through a connection/handshake failure. > > I think we can handle this by thinking about fallback options more > carefully. Certainly a resend can be done at the implementation level > with the new handshake: this will cost latency, but it can be done. For 0RTT this option does not exist. A multi-megabyte HTTP POST on top of a 0RTT TLS connection would waste lots of resources before even realizing that there is a problem and the bandwith was completely wasted. For other TLS extensions, a possibility to restart/reset the ongoing handshake could be defined so that TLS implementations could adopt and transparently provide it. But look at what gets pushed here in TLS WG instead: http://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00 which is a bogus proposal to panic and close the network connection on the server side and dump a genuine TLS problem entirely on the application caller of the clients TLS implementation. -Martin From nobody Wed Aug 6 04:43:21 2014 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 E56131A0048 for ; Wed, 6 Aug 2014 04:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, 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 J6p3b_acr9Gq for ; Wed, 6 Aug 2014 04:43:17 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 052741A0046 for ; Wed, 6 Aug 2014 04:43:16 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so1842451lab.34 for ; Wed, 06 Aug 2014 04:43: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-type:content-transfer-encoding; bh=/0YEku1Te149DbVmG9BD2RSn6zeQZFmcXKrIZ3H8ZE4=; b=ad1oE6/T54FpWV9vVRsea+8Q/djlV6UvDIjJrxwG18whS5dk4oFWNL8WUQApiIxQSi wSyhzz4oKNW7nOzkeuszaI4IgZ92J2nL6c7SfetITIHH6SZ3b9iKcSQqEGg4xn/g/hTE WWEaud7hFGTRjCN04oeq3bbQslZCEMeM/VI+L0WzHOKgxg/l5qzrETKtoJuCxpLfvLHt vSwJWS4mvPMLlCrzI2NV4s/7y1FbeYEvPczX67AiweGX/BIc3AF9JbwRk7h15hp9IZxu zF+ZM+g86RUUrFvbUxfzdPD3V9RqFZpSoUI16g6J/Bnqkae1H7DYV4CNKutliXGouPYC 0h9w== MIME-Version: 1.0 X-Received: by 10.112.225.7 with SMTP id rg7mr10036311lbc.52.1407325395234; Wed, 06 Aug 2014 04:43:15 -0700 (PDT) Received: by 10.112.16.70 with HTTP; Wed, 6 Aug 2014 04:43:15 -0700 (PDT) In-Reply-To: <53D9147B.1080203@nthpermutation.com> References: <201407281624.10986.davemgarrett@gmail.com> <53D9147B.1080203@nthpermutation.com> Date: Wed, 6 Aug 2014 13:43:15 +0200 Message-ID: From: =?UTF-8?Q?Henrik_Grubbstr=C3=B6m?= To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YzWkZ49yrEEY5ua12MIe_piWEJU Cc: tls@ietf.org Subject: Re: [TLS] PRF in 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, 06 Aug 2014 11:43:19 -0000 On Wed, Jul 30, 2014 at 5:51 PM, Michael StJohns w= rote: > On 7/28/2014 4:24 PM, Dave Garrett wrote: >> >> https://github.com/tlswg/tls13-spec/issues/26 >> [...] > I don't believe this is the right place to start asking the questions. > Instead, let's look at where the PRF is used and in what context, and the= n > figure out whether or not what we have is good enough. Agreed. [...] > So breaking it down: > > Is (1) secure enough to derive keys? The construct used in TLS is simil= ar > to the section 5.2 construct of NIST SP800-108. But the SP800 construct = has > one extra piece missing from this one - the L parameter which ensures tha= t > the key stream changes if the number of output bits change. There's also > expanded guidance on the context field - the equivalent values in TLS are > currently just the client and server random. I've got some issues with > that - see > http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and I > would add information about the types and lengths of the keys to be deriv= ed > from the key stream to the context. With those changes, a recursive base= d > HMAC PRDG at the heart of the KDF is probably sufficiently secure for key > derivation going forward. I'd like to hear from the people that rejected P_SHA256 for the AES256 suites in RFC 5289 (which instead use P_SHA384). I suspect that it is to avoid leaking the entire state of the PRF in the AES256 keys and/or to avoid correlation between the client-side and server-side keys. [...] > The requirements for (2) (key not available until later) argues that the = TLS > PRF has to continue to be built on a hash function unless the data signed= by > (2) changes. The discussion for (4) suggests that we can't just say that > SHA256 will always be the value. Agreed. /grubba --=20 Henrik Grubbstr=C3=B6m grubba@grubba.= org Roxen Internet Software AB grubba@roxen.com From nobody Wed Aug 6 11:58:02 2014 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 656231B27D6 for ; Wed, 6 Aug 2014 11:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] 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 XM_1Tm89x4tf for ; Wed, 6 Aug 2014 11:57:56 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C5D1B27CB for ; Wed, 6 Aug 2014 11:57:56 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j15so2992956qaq.29 for ; Wed, 06 Aug 2014 11:57:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EFmXiWPwm0lseu7BQAIy/SJj0gJ2eMnYacH+BZU6jW8=; b=StY8CuDqtRjcd5t3pZgwaX7BitbROSiWvBurV51Cr+wRM+SrNjUvkAFEZ5TPCzsbrp pOOX4nuIgYxWLKuiMGsX2exFhZ69dDxOhtHtEOUwVbH3jJAsxAUpOfqTr+wOUzJWyjd1 zJZZdUyLbbDAUQYQ1WKrRKbd9Fwbex4mzFpuPsHF/F/83EazzZXLCaTcvb+5LdF0I4Rc SEpB0JU+IeLJ0XClT/a78hAeVQvel1+7OUavKti2ASyV8AHQhAEuK7TB1jRsHchxFHGx AKIwdbQTafFjQwe0z4XBMkhUgHJiODVMFRyzztNt9x5YY50nMjakpy5Rz7tS+z/Rbw1D az8g== X-Gm-Message-State: ALoCoQk4vmg1lNdG8YGRhfB5DsJ+cgKFyJRppxAW+5UIzHhEo2IxzTGipCL/P5O8r/b7xCdDTYUB X-Received: by 10.140.49.77 with SMTP id p71mr5985587qga.86.1407351475531; Wed, 06 Aug 2014 11:57:55 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id 38sm1856421qgp.30.2014.08.06.11.57.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 11:57:55 -0700 (PDT) Message-ID: <53E27AB6.1080809@nthpermutation.com> Date: Wed, 06 Aug 2014 14:57:58 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?SGVucmlrIEdydWJic3Ryw7Zt?= References: <201407281624.10986.davemgarrett@gmail.com> <53D9147B.1080203@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TbsqK3MDog5B8LU7piawMm8dCVA Cc: tls@ietf.org Subject: Re: [TLS] PRF in 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, 06 Aug 2014 18:57:58 -0000 On 8/6/2014 7:43 AM, Henrik Grubbström wrote: >> that - see >> >http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and I >> >would add information about the types and lengths of the keys to be derived >> >from the key stream to the context. With those changes, a recursive based >> >HMAC PRDG at the heart of the KDF is probably sufficiently secure for key >> >derivation going forward. > I'd like to hear from the people that rejected P_SHA256 for the AES256 > suites in RFC 5289 (which instead use P_SHA384). I suspect that it is > to avoid leaking the entire state of the PRF in the AES256 keys and/or > to avoid correlation between the client-side and server-side keys. I think this is actually not a question with respect to the KDF use of the PRF, but with the "PRF(k, HASH(handshake messages))" formation of the verify_data in the Finished messages. HMAC_SHAXXX (k, data) is XXX bits of strength secure, but SIGN (k, SHAXXX(data)) (which is really what the PRF is being used for here) is only XXX/2 bits of strength - or so I understand from the NIST key management special publication. That would place the strength of a suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and before. Mike From nobody Wed Aug 6 12:11:31 2014 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 82FDD1A00B0 for ; Wed, 6 Aug 2014 12:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 0EFv41nFSg8p for ; Wed, 6 Aug 2014 12:11:25 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABE71A008F for ; Wed, 6 Aug 2014 12:11:25 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s76JBMsK016676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 6 Aug 2014 21:11:22 +0200 (MEST) In-Reply-To: <53E27AB6.1080809@nthpermutation.com> To: Michael StJohns Date: Wed, 6 Aug 2014 21:11:22 +0200 (CEST) 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: <20140806191122.57BC61ADF5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3Qsu1aKlTnKpv49sFpBDWt_DIRQ Cc: tls@ietf.org Subject: Re: [TLS] PRF in 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: Wed, 06 Aug 2014 19:11:29 -0000 Michael StJohns wrote: [ Charset UTF-8 unsupported, converting... ] > On 8/6/2014 7:43 AM, Henrik Grubbstr=F6m wrote: > >> that - see > >> >http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, a= nd I > >> >would add information about the types and lengths of the keys to be d= erived > >> >from the key stream to the context. With those changes, a recursive = based > >> >HMAC PRDG at the heart of the KDF is probably sufficiently secure for= key > >> >derivation going forward. > > I'd like to hear from the people that rejected P_SHA256 for the AES256 > > suites in RFC 5289 (which instead use P_SHA384). I suspect that it is > > to avoid leaking the entire state of the PRF in the AES256 keys and/or > > to avoid correlation between the client-side and server-side keys. >=20 > I think this is actually not a question with respect to the KDF use of=20 > the PRF, but with the "PRF(k, HASH(handshake messages))" formation of=20 > the verify_data in the Finished messages. >=20 > HMAC_SHAXXX (k, data) is XXX bits of strength secure, but SIGN (k,=20 > SHAXXX(data)) (which is really what the PRF is being used for here) is=20 > only XXX/2 bits of strength - or so I understand from the NIST key=20 > management special publication. That would place the strength of a=20 > suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and=20 > before. The PRF output is not used for in a signature style fashion. The default signature algorithm (for combination with RSA) in TLSv1.2 is either (sha1,rsa) or (md5,rsa), and particularly the latter is ludicrously weak in comparison to the tlsv1.[01] (sha1+md5,rsa). The problem with the Finished message in TLSv1.2 is that it still truncates the PRF output to 12 bytes (96 bits). The HMAC rfc explictly says that one should not truncate to less than half the output size of the underlying hash function, so TLSv1.2 **should** have used Finished messages of at least 128 bits (16 octets) for a SHA256-based PRF, and at least 192 bits (24 octets) for a SHA384-based PRF. This is one of the TLSv1.2 goofs that should be fixed in TLSv1.3, btw. -Martin From nobody Wed Aug 6 13:10:50 2014 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 E40181A0198 for ; Wed, 6 Aug 2014 13:10: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00X0zu55spy0 for ; Wed, 6 Aug 2014 13:10:45 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE501A005C for ; Wed, 6 Aug 2014 13:10:44 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id e89so3368831qgf.3 for ; Wed, 06 Aug 2014 13:10:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=b18KzhxJM7QJTUC7MsKqT94Yye8Ap1/lgumpHjmz9aU=; b=X5AnWAhEERiUpuGMfDrRBXQNZcGAEIxjKjUSUDMYrPR/RhscVOuF43xtYHLTUGo1Wx YoNF4fgEsuOxVelpHDMUT1ElNTqsTd/3VQnUfuDBTYGPYw+dQa4s4n3UzbEQj2n9gbZL FvIOc26nWrbmKgWt/qsClxf0aNpVe/26DweHG3/4SIgx40qYZdBS7UynFeZgvikyyvVu 03cKtrGG0r50glrkGr/mzIop1SJevtPb8aXB0S3E1ywaKvakghe3HeGb3GQ3Am85P33f JTGfI0RVNH1tUvfnBoIznxnd7UbRbAoUHIb58qd7LFqQK64CRqxAT74uKrwo9MHIeK9z hL2g== X-Gm-Message-State: ALoCoQkJuDqz36WDJ64AB8KdWnLVNbmNx+YVh6MH+4lXKR0fiq7lQC2XUk6uwxnzz0RRF1nE2IxM X-Received: by 10.224.12.134 with SMTP id x6mr664795qax.1.1407355844112; Wed, 06 Aug 2014 13:10:44 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id t23sm2055632qge.13.2014.08.06.13.10.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Aug 2014 13:10:43 -0700 (PDT) Message-ID: <53E28BC6.6040208@nthpermutation.com> Date: Wed, 06 Aug 2014 16:10:46 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mrex@sap.com References: <20140806191122.57BC61ADF5@ld9781.wdf.sap.corp> In-Reply-To: <20140806191122.57BC61ADF5@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CfU8z3pqHb5yBtDb-bL4h4aMLEo Cc: tls@ietf.org Subject: Re: [TLS] PRF in 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, 06 Aug 2014 20:10:48 -0000 On 8/6/2014 3:11 PM, Martin Rex wrote: > Michael StJohns wrote: > [ Charset UTF-8 unsupported, converting... ] >> On 8/6/2014 7:43 AM, Henrik Grubbström wrote: >>>> that - see >>>>> http://tools.ietf.org/html/draft-stjohns-tls-tls13-crypto-infra-00, and I >>>>> would add information about the types and lengths of the keys to be derived >>>> >from the key stream to the context. With those changes, a recursive based >>>>> HMAC PRDG at the heart of the KDF is probably sufficiently secure for key >>>>> derivation going forward. >>> I'd like to hear from the people that rejected P_SHA256 for the AES256 >>> suites in RFC 5289 (which instead use P_SHA384). I suspect that it is >>> to avoid leaking the entire state of the PRF in the AES256 keys and/or >>> to avoid correlation between the client-side and server-side keys. >> I think this is actually not a question with respect to the KDF use of >> the PRF, but with the "PRF(k, HASH(handshake messages))" formation of >> the verify_data in the Finished messages. >> >> HMAC_SHAXXX (k, data) is XXX bits of strength secure, but SIGN (k, >> SHAXXX(data)) (which is really what the PRF is being used for here) is >> only XXX/2 bits of strength - or so I understand from the NIST key >> management special publication. That would place the strength of a >> suite with a PRF P_SHA256 at not greater than 128 bits for TLS1.2 and >> before. > The PRF output is not used for in a signature style fashion. > > The default signature algorithm (for combination with RSA) in > TLSv1.2 is either (sha1,rsa) or (md5,rsa), and particularly the > latter is ludicrously weak in comparison to the tlsv1.[01] (sha1+md5,rsa). > > The problem with the Finished message in TLSv1.2 is that it still > truncates the PRF output to 12 bytes (96 bits). The HMAC rfc explictly > says that one should not truncate to less than half the output size > of the underlying hash function, so TLSv1.2 **should** have used > Finished messages of at least 128 bits (16 octets) for a SHA256-based PRF, > and at least 192 bits (24 octets) for a SHA384-based PRF. > > This is one of the TLSv1.2 goofs that should be fixed in TLSv1.3, btw. I think you're still missing the point - the PRF *is* used as a signature function over a hash. If the PRF were used as an HMAC signature function over the raw handshake data, it would be as secure as the HMAC (which is 256 bits for SHA256) underlying the PRF, but since you're signing the hash of the handshake data, you've no more security than the collision resistance of the hash which is 128 bites for SHA256. The security of HMAC_SHA256 (key, SHA256 (data)) or PRF_SHA256(key, SHA256(data)) or ECDSA_521 (key, SHA256(data)) is no more secure than 128 bits because the security of SHA256(data) is no more secure than 128 bits for a signature function. See table 3 of http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf I may be confused about this, but I don't think I am. I think you're probably also right about the truncation issue for the finished message - but that's at least a little unclear because of the recursive nature of the PRF function. Mike > > -Martin > > From nobody Wed Aug 6 22:37:33 2014 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 995121A0AD1 for ; Wed, 6 Aug 2014 22:37:30 -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, 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 u7J9z7xjR6aP for ; Wed, 6 Aug 2014 22:37:29 -0700 (PDT) Received: from qmta06.emeryville.ca.mail.comcast.net (qmta06.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:56]) by ietfa.amsl.com (Postfix) with ESMTP id 16FD21A0ACE for ; Wed, 6 Aug 2014 22:37:29 -0700 (PDT) Received: from omta03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by qmta06.emeryville.ca.mail.comcast.net with comcast id bhNB1o0020b6N64A6hdUo1; Thu, 07 Aug 2014 05:37:28 +0000 Received: from [192.168.1.2] ([71.202.164.227]) by omta03.emeryville.ca.mail.comcast.net with comcast id bhdT1o00P4uhcbK8PhdUX0; Thu, 07 Aug 2014 05:37:28 +0000 Message-ID: <53E31097.5030800@brainhub.org> Date: Wed, 06 Aug 2014 22:37:27 -0700 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: tls@ietf.org X-Priority: 5 (Lowest) References: <20140806191122.57BC61ADF5@ld9781.wdf.sap.corp> <53E28BC6.6040208@nthpermutation.com> In-Reply-To: <53E28BC6.6040208@nthpermutation.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407389848; bh=aDd7K30T0/ytDbt4hld4sDojA+UVFiqjp1SpekB2JNg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EJDyXvjIerkmZ9/XcDJSXAjh0LgxKd7cD8/c7XqzQ5sRhOYfhQhhdmeU83XTwsi7Z Qn4z5zq/SMiSnPewtVakHDCCiRN5MMlo3NrO4Lqlbv+KeqGUiDC6VZPhq7Uk3ZfUNv O/mLtizvvg6cSSc7SUoo6t1IdeAHuAnYkub+VeQWZTU6GMmXfeRrPqqjC7nQbM3tiA /de5iFEq3QcG4MXbT9T7jV3mdkfKP82RW09RX2RBIZVs7UmL3If9jlzU5sBK7nNXnt bQpc77OWI5XeitA44QOhZwe3cxtTtyqFVn3xm6Bc6EazOahzZyTzdgIaX0+gieTZRx LHtvqRy5LfEWw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/txpi7RM3_Of32TBANZuj0qEZfUI Subject: Re: [TLS] PRF in 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, 07 Aug 2014 05:37:30 -0000 On 08/06/2014 01:10 PM, Michael StJohns wrote: > I think you're still missing the point - the PRF *is* used as a > signature function over a hash. If the PRF were used as an HMAC > signature function over the raw handshake data, it would be as secure as > the HMAC (which is 256 bits for SHA256) unneedsderlying the PRF, but since > you're signing the hash of the handshake data, you've no more security > than the collision resistance of the hash which is 128 bites for SHA256. For the hash function collision over a handshake to be a problem there should to be a setting in which a collision of the hash output value over *any* two handshakes poses a problem. Statements about *this* particular handshake still fall under MAC usage. This case seems to apply here because each peer is hashing "his" packets and that is the hash value that needs to match. From nobody Thu Aug 7 13:12:45 2014 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 390C51B2818 for ; Thu, 7 Aug 2014 13:12: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bBOCtltAyRp for ; Thu, 7 Aug 2014 13:12:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 64A691B2819 for ; Thu, 7 Aug 2014 13:12:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 539CEBE88 for ; Thu, 7 Aug 2014 21:12:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mwe-Amk82p0 for ; Thu, 7 Aug 2014 21:12:36 +0100 (IST) Received: from [10.87.48.11] (unknown [86.46.26.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CB4E6BE47 for ; Thu, 7 Aug 2014 21:12:36 +0100 (IST) Message-ID: <53E3DDB4.3070807@cs.tcd.ie> Date: Thu, 07 Aug 2014 21:12:36 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "tls@ietf.org" References: <20140807182654.9855.91935.idtracker@ietfa.amsl.com> In-Reply-To: <20140807182654.9855.91935.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140807182654.9855.91935.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-RQgwhEzeN86z3QhdSsCjwYSxfs Subject: [TLS] Fwd: ALPN Registry Expert 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, 07 Aug 2014 20:12:42 -0000 FYI. Someone was asking and Joe volunteered (thanks Joe!) S. -------- Forwarded Message -------- Subject: ALPN Registry Expert Date: Thu, 07 Aug 2014 11:26:54 -0700 From: IESG Secretary Reply-To: iesg@ietf.org To: iana@iana.org CC: iesg@ietf.org IANA, The IESG has approved Joe Salowey as the designated expert for the ALPN Registry. http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids Best regards, IESG Secretary From nobody Thu Aug 7 16:17:55 2014 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 62D7A1B28B7 for ; Thu, 7 Aug 2014 16:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.133 X-Spam-Level: *** X-Spam-Status: No, score=3.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 c8nn47LYz9W3 for ; Thu, 7 Aug 2014 16:17:52 -0700 (PDT) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.142.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F085E1B28A2 for ; Thu, 7 Aug 2014 16:17:51 -0700 (PDT) Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id 3BE2A3A6DD68; Thu, 7 Aug 2014 18:17:51 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id 210D43A6DCC4 for ; Thu, 7 Aug 2014 18:17:51 -0500 (CDT) Received: from [96.231.227.95] (port=58916 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XFWwP-0003Vx-PF for tls@ietf.org; Thu, 07 Aug 2014 18:17:50 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <67F42F2E-10D9-4E42-82CB-D7C43F5B630F@ieca.com> Date: Thu, 7 Aug 2014 19:17:45 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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.227.95 X-Exim-ID: 1XFWwP-0003Vx-PF X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:58916 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MUXKOfuvQaHsY4jRCPYatmUok6Y Subject: [TLS] wg minutes posted 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, 07 Aug 2014 23:17:53 -0000 Meeting minutes for the interim and to sessions @ IETF 90 have been = posted. Please send the chairs any comments (tls-chairs@tools.ietf.org) = by next Friday. Note that I uploaded the same file to both repos. = http://www.ietf.org/proceedings/interim/2014/07/20/tls/minutes/minutes-int= erim-2014-tls-2 http://www.ietf.org/proceedings/90/minutes/minutes-90-tls Thanks, spt= From nobody Fri Aug 8 03:25:57 2014 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 8F59D1B28D4 for ; Fri, 8 Aug 2014 03:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 gh0jU6eLPTVK for ; Fri, 8 Aug 2014 03:25:53 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDC511B287B for ; Fri, 8 Aug 2014 03:25:52 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id eb12so3920678oac.3 for ; Fri, 08 Aug 2014 03:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=bH1Kt1T5WGSFtiS1xJeJbUnGWQYNXTzYxetVS9j7M2E=; b=NctBFmpXiSWzjQbHjKY+e6/7JCsfHTfJmg/Q50vXGZAqXdYDTnyeSg3mNPlOHREUeJ Rw5DKOmUnZqFQoU7myWDY59CQbbMq+a4AQ/6w2T0s4+AuqSfZDhdDMg5A9xLoxDRT8gr Iks+9V0AYx2Qh7YXp3g9sSir6lEVUsPhGAimE= 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:content-type; bh=bH1Kt1T5WGSFtiS1xJeJbUnGWQYNXTzYxetVS9j7M2E=; b=MU69ZjI9lb2mKYSA9jYA7ntpJIuqeM8nkvJ0kl+mgMjDlj/W5mzpD2hFRocBe32Oet RoaVR25cthlXiCENAUOcs7lQfjTT+jJxWOyr8TW3oQFSbS16rdsu88GprKEfqiijdTCS aQ6j4Gs2ocV5/h01gLLEtm9XlYH1v5UI1wQUFX1+iiZAWzIlZmCqykCQ+jwYT8TTHgRB 8NkfbL6Pp/ryhEJz43byD3UwPBFT5z8OAJD1wGZpLU+9/r5FivSp9WoOB/UkBPdz/T42 3GduBNyKhEoo3qKXbEqx395EmMo7oWa0rpXBI97bKToEarzF7DzIn+ZfT+GA6uZ/4XCm Dm1A== X-Gm-Message-State: ALoCoQkgsjQ1hzKB/SOIrmwbOHpvyFtukNgIahmxMHlTqToPg/gXSptpIx0+dI8XUcWAsQr2n+BE MIME-Version: 1.0 X-Received: by 10.60.63.166 with SMTP id h6mr1818995oes.79.1407493551790; Fri, 08 Aug 2014 03:25:51 -0700 (PDT) Received: by 10.76.25.42 with HTTP; Fri, 8 Aug 2014 03:25:51 -0700 (PDT) X-Originating-IP: [2001:660:3013:3:f17e:3914:5512:a96e] In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738EFB2448@uxcn10-5.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C738EFB2448@uxcn10-5.UoA.auckland.ac.nz> Date: Fri, 8 Aug 2014 12:25:51 +0200 Message-ID: From: Alfredo Pironti To: "" Content-Type: multipart/alternative; boundary=001a11c21eae2dad8f05001ba148 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Be09Nv_kQGx0ZTHaY2xGfFd46Ck Subject: Re: [TLS] Encryption of TLS 1.3 content type 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, 08 Aug 2014 10:25:55 -0000 --001a11c21eae2dad8f05001ba148 Content-Type: text/plain; charset=UTF-8 I guess the benefit of encrypting the content type and hiding the message length are easier to appreciate when both features are deployed together. Yet, such features can be designed somewhat independently. I believe TLS holds an amenable place in the network stack where these traffic analysis countermeasures can be implemented. But, I stress, the application remains responsible for the privacy policy, and hence how these TLS features are used. For example, Tor abandoned doing authentication via TLS renegotiation* because, among other reasons, "TLS renegotiation to become rarer and rarer in the wild, making our own use stand out more" [2]. If TLS could be used to disguise, both in content type and in traffic shape, a renegotiation as normal application data, projects like Tor may benefit from it. * see "v2 handshake" vs "v3 handshake" in [1] [1] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.txt [2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/176-revising-handshake.txt --001a11c21eae2dad8f05001ba148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess the benefit of encrypting the content type an= d hiding the message length are easier to appreciate when both features are= deployed together. Yet, such features can be designed somewhat independent= ly.

I believe TLS holds an amenable place in the network stack where these = traffic analysis countermeasures can be implemented. But, I stress, the app= lication remains responsible for the privacy policy, and hence how these TL= S features are used.

For example, Tor abandoned doing authentication via TLS renegotiation* = because, among other reasons, "TLS renegotiation to become rarer and r= arer in the wild, making our own use stand out more" [2].
If TLS co= uld be used to disguise, both in content type and in traffic shape, a reneg= otiation as normal application data, projects like Tor may benefit from it.=
--001a11c21eae2dad8f05001ba148-- From nobody Fri Aug 8 05:52:33 2014 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 12E2C1B2B53 for ; Fri, 8 Aug 2014 05:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.332 X-Spam-Level: ** X-Spam-Status: No, score=2.332 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FSL_HELO_BARE_IP_2=2, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 u6ZneJuHSTko for ; Fri, 8 Aug 2014 05:52:29 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.170.18]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7361B2ACC for ; Fri, 8 Aug 2014 05:52:29 -0700 (PDT) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id 2A5683CC930CF; Fri, 8 Aug 2014 07:52:29 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway07.websitewelcome.com (Postfix) with ESMTP id 197B93CC930B1 for ; Fri, 8 Aug 2014 07:52:29 -0500 (CDT) Received: from [96.231.227.95] (port=64366 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XFjem-0008FX-DS for tls@ietf.org; Fri, 08 Aug 2014 07:52:28 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <28ABE4ED-F5E5-4561-9A47-27EE2551A15B@ieca.com> Date: Fri, 8 Aug 2014 08:52:26 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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.227.95 X-Exim-ID: 1XFjem-0008FX-DS X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:64366 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mwfHqxxL-XiT4ZBYzGuLK5GXbnw Subject: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 12:52:31 -0000 This is the working group last call for draft-ietf-tls-prohibiting-rc4-00: http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ Please send comments on this draft to the TLS list before August 23, 2014. J&S From nobody Fri Aug 8 06:01:06 2014 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 0049B1B2B58 for ; Fri, 8 Aug 2014 06:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 q767nlUHIo_x for ; Fri, 8 Aug 2014 06:01:03 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7EAE41B2ACC for ; Fri, 8 Aug 2014 06:01:03 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78D11tH006390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 15:01:01 +0200 (MEST) In-Reply-To: To: Alfredo Pironti Date: Fri, 8 Aug 2014 15:01:01 +0200 (CEST) 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: <20140808130101.959E11ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F-bVWQHi4RgbwQ_VhcqvPZRPOTc Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type 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, 08 Aug 2014 13:01:06 -0000 Alfredo Pironti wrote: > > For example, Tor abandoned doing authentication via TLS renegotiation* > because, among other reasons, "TLS renegotiation to become rarer and rarer > in the wild, making our own use stand out more" [2]. > If TLS could be used to disguise, both in content type and in traffic > shape, a renegotiation as normal application data, projects like Tor may > benefit from it. What you may have missed in the discussion: this is not about changing the presence, availability and visibility of renegotiation in TLSv1.2, TLSv1.1 and TLSv1.0, but exclusively about the visibility of the ContentInfo in a future TLSv1.3 _which_has_Renegotiation_removed_. -Martin From nobody Fri Aug 8 06:10:17 2014 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 42A2B1B2B5E for ; Fri, 8 Aug 2014 06:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 p7cNmYuG1Y6C for ; Fri, 8 Aug 2014 06:10:12 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89ECA1B2B58 for ; Fri, 8 Aug 2014 06:10:12 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id vb8so3998494obc.33 for ; Fri, 08 Aug 2014 06:10:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GFf+ZQAnTciLY8Ny7AGeb84ZzXNEU88Ug2+l7qxz7O4=; b=Rk9rRR6JyWUhcCRighRRsh0yz4c1emasRUalyT20av1+3jVT0oVQmLBSRLIjTp3urp zS2yHOj5A/NxQStUugGwD8Iq2trLJ5BDrgl7trv05MfsUrgdzGWwAFfVDkInDtRQ6V6o /+xz1NGGjCd/5m2TRqQ+5fHnSM5wzq8SBhl6E= 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-type; bh=GFf+ZQAnTciLY8Ny7AGeb84ZzXNEU88Ug2+l7qxz7O4=; b=SKmvnRBuCwHC+18jxH4aTuBjrzTEyOKhpvHbW2ipPPpEiCPcHOAf17xihtaMcfXHEH Ri1566UjlSrLN3u16jtOs/J3UQe0dsHBq2NY0P1JHvxgC1pyJTCbZuRNs7rECzr5VK9n lzWkyiKfQZyJ7SGYrO7W7mKChVxMoGa3QtYWQRk+6DT6N3EYvKxVBr0nioKQR21A3aqE bHOM7E+fNpmGT3O0lZqZdUVKSJ12/X9nfv8hZzyAOidoLuVoStTs2v3LsGkJq7I1B4Vs eqo6JZYCFmNSQ+pMSeLMpd+HvtL7qc4F095UIZLABQJS66zfzLo9+AjRp4YqYbymT2Da YUew== X-Gm-Message-State: ALoCoQlltf5sDjwmPqNF3RcAr8IlOSHxteRvE8voBdwDCnXXfTap0GdjHBVIr7nSu9DXBRnJYwFS MIME-Version: 1.0 X-Received: by 10.60.162.71 with SMTP id xy7mr30098712oeb.33.1407503411732; Fri, 08 Aug 2014 06:10:11 -0700 (PDT) Received: by 10.76.25.42 with HTTP; Fri, 8 Aug 2014 06:10:11 -0700 (PDT) X-Originating-IP: [2001:660:3013:3:f4ac:7052:e992:88bc] In-Reply-To: <20140808130101.959E11ADFC@ld9781.wdf.sap.corp> References: <20140808130101.959E11ADFC@ld9781.wdf.sap.corp> Date: Fri, 8 Aug 2014 15:10:11 +0200 Message-ID: From: Alfredo Pironti To: mrex@sap.com Content-Type: multipart/alternative; boundary=047d7b33c6eae07b8d05001dec39 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y7dnF4JDluXL0EXRNXBZSJ7x_LQ Cc: "" Subject: Re: [TLS] Encryption of TLS 1.3 content type 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, 08 Aug 2014 13:10:15 -0000 --047d7b33c6eae07b8d05001dec39 Content-Type: text/plain; charset=UTF-8 On Fri, Aug 8, 2014 at 3:01 PM, Martin Rex wrote: > Alfredo Pironti wrote: > > > > For example, Tor abandoned doing authentication via TLS renegotiation* > > because, among other reasons, "TLS renegotiation to become rarer and > rarer > > in the wild, making our own use stand out more" [2]. > > If TLS could be used to disguise, both in content type and in traffic > > shape, a renegotiation as normal application data, projects like Tor may > > benefit from it. > > What you may have missed in the discussion: this is not about changing > the presence, availability and visibility of renegotiation in TLSv1.2, > TLSv1.1 and TLSv1.0, but exclusively about the visibility of the > ContentInfo in a future TLSv1.3 _which_has_Renegotiation_removed_. > My understanding was that some form of re-keying or client-authentication may be provided instead. In the latter case, similar reasoning would apply. If the content type was encrypted, one could use different application data content type values to multiplex several application streams over one TLS connection. Alfredo > > -Martin > --047d7b33c6eae07b8d05001dec39 Content-Type: text/html; charset=UTF-8



On Fri, Aug 8, 2014 at 3:01 PM, Martin Rex <mrex@sap.com> wrote:
Alfredo Pironti wrote:
>
> For example, Tor abandoned doing authentication via TLS renegotiation*
> because, among other reasons, "TLS renegotiation to become rarer and rarer
> in the wild, making our own use stand out more" [2].
> If TLS could be used to disguise, both in content type and in traffic
> shape, a renegotiation as normal application data, projects like Tor may
> benefit from it.

What you may have missed in the discussion: this is not about changing
the presence, availability and visibility of renegotiation in TLSv1.2,
TLSv1.1 and TLSv1.0, but exclusively about the visibility of the
ContentInfo in a future TLSv1.3 _which_has_Renegotiation_removed_.

My understanding was that some form of re-keying or client-authentication may be provided instead. In the latter case, similar reasoning would apply.

If the content type was encrypted, one could use different application data content type values to multiplex several application streams over one TLS connection.

Alfredo



-Martin

--047d7b33c6eae07b8d05001dec39-- From nobody Fri Aug 8 06:36:39 2014 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 45BC31B28D0 for ; Fri, 8 Aug 2014 06:36:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 SpEHqyO91VkJ for ; Fri, 8 Aug 2014 06:36:33 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 48ED61B28AD for ; Fri, 8 Aug 2014 06:36:33 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78DaSjS009091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 15:36:28 +0200 (MEST) In-Reply-To: <28ABE4ED-F5E5-4561-9A47-27EE2551A15B@ieca.com> To: Sean Turner Date: Fri, 8 Aug 2014 15:36:28 +0200 (CEST) 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: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1PHsGga_wDviQhwul74USZC1t6c Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 13:36:36 -0000 Sean Turner wrote: > > This is the working group last call for draft-ietf-tls-prohibiting-rc4-00: > http://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/ > Please send comments on this draft to the TLS list before August 23, 2014. The RC4 cipher suites are still stronger than the EXPORT40 and EXPORT56 cipher suites, because for the latter, even one singular session can be successfully attack and *completely decrypted* in most cases, whereas the weaknesses currently known for RC4 cipher suites allow an attacker to recover only the plaintext equivalent of a static "disclosing authentication" (password or token) after 2^20+ TLS session. I therefore object to the Bullets 2 & 3 of section 2, (I'm OK with bullet 1): 2. Changes to TLS Because of the deficiencies noted in Section 1: o TLS clients MUST NOT include RC4 cipher suites in the ClientHello message. o TLS servers MUST NOT select an RC4 cipher suite when a TLS client sends such a cipher suite in the ClientHello message. o If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case. It should be left to the local policy of the server whether to agree to the use of an RC4 cipher suite rather than fail the connection. Servers should NEVER let the client-side ordering of cipher suites in ClientHello take precedence over the servers' preference, and RC4 cipher suites, similar to EXPORT40 and EXPORT56 cipher suites should never take precedence over stronger cipher suites that client and server have in common, just because they happen to appear earlier in the list in ClientHello. Especially in the Web, where access to information is often available through HTTP and HTTPS, a policy like the above (when adopted) would cause MORE communication to be performed in plaintext. There currently exists *no* known attack against the integrity protection of the TLS handshake, so this looks primarily like an attempt to promote "planned obsolesence", and a poor excuse for Microsoft to actively break interop with Windows XP (and potentially other installed base). -Martin From nobody Fri Aug 8 06:49:49 2014 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 D36551B29B9 for ; Fri, 8 Aug 2014 06:49:47 -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, 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 vjh6_gyZDlKx for ; Fri, 8 Aug 2014 06:49:45 -0700 (PDT) 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 6E0BB1B29E8 for ; Fri, 8 Aug 2014 06:49:45 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp> References: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Fri, 08 Aug 2014 14:49:39 +0100 To: tls@ietf.org Message-ID: <93462f83-ffff-4ad4-9a5b-89d3bbc1497c@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bdICSaZa1uG9XLqmGJFGc4cA-Lw Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 13:49:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 8 August 2014 14:36:28 BST, mrex@sap.com wrote: >The RC4 cipher suites are still stronger than the EXPORT40 and EXPORT56 >cipher suites, because for the latter, even one singular session can >be successfully attack and *completely decrypted* in most cases, >whereas >the weaknesses currently known for RC4 cipher suites allow an attacker >to recover only the plaintext equivalent of a static >"disclosing authentication" (password or token) after 2^20+ TLS >session. > > >I therefore object to the Bullets 2 & 3 of section 2, >(I'm OK with bullet 1): > > > > 2. Changes to TLS > > Because of the deficiencies noted in Section 1: > > o TLS clients MUST NOT include RC4 cipher suites in the ClientHello > message. > > o TLS servers MUST NOT select an RC4 cipher suite when a TLS client > sends such a cipher suite in the ClientHello message. > > o If the TLS client only offers RC4 cipher suites, the TLS server > MUST terminate the handshake. The TLS server MAY send the > insufficient_security fatal alert in this case. > > >It should be left to the local policy of the server whether to agree >to the use of an RC4 cipher suite rather than fail the connection. > >Servers should NEVER let the client-side ordering of cipher suites >in ClientHello take precedence over the servers' preference, >and RC4 cipher suites, similar to EXPORT40 and EXPORT56 cipher suites >should never take precedence over stronger cipher suites that client >and server have in common, just because they happen to appear earlier >in the list in ClientHello. > > >Especially in the Web, where access to information is often available >through HTTP and HTTPS, a policy like the above (when adopted) would >cause MORE communication to be performed in plaintext. > >There currently exists *no* known attack against the integrity >protection of the TLS handshake, so this looks primarily like an >attempt to promote "planned obsolesence", and a poor excuse for >Microsoft to actively break interop with Windows XP (and potentially >other installed base). (Apologies if this brief message comes across abrupt/rude, as I'm pressed for time right now. Please infer due respect.) Strongly disagree with your proposed change Martin, which fundamentally goes against the wide MUST NOT use RC4 consensus already confirmed in previous calls. I feel the draft language should stay just as it is. Given the discussions and meetings already supporting that consensus, I have to ask: why are you proposing this big change so late in support of *any* continued use of a known-weak cipher? XP is out of support and should definitely not be considered as a blocker. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJT5NVyGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6ZtIQAK2+xpNdI8wCIUQqTVzxSCoiYiAMpSWnsQZBAmGgSaj11nsCagRm r4GLMqqm9Q9m1Dx34QiPb1nVV+aFutQpAhn9j7ElSRLIYSOhl67H30CmJ/3MS/Wh fOnL44lHiMDtj1E/thWO+iW5UvMcg4VWfm0N5fV6o2vC4kOJ+alPvvcGt7oJ23ZQ lH4cBKzqcgofaYEP58vHPVC08I6LEAdMQ+XkBCovW38J1lJRtCRrnctjpPaFS9kB 615+te7vQChH0hFeFPZ7MgrXUh3btfc7PQPsKf4HtZ6FURrA9DQkk/zwdKWzLd3X uRTQO5NHdr/HwP2CStF9yP21CezewV46wpBH+QpJ/VGwbYdMdFWyrIy/bFwEZJuV 46Gz382d89Y3O0487V8+Emd1jl6ASZX1d96XYA0r/8QPlwMewUxljmfNBwl6oDam oIhwK7fFx3HL+R4DY+87beR00Y4lR+3DeRAlHj75c8bWKS6LVq4/FEg2RCAfn9DE Rk86eNVlfzFGtAj5LzCa3ROc8RzpycN91LMBPs6UuPLdTghDIzTIGkeQgnn+QAy1 hrs8VVak4m/pWR+lkn0/UcmZDlPtJmVTQDxfIO6DFokwk5gkvPNzngxdB/SNZ1FR vrr8z2XKTDajoeSgrKs5p7GxlWFJbxWnGjtvGfre5e/WiKzvmc4w1m+t =F8sW -----END PGP SIGNATURE----- From nobody Fri Aug 8 06:59:18 2014 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 1D19F1B2A31 for ; Fri, 8 Aug 2014 06:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.603 X-Spam-Level: X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 j5CgKg1LhVIb for ; Fri, 8 Aug 2014 06:59:15 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE031B29CD for ; Fri, 8 Aug 2014 06:59:15 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s78Dx9fD028132; Fri, 8 Aug 2014 09:59:09 -0400 Date: Fri, 8 Aug 2014 09:59:09 -0400 (EDT) From: Hubert Kario To: mrex@sap.com Message-ID: <291878953.27023269.1407506349223.JavaMail.zimbra@redhat.com> In-Reply-To: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp> References: <20140808133628.7C9931ADFC@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: WGLC: draft-ietf-tls-prohibiting-rc4-00 Thread-Index: cO4t24njEobdKKlRkyNB1o3H1zdQXQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KEbjaMHK-9ck98FRWFRZ1egi0WI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 13:59:17 -0000 ----- Original Message ----- > From: "Martin Rex" > To: "Sean Turner" > Cc: "TLS@ietf.org (tls@ietf.org)" > Sent: Friday, 8 August, 2014 3:36:28 PM > Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 > > Especially in the Web, where access to information is often available > through HTTP and HTTPS, a policy like the above (when adopted) would > cause MORE communication to be performed in plaintext. according to CloudFlare[0] basically no web clients support just RC4. During their test 0.0009% of visitors connected using RC4 after their servers placed RC4 last in the cipher order. > There currently exists *no* known attack against the integrity > protection of the TLS handshake, so this looks primarily like an > attempt to promote "planned obsolesence", and a poor excuse for > Microsoft to actively break interop with Windows XP (and potentially > other installed base). 3DES remains an option if you need to interoperate with very old systems. It doesn't break interoperability with Windows XP. 0 - http://blog.cloudflare.com/killing-rc4-the-long-goodbye -- Regards, Hubert Kario From nobody Fri Aug 8 07:57:05 2014 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 5DFB11B2B07 for ; Fri, 8 Aug 2014 07:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 KBve4uqvMDz5 for ; Fri, 8 Aug 2014 07:57:02 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8D4A91B2AF2 for ; Fri, 8 Aug 2014 07:57:02 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78EuxU1017143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 16:56:59 +0200 (MEST) In-Reply-To: <291878953.27023269.1407506349223.JavaMail.zimbra@redhat.com> To: Hubert Kario Date: Fri, 8 Aug 2014 16:56:58 +0200 (CEST) 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: <20140808145658.E70281ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ghj6OcHwY5VxyTjUKwgihSD2zes Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 14:57:04 -0000 Hubert Kario wrote: > >> There currently exists *no* known attack against the integrity >> protection of the TLS handshake, so this looks primarily like an >> attempt to promote "planned obsolesence", and a poor excuse for >> Microsoft to actively break interop with Windows XP (and potentially >> other installed base). > > 3DES remains an option if you need to interoperate with very old > systems. It doesn't break interoperability with Windows XP. > > 0 - http://blog.cloudflare.com/killing-rc4-the-long-goodbye This is the theory. In theory, theory an practice are the same, in practice they differ. There seems to be stuff that breaks with TLS cipher suites that use padding. This is just Windows stuff, I've also seen such interop problems with Java (J2SE) client (using nio it seems), that will simply not interop with 3DES-EDE (nor AES128-SHA), and RC4 is the only alternative that works. -Martin From nobody Fri Aug 8 08:23:20 2014 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 306DE1B2AEE for ; Fri, 8 Aug 2014 08:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.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] 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 4iZRoFOZx7VP for ; Fri, 8 Aug 2014 08:23:15 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id D46091A04AE for ; Fri, 8 Aug 2014 08:23:15 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s78FNAm0012612; Fri, 8 Aug 2014 11:23:10 -0400 Date: Fri, 8 Aug 2014 11:23:10 -0400 (EDT) From: Hubert Kario To: mrex@sap.com Message-ID: <1932336411.27094506.1407511390224.JavaMail.zimbra@redhat.com> In-Reply-To: <20140808145658.E70281ADFC@ld9781.wdf.sap.corp> References: <20140808145658.E70281ADFC@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: WGLC: draft-ietf-tls-prohibiting-rc4-00 Thread-Index: gt02Bv+gsGvp23FKvICLBxGHTla0Ww== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Nr_Q9IaY_FgUEgfswNBliX_64Yw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 15:23:18 -0000 ----- Original Message ----- > From: "Martin Rex" > To: "Hubert Kario" > Cc: mrex@sap.com, "Sean Turner" , "TLS@ietf.org (tls@ietf.org)" > Sent: Friday, 8 August, 2014 4:56:58 PM > Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 > > Hubert Kario wrote: > > > >> There currently exists *no* known attack against the integrity > >> protection of the TLS handshake, so this looks primarily like an > >> attempt to promote "planned obsolesence", and a poor excuse for > >> Microsoft to actively break interop with Windows XP (and potentially > >> other installed base). > > > > 3DES remains an option if you need to interoperate with very old > > systems. It doesn't break interoperability with Windows XP. > > > > 0 - http://blog.cloudflare.com/killing-rc4-the-long-goodbye > > > This is the theory. > In theory, theory an practice are the same, in practice they differ. > > There seems to be stuff that breaks with TLS cipher suites that > use padding. This is just Windows stuff, I've also seen such > interop problems with Java (J2SE) client (using nio it seems), > that will simply not interop with 3DES-EDE (nor AES128-SHA), > and RC4 is the only alternative that works. Those are bugs, if you _need_ to work around them, then work around them, that's what MUST means. But don't deploy those workarounds unless you're: 1). sure that they are needed 2). sure that this is the only way to workaround the issue -- Regards, Hubert Kario From nobody Fri Aug 8 10:14:56 2014 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 195361B2866 for ; Fri, 8 Aug 2014 10:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, UNPARSEABLE_RELAY=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 huTI_Jh8XRIB for ; Fri, 8 Aug 2014 10:14:52 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 698DA1B2860 for ; Fri, 8 Aug 2014 10:14:52 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s78HEgEP000710; Fri, 8 Aug 2014 13:14:51 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "mrex@sap.com" Thread-Topic: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Thread-Index: AQHPsxDzfQ5Gw8dfRUSnLamikTCz3ZvHDu0A///jZYA= Date: Fri, 8 Aug 2014 17:14:40 +0000 Message-ID: References: <291878953.27023269.1407506349223.JavaMail.zimbra@redhat.com> <20140808145658.E70281ADFC@ld9781.wdf.sap.corp> In-Reply-To: <20140808145658.E70281ADFC@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3490348475_57150391" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-08_05:2014-08-08,2014-08-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408080205 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8VEoFV3cZcDMAVD7DkQ4ASwZTVw Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 17:14:55 -0000 --B_3490348475_57150391 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit >...........I've also seen such >interop problems with Java (J2SE) client (using nio it seems), >that will simply not interop with 3DES-EDE (nor AES128-SHA), >and RC4 is the only alternative that works. Could you please provide more information on this? What exactly did not interoperate? And details, please? Thanks! --B_3490348475_57150391 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCC+cmzq61ypH2MGXKoSFNnaA4NGFN3HyxADvOMav11nhDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA4MDgxNzE0MzVaMA0GCSqGSIb3 DQEBAQUABIIBAFN7a3Gc8bHL9PIQjflc8/TOLxVbzmXM9CHSMX6b+pQ0BE2BPOAFYMb5RuBz 4aFhvA66oEupWEJ1J/zJZGZKrdqVRdroak8KvFX9dcpesNsvYphU7HCm4+LX74CFzoJtmpP7 /Qh0sIgyXbhJTD5g/pNk2THqTsDcCj0ML1TJJWxXudeKBbPaD3sz41R345BtqOmcYsawrKE1 ZJjwrqhx9JlMAMYn2piMHpoLOrfeqCVFJjmp95SHrGpyk7KRjfN43lfYu99LXRN+UeCVnTe+ RlgDKByESZsCr443oo+JEtAfU+cG27eXXGZxl4tDsYJC8PUpQEA+GvH81BIQVIB1kcY= --B_3490348475_57150391-- From nobody Fri Aug 8 13:02:14 2014 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 07E1D1A0421 for ; Fri, 8 Aug 2014 13:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 UTWO81uGBBG0 for ; Fri, 8 Aug 2014 13:01:41 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BF11A041C for ; Fri, 8 Aug 2014 13:01:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,827,1400018400"; d="asc'?scan'208,217";a="74345437" Received: from pool-71-161-100-124.cncdnh.east.myfairpoint.net (HELO [10.0.1.3]) ([71.161.100.124]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 08 Aug 2014 22:01:37 +0200 From: Karthikeyan Bhargavan Content-Type: multipart/signed; boundary="Apple-Mail=_83EE4700-2ED9-44F6-AB28-C6B4417FF578"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 8 Aug 2014 16:01:34 -0400 References: <79E82046-616E-4179-8CF6-12126DDE4640@inria.fr> To: "TLS@ietf.org (tls@ietf.org)" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MJ7lfr9qHMFXXlAE5uSixuDcZps Subject: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant) 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, 08 Aug 2014 20:01:57 -0000 --Apple-Mail=_83EE4700-2ED9-44F6-AB28-C6B4417FF578 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A0DB78F-97D6-4949-B8F2-48F387DDE4AA" --Apple-Mail=_7A0DB78F-97D6-4949-B8F2-48F387DDE4AA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, The following is specific to SRP, but perhaps of interest to those = working with TLS-SRP. (The email address for the SRP spec authors seems to be out of date, and = I=92m hoping they are on this list.)=20 While investigating the triple handshake attack on various TLS cipher = suites, we came upon two scenarios in which one of the participants of = the SRP protocol can unilaterally control the generated session key. We = wonder if this is already well known about SRP? In the key exchange = literature, the violated property is often called =93contributiveness=94 = and the attack is sometimes called =93key control.=94 It is a somewhat = theoretical attack and the only exploit we know of is as a first step in = a triple handshake attack, but it is an avoidable vulnerability = nevertheless. We describe two scenarios below, adopting the notation of = http://srp.stanford.edu/design.html The key observation is that SRP only asks clients to verify that A and B = are not 0; it does not require any additional public-key validation steps (and indeed TLS-SRP in = OpenSSL does not perform any other checks, although SRP in GnuTLS does). = Consequently, an attacker (acting as a client or as a server) can mount = a specific kind of small subgroup confinement attack resulting in key = control, both as a client and as a server. Since SRP uses Sophie-Germain MODP groups, we advocate that both parties = in SRP should fully validate that the received Diffie-Hellman public = keys belong to the prime-order subgroup [2..N-2]. In the context of = TLS-SRP, the session-hash extension will also prevent these scenarios, = but that extension cannot protect other uses of SRP. Case 1: Compromised Verifier v, Degenerate server public-key g^b = --------------------------------------------------------------------------= --------------- Suppose an attacker has obtained the verifier v for a client.=20 Now the attacker impersonates the host in the SRP exchange and chooses=20= B =3D kv + 1 or B =3D kv or B =3D kv + (N-1) and in all three cases the = generated key K will be *independent*=20 of the user=92s session specific value A. For the example with B =3D kv = + 1, see: User -> Host: I, A =3D g^a (identifies self, a =3D = random number) Host -> User: s, B =3D kv + 1 (sends salt, b =3D 0) Both: u =3D H(A, B) User: x =3D H(s, p) (user enters password) User: S =3D (B - kg^x) ^ (a + ux) =3D 1 (computes session = key) User: K =3D H(S) =3D H(1) Host: S =3D (Av^u) ^ b (computes session key) Host: K =3D H(S)=3D H(1) Case 2: Degenerate verifier v =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97 Suppose an attacker registers at the SRP host with a triplet (I, s, v) = where v is either 0 or 1 or N-1. Further, assume that the user always chooses A =3D 0 or 1 or N-1. Now, = all sessions between the user and host will result in a generated key = that is independent of the server=92s session specific choice of g^b.=20 For the example with v =3D 1 and A =3D 1, see: User -> Host: I, A =3D g^0 =3D 1 (identifies self, a =3D = 0) Host -> User: s, B =3D kv + g^b (sends salt, b =3D random = number) User: K =3D H(S) =3D H(1) Host: S =3D (Av^u) ^ b =3D 1 (computes session = key) Host: K =3D H(S)=3D H(1) Problem(?) and Fix =97=97=97=97=97=97=97=97=97=97=97=97=97 It is possible that the above scenarios known and considered innocuous. = Indeed, by themselves, they do not appear to break the stated security = goals of SRP. However Key Control vulnerabilities like these typically = lead to failures when composed with other protocols in compound = authentication schemes. In this case, TLS-SRP becomes one of the key = exchanges (along with RSA and DHE) that is vulnerable to the triple = handshake attack (renegotiation after resumption). In particular, after = a TLS-SRP exchange, the master secret is not guaranteed to be unique = across sessions, and hence it should not be used for (say) cryptographic = binding in PEAP/EAP-TTLS.=20 The fix seems simple on the surface (ensure that the DH public keys are = in [2,p-2]) but perhaps this requires more analysis, lest it violate = the one-guess-per-session guarantee of SRP. The client should validate = that B-kv is not 0,1,N-1. Similarly, the server should reject verifier = values of 0,1,N-1. Best, Karthik --Apple-Mail=_7A0DB78F-97D6-4949-B8F2-48F387DDE4AA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi,

The following is = specific to SRP, but perhaps of interest to those working with = TLS-SRP.
(The email address for the SRP spec authors seems to = be out of date, and I=92m hoping they are on this = list.) 

While investigating the triple handshake attack on = various TLS cipher suites, we came upon two scenarios in which one of = the participants of the SRP protocol can unilaterally control the = generated session key. We wonder if this is already well known about = SRP? In the key exchange literature, the violated property is often = called =93contributiveness=94 and the attack is sometimes called =93key = control.=94 It is a somewhat theoretical attack and the only exploit we = know of is as a first step in a triple handshake attack, but it is an = avoidable vulnerability nevertheless.

We describe two scenarios below, = adopting the notation of http://srp.stanford.edu/desig= n.html
The key observation is that SRP only asks clients = to verify that A and B are not 0; it does not require
any = additional public-key validation steps (and indeed TLS-SRP in OpenSSL = does not perform any other checks, although SRP in GnuTLS does). = Consequently, an attacker (acting as a client or as a server) can mount = a specific kind of small subgroup confinement attack resulting in key = control, both as a client and as a = server.

Since SRP uses Sophie-Germain MODP = groups, we advocate that both parties in SRP should fully validate that = the received Diffie-Hellman public keys belong to the prime-order = subgroup [2..N-2].  In the context of TLS-SRP, the session-hash = extension will also prevent these scenarios, but that extension cannot = protect  other uses of SRP.

Case 1: = Compromised Verifier v, Degenerate server public-key = g^b
------------------------------------------------------------= -----------------------------

Suppose an = attacker has obtained the verifier v for a client. 
Now = the attacker impersonates the host in the SRP exchange and = chooses 
B =3D kv + 1 or B =3D kv or B =3D kv + (N-1) and = in all three cases the generated key K will be = *independent* 
of the user=92s session specific value A. = For the example with B =3D kv + 1, = see:

User -> Host:  I, A =3D g^a        =
          (identifies self, a =3D random number)
Host -> User:  s, B =3D kv + 1               (sends salt, b =3D 0)

        Both:  u =3D H(A, B)

        User:  x =3D H(s, p)                     (user enters password)
        User:  S =3D (B - kg^x) ^ (a + ux) =3D 1   (computes session =
key)
        User:  K =3D H(S) =3D H(1)

        Host:  S =3D (Av^u) ^ b              (computes session key)
        Host:  K =3D H(S)=3D H(1)

Case 2: = Degenerate verifier = v
=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97

Suppose an attacker registers at the SRP host = with a triplet (I, s, v) where v is either 0 or 1 or = N-1.
Further, assume that the user always chooses A =3D 0 or 1 = or N-1. Now, all sessions between the user and host will result in a = generated key that is independent of the server=92s session specific = choice of g^b. 
For the example with v =3D 1 and A =3D 1, = see:

User -> Host:  I, A =3D g^0 =3D 1  =
            (identifies self, a =3D 0)
Host -> User:  s, B =3D kv + g^b             (sends salt, b =3D =
random number)
        User:  K =3D H(S) =3D H(1)

        Host:  S =3D (Av^u) ^ b =3D 1              (computes =
session key)
        Host:  K =3D H(S)=3D =
H(1)


Problem(?) and = Fix
=97=97=97=97=97=97=97=97=97=97=97=97=97

=
It is possible that the above scenarios known and considered = innocuous. Indeed, by themselves, they do not appear to break the stated = security goals of SRP. However Key Control vulnerabilities like these = typically lead to failures when composed with other protocols in = compound authentication schemes. In this case, TLS-SRP becomes one of = the key exchanges (along with RSA and DHE) that is vulnerable to the = triple handshake attack (renegotiation after resumption). In particular, = after a TLS-SRP exchange, the master secret is not guaranteed to be = unique across sessions, and hence it should not be used for (say) = cryptographic binding in = PEAP/EAP-TTLS. 

The fix seems simple on = the surface (ensure that the DH public keys are in [2,p-2])  but = perhaps this requires more analysis, lest it violate the = one-guess-per-session guarantee of SRP. The client should validate that = B-kv is not 0,1,N-1. Similarly, the server should reject verifier values = of = 0,1,N-1.

Best,
Karthik



= --Apple-Mail=_7A0DB78F-97D6-4949-B8F2-48F387DDE4AA-- --Apple-Mail=_83EE4700-2ED9-44F6-AB28-C6B4417FF578 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT5SyeAAoJEB/WSo9veuUK09EH/Ra7Re9IzbU7EyMCWyvIayEL r8BnOpg8MkfAvKg5RMZk+uT+/te3QxhNBWUVr8qLcvI06dZgMP4BmCxR2SJFjhWP m70Mqcq7lxPz8HEitDLNNY8RixcYYgUwbNvEuWlfDc23eXU+JC9pHL5ZBVu6YE1z AWpkjNEzNJ/Fseyww9DXLTr+5BcJV7yaYm0yDplCuPOEViRqZXPeJr217FxQMbKG Mtq0FqmpXHEAHS5tjMXXLR2L4jLjbjpxFtFjmZIAepz9fkpihLUegd4mGSNyUPrA L58DfbLtyN/Hu/n5iBox318B8Un9mlUGhPF8EbWNRS6+4eN6+qTU3mvEyR0yl8I= =UnxE -----END PGP SIGNATURE----- --Apple-Mail=_83EE4700-2ED9-44F6-AB28-C6B4417FF578-- From nobody Fri Aug 8 13:18:40 2014 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 67A851A0450 for ; Fri, 8 Aug 2014 13:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 15oUGl0Vtd3A for ; Fri, 8 Aug 2014 13:18:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 636D71A0A88 for ; Fri, 8 Aug 2014 13:18:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C64F748516 for ; Fri, 8 Aug 2014 20:18:34 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id B8A4F4846F for ; Fri, 8 Aug 2014 20:18:34 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 8B41A98058 for ; Fri, 8 Aug 2014 20:18:34 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Fri, 8 Aug 2014 16:18:34 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Fri, 8 Aug 2014 16:18:32 -0400 Thread-Topic: SNI and tickets and resumption Thread-Index: Ac+zRcV74n+EsqUATjuM95BbDPTw9g== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850BUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/aAgOGFjPl07xrXsgJ0V1-DuwMjQ Subject: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 20:18:37 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850BUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can a client connect with an SNI extension and then later on resume or send= a ticket with a different SNI value? I couldn't find it documented anywhere. Am I missing something, or should w= e? -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850BUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can a client con= nect with an SNI extension and then later on resume or send a ticket with a= different SNI value?

 <= /p>

I couldn’t find it documented anywhere. Am I = missing something, or should we?

&n= bsp;

-- 

Principal Security Engineer

Akamai = Technologies, Cambridge MA

IM: rsalz@jabber.me Twitter: RichSalz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850BUSMBX1msgcorp_-- From nobody Fri Aug 8 13:28:52 2014 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 0EAED1A0197 for ; Fri, 8 Aug 2014 13:28:51 -0700 (PDT) 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 SkAtlLf7_Abb for ; Fri, 8 Aug 2014 13:28:49 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BA021A0109 for ; Fri, 8 Aug 2014 13:28:49 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id c11so4271250lbj.9 for ; Fri, 08 Aug 2014 13:28:47 -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:content-type; bh=WNHN/+E9j/VYJQ3offextRhLEExXkoAHiJnwQs84heA=; b=ePrUVWVJF2tHawt+h9VD7g4LwcEmBCr1C9NwqiKulg4qjwdGb8V7ZpKhoW1nVk2NGH i6YYMJlivCTNyRfvGJKqfqvTWQzfnHdXSfm8t/I+zrJWF6RdLCqcfjm3LaTU6JW8181f RDCBoFX0giSBOqp3BwxJMY2TSsyruDAuQBW9crsg+5fZIhIgCFpQK+eQ5wfCbHVL+3qa lDafDw6IBEhFHNlwqMDa8ouT0P+3aG6D8RcphpoEWC+FXCHCUU8ey/hDX08/mNkNTJeR TA3tr+dW9liZB2MLS6vmGf5OBqUxvouMnGVhFcSO0pO570omK9gxZlatNanqtA0DIr2p YSDQ== MIME-Version: 1.0 X-Received: by 10.152.161.225 with SMTP id xv1mr3907864lab.71.1407529727573; Fri, 08 Aug 2014 13:28:47 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.170.37 with HTTP; Fri, 8 Aug 2014 13:28:47 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> Date: Fri, 8 Aug 2014 13:28:47 -0700 X-Google-Sender-Auth: RZYQclDsycfX6ZGe_I07QpCq6_E Message-ID: From: Adam Langley To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vG2s6V_W8-IA378tzSpuji_3MpY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 20:28:51 -0000 On Fri, Aug 8, 2014 at 1:18 PM, Salz, Rich wrote: > Can a client connect with an SNI extension and then later on resume or send > a ticket with a different SNI value? In practice, often yes. However, whether you want to allow that is a different matter. If you share ticket keys between different servers you would want to ensure that a client's connection to one of them can't be redirected to another unless the servers are identical. At Google, we share ticket keys between servers, but the servers will reject a resumption if any part of the ClientHello causes a different certificate to be selected than was presented on the original connection. Then services that don't route requests based on the Host header are then given their own certificates to partition them. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Aug 8 13:31:02 2014 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 F1CB11A02A2 for ; Fri, 8 Aug 2014 13:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ck2QEWYbmst for ; Fri, 8 Aug 2014 13:30:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 498BE1A011E for ; Fri, 8 Aug 2014 13:30:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 000E6475A4; Fri, 8 Aug 2014 20:30:50 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E7121475A3; Fri, 8 Aug 2014 20:30:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id E3607202E; Fri, 8 Aug 2014 20:30:50 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Fri, 8 Aug 2014 16:30:50 -0400 From: "Salz, Rich" To: Adam Langley Date: Fri, 8 Aug 2014 16:30:48 -0400 Thread-Topic: [TLS] SNI and tickets and resumption Thread-Index: Ac+zR11HT2XusErwT4CY8pSKgYIcrQAACFOw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8523@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BD2BDdnJ80bZz5ezMbVm-2CiIEs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 20:30:57 -0000 V2UgZG8gdGhlIHNhbWUgdGhpbmcsIGJ1dCB3YXNuJ3Qgc3VyZSBpZiBpdCB3YXMgbGVnaXQuIA0K DQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXINCkFrYW1haSBUZWNobm9sb2dpZXMs IENhbWJyaWRnZSBNQQ0KSU06IHJzYWx6QGphYmJlci5tZSBUd2l0dGVyOiBSaWNoU2Fseg0KDQo= From nobody Fri Aug 8 13:55:49 2014 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 02DAF1A017A for ; Fri, 8 Aug 2014 13:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 uIz9mme6gCPG for ; Fri, 8 Aug 2014 13:55:45 -0700 (PDT) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8EB1A0158 for ; Fri, 8 Aug 2014 13:55:45 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id uq10so1650903igb.14 for ; Fri, 08 Aug 2014 13:55:44 -0700 (PDT) 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-type; bh=AtcZCzWvlt9/bfK4bBElofN4Vmm0yNmLicvXw+0CXc8=; b=k55LwilFbzXimhs+gw14Tnd7kiLCNtRU0AUUuNCrqJnbR9qf1abByDYpxqSXnom0Oy pSOe8nHftyAnbck+VFuc8Bip+3bkoHe21TRS4vyz6dPu6NlkpW5qvoD6aApQxNVbzHeu jaz18wI65xQ6z53vaWg+So6pDYobYFke8Z+ctk8G+9yGp8KNc6+druMz3eWZv5fulwV3 VPqOmKf25je1mD6c+L09/yf0HDX8/U+gi+0ISQMyXcb5F75XKY61Ljn2+TkaQ+/LvICr LtLmDTn8aXFLUTy0DjbgmT60OjCUJLE4nElh61wmD1hj1XsMusqzRPJ0S/QuHpsa2tgF snNw== X-Gm-Message-State: ALoCoQm1EooAeZ1kSr0WzZLSNGLg6ISz3JQIc7579F6K2fgWIOCK4ANoxSbbVHf/4QuXCoRwFcDF MIME-Version: 1.0 X-Received: by 10.50.142.99 with SMTP id rv3mr8817197igb.48.1407531344495; Fri, 08 Aug 2014 13:55:44 -0700 (PDT) Received: by 10.107.133.154 with HTTP; Fri, 8 Aug 2014 13:55:44 -0700 (PDT) X-Originating-IP: [70.36.227.134] In-Reply-To: References: <79E82046-616E-4179-8CF6-12126DDE4640@inria.fr> Date: Fri, 8 Aug 2014 13:55:44 -0700 Message-ID: From: Trevor Perrin To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M0MfXNyCvFKsXb7jchqOn_9PhXo Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant) 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, 08 Aug 2014 20:55:49 -0000 On Fri, Aug 8, 2014 at 1:01 PM, Karthikeyan Bhargavan wrote: > Hi, > > The following is specific to SRP, but perhaps of interest to those working > with TLS-SRP. [...] > > While investigating the triple handshake attack on various TLS cipher > suites, we came upon two scenarios in which one of the participants of the > SRP protocol can unilaterally control the generated session key. Hi Karthikeyan, Thanks for the observation. I haven't followed the triple-handshake discussion closely. My impression is that it's a TLS issue - not an SRP issue - which should be fixed by something like [1]. Is that correct? Trevor [1] http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ From nobody Fri Aug 8 14:08:59 2014 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 8CDF21B279D for ; Fri, 8 Aug 2014 14:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg9TImpOowif for ; Fri, 8 Aug 2014 14:08:44 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E0461A0AE7 for ; Fri, 8 Aug 2014 14:08:38 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so3086574wiv.0 for ; Fri, 08 Aug 2014 14:08:37 -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-type; bh=f5uZEoNTHrDOj0e7fVCLH32PpBY2fWz3RMNrxBVqJ/0=; b=cRsKTI6aRaHGhg0efcPEhq1adFKXDyJQOeQzxfs59/VQQjIS0j8/CXV4LZg20m+c6c Ws9aD4ExJ0ZTVuH3sC8Mc/uLh7rBph16Lj638EFuP66QURHtfHDPGSaHDvZNdHyouMVr EpZ1YaFzehrwGyt2v2TbM3gMWLWuqEWoWuwH7n0XQfblKb1PWmQAZhi/8101XXna2g9J QQnzGkL1j1+6cUIBzV8FWLTR6T7UVXkSM2BmWtOOzT3h3MoTNIWb/O7MKTa/rKEHV6dU IJqC0YKOV2mRyIZ3iwVpH7REWirAT/ngJ4bxjW5qErBC6DUQcY9WA0oQmxBXpKI1nY6Q T7Lw== MIME-Version: 1.0 X-Received: by 10.180.92.38 with SMTP id cj6mr6864677wib.64.1407532117689; Fri, 08 Aug 2014 14:08:37 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Fri, 8 Aug 2014 14:08:37 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8523@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8523@USMBX1.msg.corp.akamai.com> Date: Fri, 8 Aug 2014 14:08:37 -0700 Message-ID: From: Martin Thomson To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Eg1WIbbTIYeBxXbtkSuS3aK5ims Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 21:08:56 -0000 On 8 August 2014 13:30, Salz, Rich wrote: > We do the same thing, but wasn't sure if it was legit. We can probably do better than that. And I'm sure that this goes beyond SNI, though that's a pretty obvious one. https://github.com/tlswg/tls13-spec/issues/76 From nobody Fri Aug 8 14:09:35 2014 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 EC6131A0379 for ; Fri, 8 Aug 2014 14:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 IsKR0h_KEYYC for ; Fri, 8 Aug 2014 14:09:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D09D31B27A5 for ; Fri, 8 Aug 2014 14:09:04 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s78L92gT017753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Aug 2014 23:09:02 +0200 (MEST) In-Reply-To: To: "Blumenthal, Uri - 0558 - MITLL" Date: Fri, 8 Aug 2014 23:09:02 +0200 (CEST) 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: <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EZpUVhO8R43RF30X87EuMKQ8kbU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 21:09:33 -0000 Blumenthal, Uri - 0558 - MITLL wrote: >>...........I've also seen such >>interop problems with Java (J2SE) client (using nio it seems), >>that will simply not interop with 3DES-EDE (nor AES128-SHA), >>and RC4 is the only alternative that works. > > Could you please provide more information on this? What exactly did not > interoperate? And details, please? I know very little about Java, so I'll try to describe what happened. A partner had writen some data aggregation tool in Java (with JBoss, I believe) that was trying to submit that data as XML/SOAP via HTTPS to our backend server, but they were encountering TLS handshake failures. Our server was aborting the handshake with a fatal bad_mac(20) alert. The error message that the partner saw when debugging his java client was: javax.net.ssl.SSLException: Received fatal alert: bad record mac I gave them a special debug build of our our SSL implementation that had all "countermeasures" (bleichenbacher,vaudenay) disabled and it turned out that the Java SSL client was sending bogus Finished handshake message records (decryption resulted in random garbage, including the padding value). Since the Java client offered AES128-SHA, our server would choose that (server preference). The Java client was sending the following cipher suites in ClientHello: (26 cipher suites, EMPTY_RENEGOTIATON_INFO_SCSV included, head only ): TLS_RSA_WITH_RC4_128_MD5 (0x0004) TLS_RSA_WITH_RC4_128_SHA (0x0005) TLS_RSA_WITH_AES_128_SHA (0x002f) TLS_DHE_RSA_WTIH_AES_128_CBC_SHA (0x0033) TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) TLS_RSA_WTIH_3DES_EDE_CBC_SHA (0x000a) TLS_DHE_RSA_WITH_3DES_ECE_CBC_SHA (0x0016) TLS_DHE_DSA_WITH_3DES_ECE_CBC_SHA (0x0013) TLS_RSA_WITH_DES_CBC_SHA (0x0009) >From that list our server will pick the 3rd in its default configuration. So I suggested to them thre tests with our server, limiting our server's ciper suite to (1) AES128-SHA, (2) 3DES-EDE-SHA, (3) RC4-128, and the test with AES128 and 3DES failed with bad-mac, whereas the test with RC4-128 succeeded. Then I asked them to try handshaking with an openssl s_server in similar configurations, and the results were the same: bad_mac for the cipher suites that were using CBC ciphers, success for RC4-128 >From what I remember, they were using J2EE 1.6 I do not know what part of the partner's software or the underlying Java J2EE is causing these problems. But with the RC4 ciphers first in the Java's ClientHello and the bad habit of several TLS implementations to yield to the clients ordering rather than using the servers preference, the bug causing this interop problem may be rather old have gone unnoticed for a long time. The issue with 3DES is that it is *SLOW*. much much slower than RC4-128. If you look at Intels paper about improving openssl AES ciper suites with AES-NI hardware support here: http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/open-ssl-performance-paper.pdf they get merely the same throughput with AES-NI boosted AES-CBC cipher suites as they get with plain old RC4-128. RC4 cipher suites are a problem when applications on top use a disclosing authentication scheme in the clear with an authentication token or password that is valid essentially forever, and when clients can either be coerced to send this disclosing authentication several million times (or do this all by themselves). -Martin From nobody Fri Aug 8 14:11:44 2014 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 299FB1ABD18 for ; Fri, 8 Aug 2014 14:11:42 -0700 (PDT) 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_FR=0.35, RCVD_IN_DNSWL_HI=-5, 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 FRJLUgl7n1zZ for ; Fri, 8 Aug 2014 14:11:36 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A841A0379 for ; Fri, 8 Aug 2014 14:11:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,827,1400018400"; d="asc'?scan'208";a="74348410" Received: from pool-71-161-100-124.cncdnh.east.myfairpoint.net (HELO [10.0.1.3]) ([71.161.100.124]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 08 Aug 2014 23:11:33 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_C19BB4DE-E8B7-4E73-8009-16DD973BADB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 8 Aug 2014 17:11:31 -0400 Message-Id: <184302E9-0674-49FE-B0E5-3D356404573F@inria.fr> References: <79E82046-616E-4179-8CF6-12126DDE4640@inria.fr> To: Trevor Perrin X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/naYiWniyDnrVYmaykoK6Q-G9ILs Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant) 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, 08 Aug 2014 21:11:42 -0000 --Apple-Mail=_C19BB4DE-E8B7-4E73-8009-16DD973BADB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > I haven't followed the triple-handshake discussion closely. My > impression is that it's a TLS issue - not an SRP issue - which should > be fixed by something like [1]. > =85. > [1] http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/ Yes, [1] is the current proposal to prevent all triple-handshake-style = key synchronisation attacks The observation here is meant to document that TLS-SRP (not just TLS-RSA = and TLS-DHE) also allows key control, but that this can be easily avoided by some cheap = implementation checks. The main concern may be for for other uses of SRP where [1] may not = apply, but I don=92t know enough about such applications to comment. Best, -Karthik >=20 > Is that correct? >=20 > Trevor >=20 --Apple-Mail=_C19BB4DE-E8B7-4E73-8009-16DD973BADB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT5T0DAAoJEB/WSo9veuUKgC8IALDQbrDOSSe9BZ0pXcmMpUGU bwjQzzRSDMHAvC+TecWdKt4KR4yBMaeJOkBGdFlLmQaTWp6GiIns+QaERYKFptvz HXjXVd3UJU+poM73PIOqGsny2OoYktCQSx2SLRKOsjAMkBjUHz/mQMB/4KN15k7Z FBW1uBLHMj5o9PXseK0NWTWuoVCfVaxFyvgfcvIm+x5tD/xvgGEFp6rXI/68A42h aWCT2dPrpCV1d06gAeIzvYypKoG/lEyDIXun4oisl1MvFnLbqK/5SsfJzcgbeCIu rqhDWszC96mdBBjuR+8IqAM6mgK0ep6+gosxJD+0hmixp4umyA8sGE2nJIBFThI= =3MOX -----END PGP SIGNATURE----- --Apple-Mail=_C19BB4DE-E8B7-4E73-8009-16DD973BADB4-- From nobody Fri Aug 8 14:21:15 2014 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 6A7FF1B27A6 for ; Fri, 8 Aug 2014 14:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, 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 6sUDoVO4n8eg for ; Fri, 8 Aug 2014 14:21:10 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 160EC1A0AD9 for ; Fri, 8 Aug 2014 14:21:10 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s78LL7wt009164; Fri, 8 Aug 2014 14:21:09 -0700 Received: from sc-owa01.marvell.com ([199.233.58.136]) by mx0a-0016f401.pphosted.com with ESMTP id 1nm87curp3-1 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 08 Aug 2014 14:21:09 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA01.marvell.com ([10.93.76.21]) with mapi; Fri, 8 Aug 2014 14:20:57 -0700 From: Paul Lambert To: "mrex@sap.com" , "Blumenthal, Uri - 0558 - MITLL" Date: Fri, 8 Aug 2014 14:20:54 -0700 Thread-Topic: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 Thread-Index: Ac+zTqO0y6aeAm7kQNeCjAzXPK7ynw== Message-ID: References: <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp> In-Reply-To: <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-08_05:2014-08-08,2014-08-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408080253 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RnhTS9h7ZYOXowyfe20T7Cp-Jzg Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 08 Aug 2014 21:21:12 -0000 +1 on strongly disagree Not sure how example below is relevant to total removal of RC4. It=B9s important to maintain the clear position that is in current draft: =B3 =8A clients MUST NOT include RC4 cipher suites =8A =B3 Paul On 8/8/14, 2:09 PM, "Martin Rex" wrote: >Blumenthal, Uri - 0558 - MITLL wrote: >>>...........I've also seen such >>>interop problems with Java (J2SE) client (using nio it seems), >>>that will simply not interop with 3DES-EDE (nor AES128-SHA), >>>and RC4 is the only alternative that works. >>=20 >> Could you please provide more information on this? What exactly did not >> interoperate? And details, please? > > >I know very little about Java, so I'll try to describe what happened. > >A partner had writen some data aggregation tool in Java (with JBoss, >I believe) that was trying to submit that data as XML/SOAP via HTTPS >to our backend server, but they were encountering TLS handshake failures. > >Our server was aborting the handshake with a fatal bad_mac(20) alert. >The error message that the partner saw when debugging his java client >was: > > javax.net.ssl.SSLException: Received fatal alert: bad record mac > >I gave them a special debug build of our our SSL implementation that >had all "countermeasures" (bleichenbacher,vaudenay) disabled and >it turned out that the Java SSL client was sending bogus Finished >handshake message records (decryption resulted in random garbage, >including the padding value). Since the Java client offered >AES128-SHA, our server would choose that (server preference). > >The Java client was sending the following cipher suites in ClientHello: >(26 cipher suites, EMPTY_RENEGOTIATON_INFO_SCSV included, head only ): > > TLS_RSA_WITH_RC4_128_MD5 (0x0004) > TLS_RSA_WITH_RC4_128_SHA (0x0005) > TLS_RSA_WITH_AES_128_SHA (0x002f) > TLS_DHE_RSA_WTIH_AES_128_CBC_SHA (0x0033) > TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) > TLS_RSA_WTIH_3DES_EDE_CBC_SHA (0x000a) > TLS_DHE_RSA_WITH_3DES_ECE_CBC_SHA (0x0016) > TLS_DHE_DSA_WITH_3DES_ECE_CBC_SHA (0x0013) > TLS_RSA_WITH_DES_CBC_SHA (0x0009) > >>From that list our server will pick the 3rd in its default configuration. > >So I suggested to them thre tests with our server, limiting >our server's ciper suite to (1) AES128-SHA, (2) 3DES-EDE-SHA, (3) RC4-128, >and the test with AES128 and 3DES failed with bad-mac, whereas the test >with RC4-128 succeeded. > >Then I asked them to try handshaking with an openssl s_server in similar >configurations, and the results were the same: bad_mac for the cipher >suites that were using CBC ciphers, success for RC4-128 > >>From what I remember, they were using J2EE 1.6 > > >I do not know what part of the partner's software or the underlying >Java J2EE is causing these problems. But with the RC4 ciphers first >in the Java's ClientHello and the bad habit of several TLS >implementations to yield to the clients ordering rather than using >the servers preference, the bug causing this interop problem may be >rather old have gone unnoticed for a long time. > > >The issue with 3DES is that it is *SLOW*. much much slower than RC4-128. > >If you look at Intels paper about improving openssl AES ciper suites >with AES-NI hardware support here: > =20 >http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/o >pen-ssl-performance-paper.pdf > >they get merely the same throughput with AES-NI boosted AES-CBC cipher >suites >as they get with plain old RC4-128. > > >RC4 cipher suites are a problem when applications on top use a disclosing >authentication scheme in the clear with an authentication token or >password >that is valid essentially forever, and when clients can either be coerced >to send this disclosing authentication several million times (or do this >all by themselves). > > >-Martin > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Fri Aug 8 14:55:23 2014 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 21B8E1A00BE for ; Fri, 8 Aug 2014 14:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 d1s0OmFGOFtj for ; Fri, 8 Aug 2014 14:55:20 -0700 (PDT) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B247C1A00B0 for ; Fri, 8 Aug 2014 14:55:20 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id at1so7220758iec.30 for ; Fri, 08 Aug 2014 14:55:20 -0700 (PDT) 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-type; bh=h4Nz9OQyQ8CeI0ORYw6LJynClBE3tfYfT2T/2Y0leH8=; b=cr/DAcWQYchVuGBEHHWdvoP+GoFBBnXWoGJsWGcTVJq+sA6ArnDx4ut/Urpxj7DJ1j q5s7PsACwuGAqHcc8iUepkX/NMNRyPHQUmxXeaE0GaOZo72z0eWD51cfsXa5wTiiUPW/ NtwMVwhIpjNvi6KblR9UAT8UaGusUjt0mupslQFFcmCSOzGkE9s0HeTf02YD/J2SOnBG ANbdtPs23bfICJCdaR15DFK9+QAORuOhMw/lOThGZdUKafuESFrcNQz7neVlbdPvhB2A Kk4PaP3ezFQ/341DqHQ+0nKlJ6UGCJAl9gk9HY/9g6dhInsh50yovTZvHPNka0c1Lt1E 35hA== X-Gm-Message-State: ALoCoQk7oLjHXupSLzv4S3Gza+BsXCf/SD+YNWVUMyoYWCSrSEU57yAFm/Ywo/vtr93pFWaBnUHa MIME-Version: 1.0 X-Received: by 10.42.109.79 with SMTP id k15mr16109592icp.42.1407534919908; Fri, 08 Aug 2014 14:55:19 -0700 (PDT) Received: by 10.107.133.154 with HTTP; Fri, 8 Aug 2014 14:55:19 -0700 (PDT) X-Originating-IP: [70.36.227.134] In-Reply-To: <184302E9-0674-49FE-B0E5-3D356404573F@inria.fr> References: <79E82046-616E-4179-8CF6-12126DDE4640@inria.fr> <184302E9-0674-49FE-B0E5-3D356404573F@inria.fr> Date: Fri, 8 Aug 2014 14:55:19 -0700 Message-ID: From: Trevor Perrin To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uQ7WYry02-29JYbsigmVv2wYuHQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Key Control Vulnerability in SRP (Triple Handshake Variant) 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, 08 Aug 2014 21:55:22 -0000 On Fri, Aug 8, 2014 at 2:11 PM, Karthikeyan Bhargavan wrote: > > The observation here is meant to document that TLS-SRP (not just TLS-RSA and TLS-DHE) also > allows key control, but that this can be easily avoided by some cheap implementation checks. Maybe, but you said yourself this would "require more analysis". I think if a protocol like TLS is going to reuse a session key, it's the protocol's job to ensure this is safe. There are generic ways to do so (e.g. hashing the transcript into session key). So I'm not convinced we should be going through the math of all key agreements and trying to tweak them for an unusual property like "key control". Trevor From nobody Fri Aug 8 16:07:04 2014 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 4CB2B1A014E for ; Fri, 8 Aug 2014 16:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 o_p8jUDHVjLr for ; Fri, 8 Aug 2014 16:06:59 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A110D1A01AA for ; Fri, 8 Aug 2014 16:06:58 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78N6rVR019106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 01:06:53 +0200 (MEST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8523@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Sat, 9 Aug 2014 01:06:53 +0200 (CEST) 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: <20140808230653.C508F1ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KE4zj4IOT3zS1jEdenvzlMN5720 Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 23:07:02 -0000 Salz, Rich asked: > > Can a client connect with an SNI extension and then later on resume > or send a ticket with a different SNI value? AGL responded: > > At Google, we share ticket keys between servers, but the servers will > reject a resumption if any part of the ClientHello causes a different > certificate to be selected than was presented on the original > connection. Salz, Rich wrote: > > We do the same thing, but wasn't sure if it was legit. The words you're using are sufficiently ambiguous to get me worried. Since the specification of the TLS extension "server name indication" is also somewhat wrong (which I only noticed when I implemented it), I would appreciate to get this clarified. On a mismatch of SNI in combination of resumption with the original SNI value (and I include _absent_ SNI on an initial SSLv2 CLIENT-HELLO in this count!), the server should behave according to the "Principle of least surprise", and **NOT** reject the connection (i.e. *NOT* abort with a fatal alert). If the server doesn't use SNI at all (which includes not supporting TLS extension SNI), then it should continue to ignore SNI on resumption. If the server uses SNI on initial full handshakes (those without any kind of resumption proposed by the client), then the server should perform a full TLS handshake if SNI differs from what was used for the session that was proposed for resumption. -Martin From nobody Fri Aug 8 16:25:09 2014 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 E3D4B1A015D for ; Fri, 8 Aug 2014 16:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 Km8benh2tgIy for ; Fri, 8 Aug 2014 16:25:06 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0A39B1A014E for ; Fri, 8 Aug 2014 16:25:05 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s78NP3WI020124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 01:25:03 +0200 (MEST) In-Reply-To: <20140808230653.C508F1ADFC@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Sat, 9 Aug 2014 01:25:03 +0200 (CEST) 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: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8xPpdJGOs0a4TAL3qv9K0Tnjkq4 Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 23:25:08 -0000 Ooops. Somehow the previous message wasn't what I wanted to say. When I implemented support for TLS extension SNI (at the lower levels or our software stack), then I implemented the "principle of least surprise" in the following fashion: Essentially, whenever a full handshake would result in the use of the same server certificate as the resumption proposed by the client, my server will perform session resumption, and ingnore SNI mismatches. -Martin Martin Rex wrote: > Salz, Rich asked: >> >> Can a client connect with an SNI extension and then later on resume >> or send a ticket with a different SNI value? > > AGL responded: >> >> At Google, we share ticket keys between servers, but the servers will >> reject a resumption if any part of the ClientHello causes a different >> certificate to be selected than was presented on the original >> connection. > > > Salz, Rich wrote: >> >> We do the same thing, but wasn't sure if it was legit. > > > The words you're using are sufficiently ambiguous to get me worried. > > Since the specification of the TLS extension "server name indication" > is also somewhat wrong (which I only noticed when I implemented it), > I would appreciate to get this clarified. > > On a mismatch of SNI in combination of resumption with the original SNI > value (and I include _absent_ SNI on an initial SSLv2 CLIENT-HELLO > in this count!), the server should behave according to the > "Principle of least surprise", and **NOT** reject the connection > (i.e. *NOT* abort with a fatal alert). > > If the server doesn't use SNI at all (which includes not supporting > TLS extension SNI), then it should continue to ignore SNI on resumption. > > > If the server uses SNI on initial full handshakes (those without any > kind of resumption proposed by the client), then the server should > perform a full TLS handshake if SNI differs from what was used for > the session that was proposed for resumption. From nobody Fri Aug 8 16:25:44 2014 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 289761A01C5 for ; Fri, 8 Aug 2014 16:25:43 -0700 (PDT) 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 ibHGNVRUMlFY for ; Fri, 8 Aug 2014 16:25:40 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AB11A014E for ; Fri, 8 Aug 2014 16:25:37 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id pv20so5197761lab.29 for ; Fri, 08 Aug 2014 16:25:36 -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:content-type; bh=xwoJlOz2Hyz5P9tzxo/LnXlOJbcOuoBa9kTJm9aIQ+k=; b=ZrJzdLd9f6DPLDHHXhe/BWi21KeQxASb4aYpfNKJ2FcutuLKWHUy1Ki3az3xUkn/g1 oRQw0cFw+Sbtgk0AKhMYmx0CNbCkL5irZ3MZybSVU7SVJVnUIpaOwWRETFQkjlprTpaU A9pd27Tcniqu3UBuhY0Qhv50TniuN9wiU+LvBTTjKQoEMyC8ZkyOFv7+4k4oxMQZijLi 9j1Swbs/MW63odCg6imTUSfDmqz+VlT/wBJ627LtcqERG+7LjThUWAjFXCp124UICfJ0 trckPeyxKtZEtkze62IRX7PEChbijRWt6WYrrmCu6l24mYSIhkho6feKy2x3aBkpYkdM rOhQ== MIME-Version: 1.0 X-Received: by 10.153.6.39 with SMTP id cr7mr4477390lad.66.1407540336384; Fri, 08 Aug 2014 16:25:36 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.170.37 with HTTP; Fri, 8 Aug 2014 16:25:35 -0700 (PDT) In-Reply-To: <20140808230653.C508F1ADFC@ld9781.wdf.sap.corp> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C8523@USMBX1.msg.corp.akamai.com> <20140808230653.C508F1ADFC@ld9781.wdf.sap.corp> Date: Fri, 8 Aug 2014 16:25:35 -0700 X-Google-Sender-Auth: BrknSuCXc8veURLcg1oztmJW9m8 Message-ID: From: Adam Langley To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wU6_eOGCheL1vsJHw9Dne_e1EYg Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 23:25:43 -0000 On Fri, Aug 8, 2014 at 4:06 PM, Martin Rex wrote: > and **NOT** reject the connection We're certainly not rejecting the connection - just the resumption, i.e. we'll make do a full handshake. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Aug 8 16:27:15 2014 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 9939F1A014E for ; Fri, 8 Aug 2014 16:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 wfoAdNgpagEr for ; Fri, 8 Aug 2014 16:27:12 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A18C11A01E2 for ; Fri, 8 Aug 2014 16:27:11 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s78NR7XE023687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Aug 2014 01:27:07 +0200 (MEST) In-Reply-To: To: Adam Langley Date: Sat, 9 Aug 2014 01:27:07 +0200 (CEST) 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: <20140808232707.B01BF1ADFC@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sPKSekljS1ARHWzcjHZrgfUqpzY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 08 Aug 2014 23:27:14 -0000 Adam Langley wrote: [ Charset UTF-8 unsupported, converting... ] > On Fri, Aug 8, 2014 at 4:06 PM, Martin Rex wrote: > > and **NOT** reject the connection > > We're certainly not rejecting the connection - just the resumption, > i.e. we'll make do a full handshake. Great! Thanks. -Martin From nobody Sat Aug 9 08:04:43 2014 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 9B52B1A0457 for ; Sat, 9 Aug 2014 08:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[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 56z8BnkyBAwU for ; Sat, 9 Aug 2014 08:04:37 -0700 (PDT) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7E61A02ED for ; Sat, 9 Aug 2014 08:04:36 -0700 (PDT) Received: by mail-yh0-f41.google.com with SMTP id b6so5048563yha.14 for ; Sat, 09 Aug 2014 08:04:36 -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:content-type; bh=Ummmjpt7Qjw0CjsKDBGZ6b/BKrOcx1RBmPTXSNSOBAU=; b=SpuGb476Xj+mpIO+BJ8GPsg+rIYMxGBm23cuhoe+NhxM9/8AVp4Gq07pT6rgngcLSE OgOg3X9HGXB3MfMcvaRJs5YOLxKKYEIM7QJv+LjjBXknUMhP1azn76ea1NfErXVt3XY+ KKqO2T2QmCATj9eSeJ5iKw5W/z3m4rHg+w4eY1a3I0KJzmoGLDv2ivgxIsaYvTvUcSAc UonAl/EZ42i06+Hbf1EQ0/0+A8Rcw4u47KRKXJTHS1JmyE5Ey/daFduz9970GxtYw3Na 5G4R3i0ezkJkgAhYb8N+YWtgki4VLJaLfUIxfoedn7NVRwYf5aqfV8l0J6KQ69l0viXN kxDw== MIME-Version: 1.0 X-Received: by 10.236.210.104 with SMTP id t68mr2451587yho.163.1407596325623; Sat, 09 Aug 2014 07:58:45 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sat, 9 Aug 2014 07:58:45 -0700 (PDT) Date: Sat, 9 Aug 2014 07:58:45 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HPi7PPjknWVy-DGQCcP3WhOlP_A Subject: [TLS] Inter-protocol attacks 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, 09 Aug 2014 15:04:40 -0000 Dear all, By combining fallback to SSLv3 and session ID based resumption, it is possible to do some major damage. This is due to Antoine Delignat-Lavaud according to whois. Slides are at https://bh.ht.vc/bh_slides.pdf. This depends on subtleties of TLS configuration and interactions with the same origin policy, and results in the sort of thing you don't want to see. Moral of the story: simplify, simplify, simplify! Sincerely, Watson Ladd From nobody Sat Aug 9 08:12:20 2014 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 DA01E1A0458 for ; Sat, 9 Aug 2014 08:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.294 X-Spam-Level: ** X-Spam-Status: No, score=2.294 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, 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 3lBPgfAXzTNo for ; Sat, 9 Aug 2014 08:12:16 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8501A0427 for ; Sat, 9 Aug 2014 08:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=XZ+R9dhFj0h+hI49QyFtRMQH6O+uknn2Ho4qC0aWioE=; b=bB8Sn9SM2ocD/pGNjVKddZjl6/Ox4QMFXR3Zg+YUg6Lk2Wzobv3528HeomqRF335o+HBGNVanKtQNU0SZ/K837WZa/ipriSHxC9lNLV9jtLw1J+G0Cgt5wx7yPo2erKwjHvPsvsWljDWmmP2XMYRI5cUAIme3pgZdEKlpeGudBI=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.brainspark.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XG7wN-000401-KB; Sat, 09 Aug 2014 16:48:16 +0200 Message-ID: <53E63465.4040907@polarssl.org> Date: Sat, 09 Aug 2014 16:47:01 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "" References: <53CD4B2C.5080906@polarssl.org> In-Reply-To: <53CD4B2C.5080906@polarssl.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/35hkS4VKeSYqgUuQlR88L3-MvWY Cc: Nagendra Modadugu Subject: Re: [TLS] DTLS HelloVerifyRequest.server_version 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, 09 Aug 2014 15:12:18 -0000 Hi again, I'm sorry to insist (cc-ing authors of RFC 6347) but unless these statements are clarified, as an implementer I'll have to just pick whatever behaviour looks most reasonable to me, a situation that standards are supposed to avoid. Manuel. On 21/07/2014 19:17, Manuel Pégourié-Gonnard wrote: > Hi, > > Sorry if I'm just being dense and fail to understand something very > obvious, but I have trouble understanding how the server_version field > of HelloVerifyRequest should be handled, according to section 4.2.1 of > RFC 6347. > > More precisely, I'm under the impression that the last paragraph of page > 15 and the first of page 16 contain contradictory statements: > > DTLS 1.2 server implementations SHOULD use DTLS > version 1.0 regardless of the version of TLS that is expected to be > negotiated. > > The server MUST use the same > version number in the HelloVerifyRequest that it would use when > sending a ServerHello. > > It seems to me that if a server obeys the MUST of the second sentence, > it cannot obey the SHOULD of the first one (unless of course it never > negotiates DTLS 1.2, which I assume is not the intention of the RFC). > > DTLS 1.2 and 1.0 clients MUST use the version solely to > indicate packet formatting (which is the same in both DTLS 1.2 and > 1.0) and not as part of version negotiation. In particular, DTLS 1.2 > clients MUST NOT assume that because the server uses version 1.0 in > the HelloVerifyRequest that the server is not DTLS 1.2 or that it > will eventually negotiate DTLS 1.0 rather than DTLS 1.2. > > Upon receipt of the ServerHello, the client > MUST verify that the server version values match. > > It seems to me that verifying the server version values match (between > HelloVerifyRequest and ServerHello) is actually using the version for > another goal that "to indicate packet formatting", something that seems > to be forbidden. > > Am I misinterpreting the text? > > Thanks, > Manuel > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From SRS0=Bv73=5D=acm.org=bmoeller@srs.kundenserver.de Sat Aug 9 08:48:25 2014 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 2DEEA1A046B for ; Sat, 9 Aug 2014 08:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.304 X-Spam-Level: X-Spam-Status: No, score=0.304 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 V_u__lae4BvZ for ; Sat, 9 Aug 2014 08:48:24 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (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 0050E1A0468 for ; Sat, 9 Aug 2014 08:48:23 -0700 (PDT) Received: from mail-yh0-f52.google.com (mail-yh0-f52.google.com [209.85.213.52]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0Lj2nG-1WhdsJ0rmQ-00dEDt; Sat, 09 Aug 2014 17:48:21 +0200 Received: by mail-yh0-f52.google.com with SMTP id t59so5015974yho.25 for ; Sat, 09 Aug 2014 08:48:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.101.138 with SMTP id b10mr26131890yhg.91.1407599300247; Sat, 09 Aug 2014 08:48:20 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Sat, 9 Aug 2014 08:48:19 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Sat, 9 Aug 2014 08:48:19 -0700 (PDT) In-Reply-To: References: Date: Sat, 9 Aug 2014 11:48:19 -0400 Message-ID: From: Bodo Moeller To: Watson Ladd Content-Type: multipart/alternative; boundary=20cf301b606f47148205003440a5 X-Provags-ID: V02:K0:+Z26dSHQjIhy7Fb2KaEh+4ozJL0Kl2EIv3an18il52v 72WBYgf1tz+ApV6/EKfZETZnPt8PPfNvhDX96D5/bEeCI4nCfl XsGKSPguf0BhlMa3BjRDEkqI56t/OI+zxR9dTfqMOw/Mh+m9bV LbLh201Pl7iOWbHmUSk6vVlJi1UdeGbZHlWiY+3S1vjlqtXDDF SgG7KOzMZJOGB47n6NlubOx22ItrUnHl8BUP7/Z9f6fb/r1bWv ngHU6Sp1Z6EGcc2b069AxnaBh2bckFgn9+x/7hIutJGbn2pG+j PZLIVX0A6w+SEEMHk/bSvDWIniNkjfZaMp1T7lekl54rdwWYmy MN0ZndmoGalP8snCyB/1FavtKtCv9rZ8NO4+fhUAmQuyLWOgOE rHIkhZgPTqLBDQg5KfDbYGrCFoCqodpHjg2GhAmYsgxrQuFHnY /8fFb X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UnK5TTiyfuC9USWdObDZnuLxM2U Cc: tls@ietf.org Subject: Re: [TLS] Inter-protocol attacks 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, 09 Aug 2014 15:51:05 -0000 --20cf301b606f47148205003440a5 Content-Type: text/plain; charset=UTF-8 Falling back to SSL 3.0 can lead to major problems, period. (SSL 3.0 was the main motivation for TLS_FALLBACK_SCSV - not this particular attack, but there are other options.) --20cf301b606f47148205003440a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Falling back to SSL 3.0 can lead to major problems, period.= =C2=A0 (SSL 3.0 was the main motivation for TLS_FALLBACK_SCSV - not this pa= rticular attack, but there are other options.)

--20cf301b606f47148205003440a5-- From nobody Sat Aug 9 11:00:23 2014 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 29AD91A00FF for ; Sat, 9 Aug 2014 11:00: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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9dgjZyLRu-RD for ; Sat, 9 Aug 2014 11:00:16 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797961A00F9 for ; Sat, 9 Aug 2014 11:00:15 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 560598182F; Sat, 9 Aug 2014 21:00:05 +0300 (EEST) Date: Sat, 9 Aug 2014 21:00:04 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140809180004.GA5890@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Edt15eE6ebl1UC_e1AbG0P8040s Cc: "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 09 Aug 2014 18:00:19 -0000 On Sat, Aug 09, 2014 at 07:58:45AM -0700, Watson Ladd wrote: > Dear all, > By combining fallback to SSLv3 and session ID based resumption, it is > possible to do some major damage. This is due to Antoine > Delignat-Lavaud according to whois. Slides are at > https://bh.ht.vc/bh_slides.pdf. This depends on subtleties of TLS > configuration and interactions with the same origin policy, and > results in the sort of thing you don't want to see. The prominent themes in that represetation (excluding the THS part) seem to be: - Cookies are just plain insecure[1] - HTTP servers issuing false authoritative responses. [1] And extractable bearer tokens in general. -Ilari From nobody Sun Aug 10 06:21:18 2014 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 D5D6B1A0717 for ; Sun, 10 Aug 2014 06:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 YxnVEkwYiMHc for ; Sun, 10 Aug 2014 06:21:10 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69AB11A071C for ; Sun, 10 Aug 2014 06:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=jRTXm9Q+3K6VuvEt2keMHEkmPqqe8pymZozIEkf9ydQ=; b=lZgEmVowKXMnbG3INQ0m8zxyUUMYf4amn6VINmCgyJnFDt9Wh29oRBPmMVi+E/pehBmuCptbFGYqxDaLeKdYozVs24U4cxda83hT24Q9AI9DyjWH8DkIeYqeX8Wn6Lnn; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1XGT3P-0006UN-Vy ; Sun, 10 Aug 2014 15:20:56 +0200 Message-ID: <53E771B7.7060609@delignat-lavaud.fr> Date: Sun, 10 Aug 2014 14:20:55 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Watson Ladd , "tls@ietf.org" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030009040102080505030309" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XOLfYjuib6Q1rCZBPdNRZ_2rgo8 Subject: Re: [TLS] Inter-protocol attacks 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, 10 Aug 2014 13:21:17 -0000 This is a multi-part message in MIME format. --------------030009040102080505030309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, Le 8/9/2014 3:58 PM, Watson Ladd a écrit : > By combining fallback to SSLv3 and session ID based resumption, it is > possible to do some major damage. This is an imprecise description. In the case you are referring to, the browser fallback behavior is abused to exploit the fact that some Mozilla servers had an improperly isolated server-side session cache (but, interestingly, it also had well-isolated session tickets, hence the need to prevent the victim from using tickets). This is another reason why draft-bmoeller-tls-downgrade-scsv should be adopted and implemented, as the ability of the attacker to get rid of the SNI and session ticket of the client can have bad, unexpected effects on some servers. > This is due to Antoine > Delignat-Lavaud according to whois. Slides are at > https://bh.ht.vc/bh_slides.pdf. This depends on subtleties of TLS > configuration and interactions with the same origin policy, and > results in the sort of thing you don't want to see. Indeed, the attacks I presented rely on improper server configuration, plus a very nasty legacy behavior of not rejecting HTTP requests that contain an unexpected Host header (I don't anticipate this behavior will change). However, TLS is not helping in some regards, and extensions that have been described as having no security impact whatsoever (including, but not limited to, SNI and session tickets) when in fact, there should have been a precise security discussion about the application behavior when using these extensions. > Moral of the story: simplify, simplify, simplify! What I am seeing is an exactly opposite trend. In particular, I would like to attract the attention of the TLS WG on the fact that Chrome introduced a very significant change to the authentication model of TLS that went virtually unnoticed. In SPDY, the TLS client session cache is no longer indexed by domain and port, but instead by domain set, IP and port: in classic TLS, an established connection or session can only be reused for the same domain, whereas in SPDY, it can be reused for any domain in the certificate verified when the session was created, provided that it points to the same IP as the original connection. The DNS condition is obviously meaningless to a network attacker, which means that all security guarantees that were previously session-specific should now be considered certificate-specific. I argued against this behavior with Adam Langley, for several reasons. First, it means that our miTLS efforts to prove authentication were once again thrown out of the window (not a big deal, but still, such a change deserved more than 3 lines in section 9.1.1 of draft-ietf-httpbis-http2); second, it explains why current webservers are happy to resume connections with an SNI that doesn't match the one in the initial connection. Furthermore, they are also accepting requests whose Host header doesn't match the SNI of the connection (because connection reuse not only occurs at the session level, but also at the connection level: if a connection is established with a certificate valid for *.x.com, the browser is allowed to send a request first to www.x.com, then to static.x.com on the same connection). Unsurprisingly, this freedom can be abused by the attacker to exploit an improperly-isolated server-side session cache. My third complain was that this behavior is not well-known and breaks certain things when one is unaware of it. For instance, client authentication and Channel ID become hazardous with multi-domain certificates. It may even get worse if a malicious domain appears in the certificate, a scenario that sounds unlikely but is in fact common in practice (e.g. CloudFlare loves to pack unrelated customer domains in their certificates). It also turns out that this feature has been buggy in Chrome for the past 2 years, allowing an attacker universal server impersonation (I didn't talk about it at Black Hat because the fix is not yet deployed). I'm fairly sure that if there had been more discussion, such an ugly bug could have been averted. For all these reasons, it may be a good idea to reconsider certain aspects of the design of TLS in an HTTP context. For instance, it would be useful to provide strong implementation requirements about the isolation of the session cache, and try to make an explicit decision about session-specific vs. certificate-specific security guarantees. Best, Antoine Delignat-Lavaud --------------030009040102080505030309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi,

Le 8/9/2014 3:58 PM, Watson Ladd a écrit :
By combining fallback to SSLv3 and session ID based resumption, it is
possible to do some major damage.

This is an imprecise description. In the case you are referring to, the browser fallback behavior is abused to exploit the fact that some Mozilla servers had an improperly isolated server-side session cache (but, interestingly, it also had well-isolated session tickets, hence the need to prevent the victim from using tickets). This is another reason why draft-bmoeller-tls-downgrade-scsv should be adopted and implemented, as the ability of the attacker to get rid of the SNI and session ticket of the client can have bad, unexpected effects on some servers.

  This is due to  Antoine
Delignat-Lavaud according to whois. Slides are at
https://bh.ht.vc/bh_slides.pdf. This depends on subtleties of TLS
configuration and interactions with the same origin policy, and
results in the sort of thing you don't want to see.

Indeed, the attacks I presented rely on improper server configuration, plus a very nasty legacy behavior of not rejecting HTTP requests that contain an unexpected Host header (I don't anticipate this behavior will change). However, TLS is not helping in some regards, and extensions that have been described as having no security impact whatsoever (including, but not limited to, SNI and session tickets) when in fact, there should have been a precise security discussion about the application behavior when using these extensions.

Moral of the story: simplify, simplify, simplify!

What I am seeing is an exactly opposite trend. In particular, I would like to attract the attention of the TLS WG on the fact that Chrome introduced a very significant change to the authentication model of TLS that went virtually unnoticed. In SPDY, the TLS client session cache is no longer indexed by domain and port, but instead by domain set, IP and port: in classic TLS, an established connection or session can only be reused for the same domain, whereas in SPDY, it can be reused for any domain in the certificate verified when the session was created, provided that it points to the same IP as the original connection. The DNS condition is obviously meaningless to a network attacker, which means that all security guarantees that were previously session-specific should now be considered certificate-specific.

I argued against this behavior with Adam Langley, for several reasons. First, it means that our miTLS efforts to prove authentication were once again thrown out of the window (not a big deal, but still, such a change deserved more than 3 lines in section 9.1.1 of draft-ietf-httpbis-http2); second, it explains why current webservers are happy to resume connections with an SNI that doesn't match the one in the initial connection. Furthermore, they are also accepting requests whose Host header doesn't match the SNI of the connection (because connection reuse not only occurs at the session level, but also at the connection level: if a connection is established with a certificate valid for *.x.com, the browser is allowed to send a request first to www.x.com, then to static.x.com on the same connection). Unsurprisingly, this freedom can be abused by the attacker to exploit an improperly-isolated server-side session cache. My third complain was that this behavior is not well-known and breaks certain things when one is unaware of it. For instance, client authentication and Channel ID become hazardous with multi-domain certificates. It may even get worse if a malicious domain appears in the certificate, a scenario that sounds unlikely but is in fact common in practice (e.g. CloudFlare loves to pack unrelated customer domains in their certificates).

It also turns out that this feature has been buggy in Chrome for the past 2 years, allowing an attacker universal server impersonation (I didn't talk about it at Black Hat because the fix is not yet deployed). I'm fairly sure that if there had been more discussion, such an ugly bug could have been averted.

For all these reasons, it may be a good idea to reconsider certain aspects of the design of TLS in an HTTP context. For instance, it would be useful to provide strong implementation requirements about the isolation of the session cache, and try to make an explicit decision about session-specific vs. certificate-specific security guarantees.

Best,

Antoine Delignat-Lavaud



--------------030009040102080505030309-- From nobody Sun Aug 10 09:16:44 2014 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 CCCA91A077B for ; Sun, 10 Aug 2014 09:16:41 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BLwB03PYlVU for ; Sun, 10 Aug 2014 09:16:40 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70801A0772 for ; Sun, 10 Aug 2014 09:16:39 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id u20so4909336oif.36 for ; Sun, 10 Aug 2014 09:16:39 -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-type; bh=xhTms1a43PMxPiTNmZ8hFfuWfkwU8Wti9A6WbF4k9oo=; b=wTIMbNQfsYFqlbXyduGmQ/902Xt/39TDEKyoPgEgxYMcwLiUQ99unEUV+Go0coN+7n peCRvuwwfv0sP6yOHlaRchvXX7+3OIGNsC9qT8VUo1EFGQZqRCe+S4dNHtWvFR7PsVka 238R6dT46IujUfny53r+h9nUJI1phsWpQl/xFxWS7RSaSoK2FPMjve/QKcb394AFt4nd fZkWcDVmSF1HtL0KN6uFsachI87vwz9NSkQFCO5Py8JazTs0Yb9Q+8BlqXzaMZ7I7oTL pzIr14mPXovIJu1n1e8icDj5kA1sQnX3sNPk0JPTpw7gDo3awp96wgc//wWOyKRkFtAP aUxA== MIME-Version: 1.0 X-Received: by 10.60.45.234 with SMTP id q10mr44117030oem.25.1407687399178; Sun, 10 Aug 2014 09:16:39 -0700 (PDT) Received: by 10.76.103.162 with HTTP; Sun, 10 Aug 2014 09:16:39 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C7185A0C850B@USMBX1.msg.corp.akamai.com> Date: Sun, 10 Aug 2014 21:46:39 +0530 Message-ID: From: Sajeev S To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11c21b06620538050048c320 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TqwQubUzksjYKKjc96500pvOJkU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 10 Aug 2014 16:16:41 -0000 --001a11c21b06620538050048c320 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As per RFC 6066--->Transport Layer Security (TLS) Extensions: Extension Definitions Note also that all the extensions defined in this document are relevant only when a session is initiated. A client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extensions as it would send if it were not attempting resumption. When a client includes one or more of the defined extension types in an extended client hello while requesting session resumption: - The server name indication extension MAY be used by the server when deciding whether or not to resume a session as described in Section 3 . - If the resumption request is denied, the use of the extensions is negotiated as normal. - If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session. Regards, Sajeev On Sat, Aug 9, 2014 at 1:48 AM, Salz, Rich wrote: > Can a client connect with an SNI extension and then later on resume or > send a ticket with a different SNI value? > > > > I couldn=E2=80=99t find it documented anywhere. Am I missing something, o= r should > we? > > > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge MA > > IM: rsalz@jabber.me Twitter: RichSalz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c21b06620538050048c320 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 
As per RFC 6066--->Transport Layer Security (TLS) Extensions: E=
xtension Definitions

Note also that all the extensions defined in this document a=
re
   relevant only when a session is initiated.  A client that requests
   session resumption does not in general know whether the server will
   accept this request, and therefore it SHOULD send the same extensions
   as it would send if it were not attempting resumption.  When a client
   includes one or more of the defined extension types in an extended
   client hello while requesting session resumption:

   -  The server name indication extension MAY be used by the server
      when deciding whether or not to resume a session as described in
      Section 3.

   -  If the resumption request is denied, the use of the extensions is
      negotiated as normal.

   -  If, on the other hand, the older session is resumed, then the
      server MUST ignore the extensions and send a server hello
      containing none of the extension types.  In this case, the
      functionality of these extensions negotiated during the original
      session initiation is applied to the resumed session.

Regards,
Sajeev

On Sat, Aug 9,= 2014 at 1:48 AM, Salz, Rich <rsalz@akamai.com> wrote:

Can a client connect with an SNI extensi= on and then later on resume or send a ticket with a different SNI value?=

=C2=A0

I cou= ldn=E2=80=99t find it documented anywhere. Am I missing something, or shoul= d we?

=C2=A0

--=C2=A0

<= p class=3D"MsoNormal">Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: rsalz@jabber.me Twitter: RichSalz

=C2=A0


____________________________________= ___________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls


--001a11c21b06620538050048c320-- From nobody Sun Aug 10 13:35:16 2014 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 3F5051A0045 for ; Sun, 10 Aug 2014 13:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHgiZI1cQpTE for ; Sun, 10 Aug 2014 13:35:14 -0700 (PDT) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 171621A000E for ; Sun, 10 Aug 2014 13:35:14 -0700 (PDT) Received: by mail-yk0-f174.google.com with SMTP id q9so5334407ykb.5 for ; Sun, 10 Aug 2014 13:35:13 -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:content-type; bh=lB8yJV50Vpsqwfyp8SalCjCdfIGdExdr5A2LjQ2Q0d4=; b=BBo0zHktHmnaBK8dOErn5vMB8QtjbjMVGmWja93F8+WLXOefbvrb/+myu4a/nmmAYi nUI36SwfXQyoHlSwu5M5XVz16Ujslvxb/139GXAF/+vDtMgeGMzk+zoQZCQliV+s9+9F ZK+vUFa73DTmjFE6H2cY21Za1VhRzhz7NYv3RUDPsSNGNf6/4pRVebRM0C3SBINZQi34 vJHGwpF8oHBqJMuqSPDhIbu7ThsqTMV7SxRuiCX9B8lan5DrKzhopdOpn6quN5Z6aPCC l0abt5HAdcQ7lXNn2AM/IwMzASGSd+bL0ZO5VZzYYGUX+A8yFfMkFUe5EViMM70G6oZt HfxQ== MIME-Version: 1.0 X-Received: by 10.236.99.39 with SMTP id w27mr36446380yhf.109.1407702913199; Sun, 10 Aug 2014 13:35:13 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 10 Aug 2014 13:35:13 -0700 (PDT) Date: Sun, 10 Aug 2014 13:35:13 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/U1R8HanKoVloGynU0ZOYdTwCf2A Subject: [TLS] CPU cost of 1RTT handshake 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, 10 Aug 2014 20:35:15 -0000 Dear all, Right now, instead of the server defining the group to be used and sending a key in the group, the client computes multiple keys, and the server selects one. This is very bad for embedded devices with constrained CPU, especially if they are connecting to a server over high-latency, low-bandwidth links. The justification for the current behavior is similarity to 0-RTT. But I'm not convinced that this actually makes the protocol or implementations any simpler, and it has real costs for many devices that will otherwise not adopt TLS or try to invent their own encrypted protocols. Sincerely, Watson Ladd From nobody Sun Aug 10 14:11:24 2014 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 93E3C1A0052 for ; Sun, 10 Aug 2014 14:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 dPyRskEZ6lXX for ; Sun, 10 Aug 2014 14:11:19 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6061C1A0051 for ; Sun, 10 Aug 2014 14:11:19 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 71DCC699B2; Mon, 11 Aug 2014 00:11:14 +0300 (EEST) Date: Mon, 11 Aug 2014 00:11:13 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140810211113.GA32711@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/s6zbaayloAtqJRpzocfSowNh2lA Cc: "tls@ietf.org" Subject: Re: [TLS] CPU cost of 1RTT handshake 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, 10 Aug 2014 21:11:21 -0000 On Sun, Aug 10, 2014 at 01:35:13PM -0700, Watson Ladd wrote: > Dear all, > > Right now, instead of the server defining the group to be used and > sending a key in the group, the client computes multiple keys, and the > server selects one. This is very bad for embedded devices with > constrained CPU, especially if they are connecting to a server over > high-latency, low-bandwidth links. Have the constrained client support just 1 group (most probably the cheapest one to compute, hopefully it is something secure)? Constrained clients hopefully don't go connecting to random servers. Supporting additional groups would mean additional code too, and ROM space is scarce in constrained devices (50-250kB _total_ might be typical). -Ilari From nobody Sun Aug 10 21:02:12 2014 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 2D3A81A02BD for ; Sun, 10 Aug 2014 21:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] 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 CJdy_BFv-O8C for ; Sun, 10 Aug 2014 21:02:08 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 17C1F1A01B0 for ; Sun, 10 Aug 2014 21:02:07 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D233548453; Mon, 11 Aug 2014 04:02:06 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4A620482E3; Mon, 11 Aug 2014 04:02:06 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 2F07998042; Mon, 11 Aug 2014 04:02:06 +0000 (GMT) Received: from Tereva.local (172.19.42.82) by usma1ex-cashub7.kendall.corp.akamai.com (172.27.105.23) with Microsoft SMTP Server (TLS) id 8.3.348.2; Mon, 11 Aug 2014 00:02:05 -0400 From: Brian Sniffen To: Martin Rex , "mrex@sap.com" In-Reply-To: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp> References: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.4.0) Date: Mon, 11 Aug 2014 00:02:03 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ba6LVCrON_N5K-2-dwQqgEi0LlY Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 11 Aug 2014 04:02:11 -0000 > Essentially, whenever a full handshake would result in the use of the > same server certificate as the resumption proposed by the client, > my server will perform session resumption, and ingnore SNI mismatches. So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a session with one is resumed to the other---that's unsurprising? I don't see a path all the way through to an attack, but it leads me to worry about a web app and a web server interacting in this way. At least for HTTP, the changing SNI will indicate a change of cookie and same-origin context. But RFC 6066 says: If there is a mismatch between the server name used by the client application and the server name of the credential chosen by the server, this mismatch will become apparent when the client application performs the server endpoint identification, at which point the client application will have to decide whether to proceed with the communication. So maybe the client applications all carefully follow this tricky advice. On the other hand, RFC 6066 also says: A server that implements [SNI] MUST NOT accept the request to resume the session if the server_name extension contains a different name. Instead, it proceeds with a full handshake to establish a new session. It doesn't sound like your server quite does that? -Brian -- Brian Sniffen Information Security Akamai Technologies From nobody Sun Aug 10 21:10:24 2014 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 9E8581A02CF for ; Sun, 10 Aug 2014 21:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 C7OharXHMXZD for ; Sun, 10 Aug 2014 21:10:20 -0700 (PDT) Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110311A01B0 for ; Sun, 10 Aug 2014 21:10:19 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so7912353wes.25 for ; Sun, 10 Aug 2014 21:10:18 -0700 (PDT) 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-type; bh=QmJHFx2xRTPE3qYGQZlBBXjfsixgjwNep/6LOljUCWQ=; b=nJEqySRsB6EssK9VTuWdq9m1kMtPSsdHRdsbcXw8vf4IjRBD8R+DxSikyl447tJP6n 8Ar45h+kcovzisDvB63PPFGoiJWPqti9yPA87S4LwOqQRZznIbtdS89VweNzCB2paWi9 0GxBDmC+BkU6h7MVpFko1P1OUcDoyxlS3sQi2qhk8/qz4TYbFneop6g0wKxbJhI7tyMq xPcNZf81NiqRUWyqE/x0AoOjF6MIXDw9GlXqajEUSe17z4G7JCmuvbo8FlpEJFEAsgZn TMdqKRx8hfpu+nse6hGT6Dz8sDbM/6HUx2pdoPU6fVJbbPrAqUXOML3vjLzO05+D5FeD 2+8Q== X-Gm-Message-State: ALoCoQmSb4sSsZrjyiAlE0Zr8JlZlp3Yq8GCldYV/CY/blk6k0D8My8U4EjrRB7Hbosiw7ZRhy6w X-Received: by 10.194.184.166 with SMTP id ev6mr17265071wjc.61.1407730218671; Sun, 10 Aug 2014 21:10:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 10 Aug 2014 21:09:38 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 10 Aug 2014 21:09:38 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bae49329fb85f050052bbd1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JZwv4d5l8EEHXAn7F5smpPkEDLk Cc: "tls@ietf.org" Subject: Re: [TLS] CPU cost of 1RTT handshake 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, 11 Aug 2014 04:10:22 -0000 --047d7bae49329fb85f050052bbd1 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 10, 2014 at 1:35 PM, Watson Ladd wrote: > Dear all, > > Right now, instead of the server defining the group to be used and > sending a key in the group, the client computes multiple keys, and the > server selects one. This is very bad for embedded devices with > constrained CPU, especially if they are connecting to a server over > high-latency, low-bandwidth links. > > The justification for the current behavior is similarity to 0-RTT. But > I'm not convinced that this actually makes the protocol or > implementations any simpler, and it has real costs for many devices > that will otherwise not adopt TLS or try to invent their own encrypted > protocols. > I'm not sure I would phrase the protocol behavior exactly as you have above. Rather, the client sends a list of the groups it supports (as in TLS 1.2). It can also send any number of (EC)DHE shares that match those groups. If the server selects a group that matches one of those shares, the handshake proceeds. Otherwise, the server tells the client which group it has selected and the client then adds a share from that group to the list. In other words: 1. The server does get to select the group as it can reject all the client's shares (thougb of course it cannot force the client to use a group it does not accept or know about).. 2. The client is not forced to send any shares. It can simply send an empty ClientKeyExchange (See S 7.4.2) and then wait for the server to select a group. In other words, it can act as you suggest above, but at the cost of a round trip. It's a explicit computation/ latency tradeoff. -Ekr --047d7bae49329fb85f050052bbd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Sun, Aug 10, 2014 at 1:35 PM, Watson Ladd <= watsonbladd@gmai= l.com> wrote:
Dear all,

Right now, instead of the server defining the group to be used and
sending a key in the group, the client computes multiple keys, and the
server selects one. This is very bad for embedded devices with
constrained CPU, especially if they are connecting to a server over
high-latency, low-bandwidth links.

The justification for the current behavior is similarity to 0-RTT. But
I'm not convinced that this actually makes the protocol or
implementations any simpler, and it has real costs for many devices
that will otherwise not adopt TLS or try to invent their own encrypted
protocols.

I'm not sure I would phr= ase the protocol behavior exactly as you have
above. Rather, the = client sends a list of the groups it supports =C2=A0(as in
TLS 1.= 2). It can also send any number of (EC)DHE shares that match
those groups. If the server selects a group that matches one of those<= /div>
shares, the handshake proceeds. Otherwise, the server tells the
client which group it has selected and the client then adds a shar= e
from that group to the list.

In other words:<= /div>

1. The server does get to select the group as =C2= =A0it can reject all the
client's shares (thougb of course it= cannot force the client to use
a group it does not accept or know about)..

2= . The client is not forced to send any shares. It can simply send
an empty ClientKeyExchange (See S 7.4.2) and then wait for the
server to select a group. In other words, it can act as you suggest
above, but at the cost of a round trip. It's a explicit computation/=
latency tradeoff.

-Ekr

--047d7bae49329fb85f050052bbd1-- From nobody Sun Aug 10 21:28:32 2014 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 2F27E1A02DB for ; Sun, 10 Aug 2014 21:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHJaWt4XyGKv for ; Sun, 10 Aug 2014 21:28:31 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB48C1A02D0 for ; Sun, 10 Aug 2014 21:28:30 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 9so5674574ykp.29 for ; Sun, 10 Aug 2014 21:28: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:content-type; bh=wAoOUmR4b0CSGqg+hKs915sqgjcSe/fz2lOxUldHedk=; b=jXwQwqNd/PdxO9NStSDwmeZ8MlsgQKCw7EQhn6QlCumaqZqd7PKZOjyiEZLMGBbs2w PWIpgAqX27/1J9SXLwrC04/nb/ZPyI2OTmZUzNAsN5Mgjy1xGMczqapbnMnqXIKQce3Z 0T0Oao9y72FgYoBFX4KuBHmvfuAz52jm/ugXn+J8YqX+EDMg8JfGaMq5Hl00eILJRNP9 lf1oakXiF0svmzxBw3fDfdw7bXv9zo9qvPmwtgBMtrjnPAgYuQHoFP7Im/h0JoUqb3FZ MWhZwIxI8U2UBXCpf2VDOPPC5KWWZR3NGw3l/YfA9gumfzRvrVG3YM95+CTAQJFvd55+ qSPg== MIME-Version: 1.0 X-Received: by 10.236.133.165 with SMTP id q25mr39475945yhi.62.1407731310113; Sun, 10 Aug 2014 21:28:30 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Sun, 10 Aug 2014 21:28:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 10 Aug 2014 21:28:30 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oSxtGB1ZNREMjTHU9e6Ezxe5Wm4 Cc: "tls@ietf.org" Subject: Re: [TLS] CPU cost of 1RTT handshake 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, 11 Aug 2014 04:28:32 -0000 On Sun, Aug 10, 2014 at 9:09 PM, Eric Rescorla wrote: > > > > On Sun, Aug 10, 2014 at 1:35 PM, Watson Ladd wrote: >> >> Dear all, >> >> Right now, instead of the server defining the group to be used and >> sending a key in the group, the client computes multiple keys, and the >> server selects one. This is very bad for embedded devices with >> constrained CPU, especially if they are connecting to a server over >> high-latency, low-bandwidth links. >> >> The justification for the current behavior is similarity to 0-RTT. But >> I'm not convinced that this actually makes the protocol or >> implementations any simpler, and it has real costs for many devices >> that will otherwise not adopt TLS or try to invent their own encrypted >> protocols. > > > I'm not sure I would phrase the protocol behavior exactly as you have > above. Rather, the client sends a list of the groups it supports (as in > TLS 1.2). It can also send any number of (EC)DHE shares that match > those groups. If the server selects a group that matches one of those > shares, the handshake proceeds. Otherwise, the server tells the > client which group it has selected and the client then adds a share > from that group to the list. > > In other words: > > 1. The server does get to select the group as it can reject all the > client's shares (thougb of course it cannot force the client to use > a group it does not accept or know about).. > > 2. The client is not forced to send any shares. It can simply send > an empty ClientKeyExchange (See S 7.4.2) and then wait for the > server to select a group. In other words, it can act as you suggest > above, but at the cost of a round trip. It's a explicit computation/ > latency tradeoff. It's a completely unnecessary one: the server can send its share, then the client goes, which is followed by the remaining messages. Why are we making 1-RTT unnecessarily expensive? Sincerely, Watson Ladd From nobody Sun Aug 10 21:29:07 2014 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 B9A051A02DF for ; Sun, 10 Aug 2014 21:29:05 -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, 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 oyeOhJL8810m for ; Sun, 10 Aug 2014 21:29:04 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90AA1A02E0 for ; Sun, 10 Aug 2014 21:29:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=k23xZ8mZ+6TEwLVJmBJ61uT1829NWIzr9FseFj6OAfI=; b=i2pDPF1TMw5PWzxWnukOJO1aB6yc387OsMUzgGAQMu1xQdKoVE7mDi/K0J6vK7eO9F1tgWPkBE5XtWdQMgo2kJcKlWAH/2ihBRsnDlW1L62qTEtHkAb6pMwC5FOd74lx; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1XGhDx-0003gG-3h ; Mon, 11 Aug 2014 06:28:45 +0200 Message-ID: <53E8467B.2090609@delignat-lavaud.fr> Date: Mon, 11 Aug 2014 05:28:43 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Brian Sniffen , Martin Rex References: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vNRwqMJJ3axpYHfeGEOPIuEmQVs Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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, 11 Aug 2014 04:29:05 -0000 Le 8/11/2014 5:02 AM, Brian Sniffen a écrit : >> Essentially, whenever a full handshake would result in the use of the >> same server certificate as the resumption proposed by the client, >> my server will perform session resumption, and ingnore SNI mismatches. > So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a > session with one is resumed to the other---that's unsurprising? I don't > see a path all the way through to an attack, but it leads me to worry > about a web app and a web server interacting in this way. Yes, it *is* indeed unsurprising: this behavior is the standard in SPDY and in the current HTTP2 draft even though it goes against the spirit of RFC 6066 -- see my message in the thread "inter-protocol attacks". Moreover, current webservers will also proceed with resumption even if the SNI provided by the client would have resulted in the server picking a different certificate. This is why resumption can be used to bypass certificate validation - this problem is related to yet another TLS API problem with the SNI callback. In many cases, the application may not even get to see the certificate selection callback from TLS when doing resumption. Best, Antoine Delignat-Lavaud From nobody Sun Aug 10 21:37:32 2014 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 70B2D1A02E3 for ; Sun, 10 Aug 2014 21:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 oY8ZXVbtbzWc for ; Sun, 10 Aug 2014 21:37:29 -0700 (PDT) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4401A02E0 for ; Sun, 10 Aug 2014 21:37:29 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id k48so7989220wev.41 for ; Sun, 10 Aug 2014 21:37:28 -0700 (PDT) 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-type; bh=Qhxk1tAuIvSOjOH0hhJ0Yc9wVnJ1TQBjKTFXJtQgjzc=; b=TcxfGySNTDvl3KAiX9u1KTSv4iThtvwVIM9FTOFEdpJV0oakaeNmJPvwOw27oY0BFl mSX0qrlyQOIkZUVLT9r9wZ+KwHBB0K0qP6txWjNt7tSjZyuSrK8a6mQfMIKjCnjIYGKQ /NOMNGtjZwGGh8WfC6XDqi+U5XLaTKxGCMUp0PKtEXsmAcle/LvW2/RXR2xiG4F9Aam8 6hdfQBxHWGYgdcmSYhLyJLhEoxVJ26u6bvwu7setnhDxAP31jx30romSRqcnI9RV6bbo pwXz9c+n0zK0P1wFLTazUZoCrKirahVLbH8Wo5E4IiDIKwZJdGbKFQYRhXsHnYJQywyi Ecog== X-Gm-Message-State: ALoCoQnvpBl5RnHDwpkwvIc0Cfx1ivF2Ceee+ABwBb9MvbTtJRFUPHit44mQk/DiwUJkpFQkevKD X-Received: by 10.180.37.77 with SMTP id w13mr22269147wij.78.1407731847981; Sun, 10 Aug 2014 21:37:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 10 Aug 2014 21:36:47 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: From: Eric Rescorla Date: Sun, 10 Aug 2014 21:36:47 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=e89a8f647021bcff110500531cff Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QjVPYhnmzIqAGjxmwPEDeWynS9E Cc: "tls@ietf.org" Subject: Re: [TLS] CPU cost of 1RTT handshake 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, 11 Aug 2014 04:37:30 -0000 --e89a8f647021bcff110500531cff Content-Type: text/plain; charset=UTF-8 On Sun, Aug 10, 2014 at 9:28 PM, Watson Ladd wrote: > > > 2. The client is not forced to send any shares. It can simply send > > an empty ClientKeyExchange (See S 7.4.2) and then wait for the > > server to select a group. In other words, it can act as you suggest > > above, but at the cost of a round trip. It's a explicit computation/ > > latency tradeoff. > > It's a completely unnecessary one: the server can send its share, then > the client goes, which is followed by the remaining messages. Yes, one could do that, but it has different properties: 1. It doesn't allow the server to encrypt its handshake data on the first flight and therefore does not conceal it from passive observers [0] 2. It doesn't allow the server to send data to the client on its first flight (if it doesn't care about the client's identity). -Ekr [0] Or active observers in cases like WebRTC where the server doesn't respond to any client. --e89a8f647021bcff110500531cff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Aug 10, 2014 at 9:28 PM, Watson Ladd <watsonbladd@gmail.com>= ; wrote:
> 2. The client is not forced to send any shares. It can simply send
> an empty ClientKeyExchange (See S 7.4.2) and then wait for the
> server to select a group. In other words, it can act as you suggest > above, but at the cost of a round trip. It's a explicit computatio= n/
> latency tradeoff.

It's a completely unnecessary one: the server can send its = share, then
the client goes, which is followed by the remaining messages.
<= div>
Yes, one could do that, but it has different properties:=

1. It doesn't allow the server to encrypt its= handshake data on
the first flight and therefore does not conceal it from passive
<= div>observers [0]=C2=A0

2. It doesn't allow th= e server to send data to the client on its first
flight (if i= t doesn't care about the client's identity).

-Ekr

[0] Or active observers i= n cases like WebRTC where the server
doesn't respond to any c= lient.

--e89a8f647021bcff110500531cff-- From nobody Sun Aug 10 23:06:51 2014 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 578961A030F for ; Sun, 10 Aug 2014 23:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNi0pdqHkH28 for ; Sun, 10 Aug 2014 23:06:45 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CDA91A030E for ; Sun, 10 Aug 2014 23:06:45 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so7959505wgh.27 for ; Sun, 10 Aug 2014 23:06: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:date:message-id:subject:from:to :cc:content-type; bh=6GxpX/E4ZIml19730QI2o19XjZxDbiqQGlJBI9H+bsg=; b=Ve5ulL+4+8X67j7k8+Ds0jQFNlJb6TLvWak/6OidFuCS3ucS5ApeICt+IQOl+eO71S BZ/lc/YAycnanVSliD1OO+8ZPVqovRKdlG/B5VJrbbpe2gyPkPCgwreg3FLKdOrVINXF w3PaVtW6TbQNG4Ry3yi+yiFi3foLfy3Eddt8H6KiHVoH9slFlGmWOZcTuEW6k8SJOZVH qGi8IDoaxhsD8VIiDfMHFIza8TqEA4UqwjEF0tsHFA2/8m6IFzGICKBZVnF0oDIcPsgv +PCipkmYZMUPfIH7TdNWYKiJ1TH1gHBcw/r26Vq07l2MkjtIgDjsP2DinIe9XfZUyUo5 sakA== MIME-Version: 1.0 X-Received: by 10.180.103.74 with SMTP id fu10mr23191376wib.47.1407737204015; Sun, 10 Aug 2014 23:06:44 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Sun, 10 Aug 2014 23:06:43 -0700 (PDT) In-Reply-To: <53E771B7.7060609@delignat-lavaud.fr> References: <53E771B7.7060609@delignat-lavaud.fr> Date: Sun, 10 Aug 2014 23:06:43 -0700 Message-ID: From: Martin Thomson To: Antoine Delignat-Lavaud Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/S08AYiPuXN5Eogwlt-mSJiCRbCQ Cc: "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 11 Aug 2014 06:06:47 -0000 On 10 August 2014 06:20, Antoine Delignat-Lavaud wrote: > Chrome introduced a very significant change to the authentication model of > TLS that went virtually unnoticed. In SPDY, the TLS client session cache is > no longer indexed by domain and port, but instead by domain set, IP and > port: in classic TLS, an established connection or session can only be > reused for the same domain, whereas in SPDY, it can be reused for any domain > in the certificate verified when the session was created, provided that it > points to the same IP as the original connection. The DNS condition is > obviously meaningless to a network attacker, which means that all security > guarantees that were previously session-specific should now be considered > certificate-specific. The behaviour you describe isn't quite correct, because - I believe - that it requires that the DNS resolve to the same IP (or that one of a set of alternative values point there). But that's not a particularly important detail, DNS has never been a part of the security story for https. It's a big part of http, but we all know what you get there. Either way, this behaviour has been discussed at some length and was not found lacking in the SPDY/HTTP2 context. Yes, HTTP/2 standardizes this practice. The poor handling of Host header fields in HTTP/1.1 means that it will probably never be advisable to do something like this there. As always, I caution that we have to be careful to distinguish between attacks on implementations and attacks on standards. I am aware that there are bugs in implementations. I'm also told that they are somewhat difficult to exploit. From nobody Mon Aug 11 00:24:46 2014 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 CB7F01A0350 for ; Mon, 11 Aug 2014 00:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 6FsbX0ndaTSP for ; Mon, 11 Aug 2014 00:24:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 9677A1A034E for ; Mon, 11 Aug 2014 00:24:43 -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 (8.14.4/8.14.4) with ESMTP id s7B7OgrE027653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Aug 2014 03:24:42 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7B7OdH5020219 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 11 Aug 2014 03:24:41 -0400 Message-ID: <1407741884.2390.3.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Manuel =?ISO-8859-1?Q?P=E9gouri=E9-Gonnard?= Date: Mon, 11 Aug 2014 09:24:44 +0200 In-Reply-To: <53CD4B2C.5080906@polarssl.org> References: <53CD4B2C.5080906@polarssl.org> 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: http://mailarchive.ietf.org/arch/msg/tls/EnJEFZXexm_VBFWGxJHkOr9od04 Cc: "" Subject: Re: [TLS] DTLS HelloVerifyRequest.server_version 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, 11 Aug 2014 07:24:44 -0000 On Mon, 2014-07-21 at 19:17 +0200, Manuel Pégourié-Gonnard wrote: > Hi, > > Sorry if I'm just being dense and fail to understand something very > obvious, but I have trouble understanding how the server_version field > of HelloVerifyRequest should be handled, according to section 4.2.1 of > RFC 6347. > > More precisely, I'm under the impression that the last paragraph of page > 15 and the first of page 16 contain contradictory statements: > DTLS 1.2 server implementations SHOULD use DTLS > version 1.0 regardless of the version of TLS that is expected to be > negotiated. If I remember well the reason for that is that the HelloVerifyRequest is sent without any state being considered. That is, it is very likely that the server does not know the protocol that will actually be negotiated in the handshake (remember that HelloVerifyRequest is sent in a stateless way to prevent DoS on the server). > The server MUST use the same > version number in the HelloVerifyRequest that it would use when > sending a ServerHello. I'd fill an errata for that, the text as you notice looks inconsistent. regards, Nikos From nobody Mon Aug 11 09:54:26 2014 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 BC5101A066C for ; Mon, 11 Aug 2014 09:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 BEI75C8bhpTn for ; Mon, 11 Aug 2014 09:54:23 -0700 (PDT) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9491A06D6 for ; Mon, 11 Aug 2014 09:54:22 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id d1so4585525wiv.13 for ; Mon, 11 Aug 2014 09:54:21 -0700 (PDT) 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 :content-type; bh=o2lS+/XjX2PiLxbUErxfoeKZsSoFwQ9bzyPO6ksUfl0=; b=dfj7j0AqgnZpd/2lAxcF+eLuR7k93nMUIAtybqA5+vyZk5anT0MNX9v/OwsBwqrvZ3 mursChQr4XLhp7es00L2Mr1Q52FygxtU/hnnU+zrlpuFf6Dc3l2JWHwAQEYPu3uRU0mi V5fBhwjYJKF4gsTfm5GDsgrVn+sf725thnN0H+gu3SQkvuxYwJTGkNZMJ9jfRk/4idKm ExLJ+ZCqoPQFTFR1+bbPZRSiCk2WCNnlbVuiU+OMstSZ13M4iKfGXDT8pHSjQm/NZngg k6oiz5ZZIFvqcj+KWGJbPKr5o8m4/CHReQH88VyEwfp6dJFjyJSY7sf4TNCOli59FlVV qENg== X-Gm-Message-State: ALoCoQlfREHvP+UsjrnrpPstVrmL7f/ek2wUvilnH0F9e4OM3S4JjX4oDYVZQZkYQmFLjelJeWSw X-Received: by 10.194.91.228 with SMTP id ch4mr56087160wjb.59.1407776061539; Mon, 11 Aug 2014 09:54:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 11 Aug 2014 09:53:41 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:6049:62d9:3779:ea46] From: Eric Rescorla Date: Mon, 11 Aug 2014 09:53:41 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bd91d9e125f5205005d684f Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mMNj7XmuH680_vaHD9gIGZZ1zNY Subject: [TLS] "Draft Version" extension 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, 11 Aug 2014 16:54:24 -0000 --047d7bd91d9e125f5205005d684f Content-Type: text/plain; charset=UTF-8 Experience with HTTP 2 has shown that it's convenient to be able to distinguish which draft version you're implementing so you don't end worrying about interop between various I-D versions. Accordingly, for TLS 1.3 I'd like to define a temporary extension that indicates which TLS 1.3 draft it implements. The idea here is that the client would signal TLS 1.3 and then "draft 3" and the server would only negotiate 1.3 if it had a compatible draft. Otherwise it would fall back to TLS 1.2. My proposed extension would be as follows: struct { uint16 draft_version; } DraftVersionExtension; And would have a code point in the (unofficially) experimental range: 0xff02. We would not need a permanent allocation since once TLS 1.3 ships you would send no extension at all. I've implemented this in NSS and it's trivial to do. Thoughts? -Ekr --047d7bd91d9e125f5205005d684f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Experience with HTTP 2 has shown that it's convenient = to be able to
distinguish which draft version you're implementing s= o you don't end
worrying about interop between various I-D ve= rsions. Accordingly,
for TLS 1.3 I'd like to define a temporary extension that indicate= s which
TLS 1.3 draft it implements. The idea here is that the cl= ient would signal
TLS 1.3 and then "draft 3" and the se= rver would only negotiate 1.3 if
it had a compatible draft. Otherwise it would fall back to TLS 1.2.

My proposed extension would be as follows:

struct {
=C2=A0 uint16 draft_version;
}= DraftVersionExtension;

And would have a code point in the (unofficially) exper= imental range: 0xff02.
We would not need a permanent allocation s= ince once TLS 1.3 ships you
would =C2=A0send no extension at all.=

I've implemented this in NSS and it's trivial t= o do.

Thoughts?
-Ekr


--047d7bd91d9e125f5205005d684f-- From nobody Mon Aug 11 10:06:27 2014 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 120E71A05C0 for ; Mon, 11 Aug 2014 10:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 wH8Iew-I-gtk for ; Mon, 11 Aug 2014 10:06:23 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 624CB1A04A8 for ; Mon, 11 Aug 2014 10:06:23 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s7BH6J1x028289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Aug 2014 19:06:19 +0200 (MEST) In-Reply-To: To: Brian Sniffen Date: Mon, 11 Aug 2014 19:06:19 +0200 (CEST) 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: <20140811170619.0509F1AE02@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/suQJY7wfRDQ7tasOUG-qwQSc9OQ Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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: Mon, 11 Aug 2014 17:06:26 -0000 Brian Sniffen wrote: > > On the other hand, RFC 6066 also says: > > A server that implements [SNI] MUST NOT accept the request > to resume the session if the server_name extension contains a > different name. Instead, it proceeds with a full handshake to > establish a new session. > > It doesn't sound like your server quite does that? Correct, my server doesn't follow that formally provable invalid wording above in the spec. As I said, I only realized this fallacy in the spec when I implemented it. TLS session resumption is a performance optimization that happens at the TLS level. TLS server endpoint identification and selection/provisioning of suitable server credentials is a matter of the application on top of TLS. Whether and how often the server uses resumption from the cache or full handshake is the result of the caching&resumption strategies & lifetimes of client plus server combined. The purpose of SNI a hint from the client to the server which kind of server endpoint identification the client is going to perform, and the server may use that hint in selecting the most appropriate server certificate. If a full handshake and a session resumption will result in the use of the exact same server certificate, then the Server can freely choose which way to go (resume or full handshake), provided that the client offers session resumption and the server is capable of accepting it. The server endpoint identification performed by the client is an application-level matter, and ought to be performed independent of whether a TLS session resumption of a TLS full handshake is performed. -Martin From nobody Mon Aug 11 10:15:33 2014 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 14D2E1A066C for ; Mon, 11 Aug 2014 10:15:31 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XafNfHheH-8u for ; Mon, 11 Aug 2014 10:15:29 -0700 (PDT) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C6A1A0661 for ; Mon, 11 Aug 2014 10:15:29 -0700 (PDT) Received: by mail-yh0-f49.google.com with SMTP id b6so6498552yha.36 for ; Mon, 11 Aug 2014 10:15: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:content-type; bh=qAyxxTfcIuUV9TPVKbFsB4eMQQI3ae3JZ2iRd/h0LGM=; b=fNelzgB0Leuhsiq0FHv4GZQ/a3JhBiFhA0WUGq21886BOwjnbkGmQ8hyk3Hw2WGmbf 54jTqcntz1mOcSj+ru+5Ktg9XbDYFM7kZkzcNMXIiPZSmnpp1jVnZMQQ2RNfEjqLVapV piZxq1wEaBawbeiEsqa9Ew8pJXr/MjeHIUJ9Oh8rTZUAJSVAfDRofRTJJ84PN3bb6y2q XkBf3P58TgW4Re2/2y0TI2Xh+Z1yPXyggwN0bl7m7hfgMuBERfR1v7wn66P2XqjSa7b4 gvEn4WFRT6RmoI2kU4KyuL+VmyDqzpzMEq7Qt0t5N4X0OjsQNoUE/xbt8TLTShXqe2iC UQVQ== MIME-Version: 1.0 X-Received: by 10.236.134.208 with SMTP id s56mr45069876yhi.4.1407777328881; Mon, 11 Aug 2014 10:15:28 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 11 Aug 2014 10:15:28 -0700 (PDT) Received: by 10.170.202.8 with HTTP; Mon, 11 Aug 2014 10:15:28 -0700 (PDT) In-Reply-To: References: Date: Mon, 11 Aug 2014 10:15:28 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: multipart/alternative; boundary=20cf303a2bbb9c683705005db36b Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zdMB9Oe5M_-fjW2BkVwN0DqUaoc Cc: tls@ietf.org Subject: Re: [TLS] "Draft Version" extension 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, 11 Aug 2014 17:15:31 -0000 --20cf303a2bbb9c683705005db36b Content-Type: text/plain; charset=UTF-8 On Aug 11, 2014 9:55 AM, "Eric Rescorla" wrote: > > Experience with HTTP 2 has shown that it's convenient to be able to > distinguish which draft version you're implementing so you don't end > worrying about interop between various I-D versions. Accordingly, > for TLS 1.3 I'd like to define a temporary extension that indicates which > TLS 1.3 draft it implements. The idea here is that the client would signal > TLS 1.3 and then "draft 3" and the server would only negotiate 1.3 if > it had a compatible draft. Otherwise it would fall back to TLS 1.2. How would the server negotiate v2 vs v3? Nothing in the spec requires the pain of a version jump. Other then that I think it is reasonable. > > My proposed extension would be as follows: > > struct { > uint16 draft_version; > } DraftVersionExtension; > > And would have a code point in the (unofficially) experimental range: 0xff02. > We would not need a permanent allocation since once TLS 1.3 ships you > would send no extension at all. > > I've implemented this in NSS and it's trivial to do. > > Thoughts? > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --20cf303a2bbb9c683705005db36b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 11, 2014 9:55 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
> Experience with HTTP 2 has shown that it's convenient to be able t= o
> distinguish which draft version you're implementing so you don'= ;t end
> worrying about interop between various I-D versions. Accordingly,
> for TLS 1.3 I'd like to define a temporary extension that indicate= s which
> TLS 1.3 draft it implements. The idea here is that the client would si= gnal
> TLS 1.3 and then "draft 3" and the server would only negotia= te 1.3 if
> it had a compatible draft. Otherwise it would fall back to TLS 1.2.

How would the server negotiate v2 vs v3? Nothing in the spec= requires the pain of a version jump. Other then that I think it is reasona= ble.

>
> My proposed extension would be as follows:
>
> struct {
> =C2=A0 uint16 draft_version;
> } DraftVersionExtension;
>
> And would have a code point in the (unofficially) experimental range: = 0xff02.
> We would not need a permanent allocation since once TLS 1.3 ships you<= br> > would =C2=A0send no extension at all.
>
> I've implemented this in NSS and it's trivial to do.
>
> Thoughts?
> -Ekr
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--20cf303a2bbb9c683705005db36b-- From nobody Mon Aug 11 10:27:06 2014 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 046DC1A045E for ; Mon, 11 Aug 2014 10:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 dwqMQnZnI3_7 for ; Mon, 11 Aug 2014 10:27:02 -0700 (PDT) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E4971A0037 for ; Mon, 11 Aug 2014 10:27:02 -0700 (PDT) Received: by mail-wg0-f47.google.com with SMTP id b13so8653355wgh.6 for ; Mon, 11 Aug 2014 10:27:01 -0700 (PDT) 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-type; bh=vsfDBdv3lN3NkOMznYJUzpdF+8nXBGGccNl1p0UCLHA=; b=Sy1YOo6m2c8YkkPyoiMDJSZSvLjUhzr1QIZzlDKE98pQt7k2ArNsaAVclPAqBEzx5A vK+89Tyk47eoZ0W+xtkefCXiMEh7yraQM8hfcANHktJPZgyd0TVJB0sz4/jNHyxFpjk9 QxYsABMK1m0dapMVeB6WTRR+s5oH0cO5+/GzCbppXQFG0N7n3JakoHHZW7vknVTFi3t5 uvIEgApu0iSeqZ7mCRny9p7cWMztw1o0Snz6Y0uGIoRRVeAzrSvod9YgukYfHSETAxat IMNcpn682Fn3ft8895gZXH69zFzlJRh4zN3u4jdc000jOUTs4Te/Sdzm1RiZ4fQlOol+ CW0g== X-Gm-Message-State: ALoCoQnlcQSCbIKn5Z/gP4A1UyoJILq641nxGEck06abiJLK7s0rN1418yUUesZDtHJPujnbqWcn X-Received: by 10.180.186.3 with SMTP id fg3mr20754458wic.78.1407778021024; Mon, 11 Aug 2014 10:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 11 Aug 2014 10:26:20 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:6049:62d9:3779:ea46] In-Reply-To: References: From: Eric Rescorla Date: Mon, 11 Aug 2014 10:26:20 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11c26aceddbe1105005ddc75 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hsEvAGJ3cS-Z2J2A2T6oBOqjHT4 Cc: "tls@ietf.org" Subject: Re: [TLS] "Draft Version" extension 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, 11 Aug 2014 17:27:04 -0000 --001a11c26aceddbe1105005ddc75 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 11, 2014 at 10:15 AM, Watson Ladd wrote: > > On Aug 11, 2014 9:55 AM, "Eric Rescorla" wrote: > > > > Experience with HTTP 2 has shown that it's convenient to be able to > > distinguish which draft version you're implementing so you don't end > > worrying about interop between various I-D versions. Accordingly, > > for TLS 1.3 I'd like to define a temporary extension that indicates which > > TLS 1.3 draft it implements. The idea here is that the client would > signal > > TLS 1.3 and then "draft 3" and the server would only negotiate 1.3 if > > it had a compatible draft. Otherwise it would fall back to TLS 1.2. > > How would the server negotiate v2 vs v3? > You negotiate TLS 1.2 versus TLS 1.3 via the usual mechanism, I.e., the version in the ClientHello. -Ekr --001a11c26aceddbe1105005ddc75 Content-Type: text/html; charset=UTF-8



On Mon, Aug 11, 2014 at 10:15 AM, Watson Ladd <watsonbladd@gmail.com> wrote:


On Aug 11, 2014 9:55 AM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
> Experience with HTTP 2 has shown that it's convenient to be able to
> distinguish which draft version you're implementing so you don't end
> worrying about interop between various I-D versions. Accordingly,
> for TLS 1.3 I'd like to define a temporary extension that indicates which
> TLS 1.3 draft it implements. The idea here is that the client would signal
> TLS 1.3 and then "draft 3" and the server would only negotiate 1.3 if
> it had a compatible draft. Otherwise it would fall back to TLS 1.2.

How would the server negotiate v2 vs v3?


You negotiate TLS 1.2 versus TLS 1.3 via the usual mechanism, I.e., the version
in the ClientHello.

-Ekr

--001a11c26aceddbe1105005ddc75-- From nobody Mon Aug 11 10:52:08 2014 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 985D31A049D for ; Mon, 11 Aug 2014 10:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.3 X-Spam-Level: X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6] 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 TJ6lz3f8iYZf for ; Mon, 11 Aug 2014 10:52:03 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08611A048D for ; Mon, 11 Aug 2014 10:52:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EA3D72AB2BD; Mon, 11 Aug 2014 17:52:00 +0000 (UTC) Date: Mon, 11 Aug 2014 17:52:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140811175200.GQ14392@mournblade.imrryr.org> References: <20140808232503.6480A1ADFC@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tgFhdQSpcBrtSzyETqNNrxk7CNE Subject: Re: [TLS] SNI and tickets and resumption 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: Mon, 11 Aug 2014 17:52:06 -0000 On Mon, Aug 11, 2014 at 12:02:03AM -0400, Brian Sniffen wrote: > > Essentially, whenever a full handshake would result in the use of the > > same server certificate as the resumption proposed by the client, > > my server will perform session resumption, and ingnore SNI mismatches. > > So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a > session with one is resumed to the other---that's unsurprising? I don't > see a path all the way through to an attack, but it leads me to worry > about a web app and a web server interacting in this way. With DANE TLSA records of the form: _443._tcp.www.nsa.gov. IN CNAME _443._tcp.www.example.net. _443._tcp.www.eff.org. IN CNAME _443._tcp.www.example.net. _443._tcp.www.example.net. IN TLSA DANE-EE(3) SPKI(1) SHA2-256(1) {blob} and supposing that at some future date, browsers support RFC 6698 and updates, the name in the server certificate is entirely irrelevant, the name to key binding is in DNS. The HTTPS server is then authenticated by its public key alone. The clients will then send SNI with either "www.nsa.gov" or "www.eff.org" (on the off chance that the server cares), but there is nothing a-priori wrong with a single certificate associated with multiple domains (as unlikely as it may seem that eff.org and nsa.gov would choose the same hosting provider). > On the other hand, RFC 6066 also says: > > A server that implements [SNI] MUST NOT accept the request > to resume the session if the server_name extension contains a > different name. Instead, it proceeds with a full handshake to > establish a new session. Some client caches are poorly designed, and their cache lookup key might be only the peer IP:port and not the associated domain or other relevant data. Servers should tolerate this at least to the extent performing a full handshake instead of resumption. Resuming with mismatched SNI is perhaps in conflict with 6066, but seems harmless from a server perspective, the error is on the client side, and if there are security consequences, it seems to me that the exposure is there as soon as the client offers to resumt the mismatched session. I think it is the client that SHOULD NOT resume sessions across mismatched SNI values, since it can no longer be sure it is connected to the intended server. I see little harm in the server saying yes if the certificate is the same in either case. -- Viktor. From nobody Mon Aug 11 11:32:17 2014 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 1A9C11A0735 for ; Mon, 11 Aug 2014 11:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 mJo_dJ4pfXYM for ; Mon, 11 Aug 2014 11:32:14 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 444881A0066 for ; Mon, 11 Aug 2014 11:32:14 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s7BIVxig019139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Aug 2014 20:31:59 +0200 (MEST) In-Reply-To: <53E8467B.2090609@delignat-lavaud.fr> To: Antoine Delignat-Lavaud Date: Mon, 11 Aug 2014 20:31:59 +0200 (CEST) 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: <20140811183159.145C81AE02@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/glHAST80fwzLH6W3MjkCfK_XCQ0 Cc: Adam Langley , "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] SNI and tickets and resumption 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: Mon, 11 Aug 2014 18:32:16 -0000 Antoine Delignat-Lavaud wrote: > Le 8/11/2014 5:02 AM, Brian Sniffen a =E9crit : >>> Essentially, whenever a full handshake would result in the use of the >>> same server certificate as the resumption proposed by the client, >>> my server will perform session resumption, and ingnore SNI mismatches. >> So if a server has a giant SAN cert for `eff.org` and `nsa.gov`, and a >> session with one is resumed to the other---that's unsurprising? I don't >> see a path all the way through to an attack, but it leads me to worry >> about a web app and a web server interacting in this way. >=20 > Yes, it *is* indeed unsurprising: this behavior is the standard in SPDY= =20 > and in the current HTTP2 draft even though it goes against the spirit of= =20 > RFC 6066 -- see my message in the thread "inter-protocol attacks". It is not against the *spirit* (aka underlying design) of TLS extension server name indication, only against the current, formally provable defective ad-hoc wording that was used to describe one aspect of the behaviour (keep in mind that RFC at the "Proposed Standard" maturity level must be assumed to contain defects such as this one.) > > Moreover, current webservers will also proceed with resumption even if=20 > the SNI provided by the client would have resulted in the server picking= =20 > a different certificate. This behaviour would be against the spirit of rfc6066, and against the "principle of least surprise". It would indicate a significant lack of robustness when fiddling with the session cache lifetime on client or sorver or when disabling the client-side or server-side session cache would affect application behaviour / usage scenarios. > > This is why resumption can be used to bypass certificate validation > - this problem is related to yet another TLS API problem with the > SNI callback. In many cases, the application may not even get to see > the certificate selection callback from TLS when doing resumption. According to the TLS specification (last paragraph of Introduction), the server endpoint identification is something that the application on top of TLS performs, whereas TLS session caching and resumption is something that happens transparently within the TLS protocol stack. Last sentence of Section 1. Introduction https://tools.ietf.org/html/rfc2246#page-4 https://tools.ietf.org/html/rfc5246#page-5 how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. The TLS client app ought to perform server endpoint identification "interpret the authentication certificates exchanged" independent of whether the TLS connection is established with a full TLS handshake or and abbreviated TLS handshake (aka TLS session resume). Normally, I would assume that the client-side session cache is organized/ indexed by the information that is used for server endpoint identification, and a client should not be proposing session resumption of a cached session that would fail server endpoint identification. -Martin From nobody Mon Aug 11 11:38:38 2014 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 959981A075B; Mon, 11 Aug 2014 11:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 QDc3vXuls4xA; Mon, 11 Aug 2014 11:38:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC4BA1A0766; Mon, 11 Aug 2014 11:38:33 -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: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140811183833.11466.35217.idtracker@ietfa.amsl.com> Date: Mon, 11 Aug 2014 11:38:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5HmItW2K47GEJ9XZjj0ZA8xOLMg Cc: tls mailing list , tls chair , RFC Editor Subject: [TLS] Protocol Action: 'Encrypt-then-MAC for TLS and DTLS' to Proposed Standard (draft-ietf-tls-encrypt-then-mac-03.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 11 Aug 2014 18:38:36 -0000 The IESG has approved the following document: - 'Encrypt-then-MAC for TLS and DTLS' (draft-ietf-tls-encrypt-then-mac-03.txt) as Proposed Standard This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-tls-encrypt-then-mac/ Technical Summary This document defines a means to negotiate the use of encrypt-then-MAC instead of the existing MAC-then-encrypt one. WRT the existing mechanism, there are a number of identified vulnerabilities (see the references in the draft). Working Group Summary: This draft has been kicking around for a number of years and was adopted and progressed fairly quickly. There were really just two debates 1) how to do the negotiation (see sec 2.1 of the draft), and 2) whether this applied to both stream and block ciphers (ended up applying to just block). Document Quality There's a test server up and running. There's also a number of known implementations. Personnel Stephen Farrell is the responsible AD. Sean Turner is the shepherd. IANA Note Please make the relevant temporary registration permanent. From nobody Mon Aug 11 13:11:55 2014 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 87FE81A0002 for ; Mon, 11 Aug 2014 13:11:53 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaVeqSA8_u6M for ; Mon, 11 Aug 2014 13:11:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18E81A0004 for ; Mon, 11 Aug 2014 13:11:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 80ED52AB2BD; Mon, 11 Aug 2014 20:11:49 +0000 (UTC) Date: Mon, 11 Aug 2014 20:11:49 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140811201149.GX14392@mournblade.imrryr.org> References: <53E8467B.2090609@delignat-lavaud.fr> <20140811183159.145C81AE02@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140811183159.145C81AE02@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hEQ_XjNP3modboIyjP138gbJXrA Subject: Re: [TLS] SNI and tickets and resumption 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: Mon, 11 Aug 2014 20:11:53 -0000 On Mon, Aug 11, 2014 at 08:31:59PM +0200, Martin Rex wrote: > Normally, I would assume that the client-side session cache is organized/ > indexed by the information that is used for server endpoint identification, > and a client should not be proposing session resumption of a cached session > that would fail server endpoint identification. Exactly! This is, for example, how the Postfix client session cache is keyed. With DANE, the session lookup key even covers the current peer TLSA RRset, so that when TLSA RRs change, the client negotiates a new session. If the client proposes a session with an SNI name it would not accept for the certificate chain of the cached session, that's the client's fault. -- Viktor. From nobody Tue Aug 12 11:26:30 2014 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 19AD01A06A0 for ; Tue, 12 Aug 2014 11:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] 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 kkNwl-kRwmEZ for ; Tue, 12 Aug 2014 11:26:26 -0700 (PDT) Received: from waldorf.isode.com (ext-bt.isode.com [217.34.220.158]) by ietfa.amsl.com (Postfix) with ESMTP id 54ED31A04F1 for ; Tue, 12 Aug 2014 11:26:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1407867985; d=isode.com; s=selector; i=@isode.com; bh=OWkYUGJVYsEBWuzPzcqdvNp3XwQvI2V3IXOC/+lYuGY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=FLglFnJ7PUSgzEO6rrdRoOsfJ3ssMnxf0+gIBkZ6Q+83GIS1RnAmRFuprgngZOeysyEScn Dv5guScQ3eFATVK4bRfIMAtaS8ygjB1GNpNxi9BxXmAP+yptCXiywiezmpXQmC2JKvaSoi zs/DN5FBBD59Ai2TnM7T5Cn/vLIFQho=; Received: from [172.20.1.47] ((unknown) [217.34.220.158]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 12 Aug 2014 19:26:25 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <53EA5C50.70105@isode.com> Date: Tue, 12 Aug 2014 19:26:24 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 To: Eric Rescorla , "tls@ietf.org" References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/up6nwCLH49j262ejGzpXMhjudgA Subject: Re: [TLS] "Draft Version" extension 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, 12 Aug 2014 18:26:28 -0000 On 11/08/2014 17:53, Eric Rescorla wrote: > Experience with HTTP 2 has shown that it's convenient to be able to > distinguish which draft version you're implementing so you don't end > worrying about interop between various I-D versions. Accordingly, > for TLS 1.3 I'd like to define a temporary extension that indicates which > TLS 1.3 draft it implements. The idea here is that the client would signal > TLS 1.3 and then "draft 3" and the server would only negotiate 1.3 if > it had a compatible draft. Otherwise it would fall back to TLS 1.2. > > My proposed extension would be as follows: > > struct { > uint16 draft_version; > } DraftVersionExtension; > > And would have a code point in the (unofficially) experimental range: > 0xff02. > We would not need a permanent allocation since once TLS 1.3 ships you > would send no extension at all. > > I've implemented this in NSS and it's trivial to do. Sounds like a good idea. I implemented similar extensions for other protocols. > > Thoughts? > -Ekr From nobody Wed Aug 13 06:01:07 2014 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 4A6D41A0095 for ; Wed, 13 Aug 2014 06:01:06 -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, 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 WqR8kk__fEX3 for ; Wed, 13 Aug 2014 06:01:03 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 761371A0053 for ; Wed, 13 Aug 2014 06:01:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Fja3EBHk/2R5K1+Yu0wNsMmWTnHE//yWk3REgwOyC6A=; b=Q6RPKNbZndeME+Omxn0pcXMSZesYOaJxcpJ2aR34kdQuJZfLqu2QETNO53BFOn/b2ysO6ejr8q6IvHAAayhkR2SAd0Ox5Oyt08Gh50Hjc+EPS/5yg2icVnVLXcKtJjGZ; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1XHYAZ-0001Nd-54 ; Wed, 13 Aug 2014 15:00:47 +0200 Message-ID: <53EB6180.2030006@delignat-lavaud.fr> Date: Wed, 13 Aug 2014 14:00:48 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Thomson References: <53E771B7.7060609@delignat-lavaud.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OCCZLNTdlbHI98o7bxH2YDpRnug Cc: "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 13 Aug 2014 13:01:06 -0000 Le 8/11/2014 7:06 AM, Martin Thomson a écrit : > On 10 August 2014 06:20, Antoine Delignat-Lavaud > wrote: >> Chrome introduced a very significant change to the authentication model of >> TLS that went virtually unnoticed. In SPDY, the TLS client session cache is >> no longer indexed by domain and port, but instead by domain set, IP and >> port: in classic TLS, an established connection or session can only be >> reused for the same domain, whereas in SPDY, it can be reused for any domain >> in the certificate verified when the session was created, provided that it >> points to the same IP as the original connection. The DNS condition is >> obviously meaningless to a network attacker, which means that all security >> guarantees that were previously session-specific should now be considered >> certificate-specific. > The behaviour you describe isn't quite correct, because - I believe - > that it requires that the DNS resolve to the same IP (or that one of a > set of alternative values point there). But that's not a particularly > important detail, DNS has never been a part of the security story for > https. It's a big part of http, but we all know what you get there. Ultimately, we agree that the precise DNS condition doesn't matter. In HTTPS, DNS is under attacker control. > Either way, this behaviour has been discussed at some length and was > not found lacking in the SPDY/HTTP2 context. Yes, HTTP/2 standardizes > this practice. The poor handling of Host header fields in HTTP/1.1 > means that it will probably never be advisable to do something like > this there. > > As always, I caution that we have to be careful to distinguish between > attacks on implementations and attacks on standards. I am aware that > there are bugs in implementations. I'm also told that they are > somewhat difficult to exploit. The argument is not whether such attacks are to blame on implementation or specification. The question is whether behavior such as reusing a connection established with attacker.com to send data meant for google.com /should be considered an attack at all/. This is the TLS mailing list, and the relevant problem here is the complete lack of any restriction in RFC 5246 and 5077 on when a session can be resumed. Thus, we end up in a situation where resumption is up to implementations to decide; because of the lack of any specification, TLS libraries simply hand off the decision to the application; the application won't know what to do (this kind of question is typically considered out of the scope of application protocol definitions), and thus let the user decide. Of course, the user is very unlikely to understand the security impact of session cache or name-based certificate settings, and this is how we end up with the kind of attacks I demonstrated at Black Hat. SPDY is an interesting case, as it does specify a clear resumption policy (even though, I must against stress out again, this policy technically allows resumption between any two HTTP origins as long as they appear in the same certificate; thus, CVE-2014-3166 does not violate any TLS or HTTP specification and cannot be considered an implementation bug). This policy should be interpreted as an authorization function for TLS authentication. In a full handshake, there is a well-specified and widely-adopted authorization function defined in RFC 5280. The problem I am pointing out is that the SPDY and PKIX authorization functions are incompatible. Thus, TLS features that assume PKIX authorization, such as SNI or ChannelID, may not guarantee the same security properties under SPDY authorization. Similarly, certain PKIX extensions will also fail under SPDY authorization, most notably certificate pinning. From the TLS viewpoint, it is reasonable to consider authorization outside the scope of the protocol. However, for the security of TLS, authentication and authorization must critically be preserved by resumption, as it is entirely a protocol feature that currently occurs without any application involvement. The issue may disappear in TLS 1.3 if resumption is removed, but in current versions, the use of different authorization policies for full handshakes and resumption should be considered a weakness, which can be exploited. Speaking of this, I have to disagree with your claim that attacks in this class are difficult to exploit. It may be true if you compare these attacks to heartbleed or browser memory bugs. However, compared to BEAST, Lucky13 or triple handshake, these attacks are orders of magnitude more exploitable. Best, Antoine Delignat-Lavaud From nobody Wed Aug 13 07:00:47 2014 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 244B51A02F0 for ; Wed, 13 Aug 2014 07:00:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 NaM_ojdu1eUw for ; Wed, 13 Aug 2014 07:00:41 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5A61A02D5 for ; Wed, 13 Aug 2014 07:00:41 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s7DE0SGu023954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Aug 2014 16:00:29 +0200 (MEST) In-Reply-To: <53EB6180.2030006@delignat-lavaud.fr> To: Antoine Delignat-Lavaud Date: Wed, 13 Aug 2014 16:00:28 +0200 (CEST) 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: <20140813140028.BE4351AE06@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YkGnwXu9yOOEpaEp5qaEyCl6z8U Cc: "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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: Wed, 13 Aug 2014 14:00:45 -0000 Antoine Delignat-Lavaud wrote: > > This is the TLS mailing list, and the relevant problem here is the > complete lack of any restriction in RFC 5246 and 5077 on when a session > can be resumed. This lack is intentional. The only prerequisite is that both peers have the session in their cache and are willing to use it for a session instead of a full handshake. > > Thus, we end up in a situation where resumption is up to > implementations to decide; because of the lack of any specification, > TLS libraries simply hand off the decision to the application; You seem to be seriously misinterpreting the specifications. The TLS libraries are not "simply handing off the decision to the application", they are EXPLICITLY REQUIRED to leave any such decision to the application. Last sentence of Section 1. Introduction of every TLS spec: https://tools.ietf.org/html/rfc2246#page-4 the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left up to the judgment of the designers and implementors of protocols which run on top of TLS. In the abstract definition, the TLS client implementation has _absolutely_ _no_idea_ who it is talking to, working purely on a memory buffer interface to the client application. What is probably dangerous and unreasonable is when a TLS implementation lets an application interfere with the PKIX path validation of a peer cert chain. The application level "interpretation of authentication certificates exchanged" ought to be independent from whether the TLS stack performs a full or an abbreviated TLS handshake, and the calling application ought to retrieve and check/map the peer certificates after completion of the TLS handshake and independent of whether the handshake was full or abbreviated (and independent from the PKIX path validation). > > the application won't know what to do (this kind of question is typically > considered out of the scope of application protocol definitions), Nope, that can not possibly happen. Per specification, the application *KNOWS* what to do. There might be clueless programmers that don't know what to do, but that is a different issue. > > SPDY is an interesting case, as it does specify a clear resumption > policy (even though, I must against stress out again, this policy > technically allows resumption between any two HTTP origins as long as > they appear in the same certificate; thus, CVE-2014-3166 does not > violate any TLS or HTTP specification and cannot be considered an > implementation bug). This policy should be interpreted as an > authorization function for TLS authentication. In a full handshake, > there is a well-specified and widely-adopted authorization function > defined in RFC 5280. The problem I am pointing out is that the SPDY and > PKIX authorization functions are incompatible. Thus, TLS features that > assume PKIX authorization, such as SNI or ChannelID, may not guarantee > the same security properties under SPDY authorization. Similarly, > certain PKIX extensions will also fail under SPDY authorization, most > notably certificate pinning. PKIX authorization does not exist within TLS. Whether it exists in the function of the application that "decisions how to interpret the authentication certificates" is purely an application matter an none of TLS business. Certificate pinning would be an application decision, not a TLS decision. But with your description I somehow still fail to see a problem. If the server certificate of such resumptions will *pass* the "server endpoint identification", then why would re-doing the server endpoint identification make a difference? -Martin From nobody Wed Aug 13 09:07:04 2014 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 57AB81A0426 for ; Wed, 13 Aug 2014 09:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 LXWmvEGMrcVD for ; Wed, 13 Aug 2014 09:07:01 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636D41A08CB for ; Wed, 13 Aug 2014 09:06:57 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 1DA051A2637; Wed, 13 Aug 2014 19:06:54 +0300 (EEST) Date: Wed, 13 Aug 2014 19:06:53 +0300 From: Ilari Liusvaara To: Martin Rex Message-ID: <20140813160653.GA32598@LK-Perkele-VII> References: <53EB6180.2030006@delignat-lavaud.fr> <20140813140028.BE4351AE06@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20140813140028.BE4351AE06@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IltZ0ZSYoHxlkVe3pcJuVHT-g7M Cc: Antoine Delignat-Lavaud , "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 13 Aug 2014 16:07:03 -0000 On Wed, Aug 13, 2014 at 04:00:28PM +0200, Martin Rex wrote: > > But with your description I somehow still fail to see a problem. > If the server certificate of such resumptions will *pass* the > "server endpoint identification", then why would re-doing the > server endpoint identification make a difference? As far as I understand, the actual issue is HTTP servers issuing false responses to HTTP reqeusts if sent to wrong server (but that server may still have valid certificate). And clients interpretting those false responses as proper ones then leads to all sorts of unpleasant problems. Usually those false responses are because of misconfiguration (usually default virtual host is something unintended, or the default vhost is issuing redirects to "main site" even when such redirect must not be sent (the vhost being handled else- where)). HTTP/2 even defines error code specifically for responding to such requests (421). That code would also apply to HTTP/1.1 (in pinch, 400 would do while waiting for 421). Where session resumption comes in is that it is more vulernable than full handshake to attacker interference, resulting in it being easier to make user connect to wrong server. -Ilari From nobody Thu Aug 14 18:57:50 2014 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 48F5D1A06A4 for ; Thu, 14 Aug 2014 18:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, 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 QI7mL4wxYSii for ; Thu, 14 Aug 2014 18:56:55 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02F1A067C for ; Thu, 14 Aug 2014 18:56:54 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s7F1uUO4002768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 15 Aug 2014 03:56:31 +0200 (MEST) In-Reply-To: <20140813160653.GA32598@LK-Perkele-VII> To: Ilari Liusvaara Date: Fri, 15 Aug 2014 03:56:30 +0200 (CEST) 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: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k5sSmThcFhOCJbxVEW3IX16lODQ Cc: Antoine Delignat-Lavaud , "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 15 Aug 2014 01:57:46 -0000 Ilari Liusvaara wrote: >> >> But with your description I somehow still fail to see a problem. >> If the server certificate of such resumptions will *pass* the >> "server endpoint identification", then why would re-doing the >> server endpoint identification make a difference? > > As far as I understand, the actual issue is HTTP servers issuing > false responses to HTTP reqeusts if sent to wrong server (but > that server may still have valid certificate). And clients > interpretting those false responses as proper ones then leads > to all sorts of unpleasant problems. I did understand that part. > > Where session resumption comes in is that it is more vulernable > than full handshake to attacker interference, resulting in it > being easier to make user connect to wrong server. But I still fail to see how session resumption would aggravate any bogosities performed by applications as long as the servers certificates on both handshakes (resumption an full) will properly *PASS* the usual server endpoint identification checks, which is what has been asserted. -Martin From nobody Fri Aug 15 01:45:25 2014 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 E1B461A0972 for ; Fri, 15 Aug 2014 01:45:23 -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, 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 J_P9tv2YXL8M for ; Fri, 15 Aug 2014 01:45:20 -0700 (PDT) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624781A092B for ; Fri, 15 Aug 2014 01:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yqIqVpnI8HBU+sipJTgpzVm8znXXmJ8hJ0vnoTdH+P0=; b=PmDYl7Wo075q94jmmFBNx6tg5RZSQNUaeXCDx6QKRpIdBEYew38JMYOozibz6EE8L9/GbAEtB4Sl09yKCRcE5COFTO+dygIA4QmbXRTnXbWP3FxrHzFBYOW6VER/SEIQ; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (envelope-from ) id 1XID8B-0001yC-2u ; Fri, 15 Aug 2014 10:45:03 +0200 Message-ID: <53EDC889.5030704@delignat-lavaud.fr> Date: Fri, 15 Aug 2014 09:44:57 +0100 From: Antoine Delignat-Lavaud User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: mrex@sap.com, Ilari Liusvaara References: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> In-Reply-To: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3qZvYxnNqK6BMvE--wKot5_mK2o Cc: "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 15 Aug 2014 08:45:24 -0000 Le 8/15/2014 2:56 AM, Martin Rex a écrit : > But I still fail to see how session resumption would aggravate > any bogosities performed by applications as long as the servers > certificates on both handshakes (resumption an full) > will properly *PASS* the usual server endpoint identification checks, > which is what has been asserted. As I explained before, the reason why it is the case is because TLS authorization is not context free: it depends on the application context. In HTTP, application context boils down to origin, because the same origin policy is the only security context that makes sense in a browser. Any TLS authorization for the Web that uses a context broader than origin is going to be a source of attack. This applies to both server and client. The problem with resumption is that unlike full handshakes, it uses implicit authorization. This can be easily blamed on protocol implementations, but TLS could have made resumption authorization more explicit. On the server side, most web servers use a very simple authorization policy, which is basically "return true" regardless of the context. This is bad, because there are many reasons why a server would want to reject certain resumption requests, in particular when the application context (domain / SNI) of the resumption is different from the one in the initial connection. For instance, if the session being resumed is user authenticated, the server may want to use a different CA on the domain of the resumption, or an anonymous session. It may also prefer to use another certificate (such as an extended validation one) for this domain (even though the initial one may also work, say because it has a wildcard), or a different cipher, or avoid using the same Channel ID, or many other reasons. The new domain of the resumption may not be handled by the server (in fact, if the server uses multiple certificates, or a shared ticket key, it can even be that the requested domain is not in the certificate of the original session), in which case authorizing the resumption is guaranteed to break the same origin policy. These are all real attacks that can be found against top websites (see https://bh.ht.vc). On the client side, clients typically use a resumption policy based on the domain associated with the session. This works great for HTTPS because protocol+domain is almost as good as origin (port being part of origin is a mistake). However, SPDY uses a resumption policy that assumes that authorization of the initial connection extends to other domains in the certificate. This is not the case: the original authorization was granted in a different application context, and it is in fact necessary to re-authorize the connection in the new context. See http://youtu.be/7zNWKTDs99g for a concrete exploit. Overall, I am well aware that little can be done in the TLS protocol to solve the shortcomings of application authorization. Since SNI provides a good application context indication even outside HTTPS, the change that I was initially proposing to OpenSSL and Nginx several months ago was to enforce that the SNI may not change when a session is resumed. However, this restriction is not compatible with SPDY, and almost all servers continue to accept resumption with a different SNI currently. Best, Antoine Delignat-Lavaud From nobody Fri Aug 15 05:37:09 2014 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 30A241A0A75 for ; Fri, 15 Aug 2014 05:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.617 X-Spam-Level: X-Spam-Status: No, score=-6.617 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] 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 TTKsSSrsyavQ for ; Fri, 15 Aug 2014 05:37:03 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A5E1A0A71 for ; Fri, 15 Aug 2014 05:37:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,870,1400018400"; d="asc'?scan'208,217";a="89451082" Received: from pool-64-222-88-227.burl.east.myfairpoint.net (HELO [10.0.1.3]) ([64.222.88.227]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 15 Aug 2014 14:36:46 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_2C7D84A6-E005-4FE1-9561-D0CCC3EA57B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> Date: Fri, 15 Aug 2014 08:36:44 -0400 Message-Id: <515ACDD8-F8F6-4A75-9F5E-E0EC5DB15D35@inria.fr> References: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/O3PsDw7Bveb4H7yRmyT7sZ1dQzY Cc: Antoine Delignat-Lavaud , "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 15 Aug 2014 12:37:07 -0000 --Apple-Mail=_2C7D84A6-E005-4FE1-9561-D0CCC3EA57B5 Content-Type: multipart/alternative; boundary="Apple-Mail=_6848B003-CFCA-41E8-8EA5-86D222E3C3B8" --Apple-Mail=_6848B003-CFCA-41E8-8EA5-86D222E3C3B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 14 Aug 2014, at 21:56, Martin Rex wrote: > But I still fail to see how session resumption would aggravate > any bogosities performed by applications as long as the servers > certificates on both handshakes (resumption an full) > will properly *PASS* the usual server endpoint identification checks, > which is what has been asserted. Perhaps an example scenario would be useful. ----- Suppose a TLS server S uses a certificate C for domain D and a TLS server S=92 uses a certificate C=92 for domain D=92. S and S=92 share a session ticket encryption key K (or a session cache). (Real-world example in Antoine=92s talk: D=3Dbugzilla.mozilla.org and = D=92=3Dgit.mozilla.org) =97=97 Connection 1: C intends to connect to D and completes a full handshake with S. S sends C a session ticket for encryption (encrypted under K) =97=97 Connection 2: C resumes its session over a new connection using the session ticket. The network attacker redirects the connection to S=92. S=92 will accept the ticket (since it uses the same ticket encryption = key K) C and S=92 complete the abbreviated handshake. =97=97 Result: C thinks it is (re-)connected to server S/domain D but it is = connected to server S=92/domain D=92, even though S and S=92 *do not* serve the same certificate. (A similar trace can be worked out for session caches shared between S = and S=92) =97=97 That this result is undesirable should not be in doubt (it leads to = medium-level security exploits in deployed websites.) At what level do = we fix it seems more open to debate. One may argue that: (a) this is the application=92s fault (at S=92). It is fine for S and S=92= to share ticket encryption keys (or session caches) but the application = (e.g. HTTPS) must carefully disambiguate streams meant for S and S=92 = using some application-level information (e.g. Host header) (b) using SNI during resumption should prevent this. S=92 should refuse = to resume a connection that has an SNI=3DD when it does not have a = certificate that covers D. (c) TLS session tickets/resumption are underspecified. Session tickets = should also include the server_identity, that is the server = certificate/hash/server name, not just the client_identity (see = http://tools.ietf.org/html/rfc5077#section-4). Then, during resumption, = the client should indicate the certificate/server name it wishes to = connect to (e.g. via SNI) so that S=92 can check that the resumed = connection is for the same certificate/server name.=20 I gather (from Adam=92s and Rich's emails) that Google and Akamai do = some version of (c).=20 One may force HTTP web servers to do (a), but what about SMTP/IMAP/=85 = servers that may not have a convenient =93Host=94 header? One may also say that servers should use different ticket encryption = keys for each certificate/domain they serve, but this would probably = vastly increase the number of full handshakes. One may try to use SNI as in (b), but only after downgrade attacks have = been eliminated. Is the above (a) a failure of TLS session resumption or (b) a failure of = the server implementation at S=92 or (c) a failure of the HTTP level = addressing >=20 > -Martin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_6848B003-CFCA-41E8-8EA5-86D222E3C3B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 14 Aug 2014, at 21:56, Martin Rex = <mrex@sap.com> = wrote:

But I still fail to = see how session resumption would aggravate
any bogosities performed = by applications as long as the servers
certificates on both = handshakes (resumption an full)
will properly *PASS* the usual server = endpoint identification checks,
which is what has been = asserted.

Perhaps an example = scenario would be = useful.

-----
Suppose a TLS server S = uses a certificate C for domain D
and a TLS server S=92 uses a = certificate C=92 for domain D=92.
S and S=92 share a session = ticket encryption key K (or a session cache).
(Real-world = example in Antoine=92s talk: D=3Dbugzilla.mozilla.org and D=92=3D<= a = href=3D"http://git.mozilla.org">git.mozilla.org)
=97=97
Connection 1:
C intends to connect to D and completes a = full handshake with S.
S sends C a session ticket for = encryption (encrypted under K)
=97=97
Connection = 2:
C resumes its session over a new connection using the = session ticket.
The network attacker redirects the connection = to S=92.
S=92 will accept the ticket (since it uses the same = ticket encryption key K)
C and S=92 complete the abbreviated = handshake.
=97=97
Result: C thinks it is = (re-)connected to server S/domain D but it is connected to server = S=92/domain D=92,
even though S and S=92 *do not* serve the = same certificate.
(A similar trace can be worked out for = session caches shared between S and = S=92)
=97=97

That this result is = undesirable should not be in doubt (it leads to medium-level security = exploits in deployed websites.)  At what level do we fix it seems = more open to debate.

One may argue = that:

(a) this is the application=92s fault (at = S=92). It is fine for S and S=92 to share ticket encryption keys (or = session caches) but the application (e.g. HTTPS) must carefully = disambiguate streams meant for S and S=92 using some application-level = information (e.g. Host header)

(b) using SNI = during resumption should prevent this. S=92 should refuse to resume a = connection that has an SNI=3DD when it does not have a certificate that = covers D.

(c) TLS session tickets/resumption = are underspecified. Session tickets should also include the = server_identity, that is the server certificate/hash/server name, not = just the client_identity (see http://tools.ietf.or= g/html/rfc5077#section-4). Then, during resumption, the client = should indicate the certificate/server name it wishes to connect to = (e.g. via SNI) so that S=92 can check that the resumed connection is for = the same certificate/server name. 

I = gather (from Adam=92s and Rich's emails) that Google and Akamai do some = version of (c). 
One may force HTTP web servers to do = (a), but what about SMTP/IMAP/=85 servers that may not have a convenient = =93Host=94 header?
One may also say that servers should use = different ticket encryption keys for each certificate/domain they serve, = but this would probably vastly increase the number of full = handshakes.
One may try to use SNI as in (b), but only after = downgrade attacks have been = eliminated.










Is the above (a) a failure of TLS session = resumption or (b) a failure of the server implementation at S=92 or (c) = a failure of the HTTP level = addressing





-Martin

_________________________________________= ______
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail= man/listinfo/tls

= --Apple-Mail=_6848B003-CFCA-41E8-8EA5-86D222E3C3B8-- --Apple-Mail=_2C7D84A6-E005-4FE1-9561-D0CCC3EA57B5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJT7f7cAAoJEB/WSo9veuUK7F4H+gKbKwfPD5Ey0YWUDaclFlYs RO8sPQ4U/EkfA2vintAjnOjxls0cAcTmqjZFm6AfA1XYyZIHitmKOO2K8ylEMb5J XVknYkDF6alylPiTdRcBvRSUBmIfgapHyEii9DUwYT8cCCHiyia3BAkUB3lxYhEi otmJmzpUhgyR3U45pejK3xxxyWUa0JZJ0y4qm+ck1kVJXeyZRsKEalc5htfc2v+Q NSmVmaW+6vCcxhtmStcnSlKtUTgRXhbh5O7MhWfZo6s0toha5uiP+F95s2JmFMXi NpwGXhZQ4N++RWJH34qcz9s8rPU8DQKq5xGI8vvUOG7a1L+CHoZVD00i/gjamOM= =hWRZ -----END PGP SIGNATURE----- --Apple-Mail=_2C7D84A6-E005-4FE1-9561-D0CCC3EA57B5-- From nobody Fri Aug 15 09:56:21 2014 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 EC2A31A0060 for ; Fri, 15 Aug 2014 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUyID1B6KIu0 for ; Fri, 15 Aug 2014 09:56:13 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01DC1A0054 for ; Fri, 15 Aug 2014 09:56:12 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so1072173wib.14 for ; Fri, 15 Aug 2014 09:56:11 -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-type:content-transfer-encoding; bh=YXJze9EWY1ReHeqGNwqCM6p13061OWFQT+wvVHIELzQ=; b=I4bBL77DaxdpgK04ofRxI2gDxGkqxVgbTogIHlL/xEseicIrUB9R12LSJJ6khX23Og FHqShn+aXoYOKFWEL9fVWD/6MLBrNiVwzt7k+mDdljCGqAIUliQCqW3jJ8TxdAzyBfcL 5/oG8FYjkP0fUYD6vVoIzpMWSlf09ovaLFX2Q8S0gb/4oRg9yCTlfix8CQwn7Lk9XESh zq1jp1bQwkmpqktBgAgXBBGbZAQlYFEYGDHgw7LuYZhSC7yosQG9MgdejHSa99KlrV7j dZjU8yMNXSYXypbvli7IBM36bYmW1L35aBjRWsQ8L06g4fbHbDzrBkFZARer3s5oL43U IO3A== MIME-Version: 1.0 X-Received: by 10.194.91.228 with SMTP id ch4mr22182291wjb.59.1408121771650; Fri, 15 Aug 2014 09:56:11 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Fri, 15 Aug 2014 09:56:11 -0700 (PDT) In-Reply-To: <515ACDD8-F8F6-4A75-9F5E-E0EC5DB15D35@inria.fr> References: <20140815015630.D29521AE0D@ld9781.wdf.sap.corp> <515ACDD8-F8F6-4A75-9F5E-E0EC5DB15D35@inria.fr> Date: Fri, 15 Aug 2014 09:56:11 -0700 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JiS_uNWsHRPV1KokUmtWvD1c4kM Cc: Antoine Delignat-Lavaud , "tls@ietf.org" Subject: Re: [TLS] Inter-protocol attacks 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, 15 Aug 2014 16:56:17 -0000 On 15 August 2014 05:36, Karthikeyan Bhargavan wrote: > (c) TLS session tickets/resumption are underspecified. Session tickets > should also include the server_identity, that is the server > certificate/hash/server name, not just the client_identity (see > http://tools.ietf.org/html/rfc5077#section-4). Then, during resumption, t= he > client should indicate the certificate/server name it wishes to connect t= o > (e.g. via SNI) so that S=E2=80=99 can check that the resumed connection i= s for the > same certificate/server name. I think that this is pretty much the right answer. Since session tickets are basically the server talking to itself, it's really only something we can only recommend in a specification. Deployments that don't have multiple configurations aren't going to need a binding, but those that do should be binding the ticket to the configuration. In the end, it's probably best to recommend the binding for all cases to avoid usage issues. I don't want to make applications responsible for this, at least to the extent that is possible. From nobody Sun Aug 17 04:07:34 2014 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 76E291A082C for ; Sun, 17 Aug 2014 04:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Cp_UWsWxXFzg for ; Sun, 17 Aug 2014 04:07:28 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D93A1A082A for ; Sun, 17 Aug 2014 04:07:26 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 4F2B01A2641 for ; Sun, 17 Aug 2014 14:07:19 +0300 (EEST) Date: Sun, 17 Aug 2014 14:07:19 +0300 From: Ilari Liusvaara To: tls mailing list Message-ID: <20140817110719.GA583@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/t4Mgu08BXe1GDo2CgLoyeWfMJkU Subject: [TLS] Review of draft-ietf-tls-cached-info-16 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, 17 Aug 2014 11:07:31 -0000 Doing a quick readthrough (since this doc is allegedly in WGLC). > 4. Exchange Specification > The handshake protocol MUST proceed using the information as if it > was provided in the handshake protocol. The Finished message MUST be > calculated over the actual data exchanged in the handshake protocol. > That is, the Finished message will be calculated over the information > that was omitted from transmission by means of its present hash in > the client hello and not through its presence in the handshake > exchange. CertificateVerify messages also use transcripts. Those are defined as usual[1] (like Finished seems to be), right? [1] Omitted data is indirectly included via hashes present in ClientHello/ServerHello. -Ilari From nobody Sun Aug 17 11:47:46 2014 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 A17351A00A8 for ; Sun, 17 Aug 2014 11:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 rz6XMdj7zJ0f for ; Sun, 17 Aug 2014 11:47:44 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B78391A0072 for ; Sun, 17 Aug 2014 11:47:43 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id b13so4099638wgh.34 for ; Sun, 17 Aug 2014 11:47:42 -0700 (PDT) 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-type; bh=swgKT29VasLTl27qEGrS6zQuXSSA7wVwHkOrlWngH3A=; b=b+MK0q3Z/0LtMKVCbqjc69PoHyIwX3Cw2sreD8s2r27SDonS9z7GxEsaob0+lvfmml Ql6B7oRSaBH2JK9JxAUX++qtAryK9JC8GIuhBdtaWqMVqVzYOwfT17I6WibICFIRTrTE OqKQtBtgyQU+x6fTD2PcDsCyxvyK4lQ1naMiaJnrzaetwx/QEhpHwokljSa0H1T24Z6/ 8+yOVFqxwzfy++mJQq/yyyAkrW9bZlwVvBEXct0FxIm6XwR7MZtukIn1pTt+djLYR8IY UoeTropxvRwP4oHZyPVGyFTzVXIUgp/O1LrAG+qiBgNnVs3fIQpc55kLZZ3nIwthQVWe 5gfw== X-Gm-Message-State: ALoCoQldw1etxX95WIrJd/rj4BiBCT/jBjPKPdeqpr5PGIqWmJYAOf35Q2KPlYG2RROIhyLYonPX X-Received: by 10.180.39.34 with SMTP id m2mr68299962wik.80.1408301262170; Sun, 17 Aug 2014 11:47:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Sun, 17 Aug 2014 11:47:02 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:4ca8:f93c:912:f129] In-Reply-To: References: From: Eric Rescorla Date: Sun, 17 Aug 2014 11:47:02 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a1134b5b8780b690500d7b0fd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w-lZ-Nor2g5MWTidp4YUMOWm66I Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-cached-info 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, 17 Aug 2014 18:47:45 -0000 --001a1134b5b8780b690500d7b0fd Content-Type: text/plain; charset=UTF-8 Comments below. Generally, I think some work is still needed here. I'm starting to wonder whether this piecemeal design is really the one we want here. I.e., it's possible for the client to let the server cache X and Y but not Z. I wonder if we instead want the server to advertise "This is configuration XXX and the client just says OK" rather than letting the client pick and choose. How much more bandwidth would that really lose? Conversely, if we're going to have a pick and choose design, we should think about adding the client's cert since that can be large. I think the text needs to be tightened up to be clear on what's going on. As I understand it: - The client can offer as many cached items as it wants including multiples of the same type. - The server can respond with at most one of each type. If he offers a value that the client offered that means he is going to omit that value. If he offers a value that the client didn't offer, that means he would be willing to let the client cache that value. Is this correct? If so, these seem like kind of confusing semantics, since it means that, for instance, if the client offers: certificate = X and the server responds with: certificate = X Then it means that the server will omit the cert but if the server offers certificate = Y it means "I would be willing to omit cert Y" but I didn't omit X. I trust it does not mean "I omit Y". That seems confusing. Section 3. I Suggest renaming the "trusted_cas". That seems like a bad name for this. Do we want to add OCSP responses to this. Section 4: Following a successful exchange of the "cached_information" extensions in the client and server hello, the server omits sending the corresponding handshake message. My understanding was that you in fact shrank the message but didn't omit it. Section 4.2. When a fingerprint for an object of type 'trusted_cas' is provided in the client hello, the server MAY send a DistinguishedName in the Certificate Request message with an actual length field of zero (=empty vector). This is a sequence of DistinguishedNames. So do you send a list with one empty DN in it or an empty list? Is there a reason not to just compress the entire message? Surely the types and algorithms are just as stable. Section 5: namely 'trusted_cas' (also defined in this document), and the 'foo- bar' extension (i.e., an imaginary extension that yet needs to be defined). Nit: extensions generally have underscores. Please make these diagrams match the style in RFC 5246. Section 6: The hash algorithm used in this specification is required to have reasonable random properties in order to provide reasonably unique You don't mean "random", right? I also share AGL's concerns about the security analysis. On Tue, Jul 29, 2014 at 5:48 AM, Sean Turner wrote: > This is the working group last call for draft-ietf-tls-cached-info: > http://datatracker.ietf.org/doc/draft-ietf-tls-cached-info/ > Please send comments on this draft to the TLS list before August 19, 2014. > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1134b5b8780b690500d7b0fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0Comments below. Generally, I think some work is= still needed here.

I'm starting to wonder whe= ther this piecemeal design is really
the one we want here. I.e., = it's possible for the client
to let the server cache X and Y but not Z. I wonder
if we in= stead want the server to advertise "This is
configuration XX= X and the client just says OK" rather
than letting the clien= t pick and choose. How much
more bandwidth would that really lose?


Conversely, if we're going to have a pick and choose design,
we should think about adding the client's cert since that
can be large.


I think the text= needs to be tightened up to be clear on what's
going on. As = I understand it:

- The client can offer as many ca= ched items as it wants including
=C2=A0 multiples of the same type.

- The serv= er can respond with at most one of each type. If he
=C2=A0 offers= a value that the client offered that means he is
=C2=A0 going to= omit that value. If he offers a value that the
=C2=A0 client didn't offer, that means he would be willing to let<= /div>
=C2=A0 the client cache that value.

Is t= his correct? If so, these seem like kind of confusing
semantics, = since it means that, for instance, if the client
offers:

=C2=A0certificate =3D X
and the server responds with:

=C2=A0ce= rtificate =3D X

Then it means that the server will= omit the cert but if the server
offers certificate =3D Y it means "I would be willing to omit cer= t Y"
but I didn't omit X. I trust it does not mean "= ;I omit Y".
That seems confusing.


Section 3.
I Suggest renaming the "trusted_ca= s". That seems like a bad name
for this.

Do we want to add OCSP responses to this.



Section 4:
=C2=A0 =C2=A0Following a= successful exchange of the "cached_information"
=C2=A0= =C2=A0extensions in the client and server hello, the server omits sending<= /div>
=C2=A0 =C2=A0the corresponding handshake message.

My understanding was that you in fact shrank the messag= e but didn't
omit it.


Section 4.2.

=C2=A0 =C2=A0When a fingerprint for = an object of type 'trusted_cas' is provided in
=C2=A0 =C2=A0the client hello, the server MAY send a DistinguishedName= in the
=C2=A0 =C2=A0Certificate Request message with an actual l= ength field of zero
=C2=A0 =C2=A0(=3Dempty vector).
This is a sequence of DistinguishedNames. So do you
send a list with one empty DN in it or an empty list?

Is there a reason not to just compress the entire message?
Surely the types and algorithms are just as stable.


Section 5:
=C2=A0 =C2=A0namely 'trusted_c= as' (also defined in this document), and the 'foo-
=C2=A0= =C2=A0bar' extension (i.e., an imaginary extension that yet needs to b= e
=C2=A0 =C2=A0defined).

Nit: extensions generally have underscores.
<= br>

Please make these diagrams match the style in = RFC 5246.


Section 6:
=C2=A0 =C2=A0The hash algorithm used in this specification is required to h= ave
=C2=A0 =C2=A0reasonable random properties in order to provide= reasonably unique

You don't mean "random= ", right?


I also share AGL's concerns about th= e security analysis.









On Tue, Jul 29, 2014 at 5:48 AM, Sean Tu= rner <TurnerS@ieca.com> wrote:
This is the working group last call for draft-ietf-tls-cached-info:
=C2=A0 http://datatracker.ietf.org/doc/draft-ietf-tls-cached= -info/
Please send comments on this draft to the TLS list before August 19, 2014.<= br>
J&S

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

--001a1134b5b8780b690500d7b0fd-- From nobody Mon Aug 18 13:33:03 2014 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 335D21A6F52 for ; Mon, 18 Aug 2014 13:33:00 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEq12DTBSr0e for ; Mon, 18 Aug 2014 13:32:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7061A6F4D for ; Mon, 18 Aug 2014 13:32:58 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so5601130wes.31 for ; Mon, 18 Aug 2014 13:32:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=4M9VTlhSB+EAI5R51NezwaIBR9EnFPlePaZ7C0J8c+A=; b=m6R5JOuKK2hcMQV6lXbRZk46sWD/L6vywfY3FKqSIq8ksSVBPOYYrGpcY7M26WJ8le nRhyMbNw+Wi59pl4008l5Prn4BzXkIvFGEk1kRBVpfdfNl9l+9hV0IR0d4HnIrc5qlfS MdgZaMUWE/ADUvO+ZVgbkgYL29MyogvCUAMazXnmZxryvPX+uKYEOUrzVDJk3SA+zbxW lNnK3/3xE/k6AQf/7si+NBo+6UfHuOA4T0kfAlxsEjCl/GTgf5tI49j2BjmRemJ08PdV UAaCBuYnYo2Q2AuW49pMzXRxs6n4Kmh/K842xOeLi7jHVGsxl0NoyTn1Z8WiX8lhUb7B C4rA== X-Gm-Message-State: ALoCoQl44b8q0jFaATAHZ0of6JqWXrgIZD4E3s4zdcpuRUueAEwc/uz5P7HUSEhAJW3hvfS45WrQ X-Received: by 10.180.24.225 with SMTP id x1mr1561633wif.14.1408393977302; Mon, 18 Aug 2014 13:32:57 -0700 (PDT) Received: from [10.0.0.132] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id ci3sm863725wjc.35.2014.08.18.13.32.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Aug 2014 13:32:56 -0700 (PDT) Message-ID: <53F262F7.4020805@azet.org> Date: Mon, 18 Aug 2014 22:32:55 +0200 From: Aaron Zauner User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Paul Lambert References: <20140808210902.8E0471ADFC@ld9781.wdf.sap.corp> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigFCAEF6379574FF4244BBAF9C" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rZ86o27sxTmCNz3UC4ttiZzx1hU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] WGLC: draft-ietf-tls-prohibiting-rc4-00 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, 18 Aug 2014 20:33:00 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFCAEF6379574FF4244BBAF9C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Paul Lambert wrote: > +1 on strongly disagree >=20 > Not sure how example below is relevant to total removal of RC4. >=20 > It=B9s important to maintain the clear position that is in current draf= t: > =B3 =8A clients MUST NOT include RC4 cipher suites =8A =B3 +1. RC4 needs to go. Urgently. The suggested change can - sorry - only be described as malicious. I've seen not one solid reason in this thread to keep RC4 alive, and cannot think of any reason today. Aaron --------------enigFCAEF6379574FF4244BBAF9C Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT8mL3AAoJEOTbZJL9ubXV+PEP/3iA/0xZSlVEI9wcadk923ft 4vn3nPL4m+ecaMnLm12+Yr/uwfS1upP9Be0NYY4852ItGgurKNyAkokE9rbTDrXC nnaWlCA/MpznSSj10QojTr0yJOBwqfyGNJkublTN+7B5/IPsoYzYOchX8z7JxsdU 1+0nhy0xh44eXDwB5k/3iN3LJGqaYkRqCXLEjlLGHAN3cdSvYm7zyXt+I3K9ZMsk gYN9VjQnpx4prcP88glgc+QoQawBz9EDU6dE7FLnba/Mr5dYvt/yOiDlqqroIrDx xJUlX1yA9nt3HRj5GOvJcIfRlHDKMN18CqqtXnDdmdsUL03WLq0ZfYfGwUSzpzGg rFbDyrkUfy+fdm15DAFPBUPws4hUBI8LUFA+c+JnYhS2SCYelPK8W2Fb6RbKjHO7 8YqA+IYVhsdvGWb55RDdLwlXNmi4OliGL5tJUiRQpHWT+0CC2v635e26dx0qXmw9 oEPJ3KqlUrz0xsLL7n6HCjfwhEmFyWAKjVA4X8np//9U2FEg+hmAhCjtUB4pFQdX VGViEThZS/nnXScCEuGF2kYroRd1Cw94sDu1ME3GnezJPA2xxP95EPAOYANGI8JA yUYR1JRaNOvbdhXuv/4rp5pQvlOQ2gyHiDQqlDLpfAW5hYddQaVvbeOLKvc0CwWm Hqjvu7XgycxFJ+isYYAj =HdzK -----END PGP SIGNATURE----- --------------enigFCAEF6379574FF4244BBAF9C-- From nobody Tue Aug 19 09:31:34 2014 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 ED7201A0666 for ; Tue, 19 Aug 2014 09:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.807 X-Spam-Level: ** X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 xizzxEXw5NHR for ; Tue, 19 Aug 2014 09:31:26 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [67.18.144.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AFBB1A068F for ; Tue, 19 Aug 2014 09:31:18 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 7601CFE2B2F5A; Tue, 19 Aug 2014 11:31:17 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 6367CFE2B2F3A for ; Tue, 19 Aug 2014 11:31:17 -0500 (CDT) Received: from [96.231.227.95] (port=61881 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XJmJY-0000BM-Fw; Tue, 19 Aug 2014 11:31:16 -0500 From: Sean Turner Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <609BA59A-2C53-490A-B23B-2B14A34F7D25@ieca.com> Date: Tue, 19 Aug 2014 12:31:13 -0400 To: "TLS@ietf.org (tls@ietf.org)" , draft-bhargavan-tls-session-hash@tools.ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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.227.95 X-Exim-ID: 1XJmJY-0000BM-Fw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:61881 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1RH3Vt2OmpImO5w11hffsxoH9rA Subject: [TLS] adopted: draft-bhargavan-tls-session-hash 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, 19 Aug 2014 16:31:31 -0000 There was consensus at the TLS interim held on 20140720 to adopt=20 draft-bhargavan-tls-session-hash without the Signaling Cipher Suite = Value (SCSV) text. To confirm this, an adoption call was put to the = list. While there was some discussion on the list, the chairs believe = that the consensus reached at the interim meetings holds. = draft-bhargavan-tls-session-hash-01, which removes the SCSV text, has = been adopted as a WG item. Please note we=92re aware there might be some impacts on other drafts = but figured it best to get the draft in and start working on it. Authors, Please submit your individual draft as draft-ietf-tls-session-hash-00. J&S= From nobody Tue Aug 19 15:14:57 2014 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 A2D011A6F53; Tue, 19 Aug 2014 15:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW7xr2wQHjTp; Tue, 19 Aug 2014 15:14:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DE51A016A; Tue, 19 Aug 2014 15:14:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140819221453.23534.35283.idtracker@ietfa.amsl.com> Date: Tue, 19 Aug 2014 15:14:53 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/paviy6f8ow5rCw0zN18-0Hv6kbQ Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 19 Aug 2014 22:14:54 -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 Working Group of the IETF. Title : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Authors : Karthikeyan Bhargavan Antoine Delignat-Lavaud Alfredo Pironti Adam Langley Marsh Ray Filename : draft-ietf-tls-session-hash-00.txt Pages : 8 Date : 2014-08-19 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the client and server identities. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including renegotiation after session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-session-hash-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 20 09:45:09 2014 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 890861A045B for ; Wed, 20 Aug 2014 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.598 X-Spam-Level: X-Spam-Status: No, score=0.598 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 2_N5gvtmhb91 for ; Wed, 20 Aug 2014 09:45:04 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAB21A03F9 for ; Wed, 20 Aug 2014 09:45:03 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id 67CF2818A0 for ; Wed, 20 Aug 2014 19:45:01 +0300 (EEST) Date: Wed, 20 Aug 2014 19:45:00 +0300 From: Ilari Liusvaara To: tls mailing list Message-ID: <20140820164500.GA26426@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KjwfAgM1Opj21daxYCKLv1z-E1s Subject: [TLS] Problems with TLS 1.3 handshake protocol 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, 20 Aug 2014 16:45:06 -0000 Here is listing of some problems with proposed TLS 1.3 handshake protocol (of various severity), and some proposals how to solve those. 1) Is ClientKeyExchange coming? ------------------------------- Because the handshake protocol uses transcripts, it requires that both sides always know who will transmit next, which impiles knowing when peer's flight has ended. This goes badly with ClientKeyExchange. It is optional, and there is no marker for end of flight. As consequence, the first flight can end with either ClientHello or ClientKeyExchange. Proposal: Stick those first flight key exchange messages inside ClientHello. 2) Duplicate ClientHello: ------------------------- If the client misses all its guesses about Key Exchange, the current spec has it restart from ClientHello. This seems very dangerous. This kind of repetion is a good source of bugs. Bugs that one absolutely does not want in any security-sensitive protocol. Proposal: Have client send remedial key exchange message (containing one key) if needed. 3) Duplicate master secrets: ---------------------------- The handshake does not hash exchange keys into master secret, and as such is vulernable to duplicated master secrets. This leads to THS and other vulernabilities. Yes, those could also be addressed with validating keys, but some implementations will just omit that and be vulernable. The proposed THS fix does actually work here (it says to cut off transcript as soon as all exchange keys are sent, which is enough). In (EC)DHE, certificates do not contain exchange keys. But having to use that extension in TLS 1.3 would be sad (the TLS 1.3 key exchange should not be vulernable to THS&co no matter what). Proposal: Hash the transcript up to where server's ChangeCipherSpec appears and make the master secret depend upon that (this is equivalent to what proposed THS fix would do). That is: ClientHello, ServerHello, ServerKeyExchange (if present) and ClientKeyExchange (if present). 4) Problems with PSK: --------------------- PSK has specific key exchange format, and the PSK spec has something called identity_hint (which requires protocol on top to specify what it means). If there is no identity_hint, the client could send its identity in ClientHello. Otherwise this needs extra RTT. Proposal: Does this need to be supported (some very constrained devices seem to use PSK)? If yes: - Client can send PSK identity in ClientHello. In this case, both ClientKeyExchange and ServerKeyExchange are absent. - If no PSK identity in ClientHello, server sends identity hint in ServerKeyExchange (forced present) and client sends PSK identity in ClientKeyExchange. 5) Problems with DHE_PSK: ------------------------- DHE_PSK has different specific format for KeyExchange messages. The problems here are mostly similar to PSK, but there is additional one: The identity is not DH algorithm specific, but shared among all algorithms. Proposal: Does this need to be supported? If yes: - Client can send PSK identity in ClientHello. DH key exchange proceeds as usual. - No PSK identity in ClientHello, server sends indentity hint in ServerKeyExchange and client sends PSK identity and possibly key in ClientKeyExchange. 6) Problems with SRP: --------------------- SRP in general needs ServerKeyExchange before ClientKeyExchange. Now, if client is able to guess the exchange group, the order of those two can be inverted. Also, the key exchange messages have their own format. Some additional issues: - The key shares are relatively large (multiplicative group!) - The key shares are relatively slow to generate (ditto) - The usual SRP groups do not match named groups. There is no straightforward way to make ECC SRP. Also, SRP is seemingly pretty much unused in context of TLS. Proposal: Does this need to be supported? If yes, just force remedial ClientKeyExchange (2RTT) with SRP-specific ServerKeyExchange/ClientKeyExchange format. 7) RSA_PSK: ----------- RSA_PSK is another (non-PFS) variant of PSK. Does not seem to be of much use. Proposal: Not supported at all. 8) 0RTT issues: --------------- Due to how applications work, failed 0RTT must smoothly fall back. Losing the connection is not acceptable. Losing the initial data is acceptable (client TLS stack can retransmit it, presumably is not large). And because duplicate ClientHello seems like asking for trouble, it follows that 0RTT handshake should be like 1RTT, except for extra encrypted data. Also, because of difficulties in FS with 0RTT, one should still do full rekey of the connection. Proposal: Have optional extension for early encrypted data in ClientHello. The server can accept or refuse it (signaling that in ServerHello). Either way, the exchange otherwise proceeds normally. If server refuses, client retransmits the data after it completes the handshake. 9) Issue #71: ------------- Traditionally TLS has split between DH and ECDH. But there is no technical reason for that outside of arbitrary groups (which seem like bad idea). Also, if the spaces are unified, it would be useful to allow some group to use special formats. Would make easier to support some more special DH functions (e.g. Curve25519). Also, one could make the group space 2 bytes, with 0-255 mapping to draft-dkg groups. This runs into issues with ciphersuite names (since there would be no difference between _ECDHE_ and _DHE_). But then, TLS seems to get into similar trouble (but with signatures) already via signature_algorithms extension (which is defined in base TLS 1.2 document). Proposal: ? 10) Editorial: -------------- In section "Client Authentication and Key Exchange Messages", there is: - Seemingly duplicate struct ClientKeyExchange (looks like old version) - Seemingly unused struct PreMasterSecret (looks RSA-related) - Seemingly transitively unused struct ClientDiffieHellmanPublic - Seemingly transitively unused enum PublicValueEncoding. Proposal: Remove those. -Ilari From nobody Wed Aug 20 11:24:48 2014 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 95A151A0639 for ; Wed, 20 Aug 2014 11:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.023 X-Spam-Level: X-Spam-Status: No, score=0.023 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 U2-ehIRG0HyE for ; Wed, 20 Aug 2014 11:24:39 -0700 (PDT) Received: from mail-we0-f173.google.com (mail-we0-f173.google.com [74.125.82.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DC81A0694 for ; Wed, 20 Aug 2014 11:23:56 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so8347608wes.32 for ; Wed, 20 Aug 2014 11:23:55 -0700 (PDT) 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-type; bh=PlwIGnvehX7zWYrZ4p0Qiyj1LhvPxo+OC1EIBLtedbQ=; b=IIQpQ6Pmsl9zqvcZAw2HRtEF5UZTz9j9Dd2U/nk7eKsbm09qltAfToyvYjDNMFC+nG yhlvgN5+L4x1VFEp6q6sfukcutiZv19LthhLkuKbGBeSdNZP2tOr2KEGrfPh1rn2LBBK G+pLwq6jdQw/PTh+supEVrJfR7808hr+RaFCFGOQ4TKZRMmdNqoK8S8KOxckx6mv/r1s 0DA24cM93TgiYk0upDeP5kbV0Hx4X7MYq5bvHH/2o03tU7zaTv/zCbt8eHw1S9jrvdjX 8H4/sVrE5lS+o37LPw6kS5PkmTAeDR5lAT1IGd947aN15si0wdYCMm84PduDPBScVeWQ 00rg== X-Gm-Message-State: ALoCoQmLRjLdXVdV5JdjdNoXrVSt36qI57+MX2Fy2gWyWHIMOI9hZ/BWSbqSjhjXImWIjdBiQUES X-Received: by 10.180.37.77 with SMTP id w13mr16881072wij.78.1408559035492; Wed, 20 Aug 2014 11:23:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 20 Aug 2014 11:23:15 -0700 (PDT) X-Originating-IP: [2620:101:80fb:232:6d2d:1a2c:b54f:6ed8] In-Reply-To: <20140820164500.GA26426@LK-Perkele-VII> References: <20140820164500.GA26426@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 20 Aug 2014 11:23:15 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=e89a8f647021f4c44f050113b4bf Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M3SdOqEbNrBvdD8UWXlhsfwKzo8 Cc: tls mailing list Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 20 Aug 2014 18:24:42 -0000 --e89a8f647021f4c44f050113b4bf Content-Type: text/plain; charset=UTF-8 Ilari, thanks for your detailed comments. On Wed, Aug 20, 2014 at 9:45 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > Here is listing of some problems with proposed TLS 1.3 handshake > protocol (of various severity), and some proposals how to solve those. > > > 1) Is ClientKeyExchange coming? > ------------------------------- > > Because the handshake protocol uses transcripts, it requires that both > sides always know who will transmit next, which impiles knowing when > peer's flight has ended. > > This goes badly with ClientKeyExchange. It is optional, and there is > no marker for end of flight. As consequence, the first flight can > end with either ClientHello or ClientKeyExchange. > > Proposal: Stick those first flight key exchange messages inside > ClientHello. > The ClientKeyExchange is actually not intended to be optional. The client sends a ClientHello message which contains a random nonce (ClientHello.random), its preferences for Protocol Version, Cipher Suite, and a variety of extensions. In the same flight, it sends a ClientKeyExchange message which contains its share of the parameters for key agreement for some set of expected server parameters (DHE/ECDHE groups, etc.). > 2) Duplicate ClientHello: > ------------------------- > > If the client misses all its guesses about Key Exchange, the current > spec has it restart from ClientHello. > > This seems very dangerous. This kind of repetion is a good source of > bugs. Bugs that one absolutely does not want in any security-sensitive > protocol. > > Proposal: Have client send remedial key exchange message (containing > one key) if needed. > Hmm.. This is actually intended to reduce protocol complexity, since it allows the second half of the missed-guess flow to look identical to a correct guess (several people have made this argument). I agree that it's a potential source of issues, but my sense is these are addressable. What do others think? > 3) Duplicate master secrets: > ---------------------------- > > The handshake does not hash exchange keys into master secret, and as > such is vulernable to duplicated master secrets. > > This leads to THS and other vulernabilities. > > Yes, those could also be addressed with validating keys, but some > implementations will just omit that and be vulernable. > > The proposed THS fix does actually work here (it says to cut off > transcript as soon as all exchange keys are sent, which is enough). > > In (EC)DHE, certificates do not contain exchange keys. > > But having to use that extension in TLS 1.3 would be sad (the TLS > 1.3 key exchange should not be vulernable to THS&co no matter what). > > Proposal: Hash the transcript up to where server's ChangeCipherSpec > appears and make the master secret depend upon that (this is > equivalent to what proposed THS fix would do). > > That is: ClientHello, ServerHello, ServerKeyExchange (if present) > and ClientKeyExchange (if present). > Thanks. We discussed this in Toronto and agreed provisionally to do as you suggestion. I have not edited the draft yet, but I intend to do so soon. 4) Problems with PSK: > --------------------- > > PSK has specific key exchange format, and the PSK spec has something > called identity_hint (which requires protocol on top to specify what > it means). > > If there is no identity_hint, the client could send its identity > in ClientHello. > > Otherwise this needs extra RTT. > > Proposal: Does this need to be supported (some very constrained > devices seem to use PSK)? > > If yes: > - Client can send PSK identity in ClientHello. In this case, both > ClientKeyExchange and ServerKeyExchange are absent. > - If no PSK identity in ClientHello, server sends identity hint in > ServerKeyExchange (forced present) and client sends PSK identity > in ClientKeyExchange. > I think we do need to support PSK but I don't think people have done much thinking about it. My guess is that as a practical matter the server never needs to specify a hint and the client can just supply the identity in the ClientHello. I would be interested in hearing from PSK users how they use it, however. > 6) Problems with SRP: > --------------------- > > SRP in general needs ServerKeyExchange before ClientKeyExchange. > Now, if client is able to guess the exchange group, the order > of those two can be inverted. > > Also, the key exchange messages have their own format. > > Some additional issues: > - The key shares are relatively large (multiplicative group!) > - The key shares are relatively slow to generate (ditto) > - The usual SRP groups do not match named groups. > > There is no straightforward way to make ECC SRP. > > Also, SRP is seemingly pretty much unused in context of TLS. > > Proposal: Does this need to be supported? > > If yes, just force remedial ClientKeyExchange (2RTT) with > SRP-specific ServerKeyExchange/ClientKeyExchange format. > I'm not sure we need SRP, but if we do this seems like a good approach. > 7) RSA_PSK: > ----------- > > RSA_PSK is another (non-PFS) variant of PSK. Does not seem to be of > much use. > > Proposal: Not supported at all. > That seems consistent with our existing decision to always require FS. > 8) 0RTT issues: > --------------- > > Due to how applications work, failed 0RTT must smoothly fall back. > Losing the connection is not acceptable. > > Losing the initial data is acceptable (client TLS stack can retransmit > it, presumably is not large). > > And because duplicate ClientHello seems like asking for trouble, it > follows that 0RTT handshake should be like 1RTT, except for extra > encrypted data. > > Also, because of difficulties in FS with 0RTT, one should still do > full rekey of the connection. > > Proposal: Have optional extension for early encrypted data in > ClientHello. The server can accept or refuse it (signaling that in > ServerHello). Either way, the exchange otherwise proceeds normally. > I'm not sure this is enough. What about Client Auth, for instance? > 9) Issue #71: > ------------- > Traditionally TLS has split between DH and ECDH. But there is no > technical reason for that outside of arbitrary groups (which seem > like bad idea). > > Also, if the spaces are unified, it would be useful to allow some > group to use special formats. Would make easier to support some > more special DH functions (e.g. Curve25519). > > Also, one could make the group space 2 bytes, with 0-255 mapping > to draft-dkg groups. > > This runs into issues with ciphersuite names (since there would be > no difference between _ECDHE_ and _DHE_). > > But then, TLS seems to get into similar trouble (but with signatures) > already via signature_algorithms extension (which is defined in > base TLS 1.2 document). > > Proposal: ? > I suggest that I generate a new Pull Request with merged spaces as discussed in Toronto and then we can see if we want to incrementally revise that. > 10) Editorial: > -------------- > > In section "Client Authentication and Key Exchange Messages", there is: > - Seemingly duplicate struct ClientKeyExchange (looks like old version) > - Seemingly unused struct PreMasterSecret (looks RSA-related) > - Seemingly transitively unused struct ClientDiffieHellmanPublic > - Seemingly transitively unused enum PublicValueEncoding. > > Proposal: Remove those. > > Thanks. I will clean these up. > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --e89a8f647021f4c44f050113b4bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ilari, thanks for your detailed= comments.

O= n Wed, Aug 20, 2014 at 9:45 AM, Ilari Liusvaara <ilari.liusvaara= @elisanet.fi> wrote:
Here is listing of some problems with proposed TLS 1.3 han= dshake
protocol (of various severity), and some proposals how to solve those.


1) Is ClientKeyExchange coming?
-------------------------------

Because the handshake protocol uses transcripts, it requires that both
sides always know who will transmit next, which impiles knowing when
peer's flight has ended.

This goes badly with ClientKeyExchange. It is optional, and there is
no marker for end of flight. As consequence, the first flight can
end with either ClientHello or ClientKeyExchange.

Proposal: Stick those first flight key exchange messages inside
ClientHello.

The ClientKeyExchange is a= ctually not intended to be optional.


   The client sends a ClientHello message which
   contains a random nonce (ClientHello.random), its preferences for
   Protocol Version, Cipher Suite, and a variety of extensions.  In the
   same flight, it sends a ClientKeyExchange message which contains its
   share of the parameters for key agreement for some set of expected
   server parameters (DHE/ECDHE groups, etc.).


2) Duplicate ClientHello:
-------------------------

If the client misses all its guesses about Key Exchange, the current
spec has it restart from ClientHello.

This seems very dangerous. This kind of repetion is a good source of
bugs. Bugs that one absolutely does not want in any security-sensitive
protocol.

Proposal: Have client send remedial key exchange message (containing
one key) if needed.

Hmm.. This is actua= lly intended to reduce protocol complexity, since it
allows the s= econd half of the missed-guess flow to look identical to
a correc= t guess (several people have made this argument). I agree that
it's a potential source of issues, but my sense is these are addre= ssable.
What do others think?

=C2=A0
3) Duplicate master secrets:
----------------------------

The handshake does not hash exchange keys into master secret, and as
such is vulernable to duplicated master secrets.

This leads to THS and other vulernabilities.

Yes, those could also be addressed with validating keys, but some
implementations will just omit that and be vulernable.

The proposed THS fix does actually work here (it says to cut off
transcript as soon as all exchange keys are sent, which is enough).

In (EC)DHE, certificates do not contain exchange keys.

But having to use that extension in TLS 1.3 would be sad (the TLS
1.3 key exchange should not be vulernable to THS&co no matter what).
Proposal: Hash the transcript up to where server's ChangeCipherSpec
appears and make the master secret depend upon that (this is
equivalent to what proposed THS fix would do).

That is: ClientHello, ServerHello, ServerKeyExchange (if present)
and ClientKeyExchange (if present).

Tha= nks. We discussed this in Toronto and agreed provisionally to do
= as you suggestion. I have not edited the draft yet, but I intend to do
so soon.


4) Problems with PSK:
---------------------

PSK has specific key exchange format, and the PSK spec has something
called identity_hint (which requires protocol on top to specify what
it means).

If there is no identity_hint, the client could send its identity
in ClientHello.

Otherwise this needs extra RTT.

Proposal: Does this need to be supported (some very constrained
devices seem to use PSK)?

If yes:
- Client can send PSK identity in ClientHello. In this case, both
=C2=A0 ClientKeyExchange and ServerKeyExchange are absent.
- If no PSK identity in ClientHello, server sends identity hint in
=C2=A0 ServerKeyExchange (forced present) and client sends PSK identity
=C2=A0 in ClientKeyExchange.

I think we= do need to support PSK but I don't think people have done
mu= ch thinking about it. My guess is that as a practical matter the
server never needs to specify a hint and the client can just supply
the identity in the ClientHello. I would be interested in hearing from
PSK users how they use it, however.


6) Problems with SRP:
---------------------

SRP in general needs ServerKeyExchange before ClientKeyExchange.
Now, if client is able to guess the exchange group, the order
of those two can be inverted.

Also, the key exchange messages have their own format.

Some additional issues:
- The key shares are relatively large (multiplicative group!)
- The key shares are relatively slow to generate (ditto)
- The usual SRP groups do not match named groups.

There is no straightforward way to make ECC SRP.

Also, SRP is seemingly pretty much unused in context of TLS.

Proposal: Does this need to be supported?

If yes, just force remedial ClientKeyExchange (2RTT) with
SRP-specific ServerKeyExchange/ClientKeyExchange format.

I'm not sure we need SRP, but if we do this seems lik= e a good approach.
=C2=A0
7) RSA_PSK:
-----------

RSA_PSK is another (non-PFS) variant of PSK. Does not seem to be of
much use.

Proposal: Not supported at all.

That se= ems consistent with our existing decision to always require FS.
<= br>

=C2=A0
8) 0RTT issues:
---------------

Due to how applications work, failed 0RTT must smoothly fall back.
Losing the connection is not acceptable.

Losing the initial data is acceptable (client TLS stack can retransmit
it, presumably is not large).

And because duplicate ClientHello seems like asking for trouble, it
follows that 0RTT handshake should be like 1RTT, except for extra
encrypted data.

Also, because of difficulties in FS with 0RTT, one should still do
full rekey of the connection.

Proposal: Have optional extension for early encrypted data in
ClientHello. The server can accept or refuse it (signaling that in
ServerHello). Either way, the exchange otherwise proceeds normally.

I'm not sure this is enough. What about Cl= ient Auth, for instance?



9) Issue #71:
-------------
Traditionally TLS has split between DH and ECDH. But there is no
technical reason for that outside of arbitrary groups (which seem
like bad idea).

Also, if the spaces are unified, it would be useful to allow some
group to use special formats. Would make easier to support some
more special DH functions (e.g. Curve25519).

Also, one could make the group space 2 bytes, with 0-255 mapping
to draft-dkg groups.

This runs into issues with ciphersuite names (since there would be
no difference between _ECDHE_ and _DHE_).

But then, TLS seems to get into similar trouble (but with signatures)
already via signature_algorithms extension (which is defined in
base TLS 1.2 document).

Proposal: ?

I suggest that I generate a= new Pull Request with merged spaces as discussed
in Toronto and = then we can see if we want to incrementally revise
that.
=C2=A0
10) Editorial:
--------------

In section "Client Authentication and Key Exchange Messages", the= re is:
- Seemingly duplicate struct ClientKeyExchange (looks like old version)
- Seemingly unused struct PreMasterSecret (looks RSA-related)
- Seemingly transitively unused struct ClientDiffieHellmanPublic
- Seemingly transitively unused enum PublicValueEncoding.

Proposal: Remove those.


Thanks. I w= ill clean these up.
=C2=A0
-Ilari

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

--e89a8f647021f4c44f050113b4bf-- From nobody Wed Aug 20 22:06:20 2014 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 9B6401A8028 for ; Wed, 20 Aug 2014 22:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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, RP_MATCHES_RCVD=-0.668, 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 P-mpClhNM8sV for ; Wed, 20 Aug 2014 22:06:17 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FA11A70FE for ; Wed, 20 Aug 2014 22:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=370; q=dns/txt; s=iport; t=1408597577; x=1409807177; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=WuZGUeNBBOMBSXVVSlUPSJkhqnLJUNogoBHPeNrFtRA=; b=EzqtR0cESXpIjjMgddx5HD5TBZhiXFTc3GTvEUf4ZvUExbGiaGVe6RAn aFfjeB1lMFx7tkSD+j63zTZpwX8xpq2APbMMkPf+LRbbMAYm+/oD4tUbm yFQPiVfk4nSAAShU3p3IIozLgiWU67BF5KcyqghYNK/A+St+gkNtkoudx o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMp99VOtJV2P/2dsb2JhbABagw2BLtU0FneECjpRAT5CJwSIVZx8pGEXkwKBHQWRJYsflQqBZRyBXII0gQcBAQE X-IronPort-AV: E=Sophos;i="5.01,906,1400025600"; d="scan'208";a="71078909" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-5.cisco.com with ESMTP; 21 Aug 2014 05:06:16 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7L56GNV029557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Aug 2014 05:06:16 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 21 Aug 2014 00:06:16 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Early code-point assignment for draft-ietf-tls-session-hash Thread-Index: AQHPvP2i8FmE+xBKU0OpoHZGpRLOTg== Date: Thu, 21 Aug 2014 05:06:16 +0000 Message-ID: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.81] Content-Type: text/plain; charset="us-ascii" Content-ID: <90CCB5DB36D14040846A3CED28AA7BB2@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pPJ3udKSx_Xp6Rr5nFOHPIPI-Go Subject: [TLS] Early code-point assignment for draft-ietf-tls-session-hash 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, 21 Aug 2014 05:06:18 -0000 We have a request for early code point assignment for the extended_master_s= ecret extension in draft-ietf-tls-session-hash. I've asked the authors to = update the draft with an IANA section including the details. If anyone has= a concern with early code point assignment for this draft, please respond = to the list by September 3, 2014. =20 Thanks, J&S= From nobody Wed Aug 20 22:13:06 2014 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 E381B1A6F96 for ; Wed, 20 Aug 2014 22:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 KXCdPUQbe067 for ; Wed, 20 Aug 2014 22:13:01 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1769D1A042D for ; Wed, 20 Aug 2014 22:13:00 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so7866643wiv.15 for ; Wed, 20 Aug 2014 22:12:59 -0700 (PDT) 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-type; bh=tYpvVN4R2QzoQeoxTwsfh+JSbwAXcbmwOJZkSxGq3sc=; b=Fs4LAdHu+2QLLnZ9qBCD7OBuQ73sAl7CWq3x4I8WBFjNmbUUserrgIfteSpXrKPRG7 mzrk3TwubFMTbaCUdxGqzm/t+xzZBIxcQfQB2bjeNxLKyYvijq9dvprkLSw8s1cr9jQr sNxo/TWmSSuSHm5kBsYkEk7GrrdoPGfC4Ht5ykk0SEnq78WYOFgAGiGzQy/8zF4hJJ/Q ZFEs6BFMLDbX95KXKOcqjQbWTMu+FfAOz+JD/uoEBHu7aLKDUNkxR6ja4mKaPzL5C7Zs oRl/vV3w32V7DQBnofjcIMeJWwnvhlJHwPU77Pc/4MvTmt8o44wHcNz2JuMRqzQ6hyg6 LSqA== X-Gm-Message-State: ALoCoQkdkSDhkDnMu8oJR7GMXtzWl4+ehqBq1AFfJwB2qygt5QxyHGGbGOfwNo1X2TLW8uGwUYER X-Received: by 10.180.78.100 with SMTP id a4mr20336813wix.36.1408597979727; Wed, 20 Aug 2014 22:12:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 20 Aug 2014 22:12:19 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> From: Eric Rescorla Date: Wed, 20 Aug 2014 22:12:19 -0700 Message-ID: To: "Joseph Salowey (jsalowey)" Content-Type: multipart/alternative; boundary=f46d043890eb369fe705011cc672 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hSjag62WcXaWkNC8pjRsnAg5bu4 Cc: "" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash 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, 21 Aug 2014 05:13:03 -0000 --f46d043890eb369fe705011cc672 Content-Type: text/plain; charset=UTF-8 +1 On Wed, Aug 20, 2014 at 10:06 PM, Joseph Salowey (jsalowey) < jsalowey@cisco.com> wrote: > We have a request for early code point assignment for the > extended_master_secret extension in draft-ietf-tls-session-hash. I've > asked the authors to update the draft with an IANA section including the > details. If anyone has a concern with early code point assignment for this > draft, please respond to the list by September 3, 2014. > > Thanks, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d043890eb369fe705011cc672 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Wed, Aug 20, 2014 at 10:06 PM, Joseph Salowey (jsalowey) <= jsalowey@cisco.com> wrote:
We have a request for early code point assig= nment for the extended_master_secret extension in draft-ietf-tls-session-ha= sh.=C2=A0 I've asked the authors to update the draft with an IANA secti= on including the details.=C2=A0 If anyone has a concern with early code poi= nt assignment for this draft, please respond to the list by September 3, 20= 14.

Thanks,

J&S
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--f46d043890eb369fe705011cc672-- From nobody Thu Aug 21 10:52:24 2014 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 7DF031A0B04 for ; Thu, 21 Aug 2014 10:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 QAK2AaSXRofo for ; Thu, 21 Aug 2014 10:52:20 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF8801A0AF5 for ; Thu, 21 Aug 2014 10:52:19 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 98F99699D2; Thu, 21 Aug 2014 20:52:17 +0300 (EEST) Date: Thu, 21 Aug 2014 20:52:17 +0300 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20140821175217.GA2955@LK-Perkele-VII> References: <20140820164500.GA26426@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cQsN3W4HL2stAw-mHJuqw0ns33Q Cc: tls mailing list Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 21 Aug 2014 17:52:22 -0000 On Wed, Aug 20, 2014 at 11:23:15AM -0700, Eric Rescorla wrote: > > On Wed, Aug 20, 2014 at 9:45 AM, Ilari Liusvaara < > ilari.liusvaara@elisanet.fi> wrote: > > > > > > 1) Is ClientKeyExchange coming? > > ------------------------------- > > > > Because the handshake protocol uses transcripts, it requires that both > > sides always know who will transmit next, which impiles knowing when > > peer's flight has ended. > > > > This goes badly with ClientKeyExchange. It is optional, and there is > > no marker for end of flight. As consequence, the first flight can > > end with either ClientHello or ClientKeyExchange. > > > > Proposal: Stick those first flight key exchange messages inside > > ClientHello. > > > > The ClientKeyExchange is actually not intended to be optional. > > > The client sends a ClientHello message which > contains a random nonce (ClientHello.random), its preferences for > Protocol Version, Cipher Suite, and a variety of extensions. In the > same flight, it sends a ClientKeyExchange message which contains its > share of the parameters for key agreement for some set of expected > server parameters (DHE/ECDHE groups, etc.). You mean that if protocol version (not to be confused with client version) in ClientHello is 1.3 (0x0304), then ClientKeyExchange follows, otherwise it is packaged inside ClientHello (TLS 1.2 compatiblity)? Flights can't be reliably detected without reference to state machine. > 4) Problems with PSK: > > --------------------- > > > > PSK has specific key exchange format, and the PSK spec has something > > called identity_hint (which requires protocol on top to specify what > > it means). > > > > If there is no identity_hint, the client could send its identity > > in ClientHello. > > > > Otherwise this needs extra RTT. > > > > Proposal: Does this need to be supported (some very constrained > > devices seem to use PSK)? > > > > If yes: > > - Client can send PSK identity in ClientHello. In this case, both > > ClientKeyExchange and ServerKeyExchange are absent. > > - If no PSK identity in ClientHello, server sends identity hint in > > ServerKeyExchange (forced present) and client sends PSK identity > > in ClientKeyExchange. > > > > I think we do need to support PSK but I don't think people have done > much thinking about it. My guess is that as a practical matter the > server never needs to specify a hint and the client can just supply > the identity in the ClientHello. I would be interested in hearing from > PSK users how they use it, however. Did some digging among RFCs, and RFC 5415 ("Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification") seems to use PSK identity hints. That RFC a PS, no idea if it is actually used (and even if used, if it uses PSK in real world). Additionally, RFC 7252 ("The Constrained Application Protocol (CoAP)") seems to push if to use identity hints or not upwards. There are lots of drafts referencing this normatively, haven't checked if those do any- thing with the hint or not. > > 8) 0RTT issues: > > --------------- > > > > Proposal: Have optional extension for early encrypted data in > > ClientHello. The server can accept or refuse it (signaling that in > > ServerHello). Either way, the exchange otherwise proceeds normally. > > > > I'm not sure this is enough. What about Client Auth, for instance? Also, 0RTT interacts with ALPN (so that the data is not given to wrong protocol). Could be done by either requiring client to specify only one protocol or allowing multiple pieces of data, one per protocol. -Ilari From nobody Thu Aug 21 11:19:16 2014 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 EF0B21A049A for ; Thu, 21 Aug 2014 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZI0ikfxwNCY for ; Thu, 21 Aug 2014 11:19:14 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACD91A048E for ; Thu, 21 Aug 2014 11:19:13 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so9121448wib.15 for ; Thu, 21 Aug 2014 11:19: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:content-type; bh=yQNdtnAD1XSOS4xLzc7DWG6XQ9hrGQwuEyJvMcwb6yo=; b=F6IbR8HkBkgKTS/Bi9pDGwEBKXPmldPAKB+kyDOaqbKUWIyIiGAt+fxBbi95MwF6Sk 9Y5VysABH8Amk2SGzVPKzb8oIHgo/dSccxLXZ0L/w9zGwfywpoZYiVPAdqe9oJk/fh8Q x6KdxpeUk6nI4yAz0eJjzWTb1TiEGechh8I6JAs79b79MLAcGTaKmLax8UmeEsemIEkz rInMlnKSlvyU65Li5IXP+3hnTGBo6HNX5uTfJYbi+TvRhhvCH9sCmOx5jmhuXnm4jzSP ygd0d629D8uSARgDqQ1lVBsIvQShPeZqfKVXlPXuZm8wxLPnZKtWDewFVYFGi7M1wVz5 +yIA== MIME-Version: 1.0 X-Received: by 10.194.59.244 with SMTP id c20mr165097wjr.59.1408645152340; Thu, 21 Aug 2014 11:19:12 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 21 Aug 2014 11:19:12 -0700 (PDT) In-Reply-To: <20140821175217.GA2955@LK-Perkele-VII> References: <20140820164500.GA26426@LK-Perkele-VII> <20140821175217.GA2955@LK-Perkele-VII> Date: Thu, 21 Aug 2014 11:19:12 -0700 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GV7KsicoYt-RL7q79ZzWYd7JOzc Cc: tls mailing list Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 21 Aug 2014 18:19:15 -0000 On 21 August 2014 10:52, Ilari Liusvaara wrote: > You mean that if protocol version (not to be confused with client version) > in ClientHello is 1.3 (0x0304), then ClientKeyExchange follows, otherwise > it is packaged inside ClientHello (TLS 1.2 compatiblity)? I don't think that there is any scenario where putting the ClientKeyExchange outside of the ClientHello extensions is going to produce good results. I had assumed that it would always have to appear in the extension. From nobody Thu Aug 21 11:24:42 2014 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 3E7641A05E5 for ; Thu, 21 Aug 2014 11:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 lll9kAt8WoGe for ; Thu, 21 Aug 2014 11:24:38 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC001A058E for ; Thu, 21 Aug 2014 11:24:37 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id n3so11933wiv.2 for ; Thu, 21 Aug 2014 11:24:36 -0700 (PDT) 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-type; bh=WvT/+lrZSpyqH4oCEQqA4exn+l/FkCO9IMlXviKMeU4=; b=XUmNQXuyUc3FkVUc+Lkg6EkhU5jXQUWFLSuCvdIDILRbpDe3Ugk6bhAkgntwaROt2I BUq9JHC0mJvUr+tYyTnn/FXISiRHeUggRjlF+gFo/1QbAc7K8FI3rAexrmKjquas8i2c hy8dnWPhuM7KXSD1EEe3++D6oHo0hIsfS5ejIQPi0etrokYgXbrhhTNSA2mVUyYszznP WYanxsRy2Z2odyy54DbzFlhWHmKtNGZWiVo/SFFUxKAvOYEwZKlPamBXEBcbyHTBjK6G L9KRDWg1aQj0occ8HlyQotkOZhoDI9rp9/16buoY5IpeeDF7Yx5W1/m3HTZ3/9u2e+kx sChQ== X-Gm-Message-State: ALoCoQkf1IFCvCmbYJm06psNXvmAmtgCAh9JwqTmG0y+ebgZMI3zMvRiI8HGE8+lceyo3nbVAjng X-Received: by 10.180.78.100 with SMTP id a4mr24161621wix.36.1408645476662; Thu, 21 Aug 2014 11:24:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Thu, 21 Aug 2014 11:23:56 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:c0c8:d568:c61d:f25e] In-Reply-To: <20140821175217.GA2955@LK-Perkele-VII> References: <20140820164500.GA26426@LK-Perkele-VII> <20140821175217.GA2955@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 21 Aug 2014 11:23:56 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=f46d043890eb4060ca050127d5b9 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FIIkMENcs1uaAxWafXZcWaeb8b0 Cc: tls mailing list Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 21 Aug 2014 18:24:40 -0000 --f46d043890eb4060ca050127d5b9 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 21, 2014 at 10:52 AM, Ilari Liusvaara < ilari.liusvaara@elisanet.fi> wrote: > On Wed, Aug 20, 2014 at 11:23:15AM -0700, Eric Rescorla wrote: > > > > On Wed, Aug 20, 2014 at 9:45 AM, Ilari Liusvaara < > > ilari.liusvaara@elisanet.fi> wrote: > > > > > > > > > 1) Is ClientKeyExchange coming? > > > ------------------------------- > > > > > > Because the handshake protocol uses transcripts, it requires that both > > > sides always know who will transmit next, which impiles knowing when > > > peer's flight has ended. > > > > > > This goes badly with ClientKeyExchange. It is optional, and there is > > > no marker for end of flight. As consequence, the first flight can > > > end with either ClientHello or ClientKeyExchange. > > > > > > Proposal: Stick those first flight key exchange messages inside > > > ClientHello. > > > > > > > The ClientKeyExchange is actually not intended to be optional. > > > > > > The client sends a ClientHello message which > > contains a random nonce (ClientHello.random), its preferences for > > Protocol Version, Cipher Suite, and a variety of extensions. In the > > same flight, it sends a ClientKeyExchange message which contains its > > share of the parameters for key agreement for some set of expected > > server parameters (DHE/ECDHE groups, etc.). > > You mean that if protocol version (not to be confused with client version) > in ClientHello is 1.3 (0x0304), then ClientKeyExchange follows, otherwise > it is packaged inside ClientHello (TLS 1.2 compatiblity)? > What I was thinking was that upon reading the ClientHello if the offered version number (in the ClientHello) was TLS 1.3, the server would then expect a ClientKeyExchange. It would first process whatever was in the ClientHello in EarlyData and if that was not present would read whatever handshake messages were on the wire. -Ekr > 4) Problems with PSK: > > > --------------------- > > > > > > PSK has specific key exchange format, and the PSK spec has something > > > called identity_hint (which requires protocol on top to specify what > > > it means). > > > > > > If there is no identity_hint, the client could send its identity > > > in ClientHello. > > > > > > Otherwise this needs extra RTT. > > > > > > Proposal: Does this need to be supported (some very constrained > > > devices seem to use PSK)? > > > > > > If yes: > > > - Client can send PSK identity in ClientHello. In this case, both > > > ClientKeyExchange and ServerKeyExchange are absent. > > > - If no PSK identity in ClientHello, server sends identity hint in > > > ServerKeyExchange (forced present) and client sends PSK identity > > > in ClientKeyExchange. > > > > > > > I think we do need to support PSK but I don't think people have done > > much thinking about it. My guess is that as a practical matter the > > server never needs to specify a hint and the client can just supply > > the identity in the ClientHello. I would be interested in hearing from > > PSK users how they use it, however. > > Did some digging among RFCs, and RFC 5415 ("Control And Provisioning of > Wireless Access Points (CAPWAP) Protocol Specification") seems to use > PSK identity hints. > > That RFC a PS, no idea if it is actually used (and even if used, if it > uses PSK in real world). > > Additionally, RFC 7252 ("The Constrained Application Protocol (CoAP)") > seems to push if to use identity hints or not upwards. There are lots > of drafts referencing this normatively, haven't checked if those do any- > thing with the hint or not. > > > > > 8) 0RTT issues: > > > --------------- > > > > > > Proposal: Have optional extension for early encrypted data in > > > ClientHello. The server can accept or refuse it (signaling that in > > > ServerHello). Either way, the exchange otherwise proceeds normally. > > > > > > > I'm not sure this is enough. What about Client Auth, for instance? > > Also, 0RTT interacts with ALPN (so that the data is not given to > wrong protocol). Could be done by either requiring client to specify > only one protocol or allowing multiple pieces of data, one per protocol. > > > -Ilari > --f46d043890eb4060ca050127d5b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Thu, Aug 21, 2014 at 10:52 AM, Ilari Liusvaara <ilari= .liusvaara@elisanet.fi> wrote:
On Wed, Aug 20, 2014 at 11:2= 3:15AM -0700, Eric Rescorla wrote:
>
> On Wed, Aug 20, 2014 at 9:45 AM, Ilari Liusvaara <
> ilari.liusvaara@elisane= t.fi> wrote:
> >
> >
> > 1) Is ClientKeyExchange coming?
> > -------------------------------
> >
> > Because the handshake protocol uses transcripts, it requires that= both
> > sides always know who will transmit next, which impiles knowing w= hen
> > peer's flight has ended.
> >
> > This goes badly with ClientKeyExchange. It is optional, and there= is
> > no marker for end of flight. As consequence, the first flight can=
> > end with either ClientHello or ClientKeyExchange.
> >
> > Proposal: Stick those first flight key exchange messages inside > > ClientHello.
> >
>
> The ClientKeyExchange is actually not intended to be optional.
>
>
>=C2=A0 =C2=A0 The client sends a ClientHello message which
>=C2=A0 =C2=A0 contains a random nonce (ClientHello.random), its prefere= nces for
>=C2=A0 =C2=A0 Protocol Version, Cipher Suite, and a variety of extensio= ns.=C2=A0 In the
>=C2=A0 =C2=A0 same flight, it sends a ClientKeyExchange message which c= ontains its
>=C2=A0 =C2=A0 share of the parameters for key agreement for some set of= expected
>=C2=A0 =C2=A0 server parameters (DHE/ECDHE groups, etc.).

You mean that if protocol version (not to be confused with client ver= sion)
in ClientHello is 1.3 (0x0304), then ClientKeyExchange follows, otherwise it is packaged inside ClientHello (TLS 1.2 compatiblity)?
<= div>
What I was thinking was that upon reading the ClientHell= o if the
offered version number (in the ClientHello) was TLS 1.3,= the server
would then expect a ClientKeyExchange. It would first process whatever=
was in the ClientHello in EarlyData and if that was not present = would
read whatever handshake messages were on the wire.

-Ekr


> 4) Problems with PSK:
> > ---------------------
> >
> > PSK has specific key exchange format, and the PSK spec has someth= ing
> > called identity_hint (which requires protocol on top to specify w= hat
> > it means).
> >
> > If there is no identity_hint, the client could send its identity<= br> > > in ClientHello.
> >
> > Otherwise this needs extra RTT.
> >
> > Proposal: Does this need to be supported (some very constrained > > devices seem to use PSK)?
> >
> > If yes:
> > - Client can send PSK identity in ClientHello. In this case, both=
> >=C2=A0 =C2=A0ClientKeyExchange and ServerKeyExchange are absent. > > - If no PSK identity in ClientHello, server sends identity hint i= n
> >=C2=A0 =C2=A0ServerKeyExchange (forced present) and client sends P= SK identity
> >=C2=A0 =C2=A0in ClientKeyExchange.
> >
>
> I think we do need to support PSK but I don't think people have do= ne
> much thinking about it. My guess is that as a practical matter the
> server never needs to specify a hint and the client can just supply > the identity in the ClientHello. I would be interested in hearing from=
> PSK users how they use it, however.

Did some digging among RFCs, and RFC 5415 ("Control And Provisio= ning of
Wireless Access Points (CAPWAP) Protocol Specification") seems to use<= br> PSK identity hints.

That RFC a PS, no idea if it is actually used (and even if used, if it
uses PSK in real world).

Additionally, RFC 7252 ("The Constrained Application Protocol (CoAP)&q= uot;)
seems to push if to use identity hints or not upwards. There are lots
of drafts referencing this normatively, haven't checked if those do any= -
thing with the hint or not.


> > 8) 0RTT issues:
> > ---------------
> >
> > Proposal: Have optional extension for early encrypted data in
> > ClientHello. The server can accept or refuse it (signaling that i= n
> > ServerHello). Either way, the exchange otherwise proceeds normall= y.
> >
>
> I'm not sure this is enough. What about Client Auth, for instance?=

Also, 0RTT interacts with ALPN (so that the data is not given to
wrong protocol). Could be done by either requiring client to specify
only one protocol or allowing multiple pieces of data, one per protocol.

-Ilari

--f46d043890eb4060ca050127d5b9-- From nobody Thu Aug 21 12:35:02 2014 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 895BA1A0689 for ; Thu, 21 Aug 2014 12:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 aUpkgOb-KLbZ for ; Thu, 21 Aug 2014 12:34:59 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40F4D1A067A for ; Thu, 21 Aug 2014 12:34:59 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so9649976wes.23 for ; Thu, 21 Aug 2014 12:34:57 -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-type; bh=L9ooNlRAuS2kP8wV0NovXcxAbfybCi4cP4VUQKbkTNs=; b=njtyXB1FLzWbJg19wcE/c09+cjkc37R8uX7BgW+z0jzuW6KVDxvLAAARz8OWCoGxA/ 05zI4OsCeKEHtv0TDtbU5QwOzhYz6xI2JdYe890y5Pjo+imyt6Hr4RuxD/wI5ddSmyrr HZyjgFNk3PGf3sLiqvpckPRq2ivh/OZ4nz0yTvebhOBNmrIgn6ZYf4GH0yVdw5P/WpgH s8zp90FLV1aCD3N/0t2UFYh3wcjdWJwrSOnJdOVka42KWZ6o/igs7GXwYIW5V3QjNCiA +rt4vl5EdJa34D0rmDobOqohMYZ3mu6efFldSvbymJ+kdp6i9aTOekxRqG9IrtCQBasM DhLA== MIME-Version: 1.0 X-Received: by 10.194.81.37 with SMTP id w5mr697754wjx.12.1408649697941; Thu, 21 Aug 2014 12:34:57 -0700 (PDT) Received: by 10.194.6.229 with HTTP; Thu, 21 Aug 2014 12:34:57 -0700 (PDT) In-Reply-To: References: <20140820164500.GA26426@LK-Perkele-VII> <20140821175217.GA2955@LK-Perkele-VII> Date: Thu, 21 Aug 2014 12:34:57 -0700 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9LVOh_l4IR25YkFR9dCzV_nHEM4 Cc: tls mailing list Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 21 Aug 2014 19:35:00 -0000 On 21 August 2014 11:23, Eric Rescorla wrote: > What I was thinking was that upon reading the ClientHello if the > offered version number (in the ClientHello) was TLS 1.3, the server > would then expect a ClientKeyExchange. It would first process whatever > was in the ClientHello in EarlyData and if that was not present would > read whatever handshake messages were on the wire. Is the non-extension variant ever going to be safe to send? From nobody Thu Aug 21 22:16:52 2014 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 E67781A003A for ; Thu, 21 Aug 2014 22:16: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uha-gNukbbeX for ; Thu, 21 Aug 2014 22:16:45 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501051A0029 for ; Thu, 21 Aug 2014 22:16:45 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id z107so6470266qgd.9 for ; Thu, 21 Aug 2014 22:16:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GD7w5j0vlyYyjFXOt4WBLfoCKKYV4LvglRyqVE6G61E=; b=FTL1geonz4QzEkdu8F9X+DjH8xNOZ/BVH8k0oeozfJrrxWkcBOvNTLyTlrjusMFDmB z+G88VqLu0AKC4PX3jduM/bXaVpgpVwOTM3tr5j+NuG8omOAk1XHXq2Ek8DSS5XJ0ERm b4LHR8Z6sF7BrjEEeZC2Jo7fGTHVXZEHX7Xmubpax8avX1lUSzIOFAw/joxqZGUwp4Sh DLKnOg+5FrbAI6Op8BsVqsnwJJqZNZGqIU1ubqH+WN1ZBIoO42gbdxbxPV4fqV55oRup V3I/aEcf2d59OvxOSs6CtzbA81dvKG1zJ1v7HNLStkTsrfbABMvy2tPzi3w9d3VfEVo2 huLw== X-Gm-Message-State: ALoCoQngimF+NVZFBrl1/ju6eQ7N5pUgZDroTjnsLWbo/Oa94LZv4K5mQNXKCksvGEvUklTZu0ta X-Received: by 10.229.26.10 with SMTP id b10mr4602789qcc.29.1408684603325; Thu, 21 Aug 2014 22:16:43 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:344:84b1:781c:6435:fe31? ([2601:a:2a00:344:84b1:781c:6435:fe31]) by mx.google.com with ESMTPSA id b19sm51624930qaw.44.2014.08.21.22.16.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 22:16:42 -0700 (PDT) Message-ID: <53F6D23E.9080806@nthpermutation.com> Date: Fri, 22 Aug 2014 01:16:46 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140820164500.GA26426@LK-Perkele-VII> <20140821175217.GA2955@LK-Perkele-VII> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pkUMHzL7H6DcE3k0AGxQJ2P52Y8 Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 22 Aug 2014 05:16:47 -0000 On 8/21/2014 3:34 PM, Martin Thomson wrote: > On 21 August 2014 11:23, Eric Rescorla wrote: >> What I was thinking was that upon reading the ClientHello if the >> offered version number (in the ClientHello) was TLS 1.3, the server >> would then expect a ClientKeyExchange. It would first process whatever >> was in the ClientHello in EarlyData and if that was not present would >> read whatever handshake messages were on the wire. > Is the non-extension variant ever going to be safe to send? AFAICT - Not as long as backwards compatibility is required with TLS1.2 and before. If you read the protocol, it could actually work. In practice, the server closes out the TCP connection if it sees out of order messages. That behavior isn't explicitly specified in the TLS RFCs, but seems to be the behavior in practice. For why I say this, read the text in RFC 5246 section 7.2 and compare it to the language in section 4.2.7 of the DTLS RFC 6347. The language used - "termination of the connection" section 7.2 - appears to really refer to the TLS connection, and not the underlying TCP connection, but in practice the fatal error of the TLS session results in a close of the TCP connection. It probably shouldn't. If I were writing this from scratch, I'd make it clear that the TCP connection and the TLS session do not explicitly share states. That would have made a lot of the renegotiation stuff a lot cleaner as the server side handshaker could have just returned to the start state after a fatal error without resulting in a TCP close. But its too late to do that I think. As it stands, we're limited to changes in message sequencing that do not cause a fatal error for TLS1.2 implementations and before. From nobody Fri Aug 22 06:47:16 2014 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 52CD81A03E7; Fri, 22 Aug 2014 06:47:13 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkMWWzUS1RhH; Fri, 22 Aug 2014 06:47:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1367F1A03E6; Fri, 22 Aug 2014 06:47:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140822134712.18593.56531.idtracker@ietfa.amsl.com> Date: Fri, 22 Aug 2014 06:47:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hOFG-OX4-cggOkP6mrVJY39nDaY Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-session-hash-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 22 Aug 2014 13:47:13 -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 Working Group of the IETF. Title : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension Authors : Karthikeyan Bhargavan Antoine Delignat-Lavaud Alfredo Pironti Adam Langley Marsh Ray Filename : draft-ietf-tls-session-hash-01.txt Pages : 8 Date : 2014-08-22 Abstract: The Transport Layer Security (TLS) master secret is not cryptographically bound to important session parameters such as the client and server identities. Consequently, it is possible for an active attacker to set up two sessions, one with a client and another with a server, such that the master secrets on the two sessions are the same. Thereafter, any mechanism that relies on the master secret for authentication, including session resumption, becomes vulnerable to a man-in-the-middle attack, where the attacker can simply forward messages back and forth between the client and server. This specification defines a TLS extension that contextually binds the master secret to a log of the full handshake that computes it, thus preventing such attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-session-hash-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-01 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 Fri Aug 22 12:39:14 2014 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 B384C1A058E for ; Fri, 22 Aug 2014 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 U4trCs2OuIpK for ; Fri, 22 Aug 2014 12:39:11 -0700 (PDT) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5141A056D for ; Fri, 22 Aug 2014 12:39:11 -0700 (PDT) Received: by mail-yk0-f172.google.com with SMTP id 10so8967150ykt.3 for ; Fri, 22 Aug 2014 12:39: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:content-type; bh=zueVcoOupsmvm2RTFbBkmP8J+y5vSyPGKdNcDNkRZcU=; b=Iu49MVjObb1gG0sj4Bwe3se2iygjmpEda30SBuay0ZBfd0H5KHlsqvTI6QQVm1jtVP +/PvovyuVODxuaDD6CRTJQLzHh+a02ezhroJXfj1lkzSG4Z0DEcWe0n7VCcgojUWbtBE pDYLM1k2pZUM2rJUQQDUQkx27lmviedodXsIs4cAMwJIWyKGLb5nFSzsuig88gIGe1ap NNu+bHw3ZOW+W0QFKJsB/x9byoPGRa8SZq0K2X8jPxEExbU4vY2uI9eVnfKaLbT7z1m1 b6KKBAhRtRlKQ9NDFP+Uy4RlgtG2iT7anU2o3rhd2Em+H1z6ReYLp5iH7ZFlLCIZPJq2 SyqA== MIME-Version: 1.0 X-Received: by 10.236.104.133 with SMTP id i5mr4169122yhg.137.1408736351025; Fri, 22 Aug 2014 12:39:11 -0700 (PDT) Received: by 10.170.202.2 with HTTP; Fri, 22 Aug 2014 12:39:10 -0700 (PDT) Date: Fri, 22 Aug 2014 12:39:10 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/X0hJm-fKEVm-jMK-S37IPGV4ov0 Subject: [TLS] Simplifying the proof 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, 22 Aug 2014 19:39:12 -0000 Dear all, While we now have a multi thousand line computer checkable proof of the correctness of the handshake with certain extensions, this is suboptimal in many respects. It's a pain to check, and interaction with extensions is even more painful, which means that extending it to all of TLS 1.3 is going to be even more painful. How can we fix this? Everything goes fine, up until the master-secret gets use to derive keys, and then the Finished message is sent. The reason this isn't good is that we want the keys the record layer uses to be independent of what an attacker saw in the handshake and they aren't because of the Finished message coming after the Change Cipher Spec. If we want key confirmation, we should send a key confirmation value outside the record layer encryption to solve this. We should also work on defining security properties we want new features to have and work backwards, instead of going back from a design to determine the security it actually provides. Sincerely, Watson Ladd From nobody Sat Aug 23 13:22:28 2014 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 03B7B1A88DD for ; Sat, 23 Aug 2014 13:22: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, 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 3vKzHt8rovGd for ; Sat, 23 Aug 2014 13:22:24 -0700 (PDT) Received: from eu1sys200aog116.obsmtp.com (eu1sys200aog116.obsmtp.com [207.126.144.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C47B1A88DB for ; Sat, 23 Aug 2014 13:22:23 -0700 (PDT) Received: from mail-wi0-f181.google.com ([209.85.212.181]) (using TLSv1) by eu1sys200aob116.postini.com ([207.126.147.11]) with SMTP ID DSNKU/j3+45FTrc8K9j2oPUvLgbaZaj5GfPk@postini.com; Sat, 23 Aug 2014 20:22:23 UTC Received: by mail-wi0-f181.google.com with SMTP id bs8so996922wib.2 for ; Sat, 23 Aug 2014 13:22:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ZQdT0EypPi/QRvZZUKj/zE4wZLoKWLrUDcoGhNernhk=; b=LuA/YiT5ndcBjP7nt28kdBWpEDDL4TuuAUW6/ZGmdzH+SX4MuUz7fgiBpgUPseaWpc pL0PqPAiYMurOTKifxMEa6I63/TBmhguwdxqVB0ep1/kCRsKsP3nif6pNsgR/b1rUbTe VFaGRxqXLKO8OfGAIJx90FO8o3ZPR7F3i0K5F2n1xXF/ncA7aopQ4i/s6xdK6DI5OE/C L12nSVf29g1L/LC6r+Jw+HqOWuoKsX5JfqgFdD5vhF/tWbcbAWPYOGuPmg4Z0Id+DTPz xFX97kyJc8EpGGHtC3ccR43Fk8PNpDvioi8dcC8yb/fecYCCxrU0J5Ga+J1aydVmrWuW XkYg== X-Gm-Message-State: ALoCoQkrTIU2CmiBnU3+HdNQvqzUwBGro22+VXf70eFYAhM74zzspUuLZ/bXZgwe7zuLbxF2OsQk5nfWFl/iLSsLNOnqyG1Sx68CLBg/Kr2A2uhHJLmBOjXD6r8B6vI6HUmE2dSSYu1m X-Received: by 10.180.11.177 with SMTP id r17mr5581077wib.67.1408825339098; Sat, 23 Aug 2014 13:22:19 -0700 (PDT) X-Received: by 10.180.11.177 with SMTP id r17mr5581070wib.67.1408825338999; Sat, 23 Aug 2014 13:22:18 -0700 (PDT) Received: from [192.168.1.78] (host109-148-239-24.range109-148.btcentralplus.com. [109.148.239.24]) by mx.google.com with ESMTPSA id gd17sm11899845wic.2.2014.08.23.13.22.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Aug 2014 13:22:18 -0700 (PDT) Message-ID: <53F8F7F8.5080300@cs.bris.ac.uk> Date: Sat, 23 Aug 2014 21:22:16 +0100 From: Nigel Smart User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mPfc8omtM92M24cjKc_KWoBfvfg Subject: Re: [TLS] Simplifying the proof 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, 23 Aug 2014 20:22:26 -0000 On 23/08/2014 20:00, tls-request@ietf.org wrote: > If we want key confirmation, we should send a key confirmation > value outside the record layer encryption to solve this. Not quite true. If the key confirmation is sent un-encrypted one still has a problem as the BR key agreement security definition will not apply. So it depends what you mean by "secure". The correct definition should be to have a combined "KA+secure channel" definition it would appear. There has been multiple work on this over the last couple of years; much in relation to TLS. Nigel From nobody Sat Aug 23 14:26:20 2014 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 36E4B1A06C0 for ; Sat, 23 Aug 2014 14:26:19 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eodVEmbB8y6C for ; Sat, 23 Aug 2014 14:26:17 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3231A06DD for ; Sat, 23 Aug 2014 14:26:17 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id q9so9411321ykb.41 for ; Sat, 23 Aug 2014 14:26: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-type; bh=fY1T4zhUNioM1mnHSrzIrW0Rg+8uOTgPJ8MnEePvt1c=; b=D06q7dyzY78qSytHn8/EAr+WkA/k/nSLT5aEvGpRebtmlvph0wdqP2BXONuLsmn3q4 cCFXH19aaUs5fsI2CjUE5tcpOxIQ9Y6J4Ho0hcsijYi27KYcJHcUnMS41JrAzE+siRm2 1E+NrARHbsLTk3KRQAAvV5OH4/hD46jmSLQuumzHMGE8QVO0Ow1dcOsKPZkYHKkrJIB7 BO+NzNzd3m2vDMjClMkeNVeHCE8FmWUc4w9cQkkYFRri0+VYiCwIdjO3G4xdA9rAZ6Re 2Qm5DejJuZtIS+uAdgx8ntrg/e+6Sa24Px+wvI9vgh6K/DUkxBHnD1DB8TXniesVK4Jq be8Q== MIME-Version: 1.0 X-Received: by 10.236.229.138 with SMTP id h10mr148500yhq.122.1408829177105; Sat, 23 Aug 2014 14:26:17 -0700 (PDT) Received: by 10.170.202.2 with HTTP; Sat, 23 Aug 2014 14:26:16 -0700 (PDT) Received: by 10.170.202.2 with HTTP; Sat, 23 Aug 2014 14:26:16 -0700 (PDT) In-Reply-To: <53F8F7F8.5080300@cs.bris.ac.uk> References: <53F8F7F8.5080300@cs.bris.ac.uk> Date: Sat, 23 Aug 2014 14:26:16 -0700 Message-ID: From: Watson Ladd To: Nigel Smart Content-Type: multipart/alternative; boundary=089e0160c638a691b30501529a27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0gPsr_l5lTEbPeKd1yFOMu-CNFY Cc: tls@ietf.org Subject: Re: [TLS] Simplifying the proof 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, 23 Aug 2014 21:26:19 -0000 --089e0160c638a691b30501529a27 Content-Type: text/plain; charset=UTF-8 On Aug 23, 2014 1:22 PM, "Nigel Smart" wrote: > > On 23/08/2014 20:00,tls-request@ietf.orgwrote: >> >> If we want key confirmation, we should send a key confirmation >> value outside the record layer encryption to solve this. > > > Not quite true. If the key confirmation is sent un-encrypted one still > has a problem as the BR key agreement security definition will not > apply. So it depends what you mean by "secure". The correct > definition should be to have a combined "KA+secure channel" > definition it would appear. There has been multiple work on this > over the last couple of years; much in relation to TLS. You are probably correct: I think BR can include key confirmation but I need to think more about it. However I don't think we should weaken the definitions in response to the failure of TLS to meet them, or even to say clearly what it is trying to do. In particular some new features being proposed don't have obvious security definitions. Sincerely, Watson Ladd > > Nigel > > _______________________________________________ > TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --089e0160c638a691b30501529a27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 23, 2014 1:22 PM, "Nigel Smart" <nigel@cs.bris.ac.uk> wrote:
>
> On 23/08/2014 20:00,tls-reques= t@ietf.orgwrote:
>>
>> If we want key confirmation, we should send a key confirmation
>> value outside the record layer encryption to solve this.
>
>
> Not quite true. If the key confirmation is sent un-encrypted one still=
> has a problem as the BR key agreement security definition will not
> apply.=C2=A0 =C2=A0So it depends what you mean by "secure".= =C2=A0 The correct
> definition should be to have a combined "KA+secure channel"<= br> > definition it would appear. There has been multiple work on this
> over the last couple of years; much in relation to TLS.

You are probably correct: I think BR can include key confirm= ation but I need to think more about it. However I don't think we shoul= d weaken the definitions in response to the failure of TLS to meet them, or= even to say clearly what it is trying to do. In particular some new featur= es being proposed don't have obvious security definitions.

Sincerely,
Watson Ladd
>
> Nigel
>
> _______________________________________________
> TLS mailing list
>TLS@ietf.org
>https://www.ietf.= org/mailman/listinfo/tls

--089e0160c638a691b30501529a27-- From nobody Tue Aug 26 02:28:18 2014 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 560DE1A6EF3 for ; Tue, 26 Aug 2014 02:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.498 X-Spam-Level: ** X-Spam-Status: No, score=2.498 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 UvTaeS8pkzQG for ; Tue, 26 Aug 2014 02:28:13 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id E2B8A1A6EF1 for ; Tue, 26 Aug 2014 02:28:12 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-27-55-207-130.revip3.asianet.co.th; Message-ID: <53FC5327.1080909@bouncycastle.org> Date: Tue, 26 Aug 2014 16:28:07 +0700 From: Peter Dettman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140822134712.18593.56531.idtracker@ietfa.amsl.com> In-Reply-To: <20140822134712.18593.56531.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: http://mailarchive.ietf.org/arch/msg/tls/08q6f_IDBJ3OswA1PHz49MEybXg Subject: Re: [TLS] I-D Action: draft-ietf-tls-session-hash-01.txt 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, 26 Aug 2014 09:28:15 -0000 Thanks to the authors for their time and effort in preparing this draft. I spent some time today implementing it in the BouncyCastle TLS client/server, and have a few comments: 1. Initially I was focused on replacing the "seed" input to the PRF, and overlooked that the label ("extended master secret") had also changed. It might be worth adverting to that in the surrounding text. 2. Section 5.2 appears to make acceptance of the extension compulsory i.e. that the server MUST negotiate the extension. Is there a clause missing there (e.g. "... if it wishes to negotiate use of the extended master_secret derivation"), or is it really intended that the handshake must fail when the server doesn't implement this feature? 3. Also in 5.2, I have issues with the "Implementation note" regarding resumption. Existing RFCs say that a server choosing resumption should ignore client extensions and (MUST) not send any server extensions (RFC 5746 is already an exception to this, but do we want to add more exceptions?). Some server implementations do send them regardless, so in our client we just ignore those in favour of the resumed-session extensions. The rule described in this implementation note does not make the logic simpler; I would like to see this bit removed and just refer to the existing rules for resumption - don't send the extension. If anyone puts up a test server implementing this draft, please let me know. Pete Dettman On 22/08/2014 8:47 pm, 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 : Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension > Authors : Karthikeyan Bhargavan > Antoine Delignat-Lavaud > Alfredo Pironti > Adam Langley > Marsh Ray > Filename : draft-ietf-tls-session-hash-01.txt > Pages : 8 > Date : 2014-08-22 > > Abstract: > The Transport Layer Security (TLS) master secret is not > cryptographically bound to important session parameters such as the > client and server identities. Consequently, it is possible for an > active attacker to set up two sessions, one with a client and another > with a server, such that the master secrets on the two sessions are > the same. Thereafter, any mechanism that relies on the master secret > for authentication, including session resumption, becomes vulnerable > to a man-in-the-middle attack, where the attacker can simply forward > messages back and forth between the client and server. This > specification defines a TLS extension that contextually binds the > master secret to a log of the full handshake that computes it, thus > preventing such attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-session-hash/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-session-hash-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-session-hash-01 > > > 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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Aug 26 09:35:08 2014 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 4B5131A0024 for ; Tue, 26 Aug 2014 09:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 MisvivEq7Yka for ; Tue, 26 Aug 2014 09:35:04 -0700 (PDT) Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99C51A008F for ; Tue, 26 Aug 2014 09:35:03 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id bs8so4455636wib.14 for ; Tue, 26 Aug 2014 09:35:02 -0700 (PDT) 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 :content-type; bh=Fsc20FJCduYnucjWfnpoGdDGxqNeOb9l5d/EAU9Hr7E=; b=A35qzsGKHNdXG01YaFAOeFUU2r/duA38zfB6snEsSNQTAi0sCKxQVQfjpbLP8eO53Q NyiXICbB+LU9VP8SA7HBNNg1f5GQOk0/0z15ab8OquS+ThFNsyGcAckC4u/7/p+l08pZ e1IrXX6x7VyafhSUxcQpQC9Ow9po5riClqfxOXU595Pz4Y1b5XjL7eryokE0wpuXeUxS xuQMQDNeG9KEOKJDSOdihcs5ZFZ02iKmv8mB+a4+3ub5nY9c+hFxil3w6MqqTDYS9jBX FQd/2TU5H3Fla6kKKTrt70bTXYNrLzxl9YCuhu8L7Ykvk3BVYxokF1hmzQKMMXiDNuk5 10fQ== X-Gm-Message-State: ALoCoQmXAaMXpM51dSY/coXtfKU6cgtYlfPcmCB6fFDeIbEICidWrZQ1NKkFX9tqQkbc0qt+pqnY X-Received: by 10.194.184.166 with SMTP id ev6mr28764816wjc.61.1409070902418; Tue, 26 Aug 2014 09:35:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Tue, 26 Aug 2014 09:34:22 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:3db6:9d98:127c:1263] From: Eric Rescorla Date: Tue, 26 Aug 2014 09:34:22 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bae49329a29eb05018ae261 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Isu2eNaIdk62GE3JX7zi_V9HmEo Subject: [TLS] Pull request: Remove length from AEAD Ciphers 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, 26 Aug 2014 16:35:06 -0000 --047d7bae49329a29eb05018ae261 Content-Type: text/plain; charset=UTF-8 Per discussion in Toronto. Fixes: https://github.com/tlswg/tls13-spec/issues/67 https://github.com/tlswg/tls13-spec/issues/47 https://github.com/tlswg/tls13-spec/pull/77 Target merge date: 8/28. Please comment here or on github if you see issues. -Ekr --047d7bae49329a29eb05018ae261 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Per discussion in Toronto. Fixes:

Please comment here or= on github if you see issues.

-Ekr


--047d7bae49329a29eb05018ae261-- From nobody Tue Aug 26 09:57:51 2014 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 877981A00C5 for ; Tue, 26 Aug 2014 09:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 Qi4liaVl0LPz for ; Tue, 26 Aug 2014 09:57:47 -0700 (PDT) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B381A8769 for ; Tue, 26 Aug 2014 09:57:33 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so4542170wiw.12 for ; Tue, 26 Aug 2014 09:57:31 -0700 (PDT) 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 :content-type; bh=u605Uj+0sNYl7iWWaDmtTszb6keSxe/YlXEe3I7zEoY=; b=LsvJAkqvl6GvmrrHIPbKEdCNd1jZT20TYTszW2R3mqKirAopDtQk6REmeBW27FuAGP og27Lv8JxOTQfIpaKr1EkKcUn1X+AFbas2Bf1xuTxAwPhhi+ktFETLmy1FwQNXEQWTGJ bXRXevS9ZpooV3jH22ctJ65Ida5wiQp9hieHpnSF9D1srESOz5QmjNCzhyCplhi0H5K9 tu4vgTZQp8nx/U6UfSnjINV5EmfKsGw61R/ecFgKqAY7WJ/+Mg7Xy3+WXiBDcTZ9sjQV hJPP8ZTTATC+ZxdLhClzqv/JPl9M1h0TsYeGcdK86b1hEfO5sDnEwzBMwS2tMDByKs79 UVVA== X-Gm-Message-State: ALoCoQmqrkNeY6BDnxdhZVu4nle8tYwOj02obbFKA6VxBpX8S0RNIxHur/rDgS3RUs5HeAxVcc7s X-Received: by 10.180.104.7 with SMTP id ga7mr22754583wib.36.1409072251202; Tue, 26 Aug 2014 09:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Tue, 26 Aug 2014 09:56:51 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:3db6:9d98:127c:1263] From: Eric Rescorla Date: Tue, 26 Aug 2014 09:56:51 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04427186ff350005018b3216 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W1IlYbuT7oTvQ89o1mcZ-iAF9Aw Subject: [TLS] Should we allow GMT in ServerRandom? 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, 26 Aug 2014 16:57:48 -0000 --f46d04427186ff350005018b3216 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/issues/64 Per WG consensus, we have removed the GMT field from ClientRandom and ServerRandom but we still have the following text in TLS 1.3: Note: Versions of TLS prior to TLS 1.3 used the top 32 bits of the Random value to encode the time since the UNIX epoch. TLS 1.3 Server implementations MAY opt to include the time in their Server.random values in order to accomodate clients which use that field for time synchronization. There's no obvious way for a client to know if this is true or not and people have suggested removing this text entirely see, for instance: http://www.ietf.org/mail-archive/web/tls/current/msg13140.html) Does anyone want to argue in favor of retaining this? -Ekr --f46d04427186ff350005018b3216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= https://github.com/tlswg/tls13-spec/issues/64

Pe= r WG consensus, we have removed the GMT field from ClientRandom
a= nd ServerRandom but we still have the following text in TLS 1.3:

=C2=A0 =C2=A0Note: Versions of TLS prior to TLS 1.= 3 used the top 32 bits of
=C2=A0 =C2=A0the Random value to encode= the time since the UNIX epoch. TLS 1.3
=C2=A0 =C2=A0Server imple= mentations MAY opt to include the time in their
=C2=A0 =C2=A0Server.random values in order to accomodate clients which= use
=C2=A0 =C2=A0that field for time synchronization.
=
There's no obvious way for a client to know if thi= s is true or not and
people have suggested removing this text entirely see, for instance:

Does anyone want to argue in favor of retaining t= his?

-Ekr


=
--f46d04427186ff350005018b3216-- From nobody Tue Aug 26 14:05:22 2014 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 309CE1A8846 for ; Tue, 26 Aug 2014 14:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, 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 9whNuqKJqThe for ; Tue, 26 Aug 2014 14:05:19 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1830E1A883D for ; Tue, 26 Aug 2014 14:05:19 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AB6F710224008; Tue, 26 Aug 2014 14:05:18 -0700 (PDT) Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 26 Aug 2014 14:05:18 -0700 (PDT) Message-ID: In-Reply-To: <20140820164500.GA26426@LK-Perkele-VII> References: <20140820164500.GA26426@LK-Perkele-VII> Date: Tue, 26 Aug 2014 14:05:18 -0700 (PDT) From: "Dan Harkins" To: "Ilari Liusvaara" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7z9wMHF8gr6Ml3JmJkvrE9le9AU Cc: tls mailing list Subject: Re: [TLS] Problems with TLS 1.3 handshake protocol 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, 26 Aug 2014 21:05:20 -0000 Hello, On Wed, August 20, 2014 9:45 am, Ilari Liusvaara wrote: [snip] > 6) Problems with SRP: > --------------------- > > SRP in general needs ServerKeyExchange before ClientKeyExchange. > Now, if client is able to guess the exchange group, the order > of those two can be inverted. > > Also, the key exchange messages have their own format. > > Some additional issues: > - The key shares are relatively large (multiplicative group!) > - The key shares are relatively slow to generate (ditto) > - The usual SRP groups do not match named groups. > > There is no straightforward way to make ECC SRP. All of these issues are addressed by draft-ietf-tls-pwd-- it can use ECC, supports named groups, and can have key shares that are smaller and faster to generate. > Also, SRP is seemingly pretty much unused in context of TLS. > > Proposal: Does this need to be supported? The overwhelming majority of use of TLS is browser based and there really isn't a compelling use for SRP (or any similar kind of password-authenticated key exchange) in a browser but there is in other uses of TLS, notably EST (RFC 7030). EST requires maintenance of a trust anchor database so you need a certificate to get a certificate. By using a TLS cipher suite that does not require a certificate, like TLS-pwd, this problem is mitigated. It's much easier to use an app that implements EST and it's much less likely that such an app would be misconfigured. For this reason alone I think such a cipher suite needs to be supported. regards, Dan. From nobody Wed Aug 27 00:27:06 2014 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 56A5C1A045C; Wed, 27 Aug 2014 00:27:04 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vkioSimmPeex; Wed, 27 Aug 2014 00:27:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD7C1A0450; Wed, 27 Aug 2014 00:27:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140827072703.17771.93063.idtracker@ietfa.amsl.com> Date: Wed, 27 Aug 2014 00:27:03 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8OwUXKHfvSW-TrT91ULkiZhwvrg Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list 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, 27 Aug 2014 07:27:04 -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 Working Group of the IETF. Title : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS Author : Daniel Kahn Gillmor Filename : draft-ietf-tls-negotiated-ff-dhe-01.txt Pages : 22 Date : 2014-08-27 Abstract: Traditional finite-field-based Diffie-Hellman (DH) key exchange during the TLS handshake suffers from a number of security, interoperability, and efficiency shortcomings. These shortcomings arise from lack of clarity about which DH group parameters TLS servers should offer and clients should accept. This document offers a solution to these shortcomings for compatible peers by establishing a registry of DH parameters with known structure and a mechanism for peers to indicate support for these groups. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-01 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 Wed Aug 27 01:26:59 2014 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 8C5901A049E for ; Wed, 27 Aug 2014 01:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 gMvtAv_Z9eET for ; Wed, 27 Aug 2014 01:26:56 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7411A046D for ; Wed, 27 Aug 2014 01:26:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-27-55-237-111.revip3.asianet.co.th; Message-ID: <53FD9647.3090101@bouncycastle.org> Date: Wed, 27 Aug 2014 15:26:47 +0700 From: Peter Dettman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140827072703.17771.93063.idtracker@ietfa.amsl.com> In-Reply-To: <20140827072703.17771.93063.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-xL0GLDGWjij_a7QtAEo27HWIy0 Subject: Re: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-01.txt 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, 27 Aug 2014 08:26:57 -0000 Is the ExtensionType entry to be "negotiated_ff_dhe_groups" or "negotiated_dh_group"? Both are used in different sections of the draft. On 27/08/2014 2:27 pm, 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 : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS > Author : Daniel Kahn Gillmor > Filename : draft-ietf-tls-negotiated-ff-dhe-01.txt > Pages : 22 > Date : 2014-08-27 > > Abstract: > Traditional finite-field-based Diffie-Hellman (DH) key exchange > during the TLS handshake suffers from a number of security, > interoperability, and efficiency shortcomings. These shortcomings > arise from lack of clarity about which DH group parameters TLS > servers should offer and clients should accept. This document offers > a solution to these shortcomings for compatible peers by establishing > a registry of DH parameters with known structure and a mechanism for > peers to indicate support for these groups. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-01 > > > 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/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Aug 27 04:11:11 2014 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 669331A0640 for ; Wed, 27 Aug 2014 04:11:09 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3H7K8lWZhiY for ; Wed, 27 Aug 2014 04:11:07 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CA781A05F5 for ; Wed, 27 Aug 2014 04:11:06 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so5625159wib.14 for ; Wed, 27 Aug 2014 04:11:03 -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:content-type; bh=ITiBzw900n8cosTOtIU5ACC+kh1ecL9eTYbM0Yf5zrY=; b=B3n+PYi+71OFHJKrma3dh5eT0MX833gTB8gNBx3fAQN82Wp/I2aD5iR8sPikkdwUgZ 1wmQWESXowF6G6ZLLFS9futxVdqAH5kEdrgWoKTTiS6mhPwl7nYD+fxsPkMU4fh74QcU sYSfCq/fGB8sZasY5/T4xUDHYulWo+HCDhHQTlI61xTFRulLbQMd5mUB5sRmccYFbFH0 OOdCxUhpHRCIr9C/QjFv6Vldlk0/rHwailYjTNFXDDdhWojyiOnhGHoDgjNkt3Ng2Nap him3bPd6pnkYR74IeUgg1nRF8mRBTey9041x+pBay758sChyIRsdg2ai4KXL9rXThPx0 TTGw== MIME-Version: 1.0 X-Received: by 10.194.63.205 with SMTP id i13mr22549103wjs.74.1409137863039; Wed, 27 Aug 2014 04:11:03 -0700 (PDT) Received: by 10.194.137.67 with HTTP; Wed, 27 Aug 2014 04:11:03 -0700 (PDT) Date: Wed, 27 Aug 2014 13:11:03 +0200 Message-ID: From: Daniel Migault To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7ba97a80c423ba05019a79ae Archived-At: http://mailarchive.ietf.org/arch/msg/tls/K-0us0X_1vCgV6HczdehU306NfY Subject: [TLS] IV generation 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, 27 Aug 2014 11:11:09 -0000 --047d7ba97a80c423ba05019a79ae Content-Type: text/plain; charset=UTF-8 Hi, draft-stjohns-tls-tls13-crypto-infra-00 [1] provides TLS crypto construction. I found the document interesting and well written, so thank you for doing so. However, I have a question related to the IV generation, and I would be happy to get some feed backs. In section 4.4 it recommends to generate the IV as follows: """ iv_data = PRDG ("clientAndServerIV", context, 2* SecurityParameters.fixed_iv_length * 8); Then, iv_data is partitioned as follows: client_write_IV[SecurityParameters.fixed_iv_length]; server_write_IV[SecurityParameters.fixed_iv_length]; """ I am considering assymetric connectivity where one peer sends all the data, whereas the other only receives. (In my use case I use IPsec.) In this case, this scheme seems to present the following drawbacks: 1) It seems unnecessary to generate the receivers' IVs. 2) More over it seems like a potential attack vector for memory/CPU exhaustion. If I suppose IVs are used in the order they are generated, then the receiver uses rIV[1], while the sender uses sIV[1]...., sIV[N]. If the receiver is likely to use rIV2 at the end of the download, then the sender needs to keep the values of r[IV[2], ..., rIV[N], or to re-compute them when used by the receiver. 3) rIV and sIV may be seen as to distinct function, and thus use different keys. As a result, it seems preferable to use something like 1) generating a server_iv_key and a client_iv_key 2) using that key to generate client_iv and server_iv separately. ## this would be a key derive from the master for example key_iv_client_server = KDF( key_iv, "clientAndServerIV", context, 2 * SecurityParameters.fixed_iv_length * 8) ## the iv key is used to derive the two subkeys key_iv_client = key_iv_client_server[:SecurityParameters.fixed_iv_length] key_iv_server = key_iv_client_server[SecurityParameters.fixed_iv_length:] client_iv = KDF(key_iv_client, "clientIV", context, SecurityParameters.fixed_iv_length * 8) server_iv = KDF(key_iv_server, "clientIV", context, SecurityParameters.fixed_iv_length * 8) This would be an alternative, but maybe it might be easier to use PRDG instead of KDF and using key_iv_client (resp. key_iv_client) as context. Both keys may also directly derived from the master. [1] http://trac.tools.ietf.org/id/draft-stjohns-tls-tls13-crypto-infra-00.txt -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7ba97a80c423ba05019a79ae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

dra= ft-stjohns-tls-tls13-crypto-infra-00 [1] provides TLS crypto construction. = I found the document interesting and well written, so thank you for doing s= o.

However, I have a question related to the IV=C2=A0 generation, and I wo= uld be happy to get some feed backs. In section 4.4 it recommends to genera= te the IV as follows:

"""
=C2=A0iv_data =3D PRDG ("clientAndServerIV&q= uot;, context,
=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 2* SecurityParameters.f= ixed_iv_length * 8);

=C2=A0=C2=A0 Then, iv_data is partitioned as fo= llows:

=C2=A0=C2=A0 client_write_IV[SecurityParameters.fixed_iv_leng= th];
=C2=A0=C2=A0 server_write_IV[SecurityParameters.fixed_iv_length];
"= ""

I am considering assymetric connectivity where one peer= sends all the data, whereas the other only receives. (In my use case I use= IPsec.)

In this case, this scheme seems to present the following drawbacks:
= =C2=A0=C2=A0=C2=A0 1) It seems unnecessary to generate the receivers' I= Vs.
=C2=A0=C2=A0=C2=A0 2) More over it seems like a potential attack vec= tor for memory/CPU exhaustion. If I suppose IVs are used in the order they = are generated, then the receiver uses rIV[1], while the sender uses sIV[1].= ..., sIV[N]. If the receiver is likely to use rIV2 at the end of the downlo= ad, then the sender needs to keep the values of r[IV[2], ..., rIV[N], or to= re-compute them when used by the receiver.
=C2=A0=C2=A0=C2=A0 3) rIV and sIV may be seen as to distinct function, and = thus use different keys.

As a result, it seems preferable to use som= ething like 1) generating a server_iv_key and a client_iv_key 2) using that= key to generate client_iv and server_iv separately.
## this would be a key derive from the master for example
key_iv_client_= server =3D KDF( key_iv, "clientAndServerIV", context, 2 * Securit= yParameters.fixed_iv_length * 8)

## the iv key is used to derive the= two subkeys
key_iv_client =3D key_iv_client_server[:SecurityParameters.fixed_iv_length]=
key_iv_server =3D key_iv_client_server[SecurityParameters.fixed_iv_leng= th:]
client_iv =3D KDF(key_iv_client, "clientIV", context,
SecurityParameters.fixed_iv_length * 8)

server_iv =3D KDF(key_iv_ser= ver, "clientIV", context,

SecurityParameters.fixed_iv_len= gth * 8)


This would be an alternative, but maybe it might be eas= ier to use PRDG instead of KDF and using key_iv_client (resp. key_iv_client= ) as context. Both keys may also directly derived from the master.

=C2=A0
[1] http://trac.tools.ietf.org/i= d/draft-stjohns-tls-tls13-crypto-infra-00.txt




--
Daniel Migault
Orange Labs -- Sec= urity
+33 6 70 72 69 58
--047d7ba97a80c423ba05019a79ae-- From nobody Wed Aug 27 04:38:54 2014 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 21A5A1A0646 for ; Wed, 27 Aug 2014 04:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 7CBisrXKB7Xf for ; Wed, 27 Aug 2014 04:38:51 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 5605E1A0645 for ; Wed, 27 Aug 2014 04: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 (8.14.4/8.14.4) with ESMTP id s7RBcoLg018921 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 27 Aug 2014 07:38:50 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7RBcmK4004337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 27 Aug 2014 07:38:49 -0400 Message-ID: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Wed, 27 Aug 2014 13:38:47 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3Lf_fQkZQ4KFGAViSWCRvBVGWmc Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 27 Aug 2014 11:38:53 -0000 On Tue, 2014-08-26 at 09:34 -0700, Eric Rescorla wrote: > Per discussion in Toronto. Fixes: > https://github.com/tlswg/tls13-spec/issues/67 > https://github.com/tlswg/tls13-spec/issues/47 > > > https://github.com/tlswg/tls13-spec/pull/77 If it is merged as is there will be two types of AEAD ciphersuites. The pre-TLS 1.3 and the post TLS 1.3. From the post-TLS 1.3 the ones that require padding wouldn't work with pre-TLS 1.3 while the others would. So let's suppose we have TLS_AEAD_AES_128_CBC_SHA1 defined sometime after TLS 1.3 is published. What would a TLS 1.2 implementation do if faced with this ciphersuite? Should it implement it using the TLS 1.3 semantics, or it shouldn't implement it at all? What if two implementations make a different choice in that dilema? The whole AEAD ciphersuite handling is becoming quite complex. The rules seem to be: - ciphersuites defined using the original AEAD: only after TLS 1.2 - ciphersuites defined after TLS 1.3: if the ciphersuite requires padding only after TLS 1.3, otherwise only after TLS 1.2. There is space for quite some bugs there, and quite some improvisation for implementors that would like to have the new AEAD format in old versions. The text should at least mention what is the intention for that. I think the simplest way to solve the ambiguities, would be to have an extension that would enable the new AEAD format, rather than rely on the TLS 1.3 version. That way negotiation would be straightforward; if the extension is present the new AEAD format will be used regardless the TLS version. regards, Nikos From nobody Wed Aug 27 04:59:43 2014 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 238461A065B for ; Wed, 27 Aug 2014 04:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 8egQha9h49C3 for ; Wed, 27 Aug 2014 04:59:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 822C41A0494 for ; Wed, 27 Aug 2014 04:59:39 -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 (8.14.4/8.14.4) with ESMTP id s7RBxclZ020766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 27 Aug 2014 07:59:38 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7RBxbFv021459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 27 Aug 2014 07:59:38 -0400 Message-ID: <1409140776.25920.30.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Wed, 27 Aug 2014 13:59:36 +0200 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/75Y80h0wY7Vo_-i5JGkG4D-KsDw Subject: [TLS] a TLS server cannot be used in a use-case that requires privilege separation 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, 27 Aug 2014 11:59:41 -0000 While trying to implement the privilege separation paradigm in various TLS servers, I've come to a limitation of the TLS protocol. Unlike SSH, a TLS server cannot use privilege separation to perform authentication of the client. That is if we have: ---------------- ------------- |authentication| | TLS server| | server | | | ---------------- ------------- there is no way for the authentication server to authenticate a user connecting to the TLS server, without having the authentication server perform the whole TLS handshake. The latter of course defeats the purpose of privilege separation. Why is that? The reason is that unlike ServerKeyExchange the client's CertificateVerify message is defined as: struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } CertificateVerify; meaning that the signature covers all the exchanged messages, and has no field that can be set by the authentication server directly. Note that in ServerKeyExchange the authentication server could have set a part or the whole server_random[] and he could have used that as a proof that the signature is on the current session. There can be very expensive work-arounds, but are of significant complexity for the authentication server, that again defeat the purpose of privilege separation. I believe it is a nice goal to set for a future revision of TLS, to have the CertificateVerify message modified to have the same properties as the ServerKeyExchange message. That is, to have an additional fixed field that is set by the server. regards, Nikos From nobody Wed Aug 27 08:05:26 2014 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 4F00D1A0AD4 for ; Wed, 27 Aug 2014 08:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 ggNTkeMX251L for ; Wed, 27 Aug 2014 08:05:18 -0700 (PDT) Received: from emh02.mail.saunalahti.fi (emh02.mail.saunalahti.fi [62.142.5.108]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC7D1A0AD6 for ; Wed, 27 Aug 2014 08:05:17 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh02.mail.saunalahti.fi (Postfix) with ESMTP id EFFA8817E7; Wed, 27 Aug 2014 18:05:14 +0300 (EEST) Date: Wed, 27 Aug 2014 18:05:14 +0300 From: Ilari Liusvaara To: Nikos Mavrogiannopoulos Message-ID: <20140827150514.GA9874@LK-Perkele-VII> References: <1409140776.25920.30.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1409140776.25920.30.camel@dhcp-2-127.brq.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pdMYXQ1-bB_bvoHR_HNWn6CF_b4 Cc: "tls@ietf.org" Subject: Re: [TLS] a TLS server cannot be used in a use-case that requires privilege separation 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, 27 Aug 2014 15:05:24 -0000 On Wed, Aug 27, 2014 at 01:59:36PM +0200, Nikos Mavrogiannopoulos wrote: > Why is that? The reason is that unlike ServerKeyExchange the client's > CertificateVerify message is defined as: > struct { > digitally-signed struct { > opaque handshake_messages[handshake_messages_length]; > } > } CertificateVerify; > > meaning that the signature covers all the exchanged messages, and has no > field that can be set by the authentication server directly. Note that > in ServerKeyExchange the authentication server could have set a part or > the whole server_random[] and he could have used that as a proof that > the signature is on the current session. There can be very expensive > work-arounds, but are of significant complexity for the authentication > server, that again defeat the purpose of privilege separation. I have thought a bit of this (in context of "certificate attach", which would be one of the two replacements for removed renegotiation, the other being rekeying). The basic idea is to derive a subkey from master secret that is then used to prove certificate verification signatures are fresh[1]. Considering the order TLS 1.3 key exchange runs, the connection master keys are known by the point either endpoint attempts to send certificates or certificate verification messages (they have to be, the messages are supposedly encrypted!). > I believe it is a nice goal to set for a future revision of TLS, to have > the CertificateVerify message modified to have the same properties as > the ServerKeyExchange message. That is, to have an additional fixed > field that is set by the server. It can't be set by the server, since that leads to security holes. It has to be set by both client and server in collision-resistant manner. [1] Recomendations to avoid attacks: - MAC the messages (being inside TLS channel implicitly does so). - Include public keys (or hashes thereof) into TBS data. - Include sequence number in TBS data. - Include endpoint role (client/server) into TBS data. -Ilari From nobody Wed Aug 27 08:15:42 2014 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 1ACE41A0AD2 for ; Wed, 27 Aug 2014 08:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 hMtYCldCVs_L for ; Wed, 27 Aug 2014 08:15:37 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE99E1A0970 for ; Wed, 27 Aug 2014 08:15:36 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id k14so374596wgh.8 for ; Wed, 27 Aug 2014 08:15:33 -0700 (PDT) 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-type; bh=UTIEOVDe2jC4X1QRmII2SEXSIh/B/o+PS2h45VDgqwM=; b=moypsymWFrURw5qhFhP9n20YkKCHkFgm9BKUGa3DPZvtv7f9vJM47m48nt/Ec+rY0G stCcI1TEBNKAaBWylkRHIU3MscuecKo37ZagGic9TH5zRfGml4kepwe5WQU8vk67RYLY 7DUDlRYodoG8Mr3GLX+J4SxQJUWhljqBmssMBI1/0wuoCgE5UmtbNGkmR45XN4bjqd6h qaAz4bzS4if/GAKwCdmmf2B39XrtcVgvlhDb5E0KxsUcXuhovwcj04OitI4gOsE3h0ng SWvFttqL1SQseDQuk1Z2n9vX6vwrSUyK20EIaVFMb7HEPPuYEJqub6ZFKm+tVYZccxfI Bq/g== X-Gm-Message-State: ALoCoQkpaEbyCKBvJZZBexDezST3awWl9OgH8+P70jEAidhrZcBekMycoSZasXDjCx1YAGmuoRmu X-Received: by 10.181.8.70 with SMTP id di6mr29083900wid.78.1409152532965; Wed, 27 Aug 2014 08:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 27 Aug 2014 08:14:52 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Wed, 27 Aug 2014 08:14:52 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1134d61c297d2a05019de459 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/j1T9LW_0ePx_cnV_s3MeAKTlVJE Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 27 Aug 2014 15:15:39 -0000 --001a1134d61c297d2a05019de459 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 27, 2014 at 4:38 AM, Nikos Mavrogiannopoulos wrote: > On Tue, 2014-08-26 at 09:34 -0700, Eric Rescorla wrote: > > Per discussion in Toronto. Fixes: > > https://github.com/tlswg/tls13-spec/issues/67 > > https://github.com/tlswg/tls13-spec/issues/47 > > > > > > https://github.com/tlswg/tls13-spec/pull/77 > > If it is merged as is there will be two types of AEAD ciphersuites. The > pre-TLS 1.3 and the post TLS 1.3. Yes, and they will use the same code points. This is already true with, for instance, the IV between version 1.0 and 1.1 and the version field between SSLv3 and TLS 1.0 So let's suppose we have TLS_AEAD_AES_128_CBC_SHA1 defined sometime > after TLS 1.3 is published. What would a TLS 1.2 implementation do if > faced with this ciphersuite? Should it implement it using the TLS 1.3 > semantics, or it shouldn't implement it at all? What if two > implementations make a different choice in that dilema? The whole AEAD > ciphersuite handling is becoming quite complex. > Sure. I would suggest we address this problem if/when someone actually defines such a cipher suite, which can either update RFC 5246 appropriately or say "do not use in TLS 1.2". > There is space for quite some bugs there, and quite some improvisation > for implementors that would like to have the new AEAD format in old > versions. The text should at least mention what is the intention for > that. > I'm happy to do that. I think the simplest way to solve the ambiguities, would be to have an > extension that would enable the new AEAD format, rather than rely on the > TLS 1.3 version. That way negotiation would be straightforward; if the > extension is present the new AEAD format will be used regardless the TLS > version. > I would prefer not to do this. One advantage of having a new version number is not having a bunch of extension-optional behavior when you really only want one. Best, -Ekr --001a1134d61c297d2a05019de459 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Wed, Aug 27, 2014 at 4:38 AM, Nikos Mavrogiannopoulos <nmav@redh= at.com> wrote:
On Tue, 2014-08-26 at 09:34 = -0700, Eric Rescorla wrote:
> Per discussion in Toronto. Fixes:
> https://github.com/tlswg/tls13-spec/issues/67
> https://github.com/tlswg/tls13-spec/issues/47
>
>
> https://github.com/tlswg/tls13-spec/pull/77

If it is merged as is there will be two types of AEAD ciphersuites. T= he
pre-TLS 1.3 and the post TLS 1.3.

Yes, and = they will use the same code points. This is already true with,
fo= r instance, the IV between version 1.0 and 1.1 and the version
field between SSLv3 and TLS 1.0


So let's suppose we have TLS_AEAD_AES_128_CBC_SHA1 defined sometime
after TLS 1.3 is published. What would a TLS 1.2 implementation do if
faced with this ciphersuite? Should it implement it using the TLS 1.3
semantics, or it shouldn't implement it at all? What if two
implementations make a different choice in that dilema? The whole AEAD
ciphersuite handling is becoming quite complex.

Sure. I would suggest we address this problem if/when someone
actually defines such a cipher suite, which can either update
RFC 5246 appropriately or say "do not use in TLS 1.2".=C2=A0=


There is space for quite some bugs there, and quite some improvisation
for implementors that would like to have the new AEAD format in old
versions. The text should at least mention what is the intention for
that.

I'm happy to do that.


I think the simplest way to solve the ambiguities, would be to have an
extension that would enable the new AEAD format, rather than rely on the TLS 1.3 version. That way negotiation would be straightforward; if the
extension is present the new AEAD format will be used regardless the TLS version.

I would prefer not to do this.= One advantage of having a new version number is
not having a bun= ch of extension-optional behavior when you really only
want one.<= /div>

Best,
-Ekr



--001a1134d61c297d2a05019de459-- From nobody Wed Aug 27 08:20:26 2014 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 9657C1A0970 for ; Wed, 27 Aug 2014 08:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=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 glhCCeNu981S for ; Wed, 27 Aug 2014 08:20:17 -0700 (PDT) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1121A0936 for ; Wed, 27 Aug 2014 08:20:16 -0700 (PDT) Received: by mail-yh0-f54.google.com with SMTP id v1so345270yhn.13 for ; Wed, 27 Aug 2014 08:20:16 -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-type; bh=sWCvTc2ulYzwxvUS/SUBy1dpKJ046EuhVa1CrJSU/kg=; b=mENOimjnzAb3X9fhHX9gYgiRCwwvcbBlrHUqfzOX7ev4MEESXU1cewuWX2AE3gZg7d URh79g96OgHEsvu+5ENde9g3QL3pP0ANKjZNrsfBASlOeIqNS+yHkLMthq062pthgUMn o5R7eqKQ5no4VRpaTlzqzo8RwZ+8uOBUXNcINoYQ0gpceOVQwgHSDggQpimLKm+MA6+6 krJScbANXhkNmgsSAdes5guK7leZhx4Fj4cuCJjdxrn9HnnWCSZaAesziJfpzsf+2eYA tEjSJ/nkephtwPVfQxWoH1B3PH2cpaTSfUilmJ3RtOu3em7tRNYV76JtYX8szxIeRRd2 LgDQ== MIME-Version: 1.0 X-Received: by 10.236.147.202 with SMTP id t50mr2082541yhj.163.1409152816303; Wed, 27 Aug 2014 08:20:16 -0700 (PDT) Received: by 10.170.202.2 with HTTP; Wed, 27 Aug 2014 08:20:16 -0700 (PDT) In-Reply-To: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> Date: Wed, 27 Aug 2014 08:20:16 -0700 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wpdfoVKhFjObYlzdU-m7KP3zc8Y Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 27 Aug 2014 15:20:18 -0000 What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just fine: we don't need variable expansion as it doesn't give us more, so why support it? Sincerely, Watson Ladd From nobody Wed Aug 27 08:29:47 2014 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 780621A0AE3 for ; Wed, 27 Aug 2014 08:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 gpNdLA9uast7 for ; Wed, 27 Aug 2014 08:29:45 -0700 (PDT) Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 998321A0ACA for ; Wed, 27 Aug 2014 08:29:45 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id x12so393196wgg.4 for ; Wed, 27 Aug 2014 08:29:44 -0700 (PDT) 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-type; bh=K7H6uTwgldwfR/pygoIQMhHvc8Kj1JV0HvaIBaTJmYA=; b=IzPAE5hUww5N8/aQtx31vlSHvdXJ4K/tgmkvAiRZ9gIduUK/3r5L54D0CY6g8HEWk2 2B+9uV1/nDprPwzGI8/B/jlkMTkqgys6zxYlGCm28kHpVDMTLq+EJkAAh8dh2zBsT5qU xPtpFrEIwPPKWoZlNnDRfr474mOuLt4IpG6MBug+ELtx0C7Jt3dd44PkuD51MToXDHnn QBlT4EZE/JTAAY4Y3LQ9zzDgksc9dIUCG/v0uvw/ei7FBXDFoQSKUi0mOx2RQ4bTFuBo 3XTewEHAFfrY1j2d0Erx6aNak66EiFnWOdl4kQheoEgHxMdJwbKNYJGsWdiCwH4+hfO6 LxXA== X-Gm-Message-State: ALoCoQkKByPAP284kVTiyj95jAs2SCSCVNkiAXDzvrI0nOjF15/wUW6AqXnIE43Y+Fc4N1hm6/i6 X-Received: by 10.194.119.41 with SMTP id kr9mr4025759wjb.114.1409153384236; Wed, 27 Aug 2014 08:29:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Wed, 27 Aug 2014 08:29:04 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Wed, 27 Aug 2014 08:29:04 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=089e012297c0e6e0cf05019e160d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/plb5hFlI2U9BUZtjmHy-RcGFn0Q Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 27 Aug 2014 15:29:46 -0000 --089e012297c0e6e0cf05019e160d Content-Type: text/plain; charset=UTF-8 On Wed, Aug 27, 2014 at 8:20 AM, Watson Ladd wrote: > > What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just > fine: we don't need variable expansion as it doesn't give us > more, so why support it? > I would look at this differently: we don't know in advance that variable expansion won't ever give us anything useful, and having the length is an impediment to ever adding them. This certainly doesn't preclude you arguing against someone defining a CBC+HMAC AEAD suite (and I do imagine someone will want to do so.) -Ekr --089e012297c0e6e0cf05019e160d Content-Type: text/html; charset=UTF-8
On Wed, Aug 27, 2014 at 8:20 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
<snip>
What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just
fine: we don't need variable expansion as it doesn't give us
more, so why support it?

I would look at this differently: we don't know in advance that variable
expansion won't ever give us anything useful, and having the length
is an impediment to ever adding them. This certainly doesn't preclude
you arguing against someone defining a CBC+HMAC AEAD suite
(and I do imagine someone will want to do so.)

-Ekr

--089e012297c0e6e0cf05019e160d-- From nobody Wed Aug 27 08:29:56 2014 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 5CBF71A0AEC for ; Wed, 27 Aug 2014 08:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=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 wuI-dErl1iWJ for ; Wed, 27 Aug 2014 08:29:49 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 754531A0AEB for ; Wed, 27 Aug 2014 08:29:49 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s7RFTM0j023139; Wed, 27 Aug 2014 11:29:47 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Blumenthal, Uri - 0558 - MITLL" In-Reply-To: Date: Wed, 27 Aug 2014 11:29:29 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> To: Watson Ladd X-Mailer: Apple Mail (2.1510) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-27_05:2014-08-27,2014-08-27,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408270178 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/umMota8WJwrw_NAb_swLvFwAX8M Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 27 Aug 2014 15:29:53 -0000 > What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just = fine: we don't need variable expansion as it doesn't give us more, so = why support it? Less disastrous consequence of (inadvertent) IV reuse for CBC? (Yes, your code would *never* do that, but there are other, less = skilled, programmers around. :-)= From nobody Wed Aug 27 11:51:09 2014 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 41E211A0154 for ; Wed, 27 Aug 2014 11:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 TM1hfBWzt0HM for ; Wed, 27 Aug 2014 11:50:56 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E100D1A0100 for ; Wed, 27 Aug 2014 11:50:55 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa1so925437pad.27 for ; Wed, 27 Aug 2014 11:50:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=VVnCgWVZPM/pHL0Yoa+t4T7RO/x3iWxlbM+zGCrn1ug=; b=g/wUNVVNU64Jps4LOhs0vLZRJNV+HVLtqw/ac1ir1x+lU4BjzUSSwGP6CNfS8M8hzL sEzXflAdl5ZXXuMUo/Gd/LIK5selJAE68hc4sLKdQq1hlY+2h4tNNP66nzpC8VIIcPan k9yi1zeVaKLjp2BGUCDdzQRioZdozC2/e94rDS298cZhSpfCmYzpp0zAZyYcshfqOT+v SJxu8hgncmQDH/sgi0z1Un2HmDNVy65QNbyzkXddC9YpxA9Pxs9f1F6S9swNsEqpM1gS 1bKzGv08kw4as2rAdl+6KG73jL8yso8XrSaEsCrv1yMo4008DUPoZ6USY74gPKMNwFux cSGQ== X-Gm-Message-State: ALoCoQmyQG92P42E/LlJECnndCaZc+WeSgvfQY36hijSTwkxwdnSASxlZBGZJx8zWMNoaD8PgbxI X-Received: by 10.67.29.227 with SMTP id jz3mr48019012pad.62.1409165454391; Wed, 27 Aug 2014 11:50:54 -0700 (PDT) Received: from [10.90.130.99] (soi.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id pv10sm1683164pdb.60.2014.08.27.11.50.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 11:50:53 -0700 (PDT) Message-ID: <53FE288F.9030105@nthpermutation.com> Date: Wed, 27 Aug 2014 14:50:55 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010609040508050607010404" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LNZ6Bl8O1L4c7TE76PnMaiXHYm4 Subject: Re: [TLS] IV generation 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, 27 Aug 2014 18:50:58 -0000 This is a multi-part message in MIME format. --------------010609040508050607010404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit See in line On 8/27/2014 7:11 AM, Daniel Migault wrote: > Hi, > > draft-stjohns-tls-tls13-crypto-infra-00 [1] provides TLS crypto > construction. I found the document interesting and well written, so > thank you for doing so. > > However, I have a question related to the IV generation, and I would > be happy to get some feed backs. In section 4.4 it recommends to > generate the IV as follows: > > """ > iv_data = PRDG ("clientAndServerIV", context, > 2* SecurityParameters.fixed_iv_length * 8); > > Then, iv_data is partitioned as follows: > > client_write_IV[SecurityParameters.fixed_iv_length]; > server_write_IV[SecurityParameters.fixed_iv_length]; > """ > > I am considering assymetric connectivity where one peer sends all the > data, whereas the other only receives. (In my use case I use IPsec.) > > In this case, this scheme seems to present the following drawbacks: > 1) It seems unnecessary to generate the receivers' IVs. > 2) More over it seems like a potential attack vector for > memory/CPU exhaustion. If I suppose IVs are used in the order they are > generated, then the receiver uses rIV[1], while the sender uses > sIV[1]...., sIV[N]. If the receiver is likely to use rIV2 at the end > of the download, then the sender needs to keep the values of r[IV[2], > ..., rIV[N], or to re-compute them when used by the receiver. > 3) rIV and sIV may be seen as to distinct function, and thus use > different keys. I didn't understand what you were getting at until this point. TLS uses the term "IV" in a way that isn't always consistent with cryptographic usage. If the TLS crypto is a stream crypto, then the IV really is an IV for the stream cipher: it's used when you initialize the stream cipher before sending the first record; the state of the stream cipher persists from record to record. If it's an AEAD cipher, its a nonce or the fixed part of a per-message IV; there's a new crypto context with each message each initialized with a unique IV. In the block cipher mode for say CBC it *was* the IV for the first message; second and subsequent messages took their IV from the last block of the previous message; that changed for TLS1.2. So for TLS there are only ever the two 'session' "IV's" even though there are many 'message' IVs built from the session IV. Note to self: figure out how to fix the language in the TLS document. [Longer winded discussion for the CCM AEAD mode: The TLS IV is used to provide part of the fixed part of a counter block. The per message nonce (see appendix A of SP800-38C) consists of the concatenation of the TLS generated IV (32 bits worth) and the message sequence number for a total of 96 bits. The counter part of the counter block is the 128 minus 96 right most bits initialized to 1 and counting up per message block. There are other variations, but they are all similar constructs] > > As a result, it seems preferable to use something like 1) generating a > server_iv_key and a client_iv_key 2) using that key to generate > client_iv and server_iv separately. > ## this would be a key derive from the master for example > key_iv_client_server = KDF( key_iv, "clientAndServerIV", context, 2 * > SecurityParameters.fixed_iv_length * 8) > > ## the iv key is used to derive the two subkeys > key_iv_client = key_iv_client_server[:SecurityParameters.fixed_iv_length] > key_iv_server = key_iv_client_server[SecurityParameters.fixed_iv_length:] > client_iv = KDF(key_iv_client, "clientIV", context, > > SecurityParameters.fixed_iv_length * 8) > > server_iv = KDF(key_iv_server, "clientIV", context, > > SecurityParameters.fixed_iv_length * 8) > > > This would be an alternative, but maybe it might be easier to use PRDG > instead of KDF and using key_iv_client (resp. key_iv_client) as > context. Both keys may also directly derived from the master. > > > [1] > http://trac.tools.ietf.org/id/draft-stjohns-tls-tls13-crypto-infra-00.txt > > > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------010609040508050607010404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
See in line

On 8/27/2014 7:11 AM, Daniel Migault wrote:
Hi,

draft-stjohns-tls-tls13-crypto-infra-00 [1] provides TLS crypto construction. I found the document interesting and well written, so thank you for doing so.

However, I have a question related to the IV  generation, and I would be happy to get some feed backs. In section 4.4 it recommends to generate the IV as follows:

"""
 iv_data = PRDG ("clientAndServerIV", context,
                   2* SecurityParameters.fixed_iv_length * 8);

   Then, iv_data is partitioned as follows:

   client_write_IV[SecurityParameters.fixed_iv_length];
   server_write_IV[SecurityParameters.fixed_iv_length];
"""

I am considering assymetric connectivity where one peer sends all the data, whereas the other only receives. (In my use case I use IPsec.)

In this case, this scheme seems to present the following drawbacks:
    1) It seems unnecessary to generate the receivers' IVs.
    2) More over it seems like a potential attack vector for memory/CPU exhaustion. If I suppose IVs are used in the order they are generated, then the receiver uses rIV[1], while the sender uses sIV[1]...., sIV[N]. If the receiver is likely to use rIV2 at the end of the download, then the sender needs to keep the values of r[IV[2], ..., rIV[N], or to re-compute them when used by the receiver.
    3) rIV and sIV may be seen as to distinct function, and thus use different keys.

I didn't understand what you were getting at until this point.  TLS uses the term "IV" in a way that isn't always consistent with cryptographic usage.  If the TLS crypto is a stream crypto, then the IV really is an IV for the stream cipher: it's used when you initialize the stream cipher before sending the first record; the state of the stream cipher persists from record to record.  If it's an AEAD cipher, its a nonce or the fixed part of a per-message IV; there's a new crypto context with each message each initialized with a unique IV.   In the block cipher mode for say CBC it *was* the IV for the first message; second and subsequent messages took their IV from the last block of the previous message; that changed for TLS1.2.

So for TLS there are only ever the two 'session' "IV's" even though there are many 'message' IVs built from the session IV.

Note to self: figure out how to fix the language in the TLS document. 

[Longer winded discussion for the CCM AEAD mode:  The TLS IV is used to provide part of the fixed part of a counter block.   The per message nonce (see appendix A of SP800-38C) consists of the concatenation of the TLS generated IV (32 bits worth) and the message sequence number for a total of 96 bits.  The counter part of the counter block is the 128 minus 96 right most bits initialized to 1 and counting up per message block.  There are other variations,  but they are all similar constructs]




As a result, it seems preferable to use something like 1) generating a server_iv_key and a client_iv_key 2) using that key to generate client_iv and server_iv separately.
## this would be a key derive from the master for example
key_iv_client_server = KDF( key_iv, "clientAndServerIV", context, 2 * SecurityParameters.fixed_iv_length * 8)

## the iv key is used to derive the two subkeys
key_iv_client = key_iv_client_server[:SecurityParameters.fixed_iv_length]
key_iv_server = key_iv_client_server[SecurityParameters.fixed_iv_length:]
client_iv = KDF(key_iv_client, "clientIV", context,

SecurityParameters.fixed_iv_length * 8)

server_iv = KDF(key_iv_server, "clientIV", context,

SecurityParameters.fixed_iv_length * 8)


This would be an alternative, but maybe it might be easier to use PRDG instead of KDF and using key_iv_client (resp. key_iv_client) as context. Both keys may also directly derived from the master.

 
[1] http://trac.tools.ietf.org/id/draft-stjohns-tls-tls13-crypto-infra-00.txt




--
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58 


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

--------------010609040508050607010404-- From nobody Wed Aug 27 14:11:36 2014 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 285461A02F0 for ; Wed, 27 Aug 2014 14:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.807 X-Spam-Level: ** X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 xueFlSb-ff-z for ; Wed, 27 Aug 2014 14:11:29 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.35.13]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2606B1A0294 for ; Wed, 27 Aug 2014 14:11:29 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 5E9177151EC72; Wed, 27 Aug 2014 16:11:28 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 42CAB7151EC1C for ; Wed, 27 Aug 2014 16:11:28 -0500 (CDT) Received: from [96.231.227.95] (port=58772 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMkV5-0005u2-EB; Wed, 27 Aug 2014 16:11:27 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Aug 2014 17:11:24 -0400 To: "TLS@ietf.org (tls@ietf.org)" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) 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.227.95 X-Exim-ID: 1XMkV5-0005u2-EB X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:58772 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DljMRfviZztPCIXQ00yzIJtlCcU Subject: [TLS] TLS interim planning fall 2014 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, 27 Aug 2014 21:11:35 -0000 We would like to get input on the preferred dates and locations of an = interim TLS meeting. The dates on offer are: October 1-2 October 2-3 in either Dublin or Paris or=20 October 20-21 October 21-22 in London, Dublin, or Paris. Please fill out the following doodle poll to indicate your preferences = by the end of Friday September 29th: http://doodle.com/6v3s6ve6zase766n Thanks, J&S= From nobody Wed Aug 27 15:04:29 2014 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 4CB591A0091 for ; Wed, 27 Aug 2014 15:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=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 2eOedTdG1C0b for ; Wed, 27 Aug 2014 15:04:27 -0700 (PDT) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C07A1A0081 for ; Wed, 27 Aug 2014 15:04:27 -0700 (PDT) Received: by mail-yk0-f176.google.com with SMTP id 19so23295ykq.21 for ; Wed, 27 Aug 2014 15:04:26 -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-type; bh=X6Gww5nlQ+9K34yGorm7cVTt1bCr8rOqyPjDZQE2xKQ=; b=zuaBxkII8P/g3Fwiy4tIIjlMnT7zaIHzMgHx9ZXInu4sLgyanN7ICLfEx9fGV8MJTz QZAxIplOAxW3t2EDcumD+wq414+E64g0HoPd2ZnZOW7m0LS9GzSglQwmBIlLt8y5NwTT atwNmpc0kjuMSD7ZHuHmAV0mSrH8GcvFWR/yd2KAQbjI9PKgFTI87R6W9euXt8RiW4jV sR0TZV7SmAettU7AvMKOx7SQAt1NHsNu49n6HKtStLtMg4hvGcPsQmlwxd/IaqGqmx93 sJ0qI+CdaGETw7Fy6X13piApUDYePzfM89MezVLiwNrStfFalycZMvGpC9PPLpDiB+qM OjiQ== MIME-Version: 1.0 X-Received: by 10.236.25.105 with SMTP id y69mr55142716yhy.33.1409177066694; Wed, 27 Aug 2014 15:04:26 -0700 (PDT) Received: by 10.170.202.2 with HTTP; Wed, 27 Aug 2014 15:04:26 -0700 (PDT) In-Reply-To: <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> Date: Wed, 27 Aug 2014 15:04:26 -0700 Message-ID: From: Watson Ladd To: "Blumenthal, Uri - 0558 - MITLL" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SxLT3YIrx9PFZwRDVZO-uzgBgp0 Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 27 Aug 2014 22:04:28 -0000 On Wed, Aug 27, 2014 at 8:29 AM, Blumenthal, Uri - 0558 - MITLL wrote: >> What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just fine: we don't need variable expansion as it doesn't give us more, so why support it? > > Less disastrous consequence of (inadvertent) IV reuse for CBC? Nonces don't repeat, IVs are random. Reuse isn't the issue for CBC, determinism is. TLS gets this wrong, badly, and repeatedly. > > (Yes, your code would *never* do that, but there are other, less skilled, programmers around. :-) Misuse-resistant AEAD schemes like SIV mode exist and do not have variable-length ciphertext expansion. Why do we need CBC+HMAC as an AEAD scheme? What problem is it solving that the existing ones don't? Furthermore, if we are willing to consider this change, why not changes to the Finished message to simplify the proof, or using a well-studied key agreement scheme? I don't understand the logic being applied: features are being put forward piecemeal, hindering debate and analysis, while large and well-known issues (like the complexity of implementations, which changes like the above don't help) aren't on the table because they could require changes to implementations. Sincerely, Watson Ladd From nobody Wed Aug 27 15:34:01 2014 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 9F9D71A0117 for ; Wed, 27 Aug 2014 15:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.006 X-Spam-Level: ** X-Spam-Status: No, score=2.006 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, 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 8s_QYmALzkUo for ; Wed, 27 Aug 2014 15:33:58 -0700 (PDT) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [67.18.22.86]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996981A00EB for ; Wed, 27 Aug 2014 15:33:58 -0700 (PDT) Received: by gateway12.websitewelcome.com (Postfix, from userid 5007) id CF0DCD866CFE1; Wed, 27 Aug 2014 17:33:57 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway12.websitewelcome.com (Postfix) with ESMTP id B91ACD866CFBA for ; Wed, 27 Aug 2014 17:33:57 -0500 (CDT) Received: from [96.231.227.95] (port=59076 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMlmp-0003xR-Kw for tls@ietf.org; Wed, 27 Aug 2014 17:33:56 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Wed, 27 Aug 2014 18:33:49 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <579BECAF-A412-4F1D-A53A-34FFA899B24D@ieca.com> References: To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) 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.227.95 X-Exim-ID: 1XMlmp-0003xR-Kw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:59076 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 9 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ILIuzg9yWwmQybho08bV8vhZaP4 Subject: Re: [TLS] TLS interim planning fall 2014 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, 27 Aug 2014 22:33:59 -0000 r/September 29th/August 29th. spt On Aug 27, 2014, at 17:11, Sean Turner wrote: > We would like to get input on the preferred dates and locations of an = interim TLS meeting. The dates on offer are: >=20 > October 1-2 > October 2-3 >=20 > in either Dublin or Paris >=20 > or=20 >=20 > October 20-21 > October 21-22 >=20 > in London, Dublin, or Paris. >=20 > Please fill out the following doodle poll to indicate your preferences = by the end of Friday September 29th: >=20 > http://doodle.com/6v3s6ve6zase766n >=20 > Thanks, >=20 > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Aug 27 19:18:36 2014 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 CCFB41A015F for ; Wed, 27 Aug 2014 19:18:33 -0700 (PDT) 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=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 BzCLTRff9qrk for ; Wed, 27 Aug 2014 19:18:32 -0700 (PDT) Received: from tauceti.org.au (mail.tauceti.org.au [203.32.61.25]) by ietfa.amsl.com (Postfix) with ESMTP id 81DBF1A0123 for ; Wed, 27 Aug 2014 19:18:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=ppp-27-55-212-217.revip3.asianet.co.th; Message-ID: <53FE9169.4010609@bouncycastle.org> Date: Thu, 28 Aug 2014 09:18:17 +0700 From: Peter Dettman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <53FE288F.9030105@nthpermutation.com> In-Reply-To: <53FE288F.9030105@nthpermutation.com> Content-Type: multipart/alternative; boundary="------------020300050404000904080007" X-Authenticated-User: peter.dettman@bouncycastle.org Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BBevYwqrug17hqasdA69-f55Hc4 Subject: Re: [TLS] IV generation 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, 28 Aug 2014 02:18:34 -0000 This is a multi-part message in MIME format. --------------020300050404000904080007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/08/2014 1:50 am, Michael StJohns wrote: > If the TLS crypto is a stream crypto, then the IV really is an IV for > the stream cipher: it's used when you initialize the stream cipher > before sending the first record; the state of the stream cipher > persists from record to record. While RC4 does not use an IV, and is stateful across records, e.g. http://tools.ietf.org/html/draft-josefsson-salsa20-tls-04 proposes Salsa20 as a stream cipher using a per-record nonce; so statefulness is not an inherent property of a TLS stream cipher and I wouldn't expect to see new ones proposed with that limitation (which prevents use in DTLS) either. > In the block cipher mode for say CBC it *was* the IV for the first > message; second and subsequent messages took their IV from the last > block of the previous message; that changed for TLS1.2. That changed for TLS 1.1, with the introduction of an explicit per-record IV for block ciphers. Pete --------------020300050404000904080007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

On 28/08/2014 1:50 am, Michael StJohns wrote:
If the TLS crypto is a stream crypto, then the IV really is an IV for the stream cipher: it's used when you initialize the stream cipher before sending the first record; the state of the stream cipher persists from record to record.
While RC4 does not use an IV, and is stateful across records, e.g. http://tools.ietf.org/html/draft-josefsson-salsa20-tls-04 proposes Salsa20 as a stream cipher using a per-record nonce; so statefulness is not an inherent property of a TLS stream cipher and I wouldn't expect to see new ones proposed with that limitation (which prevents use in DTLS) either.

In the block cipher mode for say CBC it *was* the IV for the first message; second and subsequent messages took their IV from the last block of the previous message; that changed for TLS1.2.
That changed for TLS 1.1, with the introduction of an explicit per-record IV for block ciphers.

Pete

--------------020300050404000904080007-- From nobody Wed Aug 27 22:03:38 2014 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 299D31A0360 for ; Wed, 27 Aug 2014 22:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=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 jsBcfiWUY5Ql for ; Wed, 27 Aug 2014 22:03:35 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91401A0357 for ; Wed, 27 Aug 2014 22:03:34 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id k48so204632wev.28 for ; Wed, 27 Aug 2014 22:03:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l+Q1Xg8hBDa9OqvLToL7qt8UYsntbgMOJmYl8QgtoDA=; b=cMhcDqRGejqbgTtxEI4ODLOpKtDBnnxv+LKaNgkPMA5EE5za6nOW7+OpuTIDRIgyR0 84daUu0ToKifyzGH45J3tmsr9SGIi9AoBdQx9RlJxcuXSv0CtsGNi8CtN0uwbszcQKQE XSM4AudAYj5f3jc2UiHVMWkPb3iC7vqksnJ7K1qXywj0AxfYmUGyJvmHylbW0caGrm20 3Nvn39AgxqzRlJdqiWEOywrgH+9G0c2fB7PEwc/S1IJw1rZ64J6Lhei8chRffYfIN4A0 dk+1+4c6YnCXcKsWV1pnZlBottRKCSzBYlZ4VAknDIMToyrxbeV69+aEUX7Ox5Sic+zj iRpg== X-Received: by 10.180.10.166 with SMTP id j6mr34735185wib.73.1409202213221; Wed, 27 Aug 2014 22:03:33 -0700 (PDT) Received: from [192.168.1.102] (IGLD-84-228-11-69.inter.net.il. [84.228.11.69]) by mx.google.com with ESMTPSA id ka3sm6777662wjc.3.2014.08.27.22.03.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 22:03:32 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Thu, 28 Aug 2014 08:03:30 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A2ESc2dBYjXHszp1W3b4ZciEykM Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 28 Aug 2014 05:03:36 -0000 On Aug 28, 2014, at 1:04 AM, Watson Ladd wrote: > On Wed, Aug 27, 2014 at 8:29 AM, Blumenthal, Uri - 0558 - MITLL > wrote: >>> What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works = just fine: we don't need variable expansion as it doesn't give us more, = so why support it? >>=20 >> Less disastrous consequence of (inadvertent) IV reuse for CBC? >=20 > Nonces don't repeat, IVs are random. Reuse isn't the issue for CBC, Reuse in CBC tells an observer how many of the initial blocks are = identical. This is more of an issue for IPsec (where the initial blocks = cover IP and TCP header, which tend to have a lot of fields repeat), but = it=92s information disclosure any place you use it. This has been = rationale for why we needed 128-bit block ciphers in the first place. Yoav From nobody Wed Aug 27 22:06:57 2014 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 727D61A035E for ; Wed, 27 Aug 2014 22:06:54 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QeMA-vQluyTN for ; Wed, 27 Aug 2014 22:06:52 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80E171A0351 for ; Wed, 27 Aug 2014 22:06:52 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so6864859wib.8 for ; Wed, 27 Aug 2014 22:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wQrs74n+aegzGDfNAspiF+9xA52/4ojSt3U+mFTUCYo=; b=VNKyVrRXEdXuwE6sy3/LKa1lPvMgZYmT9O4DW7j/IiYwmeafo3rHLGgIR4coGBrLmY F0BxqBSeYL/aAMy526zWDi0KOv9aahAIhAORd9FA+ZJcZPnFtp0/pmJ1pspwoRYffMSP Igwdlh4VVz6VHrfZlSB0HtPVG7PIcCZ35GBHa3znWsSPNyxLK29llHgvuEiLBYdWl0N+ 0H60a77mLJ7V+6htnMRKzEAqQXO8G/BwA5ibDj2mN5q8b051q6iL9vNwamp1gWQJA8vv aV9D4Qlu2k3A0FjZ45UQ+6xaZ1e2/r6pVGh4GhZjhYYbU9EB2dV2z8ybpVQvjRP1Fxlf FwIQ== X-Received: by 10.194.6.101 with SMTP id z5mr1905316wjz.79.1409202409266; Wed, 27 Aug 2014 22:06:49 -0700 (PDT) Received: from [192.168.1.102] (IGLD-84-228-11-69.inter.net.il. [84.228.11.69]) by mx.google.com with ESMTPSA id s7sm6644701wjo.48.2014.08.27.22.06.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Aug 2014 22:06:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7D50BD53-91D4-448E-A11C-93D03A7F7273" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <53FE9169.4010609@bouncycastle.org> Date: Thu, 28 Aug 2014 08:06:47 +0300 Message-Id: <1F64CB19-BC9E-47C1-9ECE-EDC0C50F59B2@gmail.com> References: <53FE288F.9030105@nthpermutation.com> <53FE9169.4010609@bouncycastle.org> To: Peter Dettman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SIZnsIMbBW44b4_qCnHH0dclNxo Cc: tls@ietf.org Subject: Re: [TLS] IV generation 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, 28 Aug 2014 05:06:54 -0000 --Apple-Mail=_7D50BD53-91D4-448E-A11C-93D03A7F7273 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 28, 2014, at 5:18 AM, Peter Dettman = wrote: >=20 > On 28/08/2014 1:50 am, Michael StJohns wrote: >> If the TLS crypto is a stream crypto, then the IV really is an IV for = the stream cipher: it's used when you initialize the stream cipher = before sending the first record; the state of the stream cipher persists = from record to record. > While RC4 does not use an IV, and is stateful across records, e.g. = http://tools.ietf.org/html/draft-josefsson-salsa20-tls-04 proposes = Salsa20 as a stream cipher using a per-record nonce; so statefulness is = not an inherent property of a TLS stream cipher and I wouldn't expect to = see new ones proposed with that limitation (which prevents use in DTLS) = either. Salsa20 (and ChaCha) are more like counter-mode block ciphers than real = streams. That may be splitting hairs, but the important property here is = that real stream ciphers don=92t accept a nonce input. Yoav --Apple-Mail=_7D50BD53-91D4-448E-A11C-93D03A7F7273 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 28, 2014, at 5:18 AM, Peter = Dettman <peter.dettman@bouncycastle.= org> wrote:

=20 =20

On 28/08/2014 1:50 am, Michael StJohns wrote:
If the TLS crypto is a stream crypto, then the IV really is an IV for the stream cipher: it's used when you initialize the stream cipher before sending the first record; the state of the stream cipher persists from record to record.
While RC4 does not use an IV, and is stateful across records, e.g. http://= tools.ietf.org/html/draft-josefsson-salsa20-tls-04 proposes Salsa20 as a stream cipher using a per-record nonce; so statefulness is not an inherent property of a TLS stream cipher and I wouldn't expect to see new ones proposed with that limitation (which prevents use in DTLS) = either.

Salsa20 (and ChaCha) = are more like counter-mode block ciphers than real streams. That may be = splitting hairs, but the important property here is that real stream = ciphers don=92t accept a nonce = input.

Yoav

= --Apple-Mail=_7D50BD53-91D4-448E-A11C-93D03A7F7273-- From nobody Thu Aug 28 12:06:20 2014 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 C09CD1A8977 for ; Thu, 28 Aug 2014 12:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_34=0.6, 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 7eILd9jXTNL3 for ; Thu, 28 Aug 2014 12:06:17 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93C71A890C for ; Thu, 28 Aug 2014 12:06:17 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s7SJ6Ert013885; Thu, 28 Aug 2014 12:06:15 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1p22j9hubn-9 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Aug 2014 12:06:15 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([fe80::5efe:10.93.76.28%12]) with mapi; Thu, 28 Aug 2014 12:06:11 -0700 From: Paul Lambert To: Watson Ladd , "Blumenthal, Uri - 0558 - MITLL" Date: Thu, 28 Aug 2014 12:06:10 -0700 Thread-Topic: [TLS] Pull request: Remove length from AEAD Ciphers Thread-Index: Ac/C8yHSevC1xQdWRFGOjCk5uHj1aQ== Message-ID: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-28_04:2014-08-28,2014-08-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408280214 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nClBhXN2YXHfXQWzqJYDrJBOIv4 Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 28 Aug 2014 19:06:18 -0000 On 8/27/14, 3:04 PM, "Watson Ladd" wrote: > >Nonces don't repeat, IVs are random. The above definitions do not represent industry practice for the terms. I agree that IVs generally should mean random, but there are various protocols that map a counter into an IV. Historical background of IV is from military use and extended the concept of a Message Indicator (which should be random). Likewise, many protocols have a =8Crandom nonce=B9. =20 >Reuse isn't the issue for CBC, >determinism is. TLS gets this wrong, badly, and repeatedly. > >> >> (Yes, your code would *never* do that, but there are other, less >>skilled, programmers around. :-) > >Misuse-resistant AEAD schemes like SIV mode exist and do not have >variable-length ciphertext expansion. Why do we need CBC+HMAC as an >AEAD scheme? What problem is it solving that the existing ones don't? >Furthermore, if we are willing to consider this change, why not >changes to the Finished message to simplify the proof, or using a >well-studied key agreement scheme? I don't understand the logic being >applied: features are being put forward piecemeal, hindering debate >and analysis, while large and well-known issues (like the complexity >of implementations, which changes like the above don't help) aren't on >the table because they could require changes to implementations. Yes - it is tough following this list and what it is trying to accomplish at a high level. Even the idea of length on all the supposedly opaque fields is unnecessary and confusing. If two implementations know the encoding and structure of a set of AEAD protected fields than the length and processing should be implicit. Paul > >Sincerely, >Watson Ladd > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From nobody Thu Aug 28 12:20:12 2014 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 A90C11A00AE for ; Thu, 28 Aug 2014 12:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 521kmnENexpG for ; Thu, 28 Aug 2014 12:20:08 -0700 (PDT) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 936AF1A0084 for ; Thu, 28 Aug 2014 12:20:07 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so1439328wib.16 for ; Thu, 28 Aug 2014 12:20:06 -0700 (PDT) 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-type; bh=aXIph4VIV48JanwX7oHsyr00a0AvmH+/D6tBdwrUamo=; b=Y6LhsIkpblE2L9E69BBR2u0qcyHC3AcHz6misLBy5Letk289Dlu0Kw9zFg3hZUUupO OTeSEufCcEpihbg6y/xDZOayB2iIbbqGKwDlpvHseZSrfj01RbngHR/qldcmAEAbXc4F 5nOnfuktBtNrNAm81BMfx4aVahzlfnK8ihEfn2deTALht7bM4wkidMzVoTwbGJmzB9iF AGWeb77FEAT1vBW8RfiMmUMYY/0y/X7CZjeSWYHNwh+GeseHrtO+KoMABbA6qmJtqr++ NH62MmFOjebl7A4vqm4h64zEGT51n065dRpHwmJJwY5sa51tqQjII7JibC2asaYdo6HE SQdA== X-Gm-Message-State: ALoCoQnbxczx/XwDIVUWiIlhUsbHvtKNEskLJBhlXiZF2k5UacX+PlYm30gVDEXZ03CXAJdM/SAp X-Received: by 10.194.59.244 with SMTP id c20mr7855774wjr.59.1409253606225; Thu, 28 Aug 2014 12:20:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Thu, 28 Aug 2014 12:19:26 -0700 (PDT) X-Originating-IP: [50.136.255.6] In-Reply-To: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> From: Eric Rescorla Date: Thu, 28 Aug 2014 12:19:26 -0700 Message-ID: To: Paul Lambert Content-Type: multipart/alternative; boundary=047d7ba977e89911010501b56ca3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OzmtU-3TGXBo9QUCM83UiqAuqiM Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 28 Aug 2014 19:20:09 -0000 --047d7ba977e89911010501b56ca3 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 28, 2014 at 12:06 PM, Paul Lambert wrote: > > Even the idea of length on all the supposedly opaque fields is unnecessary > and confusing. > If two implementations know the encoding and structure of a set of AEAD > protected fields > than the length and processing should be implicit. > Paul, Can you explain what you mean here? The length in question is the length of the plaintext. So, the problem is that if an AEAD cipher has content-dependent padding (or more likely content-length dependent padding) then it is not possible to determine the plaintext-length value from the ciphertext. -Ekr --047d7ba977e89911010501b56ca3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 28, 2014 at 12:06 PM, Paul Lambert <paul@marvell.com>= wrote:
Even the idea of length on all the supposedly opaque fields is unnecessary<= br> and confusing.
If two implementations know the encoding and structure of a set of AEAD
protected fields
than the length and processing should be implicit.
Paul,

Can you explain what you mean he= re? The length in question is the length
of the plaintext. So, th= e problem is that if an AEAD cipher has content-dependent
padding (or more likely content-length dependent padding) then it is n= ot
possible to determine the plaintext-length value from the ciph= ertext.

-Ekr


--047d7ba977e89911010501b56ca3-- From nobody Thu Aug 28 16:28:47 2014 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 14CCE1A010D for ; Thu, 28 Aug 2014 16:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 S6aP4WQBDsVt for ; Thu, 28 Aug 2014 16:28:44 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C145F1A0109 for ; Thu, 28 Aug 2014 16:28:43 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s7SNSfLs032583; Thu, 28 Aug 2014 16:28:41 -0700 Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1p22j9jppc-8 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Aug 2014 16:28:41 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([fe80::5efe:10.93.76.28%12]) with mapi; Thu, 28 Aug 2014 16:28:37 -0700 From: Paul Lambert To: Eric Rescorla Date: Thu, 28 Aug 2014 16:28:35 -0700 Thread-Topic: [TLS] Pull request: Remove length from AEAD Ciphers Thread-Index: Ac/DF8qqC+a5NMuNSD2+3Ld1NBFuug== Message-ID: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D02501CE4B763paulmarvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-08-29_01:2014-08-28,2014-08-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1408280269 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2yrxw_kfaDIwkq9Bh-Ka30wFLJc Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 28 Aug 2014 23:28:46 -0000 --_000_D02501CE4B763paulmarvellcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Eric, Can you explain what you mean here? Sure =85 but please forgive any ignorance shown on current TLS specifics versus my generic opinions on encapsulation methods. The length in question is the length of the plaintext. So, the problem is that if an AEAD cipher has content-dep= endent padding (or more likely content-length dependent padding) then it is not possible to determine the plaintext-length value from the ciphertext. First - I=92m assuming that it is already known what cipher=96suite is in u= se. The cipher-suite would need to be consistent for a session, or provided for= use In the message prior to the AEAD protected information. If you know the cipher suite (e.g. AEAD cipher) in use, the cipher-suite definition can directly imply the encoding and representation of all fields including the length of fields and the presence or absence of length fields. >From a general perspective, the encryption process should be allowed to increase or decrease the length of the protected Information. Compression might be possible (please, no nits on this, I know of the TLS compression attacks). Expansion Is typical given the common use of an IV and Check Value. Note that I am necessarily differentiating between the expansion due to non-stream cipher block size alignement or from the addition of leading or trailing fields used as part of the overall AEAD processing. On block aligned AEAD approaches. There are a variety of ways to indicate the original length of the plain-text. For example, the padding field has been used to carry the size of the padding =85 and hence determine the original plaintext. Equally valid would be the inclusion of a length field in the protected data. The presence of the length field would be implicit in the definition of the cipher-suite. As an aside =85 If an observer is looking at an encapsulation (AEAD protected in this discussion), all fields ideally should be Indistinguishable. The protected data should be a single opaque octet string (IMHO). It would be desirable to make it difficult to determine the cipher-suite in use by outside observation. The algorithms in use should not be obvious to a casual observer. Typical nonce/IV usage of CCM and GCM tend to break this goal. The use of a counter clearly will show the boundaries of the IV. An explicit length of the IV is still not required for parsing. Other approaches of course could be defined to ensure non-unique, but uniformly distributed IV values. So =85 I hope this digression on IV does not side track the original concept (all fields size and usage determined by cipher suite). Paul -Ekr --_000_D02501CE4B763paulmarvellcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi= Eric,

Can you exp= lain what you mean here?
Su= re =85 but please forgive any ignorance shown on 
current TL= S specifics versus my generic opinions on 
encapsulation met= hods. 

The length in question is the l= ength
of the plaintext. So, the problem is that if an AEAD cipher= has content-dependent
padding (or more likely content-length dep= endent padding) then it is not
possible to determine the plaintex= t-length value from the ciphertext.

First - I=92m assuming that it is already known wha= t cipher=96suite is in use.
The cipher-suite would need to be con= sistent for a session, or provided for use
In the message prior t= o the AEAD protected information.

If you know the = cipher suite (e.g. AEAD cipher) in use, the cipher-suite
definiti= on can directly imply the encoding and representation of all 
fields including the length of fields and the presence or absence of = ;
length fields.

From a general perspect= ive, the encryption process should be
allowed to increase or decr= ease the length of the protected 
Information. Compression m= ight be possible (please, no nits
on this, I know of the TLS comp= ression attacks).  Expansion
Is typical given the common use= of an IV and Check Value.

Note that I am necessar= ily differentiating between
the expansion due to non-stream ciphe= r block size
alignement or from the addition of leading or traili= ng
fields used as part of the overall AEAD processing.
=
On block aligned AEAD approaches.  There are a variety = of ways
to indicate the original length of the plain-text.  = For example,
the padding field has been used to carry the size of=
the padding =85 and hence determine the original plaintext.
Equally valid would be the inclusion of a length field in the
protected data.  The presence of the length field would be
implicit in the definition of the cipher-suite.  

As an aside =85 
If an observer is looking at an enca= psulation (AEAD
protected in this discussion), all fields ideally= should be
Indistinguishable.  The protected data should be = a single
opaque octet string (IMHO).  It would be desirable<= /div>
to make it difficult to determine the cipher-suite in
u= se by outside observation.  The algorithms in use
should not= be obvious to a casual observer.

Typical nonce/IV= usage of CCM and GCM tend to break 
this goal.  The us= e of a counter clearly will show the 
boundaries of the IV. =  An explicit length of the IV is still
not required for pars= ing.  Other approaches of course could
be defined to ensure = non-unique, but uniformly distributed
IV values.  So =85 I h= ope this digression on IV does not side track
the original concep= t (all fields size and usage determined 
by cipher suite).

Paul




<= div class=3D"gmail_quote">

-Ekr




= --_000_D02501CE4B763paulmarvellcom_-- From nobody Thu Aug 28 16:34:44 2014 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 0219E1A0119 for ; Thu, 28 Aug 2014 16:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQAkMlQ3vl9b for ; Thu, 28 Aug 2014 16:34:41 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 916C11A00F2 for ; Thu, 28 Aug 2014 16:34:41 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id pv20so1827653lab.5 for ; Thu, 28 Aug 2014 16:34:40 -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-type:content-transfer-encoding; bh=qCZDTnxPfQQyx5cH5pEvrwV6mIscMEO57mdcCHSo6Ms=; b=TNAVI2d/pDcG+L9r51IGRUHrzWoU5KgJ9a6SpKlvJyDJfDnJMLARiIZfY3/VTX8Dvv oV0+ifsXi4WgIhj8bhowLt89xMtZPltF1bymVaZyxmkMknx/+L9G5atZoJEqUfWInPEg foPR5jjlbbQ0G5e7F4IcH2eWQEB2gViQTP7ZFLL5sVOOZyEZFW+h6duK/19zTCCm4WWo /5ep4eWdq9e/lV+6kii354hR9lUsyYdWNZaJfQodZbipuYOQS27d0nCkDgWxXxaaRsBL iwV/4OAPC82RlIULF3sP9Fd5L4FbH4+KgbTDne8Uke4q10O+C4RyycE+rbIKxCRUA01R 7pUA== MIME-Version: 1.0 X-Received: by 10.112.180.69 with SMTP id dm5mr7268593lbc.19.1409268879959; Thu, 28 Aug 2014 16:34:39 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 28 Aug 2014 16:34:39 -0700 (PDT) In-Reply-To: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> <0416DB16-7794-419A-AA55-9902E368411C@ll.mit.edu> Date: Thu, 28 Aug 2014 16:34:39 -0700 Message-ID: From: Martin Thomson To: Paul Lambert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KxXD8BzpLgRV7q3R2VQqzA3_BtE Cc: "tls@ietf.org" Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 28 Aug 2014 23:34:43 -0000 On 28 August 2014 16:28, Paul Lambert wrote: > On block aligned AEAD approaches. There are a variety of ways > to indicate the original length of the plain-text. For example, > the padding field has been used to carry the size of > the padding =E2=80=A6 and hence determine the original plaintext. > Equally valid would be the inclusion of a length field in the > protected data. The presence of the length field would be > implicit in the definition of the cipher-suite. We might want to explicitly hide the length of the plaintext from an outside observer. Therefore, it makes sense that the length of the plaintext be, at least in some circumstances, unknown prior to decryption. However, the TLS 1.2 AEAD formulation *requires* that the plaintext length be included in the protected additional data. You cannot decrypt an AEAD block unless you have all of the additional data, so these are directly opposed goals. Yes, you could signal the amount of padding outside the encrypted envelope, but that would be a ciphersuite-specific choice (and arguably a bad one). The TLS 1.2 formulation requires that length be *generically* available. From nobody Thu Aug 28 23:46:57 2014 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 D6B9C1A0653 for ; Thu, 28 Aug 2014 23:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.97 X-Spam-Level: X-Spam-Status: No, score=-6.97 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 nNeWro-jsGUC for ; Thu, 28 Aug 2014 23:46:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 F236E1A064F for ; Thu, 28 Aug 2014 23:46:49 -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 (8.14.4/8.14.4) with ESMTP id s7T6kmZ0022607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 29 Aug 2014 02:46:49 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7T6kkJH016796 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Fri, 29 Aug 2014 02:46:48 -0400 Message-ID: <1409294806.25837.9.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Fri, 29 Aug 2014 08:46:46 +0200 In-Reply-To: References: <1409139527.25920.22.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MtsWpmtNfeCfv-7JZ8snTP0ZjcM Subject: Re: [TLS] Pull request: Remove length from AEAD Ciphers 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, 29 Aug 2014 06:46:52 -0000 On Wed, 2014-08-27 at 08:14 -0700, Eric Rescorla wrote: > So let's suppose we have TLS_AEAD_AES_128_CBC_SHA1 defined > sometime > after TLS 1.3 is published. What would a TLS 1.2 > implementation do if > faced with this ciphersuite? Should it implement it using the > TLS 1.3 > semantics, or it shouldn't implement it at all? What if two > implementations make a different choice in that dilema? The > whole AEAD > ciphersuite handling is becoming quite complex. > > > Sure. I would suggest we address this problem if/when someone > actually defines such a cipher suite, which can either update > RFC 5246 appropriately or say "do not use in TLS 1.2". That must be decided now when the change is done. Otherwise we cannot predict the intentions of a future document author; nor assume that such a document would pass from the WG. > I think the simplest way to solve the ambiguities, would be to > have an > extension that would enable the new AEAD format, rather than > rely on the > TLS 1.3 version. That way negotiation would be > straightforward; if the > extension is present the new AEAD format will be used > regardless the TLS > version. > > > I would prefer not to do this. One advantage of having a new version > number is > not having a bunch of extension-optional behavior when you really only > want one. What I'm most worried is that this will happen anyway, since at some point it will be asked from the WG to allow any new ciphersuites to be used in old TLS versions (it has already happened with TLS < 1.2 and GCM). On Wed, 2014-08-27 at 08:20 -0700, Watson Ladd wrote: > > What's the point of making CBC+HMAC ciphersuites? CTR+HMAC works just > fine: we don't need variable expansion as it doesn't give us > more, so why support it? I don't believe that's the question we are facing. I believe the question is when. Documents already exist [0], and it is the intention of the TLS chairs to move that way (or at least that was mentioned in IETF 87 during tls 1.3 discussion [1]; that may be out of date though). regards, Nikos [0]. http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-05 [1]. http://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf From nobody Fri Aug 29 01:14:25 2014 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 735F61A06A3 for ; Fri, 29 Aug 2014 01:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, 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 oyS2jDh437Cg for ; Fri, 29 Aug 2014 01:14:22 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 464251A06A2 for ; Fri, 29 Aug 2014 01:14:22 -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 (8.14.4/8.14.4) with ESMTP id s7T8E9QP023515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 29 Aug 2014 04:14:10 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7T8E7KR002294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 29 Aug 2014 04:14:09 -0400 Message-ID: <1409300046.25837.20.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Ilari Liusvaara Date: Fri, 29 Aug 2014 10:14:06 +0200 In-Reply-To: <20140827150514.GA9874@LK-Perkele-VII> References: <1409140776.25920.30.camel@dhcp-2-127.brq.redhat.com> <20140827150514.GA9874@LK-Perkele-VII> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PsQxQS57IAluMEuG5l4o0-MBoyU Cc: "tls@ietf.org" Subject: Re: [TLS] a TLS server cannot be used in a use-case that requires privilege separation 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, 29 Aug 2014 08:14:23 -0000 On Wed, 2014-08-27 at 18:05 +0300, Ilari Liusvaara wrote: > The basic idea is to derive a subkey from master secret that is then > used to prove certificate verification signatures are fresh[1]. > > Considering the order TLS 1.3 key exchange runs, the connection master > keys are known by the point either endpoint attempts to send certificates > or certificate verification messages (they have to be, the messages are > supposedly encrypted!). > > > I believe it is a nice goal to set for a future revision of TLS, to have > > the CertificateVerify message modified to have the same properties as > > the ServerKeyExchange message. That is, to have an additional fixed > > field that is set by the server. > It can't be set by the server, since that leads to security holes. It has > to be set by both client and server in collision-resistant manner. I don't really want to get into details because there is not much point at this moment, but what I say above is an _additional_ field to the existing format. The existing format (hash of all previous messages) already handles (one way or another) the requirements of the protocol from a digital signature. regards, Nikos