From turners@ieca.com Tue Sep 3 07:03:17 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C2011E8209 for ; Tue, 3 Sep 2013 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.886 X-Spam-Level: X-Spam-Status: No, score=-101.886 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEBU+qIxpjHu for ; Tue, 3 Sep 2013 07:03:12 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.103.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD5411E8202 for ; Tue, 3 Sep 2013 07:03:09 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id D5F7B46BC0C75; Tue, 3 Sep 2013 09:03:08 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id ADDC146BC0B85 for ; Tue, 3 Sep 2013 09:03:08 -0500 (CDT) Received: from [96.231.225.44] (port=53663 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VGrCG-0001K2-7e for tls@ietf.org; Tue, 03 Sep 2013 09:03:08 -0500 Message-ID: <5225EC1B.4050508@ieca.com> Date: Tue, 03 Sep 2013 10:03:07 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <20130830212058.8158.22644.idtracker@ietfa.amsl.com> In-Reply-To: <20130830212058.8158.22644.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130830212058.8158.22644.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:53663 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Subject: [TLS] Fwd: I-D Action: draft-mcgrew-tls-aes-ccm-ecc-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:03:17 -0000 This draft has been hanging out for a while and David made some changes that I requested. I'm going to issue an IETF LC in a couple of days and I'll make sure to cc the wg so you'll not miss the opportunity to send in any comments. spt -------- Original Message -------- Subject: I-D Action: draft-mcgrew-tls-aes-ccm-ecc-07.txt Date: Fri, 30 Aug 2013 14:20:58 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : AES-CCM ECC Cipher Suites for TLS Author(s) : David McGrew Daniel V. Bailey Matthew Campagna Robert Dugal Filename : draft-mcgrew-tls-aes-ccm-ecc-07.txt Pages : 10 Date : 2013-07-12 Abstract: This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. The ciphersuites defined in this document use Elliptic Curve Cryptography (ECC), and are advantageous in networks with limited bandwidth. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc There's also a htmlized version available at: http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-mcgrew-tls-aes-ccm-ecc-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From d.sturek@att.net Tue Sep 3 07:22:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA81621E80B9 for ; Tue, 3 Sep 2013 07:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJbZ60R73JG1 for ; Tue, 3 Sep 2013 07:21:55 -0700 (PDT) Received: from nm26-vm6.access.bullet.mail.bf1.yahoo.com (nm26-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.213]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7C721F9C3A for ; Tue, 3 Sep 2013 07:21:55 -0700 (PDT) Received: from [66.196.81.165] by nm26.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Sep 2013 14:21:52 -0000 Received: from [98.138.84.172] by tm11.access.bullet.mail.bf1.yahoo.com with NNFMP; 03 Sep 2013 14:21:52 -0000 Received: from [127.0.0.1] by smtp106.sbc.mail.ne1.yahoo.com with NNFMP; 03 Sep 2013 14:21:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1378218112; bh=ZP1hKLZCTA5BE5JbQGGGxfI+VrG9CDwLQt8e8/6xks8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=DdSID9p3ZgMMtzFi5vnakUxT7GK66Mq51FlHaqwit6XDHiCvWV35FuRBd83n3ETzds7zcom79dkugRj/vA5bgCx9ovx12NkZ62tDh7Le2TpXfWyzmMa8s8x1xChtxoeTKhe763mEo5TLCNxiK2JUmYk6jzUSr2xhd0dQOmljg/0= X-Yahoo-Newman-Id: 120495.81882.bm@smtp106.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MPd1bwwVM1mRUqgTEXUZbSKOz3O7KvnClACFyQUNJkqX7NK 6slCHz_nOS_DlsnJT4_3b.fjztZR6H.zF3WtacMmBBcNhHr.Zz5yqdd7_fel G2nga1XIRAdpilFyL28t.zx_7KhNYVywUdde16UoXIyDMPjB4v.i_oX1149A FqEm57M3oqXQWVIwWQ9bHUTl1vj48sPuf1cgkYcMNskBiPgmEpaLShJaPYcE aUKENIMMYHtpfPski4PbdgCaQ2p6.bqa8psvKEUZAUKXOwCfZEx9JEFLmeNR b8ujMfrilOXyl_g7SkvHBDBnZqGnFvPTBV7Yg84jP_LfpD_PL4XLxq5O6Co2 bEonQFfvomtaoUGbXCAaDbhd7oXGV4qfCjJue4ESV8ATmTXbKcQIaRc.JJOr KXdNPKEGxNdcjxvx8rwbkBzIDUqSoBDvTz2SstJKVwp9gpgwtQqYyl4jajic ajPRaOsPITHd9P5R.vmqGbnjF3xrts0CJGuygQ8NNdrFGvhOCn2crACVpcyD eNuVnV3E.IBh4vb_fTIg- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-Rocket-Received: from [10.0.0.4] (d.sturek@67.124.200.201 with login) by smtp106.sbc.mail.ne1.yahoo.com with SMTP; 03 Sep 2013 07:21:52 -0700 PDT User-Agent: Microsoft-MacOutlook/14.3.6.130613 Date: Tue, 03 Sep 2013 07:19:21 -0700 From: Don Sturek To: Sean Turner , Message-ID: Thread-Topic: [TLS] Fwd: I-D Action: draft-mcgrew-tls-aes-ccm-ecc-07.txt In-Reply-To: <5225EC1B.4050508@ieca.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Fwd: I-D Action: draft-mcgrew-tls-aes-ccm-ecc-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2013 14:22:07 -0000 Hi Sean (and David), Thanks for getting this draft moving forward again. Within ZigBee IP, we plan to support this draft and look forward to finalization. Thanks, Don Sturek Chair, ZigBee Core Stack Working Group Chair....... On 9/3/13 7:03 AM, "Sean Turner" wrote: >This draft has been hanging out for a while and David made some changes >that I requested. I'm going to issue an IETF LC in a couple of days and >I'll make sure to cc the wg so you'll not miss the opportunity to send >in any comments. > >spt > >-------- Original Message -------- >Subject: I-D Action: draft-mcgrew-tls-aes-ccm-ecc-07.txt >Date: Fri, 30 Aug 2013 14:20:58 -0700 >From: internet-drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org > > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : AES-CCM ECC Cipher Suites for TLS > Author(s) : David McGrew > Daniel V. Bailey > Matthew Campagna > Robert Dugal > Filename : draft-mcgrew-tls-aes-ccm-ecc-07.txt > Pages : 10 > Date : 2013-07-12 > >Abstract: > This memo describes the use of the Advanced Encryption Standard (AES) > in the Counter and CBC-MAC Mode (CCM) of operation within Transport > Layer Security (TLS) to provide confidentiality and data origin > authentication. The AES-CCM algorithm is amenable to compact > implementations, making it suitable for constrained environments. > The ciphersuites defined in this document use Elliptic Curve > Cryptography (ECC), and are advantageous in networks with limited > bandwidth. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-07 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-mcgrew-tls-aes-ccm-ecc-07 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/i-d-announce >Internet-Draft directories: http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From seonghan.shin@aist.go.jp Wed Sep 4 02:39:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC0311E81A4 for ; Wed, 4 Sep 2013 02:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae6BBcNTgIYJ for ; Wed, 4 Sep 2013 02:39:08 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id F1D6811E819C for ; Wed, 4 Sep 2013 02:39:06 -0700 (PDT) Received: from mail-lb0-f169.google.com ([209.85.217.169]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKUib/uuo6bX8fonPBAoz8HXA7828sRbsK@postini.com; Wed, 04 Sep 2013 02:39:07 PDT Received: by mail-lb0-f169.google.com with SMTP id z5so164859lbh.0 for ; Wed, 04 Sep 2013 02:39:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gVmRDb45/5ls7Ozq3TJsjc3lVIY8Zp2J5GDNiQ5vgVU=; b=MM9xNBnRWuVtS65xKbrCbp4YXIUP+LJZiglDYVFOWQ5yyNOv45StJiHrAKpOBsGyPK kMaTUrue8nzlnMS2ow4YX9Wc8WZ7fCxaoR2jP5zizg2RP8/c+O50AKLdrrVTM2A+bI/H HeppSq9VIrBnMdOyak1jvhRbHsPyl462PYFKE= 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=gVmRDb45/5ls7Ozq3TJsjc3lVIY8Zp2J5GDNiQ5vgVU=; b=DeYPg/ltylRm6T2GQcKeDMaWUaNBv4UHq90/rGarn805A2TT0GpNLYRwaB4pFe93ld 8c1MsKhQVuLJZh/hi0PUdS6kDAJW9XqyUAjO0aHqhSkcFkBfCpTu8o3/pTT4xDhqk7P1 er8HU7fVAMFLh1fPc5hs+qtiCXK/64PyCx5SN3O/SBAwuiLH2jC/+djcDXYMQslNoh1d SFrIehAGOmoY2G7SIZYfBF6RBodhM+5fz+2DVj0fPgw3hQJdqfcQFQ2VQxY/y/pd4Caq pjCcdTlD5a9BlYLJb0ki4CNcBzk7x4X65ORADa4NYcRBZZos44VEG8sGBjjdgE6nxbwf NPpw== X-Gm-Message-State: ALoCoQkypg4O+EN8Kocm0Vx7CtIQOTay/n/ZB03XP3fUjJYIeNeGqdxKuTgzgYo7xNPawyeWwVJMO+6ynE+TWro9KYzIQL5UW7RHOIrtDOHAOv61rXNkyADpItxk4DbJf+8da8eaBT2x97OYgO41XAzGVtbhC9CfsA== X-Received: by 10.152.7.8 with SMTP id f8mr1448494laa.31.1378287544848; Wed, 04 Sep 2013 02:39:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.152.7.8 with SMTP id f8mr1448485laa.31.1378287544645; Wed, 04 Sep 2013 02:39:04 -0700 (PDT) Received: by 10.112.134.227 with HTTP; Wed, 4 Sep 2013 02:39:04 -0700 (PDT) In-Reply-To: <20130904092645.15477.65140.idtracker@ietfa.amsl.com> References: <20130904092645.15477.65140.idtracker@ietfa.amsl.com> Date: Wed, 4 Sep 2013 18:39:04 +0900 Message-ID: From: SeongHan Shin To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11c2a0f47f499804e58b9321 Cc: =?UTF-8?B?5Y+k5Y6f5ZKM6YKm?= Subject: [TLS] Fwd: New Version Notification for draft-shin-tls-augpake-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 09:39:15 -0000 --001a11c2a0f47f499804e58b9321 Content-Type: text/plain; charset=ISO-8859-1 Dear all, I submitted a new version of our I-D regarding augmented PAKE (AugPAKE) and its integration into TLS. I added some features of AugPAKE in Appendix. Any comments are welcome! Best regards, Shin ---------- Forwarded message ---------- From: Date: Wed, Sep 4, 2013 at 6:26 PM Subject: New Version Notification for draft-shin-tls-augpake-01.txt To: Kazukuni Kobara , SeongHan Shin < seonghan.shin@aist.go.jp> A new version of I-D, draft-shin-tls-augpake-01.txt has been successfully submitted by SeongHan Shin and posted to the IETF repository. Filename: draft-shin-tls-augpake Revision: 01 Title: Augmented Password-Authenticated Key Exchange for Transport Layer Security (TLS) Creation date: 2013-09-04 Group: Individual Submission Number of pages: 19 URL: http://www.ietf.org/internet-drafts/draft-shin-tls-augpake-01.txt Status: http://datatracker.ietf.org/doc/draft-shin-tls-augpake Htmlized: http://tools.ietf.org/html/draft-shin-tls-augpake-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-shin-tls-augpake-01 Abstract: This document describes an efficient augmented password-authenticated key exchange (AugPAKE) protocol where a user remembers a low-entropy password and its verifier is registered in the intended server. In general, the user password is chosen from a small set of dictionary whose space is within the off-line dictionary attacks. The AugPAKE protocol described here is secure against passive attacks, active attacks and off-line dictionary attacks (on the obtained messages with passive/active attacks), and also provides resistance to server compromise (in the context of augmented PAKE security). Based on the AugPAKE protocol, this document also specifies a new password-only authentication handshake for Transport Layer Security (TLS) protocol. 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 -- ------------------------------------------------------------------ SeongHan Shin Research Institute for Secure Systems (RISEC), National Institute of Advanced Industrial Science and Technology (AIST), Central 2, 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan Tel : +81-29-861-2670/5284 Fax : +81-29-861-5285 E-mail : seonghan.shin@aist.go.jp ------------------------------------------------------------------ --001a11c2a0f47f499804e58b9321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

I submitte= d a new version of our I-D regarding augmented PAKE (AugPAKE) and its integ= ration into TLS.
I added some features of AugPAKE in Appendix.
Any comments are welcome!

Best regards,
Shin

--------= -- Forwarded message ----------
From: = <internet= -drafts@ietf.org>
Date: Wed, Sep 4, 2013 at 6:26 PM
Subject: New Version Notification for = draft-shin-tls-augpake-01.txt
To: Kazukuni Kobara <kobara_conf-ml@aist.go.jp>, SeongHan Shin= <seonghan.shin@aist.go.jp>



A new version of I-D, draft-shin-tls-augpake-01.txt
has been successfully submitted by SeongHan Shin and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-shin-tls-augpake
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Augmented Password-Authenticated Key Exchange fo= r Transport Layer Security (TLS)
Creation date: =A0 2013-09-04
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 19
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/inter= net-drafts/draft-shin-tls-augpake-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-= shin-tls-augpake
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-shin-tls-= augpake-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?ur= l2=3Ddraft-shin-tls-augpake-01

Abstract:
=A0 =A0This document describes an efficient augmented password-authenticate= d
=A0 =A0key exchange (AugPAKE) protocol where a user remembers a low-entropy=
=A0 =A0password and its verifier is registered in the intended server. =A0I= n
=A0 =A0general, the user password is chosen from a small set of dictionary<= br> =A0 =A0whose space is within the off-line dictionary attacks. =A0The AugPAK= E
=A0 =A0protocol described here is secure against passive attacks, active =A0 =A0attacks and off-line dictionary attacks (on the obtained messages =A0 =A0with passive/active attacks), and also provides resistance to server=
=A0 =A0compromise (in the context of augmented PAKE security). =A0Based on = the
=A0 =A0AugPAKE protocol, this document also specifies a new password-only =A0 =A0authentication handshake for Transport Layer Security (TLS) protocol= .




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

The IETF Secretariat




--
------------------------------------------------------------------
S= eongHan Shin
Research Institute for Secure Systems (RISEC),
National Ins= titute of Advanced Industrial Science and Technology (AIST),
Central 2, = 1-1-1, Umezono, Tsukuba City, Ibaraki 305-8568 Japan
Tel : +81-29-861-2670/5284
Fax : +81-29-861-5285
E-mail : = seonghan.shin@aist.go.jp
------------------------------------= ------------------------------
--001a11c2a0f47f499804e58b9321-- From msj@nthpermutation.com Thu Sep 5 21:10:51 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F721E8096 for ; Thu, 5 Sep 2013 21:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IWYrGehOUlH for ; Thu, 5 Sep 2013 21:10:45 -0700 (PDT) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC7C11E8253 for ; Thu, 5 Sep 2013 21:10:34 -0700 (PDT) Received: by mail-qc0-f180.google.com with SMTP id p19so1336542qcv.11 for ; Thu, 05 Sep 2013 21:10:34 -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:content-type:content-transfer-encoding; bh=xLZ1vqmqMyiBhp0R0BKPc7hOy4hGitQKNsbdc7iSfp0=; b=M44wiKckj4MOBs/06+SWUTVeSWSewh/P45ZeOaDr3hw4myQfCcr2vZJ3IfUXZLz4Um Raue8Z+/XviK+4gX5bExSrE7YuUeV8nc8obBBivIRBPxe/5m72eitK1WhwQPy8/Aa9Tm 3uKSyLZyzOSaZPK15YzQIp3Q5byj627W3Gr2VT9OOkFIrFI/Wrnmv9JK/7fJIZcC8J5J luajPjKowHjCYAuYddBs5WhaUVrCsAy0jsOJcj1AuySsJ2IhU+N2i8TJbj2t55GqSVOP w/6xVYKVj+YGVD8H093AGmp7XF2ld3dxBXjE+64lnDdaHqC22Np0BK9VfCOAPKlcQ1tt yfCQ== X-Gm-Message-State: ALoCoQkV2DR+Osgb9Isaztajm58wDMmLLuhxbBkVctTvBjnUCGnmjSBz0L+kVM1qbb+M2oV02tYr X-Received: by 10.229.201.67 with SMTP id ez3mr607364qcb.1.1378440634157; Thu, 05 Sep 2013 21:10:34 -0700 (PDT) Received: from [192.168.1.116] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id a2sm1051926qek.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Sep 2013 21:10:33 -0700 (PDT) Message-ID: <522955BC.8000407@nthpermutation.com> Date: Fri, 06 Sep 2013 00:10:36 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] TLS and hardware security modules - some issues related to PKCS11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 04:10:51 -0000 HI - I'm currently working with the PKCS11 group in Oasis. One of the items for the new draft (2.40) was adding PKCS11 mechanism definitions for TLS1.2. As part of that, I started looking closely at TLS and its key derivation mechanisms. Hardware Security Modules (HSMs) are used both for cryptographic acceleration, and for protection of key material. The way TLS (1.0, 1.1 and 1.2) does its key derivations pose a number of challenges for that second goal. Consider the typical chain of derived material generated for a TLS connection: (keywrap or key agreement) -> pre-master secret pre-master secret -> master secret master secret -> mac key client -> mac key server -> encrypt key client -> encrypt key server -> client IV (public data) -> server IV (public data) master secret -> client finished "mac" (public data) -> server finished "mac" (public data) All of these are produced through the application of the TLS PRF to a key using a specific "label" and other data. In PKCS11 v2.40, the CKM_TLS_PRF mechanism can be used with a key to produce public data. This is used both to produce the finished verify_data and for the more general use of key exporters. However, as defined, there is no restriction on using that function with any tls "label" and with any other additional data. That basically allows someone who has access to "use" the master_secret with the "key expansion" label and the random data to produce a public version of the mac and encryption keys. In the current PKCS11 draft to fix the above, the CKM_TLS_PRF user accessible mechanism has been deprecated in favor of a TLS KDF that can be used for a key exporter (and produces only private key material), and a TLS MAC that is used to produce the finished message verify data (public data). The latter function doesn't allow a label to be supplied, but instead takes a parameter that references two fixed label values - those associated with the finished message verify_data. That still leaves a second problem. The "key expansion" stage produces both private (key material) and public (iv data) by producing a key stream and then splitting up (based on the sizes of keys needed) into the 4 keys and 2 IVs. o Consider an application that needs to produce 2 128 bit AES keys and 2 IVs (for say GCM). o Consider that an attacker (or a hacked program that's being used to extract keys) re-runs the derivation using the same master key and same random data, this time specifying zero length keys (or 64 bits of keys etc), but still asks for the IV material. The part of the key stream previously assigned to the encryption keys is now assigned to the IV material. Since IVs by their nature are public, the attacker now has direct access to the key material previously used for encryption. Fortunately, TLS1.1 changed the way IVs were calculated making it possible to prohibit that leaking. Unfortunately, the CCM and GCM mechanisms for TLS1.2 decided to use the IV values making impossible to prohibit the leaking. For the current PKCS11 draft, we finessed it by creating two mechanisms - one that created only key material, and one that created key material and IVs. PKCS11 allows a specific key to be constrained to a specific mechanism so that permits some security for the non-AEAD suites. It's not ideal, but its a beginning Going forward (e.g. TLS1.3 and any revision to the TLS1.2 AEAD mechanisms) , I'd like to recommend the following changes to the "key expansion" derivation step (this replaces text in section 6.3 of RFC5256): >> When keys and MAC keys are generated, the master secret is used as an >> entropy source. >> >> To generate the key material, compute >> >> key_block = PRF(SecurityParameters.master_secret, >> "key expansion", >> SecurityParameters.server_random + >> SecurityParameters.client_random); >> >> until enough output has been generated. Then, the key_block is >> partitioned as follows: >> >> client_write_MAC_key[SecurityParameters.mac_key_length] >> server_write_MAC_key[SecurityParameters.mac_key_length] >> client_write_key[SecurityParameters.enc_key_length] >> server_write_key[SecurityParameters.enc_key_length] > *** Change begins here >> iv_subkey [32 bytes] (if IV material is requested) >> >> The IV's are generated by computing >> >> iv_block = PRF (iv_subkey, >> "iv generation", >> SecurityParameters.server_random + >> SecruityParameters.client_random); >> >> until enough output has been generated. Then the iv_block is >> partitioned as follows: >> >> client_write_IV[SecurityParameters.fixed_iv_length] >> server_write_IV[SecurityParameters.fixed_iv_length] >> > Basically, doing it this way places a "firewall" between the private data and the public data that can't be trivially defeated by varying the length of the requested key material. Alternately, the IV production as part of key expansion could be removed completely and crypto suites directed to find another way of selecting the IV. Thanks - Mike From stpeter@stpeter.im Sat Sep 7 19:59:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF7221F9D4C for ; Sat, 7 Sep 2013 19:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjzGiCWnD6Em for ; Sat, 7 Sep 2013 19:59:29 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5958D21F9D2B for ; Sat, 7 Sep 2013 19:59:29 -0700 (PDT) Received: from ergon.local (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E389D414CF; Sat, 7 Sep 2013 21:03:40 -0600 (MDT) Message-ID: <522BE808.4090405@stpeter.im> Date: Sat, 07 Sep 2013 20:59:20 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "'tls@ietf.org'" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] padding bug (was: Re: Requesting feedback on TACK draft) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 02:59:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [old thread alert!] On 7/1/13 3:02 AM, Lewis, Nick wrote: >> While people are looking at that, there's also the >> encrypt-then-MAC draft, >> http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-03.txt, >> >> which has been stable for about as long, has already been deployed by >> several vendors, and for which TLS extension 0x10 has been de >> facto claimed, so it'd be good to get this published to >> legitimise the use (and to document what's already being deployed >> in production). > > As I recall there were three proposals for resolving the padding > bug in TLS > > 1. An extension for Pad First (i.e. padding before an > otherwise standard TLS mode of operation) > > 2. An extension for Encrypt-then-MAC (i.e. this draft) > > 3. The replacement of each existing cipher suite with an > equivalent AEAD one > > Was any consensus achieved as to the best approach? I never saw further discussion on this topic. Are there I-Ds for each approach? #3 seems onerous to me (and doubling the number of cipher suites doesn't seem like a desirable outcome), and as far as I can tell there's no specification for #1. Although I am not a TLS expert, the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly solves a real-world problem, and we have running code; thus IMHO formalization of this approach deserves to be considered in the WG. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSK+gIAAoJEOoGpJErxa2plBoP/iUBRQUD29mmNlZkdAHhsFAL FKcBXGt6xPmUi/uNuf+p9NUz5MB4MIXJ6urkdrAy5Lk2828ll7aUoJy0muQYcNuR YdCn8VP9zlKhhzmvr3ENJkCLUg0UG+hU9CkIGXkSNUo1k3IrhxYwFQ4fvGHMhy8m n7ba5+mpLHxu9kaqbrhDIkR5gOMDLGdq3fG5y9iuEiAEobFUr4/yKDKIkXbfBrTM kKHXR4tlSChTphHMjlSuq4drILkqQ//Bpsn8fK5P9pQ1BvF9Wlo7xsSkQ4LayLvs dhNn863SWfBtdq3u2AxtdsY+mPxf/6qO5B7R+N7lawfe2bnSc/24db+grROxES6D o9rQjuFj0ReF+2bKhbxxTh/VRzCpu0L5TNzOTxnx267OW/+HmlmDTgKc2QpcM0F2 gxgkqGUZpRpZxAr21V2giub7HJ0KeN2kNfzUNaMpZaJD1MvvYZsw5sDCwEDMlUCj qbTVWDere5p+3D4gMmRSGQroO8eUKVs+hrLpAlMIHvHqtVPuqFxZXlBSA9Ev6KkK KhMeaCA9RoqkVAI0VQnuz03bduv4eWU6TLPbII6MharvM9ArPMSX8ZI39e32yWos QLZ44zt+VfoTkpZ0S9w78pWTRQDt8zdWiRx+pAoadHUlRY5JDJ0HJcoU9MphUhg/ yDu4w8yNTA/m1Z+kXmR/ =s05+ -----END PGP SIGNATURE----- From yaronf.ietf@gmail.com Sun Sep 8 01:26:04 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7088F21F9D89 for ; Sun, 8 Sep 2013 01:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RauklDVsTeI3 for ; Sun, 8 Sep 2013 01:26:02 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8058821F9D35 for ; Sun, 8 Sep 2013 01:26:02 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id j13so4320791wgh.29 for ; Sun, 08 Sep 2013 01:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=SokSf3JmydOGHXqQG+u7aLn97dk+m89bIQp6ipku19M=; b=w2UWqzMSGXfoOEqyIRJe5FBAAq0ETxjjcb3cbUmxtn8yKQiMBCfq+MVCKMD63BaSvD ysC34uieKJzRIQsOSn4qdCNHP5Z31AlKJp0A3kFnRGixZKRt3jEOmewyp9MW+bt2g6T0 4V3obkW1SmiSgcx3Ujej6ljgpy9/baxT8Rbe2COaQZBY8HAF0vaNznEy+D4xYON7s6kg P/clSytoI/T2+Ms+WN48eefVXlLhQO5BWAKsWJu+ERGCijU/xBMbW1WPCu9JTaZUyVSh GqC/P25vqyypz3CQ+lPrc3qVRrU1XXK7lmDk6gapnwFneq8nnIIc+sGHO1dHeBziNlKG ce3A== X-Received: by 10.180.38.73 with SMTP id e9mr1933108wik.31.1378628761690; Sun, 08 Sep 2013 01:26:01 -0700 (PDT) Received: from [10.0.0.143] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id i3sm8710649wiw.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 01:26:01 -0700 (PDT) Message-ID: <522C3497.9020301@gmail.com> Date: Sun, 08 Sep 2013 11:25:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> In-Reply-To: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 08:26:04 -0000 This is an early version of my proposal for a BCP-like document, to inform the industry on what can be done with existing implementations, while TLS 1.3 is still not ready. I would appreciate your comments of course. Specifically, I would like to fill in the Implementation Status table (Sec. 5) and would be glad to receive solid information (dates, planned dates, version numbers) from implementers. Thanks, Yaron -------- Original Message -------- Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt Date: Sat, 07 Sep 2013 15:46:38 -0700 From: internet-drafts@ietf.org To: Yaron Sheffer A new version of I-D, draft-sheffer-tls-bcp-00.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Filename: draft-sheffer-tls-bcp Revision: 00 Title: Recommendations for Secure Use of TLS and DTLS Creation date: 2013-09-08 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt Status: http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp Htmlized: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 Abstract: Over the last few years there have been several serious attacks on TLS, including attacks on its most commonly used ciphers and modes of operation. This document offers recommendations on securely using the TLS and DTLS protocols, given existing standards and implementations. 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 From Kenny.Paterson@rhul.ac.uk Sun Sep 8 03:12:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C91B21F9DB4 for ; Sun, 8 Sep 2013 03:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bbx4waXjb69 for ; Sun, 8 Sep 2013 03:12:48 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 477BE21F9DA9 for ; Sun, 8 Sep 2013 03:12:48 -0700 (PDT) Received: from mail79-co9-R.bigfish.com (10.236.132.239) by CO9EHSOBE023.bigfish.com (10.236.130.86) with Microsoft SMTP Server id 14.1.225.22; Sun, 8 Sep 2013 10:12:47 +0000 Received: from mail79-co9 (localhost [127.0.0.1]) by mail79-co9-R.bigfish.com (Postfix) with ESMTP id C690D340200 for ; Sun, 8 Sep 2013 10:12:47 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.107; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB01.cc.rhul.local; RD:exch-hub01.rhul.ac.uk; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zf7Izbb2dI98dI936eI148cI542I1432I4015Idb82hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h8275bh8275dhz2dh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.248.133; KIP:(null); UIP:(null); (null); H:AMXPRD0310HT004.eurprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail79-co9 (localhost.localdomain [127.0.0.1]) by mail79-co9 (MessageSwitch) id 1378635165482161_31259; Sun, 8 Sep 2013 10:12:45 +0000 (UTC) Received: from CO9EHSMHS022.bigfish.com (unknown [10.236.132.252]) by mail79-co9.bigfish.com (Postfix) with ESMTP id 67D1DA020A for ; Sun, 8 Sep 2013 10:12:45 +0000 (UTC) Received: from EXCH-HUB01.cc.rhul.local (134.219.208.107) by CO9EHSMHS022.bigfish.com (10.236.130.32) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 8 Sep 2013 10:12:44 +0000 Received: from co1outboundpool.messaging.microsoft.com (134.219.208.67) by hybrid.rhul.ac.uk (134.219.208.107) with Microsoft SMTP Server (TLS) id 14.2.328.9; Sun, 8 Sep 2013 11:12:42 +0100 Received: from mail79-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE039.bigfish.com (10.243.66.104) with Microsoft SMTP Server id 14.1.225.22; Sun, 8 Sep 2013 10:12:41 +0000 Received: from mail79-co1 (localhost [127.0.0.1]) by mail79-co1-R.bigfish.com (Postfix) with ESMTP id 541247C00F4 for ; Sun, 8 Sep 2013 10:12:41 +0000 (UTC) Received: from mail79-co1 (localhost.localdomain [127.0.0.1]) by mail79-co1 (MessageSwitch) id 1378635159509823_22143; Sun, 8 Sep 2013 10:12:39 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.230]) by mail79-co1.bigfish.com (Postfix) with ESMTP id 78F254C005D; Sun, 8 Sep 2013 10:12:39 +0000 (UTC) Received: from AMXPRD0310HT004.eurprd03.prod.outlook.com (157.56.248.133) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 8 Sep 2013 10:12:39 +0000 Received: from AMXPRD0310MB377.eurprd03.prod.outlook.com ([169.254.2.78]) by AMXPRD0310HT004.eurprd03.prod.outlook.com ([10.255.55.39]) with mapi id 14.16.0353.003; Sun, 8 Sep 2013 10:12:37 +0000 From: "Paterson, Kenny" To: Yaron Sheffer , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: AQHOrG1AVeDBKKwhJkSxbZHifQ8YWJm7r8UA Date: Sun, 8 Sep 2013 10:12:36 +0000 Message-ID: In-Reply-To: <522C3497.9020301@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.255.40.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%36694$Dn%GMAIL.COM$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-FOPE-CONNECTOR: Id%36694$Dn%IETF.ORG$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 10:12:53 -0000 Dear Yaron,=20 Thanks for sharing this draft. Some quick points of feedback: * Firstly, you asked: [[Is it possible to affect some length hiding using TLS 1.2 as specified today, i.e. without draft-pironti-tls-length-hiding-01, and using available APIs?]] The answer is "yes, to some extent, and for some cipher suites, but it does not help much against compression attacks". Expanding: variable length padding is available for CBC-mode ciphersuites in TLS 1.0 and higher (but not widely implemented). This allows an implementation to "disguise" the underlying message size to some extent, and it can be proven to be secure providing you avoid short MAC tags as in RFC 6066 (see my paper with Ristenpart and Shrimpton from Asiacrypt 2011: http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf). Such padding is not available for RC4-based ciphersuites, nor for AES-GCM, nor AES-CCM.=20 The amount of variability this feature introduces into ciphertext lengths is not sufficient to prevent CRIME/BREACH, but only slows them down a bit (I have not quantified this; that would require a more detailed analysis which is not justified given the apparent benefit). =20 * Secondly, concerning attacks on RC4: You mention the work of Isobe et al. from FSE 13 (as citation [RC4-Attack]). I've also been involved in parallel work which goes more deeply into the practical applications of RC4 weaknesses to breaking TLS and which includes more powerful attacks, making the case for abandoning RC4 even stronger: N.J. AlFardan, D.J. Bernstein, K.G. Paterson, B. Poettering and J.C.N. Schuldt. On the Security of RC4 in TLS. In USENIX Security Symposium 2013. https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls http://www.isg.rhul.ac.uk/tls * Thirdly, a technical point concerning CRIME/BREACH: You write: "The attack is a consequence of the TLS MAC-then-encrypt approach." This is incorrect. The attacks would apply equally well to AES-GCM ciphersuites (which do not adopt the MAC-then-ecnrypt approach). Regards Kennt On 08/09/2013 09:25, "Yaron Sheffer" wrote: >This is an early version of my proposal for a BCP-like document, to >inform the industry on what can be done with existing implementations, >while TLS 1.3 is still not ready. > >I would appreciate your comments of course. Specifically, >I would like to fill in the Implementation Status table (Sec. 5) and >would be glad to receive solid information (dates, planned dates, >version numbers) from implementers. > >Thanks, > Yaron > >-------- Original Message -------- >Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt >Date: Sat, 07 Sep 2013 15:46:38 -0700 >From: internet-drafts@ietf.org >To: Yaron Sheffer > > >A new version of I-D, draft-sheffer-tls-bcp-00.txt >has been successfully submitted by Yaron Sheffer and posted to the >IETF repository. > >Filename: draft-sheffer-tls-bcp >Revision: 00 >Title: Recommendations for Secure Use of TLS and DTLS >Creation date: 2013-09-08 >Group: Individual Submission >Number of pages: 8 >URL:=20 >http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt >Status: http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp >Htmlized: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 > > >Abstract: > Over the last few years there have been several serious attacks on > TLS, including attacks on its most commonly used ciphers and modes of > operation. This document offers recommendations on securely using > the TLS and DTLS protocols, given existing standards and > implementations. > >=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. > >The IETF Secretariat > > > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > > > From lists@drh-consultancy.co.uk Sun Sep 8 05:07:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01A21F9D87 for ; Sun, 8 Sep 2013 05:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G64ZBUSJGa3P for ; Sun, 8 Sep 2013 05:07:52 -0700 (PDT) Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7221F9D98 for ; Sun, 8 Sep 2013 05:07:51 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:30974 helo=[192.168.7.9]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10465) with esmtpa (authdaemon_plain:drh) id 1VIdmN-0005jO-50 for tls@ietf.org (return-path ); Sun, 08 Sep 2013 12:07:47 +0000 Message-ID: <522C6892.4020206@drh-consultancy.co.uk> Date: Sun, 08 Sep 2013 13:07:46 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <522BE808.4090405@stpeter.im> In-Reply-To: <522BE808.4090405@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 12:07:57 -0000 On 08/09/2013 03:59, Peter Saint-Andre wrote: > [old thread alert!] > > >> 2. An extension for Encrypt-then-MAC (i.e. this draft) > >> Was any consensus achieved as to the best approach? > I can add a data point to this. I spent an afternoon implementing this (i.e. the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy to do and interoped fine with the test servers. I'll make it available as an experimental feature in OpenSSL master branch. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From lists@drh-consultancy.co.uk Sun Sep 8 06:47:18 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A74E21F9FF3 for ; Sun, 8 Sep 2013 06:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZzrSK8cuJC8 for ; Sun, 8 Sep 2013 06:47:14 -0700 (PDT) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by ietfa.amsl.com (Postfix) with ESMTP id D237D21F9FE9 for ; Sun, 8 Sep 2013 06:47:13 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:64438 helo=[192.168.7.9]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10465) with esmtpa (authdaemon_plain:drh) id 1VIfKT-0006aa-FN (return-path ); Sun, 08 Sep 2013 13:47:05 +0000 Message-ID: <522C7FD8.1000301@drh-consultancy.co.uk> Date: Sun, 08 Sep 2013 14:47:04 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> In-Reply-To: <522C6892.4020206@drh-consultancy.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 13:47:18 -0000 On 08/09/2013 13:07, Dr Stephen Henson wrote: > On 08/09/2013 03:59, Peter Saint-Andre wrote: >> [old thread alert!] >> >> >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) >> >>> Was any consensus achieved as to the best approach? >> > > I can add a data point to this. I spent an afternoon implementing this (i.e. > the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy to do > and interoped fine with the test servers. > > I'll make it available as an experimental feature in OpenSSL master branch. > Well I've added this and spotted a problem. The draft extension value (0x10) clashes with the draft value used in the ALPN specification. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From n.mavrogiannopoulos@gmail.com Sun Sep 8 07:25:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5763221E8082 for ; Sun, 8 Sep 2013 07:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulTUulk+ShA1 for ; Sun, 8 Sep 2013 07:25:20 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5361D11E80D5 for ; Sun, 8 Sep 2013 07:25:20 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id n15so2603348ead.16 for ; Sun, 08 Sep 2013 07:25:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=awj0lqtqAQC3rduINpSzMEtIrxwC6jEDKdoGh8EKKLM=; b=Gr4pesXlY5XrrgOGcTZsRzTJ01u9M84lLbGshFMgWPHu3plT0FUkIpCB+4xbp3AaNo hG1yQ/fBVXpxYmtM9K85KmnoUe3F9sQyqWQVc8aW7J3WdAyZCbMMxbPpHJ6DaXgq+fR3 8Wh4/QbKI/5bJx7UM/gl2wYL+L0u7oSqrI/Fquj+NcQ/kNo0QQQnEeY0kMqvYgg+JDfN MWQyVOn8iCnS8QpZwq0ArWXwoQRUO2wPlX+TKxkmw5LR4BOf+urDg24bC7fA4K5pj59q QodjKC/HYMYLZKIP8n93XE1nEEKZpzcH3DfmJHeW+UFNGABY7+zsYGCsh3LdmLjbBVU2 vsaQ== X-Received: by 10.14.184.132 with SMTP id s4mr22405917eem.13.1378650315398; Sun, 08 Sep 2013 07:25:15 -0700 (PDT) Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id a43sm13917630eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Sep 2013 07:25:14 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <522C88D8.5030702@gnutls.org> Date: Sun, 08 Sep 2013 16:25:28 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Peter Saint-Andre References: <522BE808.4090405@stpeter.im> In-Reply-To: <522BE808.4090405@stpeter.im> X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 14:25:22 -0000 On 09/08/2013 04:59 AM, Peter Saint-Andre wrote: >> As I recall there were three proposals for resolving the padding >> bug in TLS > >> 1. An extension for Pad First (i.e. padding before an >> otherwise standard TLS mode of operation) > >> 2. An extension for Encrypt-then-MAC (i.e. this draft) > >> 3. The replacement of each existing cipher suite with an >> equivalent AEAD one > >> Was any consensus achieved as to the best approach? > > I never saw further discussion on this topic. Are there I-Ds for each > approach? #3 seems onerous to me (and doubling the number of cipher > suites doesn't seem like a desirable outcome), and as far as I can > tell there's no specification for #1. Although I am not a TLS expert, > the Encrypt-then-MAC I-D referenced above seems reasonable, it neatly > solves a real-world problem, and we have running code; thus IMHO > formalization of this approach deserves to be considered in the WG. It is important when trying to solve an issue not to introduce new issues. The current proposal for #2 unfortunately does not take into account known counter-measures for key recovery attacks in MACs (see [0]). regards, Nikos [0]. http://www.ietf.org/mail-archive/web/tls/current/msg09520.html From benl@google.com Sun Sep 8 10:57:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40FFF11E8122 for ; Sun, 8 Sep 2013 10:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 tagged_above=-999 required=5 tests=[AWL=0.457, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id At6qvpvecGsm for ; Sun, 8 Sep 2013 10:57:38 -0700 (PDT) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6479F21F9AFE for ; Sun, 8 Sep 2013 10:57:38 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id m16so8491886ieq.24 for ; Sun, 08 Sep 2013 10:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6UGunUQH6iLUPNvQ/jczQD7ZBn0xpqlsvwQcX+3wBPc=; b=lhtSQ+re6Uazz53BR8fkObXkYFOcqZi+X5GZl6jA6Q/sjRSOprSTcERj9Bp7Tml0us AAjZwR+GS8H0UiIMujuNTJHXCnPVevuDjFkKZyyPbamcI7Mv5BRKuG87Q4ZCjxrWn6Vb Vw+CcOB/TrlDcFjAay62t6seXYJRLf1qhFxBxf82UAuexNvufEVHefWEPDRa8DuKDZNx AB1gTqSaGMhHyrf08rEobQEiG1k//r8iD1a6tS2JR0BWtWMqA8PobnpEQDx29Z6P+CL6 xNenWU5RBBweeQWnQk6ZbOR9QwzQRQI2wmPvsbaUwdES/trcABu51kU3ezJM6Wmbeh+A MhJg== 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=6UGunUQH6iLUPNvQ/jczQD7ZBn0xpqlsvwQcX+3wBPc=; b=l8EzOOVHaPzqC+5JaNPSdBOJBSZEBYBLkFpw2UqWpteT/u7HrS9I1U8QKMt4NtuXtU ZErqzIPaKvnzKDljwJ9sqhQqbWG016t/YQ+OcBAJTmbCkKqIQ3Uw1ggdasyIeXfnJDQ8 LTbOvK+96WGwe93GJRz1GQ6f1wbH6Lu51LS0tC4TksywPqgZPwRC5MVLwOVKXyPYRTss e2V6usgvix3OCbQ4rcNYjckZLqRGHw3ekMb+mEglQ17tJWM7+QQs1UaT7HvDBIyTCB8+ o4IKsAeeXEJFtk9NdO/EpYFCpkeZHEhz1GpcQWioaUMnzWQ3eObFRrVrRCS0lJUhH9KC N72g== X-Gm-Message-State: ALoCoQmbIwVQbjojG8UR2JxavzcNONpQVehCPX1vHZFnuEdlfU9bCsn2sTcRkhrVKdCEv5uukZGx1HRLLZx1yYsENN4wIFyNjfL+/E3ZaVRihPXbdMmd7ZVG7Qast98bZTHlBZVal+4tg5M3tespPqdimPYwJ4ap9VoYwVFcyP6dvH0CH2ijvpb1VwxWbgJAOwxh4J03t0Be MIME-Version: 1.0 X-Received: by 10.50.25.39 with SMTP id z7mr5343984igf.59.1378663055836; Sun, 08 Sep 2013 10:57:35 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Sun, 8 Sep 2013 10:57:35 -0700 (PDT) In-Reply-To: <522C7FD8.1000301@drh-consultancy.co.uk> References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> Date: Sun, 8 Sep 2013 18:57:35 +0100 Message-ID: From: Ben Laurie To: Dr Stephen Henson Content-Type: multipart/alternative; boundary=047d7bd76898b590a304e5e301d9 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Sep 2013 17:57:39 -0000 --047d7bd76898b590a304e5e301d9 Content-Type: text/plain; charset=ISO-8859-1 On 8 September 2013 14:47, Dr Stephen Henson wrote: > On 08/09/2013 13:07, Dr Stephen Henson wrote: > > On 08/09/2013 03:59, Peter Saint-Andre wrote: > >> [old thread alert!] > >> > >> > >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) > >> > >>> Was any consensus achieved as to the best approach? > >> > > > > I can add a data point to this. I spent an afternoon implementing this > (i.e. > > the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy > to do > > and interoped fine with the test servers. > > > > I'll make it available as an experimental feature in OpenSSL master > branch. > > > > Well I've added this and spotted a problem. The draft extension value > (0x10) > clashes with the draft value used in the ALPN specification. > Given that the ALPN draft apparently has an allocated number, can we get one allocated to this I-D? --047d7bd76898b590a304e5e301d9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 8 September 2013 14:47, Dr Stephen Henson <= lists@drh-= consultancy.co.uk> wrote:
On 08/09/2013 13:07, Dr St= ephen Henson wrote:
> On 08/09/2013 03:59, Peter Saint-Andre wrote:
>> [old thread alert!]
>>
>>
>>> 2. =A0 =A0 =A0 An extension for Encrypt-then-MAC (i.e. this dr= aft)
>>
>>> Was any consensus achieved as to the best approach?
>>
>
> I can add a data point to this. I spent an afternoon implementing this= (i.e.
> the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy= to do
> and interoped fine with the test servers.
>
> I'll make it available as an experimental feature in OpenSSL maste= r branch.
>

Well I've added this and spotted a problem. The draft extension v= alue (0x10)
clashes with the draft value used in the ALPN specification.

Given that the ALPN draft apparently has an allocated= number, can we get one allocated to this I-D?

--047d7bd76898b590a304e5e301d9-- From foleyj@cisco.com Wed Aug 28 07:59:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F8921F9FE3 for ; Wed, 28 Aug 2013 07:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNn3y-u1id-p for ; Wed, 28 Aug 2013 07:59:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 342FB21F8C7C for ; Wed, 28 Aug 2013 07:59:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4190; q=dns/txt; s=iport; t=1377701976; x=1378911576; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KugghZiGq58SSviT6fuZ6mXPGtOCV1kJQrKeW5kTZPE=; b=kR+xPV29s8cKDoszfHYjOKhCTS7CVJtBYG/rdT28S/PaRd06JvcKdiln qeGDOvJaxfvZN9v6xWFpAii0FaHdYJw4YGt57/Z8I3mYhHDvd7GN5g2TJ xV/1JT6KVViQkqblTxv2L4g/cv68+XlModXkmyZTwVPB/p7cWZPbm31tp w=; X-IronPort-AV: E=Sophos;i="4.89,976,1367971200"; d="scan'208";a="252706598" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 28 Aug 2013 14:59:36 +0000 Received: from [64.102.54.158] (dhcp-64-102-54-158.cisco.com [64.102.54.158]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r7SExZZf019272; Wed, 28 Aug 2013 14:59:35 GMT Message-ID: <521E1056.5070309@cisco.com> Date: Wed, 28 Aug 2013 10:59:34 -0400 From: John Foley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: David McGrew References: <5215102B.30200@cisco.com> <1377638822.4027.228.camel@darkstar> In-Reply-To: <1377638822.4027.228.camel@darkstar> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 08 Sep 2013 17:44:58 -0700 Cc: "tls@ietf.org" , Ryan Sleevi Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 28 Aug 2013 14:59:53 -0000 Hi David, CTS is a great idea. This looks like it could be used to solve the problem. We could certainly go this route. However, thinking through the implementation details, is CTS widely deployed? I'm fairly certain OpenSSL doesn't support CTS. Is there an RFC that defines AES-CBC-CTS mode? If not, would we need to propose an IETF draft for this new mode? Thinking through both the standards process and implementation process, it might looking something like: 1) Author new draft for AES-CBC-CTS mode that coincides with NIST 800-38A? 2) Revise [draft-mcgrew-aead-aes-cbc-hmac-sha2] to include AES-CBC-CTS mode. 3) Register new AES-CBC-CTS TLS cipher suites with IANA. And moving on to implementation (e.g. OpenSSL, GNUTLS, etc.)... 4) Implement block cipher mode AES-CBC-CTS 5) Add support for the new cipher suites to TLS stack To second your final comment, what gain would come from this new AES-CBC-CTS mode for TLS? Does it achieve anything that GCM mode doesn't provide today? It's not clear to me this new mode would be providing additional value. Is this merely continued expansion of the ever increasing list of TLS cipher suites? John On 08/27/2013 05:27 PM, David McGrew wrote: > Hi John, > > On Wed, 2013-08-21 at 15:08 -0400, John Foley wrote: >> Agreed, RFC 5246 section 6.2.3.3 is written for AEAD ciphers that grow >> the payload by a fixed length. [draft-mcgrew-aead-aes-cbc-hmac-sha2] >> grows the payload by a variable length because CBC mode is used. The >> only way to use this with TLS 1.2 would be to violate the spec by >> increasing the TLSCompressed.length by the pad value prior to >> encrypting. Then when decrypting we would have the appropriate value >> for the additional data input. >> >> It seems that [draft-mcgrew-aead-aes-cbc-hmac-sha2] needs to include a >> section to revise RFC 5246, or another draft is required that revises >> 5246 to allow use of variable pad length AEAD ciphers. > another alternative would be to define a CBC based ciphersuite that uses > Cipher Text Stealing [1]. Then the plaintext and ciphertext lengths > would be off by a constant, as with the other AEAD algorithms. Now, the > existing padding method is used by the current draft because that method > is commonly implemented in CBC libraries (it dates back to early PKCS), > especially those used in JOSE. But if it is desirable, we could define > a CBC algorithm that used CTS. Since some JOSE adopters have already > implemented the current version of the draft, they may want to stick > with the current algorithm. > > David > > P.S. - or we could stop using CBC, which is something that deserves > serious discussion. > > [1] > http://csrc.nist.gov/publications/nistpubs/800-38a/addendum-to-nist_sp800-38A.pdf > >> >> >> >> On 08/21/2013 01:49 PM, Wan-Teh Chang wrote: >>> While reviewing the NSS patch for the AES-GCM TLS cipher suites, my >>> colleague Ryan Sleevi noticed that the AEAD algorithms defined in >>> draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD >>> ciphers. The problem is how TLS 1.2 specifies the additional >>> authenticated data for AEAD ciphers: >>> >>> RFC 5246 Section 6.2.3.3 says: >>> >>> The plaintext is the TLSCompressed.fragment. >>> >>> The additional authenticated data, which we denote as >>> additional_data, is defined as follows: >>> >>> additional_data = seq_num + TLSCompressed.type + >>> TLSCompressed.version + TLSCompressed.length; >>> >>> where "+" denotes concatenation. >>> >>> So additional_data includes the length of the plaintext >>> (TLSCompressed.length). But a TLS 1.2 record only gives us the length >>> of the AEAD ciphertext. So the recipient needs to calculate the >>> plaintext's length using only the ciphertext. >>> >>> This is difficult to do with the AEAD algorithms in >>> draft-mcgrew-aead-aes-cbc-hmac-sha2 because the amount of padding, and >>> therefore the plaintext length, is only known after CBC decryption. >>> >>> Is this a known problem with TLS 1.2 AEAD ciphers? >>> >>> Wan-Teh Chang >>> . >>> > > . > From lists@drh-consultancy.co.uk Sun Sep 8 18:17:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD3221E8125 for ; Sun, 8 Sep 2013 18:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON2GUh9UFY4y for ; Sun, 8 Sep 2013 18:17:24 -0700 (PDT) Received: from claranet-outbound-smtp04.uk.clara.net (claranet-outbound-smtp04.uk.clara.net [195.8.89.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA3E021E8086 for ; Sun, 8 Sep 2013 18:17:24 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:28738 helo=[192.168.7.9]) by relay04.mail.eu.clara.net (relay.clara.net [213.253.3.44]:10465) with esmtpa (authdaemon_plain:drh) id 1VIq6S-0004RF-FR for tls@ietf.org (return-path ); Mon, 09 Sep 2013 01:17:20 +0000 Message-ID: <522D21A0.2080005@drh-consultancy.co.uk> Date: Mon, 09 Sep 2013 02:17:20 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <5215102B.30200@cisco.com> <1377638822.4027.228.camel@darkstar> <521E1056.5070309@cisco.com> In-Reply-To: <521E1056.5070309@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft-mcgrew-aead-aes-cbc-hmac-sha2 can't be used as TLS 1.2 AEAD ciphers X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 01:17:25 -0000 On 28/08/2013 15:59, John Foley wrote: > > CTS is a great idea. This looks like it could be used to solve the > problem. We could certainly go this route. However, thinking through > the implementation details, is CTS widely deployed? I'm fairly certain > OpenSSL doesn't support CTS. It has support for mode operations for CTS in crypto/modes/cts128.c in development versions of OpenSSL: that's almost all of the implementation. Those can be readily converted to EVP which could be utilised in any new cipher suites. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From code@funwithsoftware.org Sun Sep 8 18:35:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6495C21E8086 for ; Sun, 8 Sep 2013 18:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4-r-2-J8lQp for ; Sun, 8 Sep 2013 18:35:02 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id DECF421E8126 for ; Sun, 8 Sep 2013 18:35:01 -0700 (PDT) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 749F91EE4F83 for ; Sun, 8 Sep 2013 21:34:55 -0400 (EDT) Received: (qmail 31267 invoked from network); 9 Sep 2013 01:34:55 -0000 Received: by simscan 1.4.0 ppid: 23081, pid: 4931, t: 2.3992s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Sep 2013 01:34:52 -0000 Message-ID: <522D25B9.7010506@funwithsoftware.org> Date: Sun, 08 Sep 2013 18:34:49 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 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 Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 01:35:07 -0000 Given the doubt that's recently been cast on the NIST curves, is it time to revive the idea of adding curve25519 as a named curve? --Patrick On 3/1/10 4:20 PM, Adam Langley wrote: > We would like to start testing EC DHE in order to give our users > forward-secrecy. > > In order to do this cheaply, one of the curves that we would like to > test with is curve25519[1]. There are several implementations of it > [2][3][4] and it's 3-4x faster than NIST's p256 (as implemented in > OpenSSL), while being constant-time. > > Curve25519 doesn't currently appear on IANA's list of named curves[5] > and we would like to see it included. > > As a first step I'd like to ask if there are any objections? > > > Cheers > > AGL > > > [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf > [2] http://cr.yp.to/ecdh.html > [3] http://code.google.com/p/curve25519-donna/ > [4] http://bench.cr.yp.to/results-dh.html > [5] http://www.iana.org/assignments/tls-parameters/ > From code@funwithsoftware.org Sun Sep 8 18:39:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AC421F99B7 for ; Sun, 8 Sep 2013 18:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Zp8R6MYmcVO for ; Sun, 8 Sep 2013 18:39:10 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5A621F8517 for ; Sun, 8 Sep 2013 18:39:10 -0700 (PDT) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 9A8241EE4FB8 for ; Sun, 8 Sep 2013 21:39:08 -0400 (EDT) Received: (qmail 503 invoked from network); 9 Sep 2013 01:39:08 -0000 Received: by simscan 1.4.0 ppid: 24876, pid: 17595, t: 1.7054s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Sep 2013 01:39:06 -0000 Message-ID: <522D26B8.80107@funwithsoftware.org> Date: Sun, 08 Sep 2013 18:39:04 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: tls@ietf.org, perpass@ietf.org References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> In-Reply-To: <522C3497.9020301@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 01:39:15 -0000 One thing which I feel is missing is recommendations on the size of Diffie-Hellman parameters. It seems generally accepted that 1024-bit Diffie-Hellman is no longer secure, and yet that's what most folks are still using. How about something along the lines of "Diffie-Hellman parameters of at least 2048 bits SHOULD be chosen"? --Patrick On 9/8/13 1:25 AM, Yaron Sheffer wrote: > This is an early version of my proposal for a BCP-like document, to > inform the industry on what can be done with existing implementations, > while TLS 1.3 is still not ready. > > I would appreciate your comments of course. Specifically, > I would like to fill in the Implementation Status table (Sec. 5) and > would be glad to receive solid information (dates, planned dates, > version numbers) from implementers. > > Thanks, > Yaron > > -------- Original Message -------- > Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt > Date: Sat, 07 Sep 2013 15:46:38 -0700 > From: internet-drafts@ietf.org > To: Yaron Sheffer > > > A new version of I-D, draft-sheffer-tls-bcp-00.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Filename: draft-sheffer-tls-bcp > Revision: 00 > Title: Recommendations for Secure Use of TLS and DTLS > Creation date: 2013-09-08 > Group: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt > Status: http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp > Htmlized: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 > > > Abstract: > Over the last few years there have been several serious attacks on > TLS, including attacks on its most commonly used ciphers and modes of > operation. This document offers recommendations on securely using > the TLS and DTLS protocols, given existing standards and > implementations. > > > > > > 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 From pgut001@cs.auckland.ac.nz Sun Sep 8 20:17:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BF21E8132; Sun, 8 Sep 2013 20:17:37 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnTx+h+4IhrN; Sun, 8 Sep 2013 20:17:31 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3C84721E8126; Sun, 8 Sep 2013 20:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378696651; x=1410232651; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=iZsUKKFcMmEzCJuM2dS/YGablXQY/riA+GFNHPOFz00=; b=jWzTNjbSPMw9RJ0q0hfPPLuMKsP4cuPN4xw4vuzk8p+wrGAaIAnAatnk Cz1HHIMLKwpeEcjnJo00osTPoN6Ox+zI1CImTHBIDP9jIkpOrOuUyPiFN 3rM3GkOK/bDLf/5pSWzNzz+KVgjN58YyOTufXWwTI94LxfLTf/rin66Kd M=; X-IronPort-AV: E=Sophos;i="4.90,866,1371038400"; d="scan'208";a="211192053" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 09 Sep 2013 15:17:28 +1200 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 9 Sep 2013 15:16:42 +1200 Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.48]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 15:16:41 +1200 From: Peter Gutmann To: "code@funwithsoftware.org" , "perpass@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: Ac6tCwDuNtvHI0CwR7yKfQrIPEIkOA== Date: Mon, 9 Sep 2013 03:16:41 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 03:17:37 -0000 Patrick Pelletier writes:=0A= =0A= >It seems generally accepted that 1024-bit Diffie-Hellman is no longer secu= re,=0A= =0A= Really? DLP !=3D factoring.=0A= =0A= >How about something along the lines of "Diffie-Hellman parameters of at le= ast=0A= >2048 bits SHOULD be chosen"?=0A= =0A= Why at least 2048 bits? What's wrong with 1280, or 1536, which will be qui= te=0A= a lot faster.=0A= =0A= Peter.=0A= From code@funwithsoftware.org Sun Sep 8 22:47:03 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3021E809F for ; Sun, 8 Sep 2013 22:47:03 -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=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXNnmAuQHgtX for ; Sun, 8 Sep 2013 22:46:51 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id E04A621F9EAD for ; Sun, 8 Sep 2013 22:46:47 -0700 (PDT) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 34D7B1EE4FC4 for ; Mon, 9 Sep 2013 01:46:44 -0400 (EDT) Received: (qmail 19651 invoked from network); 9 Sep 2013 05:46:43 -0000 Received: by simscan 1.4.0 ppid: 8977, pid: 30391, t: 1.6383s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 9 Sep 2013 05:46:42 -0000 Message-Id: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> From: Patrick Pelletier To: Peter Gutmann , perpass@ietf.org, tls@ietf.org In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> Content-Type: multipart/alternative; boundary=Apple-Mail-15-966441861 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 8 Sep 2013 22:46:40 -0700 References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> X-Mailer: Apple Mail (2.936) Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 05:47:03 -0000 --Apple-Mail-15-966441861 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote: > Patrick Pelletier writes: > >> It seems generally accepted that 1024-bit Diffie-Hellman is no >> longer secure, > > Really? DLP != factoring. I'm an engineer, not a cryptographer, and I don't claim to understand the math. But I've seen statements to that effect here, for example: http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman would fall in between a 70 and 80 bit symmetric key: +-------------+-----------+--------------+--------------+ | System | | | | | requirement | Symmetric | RSA or DH | DSA subgroup | | for attack | key size | modulus size | size | | resistance | (bits) | (bits) | (bits) | | (bits) | | | | +-------------+-----------+--------------+--------------+ | 70 | 70 | 947 | 129 | | 80 | 80 | 1228 | 148 | | 90 | 90 | 1553 | 167 | | 100 | 100 | 1926 | 186 | | 150 | 150 | 4575 | 284 | | 200 | 200 | 8719 | 383 | | 250 | 250 | 14596 | 482 | +-------------+-----------+--------------+--------------+ and other such tables come to similar conclusions. For example, ECRYPT II says a 1248-bit discrete log group only provides protection until 2015: http://www.keylength.com/en/3/ >> How about something along the lines of "Diffie-Hellman parameters >> of at least >> 2048 bits SHOULD be chosen"? > > Why at least 2048 bits? What's wrong with 1280, or 1536, which will > be quite > a lot faster. It seems like a good ballpark from looking at these tables, but I'm certainly not claiming 2048 exactly the right number. My point was merely that the draft should say something about DH group size. If 1024 is in fact good enough, then it should say that, rather than being silent on the subject. --Patrick --Apple-Mail-15-966441861 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Sep 8, 2013, at = 8:16 PM, Peter Gutmann wrote:

Patrick= Pelletier <code@funwithsoftware.org> = writes:

It seems generally accepted = that 1024-bit Diffie-Hellman is no longer = secure,

Really?  DLP !=3D = factoring.

I'm an engineer, = not a cryptographer, and I don't claim to understand the math.  But = I've seen statements to that effect here, for = example:


The IETF's own RFC 3766/BCP 86 = indicates that 1024-bit Diffie-Hellman would fall in between a 70 and 80 = bit symmetric key:

  =  +-------------+-----------+--------------+--------------+
=    | System      |         =   |              |     =          |
   | requirement = | Symmetric | RSA or DH    | DSA subgroup |
  =  | for attack  | key size  | modulus size | size   =       |
   | resistance  | = (bits)    | (bits)       | (bits)     =   |
   | (bits)      |   =         |             =  |             =  |
  =  +-------------+-----------+--------------+--------------+
=    |     70      |     70 =    |      947     |     129 =      |
   |     80   =    |     80    |     1228   =   |     148      |
  =  |     90      |     90   =  |     1553     |     167   =    |
   |    100     =  |    100    |     1926     = |     186      |
   | =    150      |    150    | =     4575     |     284     =  |
   |    200      | =    200    |     8719     | =     383      |
   |   =  250      |    250    |   =  14596     |     482     =  |
  =  +-------------+-----------+--------------+--------------+
=
and other such tables come to similar conclusions. =  For example, ECRYPT II says a 1248-bit discrete log group only = provides protection until 2015:


How about something along the lines of "Diffie-Hellman = parameters of at least
2048 = bits SHOULD be chosen"?

Why at least 2048 bits? =  What's wrong with 1280, or 1536, which will be quite
a lot = faster.

It seems like a good = ballpark from looking at these tables, but I'm certainly not claiming = 2048 exactly the right number.  My point was merely that the draft = should say something about DH group size.  If 1024 is in fact good = enough, then it should say that, rather than being silent on the = subject.

--Patrick

= --Apple-Mail-15-966441861-- From ynir@checkpoint.com Sun Sep 8 23:59:40 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B5E21E8159; Sun, 8 Sep 2013 23:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wBBMCqqD5Ve; Sun, 8 Sep 2013 23:59:28 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A7B2D21E8143; Sun, 8 Sep 2013 23:59:27 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r896x18I029156; Mon, 9 Sep 2013 09:59:01 +0300 X-CheckPoint: {522D71B5-6-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 9 Sep 2013 09:59:01 +0300 From: Yoav Nir To: Patrick Pelletier Thread-Topic: [perpass] [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: AQHOrSAT7vhu+KgFPUyyfi4xkQQkepm8x56A Date: Mon, 9 Sep 2013 06:59:01 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> In-Reply-To: <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.29] x-kse-antivirus-interceptor-info: protection disabled Content-Type: multipart/alternative; boundary="_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_" MIME-Version: 1.0 Cc: "" , "" Subject: Re: [TLS] [perpass] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 06:59:40 -0000 --_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Patrick. Those tables are mostly quoting NIST publications, so while it seems like t= here's many sources, they're not really independent. There are academic results in factoring 768-bit numbers, so with sufficient= thrust (and the NSA has more thrust than most academics), it's perfectly l= ogical to suspect that the NSA can factor 1024-bit numbers. That would be a= breakage of RSA, not D-H or DSA. There seems to be an assumption behind th= ose tables that the strength of RSA and DSA for the same bit length is abou= t equal. I don't know what this is based on, but then, IANAC. BTW: If the entire Internet was using 768-bit RSA keying and single-DES enc= ryption, then the NSA could decrypt any connection they wanted, but they wo= uld only have the resources to spy on very few people. Even if we used anon= ymous D-H for TLS, which would allow the NSA to trivially MITM any connecti= on, just having the encryption there means that the same hardware can inter= cept far fewer connections. I suspect that with enough TOR traffic scrambled hard enough that you can't= decrypt a particular one without decrypting a significant portion of the c= onnections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2048-b= it makes it harder to crack, but the TOR network is already way too slow. Yoav On Sep 9, 2013, at 8:46 AM, Patrick Pelletier > wrote: On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote: Patrick Pelletier > writes: It seems generally accepted that 1024-bit Diffie-Hellman is no longer secur= e, Really? DLP !=3D factoring. I'm an engineer, not a cryptographer, and I don't claim to understand the m= ath. But I've seen statements to that effect here, for example: http://blog.erratasec.com/2013/09/tor-is-still-dhe-1024-nsa-crackable.html The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman would= fall in between a 70 and 80 bit symmetric key: +-------------+-----------+--------------+--------------+ | System | | | | | requirement | Symmetric | RSA or DH | DSA subgroup | | for attack | key size | modulus size | size | | resistance | (bits) | (bits) | (bits) | | (bits) | | | | +-------------+-----------+--------------+--------------+ | 70 | 70 | 947 | 129 | | 80 | 80 | 1228 | 148 | | 90 | 90 | 1553 | 167 | | 100 | 100 | 1926 | 186 | | 150 | 150 | 4575 | 284 | | 200 | 200 | 8719 | 383 | | 250 | 250 | 14596 | 482 | +-------------+-----------+--------------+--------------+ and other such tables come to similar conclusions. For example, ECRYPT II = says a 1248-bit discrete log group only provides protection until 2015: http://www.keylength.com/en/3/ How about something along the lines of "Diffie-Hellman parameters of at lea= st 2048 bits SHOULD be chosen"? Why at least 2048 bits? What's wrong with 1280, or 1536, which will be qui= te a lot faster. It seems like a good ballpark from looking at these tables, but I'm certain= ly not claiming 2048 exactly the right number. My point was merely that th= e draft should say something about DH group size. If 1024 is in fact good = enough, then it should say that, rather than being silent on the subject. --Patrick _______________________________________________ perpass mailing list perpass@ietf.org https://www.ietf.org/mailman/listinfo/perpass --_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_ Content-Type: text/html; charset="us-ascii" Content-ID: <8F13BD361FD30E41A1E47BEB75AF84A6@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable Hi Patrick. 

Those tables are mostly quoting NIST publications, so while it seems l= ike there's many sources, they're not really independent. 

There are academic results in factoring 768-bit numbers, so with suffi= cient thrust (and the NSA has more thrust than most academics), it's perfec= tly logical to suspect that the NSA can factor 1024-bit numbers. That would= be a breakage of RSA, not D-H or DSA. There seems to be an assumption behind those tables that the strength= of RSA and DSA for the same bit length is about equal. I don't know what t= his is based on, but then, IANAC.

BTW: If the entire Internet was using 768-bit RSA keying and single-DE= S encryption, then the NSA could decrypt any connection they wanted, but th= ey would only have the resources to spy on very few people. Even if we used= anonymous D-H for TLS, which would allow the NSA to trivially MITM any connection, just having the encryption= there means that the same hardware can intercept far fewer connections.

I suspect that with enough TOR traffic scrambled hard enough that you = can't decrypt a particular one without decrypting a significant portion of = the connections, 1024-bit DHE is plenty strong enough. Sure, upgrading to 2= 048-bit makes it harder to crack, but the TOR network is already way too slow.

Yoav

On Sep 9, 2013, at 8:46 AM, Patrick Pelletier <code@funwithsoftware.org> wrote:

On Sep 8, 2013, at 8:16 PM, Peter Gutmann wrote:

Patrick Pelletier <code@funwithsoftware.org> writes:

It seems generally accepted that 1024-bit Diffie-= Hellman is no longer secure,

Really?  DLP !=3D factoring.

I'm an engineer, not a cryptographer, and I don't claim to understand = the math.  But I've seen statements to that effect here, for example:<= /div>


The IETF's own RFC 3766/BCP 86 indicates that 1024-bit Diffie-Hellman = would fall in between a 70 and 80 bit symmetric key:

   +-------------+-----------+--------------+= ;--------------+
   | System      |        = ;   |              |     =          |
   | requirement | Symmetric | RSA or DH    | DSA = subgroup |
   | for attack  | key size  | modulus size | size=         |
   | resistance  | (bits)    | (bits)   =     | (bits)       |
   | (bits)      |        = ;   |              |     =          |
   +-------------+-----------+--------------+= ;--------------+
   |     70      |     70=    |      947     |     129 &= nbsp;    |
   |     80      |     80=    |     1228     |     148  =    |
   |     90      |     90=    |     1553     |     167  =    |
   |    100      |    100=    |     1926     |     186  =    |
   |    150      |    150=    |     4575     |     284  =    |
   |    200      |    200=    |     8719     |     383  =    |
   |    250      |    250=    |    14596     |     482  =    |
   +-------------+-----------+--------------+= ;--------------+

and other such tables come to similar conclusions.  For example, = ECRYPT II says a 1248-bit discrete log group only provides protection until= 2015:


How about something along the lines of "Diff= ie-Hellman parameters of at least
2048 bits SHOULD be chosen"?

Why at least 2048 bits?  What's wrong with 1280, or 1536, which will b= e quite
a lot faster.

It seems like a good ballpark from looking at these tables, but I'm ce= rtainly not claiming 2048 exactly the right number.  My point was mere= ly that the draft should say something about DH group size.  If 1024 i= s in fact good enough, then it should say that, rather than being silent on the subject.

--Patrick

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

--_000_F11AE80BE1A148688C81AFF533B6E6A9checkpointcom_-- From n.mavrogiannopoulos@gmail.com Mon Sep 9 01:36:10 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D3911E8111; Mon, 9 Sep 2013 01:36:10 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL8wCbjiBaQJ; Mon, 9 Sep 2013 01:36:02 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 472F021F8793; Mon, 9 Sep 2013 01:36:02 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id b15so2978036eek.40 for ; Mon, 09 Sep 2013 01:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=f/tFwJrB6NM4OTPJNLFEPlse6lYyPkSS7CJHWmu/ai8=; b=jzy3wnnvynKji5oScJtsI7m2SsTzaqC/A58xjvO99KSfnn5YOFZ2gzI+47H1XZpy/1 qeTGvqLHb7YRYbGzFxQlkdudNZk0l1tzY3j8X+YTIQ+/BOdwOK4vcrAET2Xdam6XSBUr TdUQaL5bXzvfmu7oVRtSMECmAIHEzZtbzIxW2V0+invcuY7R8EF2HX0XIOj09zw5wr1I RI0GlpTnk6cgOUVeWNRo0ZGVSO7OjqQxKkfJaC7Td8KBPp6QOaIuMHttdpMnyOwIvR2H hNFXYwBZJ5Z6PQb5IGLbvgY/tfENYuSNVAxQxmhW4HKw05B0APRQ+fgVrPkBDrz75auh fjDA== X-Received: by 10.15.43.13 with SMTP id w13mr28300641eev.37.1378715760818; Mon, 09 Sep 2013 01:36:00 -0700 (PDT) Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id y47sm19955816eew.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 01:36:00 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <522D886F.4040903@gnutls.org> Date: Mon, 09 Sep 2013 10:35:59 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Yoav Nir References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <7CBBDAB6-15FF-4EB8-B1D0-CE96B3F8002F@funwithsoftware.org> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , Patrick Pelletier , "" Subject: Re: [TLS] [perpass] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 08:36:10 -0000 On 09/09/2013 08:59 AM, Yoav Nir wrote: > Those tables are mostly quoting NIST publications, so while it seems > like there's many sources, they're not really independent. There are > academic results in factoring 768-bit numbers, so with sufficient > thrust (and the NSA has more thrust than most academics), it's > perfectly logical to suspect that the NSA can factor 1024-bit > numbers. That would be a breakage of RSA, not D-H or DSA. Hello, While I am not in par with the advances in solving the DLOG problem, the ECRYPT 2010 report on key sizes mentions in section 6.1: "According to the state of the art the difficulty of solving DLOG in prime order fields of size 2^n is, up to constants, asymptotically equivalent to that of breaking n-bit RSA". Given that all reports on key sizes agree on that (ECRYPT is not related to NIST in any way), I wouldn't ignore these recommendations. regards, Nikos From stebila@qut.edu.au Mon Sep 9 04:12:50 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907E621E8187 for ; Mon, 9 Sep 2013 04:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU2N0z2VCbQ0 for ; Mon, 9 Sep 2013 04:12:38 -0700 (PDT) Received: from qutexedge02.qut.edu.au (qutexedge02.qut.edu.au [131.181.191.3]) by ietfa.amsl.com (Postfix) with ESMTP id 30B4A21E80F5 for ; Mon, 9 Sep 2013 04:12:22 -0700 (PDT) Received: from qutexhub01.qut.edu.au (131.181.107.106) by qutexedge02.qut.edu.au (131.181.191.3) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 9 Sep 2013 21:12:18 +1000 Received: from QUTEXMBX01.qut.edu.au ([131.181.107.108]) by qutexhub01.qut.edu.au ([131.181.107.106]) with mapi; Mon, 9 Sep 2013 21:12:21 +1000 From: Douglas Stebila To: Patrick Pelletier Date: Mon, 9 Sep 2013 21:12:19 +1000 Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry Thread-Index: Ac6tTXNjhVCfgpLOSCWVFeTvERexzw== Message-ID: <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> References: <522D25B9.7010506@funwithsoftware.org> In-Reply-To: <522D25B9.7010506@funwithsoftware.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:12:50 -0000 Recent news has highlighted doubts on a particular elliptic curve-based pse= udorandom number generation algorithm, Dual_EC_DRBG, in which a particular = point is used for which no explanation is given on how the point was genera= ted. If it was generated so that its discrete logarithm is known with respe= ct to another point, then a backdoor exists that can recover the seed. (ht= tp://rump2007.cr.yp.to/15-shumow.pdf) The NIST-standardized elliptic curves p256/p384/p512 are not related to thi= s particular issue.=20 - The prime p for each field has a special form chosen for efficiency (http= ://cacr.uwaterloo.ca/techreports/1999/corr99-39.pdf), not entirely unlike h= ow the prime 2^155-19 was chosen for efficiency in curve25519. There are n= o results that suggest that one prime is weaker than another prime for elli= ptic curve cryptography. - The curve parameters were generated "verifiably at random", meaning a see= d was chosen, and then the curve parameters a and b were generated by hashi= ng the seed a pre-determined number of times using SHA-1. (Appendix 4 ofht= tp://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, or Sectio= n 3.1.3.1 of SEC1 http://secg.org, or ANSI X9.62) =20 - I don't think it's specified how the generator was chosen, but the Diffie= -Hellman problem is self-reducible, so there are no weak generators. There are other reasons to support curve25519, including efficiency and res= istance to side-channel attacks because constant-time implementations. But= not because of concerns over backdoors in p256/p384/p512. Douglas On 2013-09-09, at 11:34 AM, Patrick Pelletier wr= ote: > Given the doubt that's recently been cast on the NIST curves, is it time = to revive the idea of adding curve25519 as a named curve? >=20 > --Patrick >=20 >=20 > On 3/1/10 4:20 PM, Adam Langley wrote: >> We would like to start testing EC DHE in order to give our users >> forward-secrecy. >>=20 >> In order to do this cheaply, one of the curves that we would like to >> test with is curve25519[1]. There are several implementations of it >> [2][3][4] and it's 3-4x faster than NIST's p256 (as implemented in >> OpenSSL), while being constant-time. >>=20 >> Curve25519 doesn't currently appear on IANA's list of named curves[5] >> and we would like to see it included. >>=20 >> As a first step I'd like to ask if there are any objections? >>=20 >>=20 >> Cheers >>=20 >> AGL >>=20 >>=20 >> [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf >> [2] http://cr.yp.to/ecdh.html >> [3] http://code.google.com/p/curve25519-donna/ >> [4] http://bench.cr.yp.to/results-dh.html >> [5] http://www.iana.org/assignments/tls-parameters/ From ekr@rtfm.com Mon Sep 9 06:05:08 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EE521E8192 for ; Mon, 9 Sep 2013 06:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SSHMzC3swkT4 for ; Mon, 9 Sep 2013 06:04:56 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8816821E81BB for ; Mon, 9 Sep 2013 06:01:43 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id ii20so135797qab.13 for ; Mon, 09 Sep 2013 06:01: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=MwDW+ROmCDPajDOMjLIu+jTGI3r2GsPnhAA4CjGR69M=; b=JIh6OAC3m0ntC2hRqSOxdGozlIJeRya/JxLBdu7Glyfl1/7UMJ85pSOL6mC9d2PO1l InMEAywCQ1o7DLXGOkaUU5IVVWgHVYnPK3E6MnQ8kUQcJREw5QgJ4QxWaLfiWLdJwlCl Dbkx9aopT46KQmJHXZEwVAv4QtuCCG5+Ru7KZm1rMX81wce86xwyJ6867gP0/RogiAZ9 HNVvTWVvVZMNq0jX3imYbG2U7QEeyCS3oX0wuKTGYXy28weyZuygUjcw1HpW0OL9XkQE enbvufNoIMFqhKbaVTbA0nZ/Sw8551dFFb89J0Ojpk6tMgT8z8CKXrSCY39m5FQP3Ya2 +zug== X-Gm-Message-State: ALoCoQmT8jCAX2h0rfggLcTdl8c5+3R3qEgTgUvSL1vYoV25k2HaLzLPQ+GxV7GzJ2m4/uzNPrvt X-Received: by 10.49.130.233 with SMTP id oh9mr24733677qeb.10.1378731702901; Mon, 09 Sep 2013 06:01:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.42.68 with HTTP; Mon, 9 Sep 2013 06:01:02 -0700 (PDT) X-Originating-IP: [74.95.2.168] In-Reply-To: References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> From: Eric Rescorla Date: Mon, 9 Sep 2013 06:01:02 -0700 Message-ID: To: Ben Laurie Content-Type: multipart/alternative; boundary=047d7bb03fa664707104e5f2fda2 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 13:05:08 -0000 --047d7bb03fa664707104e5f2fda2 Content-Type: text/plain; charset=ISO-8859-1 Ben, Generally, we're not doing advance code point assignments for documents that haven't been accepted by the TLS WG. Of course, this naturally raises the question of whether this document will be accepted by the TLS WG. However, as I think recent discussion indicates, there are a number of proposed approaches and there isn't really consensus to adopt this particular one (especially in view of the increased adoption of existing mechanisms such as GCM). If someone (Peter? You?) wants agenda time to argue for this particular approach instead of others, we're happy to have the discussion in YVR. This of course also applies to proponents of other approaches. Best, -Ekr [As Chair] On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie wrote: > > > > On 8 September 2013 14:47, Dr Stephen Henson wrote: > >> On 08/09/2013 13:07, Dr Stephen Henson wrote: >> > On 08/09/2013 03:59, Peter Saint-Andre wrote: >> >> [old thread alert!] >> >> >> >> >> >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) >> >> >> >>> Was any consensus achieved as to the best approach? >> >> >> > >> > I can add a data point to this. I spent an afternoon implementing this >> (i.e. >> > the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy >> to do >> > and interoped fine with the test servers. >> > >> > I'll make it available as an experimental feature in OpenSSL master >> branch. >> > >> >> Well I've added this and spotted a problem. The draft extension value >> (0x10) >> clashes with the draft value used in the ALPN specification. >> > > Given that the ALPN draft apparently has an allocated number, can we get > one allocated to this I-D? > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7bb03fa664707104e5f2fda2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ben,

Generally, we're not doing advance co= de point assignments for documents
that haven't been accepted= by the TLS WG.

Of course, this naturally raises the question of whethe= r this document will
be accepted by the TLS WG. However, as I thi= nk recent discussion indicates,
there are a number of proposed ap= proaches and there isn't really consensus
to adopt this particular one (especially in view of the increased adop= tion of existing
mechanisms such as GCM).=A0If someone (Peter? Yo= u?) wants agenda time
to argue for this particular approach inste= ad of others, we're happy to have the
discussion in YVR. This of course also applies to proponents of other = approaches.

Best,
-Ekr

[As Chair]



On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie <benl@go= ogle.com> wrote:



On 8 September 2013 14:47, Dr S= tephen Henson <lists@drh-consultancy.co.uk> wrote:=
On 08/09/2013 13:07, Dr Stephen Henson = wrote:
> On 08/09/2013 03:59, Peter Saint-Andre wrote:
>> [old thread alert!]
>>
>>
>>> 2. =A0 =A0 =A0 An extension for Encrypt-then-MAC (i.e. this dr= aft)
>>
>>> Was any consensus achieved as to the best approach?
>>
>
> I can add a data point to this. I spent an afternoon implementing this= (i.e.
> the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy= to do
> and interoped fine with the test servers.
>
> I'll make it available as an experimental feature in OpenSSL maste= r branch.
>

Well I've added this and spotted a problem. The draft extension v= alue (0x10)
clashes with the draft value used in the ALPN specification.

Given that the ALPN draft apparently has an all= ocated number, can we get one allocated to this I-D?


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


--047d7bb03fa664707104e5f2fda2-- From alfredo@pironti.eu Mon Sep 9 06:15:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E98921E81A9 for ; Mon, 9 Sep 2013 06:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MytOWV8340IH for ; Mon, 9 Sep 2013 06:15:46 -0700 (PDT) Received: from mail-oa0-x229.google.com (mail-oa0-x229.google.com [IPv6:2607:f8b0:4003:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id C248421E81AD for ; Mon, 9 Sep 2013 06:15:42 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id j6so6492314oag.14 for ; Mon, 09 Sep 2013 06:15:41 -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=LJuPVLffuMpIBkCRdGV87LClyGEtPX5/Q4z5tHDyOsM=; b=KZ2IFRfXq1L/SWriGLQuYDg0Aqq6ba1gtcYYeZtSKGT8EJMTWJDy4HaDXDEv8MoTlu Pis2T9AHXRcp6LSMwVWop0pR31BjTHKxt/EAPFOte7G9+h2USjbx3SDzvOO0T/C8GpC6 oA5C7ODgXGsmt9JPKOtxcaNYkAJwWarOSZr5I= 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=LJuPVLffuMpIBkCRdGV87LClyGEtPX5/Q4z5tHDyOsM=; b=GWX0CGb6GHc/k+gaNe9iLOSbcUesvepr2DQEnjFag9hAT/CQnGL2IpxlNG+TtcmZ3A ydSSMHjBB/PlURv3skIgY4qnWNpjxotSD7VbjcmuNlAJ/cizvqStnDFuje8y43VCBfMN 1LzJWHR1Gghk1e/f986nvJCWj2zxYUWyalbMbtaGhB1Ed4wSo801EIgbbbqHaSkRonbO LEwayo5YNupx7HU0fkvuXM0WnVH3ugEZZCq2XpyBkA6iuOyX9IOm5lpsySBMdaiqQgTU Nnte6m5xEsUzFa/NCB4b4KrxpJrAIWcL/JJkDYq5B5+SFFQeiMXxbTgtPpdOlVc6N3Kv kZSw== X-Gm-Message-State: ALoCoQl7BpnRhHCYsWQ4xnnObG8f2VTZvl4at478VejJkUgCnn3nCFqC/eSr/K0W1TFg9YcnsKAz MIME-Version: 1.0 X-Received: by 10.60.78.227 with SMTP id e3mr11107920oex.5.1378732541617; Mon, 09 Sep 2013 06:15:41 -0700 (PDT) Received: by 10.76.80.201 with HTTP; Mon, 9 Sep 2013 06:15:41 -0700 (PDT) X-Originating-IP: [128.93.188.195] In-Reply-To: <522BE808.4090405@stpeter.im> References: <522BE808.4090405@stpeter.im> Date: Mon, 9 Sep 2013 15:15:41 +0200 Message-ID: From: Alfredo Pironti To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 13:15:58 -0000 On Sun, Sep 8, 2013 at 4:59 AM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [old thread alert!] > > On 7/1/13 3:02 AM, Lewis, Nick wrote: >>> While people are looking at that, there's also the >>> encrypt-then-MAC draft, >>> http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-03.txt, >>> >>> > which has been stable for about as long, has already been deployed by >>> several vendors, and for which TLS extension 0x10 has been de >>> facto claimed, so it'd be good to get this published to >>> legitimise the use (and to document what's already being deployed >>> in production). >> >> As I recall there were three proposals for resolving the padding >> bug in TLS >> >> 1. An extension for Pad First (i.e. padding before an >> otherwise standard TLS mode of operation) >> >> 2. An extension for Encrypt-then-MAC (i.e. this draft) >> >> 3. The replacement of each existing cipher suite with an >> equivalent AEAD one >> >> Was any consensus achieved as to the best approach? > > I never saw further discussion on this topic. Are there I-Ds for each > approach? #3 seems onerous to me (and doubling the number of cipher > suites doesn't seem like a desirable outcome), and as far as I can > tell there's no specification for #1. Approach #1 is defined in http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 and we have a couple of implementations for it. The main purpose of the I-D is to provide means to conceal the payload length within TLS fragments; however, a valuable byproduct is to also eliminate the recent padding oracle attacks. The I-D applies to all currently defined ciphers (block, stream, and AEAD). I'd like to hear your comments about it. Best, Alfredo From benl@google.com Mon Sep 9 06:31:30 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F5811E81CF for ; Mon, 9 Sep 2013 06:31: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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HawQatp7Rf2X for ; Mon, 9 Sep 2013 06:31:22 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 744F211E81B6 for ; Mon, 9 Sep 2013 06:31:12 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so2314412ieb.37 for ; Mon, 09 Sep 2013 06:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IgutiD1g5f3Gh/clyIELCleSc6pUwCMc1gZdcA8qovo=; b=h/jsTetsH92KfYes+CLV+QF4y+DSgvnqUOIXldFUUUbbaoRmeRWnEX44sxgSukz19k +L5F7zHyR1wB+JZhBP5qVewOKng+ipmBhR8YCs+j1sXgWcZrh76wUTPwzbd+H/0L5c+7 /nh6nKaWKfDrLeIXbHsrjhCAA+BhAzkzjeCOAGOid/XamaJlbuam/jfGQZWB8ti5+UI+ 37KKq4JgDPKFHRkJwURjOZMzU8QFQBZ6en7dC63/jhPpA3x32oUzpyvF2L1FPhtAkS+p QbD9qcAWk6VZBZEp5cZ6eEaYxQ3VRbjvr1iZWLsOOpXbDrfT27dqqj2I/fFtNajvLI2c FCzg== 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=IgutiD1g5f3Gh/clyIELCleSc6pUwCMc1gZdcA8qovo=; b=mPBk9Y3Lp0UKSqMypZ2t3Y2Vzkg0X8XNsYiDECMhEh/1fkC5cx7GNmIetOMnW3REyC hfgTeDpLX8dRcaYorQV+DUbwNWWcx/93Az3a5CGwSOs3staWCpXN5ybpPZ4zOpAewURH wLifY1L3GvK9XpI9zeSctQLpqvczwL4cEt5oNnTfYEhXVqUDwBwpBq9rfFCiFbqeiOeD XVE6HAPUznJmapI1OmUiX2EtBZqgX3wT4x6aTv3xFApmSLQ25yJ7jWfgoTkhbcy8iiuF 5B7iWFEeUwefKd5aZRqycaFv4UG1hGZe8kUvWP3Hb7lB8f8Lwzv6TJ+WtE9wtiF2mujh /hkg== X-Gm-Message-State: ALoCoQmH3uLeQDB1E+F9h10iDc//2G0Y2Vgcc0RRlOMcdwoViR5OiOBEs1KCczw0yCTJlzi/L4fVTI1RpVrrkX++xQPnBnoCtvVRWp3s+z9TlsqlCbj11sAFHY0ZSU2lvTO+Z4haEuTBgMIaAhj0Yp7GCE/0ZO8u/B3T0LMz+4dURutELY4FrFCrM3WhY6RBonSN7PZUVfIq MIME-Version: 1.0 X-Received: by 10.50.108.71 with SMTP id hi7mr7836259igb.59.1378733470703; Mon, 09 Sep 2013 06:31:10 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Mon, 9 Sep 2013 06:31:10 -0700 (PDT) In-Reply-To: References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> Date: Mon, 9 Sep 2013 14:31:10 +0100 Message-ID: From: Ben Laurie To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0149c4a0c310ed04e5f366ce Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 13:31:30 -0000 --089e0149c4a0c310ed04e5f366ce Content-Type: text/plain; charset=ISO-8859-1 On 9 September 2013 14:01, Eric Rescorla wrote: > Ben, > > Generally, we're not doing advance code point assignments for documents > that haven't been accepted by the TLS WG. > > Of course, this naturally raises the question of whether this document will > be accepted by the TLS WG. However, as I think recent discussion indicates, > there are a number of proposed approaches and there isn't really consensus > to adopt this particular one (especially in view of the increased adoption > of existing > mechanisms such as GCM). If someone (Peter? You?) wants agenda time > to argue for this particular approach instead of others, we're happy to > have the > discussion in YVR. This of course also applies to proponents of other > approaches. > I'm not planning to be at YVR, what happened to using the mailing list for discussion? So, in favour of the WG adoption this I-D: 1. Nothing in this I-D prevents the adoption of other approaches. 2. If fixes the problem for all versions of TLS and SSLv3. 3. I've seen no objection that makes any sense. One objection I have seen was that it "may not protect from key-recovery in a weak MAC construction" - firstly, I am not aware of any such constructions in use in SSL/TLS, and secondly, if there are any, it would be trivial to deprecate their use in conjunction with this extension. How about we take a vote? Note, BTW, that unless convinced otherwise, we intend to implement this in OpenSSL (it went into master yesterday), so you can consider that a vote in favour :-) > Best, > -Ekr > > [As Chair] > > > > On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie wrote: > >> >> >> >> On 8 September 2013 14:47, Dr Stephen Henson > > wrote: >> >>> On 08/09/2013 13:07, Dr Stephen Henson wrote: >>> > On 08/09/2013 03:59, Peter Saint-Andre wrote: >>> >> [old thread alert!] >>> >> >>> >> >>> >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) >>> >> >>> >>> Was any consensus achieved as to the best approach? >>> >> >>> > >>> > I can add a data point to this. I spent an afternoon implementing this >>> (i.e. >>> > the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy >>> to do >>> > and interoped fine with the test servers. >>> > >>> > I'll make it available as an experimental feature in OpenSSL master >>> branch. >>> > >>> >>> Well I've added this and spotted a problem. The draft extension value >>> (0x10) >>> clashes with the draft value used in the ALPN specification. >>> >> >> Given that the ALPN draft apparently has an allocated number, can we get >> one allocated to this I-D? >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --089e0149c4a0c310ed04e5f366ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 9 September 2013 14:01, Eric Rescorla <ekr@rtfm.com> w= rote:
Ben,

Generally, we're not doing advance code poi= nt assignments for documents
that haven't been accepted by th= e TLS WG.

Of course, this naturally raises the question of whethe= r this document will
be accepted by the TLS WG. However, as I thi= nk recent discussion indicates,
there are a number of proposed ap= proaches and there isn't really consensus
to adopt this particular one (especially in view of the increased adop= tion of existing
mechanisms such as GCM).=A0If someone (Peter? Yo= u?) wants agenda time
to argue for this particular approach inste= ad of others, we're happy to have the
discussion in YVR. This of course also applies to proponents of other = approaches.

I'm= not planning to be at YVR, what happened to using the mailing list for dis= cussion?

So, in favour of the WG adoption this I-D:
1. Nothing in this I-D prevents the adoption of other approach= es.

2. If fixes the problem for all versions of TL= S and SSLv3.

3. I've seen no objection that makes any sense. One= objection I have seen was that it "may not protect from key-recovery in a weak MAC constru= ction" - firstly, I am not aware of any such constructions in use in S= SL/TLS, and secondly, if there are any, it would be trivial to deprecate th= eir use in conjunction with this extension.

How about we ta= ke a vote?

Note, BTW, that unless convinced otherwise, we intend to implement this= in OpenSSL (it went into master yesterday), so you can consider that a vot= e in favour :-)


Best,
-Ekr

[As Chair]



On Sun, Sep 8, 2013 at 10:57= AM, Ben Laurie <benl@google.com> wrote:



On 8 September 2013 14:47, Dr Steph= en Henson <lists@drh-consultancy.co.uk> wrote:
On 08/09/2013 13:07, Dr Stephen Henson wrote:
> On 08/09/2013 03:59, Peter Saint-Andre wrote:
>> [old thread alert!]
>>
>>
>>> 2. =A0 =A0 =A0 An extension for Encrypt-then-MAC (i.e. this dr= aft)
>>
>>> Was any consensus achieved as to the best approach?
>>
>
> I can add a data point to this. I spent an afternoon implementing this= (i.e.
> the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy= to do
> and interoped fine with the test servers.
>
> I'll make it available as an experimental feature in OpenSSL maste= r branch.
>

Well I've added this and spotted a problem. The draft extension v= alue (0x10)
clashes with the draft value used in the ALPN specification.

Given that the ALPN draft apparently has an all= ocated number, can we get one allocated to this I-D?


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



--089e0149c4a0c310ed04e5f366ce-- From yaronf.ietf@gmail.com Mon Sep 9 07:17:06 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D399F11E81B2 for ; Mon, 9 Sep 2013 07:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tj2puf7DTJ3p for ; Mon, 9 Sep 2013 07:16:58 -0700 (PDT) Received: from mail-bk0-x22e.google.com (mail-bk0-x22e.google.com [IPv6:2a00:1450:4008:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id C719821F9AC1 for ; Mon, 9 Sep 2013 07:10:56 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id 6so2304444bkj.19 for ; Mon, 09 Sep 2013 07:10:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kVpGsS4R8rqIrzftBblEZpxZ1tAIigktvuFxMxyKKVk=; b=uvMx0oM8EB9tWEy+YplI8idagYeyYW0wuI2gFqdKsHBe+cSdRE3qQLfNkg81utaGO5 nZYD8FOQakbpcl5tx1GnG5gwkTW5cH2VJ3kbfBuMI3gMEYk8CKggkkwsxaLEW41OC01O HK6QkZ4XUGiz9bEpNwj8wmVtrKfr51ntEgy/nsJtQSgmEdiuXf1caqsynKXn6Kmajw8J 7+EfzQtHqPuyHQLumUFncZEj9xfkfk2wFoSlOFMPVzAfqlDqBVRqxdP1VfCx9SUOzCer iIpiK4wSAMQveehIep7it0fmibognGdn5i0E7IrKzX+ZFMx18g6EFBLf9SGU+zTeBMYq vBgw== X-Received: by 10.204.76.203 with SMTP id d11mr14750358bkk.3.1378735855901; Mon, 09 Sep 2013 07:10:55 -0700 (PDT) Received: from [10.0.0.139] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id 14sm3249045bkl.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 07:10:55 -0700 (PDT) Message-ID: <522DD6ED.7000000@gmail.com> Date: Mon, 09 Sep 2013 17:10:53 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Eric Rescorla References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:17:07 -0000 Hi Eric, I don't see draft-sheffer-tls-bcp as competing with this approach. I see the BCP as an interim solution that allows users to improves their security posture today, while the WG works on TLS 1.3 and/or on extensions that enable us to go back to a wide selection of available ciphersuites. Thanks, Yaron On 09/09/2013 04:01 PM, Eric Rescorla wrote: > Ben, > > Generally, we're not doing advance code point assignments for documents > that haven't been accepted by the TLS WG. > > Of course, this naturally raises the question of whether this document will > be accepted by the TLS WG. However, as I think recent discussion indicates, > there are a number of proposed approaches and there isn't really consensus > to adopt this particular one (especially in view of the increased > adoption of existing > mechanisms such as GCM). If someone (Peter? You?) wants agenda time > to argue for this particular approach instead of others, we're happy to > have the > discussion in YVR. This of course also applies to proponents of other > approaches. > > Best, > -Ekr > > [As Chair] > > > > On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie > wrote: > > > > > On 8 September 2013 14:47, Dr Stephen Henson > > > wrote: > > On 08/09/2013 13:07, Dr Stephen Henson wrote: > > On 08/09/2013 03:59, Peter Saint-Andre wrote: > >> [old thread alert!] > >> > >> > >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) > >> > >>> Was any consensus achieved as to the best approach? > >> > > > > I can add a data point to this. I spent an afternoon > implementing this (i.e. > > the encrypt then mac draft) a while ago in OpenSSL. It was > pretty easy to do > > and interoped fine with the test servers. > > > > I'll make it available as an experimental feature in OpenSSL > master branch. > > > > Well I've added this and spotted a problem. The draft extension > value (0x10) > clashes with the draft value used in the ALPN specification. > > > Given that the ALPN draft apparently has an allocated number, can we > get one allocated to this I-D? > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From Kenny.Paterson@rhul.ac.uk Mon Sep 9 07:17:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A37021E820A for ; Mon, 9 Sep 2013 07:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6dbM0ATwGND for ; Mon, 9 Sep 2013 07:17:31 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 88B2511E81D1 for ; Mon, 9 Sep 2013 07:11:38 -0700 (PDT) Received: from mail29-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE002.bigfish.com (10.236.130.65) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 14:11:29 +0000 Received: from mail29-co9 (localhost [127.0.0.1]) by mail29-co9-R.bigfish.com (Postfix) with ESMTP id 7FB611A017B for ; Mon, 9 Sep 2013 14:11:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:134.219.208.108; KIP:(null); UIP:(null); IPV:NLI; H:EXCH-HUB02.cc.rhul.local; RD:exch-hub02.rhul.ac.uk; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zzbb2dI98dI154cP9371I1432Idb82hzz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah1de097h186068h5eeeK8275bh8275dhz2dh2a8h683h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh1155h) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.248.133; KIP:(null); UIP:(null); (null); H:AMXPRD0310HT003.eurprd03.prod.outlook.com; R:internal; EFV:INT Received: from mail29-co9 (localhost.localdomain [127.0.0.1]) by mail29-co9 (MessageSwitch) id 1378735827149689_12016; Mon, 9 Sep 2013 14:10:27 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.231]) by mail29-co9.bigfish.com (Postfix) with ESMTP id 20D59320059 for ; Mon, 9 Sep 2013 14:10:27 +0000 (UTC) Received: from EXCH-HUB02.cc.rhul.local (134.219.208.108) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 14:10:26 +0000 Received: from CO9EHSOBE038.bigfish.com (134.219.208.67) by hybrid.rhul.ac.uk (134.219.208.108) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 9 Sep 2013 15:10:24 +0100 Received: from mail162-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Mon, 9 Sep 2013 14:10:23 +0000 Received: from mail162-co9 (localhost [127.0.0.1]) by mail162-co9-R.bigfish.com (Postfix) with ESMTP id DF7A8120094 for ; Mon, 9 Sep 2013 14:10:22 +0000 (UTC) Received: from mail162-co9 (localhost.localdomain [127.0.0.1]) by mail162-co9 (MessageSwitch) id 1378735820188557_19224; Mon, 9 Sep 2013 14:10:20 +0000 (UTC) Received: from CO9EHSMHS025.bigfish.com (unknown [10.236.132.250]) by mail162-co9.bigfish.com (Postfix) with ESMTP id 296ACE00AB; Mon, 9 Sep 2013 14:10:20 +0000 (UTC) Received: from AMXPRD0310HT003.eurprd03.prod.outlook.com (157.56.248.133) by CO9EHSMHS025.bigfish.com (10.236.130.35) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 9 Sep 2013 14:10:20 +0000 Received: from AMXPRD0310MB377.eurprd03.prod.outlook.com ([169.254.2.78]) by AMXPRD0310HT003.eurprd03.prod.outlook.com ([10.255.55.38]) with mapi id 14.16.0353.003; Mon, 9 Sep 2013 14:10:19 +0000 From: "Paterson, Kenny" To: Alfredo Pironti , Peter Saint-Andre Thread-Topic: [TLS] padding bug (was: Re: Requesting feedback on TACK draft) Thread-Index: AQHOrV7JqCYZI8YfRkeamC+FHpvRkpm9gp+A Date: Mon, 9 Sep 2013 14:10:18 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.255.40.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%36694$Dn%PIRONTI.EU$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-FOPE-CONNECTOR: Id%36694$Dn%STPETER.IM$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-FOPE-CONNECTOR: Id%36694$Dn%IETF.ORG$RO%2$TLS%5$FQDN%hybrid.rhul.ac.uk$TlsDn%hybrid.rhul.ac.uk X-OriginatorOrg: rhul.ac.uk X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:17:44 -0000 On 09/09/2013 14:15, "Alfredo Pironti" wrote: >On Sun, Sep 8, 2013 at 4:59 AM, Peter Saint-Andre >wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> [old thread alert!] >> >> On 7/1/13 3:02 AM, Lewis, Nick wrote: >>>> While people are looking at that, there's also the >>>> encrypt-then-MAC draft, >>>>=20 >>>>http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac- >>>>03.txt, >>>> >>>> >> which has been stable for about as long, has already been deployed by >>>> several vendors, and for which TLS extension 0x10 has been de >>>> facto claimed, so it'd be good to get this published to >>>> legitimise the use (and to document what's already being deployed >>>> in production). >>> >>> As I recall there were three proposals for resolving the padding >>> bug in TLS >>> >>> 1. An extension for Pad First (i.e. padding before an >>> otherwise standard TLS mode of operation) >>> >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) >>> >>> 3. The replacement of each existing cipher suite with an >>> equivalent AEAD one >>> >>> Was any consensus achieved as to the best approach? >> >> I never saw further discussion on this topic. Are there I-Ds for each >> approach? #3 seems onerous to me (and doubling the number of cipher >> suites doesn't seem like a desirable outcome), and as far as I can >> tell there's no specification for #1. > >Approach #1 is defined in >http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01 and we >have a couple of implementations for it. The main purpose of the I-D >is to provide means to conceal the payload length within TLS >fragments; however, a valuable byproduct is to also eliminate the >recent padding oracle attacks. The I-D applies to all currently >defined ciphers (block, stream, and AEAD). I'd like to hear your >comments about it. Two comments, one on Approach #1, the other on Approach #2: 1. There is some formal support for the "Pad-then-encrypt-then-MAC" approach being used in the above Approach #1 in the following paper: Kenneth G. Paterson and Gaven J. Watson Authenticated-Encryption with Padding: A Formal Security Treatment Cryptography and Security: From Theory to Applications Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107. http://link.springer.com/book/10.1007/978-3-642-28368-0 See in particular, Theorem 8 in the paper. Unfortunately, this paper is behind Springer's paywall. For those on the list without access, you can access the same content in Chapter 5 (Theorem 5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here: http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf 2. Approach #2 is well supported by theory and is more cryptographically robust (in the face of bad implementations), provided the involved MAC algorithm is strong enough. I briefly reviewed the literature for the state-of-the-art on attacks against HMAC-H for hash algorithm "H". (See for example http://www.di.ens.fr/~fouque/pub/crypto07b.pdf, and later papers by L. Wang et al. at Eurocrypt 2008, by X. Wang et al. at Eurocrypt 2009, plus more recent work, e.g. Peyrin et al. at Asiacrypt 2012.) In TLS, we essentially have H =3D MD5, SHA-1 or SHA-256. In view of the literature, of these, I'd recommend deprecating MD5 as the hash if Approach #2 were to be adopted: current attacks do not seriously threaten it, but taking a fairly conservative approach seems appropriate here. Best wishes, Kenny From benl@google.com Mon Sep 9 07:30:24 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F7C21F9D0C for ; Mon, 9 Sep 2013 07:30: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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmqFP5FREnnp for ; Mon, 9 Sep 2013 07:30:13 -0700 (PDT) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 763F421E81C8 for ; Mon, 9 Sep 2013 07:19:34 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id to1so2480042ieb.37 for ; Mon, 09 Sep 2013 07:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=odEObAgFk4uyAAnD5T3+NEYvceWp+CFvUjdlRkQsF0U=; b=W6eGchWTTyproqdIE3JKawYSFeThkmI0VjbrUjeU+XSHfidMRlH00JEWbukZ7ZGRjU g0ogrdJrzVAO443lAvdSYDlMqgzpdgoi6NFL89f8uGQEMqqnIMlzIf38gh4nEYdgWBuo nAuqs1j2bCqAFHIfrlYzhokvLQK2zo0vr2FJViFvBgroB/mB9tTuCPP68/hKguxcCcVr jON/cZiIJN5kOqGZA3ujdyxr5hsSA7h5JJsF0j+c8f9Tzwx0+te7HSYPtiQxlGL+7QwQ T/W8Cg4z0vFBwmAE69YyTrFCKRpvgY5zLWJ2mnY5ACG5/MsYKygnjWHZl8eTXt0Ukz/Y Z7bg== 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=odEObAgFk4uyAAnD5T3+NEYvceWp+CFvUjdlRkQsF0U=; b=m7rH0sIUnQHDyN6iyDY9qciEoIAuA2hOrF7OPwJ2IF+3ucoNFtXep6sjC2bYwpqzey RHZ/YRhBvphC60Hvhedw9NOTqxTwpAK2GVmwhldu0QuDwwi+GLv6hfDy4d8svHk2nRCQ VKEXVZH1jwVjfRPP1J17ZoAd4/1xyrwVMGGa0WL6oAgXOH3Vyk3RCOLl7OZLUUGo33Hz +8SV+Jz/D+3bAeRDONZC7wyn3DqGwS7DqeGVvsM84gjL2Ga9lfj9XtfErm8+0R8zVRfg 2to7Sdi6aCcBhL3PC/2FFNPENLRE3CFwuPWfsqjdmwSzCLSZiIVutCcEGwP9kV/Gb9GY FxxA== X-Gm-Message-State: ALoCoQl9cPgrEvw1Qis8DLVv5R86jRQeev66M4FaZcdJevQhFPvfTaEBH3MYUiq8JOQa4XD+hThnelQ6cqE88PPIDtgUELjX2TetzjUlP8sZTGW8+IHvvkGx1gqxDwOVHQ78qr2LOTCyHqu3FKlkybvIe/W5F4TITLxjXSkmcPEBkYo1vjMAeNr09E5Q8MIce36X4t7XpFL4 MIME-Version: 1.0 X-Received: by 10.42.214.202 with SMTP id hb10mr359124icb.76.1378736373957; Mon, 09 Sep 2013 07:19:33 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Mon, 9 Sep 2013 07:19:33 -0700 (PDT) In-Reply-To: References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> Date: Mon, 9 Sep 2013 15:19:33 +0100 Message-ID: From: Ben Laurie To: Eric Rescorla Content-Type: multipart/alternative; boundary=20cf301cc3b2cf319e04e5f413c2 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:30:25 -0000 --20cf301cc3b2cf319e04e5f413c2 Content-Type: text/plain; charset=ISO-8859-1 On 9 September 2013 14:31, Ben Laurie wrote: > > > > On 9 September 2013 14:01, Eric Rescorla wrote: > >> Ben, >> >> Generally, we're not doing advance code point assignments for documents >> that haven't been accepted by the TLS WG. >> >> Of course, this naturally raises the question of whether this document >> will >> be accepted by the TLS WG. However, as I think recent discussion >> indicates, >> there are a number of proposed approaches and there isn't really consensus >> to adopt this particular one (especially in view of the increased >> adoption of existing >> mechanisms such as GCM). If someone (Peter? You?) wants agenda time >> to argue for this particular approach instead of others, we're happy to >> have the >> discussion in YVR. This of course also applies to proponents of other >> approaches. >> > > I'm not planning to be at YVR, what happened to using the mailing list for > discussion? > > So, in favour of the WG adoption this I-D: > > 1. Nothing in this I-D prevents the adoption of other approaches. > > 2. If fixes the problem for all versions of TLS and SSLv3. > > 3. I've seen no objection that makes any sense. One objection I have seen > was that it "may not protect from key-recovery in a weak MAC > construction" - firstly, I am not aware of any such constructions in use in > SSL/TLS, and secondly, if there are any, it would be trivial to deprecate > their use in conjunction with this extension. > > How about we take a vote? > I am reminded that we don't vote - so I guess I should rephrase this as - "so, should we adopt this I-D?". > > Note, BTW, that unless convinced otherwise, we intend to implement this in > OpenSSL (it went into master yesterday), so you can consider that a vote in > favour :-) > > >> Best, >> -Ekr >> >> [As Chair] >> >> >> >> On Sun, Sep 8, 2013 at 10:57 AM, Ben Laurie wrote: >> >>> >>> >>> >>> On 8 September 2013 14:47, Dr Stephen Henson < >>> lists@drh-consultancy.co.uk> wrote: >>> >>>> On 08/09/2013 13:07, Dr Stephen Henson wrote: >>>> > On 08/09/2013 03:59, Peter Saint-Andre wrote: >>>> >> [old thread alert!] >>>> >> >>>> >> >>>> >>> 2. An extension for Encrypt-then-MAC (i.e. this draft) >>>> >> >>>> >>> Was any consensus achieved as to the best approach? >>>> >> >>>> > >>>> > I can add a data point to this. I spent an afternoon implementing >>>> this (i.e. >>>> > the encrypt then mac draft) a while ago in OpenSSL. It was pretty >>>> easy to do >>>> > and interoped fine with the test servers. >>>> > >>>> > I'll make it available as an experimental feature in OpenSSL master >>>> branch. >>>> > >>>> >>>> Well I've added this and spotted a problem. The draft extension value >>>> (0x10) >>>> clashes with the draft value used in the ALPN specification. >>>> >>> >>> Given that the ALPN draft apparently has an allocated number, can we get >>> one allocated to this I-D? >>> >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >>> >> > --20cf301cc3b2cf319e04e5f413c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 9 September 2013 14:31, Ben Laurie <benl@google.com> wrote:



On 9 September 201= 3 14:01, Eric Rescorla <ekr@rtfm.com> wrote:
Ben,

Generally, we're not doing advance code poi= nt assignments for documents
that haven't been accepted by th= e TLS WG.

Of course, this naturally raises the question of whethe= r this document will
be accepted by the TLS WG. However, as I thi= nk recent discussion indicates,
there are a number of proposed ap= proaches and there isn't really consensus
to adopt this particular one (especially in view of the increased adop= tion of existing
mechanisms such as GCM).=A0If someone (Peter? Yo= u?) wants agenda time
to argue for this particular approach inste= ad of others, we're happy to have the
discussion in YVR. This of course also applies to proponents of other = approaches.

I= 'm not planning to be at YVR, what happened to using the mailing list f= or discussion?

So, in favour of the WG adoption this I-D:
1. Nothing in this I-D prevents the adoption of other approach= es.

2. If fixes the problem for all versions of TL= S and SSLv3.

3. I've seen no objection that makes any sense. One= objection I have seen was that it "may not protect from key-recovery in a weak MAC construction" - fir= stly, I am not aware of any such constructions in use in SSL/TLS, and secon= dly, if there are any, it would be trivial to deprecate their use in conjun= ction with this extension.

How about we take a vote?

I am reminded that we don't vot= e - so I guess I should rephrase this as - "so, should we adopt this I= -D?".
=A0

Note, BTW, that unless convinced otherwise, we intend to implement this= in OpenSSL (it went into master yesterday), so you can consider that a vot= e in favour :-)


Best,
-Ekr

[As Chair]



On Sun, Sep 8, 2013 at 10:57 AM, Ben Laur= ie <benl@google.com> wrote:



On 8 September 2013 14:47, Dr Steph= en Henson <lists@drh-consultancy.co.uk> wrote:
On 08/09/2013 13:07, Dr Stephen Henson wrote:
> On 08/09/2013 03:59, Peter Saint-Andre wrote:
>> [old thread alert!]
>>
>>
>>> 2. =A0 =A0 =A0 An extension for Encrypt-then-MAC (i.e. this dr= aft)
>>
>>> Was any consensus achieved as to the best approach?
>>
>
> I can add a data point to this. I spent an afternoon implementing this= (i.e.
> the encrypt then mac draft) a while ago in OpenSSL. It was pretty easy= to do
> and interoped fine with the test servers.
>
> I'll make it available as an experimental feature in OpenSSL maste= r branch.
>

Well I've added this and spotted a problem. The draft extension v= alue (0x10)
clashes with the draft value used in the ALPN specification.

Given that the ALPN draft apparently has an all= ocated number, can we get one allocated to this I-D?


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




--20cf301cc3b2cf319e04e5f413c2-- From agl@google.com Mon Sep 9 07:51:34 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7021E81F0 for ; Mon, 9 Sep 2013 07:51:33 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG1otHaZtCq2 for ; Mon, 9 Sep 2013 07:51:26 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id EFC2F21F9EE5 for ; Mon, 9 Sep 2013 07:43:06 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id uz19so5915859obc.21 for ; Mon, 09 Sep 2013 07:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ycdnbbDiBennDhCV0bjNTn4+tHLLn7h9QzEuKZiNn4I=; b=SscmBZWz6MiLQNJpWOvVjveWd98f3zZEi8lY4J6OAD7T1ZePwHdx4vrF0f1VymESTy yrxf2EaXYm6O+hiRfldoXYUHaVowbKvnQL+DSAJxmoWYmMNOi/x72OuO22JUfjz3zXxo XeShaeG7mtyA953ZZQ9bZ1BuxuBo+IID+j8u4IxLsNuRkoqoXU4JM/Z6yiyxOW06lvYa lqFLH1XJJZezWLtslloUfdk/CoybRZuFXYzaD2E5QITreN0kv6sgu/oj3b1kEOKrbzem jXbgRUcUFIANjtdAmoDyLzf3WmYQ11+AgRQCTCF3K56DvwTtjLArm3PqsUPeTjpqg57o AhBQ== 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=ycdnbbDiBennDhCV0bjNTn4+tHLLn7h9QzEuKZiNn4I=; b=Y4jmevr5BA2RHvl9D3lVSDbgFEk4IRnPedLfVPpcf2gFJ6CDwATZldiC6d6J4osvx9 XfFNiZqidoW/6Vw1ShR5EDu87ZmdbMRClF3lLGY9YanBvJXhbp7HIey0FS9e6mKAaDOm quwshhNXTsEBKHniau+LXCOe8Gyx3PJzASm9dnYq9eGURVZ54G5TY6aex4oWTSHMzZw3 305Hxbrdph1ZchNhxKqQLG68FldlYEm2jfgtbISjzy4GR2ZpTQxe+HIjl2JP6b8nbg8o wkuzbXoUJSavc+oLO6u8Cl6apISW1ZsB7ZISIccdoZQxs+mxIKie5maAZURmiXKSxSz0 GhrQ== X-Gm-Message-State: ALoCoQnr6X6mXqliictwhFRmbb7lJ+WInSynSh6aJ+J49eRCVxKjhs58GL1JrgcfcCes+CqxFsZNm2Tzj9uP9KudN115y6vn82gTZ1SsUejlMRRG/OfdHzEnXl1C/kDzkem3yxDUVoL0NuQlx8R+ZhWj/ubgAR/qJqUYGBPMSQCOsU8KmLeveep8RiCqeonItUa55F0c32gD X-Received: by 10.60.133.233 with SMTP id pf9mr1395598oeb.46.1378737786524; Mon, 09 Sep 2013 07:43:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Mon, 9 Sep 2013 07:42:46 -0700 (PDT) In-Reply-To: References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> From: Adam Langley Date: Mon, 9 Sep 2013 10:42:46 -0400 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:51:34 -0000 On Mon, Sep 9, 2013 at 9:31 AM, Ben Laurie wrote: > 1. Nothing in this I-D prevents the adoption of other approaches. > > 2. If fixes the problem for all versions of TLS and SSLv3. The cost of making any change to TLS is mostly equal to any other, since the bulk of the cost is in deployment. Using an extension to negotiate encrypt-then-MAC is a simple change, but it still leaves us with CBC mode. On the other hand, AES-GCM left the station some years ago and has a clear head start. AES-GCM does, currently, depend on TLS 1.2, which is proving to be a pain to deploy on the public Internet as a client, but we'll get there soon. I don't believe that this change solves the problem for SSLv3 as SSLv3 doesn't have extensions and so cannot negotiate it. Once AES-GCM is running I'm hoping to simply define those ciphersuites all the way down the versions in order to solve version downgrade issues. Having an alternative to AES-GCM is certainly valuable, but I don't want it to be AES-CBC. I think the prior discussion around Salsa20/Chacha20 and a polynomial MAC is the most promising direction for that. I've no objection to this ID, but nor am I esp excited by it. Cheers AGL From benl@google.com Mon Sep 9 07:56:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C2311E8214 for ; Mon, 9 Sep 2013 07:56:20 -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=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w91GbkoEUoG1 for ; Mon, 9 Sep 2013 07:56:12 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6227E21E81E4 for ; Mon, 9 Sep 2013 07:47:47 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id s9so13235551iec.35 for ; Mon, 09 Sep 2013 07:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=8B7Fq68wnL+yQIUQsG8r5BGlFegsTP6A5otg8Rqj0+c=; b=HKnyp8UGwgAe+H/tpKp6v/dfKSoN+z+mtB0iZCzZ6SadAXNvlcH5wsj3lHBfTdCR0D uJQ7G6A6cZWtfH7jpZ1UlXmkIYqpjy91Q6Z0fD8OyaahXH1FBPdsuj0tUP8ZlnvdCWrs YRaOHXnkPNzJKXxbExRtilKa14Y4fvArwljjCbCmRqN44Je+hVYUjWKTz86S/G6crvqY hoV4rSeVQKpqrc7/UzG3wS+qYPiyKjlP7eNaJChRLV1CoPM4OFWDxeOerNZuzVHyjUy9 0ZSk+GKQKmkBziPEe4cTO6C+IUtgNjVEvH1Pffyhz2+7g0d6Ag0/cwwAQ+DnOE874vKK mP4g== 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=8B7Fq68wnL+yQIUQsG8r5BGlFegsTP6A5otg8Rqj0+c=; b=OWKaVRe4clTaNf2OrTGYP/rUm+V0sNTikV1RfByuvRhDbHgeTw0J6OaNoNuX3kPHVY 3r0T6hJjBcUAw75miURGK0uV5QUvvp1WIuxJSUreFjPvMuf2LMcH/taLTwgzWb7sP/fq /CrSWqH2bOT/DkB1rbpOr3uCtqnaho7I2Jwyp1ONmNGook31qEf3ZYi5xvFQ1Z9SF6K8 8vDKo2S0hntRVCybVt3+oQq0ibCIvaFEzUqqOxwD9NHPEcB55deKXgjW2AwQSM8BIcTu 06HQUgvMe7YX+/wBobl/ecqmjo124rzCGD+e90IBfLCLO9QxAzTcuiuf/rJlFXNJaa1+ LzVg== X-Gm-Message-State: ALoCoQnloH+ujhJves41EXsYRjb3m6l30LpgMHghbVbu0gyxK+sD1Bd9p3A5wYrY1uQQHPa286SY9cPrj9XJ8DTiCQYjqY1E/z7029tot3DEd9r56rcD2XZpQOLnD6wx2p+u1JDDuJQhusdjN10Sls2zHTrnf83V4bGkwiq0pyeVqVGXtl5I3xeBL0HZh6NzPZ+zVJdoPFgO MIME-Version: 1.0 X-Received: by 10.50.25.39 with SMTP id z7mr8089695igf.59.1378738066712; Mon, 09 Sep 2013 07:47:46 -0700 (PDT) Received: by 10.64.230.140 with HTTP; Mon, 9 Sep 2013 07:47:46 -0700 (PDT) In-Reply-To: References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> Date: Mon, 9 Sep 2013 15:47:46 +0100 Message-ID: From: Ben Laurie To: Adam Langley Content-Type: multipart/alternative; boundary=047d7bd76898b48acd04e5f478c8 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:56:21 -0000 --047d7bd76898b48acd04e5f478c8 Content-Type: text/plain; charset=ISO-8859-1 On 9 September 2013 15:42, Adam Langley wrote: > On Mon, Sep 9, 2013 at 9:31 AM, Ben Laurie wrote: > > Having an alternative to AES-GCM is certainly valuable, but I don't > want it to be AES-CBC. I think the prior discussion around > Salsa20/Chacha20 and a polynomial MAC is the most promising direction > for that. > +1. Let's do that, too. --047d7bd76898b48acd04e5f478c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 9 September 2013 15:42, Adam Langley <agl@google.com> wrote:
On Mon, Sep 9, 2013 at 9:3= 1 AM, Ben Laurie <benl@google.com= > wrote:
=A0
Having an alternative to AES-GCM is ce= rtainly valuable, but I don't
want it to be AES-CBC. I think the prior discussion around
Salsa20/Chacha20 and a polynomial MAC is the most promising direction
for that.

+1. Let's do that, too.

--047d7bd76898b48acd04e5f478c8-- From lists@drh-consultancy.co.uk Mon Sep 9 07:58:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF4311E8232 for ; Mon, 9 Sep 2013 07:58:19 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moAj0t7grJgM for ; Mon, 9 Sep 2013 07:58:07 -0700 (PDT) Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id BE0A521F999D for ; Mon, 9 Sep 2013 07:49:59 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:40062 helo=[192.168.7.9]) by relay02.mail.eu.clara.net (relay.clara.net [213.253.3.42]:10465) with esmtpa (authdaemon_plain:drh) id 1VJ2mb-0007EC-7i (return-path ); Mon, 09 Sep 2013 14:49:41 +0000 Message-ID: <522DE004.6060204@drh-consultancy.co.uk> Date: Mon, 09 Sep 2013 15:49:40 +0100 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Ben Laurie References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 14:58:19 -0000 On 09/09/2013 14:31, Ben Laurie wrote: > > 2. If fixes the problem for all versions of TLS and SSLv3. > That to me is a very strong point in its favour. There have been weaknesses affecting just about every ciphersuite with the exception of GCM mode, which needs TLS 1.2. I'd love it if everyone moved to TLS 1.2 in the near future but realistically that isn't going to happen. All manner of interop headaches arrived with broken implementations when TLS 1.2 support was added to OpenSSL and we still get frequent reports. Even with TLS 1.2 I'm uneasy about there being only one symmetric cipher mode left. I can add a few additional points in favour of this draft. The signalling approach taken is similar to the one adopted with the secure renegotiation (RFC5746), with the exception that extension intolerant servers will choke. If we really care about those another signalling ciphersuite could always be added. I particularly liked the ease with which this could be implemented in OpenSSL (Peter had similar experiences with Cryptlib). It took me just a few hours and would've been less if some unfamiliar code hadn't been added recently: ironically to address the "Lucky 13" attack. It required no new APIs and it should work seamlessly with existing applications. That's very important for a library if you have a large existing code base. One negative point relates to cryptographic hardware or software optimisations (where you have an efficient or atomic way to handle record decryption) but I think this will apply to other solutions too. Anything that needs to address "Lucky 13" may have already hit this anyway. On the particular point of addressing "Lucky 13" that attack was a real headache for FIPS 140 compliance. Reimplementing algorithms at a low level to be constant time will typically require revalidation with considerable expense and delays. A partial (but far from perfect) mitigation was chosen as a compromise. If this draft was adopted that would not be a problem any more as the existing validated algorithm implementations could be used. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From stebila@qut.edu.au Mon Sep 9 04:09:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8A311E81A8 for ; Mon, 9 Sep 2013 04:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2W1pRs9EKnT for ; Mon, 9 Sep 2013 04:09:04 -0700 (PDT) Received: from QUTEXEDGE06.qut.edu.au (qutexedge06.qut.edu.au [131.181.191.23]) by ietfa.amsl.com (Postfix) with ESMTP id DF3ED21E8187 for ; Mon, 9 Sep 2013 04:08:20 -0700 (PDT) Received: from QUTEXHUB04.qut.edu.au (131.181.186.100) by QUTEXEDGE06.qut.edu.au (131.181.191.23) with Microsoft SMTP Server (TLS) id 8.3.279.5; Mon, 9 Sep 2013 21:08:18 +1000 Received: from QUTEXMBX01.qut.edu.au ([131.181.107.108]) by QUTEXHUB04.qut.edu.au ([131.181.186.100]) with mapi; Mon, 9 Sep 2013 21:08:18 +1000 From: Douglas Stebila To: Patrick Pelletier Date: Mon, 9 Sep 2013 21:08:15 +1000 Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry Thread-Index: Ac6tTONQncniNwPBT/qxrsYMCNaYkg== Message-ID: References: <522D25B9.7010506@funwithsoftware.org> In-Reply-To: <522D25B9.7010506@funwithsoftware.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 09 Sep 2013 08:04:25 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 11:09:16 -0000 Recent news has highlighted doubts on a particular elliptic curve-based pse= udorandom number generation algorithm, Dual_EC_DRBG, in which a particular = point is used for which no explanation is given on how the point was genera= ted. If it was generated so that its discrete logarithm is known with respe= ct to another point, then a backdoor exists that can recover the seed. (ht= tp://rump2007.cr.yp.to/15-shumow.pdf) The NIST-standardized elliptic curves p256/p384/p512 are not related to thi= s particular issue.=20 - The prime p for each field has a special form chosen for efficiency (http= ://cacr.uwaterloo.ca/techreports/1999/corr99-39.pdf), not entirely unlike h= ow the prime 2^155-19 was chosen for efficiency in curve25519. There are n= o results that suggest that one prime is weaker than another prime for elli= ptic curve cryptography. - The curve parameters were generated "verifiably at random", meaning a see= d was chosen, and then the curve parameters a and b were generated by hashi= ng the seed a pre-determined number of times using SHA-1. (Appendix 4 of h= ttp://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, or Secti= on 3.1.3.1 of SEC1 http://secg.org, or ANSI X9.62) =20 - I don't think it's specified how the generator was chosen, but the Diffie= -Hellman problem is self-reducible, so there are no weak generators. There are other reasons to support curve25519, including efficiency and res= istance to side-channel attacks because constant-time implementations. But= not because of concerns over backdoors in p256/p384/p512. Douglas On 2013-09-09, at 11:34 AM, Patrick Pelletier wr= ote: > Given the doubt that's recently been cast on the NIST curves, is it time = to revive the idea of adding curve25519 as a named curve? >=20 > --Patrick >=20 >=20 > On 3/1/10 4:20 PM, Adam Langley wrote: >> We would like to start testing EC DHE in order to give our users >> forward-secrecy. >>=20 >> In order to do this cheaply, one of the curves that we would like to >> test with is curve25519[1]. There are several implementations of it >> [2][3][4] and it's 3-4x faster than NIST's p256 (as implemented in >> OpenSSL), while being constant-time. >>=20 >> Curve25519 doesn't currently appear on IANA's list of named curves[5] >> and we would like to see it included. >>=20 >> As a first step I'd like to ask if there are any objections? >>=20 >>=20 >> Cheers >>=20 >> AGL >>=20 >>=20 >> [1] http://cr.yp.to/ecdh/curve25519-20060209.pdf >> [2] http://cr.yp.to/ecdh.html >> [3] http://code.google.com/p/curve25519-donna/ >> [4] http://bench.cr.yp.to/results-dh.html >> [5] http://www.iana.org/assignments/tls-parameters/ >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stephen.farrell@cs.tcd.ie Mon Sep 9 08:21:39 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD221F9E9F for ; Mon, 9 Sep 2013 08:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pbUN7Espf8X for ; Mon, 9 Sep 2013 08:21:27 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 248FE21E8200 for ; Mon, 9 Sep 2013 08:10:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77DC5BE4D; Mon, 9 Sep 2013 16:10:09 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VPswBMHKN30; Mon, 9 Sep 2013 16:10:09 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55249BE2F; Mon, 9 Sep 2013 16:10:09 +0100 (IST) Message-ID: <522DE4D2.4020403@cs.tcd.ie> Date: Mon, 09 Sep 2013 16:10:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Yaron Sheffer References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> In-Reply-To: <522C3497.9020301@gmail.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:21:39 -0000 Hi Yaron, Thanks for doing this. I hope the WG adopt this and process it quickly. A few comments: 1) Given recent news, I think section 2 should describe why PFS is a good thing and should say a bit about how server private keys can be exposed (e.g. someone hacks into server and copies a private key file, or gets keys from a decommissioned server), and the consequences that flow if non-PFS ciphersuites are used. 2) I think an appendix or section that shows how to configure a server to prefer whatever ciphersuite configurations end up as recommended would be very valuable. I realise that that would be server specific but it should be easy enough to get for the most popular server or the two most popular. While that information is already available on the web, and will go out of date, its finicky stuff so it'd be good to make all this easier for a site admin who reads the RFC in the next couple of years. 3) Similarly, saying how to turn off ciphersuites that you don't want and which those are might be useful. 4) I also think it'd be good to give recommendations for older versions of TLS (and maybe SSL) that are still widely deployed, even though TLS 1.2 will have better options and the overall recommendation is to use a 1.2 ciphersuite. 5) I agree with the point raised by Patrick that some guidance about reasonable key lengths/strengths would be good where its needed. I'd be ok with that being in the non-normative bit where you show how to configure stuff and/or in the security considerations. Some text related to a number of the above points can be found via the links in a mail that Patrick Pelletier [1] sent to the perpass list. Cheers, S. [1] http://www.ietf.org/mail-archive/web/perpass/current/msg00062.html On 09/08/2013 09:25 AM, Yaron Sheffer wrote: > This is an early version of my proposal for a BCP-like document, to > inform the industry on what can be done with existing implementations, > while TLS 1.3 is still not ready. > > I would appreciate your comments of course. Specifically, > I would like to fill in the Implementation Status table (Sec. 5) and > would be glad to receive solid information (dates, planned dates, > version numbers) from implementers. > > Thanks, > Yaron > > -------- Original Message -------- > Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt > Date: Sat, 07 Sep 2013 15:46:38 -0700 > From: internet-drafts@ietf.org > To: Yaron Sheffer > > > A new version of I-D, draft-sheffer-tls-bcp-00.txt > has been successfully submitted by Yaron Sheffer and posted to the > IETF repository. > > Filename: draft-sheffer-tls-bcp > Revision: 00 > Title: Recommendations for Secure Use of TLS and DTLS > Creation date: 2013-09-08 > Group: Individual Submission > Number of pages: 8 > URL: http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt > Status: http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp > Htmlized: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 > > > Abstract: > Over the last few years there have been several serious attacks on > TLS, including attacks on its most commonly used ciphers and modes of > operation. This document offers recommendations on securely using > the TLS and DTLS protocols, given existing standards and > implementations. > > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nico@cryptonector.com Mon Sep 9 08:49:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1921F90A7 for ; Mon, 9 Sep 2013 08:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJsJ7MYFEYOI for ; Mon, 9 Sep 2013 08:49:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2D28C21F9263 for ; Mon, 9 Sep 2013 08:34:03 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id D7206594061 for ; Mon, 9 Sep 2013 08:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=np15InUEuo9rfYhnWCeB MJjjY9M=; b=DP6vJmxAV/kVnrp32GFQwQfGsCGTbP6IsGf1P3jLm2/X0n6MXoFs M40fBJCU9ettPq7h3glIeAyot3R7hgUZ90ERRjnM4N5faZCXD/l1Gr8D1j7P+C+D ctJwTXjfQmrPanGvUXU4O7GmApSv2wIAkivcGnAI4YGai3ZRzr0EUHI= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 7A80A594059 for ; Mon, 9 Sep 2013 08:34:02 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id j13so5498182wgh.29 for ; Mon, 09 Sep 2013 08:34:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=W/oGAM/Ui8ZCB5/Smu7EQ6S1e1bL6ozAkwhNJ7ZQbTM=; b=Y9HnM3zW7X+JPvDgpN0lz+GjwNX7jg8KTpmQI8vBmKUlmAvmn7llW71difKWaVhkM2 NolWS9nQ9rUfx1QDPEVfPOm5tBgTy8xzjiLDcAewYXcGTGphEJnQFRDqxnP8FTQnmxpi MGFsAaZKGFhqTOgl2oalltGPku4e4akTjE+80Rfj1DHNz8cAdAcHe46TdlDBmDvmxh5u 38ZGaL1PayqHQtlAPyyOzImgZP0xwNMXaLF/ncV6RtHrxalmicbF0GTAy7B9nPyKpLIw Rktit17jHDSzQu3oUvdOxd6PPn4L28+aipECGgevzDKsgPeArRaAtGBNi1tssCkCdsIO 9KKQ== MIME-Version: 1.0 X-Received: by 10.194.20.170 with SMTP id o10mr13187790wje.4.1378740841069; Mon, 09 Sep 2013 08:34:01 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 08:34:00 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 08:34:00 -0700 (PDT) In-Reply-To: References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> Date: Mon, 9 Sep 2013 10:34:00 -0500 Message-ID: From: Nico Williams To: Adam Langley Content-Type: multipart/alternative; boundary=047d7b5d5c8211c4a804e5f51e56 Cc: tls@ietf.org Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 15:49:43 -0000 --047d7b5d5c8211c4a804e5f51e56 Content-Type: text/plain; charset=UTF-8 Sure SSLv3 can negotiate this, using signaling cipher suite numbers. --047d7b5d5c8211c4a804e5f51e56 Content-Type: text/html; charset=UTF-8

Sure SSLv3 can negotiate this, using signaling cipher suite numbers.

--047d7b5d5c8211c4a804e5f51e56-- From n.mavrogiannopoulos@gmail.com Mon Sep 9 09:17:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356AA21E80A5 for ; Mon, 9 Sep 2013 09:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3LkZ7eMFaw4 for ; Mon, 9 Sep 2013 09:17:08 -0700 (PDT) Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F26B521E8211 for ; Mon, 9 Sep 2013 08:53:15 -0700 (PDT) Received: by mail-ee0-f42.google.com with SMTP id b45so3253719eek.29 for ; Mon, 09 Sep 2013 08:53:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=++RBgtbvH5R7o5GJZpaGiTfzO4sV1vYqSGM3yw3Ctsg=; b=pqDRLoUml7kZSCW0vSBYZofSjfCCOtWBtdywA9DXkAtEUGK55eYtT5iP7eD0EAg7Pq Mi1wNgg67SaH6uUwUhIDdVpc7zmWBM4HURw23cF4HKaoUxWyubUrh52j+c1BiepMF+rR QeK4EKkKb8MNfU9neULAi+rMrrGqHzWZuNAQA3c8WeB1aHIL2sG1apJTIRYtd1FwPnwu Suhe+VyGpLULLDLtUvdAZXuirToN3b/+UpjuGFRflL0ameKfb/gnAwYCP1nHK41yJF1b kGBTFUyjRG7yNM5widR8IIUB+4NaP6ccrdAyI5wSwrysBpHYg4Ffy8nIwiD5Lo9vh9Ft Dufw== X-Received: by 10.14.176.8 with SMTP id a8mr31555430eem.12.1378741992622; Mon, 09 Sep 2013 08:53:12 -0700 (PDT) Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id h52sm22984795eez.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 08:53:12 -0700 (PDT) Sender: Nikos Mavrogiannopoulos Message-ID: <522DEEE8.50001@gnutls.org> Date: Mon, 09 Sep 2013 17:53:12 +0200 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7 MIME-Version: 1.0 To: Ben Laurie References: <522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk> <522C7FD8.1000301@drh-consultancy.co.uk> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:17:10 -0000 On 09/09/2013 03:31 PM, Ben Laurie wrote: > I'm not planning to be at YVR, what happened to using the mailing list for > discussion? [...] > 3. I've seen no objection that makes any sense. One objection I have seen > was that it "may not protect from key-recovery in a weak MAC construction" > - firstly, I am not aware of any such constructions in use in SSL/TLS, and > secondly, if there are any, it would be trivial to deprecate their use in > conjunction with this extension. Unfortunately all algorithms are strong until the point they are broken. We currently have HMAC-MD5 and while a key recovery attack does not exist yet, I don't think anybody could rule-out such a development. What about HMAC-SHA1? Why not protect against future key recovery attacks by truncating the MAC? After all IPSec does truncate the MAC to 96-bits for exactly the same reason (see RFC2104 Section 5: Truncated output). Using the existing good practices is a good thing. regards, Nikos From nick.a.mathewson@gmail.com Mon Sep 9 09:20:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFB3421E81B7 for ; Mon, 9 Sep 2013 09:20:20 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwlDzmQbOPzm for ; Mon, 9 Sep 2013 09:20:20 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5830A11E81D4 for ; Mon, 9 Sep 2013 09:18:47 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id es20so5030112lab.24 for ; Mon, 09 Sep 2013 09:18:46 -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:content-transfer-encoding; bh=3LRKHPPNgymd2bnSSb9/YQMRTBP5Ov6L7Hhh7fJ0yrE=; b=XicJKDMYGW4Zt4oW2+9JUfyXv5l27t5G5kVi7/cSCEEiYJaJl+QRHVjeokfjLOEhUF O6QehjuajutM6LlhTx0zR9EXW5wH3D3TvduTNV1HSW+o/Dji4fsoljg0/1AhiBvzvYu1 TAuXYvm9Z98Md+DwD6fBrm5qa71qus2aOYZ9gO5EO/NeM4X3NQASVRtk4nP9+WGOv2QO MW/vv+C1VRozipvEq989SBhmIqcqkXWSdjAD5nG8zePVPmWauwev9Yl2aDHulH+xY0xY 8aihRE/jp4VNyDrUUTyu5kR3cidMsr6Y20UZhfbW8hMG5ExG+FtBZWMdu+IrBFB+019z Ioew== MIME-Version: 1.0 X-Received: by 10.152.37.41 with SMTP id v9mr17288158laj.9.1378743526300; Mon, 09 Sep 2013 09:18:46 -0700 (PDT) Sender: nick.a.mathewson@gmail.com Received: by 10.112.184.229 with HTTP; Mon, 9 Sep 2013 09:18:46 -0700 (PDT) In-Reply-To: <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> Date: Mon, 9 Sep 2013 12:18:46 -0400 X-Google-Sender-Auth: PWbcm8HdWEqby3quT0pH-wk2qok Message-ID: From: Nick Mathewson To: Douglas Stebila Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:20:21 -0000 On Mon, Sep 9, 2013 at 7:12 AM, Douglas Stebila wrote: [...] > - The curve parameters were generated "verifiably at random", meaning a s= eed was chosen, and then the curve parameters a and b were generated by has= hing the seed a pre-determined number of times using SHA-1. (Appendix 4 of= http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, or Sec= tion 3.1.3.1 of SEC1 http://secg.org, or ANSI X9.62) A possibly foolish question, but I couldn't find the answer in any of the documents you listed: Is it documented how the seeds were chosen? (In either case, +1 on trying to making curve25519 named. In the FOSS cryptography world nowadays, I see many more new users of curve25519 than of the NIST curves, because of efficiency and ease-of-implementation issues.) yrs, --=20 Nick Mathewson From prvs=2964b78799=uri@ll.mit.edu Mon Sep 9 09:22:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9966F21E81FD for ; Mon, 9 Sep 2013 09:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUQUegWDAycA for ; Mon, 9 Sep 2013 09:22:06 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id F146E21E8251 for ; Mon, 9 Sep 2013 09:08:21 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r89Fphif023913; Mon, 9 Sep 2013 12:08:18 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Ben Laurie , Adam Langley Date: Mon, 9 Sep 2013 12:08:07 -0400 Thread-Topic: [TLS] padding bug Thread-Index: Ac6tdsd0qaWX/iz5Rdy86VSBnajHdQ== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3461573287_25227428" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-09_05:2013-09-09, 2013-09-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-1305240000 definitions=main-1309090083 Cc: "tls@ietf.org" Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:22:11 -0000 --B_3461573287_25227428 Content-type: multipart/alternative; boundary="B_3461573287_25227729" --B_3461573287_25227729 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit > On 9 September 2013 15:42, Adam Langley wrote: >> Having an alternative to AES-GCM is certainly valuable, but I don't >> want it to be AES-CBC. I think the prior discussion around >> Salsa20/Chacha20 and a polynomial MAC is the most promising direction >> for that. > > +1. Let's do that, too. +1 on both. --B_3461573287_25227729 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable <= blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"BORDER-LEFT: #b5c4= df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
On 9 September 2013 15:42, Adam Langley <= span dir=3D"ltr"> <agl@google.com><= /span> wrote:
Having an alternative to AES-GCM is certainly valuable= , but I don't
want it to be AES-CBC. I think the prior discussion around
Salsa20/Chacha20 and a polynomial MAC is the most promising direction
for that.

+1. Let's do that, too.
=

+1 on both.
<= /body> --B_3461573287_25227729-- --B_3461573287_25227428 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0 B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8 11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/ inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5 48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ /Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2 QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3 EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD 2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/ hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW 6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I 1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/ LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90 ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X 519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3 sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8 B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn +t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU 3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDo54yeSvpsONJ/yiRIEs2Oxy54LbUObHTY fd04vP56MzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5 MDkxNjA4MDdaMA0GCSqGSIb3DQEBAQUABIIBAKlO2nEtOMD9HJmR2Bqmn2gVPufywbXKlNVW uMCxkOQFD8DQ/v8GYX+Q5NN1tTsW/HNDsFJDg9SaFr1o9v14dBNDVjXJqMsYMGch5Erb4Yzq MXvbFae244VaiOXeDWIPsyF53HTbyn4wdz5KUfw8JTCdUZ6xILDCYVfx2yjKai69o7hvFmvR Kee+L/Iwz//9lDwvJQqsfWhGchZ6DLMITQHtdXuFjRDZwusXAzuJZg3FtnjGh5IyTq65tDOM vOEfd8s9QNLpz572O+DYEBvpCkiV9R6iw2Li7S3sRpMpcXrzz6TvohOBfcS6G0Ok8usW9ZPj NZ6TVcCEDxMU33dU8PM= --B_3461573287_25227428-- From michael@stroeder.com Mon Sep 9 09:32:42 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C7221F9DF3 for ; Mon, 9 Sep 2013 09:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38G6oZfGWNiX for ; Mon, 9 Sep 2013 09:32:36 -0700 (PDT) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id F40AF11E8112 for ; Mon, 9 Sep 2013 09:31:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id C039D6023B; Mon, 9 Sep 2013 18:31:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at stroeder.com Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-xwxagapYoj; Mon, 9 Sep 2013 18:30:56 +0200 (CEST) Received: from nb2.stroeder.local (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 27A2C6021F; Mon, 9 Sep 2013 16:30:56 +0000 (UTC) Message-ID: <522DF7BF.7080608@stroeder.com> Date: Mon, 09 Sep 2013 18:30:55 +0200 From: =?ISO-8859-1?Q?Michael_Str=F6der?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: Peter Gutmann , "tls@ietf.org" References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030203040206000002070908" Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 16:32:42 -0000 This is a cryptographically signed message in MIME format. --------------ms030203040206000002070908 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Peter Gutmann wrote: > Why at least 2048 bits? What's wrong with 1280, or 1536, which will be= quite > a lot faster. I vaguely remember that you brought up your doubts about bigger key-lengt= hs already somewhere else quite a while ago. Do you have numbers about the relative and absolute performance impact? Personally I don't see performance problems but I can't prove my position= with numbers. Ciao, Michael. --------------ms030203040206000002070908 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTA5MTYzMDU1WjAj BgkqhkiG9w0BCQQxFgQUMIuV1sMLTS6wSksr1NQG0Qng7tEwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAL3YHtsBjapWa26fguyGa3GohaeCk01Gd ZX7e+RqGJ6iG3ZjK5IpW1dgvqi971WgakqQMx3A7XXjXUzMND0HcCNpQ6zbPsCbY79vGdT0T 4u21tUtz1u53Rff7QS1Yr//murQKBhhbPHMse7UoBzowwKRqL9ADq9GzIlkTY9hkwEZvPHMZ mxvxa6UJ41Lmz8Xz0F0pd4CTQ8ZWES8qGXuUdNOKf6C7Hhd3AAyxtr38QD8SNbMHJgL+NjRU hFxXlM4EsUf2mcONYHQvrgTDGFauRXF7bLWT2W/Ce2CvBMAc8jlTK//IPhvwqBkufQ3NFqNW F/QYo8LX7Ye2yxxyXzjfQgAAAAAAAA== --------------ms030203040206000002070908-- From ynir@checkpoint.com Mon Sep 9 12:06:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 379ED21E80AE for ; Mon, 9 Sep 2013 12:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.555 X-Spam-Level: X-Spam-Status: No, score=-5.555 tagged_above=-999 required=5 tests=[AWL=-2.444, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2G97GSoJ1LsU for ; Mon, 9 Sep 2013 12:06:43 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C550821E80AB for ; Mon, 9 Sep 2013 12:06:39 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r89J6F3s022778; Mon, 9 Sep 2013 22:06:15 +0300 X-CheckPoint: {522E1C27-0-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Mon, 9 Sep 2013 22:06:15 +0300 From: Yoav Nir To: =?iso-8859-1?Q?Michael_Str=F6der?= Thread-Topic: [TLS] New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: AQHOrY+nTAtWeByYw0au+1HiAvNaZQ== Date: Mon, 9 Sep 2013 19:06:14 +0000 Message-ID: References: <9A043F3CF02CD34C8E74AC1594475C7344731843@uxcn10-6.UoA.auckland.ac.nz> <522DF7BF.7080608@stroeder.com> In-Reply-To: <522DF7BF.7080608@stroeder.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.77] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 19:06:49 -0000 On Sep 9, 2013, at 7:30 PM, Michael Str=F6der wrote: > Peter Gutmann wrote: >> Why at least 2048 bits? What's wrong with 1280, or 1536, which will be = quite >> a lot faster. >=20 > I vaguely remember that you brought up your doubts about bigger key-lengt= hs > already somewhere else quite a while ago. >=20 > Do you have numbers about the relative and absolute performance impact? > Personally I don't see performance problems but I can't prove my position= with > numbers. OpenSSL (probably either the most common or second most common library for = such things) does not have a speed test for D-H, but the DSA numbers should= pretty much match, no? MBA-2:tmp synp$ openssl speed dsa1024 dsa2048 Doing 1024 bit sign dsa's for 10s: 21689 1024 bit DSA signs in 9.65s Doing 1024 bit verify dsa's for 10s: 18913 1024 bit DSA verify in 9.74s Doing 2048 bit sign dsa's for 10s: 6803 2048 bit DSA signs in 9.63s Doing 2048 bit verify dsa's for 10s: 5668 2048 bit DSA verify in 9.82s OpenSSL 1.0.1e 11 Feb 2013 built on: Tue Feb 26 05:00:07 PST 2013 options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) idea(int)= blowfish(idx)=20 compiler: /usr/bin/clang -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_T= HREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN = -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOP= ENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM = -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM sign verify sign/s verify/s dsa 1024 bits 0.000445s 0.000515s 2247.6 1941.8 dsa 2048 bits 0.001416s 0.001733s 706.4 577.2 So it makes sense that with 1280 or 1536 the result would be somewhere in t= he middle. Yoav From yaronf.ietf@gmail.com Mon Sep 9 13:07:09 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280F821F9D31 for ; Mon, 9 Sep 2013 13:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTyG6mFFMa5i for ; Mon, 9 Sep 2013 13:07:05 -0700 (PDT) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id B035C21F9BC1 for ; Mon, 9 Sep 2013 13:06:34 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id l18so5634315wgh.28 for ; Mon, 09 Sep 2013 13:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=jAFiGThvFsGV3RR9kE1b5Dd0GGJxz7PSfakJyBQZ0sY=; b=ibnvFsnU8kd+Z0+vqG9CIBtxUEHT3QjfqI+ByP0z83BkI9pnLlgI8jYIN0bcivxyzy 65cBdeZ++iIw8/GKJeY8OWaEJTpEbeAOLrWI8J748dO7WnNBBifKAjIErNSdYO3U8nmC eV/jzHdztzflppK7jpkZtoXDyYXQskwmWiKyr5WfsyENpk3h7WAN+l9dwj9Y3NxilDn8 QaXyxMzAiRBsijLFptFnC2sNgO9zlx3qaoTky73wq5bchg4OqGs1y305Fiy7nMoAcf+w clXBR7C+nydK+OhvceDxchVv+FL6nIXdHR8MXRfoeHuQPeTYed4VElOe0jPwji+1M5KS bkyw== X-Received: by 10.180.90.19 with SMTP id bs19mr9772379wib.15.1378757173812; Mon, 09 Sep 2013 13:06:13 -0700 (PDT) Received: from [10.0.0.8] ([109.65.190.101]) by mx.google.com with ESMTPSA id b13sm20203988wic.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 09 Sep 2013 13:06:13 -0700 (PDT) Message-ID: <522E2A31.7090108@gmail.com> Date: Mon, 09 Sep 2013 23:06:09 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 MIME-Version: 1.0 To: Stephen Farrell References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> <522DE4D2.4020403@cs.tcd.ie> In-Reply-To: <522DE4D2.4020403@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:07:09 -0000 Hi Stephen, thanks for your review. Please see comments inline. Yaron On 09/09/2013 06:10 PM, Stephen Farrell wrote: > > Hi Yaron, > > Thanks for doing this. I hope the WG adopt this and > process it quickly. So do I. This document will become way more valuable if the WG adopts it. > > A few comments: > > 1) Given recent news, I think section 2 should describe why > PFS is a good thing and should say a bit about how server > private keys can be exposed (e.g. someone hacks into > server and copies a private key file, or gets keys from > a decommissioned server), and the consequences that flow > if non-PFS ciphersuites are used. Agree. > > 2) I think an appendix or section that shows how to configure > a server to prefer whatever ciphersuite configurations end > up as recommended would be very valuable. I realise that that > would be server specific but it should be easy enough to get > for the most popular server or the two most popular. While > that information is already available on the web, and will > go out of date, its finicky stuff so it'd be good to make > all this easier for a site admin who reads the RFC in > the next couple of years. > I'm not crazy about including Apache directives in an RFC. More importantly, I believe this is more about the client offering the right ciphersuite in a high enough place than about the server, which normally must support any client that comes along. > 3) Similarly, saying how to turn off ciphersuites that you > don't want and which those are might be useful. This is a security vs. inclusiveness tradeoff. Even if we tell people to turn off RC4 on the server, they won't. > > 4) I also think it'd be good to give recommendations for > older versions of TLS (and maybe SSL) that are still > widely deployed, even though TLS 1.2 will have better > options and the overall recommendation is to use a > 1.2 ciphersuite. I wish I knew what to recommend for <1.2. Any ideas? > > 5) I agree with the point raised by Patrick that some > guidance about reasonable key lengths/strengths would > be good where its needed. I'd be ok with that being in > the non-normative bit where you show how to configure > stuff and/or in the security considerations. Agree. My current thinking, based on today's discussion, is 2048 bits for both DH and RSA. > > Some text related to a number of the above points can be > found via the links in a mail that Patrick Pelletier [1] > sent to the perpass list. > > Cheers, > S. > > [1] http://www.ietf.org/mail-archive/web/perpass/current/msg00062.html > > > On 09/08/2013 09:25 AM, Yaron Sheffer wrote: >> This is an early version of my proposal for a BCP-like document, to >> inform the industry on what can be done with existing implementations, >> while TLS 1.3 is still not ready. >> >> I would appreciate your comments of course. Specifically, >> I would like to fill in the Implementation Status table (Sec. 5) and >> would be glad to receive solid information (dates, planned dates, >> version numbers) from implementers. >> >> Thanks, >> Yaron >> >> -------- Original Message -------- >> Subject: New Version Notification for draft-sheffer-tls-bcp-00.txt >> Date: Sat, 07 Sep 2013 15:46:38 -0700 >> From: internet-drafts@ietf.org >> To: Yaron Sheffer >> >> >> A new version of I-D, draft-sheffer-tls-bcp-00.txt >> has been successfully submitted by Yaron Sheffer and posted to the >> IETF repository. >> >> Filename: draft-sheffer-tls-bcp >> Revision: 00 >> Title: Recommendations for Secure Use of TLS and DTLS >> Creation date: 2013-09-08 >> Group: Individual Submission >> Number of pages: 8 >> URL: http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-00.txt >> Status: http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp >> Htmlized: http://tools.ietf.org/html/draft-sheffer-tls-bcp-00 >> >> >> Abstract: >> Over the last few years there have been several serious attacks on >> TLS, including attacks on its most commonly used ciphers and modes of >> operation. This document offers recommendations on securely using >> the TLS and DTLS protocols, given existing standards and >> implementations. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> From simon@josefsson.org Mon Sep 9 13:09:11 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A4221F9D31 for ; Mon, 9 Sep 2013 13:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrxv5QZwjbtr for ; Mon, 9 Sep 2013 13:09:07 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 5100C21F9C36 for ; Mon, 9 Sep 2013 13:09:05 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r89K8sxE018627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 9 Sep 2013 22:08:55 +0200 From: Simon Josefsson To: Douglas Stebila References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130909:stebila@qut.edu.au::CQ14HeOaEBJkPcDe:8Xre X-Hashcash: 1:22:130909:tls@ietf.org::41bqInuWej5hWaSd:85cg X-Hashcash: 1:22:130909:code@funwithsoftware.org::Ow+OH8+Y9i0BUqpP:DU+3 Date: Mon, 09 Sep 2013 22:08:54 +0200 In-Reply-To: <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> (Douglas Stebila's message of "Mon, 9 Sep 2013 21:12:19 +1000") Message-ID: <87zjrl21wp.fsf_-_@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: Patrick Pelletier , "tls@ietf.org" Subject: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:09:13 -0000 Douglas Stebila writes: > There are other reasons to support curve25519, including efficiency > and resistance to side-channel attacks because constant-time > implementations. I agree. To be able to move forward with standardization of the idea, an Internet Draft may help. I have create one: http://www.ietf.org/id/draft-josefsson-tls-curve25519-00.txt Feedback most welcome! /Simon From nico@cryptonector.com Mon Sep 9 13:53:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D438421E80C4 for ; Mon, 9 Sep 2013 13:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r+XJ2J4JEhCI for ; Mon, 9 Sep 2013 13:53:33 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id DC9BF11E813A for ; Mon, 9 Sep 2013 13:53:32 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 4C5AA21E015 for ; Mon, 9 Sep 2013 13:52:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LvdJIeDTCtRm9L70+q/3 uUcAjn0=; b=b3/83Py2y3zwOyVbWnK3xMxrFZSkWE+Qrd95xzJdWVO/aF7VvgVa S1vSeJ+5L2pYyArm8T5jWCgTZCriot4GeXFW2029W6+jtqVvQFgscn9iZ89yV3s1 BCB/VZ2BcekeKQBIDVHcKmenjZITfkCukm20T/nrRqWZ9Euv7esZ/to= Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 45D8721E46A for ; Mon, 9 Sep 2013 12:31:22 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id t61so4651816wes.16 for ; Mon, 09 Sep 2013 12:31:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0bZnHS/W0esRLs8RCOtgqmWBjbvNgwAkw28wvm/vFz8=; b=VF5e9FANdiN8WqL/skpwbXF9OSw3cB2RIAawR+6qYilh3Xnh2lmwqYb7lxBHQKQW1f L3/l4q5532kMGKRUA8akJwSao81Hg0+3uTY+GcWKk7uNHUOCW95cKJkKpUkenYsAv+PJ Bg5pWhzATLUX4NR2GPBHzrhLWXtFQK9aut2eArrvfFhf2vE6V9BtZkNiGW4nrNQ66J1g MxjDtLnr4DQqHMlhxdj66AxYxc75KPOSpX0764ch8/tVssHuwExXfs45BEoA+78vaPl+ 9hKzEPKKUViZo4O3UZ6JM9+78DY6OIfKfHolpygKizGr/53iFYlVO60fCOLWqQCksCUG Jq1Q== MIME-Version: 1.0 X-Received: by 10.180.198.79 with SMTP id ja15mr9717485wic.36.1378755075156; Mon, 09 Sep 2013 12:31:15 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 12:31:15 -0700 (PDT) Received: by 10.216.31.193 with HTTP; Mon, 9 Sep 2013 12:31:15 -0700 (PDT) In-Reply-To: References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> Date: Mon, 9 Sep 2013 14:31:15 -0500 Message-ID: From: Nico Williams To: Nick Mathewson Content-Type: multipart/alternative; boundary=047d7b6242527cb71204e5f86edd Cc: tls@ietf.org Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:53:38 -0000 --047d7b6242527cb71204e5f86edd Content-Type: text/plain; charset=UTF-8 Agreed, we need curve25519 cipher suites because of its technical advantages, not due to any FUD about the other ECDH curves that we have. Nico -- --047d7b6242527cb71204e5f86edd Content-Type: text/html; charset=UTF-8

Agreed, we need curve25519 cipher suites because of its technical advantages, not due to any FUD about the other ECDH curves that we have.

Nico
--

--047d7b6242527cb71204e5f86edd-- From code@funwithsoftware.org Mon Sep 9 14:22:57 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70D11E8116 for ; Mon, 9 Sep 2013 14:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LQ52+aGnIjbJ for ; Mon, 9 Sep 2013 14:22:52 -0700 (PDT) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 49DEC21F9F86 for ; Mon, 9 Sep 2013 14:22:51 -0700 (PDT) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 542C81EE4FB3 for ; Mon, 9 Sep 2013 17:22:50 -0400 (EDT) Received: (qmail 16857 invoked from network); 9 Sep 2013 21:22:49 -0000 Received: by simscan 1.4.0 ppid: 915, pid: 21124, t: 1.2408s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4 Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Sep 2013 21:22:48 -0000 Message-ID: <522E3C27.8090001@funwithsoftware.org> Date: Mon, 09 Sep 2013 14:22:47 -0700 From: Patrick Pelletier User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Stephen Farrell References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> <522DE4D2.4020403@cs.tcd.ie> In-Reply-To: <522DE4D2.4020403@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 21:22:57 -0000 On 9/9/13 8:10 AM, Stephen Farrell wrote: > Some text related to a number of the above points can be > found via the links in a mail that Patrick Pelletier [1] > sent to the perpass list. > > [1] http://www.ietf.org/mail-archive/web/perpass/current/msg00062.html Besides those links, another link worth reading is this one: https://www.imperialviolet.org/2013/06/27/botchingpfs.html I think it would be good to cover the risks of session resumption and how to mitigate them. (e. g. rotating the keys used for session tickets) --Patrick From stebila@qut.edu.au Mon Sep 9 16:40:56 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E731411E80D1 for ; Mon, 9 Sep 2013 16:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.895 X-Spam-Level: X-Spam-Status: No, score=-4.895 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJsTGxAOnZrY for ; Mon, 9 Sep 2013 16:40:52 -0700 (PDT) Received: from QUTEXEDGE05.qut.edu.au (qutexedge05.qut.edu.au [131.181.191.22]) by ietfa.amsl.com (Postfix) with ESMTP id EFEE621F95DD for ; Mon, 9 Sep 2013 16:40:51 -0700 (PDT) Received: from qutexhub01.qut.edu.au (131.181.107.106) by qutexedge05.qut.edu.au (131.181.191.22) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 10 Sep 2013 09:40:43 +1000 Received: from QUTEXMBX01.qut.edu.au ([131.181.107.108]) by qutexhub01.qut.edu.au ([131.181.107.106]) with mapi; Tue, 10 Sep 2013 09:40:37 +1000 From: Douglas Stebila To: Nick Mathewson Date: Tue, 10 Sep 2013 09:40:34 +1000 Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry Thread-Index: Ac6ttfvoAfbegr4QQLax467ShCgnPw== Message-ID: References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 23:40:57 -0000 On 2013/09/10, at 02:18, Nick Mathewson wrote: > On Mon, Sep 9, 2013 at 7:12 AM, Douglas Stebila wrot= e: > [...] >> - The curve parameters were generated "verifiably at random", meaning a = seed was chosen, and then the curve parameters a and b were generated by ha= shing the seed a pre-determined number of times using SHA-1. (Appendix 4 o= f http://csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf, or Se= ction 3.1.3.1 of SEC1 http://secg.org, or ANSI X9.62) >=20 > A possibly foolish question, but I couldn't find the answer in any of > the documents you listed: >=20 > Is it documented how the seeds were chosen? I haven't found any information on how the seeds were chosen. The earliest= reference I have listing the seeds is a September 1998 draft of ANSI X9.62= , a copy of which is available here: https://github.com/ANSSI-FR/parsifal/b= lob/master/docs/tls/X9-62-1998--ECDSA.pdf, but this provides no reason for = the choice of seeds. Maybe there's someone from X9F on this mailing list w= ho has some historical insight? Douglas From dbrown@certicom.com Mon Sep 9 18:22:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3111E816D for ; Mon, 9 Sep 2013 18:22:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED-GXs6dhGX9 for ; Mon, 9 Sep 2013 18:22:55 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA6811E813D for ; Mon, 9 Sep 2013 18:22:51 -0700 (PDT) X-AuditID: 0a412830-b7f576d00000095e-78-522e74639fc5 Received: from XCT103CNC.rim.net (xct103cnc.rim.net [10.65.161.203]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 88.15.02398.3647E225; Mon, 9 Sep 2013 20:22:43 -0500 (CDT) Received: from XCT113CNC.rim.net (10.65.161.213) by XCT103CNC.rim.net (10.65.161.203) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Sep 2013 21:22:42 -0400 Received: from XMB117CNC.rim.net ([fe80::24f3:cc30:b596:7ca0]) by XCT113CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Mon, 9 Sep 2013 21:22:42 -0400 From: Dan Brown To: Douglas Stebila , Nick Mathewson Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry Thread-Index: AQHOrPzUSgKBdqWRokmt5ggMXGJ/7Zm9g/qAgABVnwCAAHtwAIAAHIYA Date: Tue, 10 Sep 2013 01:22:41 +0000 Message-ID: <20130910012240.5595281.33313.3530@certicom.com> References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <8CFB774F62C2BC40BFE19B31438BCBF6@rim.com> content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrIKsWRmVeSWpSXmKPExsXC5bjwtG5yiV6QwZ8XkhYXjm5gtzi36T2T xafzXYwOzB5Llvxk8tiz/gubx+b1l9kCmKMaGG0S8/LySxJLUhVSUouTbZV8UtMTcxQCijLL EpMrFVwyi5NzEjNzU4uUFDJTbJVMlBQKchKTU3NT80pslRILClLzUpTsuBQwgA1QWWaeQmpe cn5KZl66rZJnsL+uhYWppa6hkp0uEkj4x53xrXsKc8Ec5Yr55+QaGFcodTFyckgImEg0Hz/D DmGLSVy4t56ti5GLQ0ignUni0fxuRghnBaPE+ZcXWSCc2YwSJ/5vZgNpYRNQlbh/9BxzFyMH h4hAoMSEK1YgYWYBRYn3l+axgNjCAtESv/43MYHYIgIxEmv/rIEqd5O4sa0axGQBmnJsYRhI Ba+AjcStSS9YITYtZJJ4+L0ZbBOngJ3Eh0e7wUYyCshK7D57nQlilbjEvvm7mSEeEJBYsuc8 lC0q8fLxP1aQ+cwCmhLrd+lDlJtJ7Do6iRnmyindD9kh9gpKnJz5BGy8kICCxJXr+1gmMErM QrJhFsKkWUgmzUIyaRaSSQsYWVcxCuZmFBuYGSbnJesVZebq5aWWbGIEJx8Ngx2M799bHGIU 4GBU4uHl8NMLEmJNLCuuzD3EKMHBrCTCu4EZKMSbklhZlVqUH19UmpNafIjRFRhWE5mluJPz gYkxryTe2MAAN0dJnNdV5UOgkEA6MNllp6YWpBbBzGHi4JRqYNz7+dtipq3rJTd0XuNdE/+i 5PaCe6daqvxn6O3muGgq9HyRSkdH4m8PQeaObzkS5q2KgpPe+Z9hlX90W+JezwV3/n21X5Y8 PXt030yJE1rTkmRLYnSjVhpIfzu4s3dtd+0Ge8sdZaseGv0/vO39pyeP7c3KJeptzecc/KzD bVhw6MnFxphvzbOVWIozEg21mIuKEwHtQg1eZAMAAA== Cc: "tls@ietf.org" Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 01:22:58 -0000 SSdtIHRoZSBjdXJyZW50IGVkaXRvciBvZiBBTlNJIFg5LjYyIGFuZCBYOS42MywgYnV0IGpv aW5lZCBYOUYxIGEgbGl0dGxlIGxhdGVyIHRoYW4gdGhl4oCOIHRpbWUgaW4gcXVlc3Rpb24s IHNvIGFtIG5vdCB0aGUgYmVzdCBoaXN0b3JpY2FsIHNvdXJjZS4NCg0K4oCOQW55d2F5LCBJ IGhhZCB0aG91Z2h0IHRoZSAxNSBOSVNUIGN1cnZlcyB3ZXJlIGluY2x1ZGVkIGluIEFOU0kg WDkuNjMgaW4gMjAwMSwgYnV0IG1vc3Qgd2VyZSBub3QgaW4gWDkuNjIgaW4gaXRzIGZpcnN0 IDE5OTggdmVyc2lvbiwgYW5kIG9ubHkgYWRkZWQgaW4gdGhlIDIwMDUgdmVyc2lvbi4NCg0K VGhlIGN1cnZlIHNlZWQgc291cmNlcyB3ZXJlIG5vdCBkb2N1bWVudGVkIGluIEFOU0kgb3Ig TklTVCBkb2NzLiBJJ3ZlIHdvbmRlcmVkIGFib3V0IGl0IGEgZmV3IHRpbWVzLCBidXQgY291 bGQgbmV2ZXIgc2VlIGEgY29uY3JldGUgcHJvYmxlbS4gQXQgbGVhc3QgaW50dWl0aXZlbHks IGl0IHdvdWxkIG9ubHkgYmUgYSBwcm9ibGVtIGlmOg0KDQoxKSBhIGxhcmdlIGZyYWN0aW9u IG9mIGVsbGlwdGljIGN1cnZlcyB3ZXJlIHdlYWssIG9yDQoNCjIpIHNoYTEgcHJlaW1hZ2Vz IGFyZSBlYXN5IHRvIGZpbmQgYW5kIHNvbWUgdW5rbm93biBidXQgcmFyZSBjbGFzcyBvZiBl bGxpcHRpYyBjdXJ2ZXMgYXJlIHdlYWsuDQoNCuKAjkJvdGggb2YgdGhlc2Ugd291bGQgdW5k ZXJtaW5lIG1vcmUgdGhhbiBqdXN0IHRoZSBjdXJ2ZSBjaG9pY2UsIGFuZCBzZWVtIGV4dHJl bWVseSB1bmxpa2VseS4NCg0KQW4gYWx0ZXJuYXRpdmUgd291bGQgaGF2ZSBiZWVuIHRvIHNl bGVjdCB0aGUgc2VlZHMgaW4gYSBjYW5vbmljYWwgd2F5LCBlZyBhcyB0aGUgc21hbGxlc3Qg aW50ZWdlciBhYm92ZSBzb21lIG1hdGggY29uc3RhbnQgY2F1c2luZyB0aGUgY3VydmUgZ2Vu ZXJhdGVkIHZpYSB0aGUgaGFzaCB0byBiZSBnb29kLiBJbiB0aGlzIGNhc2UsIHRoZSBjdXJ2 ZSBjb3VsZCBiZSBzYWlkIHRvIGJlIHBzZXVkb3JhbmRvbeKAjiwgYnV0IG5vdCByYW5kb20u DQoNCkkgd2VsY29tZSBhbnkgcG9pbnRzIG9yIGluZm8gSSd2ZSBtaXNzZWQsIGFuZCB3aWxs IGdsYWRseSBmb3J3YXJkIHRvIHRoZSByZXN0IG9mIFg5RjEuDQoNCi4uLg0KDQpUaGUgZ2Vu ZXJhdG9ycyBmb3IgdGhlIE5JU1QgY3VydmVzIGFyZSBub3QgdmVyaWZpYWJseSByYW5kb20s IGJ1dCBYOS42Mi0yMDA1IGFkZGVkIGEgbWV0aG9kIHRvIGdlbmVyYXRlIHRoZW0gdGhhdCB3 YXksIGZvciBuZXcgY3VydmVzIG9yIGFsZ29yaXRobXMgKGVnIFg5LjkyIHVzZXMgdGhpcyBt ZXRob2QpLg0KDQpFQ0RTQSBkb2VzIG5vdCBzaGFyZSB0aGUgcmFuZG9tIHNlbGYtcmVkdWNp YmlsaXR5IHByb3BlcnR5IHdpdGggRUNESOKAjiwgaGVuY2UgdGhlIGNoZWNrIHRoYXQgciBp cyBub3QgemVybyAoYW5kIHZyIGdlbnMgZm9yIG5ldyBjdXJ2ZXMgdG8gc3VwcGxlbWVudCB0 aGUgciBjaGVjayApLg0KDQouLi4NCg0KVGhlIEVDUk5HIHN0YW5kYXJkcyBpbiBxdWVzdGlv biBkbyBoYXZlIG9wdGlvbnMgZm9yIHVzZXJzIHRvIHNlbGVjdCB2ZXJpZmlhYmx5IHJhbmRv bSBjb25zdGFudHMsIHdoaWNoIHJlbW92ZXMgYW55IGRvdWJ0cywgdW5sZXNzIHNoYTUxMiBp cyB3ZWFrLg0KDQpHaXZlbiB0aGUgaW1wb3J0YW5jZSBvZiBrZXkgZ2VuZXJhdGlvbiwgc29t ZSBtaWdodCBjb25zaWRlciB0aGUgY29zdCBvZiB1c2luZyBhbiBFQ1JORy4gT3RoZXJzIGp1 c3QgbmVlZCBrZXlzIGZhc3Rlci4gSGVuY2UgdGhlIG9wdGlvbnMgaW4gc3RhbmRhcmRzLCBl ZyBITUFDIGFuZCBBRVMgYmFzZWQgUk5Hcy4NCg0KDQoNClNlbnQgZnJvbSBteSBCbGFja0Jl cnJ5IDEwIHNtYXJ0cGhvbmUgb24gdGhlIFJvZ2VycyBuZXR3b3JrLg0KRnJvbTogRG91Z2xh cyBTdGViaWxhDQpTZW50OiBNb25kYXksIFNlcHRlbWJlciA5LCAyMDEzIDc6NDEgUE0NClRv OiBOaWNrIE1hdGhld3Nvbg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNd IFRlc3RpbmcgY29uc2Vuc3VzIGZvciBhZGRpbmcgY3VydmUyNTUxOSB0byB0aGUgRUMgbmFt ZWQgY3VydmUgcmVnaXN0cnkNCg0KDQpPbiAyMDEzLzA5LzEwLCBhdCAwMjoxOCwgTmljayBN YXRoZXdzb24gPG5pY2ttQHRvcnByb2plY3Qub3JnPiB3cm90ZToNCg0KPiBPbiBNb24sIFNl cCA5LCAyMDEzIGF0IDc6MTIgQU0sIERvdWdsYXMgU3RlYmlsYSA8c3RlYmlsYUBxdXQuZWR1 LmF1PiB3cm90ZToNCj4gWy4uLl0NCj4+IC0gVGhlIGN1cnZlIHBhcmFtZXRlcnMgd2VyZSBn ZW5lcmF0ZWQgInZlcmlmaWFibHkgYXQgcmFuZG9tIiwgbWVhbmluZyBhIHNlZWQgd2FzIGNo b3NlbiwgYW5kIHRoZW4gdGhlIGN1cnZlIHBhcmFtZXRlcnMgYSBhbmQgYiB3ZXJlIGdlbmVy YXRlZCBieSBoYXNoaW5nIHRoZSBzZWVkIGEgcHJlLWRldGVybWluZWQgbnVtYmVyIG9mIHRp bWVzIHVzaW5nIFNIQS0xLiAoQXBwZW5kaXggNCBvZiBodHRwOi8vY3NyYy5uaXN0Lmdvdi9n cm91cHMvU1QvdG9vbGtpdC9kb2N1bWVudHMvZHNzL05JU1RSZUN1ci5wZGYsIG9yIFNlY3Rp b24gMy4xLjMuMSBvZiBTRUMxIGh0dHA6Ly9zZWNnLm9yZywgb3IgQU5TSSBYOS42MikNCj4N Cj4gQSBwb3NzaWJseSBmb29saXNoIHF1ZXN0aW9uLCBidXQgSSBjb3VsZG4ndCBmaW5kIHRo ZSBhbnN3ZXIgaW4gYW55IG9mDQo+IHRoZSBkb2N1bWVudHMgeW91IGxpc3RlZDoNCj4NCj4g SXMgaXQgZG9jdW1lbnRlZCBob3cgdGhlIHNlZWRzIHdlcmUgY2hvc2VuPw0KDQpJIGhhdmVu J3QgZm91bmQgYW55IGluZm9ybWF0aW9uIG9uIGhvdyB0aGUgc2VlZHMgd2VyZSBjaG9zZW4u IFRoZSBlYXJsaWVzdCByZWZlcmVuY2UgSSBoYXZlIGxpc3RpbmcgdGhlIHNlZWRzIGlzIGEg U2VwdGVtYmVyIDE5OTggZHJhZnQgb2YgQU5TSSBYOS42MiwgYSBjb3B5IG9mIHdoaWNoIGlz IGF2YWlsYWJsZSBoZXJlOiBodHRwczovL2dpdGh1Yi5jb20vQU5TU0ktRlIvcGFyc2lmYWwv YmxvYi9tYXN0ZXIvZG9jcy90bHMvWDktNjItMTk5OC0tRUNEU0EucGRmLCBidXQgdGhpcyBw cm92aWRlcyBubyByZWFzb24gZm9yIHRoZSBjaG9pY2Ugb2Ygc2VlZHMuIE1heWJlIHRoZXJl J3Mgc29tZW9uZSBmcm9tIFg5RiBvbiB0aGlzIG1haWxpbmcgbGlzdCB3aG8gaGFzIHNvbWUg aGlzdG9yaWNhbCBpbnNpZ2h0Pw0KDQpEb3VnbGFzDQoNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0Bp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRh Y2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxl Z2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xp Y2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0 aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0 aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJv aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJy b3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5 IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVu bGF3ZnVsLg0K From rob.stradling@comodo.com Tue Sep 10 01:35:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647E721F9C4F for ; Tue, 10 Sep 2013 01:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU8-sJ+Yhr09 for ; Tue, 10 Sep 2013 01:35:01 -0700 (PDT) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5F00321E8180 for ; Tue, 10 Sep 2013 01:34:52 -0700 (PDT) Received: (qmail 27426 invoked from network); 10 Sep 2013 08:34:48 -0000 Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 10 Sep 2013 08:34:48 -0000 Received: (qmail 24832 invoked by uid 1000); 10 Sep 2013 08:34:47 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Tue, 10 Sep 2013 09:34:47 +0100 Message-ID: <522ED9A7.7080802@comodo.com> Date: Tue, 10 Sep 2013 09:34:47 +0100 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Simon Josefsson References: <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> In-Reply-To: <87zjrl21wp.fsf_-_@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Patrick Pelletier , "tls@ietf.org" Subject: Re: [TLS] Curve25519 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 08:35:05 -0000 On 09/09/13 21:08, Simon Josefsson wrote: > Douglas Stebila writes: > >> There are other reasons to support curve25519, including efficiency >> and resistance to side-channel attacks because constant-time >> implementations. > > I agree. To be able to move forward with standardization of the idea, > an Internet Draft may help. I have create one: > > http://www.ietf.org/id/draft-josefsson-tls-curve25519-00.txt > > Feedback most welcome! Simon, thanks for creating this draft. draft-merkle-tls-brainpool-04 (on which you've based this new draft) says: "While the ASN.1 object identifiers defined in [RFC5639] already allow usage of the ECC Brainpool curves for TLS (client or server) authentication through reference in X.509 certificates according to [RFC3279] and [RFC5480] , their negotiation for key exchange according to [RFC4492] requires the definition and assignment of additional NamedCurve IDs." Your draft defines a NamedCurve ID for Curve25519, thereby enabling it to be used for key exchange. But what about "(client or server) authentication through reference in X.509 certificates..."? I'm not aware of an equivalent of RFC5639 for Curve25519. Should we create one? Or could we simply define some new ASN.1 Object Identifiers in your draft? -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From hanno@hboeck.de Tue Sep 10 02:47:44 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B2421F9CBD for ; Tue, 10 Sep 2013 02:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+72rzD6ccjZ for ; Tue, 10 Sep 2013 02:47:39 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 4930721E80DC for ; Tue, 10 Sep 2013 02:47:38 -0700 (PDT) Received: from localhost (91-66-72-249-dynip.superkabel.de [::ffff:91.66.72.249]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 10 Sep 2013 11:47:28 +0200 id 00000000000000DE.00000000522EEAB0.00004E81 Date: Tue, 10 Sep 2013 11:47:18 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20130910114718.3f7ca50e@hboeck.de> In-Reply-To: <522C3497.9020301@gmail.com> References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-20097-1378806449-0001-2" Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:47:44 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-20097-1378806449-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, 08 Sep 2013 11:25:59 +0300 Yaron Sheffer wrote: > This is an early version of my proposal for a BCP-like document, to=20 > inform the industry on what can be done with existing > implementations, while TLS 1.3 is still not ready. >=20 > I would appreciate your comments of course. Specifically, > I would like to fill in the Implementation Status table (Sec. 5) and=20 > would be glad to receive solid information (dates, planned dates,=20 > version numbers) from implementers. I was asked on another list to cross-post my comments on it here: I don't really see from the document why the authors discourage ECDHE-suites and AES-256. Both should be okay and we end up with four suites: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Also, DHE should only be considered secure with a large enough modulus (>=3D2048 bit). Apache hard-fixes this to 1024 bit and it's not =20 configurable. So there even can be made an argument that ECDHE is more secure - it doesn't have a widely deployed webserver using it in an insecure way. --=20 Hanno B=C3=B6ck http://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-20097-1378806449-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) iQIcBAEBCAAGBQJSLuqoAAoJEKWIAHK7tR5CzrsQALS3JuQWoElCFcvkUrj3gZnt uvKxiz99BlUuEVAGluoAK4NfzJvIB+9DqqpUGJVPNMHpjJoDPyHc5lUn7eM73Ijm 6CLRK09Zy3DxE/yeEJRwANl8TrSM7Ov3S/jYqARrMvEXU8Jw5Sm27xHaZwdGLyHV Zaee0g1tXkyqjLv2KuEoXwEWJjBmxIRa9D73KgxgVlpzWBT2MlpUAOX5b7tx4Myn z7VxihkRbLWQwIOYZT3X836a7fiYSrLXCoXwj4bCHDCaLn0JHowD8cHCZWkpfZeH szqJ1wlqWsmSOlqXNJXJO16cyQ/ZrAUrjxZbgp4iUUcC6h72VLIONenraOxv9wcJ IblVE0dLbYVwscJzVzB3/Qfqj7hrjouIkQfmKO1sRxL6srJoTwWpM97f/TTqgKmf jc6IOI0GserPlr5B7PWDiXACh8uS11ZXEgIVZ5F5fHaH553n25wWaKEKWP4Tvljy ORUOgluGUV7ms2tiVKpR15Xm4VSw7BT4hq/AwIijUrtFAL/8fWBPcgIT0cOWvUS4 T4HDYXebXumU2YDICXZyWem6sQDFBUWjaDD9EfYj8rHD1os4AK7sk+OVd9/gEmd/ mibRVUBbJv2ONrTa2hLaS5KJV991+81yHwcIAKTTzlSWpomMH62NfhtGQVuAglDn 6/dqtfABYHcJgsrV8w2j =OLGj -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-20097-1378806449-0001-2-- From pgut001@cs.auckland.ac.nz Tue Sep 10 02:50:36 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540D21E80F3 for ; Tue, 10 Sep 2013 02:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZhejWogv5K2 for ; Tue, 10 Sep 2013 02:50:24 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id E35A821F9B01 for ; Tue, 10 Sep 2013 02:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378806624; x=1410342624; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=heJMOKP58JIUaPAGKXyLAr3T2lz4wbT7Ud3/YiEP8VY=; b=qJj5mE0h9NKhnSkvHLx4iWY//IkOAFji//qhsoykc08hbWp95Eady8Dx XP02mJQCHytjuP7RJTXTgARH09nUNrpcrt8As85DK37YLsc+IS4QYuLaL dPSpgSeTNJj+4l34xRdNGPRXHRjjt9CoktAOtlGztWN7Z1q9Pikk/I+NJ 0=; X-IronPort-AV: E=Sophos;i="4.90,877,1371038400"; d="scan'208";a="211423468" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Sep 2013 21:50:23 +1200 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe1.UoA.auckland.ac.nz (130.216.4.112) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 10 Sep 2013 21:50:22 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 21:50:22 +1200 From: Peter Gutmann To: "michael@stroeder.com" , "tls@ietf.org" Thread-Topic: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt Thread-Index: Ac6uCypy9GIDjbo+QJuBWVQGqjAHOw== Date: Tue, 10 Sep 2013 09:50:22 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566C313@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:50:38 -0000 =3D?ISO-8859-1?Q?Michael_Str=3DF6der?=3D writes:=0A= =0A= >Do you have numbers about the relative and absolute performance impact?=0A= >Personally I don't see performance problems but I can't prove my position= =0A= >with numbers.=0A= =0A= http://www.javamex.com/tutorials/cryptography/rsa_key_length.shtml is one= =0A= source (and quicker than digging out my copy of HAC :-):=0A= =0A= With every doubling of the RSA key length, decryption is 6-7 times times = slower. =0A= =0A= Peter.= From pgut001@cs.auckland.ac.nz Tue Sep 10 02:56:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0441421E811D for ; Tue, 10 Sep 2013 02:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P7Skngd83jK for ; Tue, 10 Sep 2013 02:56:44 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id C9D7921E811E for ; Tue, 10 Sep 2013 02:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378807000; x=1410343000; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=tU0nmhSV9qCvmvQKNunw7flAAii2HqOYXNvudbz8QRc=; b=R4rB9CkU8Q7kdwjF2jzXpunsO6gqBhpFuG+s/otOZId3k9ZgwyUm0cCJ GQOae0vCbC1vdK9zPQYlaqSDkdiwEEncwgUB2juxD0eirmHUnbUqWAjh+ l1y31Jge+YQFs7CgeSVfWW0WEr9kvCYjOUSnetMyC3v6pcEXfdVddPLAn U=; X-IronPort-AV: E=Sophos;i="4.90,877,1371038400"; d="scan'208";a="211423830" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 10 Sep 2013 21:56:38 +1200 Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 21:56:37 +1200 From: Peter Gutmann To: "nmav@gnutls.org" , "benl@google.com" , "tls@ietf.org" Thread-Topic: [TLS] padding bug Thread-Index: Ac6uDAn11t03FwJUSQ2YNO6dq4H0sQ== Date: Tue, 10 Sep 2013 09:56:37 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566C373@uxcn10-tdc06.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] padding bug X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 09:56:58 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >Why not protect against future key recovery attacks by truncating the MAC?= =0A= >After all IPSec does truncate the MAC to 96-bits for exactly the same reas= on=0A= >(see RFC2104 Section 5: Truncated output). Using the existing good practic= es=0A= >is a good thing.=0A= =0A= IPsec's truncation has nothing to do with security, it was done in order to= =0A= fit the data into a 32-bit IP header boundary. Since then an army of cargo= -=0A= cult standards designers has mindlessly copied this design artefact into wh= o=0A= knows how many other standards without understanding why it was done in the= =0A= first place. It's not "good practice", it's cargo-cult standards design.= =0A= =0A= Peter.=0A= From agl@google.com Tue Sep 10 08:23:16 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1500021F99DE for ; Tue, 10 Sep 2013 08:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.771 X-Spam-Level: X-Spam-Status: No, score=-0.771 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9Sph7W2bGQn for ; Tue, 10 Sep 2013 08:23:15 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3883311E81B6 for ; Tue, 10 Sep 2013 08:22:59 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id y16so10532423ieg.26 for ; Tue, 10 Sep 2013 08:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=gbJ1jkclRYxuUPI73n7pYu1KCydsHHHAVq+L8FSUUX0=; b=TW6n0dtARX9DODRZq9Jo3MPQ/r33ctt04wFH8sZtH7IA8ft31bflm1y2X+MoCicvH0 vBs/rj9pDQuox3RmsPznnDga5LcttiMav/pt85+WT0gWkmoZY/kqAJMxuq9w8nvsFYq2 EJHfwAqvGMViolMr2CPFovZJ/nF/ANWdHAg4Qu7I3s3n3w2ExJ1yrnSVMNeMPQLcws5F PpPBE8iqcK4SH6HH7L44EraR80Ue8wbnyXYvXSGs4vhy7SPcbHOclSYNeH/3fFUhChgg 9ksTIPpYGSr1WOoZTECkprmSYMpjuDiAf8SwmGq5vCaUxHUuvnADzUWRV7pWbs7/G0b+ trIQ== 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:content-transfer-encoding; bh=gbJ1jkclRYxuUPI73n7pYu1KCydsHHHAVq+L8FSUUX0=; b=AgigY8inHj3hNakQNrcW81Y0V9vZ2TfYrxliBNZEYGnsL0qYX/9A4AfmCle5BucfUb k19onF0utwsvVN8tYO4FOqXv5bEmnP+1M/n0TbXnZRTaAXDf/CwHwEZvv+7pP8q6IW+V 0vTcDgflCJg7tIduuRkUaAZN0ROwGao7USVma8e0u62almAmITLgjiN2UHSrOn6xEesn wUEiCpXD2CfdMk97LS/OhxTZFoKiBWYq3JbyZ2jZWwaOkehlcDsLonfbRruJjoVjEU24 Oz6sfkKTTDdJsfruyKuUtLdz6vVS/SwWQg99F3htKOWmfL9FcgIjGW//K8J1rQaNyE7F XpYg== X-Gm-Message-State: ALoCoQlXb+DXCYFKzl4l38yC356vWigeS54qycZLvT8ZUo8iDIZVA/r+X69o46I+7Jmcztj1JxR9+Rzuy4ZyKpsp3dxpoSZ8+g3PQGUa9+6celOqUKUmKaSfFvTlB0Dv5iC5wBaPHB1ilrHEbU7SFHjCFMDf+8p0jn31cVYZ9kcx+zPteLCUwgST8hYooqJXf1HTykBQRPX7 X-Received: by 10.43.126.68 with SMTP id gv4mr16884icc.48.1378826578763; Tue, 10 Sep 2013 08:22:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.245.228 with HTTP; Tue, 10 Sep 2013 08:22:38 -0700 (PDT) From: Adam Langley Date: Tue, 10 Sep 2013 11:22:38 -0400 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [TLS] ChaCha20 + Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 15:23:16 -0000 I've just posted a draft defining ChaCha20+Poly1305 cipher suites for TLS: https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/ (To those who might not read this mailing list all the time, this was prompted by attacks on RC4 and CBC mode earlier this year and is not a response to any recent press stories.) Neither RC4 nor the current CBC modes are looking very attractive in light of recent attacks. AES-GCM is in the process of being deployed but both AES and GHASH are very troublesome to implement in software in a way that is fast, secure and has good key agility. Modern Intel chips implement AES-GCM in hardware and future, high-end ARM chips may also. But I expect that there will always be a large number of devices without that capability and there are currently no good options for them in TLS. I know that Nikos presented about using Salsa20+UMAC at the last meeting and, although close to this proposal, I obviously made some different choices. I picked ChaCha20 over Salsa20. ChaCha20[1] is a tweak of Salsa20 to achieve better diffusion. It is conjectured to be stronger than Salsa20 and an attack against a reduced round Salsa20 in [2] broke one fewer rounds of ChaCha20. ChaCha20 received some positive remarks at the CFRG[3] and is slightly faster. Salsa20 has been the target of more analysis. Overall, I weakly preferred ChaCha20 over Salsa20. I picked Poly1305 over UMAC/VMAC. UMAC/VMAC have a clear speed advantage (~2x) on high-end chips when key agility isn't important and Nikos indicated that such a scenario is important to him[4]. However, I think that use case is likely to be met with hardware AES-GCM implementations. Otherwise, I like the conceptual simplicity of Poly1305, the lack of precomputed tables, and the theoretical benefits of randomly varying the point at which the polynomial is evaluated. It is also currently slightly faster on ARM, although in single-key benchmarks I suspect that advantage could be eliminated with more optimisation, based on the x86-64 numbers. Overall, Poly1305 over [UV]MAC was a clearer choice than ChaCha vs Salsa. ChaCha20 is very simple and even a completely na=C3=AFve implementation will be secure. Poly1305 is somewhat more complex to implement but again lends itself to secure implementations. Several high-quality, optimised, public domains implementations are available of each. I have implemented this draft in NSS and OpenSSL. No heroic optimisation was done, but I used implementations by Andrew Moon, Ted Krovetz, djb and Peter Schwabe. The following numbers are encryption rates for a 1K block size with with AES-128-GCM or ChaCha20+Poly1305. The AES-128-GCM implementation is OpenSSL 1.0.1e compiled with gcc 4.6.3 and -O3, unless other compiler flags are noted. On an E5-2690@2.90GHz with Hyperthreading and Turboboost disabled: AES-128-GCM, AES-NI disabled: 131 MB/s AES-128-GCM, AES-NI enabled: 311 MB/s AES-128-GCM, AES-NI enabled & -march=3Dnative: 308 MB/s ChaCha20+Poly1305: 420 MB/s ChaCha20+Poly1305, -march=3Dnative: 560 MB/s On a Galaxy Nexus (ARM Cortex-A9@1.2GHz), gcc 4.7: AES-128-GCM: 27 MB/s ChaCha20+Poly1305: 78 MB/s Note that I'm being rather unfair to ChaCha20 here: I'm comparing 128-bit AES against a 256-bit ChaCha20. Intel suggests[5] that an E5-2690 (Sandy Bridge) should be able to do AES-128-GCM in ~2.55 cycles/byte, giving speeds of ~1.1GB/s. Possibly I've messed something up with OpenSSL, or the implementation in OpenSSL 1.0.1e is underperforming, but I'm reporting what I see. Of course, in general, one is not going to beat dedicated hardware in software. When both parties to a TLS connection have AES-GCM hardware implementations then AES-GCM is likely to be the most performant option. Cheers AGL [1] http://cr.yp.to/chacha/chacha-20080128.pdf [2] http://eprint.iacr.org/2007/472.pdf, section 3.5. [3] http://www.ietf.org/mail-archive/web/cfrg/current/msg03491.html [4] http://www.ietf.org/mail-archive/web/tls/current/msg09712.html [5] http://2013.diac.cr.yp.to/slides/gueron.pdf, page 17. From ynir@checkpoint.com Tue Sep 10 09:08:15 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA1521F8475 for ; Tue, 10 Sep 2013 09:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.918 X-Spam-Level: X-Spam-Status: No, score=-8.918 tagged_above=-999 required=5 tests=[AWL=1.681, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvgbQY+hcvf9 for ; Tue, 10 Sep 2013 09:08:05 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9277021F99BF for ; Tue, 10 Sep 2013 09:07:56 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8AG7r3q031872; Tue, 10 Sep 2013 19:07:53 +0300 X-CheckPoint: {522F43D9-9-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Tue, 10 Sep 2013 19:07:53 +0300 From: Yoav Nir To: Adam Langley Thread-Topic: [TLS] ChaCha20 + Poly1305 in TLS Thread-Index: AQHOrjmxRJ1QpN2c0UyG/dubgYCJVZm+8RCA Date: Tue, 10 Sep 2013 16:07:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.100] x-kse-antivirus-interceptor-info: protection disabled Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 16:08:15 -0000 On Sep 10, 2013, at 6:22 PM, Adam Langley wrote: > The following numbers are encryption rates for a 1K block size with > with AES-128-GCM or ChaCha20+Poly1305. The AES-128-GCM implementation > is OpenSSL 1.0.1e compiled with gcc 4.6.3 and -O3, unless other > compiler flags are noted. >=20 > On an E5-2690@2.90GHz with Hyperthreading and Turboboost disabled: >=20 > AES-128-GCM, AES-NI disabled: 131 MB/s > AES-128-GCM, AES-NI enabled: 311 MB/s > AES-128-GCM, AES-NI enabled & -march=3Dnative: 308 MB/s > ChaCha20+Poly1305: 420 MB/s > ChaCha20+Poly1305, -march=3Dnative: 560 MB/s >=20 > On a Galaxy Nexus (ARM Cortex-A9@1.2GHz), gcc 4.7: >=20 > AES-128-GCM: 27 MB/s > ChaCha20+Poly1305: 78 MB/s >=20 > Note that I'm being rather unfair to ChaCha20 here: I'm comparing > 128-bit AES against a 256-bit ChaCha20. >=20 > Intel suggests[5] that an E5-2690 (Sandy Bridge) should be able to do > AES-128-GCM in ~2.55 cycles/byte, giving speeds of ~1.1GB/s. Possibly > I've messed something up with OpenSSL, or the implementation in > OpenSSL 1.0.1e is underperforming, but I'm reporting what I see. I'm seeing 500 MB/s for AES-GCM on an Intel E5645@2.40Ghz, which is an olde= r Westmere with a somewhat slower clock speed and OpenSSL 1.0.1-something. = If I had to guess, you're using the MMX version of the ghash/gmult function= s rather than the PCLMULQDQ version.=20 Regardless, we need an alternative to AES. RC4 is out because of security, = and 3DES is around a tenth the speed. Going back to 3DES means your hardwar= e is not strong enough to handle your current load. ChaCha+poly1305 seems t= o be a good fallback, so I support the publication. Yoav From hughejp@mac.com Tue Sep 10 09:12:07 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8408911E81E0 for ; Tue, 10 Sep 2013 09:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.99 X-Spam-Level: ** X-Spam-Status: No, score=2.99 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ9QNEApezOh for ; Tue, 10 Sep 2013 09:11:49 -0700 (PDT) Received: from st11p06mm-asmtp001.mac.com (st11p06mm-asmtp004.mac.com [17.172.124.249]) by ietfa.amsl.com (Postfix) with ESMTP id 0242311E81E2 for ; Tue, 10 Sep 2013 09:11:49 -0700 (PDT) Received: from [10.0.1.221] (c-50-161-102-106.hsd1.ca.comcast.net [50.161.102.106]) by st11p06mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.07(7.0.4.27.6) 64bit (built Jun 21 2013)) with ESMTPSA id <0MSX00JBV3NDHM40@st11p06mm-asmtp001.mac.com> for tls@ietf.org; Tue, 10 Sep 2013 16:11:39 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-10_07:2013-09-10, 2013-09-10, 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-1305240000 definitions=main-1309100096 From: james hughes Content-type: multipart/alternative; boundary="Apple-Mail=_DDFF39D1-3434-4D02-ACC8-6E6F380251B9" Date: Tue, 10 Sep 2013 09:11:36 -0700 Message-id: <364EDF7D-05B1-4216-A3EA-DCA86C5D42B6@mac.com> To: TLS MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: Re: [TLS] New Version Notification for draft-sheffer-tls-bcp-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Sep 2013 16:13:02 -0000 --Apple-Mail=_DDFF39D1-3434-4D02-ACC8-6E6F380251B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 9, 2013, at 7:30 PM, Michael Str=F6der = wrote: >=20 > > Peter Gutmann wrote: >=20 >> > Do you have numbers about the relative and absolute performance = impact? >> > Personally I don't see performance problems but I can't prove my = position with >> > numbers. >=20 > MBA-2:tmp synp$ openssl speed dsa1024 dsa2048 [=85] > sign verify sign/s verify/s > dsa 1024 bits 0.000445s 0.000515s 2247.6 1941.8 > dsa 2048 bits 0.001416s 0.001733s 706.4 577.2 We are arguing about a key exchange that goes from ~1ms to ~3ms (where = the cracking goes from "yes" to "no"). Yes, this is more but this is = absolutely not a problem for PCs or even phones or tablets especially in = the light of session keep alive and other techniques that allow a key = exchange to last a while.=20 Is the complaint that the server load is too high?=20 Lastly, going a partial step seems strange also. Why do we what to put = ourselves through this again so soon? The French government suggests = 2048 now (for both RSA and DHE), and will only last 6 years. =46rom=20 http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf > La taille minimale du module est de 2048 bits, pour une utilisation ne = devant pas depasser lannee 2020. The minimum size of the modulus is 2048 bits for use not to exceed 2020. > Pour une utilisation au-dela de 2020, la taille minimale du module est = de 4096 bits For use beyond a 2020, the minimum module size is 4096 bits Pardon the bad cut/paste and google translate, but I believe you get the = point.=20 --Apple-Mail=_DDFF39D1-3434-4D02-ACC8-6E6F380251B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 
On Sep =
9, 2013, at 7:30 PM, Michael Str=F6der <michael at stroeder.com> =
wrote:

> =
Peter Gutmann wrote:

> Do you have numbers about the relative and =
absolute performance impact?
> Personally I don't see =
performance problems but I can't prove my position with
> =
numbers.

MBA-2:tmp synp$ openssl =
speed dsa1024 dsa2048
[=85]
        =
         sign    verify   =
 sign/s verify/s
dsa 1024 =
bits 0.000445s 0.000515s   2247.6   =
1941.8
dsa 2048 bits 0.001416s =
0.001733s    706.4   =
 577.2

We are arguing about =
a key exchange that goes from ~1ms to ~3ms (where the cracking goes from =
"yes" to "no"). Yes, this is more but this is absolutely not a problem =
for PCs or even phones or tablets especially in the light of session =
keep alive and other techniques that allow a key exchange to last a =
while. 

Is the complaint that the server =
load is too high? 

Lastly, going a =
partial step seems strange also. Why do we what to put ourselves through =
this again so soon? The French government suggests 2048 now (for both =
RSA and DHE), and will only last 6 years. From 

La taille minimale du module est de 2048 bits, pour une =
utilisation ne devant pas depasser lannee 2020.
The minimum =
size of the modulus is 2048 bits for use not to exceed =
2020.

Pour une utilisation au-dela de =
2020, la taille minimale du module est de 4096 bits
For use =
beyond a 2020, the minimum module size is 4096 bits

Pardon the bad =
cut/paste and google translate, but I believe you get the =
point. 

=

--Apple-Mail=_DDFF39D1-3434-4D02-ACC8-6E6F380251B9--

From jsalowey@cisco.com  Tue Sep 10 10:17:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E3321F8F78 for ; Tue, 10 Sep 2013 10:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBPt+Jc9f6He for ; Tue, 10 Sep 2013 10:17:14 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4248521F90DC for ; Tue, 10 Sep 2013 10:17:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=850; q=dns/txt; s=iport; t=1378833434; x=1380043034; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uZQ+c/Op9glFLt5aHZA/dQGiwnck1HzIAmZ/lkEkFLw=; b=bfweQYJk/tChSPGg6HtZv4UzE9uzjB39GjNr9xgrauyQ/actwwwxwlHx DsyzUY7yGYUW4ZlGq4dpdEkpn+9qx45lW7PtMn16VG3HAXbP9E9bF7QSS JTkAqicUJs90BbYrv0hj3z6DDmAr8ihqEoq7gZiFFWv+PLHucJ6/yfhDG 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: As0GAMpSL1KtJXHA/2dsb2JhbABbgwc4RQEBCoJjv12BJRZ0giUBAQEDAQEBARodNAsFCwIBCCIUECcLJQIEDgUIh3QGDL97jygCMQeDHYEAA5klkDyBY4E9gio
X-IronPort-AV: E=Sophos;i="4.90,879,1371081600"; d="scan'208";a="257931056"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 10 Sep 2013 17:17:14 +0000
Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8AHHDlg030500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Sep 2013 17:17:13 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.162]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 12:17:13 -0500
From: "Joseph Salowey (jsalowey)" 
To: "Joseph Salowey (jsalowey)" 
Thread-Topic: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tls-applayerprotoneg-01)
Thread-Index: AQHOmgayI7Fz7QRaikC2dRjq1euU/Zm/svEA
Date: Tue, 10 Sep 2013 17:17:12 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.33.248.54]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <209EA970E4D0634EAC73AF3033CB1863@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tls-applayerprotoneg-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Sep 2013 17:17:19 -0000

The working group last call for draft-ietf-tls-applayerprotoneg-01 has comp=
leted.  There is consensus in moving this work forward with some fixes to t=
he IANA section and some editorial nits.   I am going to ask the authors to=
 submit a revised draft which will be submitted to the IESG. =20

Thanks,

Joe


On Aug 15, 2013, at 3:27 PM, Joseph Salowey (jsalowey) =
 wrote:

> This is the working group last call for draft-ietf-tls-applayerprotoneg-0=
1. Please send your reviews and comments to the TLS list by September 6, 20=
13. =20
>=20
> The draft can be found at http://tools.ietf.org/html/draft-ietf-tls-appla=
yerprotoneg-01
>=20
> Thanks,
>=20
> Joe
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From n.mavrogiannopoulos@gmail.com  Tue Sep 10 10:23:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E8121F9E68 for ; Tue, 10 Sep 2013 10:23:21 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHZIRWEd6QGP for ; Tue, 10 Sep 2013 10:23:21 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0F38021F9E4F for ; Tue, 10 Sep 2013 10:23:19 -0700 (PDT)
Received: by mail-lb0-f181.google.com with SMTP id u14so6482069lbd.40 for ; Tue, 10 Sep 2013 10:23:18 -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=JnkqyaRc1NECAe6PI+vZl4xgyAUUOnX09uMyHbqVdY0=; b=DXn7T0PIUlIxNA1kpC7AudXT+8XWWxdtnuwi6undKUPBrkpWSysygaCMdITOulus4q B2co7FbPmOO7fnjGC3xhjg/7inb/TjK+2qtDYB5bxj1Rq9wsFeX6VwoZLBXXcJ9e/3Nl fY5MBzP3rFXbh/eYTomUaHyZnDpQUqGPQ9TeXjAFT8wYhYn+nrvdUybCju7RnVFEnx/t 0Vpyr4E7QlbjNqXnEM0jQ4tPuCEXOUpSuHmUYPQxY5Z0PlGmxUmmA2D++2KHqPgOoYON 8cdAYZ7VOMmAasFyojVtDTsUy7E+p7VPGUOVud80flZYJeKzm0JHN95BafqLSCBbR5E+ G++g==
MIME-Version: 1.0
X-Received: by 10.152.37.103 with SMTP id x7mr7451969laj.28.1378833798913; Tue, 10 Sep 2013 10:23:18 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.63.66 with HTTP; Tue, 10 Sep 2013 10:23:18 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735566C373@uxcn10-tdc06.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C735566C373@uxcn10-tdc06.UoA.auckland.ac.nz>
Date: Tue, 10 Sep 2013 19:23:18 +0200
X-Google-Sender-Auth: 170BpiyWV5O-mHtD--1NZZe3l_g
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: Peter Gutmann 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Sep 2013 17:23:21 -0000

On Tue, Sep 10, 2013 at 11:56 AM, Peter Gutmann
 wrote:

>>Why not protect against future key recovery attacks by truncating the MAC?
>>After all IPSec does truncate the MAC to 96-bits for exactly the same reason
>>(see RFC2104 Section 5: Truncated output). Using the existing good practices
>>is a good thing.
> IPsec's truncation has nothing to do with security, it was done in order to
> fit the data into a 32-bit IP header boundary.  Since then an army of cargo-
> cult standards designers has mindlessly copied this design artefact into who
> knows how many other standards without understanding why it was done in the
> first place.  It's not "good practice", it's cargo-cult standards design.

Do you have any reference for that? RFC2104 and the paper it
references claim otherwise.

regards,
Nikos

From prvs=296557a8eb=uri@ll.mit.edu  Tue Sep 10 10:37:08 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0659A21E811D for ; Tue, 10 Sep 2013 10:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Level: 
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsLpzobUA6hg for ; Tue, 10 Sep 2013 10:37:02 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id D8C7721E8166 for ; Tue, 10 Sep 2013 10:36:57 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8AHU8Qs026836; Tue, 10 Sep 2013 13:36:46 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Nikos Mavrogiannopoulos , Peter Gutmann 
Date: Tue, 10 Sep 2013 13:36:21 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac6uTEZTB+tnxvvZR16glBwfnj2LoA==
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3461664981_56613"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-10_08:2013-09-10, 2013-09-10, 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-1305240000 definitions=main-1309100105
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Sep 2013 17:37:08 -0000

--B_3461664981_56613
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 9/10/13 13:23 , "Nikos Mavrogiannopoulos"  wrote:

>On Tue, Sep 10, 2013 at 11:56 AM, Peter Gutmann
> wrote:
>
>>>Why not protect against future key recovery attacks by truncating the
>>>MAC?
>>>After all IPSec does truncate the MAC to 96-bits for exactly the same
>>>reason
>>>(see RFC2104 Section 5: Truncated output). Using the existing good
>>>practices
>>>is a good thing.
>> IPsec's truncation has nothing to do with security, it was done in
>>order to
>> fit the data into a 32-bit IP header boundary.
>
>Do you have any reference for that? RFC2104 and the paper it references
>claim otherwise.

I participated in that discussion back then, and confirm that the big
reason for truncating the MAC was security: specifically achieving a good
balance between resistance to MAC forging attacks and resistance to key
recovery attacks.

--B_3461664981_56613
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD
F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0
B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p
rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr
i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8
11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB
BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw
PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/
inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd
XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq
oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5
48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ
/Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw
ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J
VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v
dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w
HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT
Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg
MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK
Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2
QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z
XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK
sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn
qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G
CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny
bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG
MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3
EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G
CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk
zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm
UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD
2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU
meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB
snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw
CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD
UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz
NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx
DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv
f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT
XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/
hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX
TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW
6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y
EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G
CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I
1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P
yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/
LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr
oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90
ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw
EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL
MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT
BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X
519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb
z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn
w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3
sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8
B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD
VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH
AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ
KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC
AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn
+t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f
NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU
3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ
aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw
ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv
cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg
hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDfxHl9No6cXv6kcf1bpRwQwa2RFBAuIWvu
GOrGrGKg+jAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5
MTAxNzM2MjFaMA0GCSqGSIb3DQEBAQUABIIBABiSBkNnBiZucVpGQj/BhzDZEY6Zngb22isK
g/v9hIlwWMqbQtCA1fpHDPuJk47MIwEr4JDUgXJJtgP1vKjYaIZpVzrcgdiNNcpGXIMkkQ5j
THVqK8HMQG+zN9fpbQFIByUZzJQupfHqfkFTMBC2AG0std69wUXz1QPkTm2qVUm6Iray7+In
ISUkt6UJtbzSHbPyUroDcuUXSnUvzDYvgFCWQRSaRJ6B/rDB2p9KOjBIRkR8pPYrqP7WKB1W
alVd6V2H+yPw3f0ogakyY0oC2OtckkBUzyZIDkbZwJdevltPIUxYqdTz60QSRdQMjhaFlo30
oL5doK3G0Ill6fa04UQ=

--B_3461664981_56613--

From agl@google.com  Tue Sep 10 15:08:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB02F21E80C4 for ; Tue, 10 Sep 2013 15:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.375
X-Spam-Level: 
X-Spam-Status: No, score=-1.375 tagged_above=-999 required=5 tests=[AWL=0.603,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCe2E0+nh-cJ for ; Tue, 10 Sep 2013 15:08:46 -0700 (PDT)
Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED5321E80A1 for ; Tue, 10 Sep 2013 15:08:46 -0700 (PDT)
Received: by mail-oa0-f50.google.com with SMTP id i4so8575020oah.37 for ; Tue, 10 Sep 2013 15:08:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=DvvxbvGOzSl1FfJ1sd/RQJCOT/A6YnnSOaq1kmAQOIw=; b=NljuOrEQA7XHYdd3gcSFFv5vDZqlePhByuAeHoUuUyvweUOscsvB/yWXXE+jiFITli XtQkdd08z7gPM5R/CMurW4cWML1e71vcHU/b8fDxXrstCGp1dxbRbr6MeqQ5yiEZ0iSF WdBrV/RnplznUFX9d6+ypa68R5KEmzbywO/05VX95Ga2QafaFe1x6DDp+6jiGWngBYg2 37eiWPVPEpdA6HQKmgbyGJ62MfFB2GAqBG9QH2M6sOgIYbGitCD07gHp2qmPFpPIAzZc 6FsRv7ne2ZuT/1N1/v2LJ3BLgYY8WyoFloNB/taXQSW9//HkhQBdqxPeDRMsRHvMyWsW s6eQ==
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:content-type; bh=DvvxbvGOzSl1FfJ1sd/RQJCOT/A6YnnSOaq1kmAQOIw=; b=g16WRPpdn0l3ANuuuHuRzc5GdyaM6aeg3DDgnkIYQxYzNXOro2tm5/N8Cw53ahsUNA /9+rFi/Mm2Yej8FSpDiAlpga43dWDR1/4rXcuzZ9M6DuPYaBAtbGVNgLzE3Rvi19bM19 SefMYlD9wc/nF/s8q+qVIujJKfrsO/0crNHL/KSghCkFKctVRiugp2PDH3T64Azg1Jon 9pr1NBd/HNc57ffhbXUrvoL0Z6MejfDhgIJuxxnetTA8nsZKs3dqb7dKTo3RQLUrDJIt kwPLli7pPUVAflivnEdIlFLuEzxnrDwH0A57kfzODFOw7CHBnK9smS1qWK82e6tdyHyL PAeg==
X-Gm-Message-State: ALoCoQklTt6ytu3RsUh4gxNBm0HJ82GolJOwaMrw3RE+41FylhGrE7KNJSWwnsXUcsN0MdXmRdH4HzMV3fyOUKjG2wUC0j1igmrG0o0vkqJb3h4FBN0Ha1xRrJ0iqRbPOu7qfjefUxJC/AvMDZxKJ0Na76UXWjghtnVnOd0zNL7nLkKcyGQuPEO85BI9lPzFXl4WAB/BIWLf
X-Received: by 10.182.75.201 with SMTP id e9mr5461408obw.28.1378850925767; Tue, 10 Sep 2013 15:08:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.79.105 with HTTP; Tue, 10 Sep 2013 15:08:25 -0700 (PDT)
In-Reply-To: 
References: 
From: Adam Langley 
Date: Tue, 10 Sep 2013 18:08:25 -0400
Message-ID: 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 10 Sep 2013 22:08:47 -0000

On Tue, Sep 10, 2013 at 11:22 AM, Adam Langley  wrote:
> Intel suggests[5] that an E5-2690 (Sandy Bridge) should be able to do
> AES-128-GCM in ~2.55 cycles/byte, giving speeds of ~1.1GB/s. Possibly
> I've messed something up with OpenSSL, or the implementation in
> OpenSSL 1.0.1e is underperforming, but I'm reporting what I see.

I found what I had messed up in OpenSSL: AES-NI was in use, but only
block-by-block, not pipelined.

The AES-128-GCM speed on the E5-2690 with AES-NI enabled should be 868 MB/s.


Cheers

AGL

From pgut001@cs.auckland.ac.nz  Tue Sep 10 23:02:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E31921F9D96 for ; Tue, 10 Sep 2013 23:02:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GQXvp2USYZJ for ; Tue, 10 Sep 2013 23:02:36 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 56B2F21F99B0 for ; Tue, 10 Sep 2013 23:02:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378879357; x=1410415357; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=KhgXqNqjxE5tvbdybjHt63FDZQFkzopH8bpCIhnRZII=; b=OzPf+tLv+176R2yz6TbVMPU183g3DLnq8Zhp0zAVxzSNNZhIoiq67zsJ Bhmltt1pG7oOVZzdl4DFj0fzlRECyfEu7pAJvVKUEi8+TxG7d4pj2yRMi L2o0vRWKQEHJSI3JJfqIxyHlUhY9Lhzi5Uy/JQFmjZn0Fo8CUgdDyXl/j M=;
X-IronPort-AV: E=Sophos;i="4.90,882,1371038400"; d="scan'208";a="211587874"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Sep 2013 18:02:33 +1200
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Wed, 11 Sep 2013 18:02:32 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Wed, 11 Sep 2013 18:02:32 +1200
From: Peter Gutmann 
To: "benl@google.com" , "tls@ietf.org" , Nikos Mavrogiannopoulos 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac6utICp7mSLAskDTOGCo4UDc+wUpA==
Date: Wed, 11 Sep 2013 06:02:31 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566CD97@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 06:02:42 -0000

Nikos Mavrogiannopoulos =0A=
=0A=
>Do you have any reference for that? RFC2104 and the paper it references =
=0A=
>claim otherwise.=0A=
=0A=
Oh man, that'd require ploughing through 15-year-old email discussions...=
=0A=
to see it in effect, look at section 2 of RFC 2402.=0A=
=0A=
Peter.=0A=

From lists@drh-consultancy.co.uk  Wed Sep 11 05:30:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEFC11E820D for ; Wed, 11 Sep 2013 05:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBdMurNjrTIh for ; Wed, 11 Sep 2013 05:30:52 -0700 (PDT)
Received: from claranet-outbound-smtp02.uk.clara.net (claranet-outbound-smtp02.uk.clara.net [195.8.89.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC4411E810B for ; Wed, 11 Sep 2013 05:30:51 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:14888 helo=[192.168.7.9]) by relay02.mail.eu.clara.net (relay.clara.net [213.253.3.42]:10465) with esmtpa (authdaemon_plain:drh) id 1VJjZ5-0007In-6r  (return-path ); Wed, 11 Sep 2013 12:30:36 +0000
Message-ID: <52306269.7020200@drh-consultancy.co.uk>
Date: Wed, 11 Sep 2013 13:30:33 +0100
From: Dr Stephen Henson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Adam Langley 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 12:30:57 -0000

On 10/09/2013 16:22, Adam Langley wrote:
> I've just posted a draft defining ChaCha20+Poly1305 cipher suites for
> TLS: https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/
> 

Which versions of TLS is this aimed at, TLS 1.2 (and later) only or earlier
versions too?

Would it make sense to include some DHE ciphersuites as well as the ECDH ones
for implementations which (for whatever reason) do not support or disable ECDH?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From benl@google.com  Wed Sep 11 05:47:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B231121E80FE for ; Wed, 11 Sep 2013 05:47:43 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1Yk9bpEvqF6 for ; Wed, 11 Sep 2013 05:47:42 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 81A6821E80AA for ; Wed, 11 Sep 2013 05:47:42 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id to1so8464116ieb.37 for ; Wed, 11 Sep 2013 05:47:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rzelrfsJOezH2BPrNQKCcwa9bdjeAYrzXtIeNOGh/wM=; b=V7rT+FauCTU+yy4EjsY1GKT5Rz9c4WqezZ+Kz0IAOSJEGja2hN2ZN5Aml6ufaedx1h StbdFLTBsjyUXahQJk5f+5/8HHHwClkwaQxTCkJC8XylEWmswp0GHnLBKF2uP5kfJymV qkiogErGIS4O/ptB5skvk4vsJCNaVvUuIBjdFs9ZwoenQtlqVDh5j8DriyPGaT05Amwp yd5CU2JYal4eljd2x7bQ7KCkyqU4Mb4g3R4p3u5KbFDG/m7s07TABb5LIfs4lvYCtStn JsZM2oYpyqhwv67GqnrdcppTJqlatmhTH8dNnAE7nXNhkiWBu9OGBCVBWR98Knb4GHpT HAaQ==
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=rzelrfsJOezH2BPrNQKCcwa9bdjeAYrzXtIeNOGh/wM=; b=bY0zRjLZk0jO4hQDeoi54IMdAFtuswo+QdBgCBkjXRG1CBIclkvwlhfINC29rCwlQR 31FqtNN782huro9qJyLyy0a7h9kmoHHkIzFHMGLwElZhfhZIJc+WgYBBWNNq5bR9Da/l qDTdYAe4D2AgCSxMS29HHQiiBtKtbrE8VpyjPbo2mGWq52Gjv7809kTtNzJhWpFht62g 7C9NGQS4pCIUwJ3YTWAReP/I0LWm5nsq5wjYVWsKR76E6nWaxdtuwz0uB58849cQ8oYy 2C4APMChzsnD5/STUEkTV/5HhuEdRcInPFLcmjNgfMLeY4K/9hJ7U4V48iLlcx/6bVva jWBw==
X-Gm-Message-State: ALoCoQncBEavca3t5rprOFedtKl5c+hA0POrn9v85D23bYqUkObFVxaCfaiUTVp+DC62Z5CTV5daBRP8Jz8jhSmdhdT7vGG9RlCumdoV4Jm8Rf6yWI+BzM4KVcMuL9uM53nwquYqghjT61UIaEwX4dFcse8IHdoYJkniMiVfAMKKAWysaPaPRw5trippr49aynUzw+djS7Kb
MIME-Version: 1.0
X-Received: by 10.50.108.71 with SMTP id hi7mr293450igb.59.1378903662024; Wed, 11 Sep 2013 05:47:42 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Wed, 11 Sep 2013 05:47:41 -0700 (PDT)
In-Reply-To: <52306269.7020200@drh-consultancy.co.uk>
References:  <52306269.7020200@drh-consultancy.co.uk>
Date: Wed, 11 Sep 2013 13:47:41 +0100
Message-ID: 
From: Ben Laurie 
To: Dr Stephen Henson 
Content-Type: multipart/alternative; boundary=089e0149c4a0f4ad4304e61b06f0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 12:47:43 -0000

--089e0149c4a0f4ad4304e61b06f0
Content-Type: text/plain; charset=ISO-8859-1

On 11 September 2013 13:30, Dr Stephen Henson
wrote:

> On 10/09/2013 16:22, Adam Langley wrote:
> > I've just posted a draft defining ChaCha20+Poly1305 cipher suites for
> > TLS: https://datatracker.ietf.org/doc/draft-agl-tls-chacha20poly1305/
> >
>
> Which versions of TLS is this aimed at, TLS 1.2 (and later) only or earlier
> versions too?
>

Good point, should be explicit about that - we're aiming at all versions.


>
> Would it make sense to include some DHE ciphersuites as well as the ECDH
> ones
> for implementations which (for whatever reason) do not support or disable
> ECDH?
>
> Steve.
> --
> Dr Stephen N. Henson.
> Core developer of the   OpenSSL project: http://www.openssl.org/
> Freelance consultant see: http://www.drh-consultancy.co.uk/
> Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--089e0149c4a0f4ad4304e61b06f0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On 11 September 2013 13:30, Dr Stephen Henson <=
;lists@drh=
-consultancy.co.uk> wrote:


On 10/09/2013 16:22, Adam =
Langley wrote:

> I've just posted a draft defining ChaCha20+Poly1305 cipher suites =
for

> TLS: https://datatracker.ietf.org/doc/draft-agl-tl=
s-chacha20poly1305/

>




Which versions of TLS is this aimed at, TLS 1.2 (and later) only or e=
arlier

versions too?

Good point, should be exp=
licit about that - we're aiming at all versions.
=A0




Would it make sense to include some DHE ciphersuites as well as the ECDH on=
es

for implementations which (for whatever reason) do not support or disable E=
CDH?



Steve.

--

Dr Stephen N. Henson.

Core developer of the =A0 OpenSSL project: http://www.openssl.org/

Freelance consultant see: http://www.drh-consultancy.co.uk/

Email: shenson@drh-consult=
ancy.co.uk, PGP key: via homepage.


_____________________=
__________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--089e0149c4a0f4ad4304e61b06f0--

From agl@google.com  Wed Sep 11 07:08:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBDC21E80D1 for ; Wed, 11 Sep 2013 07:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.576
X-Spam-Level: 
X-Spam-Status: No, score=-1.576 tagged_above=-999 required=5 tests=[AWL=0.402,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmyOzRj-1nAu for ; Wed, 11 Sep 2013 07:08:50 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id E9D3921F9DFB for ; Wed, 11 Sep 2013 07:08:49 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id o17so9210713oag.21 for ; Wed, 11 Sep 2013 07:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UF8K60JN8GXdFAXobgOUIzGYz80gMFGJx5Qf4Ow+QQo=; b=QYNoDyvj26+wTKwjZy6ilJy1rb++sJIRbhbVIRhCPgbxInxz8+i1VDB2+L66yxWmFY X55LWsdAWD+bFw1qXkeyreyh5kiofYLHoRDA3AfhJVPYiZh1CpK3IrmQKGNytENATC/A J30gNSuE4BpbfXid6M0wGzbz9JwwjOS8+03nzy+CPpLB70MfH/8kZG1/LxhRRSIXF6ab B3nu5FpiFIk1BeDSF5seIhLqOL68oei8ncYaneK/D5ATlfaT3zw4jQFv/wrI2rXPz1mg GquiorEJvEdSIOrQtjGxC4uYXiKOUkMaKOGWToe/OJE9EWz4G/c1DJ+JavPLAktYVXqt qM7Q==
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=UF8K60JN8GXdFAXobgOUIzGYz80gMFGJx5Qf4Ow+QQo=; b=C5tULQ2s76XoVYYxrjqI3MNn5ySlpMo3luWUGfpa1TcyuSQKiOcPmph98yo0nLFf33 zqdVjxfsMQopIacDDV9ojVdzKmv7+n7zyviZ9WibJgIeS1HNsJABa3U6QWE5UbEWF75N RR1BJeeYv3iICgdo/3Bg11wqAlPg+WShedrSIYiXL0qvUdUzrAwEA6CRC3MnMdKvqWEP jN91TT5GKAjTDjFdySBdyRFETV1rSkQrpPs2XvGSZTRF6Y/pbBfXdaK89mtMCyP9BizI Z+FzzV0tO4mAATUZsmNLPjHWiWYYooVauwOBYU93z8zRQn4CRdNm1gkLhurF6pIQgxr7 bhbg==
X-Gm-Message-State: ALoCoQmYwMThJAUkyMGzMgLIoNfX9DIK4aLi/WLDTlqQqz33rsdEjNbxePRlsJInDBTZMvqeZmw4Asj1JOxMA7m38vtmfV93QxBIOKfZmdLPyhEwzC88h1p6I0Oe9+NF+bF2SFJaPHLfGeiqrkisDqpfAOqLNdjIRCS/z0vungcWXzZgn5RlLloKH8lV3mS6qyqAvfvTIbex
X-Received: by 10.182.113.195 with SMTP id ja3mr1649393obb.46.1378908529256; Wed, 11 Sep 2013 07:08:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.79.105 with HTTP; Wed, 11 Sep 2013 07:08:28 -0700 (PDT)
In-Reply-To: <52306269.7020200@drh-consultancy.co.uk>
References:  <52306269.7020200@drh-consultancy.co.uk>
From: Adam Langley 
Date: Wed, 11 Sep 2013 10:08:28 -0400
Message-ID: 
To: Dr Stephen Henson 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 14:08:51 -0000

On Wed, Sep 11, 2013 at 8:30 AM, Dr Stephen Henson
 wrote:
> Which versions of TLS is this aimed at, TLS 1.2 (and later) only or earlier
> versions too?

Since it's defined as an AEAD, technically it's only compatible with
TLS 1.2 - same as AES-GCM.

However, the reality, at least for browsers, is that we cannot depend
on TLS's version negotiation because of bugs in servers. Therefore, in
practice, I'm planning on making some or all AES-GCM and
Chacha20-Poly1305 ciphersuites work for all versions. For SSLv3,
ECDHE/ECDSA variants will implicitly indicate support for
P-{256,384,521} and uncompressed points since SSLv3 cannot carry the
EC extensions needed to indicate that.

I don't know whether, in standards land, that will be explicit.

> Would it make sense to include some DHE ciphersuites as well as the ECDH ones
> for implementations which (for whatever reason) do not support or disable ECDH?

I would like to support only ECDHE-ECDSA at this point but RSA has
significant inertia because of the CA system. On reflection, it does
seem reasonable that some implementations might not want the weight of
an ECC implementation given that they have to have
multiplicative-modexp for RSA anyway. So I've spun version -01 with
with a DHE_RSA ciphersuite too.


Cheers

AGL

From nick.a.mathewson@gmail.com  Wed Sep 11 08:10:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CCE21E8118 for ; Wed, 11 Sep 2013 08:10:25 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DNOzKCeTXEi for ; Wed, 11 Sep 2013 08:10:25 -0700 (PDT)
Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1C1B711E81B3 for ; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
Received: by mail-qe0-f48.google.com with SMTP id nd7so4518517qeb.21 for ; Wed, 11 Sep 2013 08:10:24 -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=ldjMmi/gC69s9X66kpD9oge2Ky+yVpS8UKitQM0Mmlc=; b=E0opElzNAma0ZqATe3ZA/PWwI3b9LjA3ZXbJBagNmLAb8veGALGZiVj6uWJwhNZmfS qc9pIxWjpNorI9p3N5bInw0nKaVPCKl8EBK/fnsib6Z8564M1d7NBG9yg5mRdQk3Cxkb 0veAryAACQEnHSK1Y8IQVvozjKRcpuWgOL+/vOgDDj/CecvbFEuBoqCYFxRnINlpSKUu SwjQHMav6p1xbizWTkDs+eMsDzfkkkNkXxTKkyIsOUUJUOlxTjYJWfrXyDktMGbMzazo 4I+XhduI13SVdwwSELm0DA9RFhLR3UnbvuX8Kr9O65352xLg83hdav9u7qEOuu7NNDnI mw5A==
MIME-Version: 1.0
X-Received: by 10.49.1.9 with SMTP id 9mr3920832qei.51.1378912224515; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 08:10:24 -0700 (PDT)
In-Reply-To: <20130910012240.5595281.33313.3530@certicom.com>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au>   <20130910012240.5595281.33313.3530@certicom.com>
Date: Wed, 11 Sep 2013 11:10:24 -0400
X-Google-Sender-Auth: tuRikIhrx4iarglgWAPMaK4tkVY
Message-ID: 
From: Nick Mathewson 
To: Dan Brown 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 15:10:25 -0000

On Mon, Sep 9, 2013 at 9:22 PM, Dan Brown  wrote:
> I'm the current editor of ANSI X9.62 and X9.63, but joined X9F1 a little later than the time in question, so am not the best historical source.
>
> Anyway, I had thought the 15 NIST curves were included in ANSI X9.63 in 2001, but most were not in X9.62 in its first 1998 version, and only added in the 2005 version.
>
> The curve seed sources were not documented in ANSI or NIST docs. I've wondered about it a few times, but could never see a concrete problem. At least intuitively, it would only be a problem if:
>
> 1) a large fraction of elliptic curves were weak, or
>
> 2) sha1 preimages are easy to find and some unknown but rare class of elliptic curves are weak.
>
> Both of these would undermine more than just the curve choice, and seem extremely unlikely.

That's true, so long as "large fraction" and "rare" are defined
appropriately.  But I think what most of the people who worry about
this are worried about is something like:

3) A small-ish fraction of elliptic curves (say, one in every
quadrillion or quintillion or so) has some as-yet-unknown weakness,
and building a sha1 brute-forcing engine to find seeds that would
produce such curves was economically viable the late 1990s.

After a little time investigating SHA1 speeds on late-1990s FPGAs,
special-purpose chips, and general purpose CPUs, a
back-of-the-envelope calculation suggests that, given about ten
million dollars of hardware and about half a year's worth of
processing time, searching quintillions of seeds to find curves with
desired properties wouldn't have been unrealistic.

Now, none of this means that the seeds in question actually _were_
chosen in any hostile way, of course. But it would make it more
comforting if anybody could point out where the seeds actually came
from.

best wishes,
-- 
Nick Mathewson

From ynir@checkpoint.com  Wed Sep 11 08:28:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7D611E819C for ; Wed, 11 Sep 2013 08:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.542
X-Spam-Level: 
X-Spam-Status: No, score=-9.542 tagged_above=-999 required=5 tests=[AWL=1.057,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWO4Y6C4aEzq for ; Wed, 11 Sep 2013 08:27:57 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id A0BDF21F9DA1 for ; Wed, 11 Sep 2013 08:26:39 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8BFQMDL015150; Wed, 11 Sep 2013 18:26:22 +0300
X-CheckPoint: {52308B9D-12-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 11 Sep 2013 18:26:22 +0300
From: Yoav Nir 
To: Adam Langley 
Thread-Topic: [TLS] ChaCha20 + Poly1305 in TLS
Thread-Index: AQHOrjmxRJ1QpN2c0UyG/dubgYCJVZnARqyAgAAbXACAABVXgA==
Date: Wed, 11 Sep 2013 15:26:21 +0000
Message-ID: 
References:  <52306269.7020200@drh-consultancy.co.uk> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.1]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <277C600B6DB96041B045D75047B5C843@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 15:28:11 -0000

On Sep 11, 2013, at 5:08 PM, Adam Langley  wrote:

>> Would it make sense to include some DHE ciphersuites as well as the ECDH=
 ones
>> for implementations which (for whatever reason) do not support or disabl=
e ECDH?
>=20
> I would like to support only ECDHE-ECDSA at this point but RSA has
> significant inertia because of the CA system. On reflection, it does
> seem reasonable that some implementations might not want the weight of
> an ECC implementation given that they have to have
> multiplicative-modexp for RSA anyway. So I've spun version -01 with
> with a DHE_RSA ciphersuite too.

Considering the performance difference, I though ECDHE-RSA would be in orde=
r. We have to have the RSA because that's what we have in the certificates,=
 but might as well not add the extra work that is DHE. That's the reason wh=
y Google servers prefer ECDHE-RSA ciphersuites, no?

Yoav


From agl@google.com  Wed Sep 11 08:29:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DF221E8128 for ; Wed, 11 Sep 2013 08:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.676
X-Spam-Level: 
X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.302,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrY0IZCkSW-6 for ; Wed, 11 Sep 2013 08:29:19 -0700 (PDT)
Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 88E2C21F9E95 for ; Wed, 11 Sep 2013 08:29:12 -0700 (PDT)
Received: by mail-ob0-f170.google.com with SMTP id eh20so8677600obb.15 for ; Wed, 11 Sep 2013 08:29:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=jGV3Kw6Piuar8S8zDfHkB3MkeRD0wcH2KRU0pbP8Rr4=; b=YvphkGWfEJWqSBdwrE+ZlgmKaJBauB4pQjGMoKo04GoPOs4eZ2AJcj9ezngOZBQxME 9cyGl+7Ln+HmW6xEkjvljLLg4SW8I3yxjxsdq9KDZedwCjSUYAWkVQwX8ifvSuoSkmWf MF0VKvjd4RdzfDE03F1aKMKAGJ/Xsyn2PUpIKs/GoRyLUIowwd2sTJnEo95Bbmfi7Uwp DoAEfBLm600iIGlQrcFS8teeC5SnjrzAcsraid4TRITLnSkVBJByncFmh9f4MQMQqs0V KLBrcN0vFpiDzL2jxmgBubAIp4DRGG1s+TgAW5bthwPeB2gf/yNBW0F6SXFkFhvP19Hs XrTg==
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:content-transfer-encoding; bh=jGV3Kw6Piuar8S8zDfHkB3MkeRD0wcH2KRU0pbP8Rr4=; b=jAI0bqCSm9cmerST740QZ2Pk0i1S7oot+mYTWXLbXTZMilvVV/4njUYuZOSkXj5E23 lt2xv7kJdjPFHLhgu9BcZe1n57pcCKb8+P61hoiUz/PQlhlmlt9jRq8I4vBty3thK1zu VkJJdAnKaQBbcWlz9dHH46rKN4g7l1nv8M+PKSwFP+pGYEwW9URdgo8vLBFmrX1C6z4F vjlBpTLfKpLty08onvz+Yth29sEbeOGSh5gf7GRkYCm/5mad8QJM+XqAHkme7ZsWp+2z qwrH/WbDcNOi0/eW+dSPNRKV72I1wK501kNvmWWYAV7JGPB9S/EdBe7PUhscNiuDxzn1 XQOg==
X-Gm-Message-State: ALoCoQnNy+iHWPUM++k5NgtDQitwtj03Zq6Acjd/8aVodTCM8Y4sU697M7bBvmzQ6DlbHdMM9idAkIrSnkvD5lU7oespO+yQxHTcD6NW/HVtjRPt/BoDMAP+q8NOqGw60sYT/MRsQ8hog5V+XVK2VrrKuhx4KmLVU/UBhftaRMs+JBcumHkv5YizXKn4ihElUpnCZgrm4Fca
X-Received: by 10.182.81.41 with SMTP id w9mr2031544obx.18.1378913349685; Wed, 11 Sep 2013 08:29:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.79.105 with HTTP; Wed, 11 Sep 2013 08:28:49 -0700 (PDT)
In-Reply-To: 
References:  <52306269.7020200@drh-consultancy.co.uk>  
From: Adam Langley 
Date: Wed, 11 Sep 2013 11:28:49 -0400
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 15:29:21 -0000

On Wed, Sep 11, 2013 at 11:26 AM, Yoav Nir  wrote:
> Considering the performance difference, I though ECDHE-RSA would be in or=
der. We have to have the RSA because that's what we have in the certificate=
s, but might as well not add the extra work that is DHE. That's the reason =
why Google servers prefer ECDHE-RSA ciphersuites, no?

An ECDHE-RSA variant was included in -00 for this reason. Although I'd
*like* to only deal with ECDHE-ECDSA, we're not there yet for the
reasons that you identify.


Cheers

AGL

From nick.a.mathewson@gmail.com  Wed Sep 11 08:44:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5860C21E8150; Wed, 11 Sep 2013 08:44:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.233
X-Spam-Level: 
X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWI2VnEZzLl9; Wed, 11 Sep 2013 08:44:20 -0700 (PDT)
Received: from mail-qe0-x230.google.com (mail-qe0-x230.google.com [IPv6:2607:f8b0:400d:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8E3A121E80D6; Wed, 11 Sep 2013 08:43:58 -0700 (PDT)
Received: by mail-qe0-f48.google.com with SMTP id nd7so4559721qeb.21 for ; Wed, 11 Sep 2013 08:43:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=nadwBqowODNn1F1WLREZev2cD/GPtWb6g87ZQhWtrY0=; b=q+8McEr3GrF0HK2vPDdHpK7gyzhNs68M5cRdz2p4mSSGJkbYQEKxe2DDiCPa1RS6nx LfLrXUrQZcWHcGx9Na38d73G7oxZ5TkdcM1dKsJJvuCD02SRMA2N2UBcwX8/a0U79Xmx xmAIS8o9ZOBudUZy7t3nVEtXjQvc3j0dGGHpRYpIW5gMwA2EZaDApZzNReyZvJlsqMaR jmHTGl4+12iQ+4OHIiziFJtwrXNCsvIZbmicDf2liyvvuLpx9zQKLSbRlCSEWA9DnTMG iI28BwfbYCQWCHiGqgJA6WHmpgNYkgW2x/4c0yrhdlTkDPn6mv0SqsaOrH5FzjNN7Pkq IJWg==
MIME-Version: 1.0
X-Received: by 10.49.120.72 with SMTP id la8mr4490597qeb.62.1378914233423; Wed, 11 Sep 2013 08:43:53 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 08:43:53 -0700 (PDT)
Date: Wed, 11 Sep 2013 11:43:53 -0400
X-Google-Sender-Auth: bJai9poECwNKPn3X9boDY4XJEQQ
Message-ID: 
From: Nick Mathewson 
To: "tls@ietf.org" , perpass@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 15:44:23 -0000

Hi, all.

Here's something I wrote about removing a fingerprinting opportunity
from the current TLS protocol.  I was going to just send it to the tls
list, but Ben Laurie suggested that I send it to the perpass list as
well.

I have little standards-body experience; if this ought to turn into an
RFC or something, I'd be happy to write a draft if need be.


(Tor currently plans to implement this by patching OpenSSL; any
feedback or advice would be appreciated.  The first three approaches
below are implemented in OpenSSL branches named "no_client_timestamp",
"no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
repository at https://github.com/nmathewson/openssl .  We have long
shipped our privacy-enhanced browser with a feature like this enabled
through an NSS patch.)


====
SYNOPSIS:

In TLS as currently specified, clients and servers each send their
current view of "the time" in the clear as part of their handshake.
This provides a fingerprint that can track users in spite of other
attempts to make them untrackable.  I propose several ways to stop
doing sending this cleartext timestamp; some trivial and some more
complex.


ACKNOWLEDGEMENTS:

Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
feedback here.


PROBLEM:

The gmt_unix_time field in the Random field in the TLS handshake
provides a way for an observer to fingerprint clients.

Despite the late date, much of the world is still not
synchronized to the second via an ntp-like service. This means
that different clients have different views of the current time,
which provides a fingerprint that helps to track and distinguish
them.  This fingerprint is useful for tracking clients as they
move around.  It can also distinguish clients using a single VPN,
NAT, or privacy network.  (Tor's modified firefox avoids this by
not sending the time.)

Worse, some implementations don't send the current time, but the
process time, or the computer's uptime, both of which are far
more distinguishing than the current time() value.

The information fingerprint here is strong enough to uniquely
identify some TLS users (the ones whose clocks are hours off).
Even for the ones whose clocks are mostly right (within a second
or two), the field leaks a bit of information, and it only takes
so many bits to make a user unique.

Of course, I realize that the gmt_unix_time fingerprint is not the
only way to track a typical client as it moves from network to
network, and not the only way to distinguish different clients
behind a NAT.



BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?

According to third-hand reports (and correct me if I'm wrong!)
gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
in cases where the PRNG was completely broken, by making a part of
the Random field that would definitely vary between TLS handshakes.

I doubt that this goal is really achieved, for two reasons:

   * On modern desktop environments, it's not really so strange to
     start two or more TLS connections within the same second.  When
     this occurs, the gmt_unix_time fails in its intended purpose of
     preventing repeated Random values.

   * Nonwithstanding the gmt_unix_time workaround, TLS in general
     does not withstand broken PRNGs.  For one example, if an
     implementation's PRNG is prone to repeating ClientRandom
     values, it is probably prone to repeating those some values as
     ephemeral Diffie-Hellman private values.

Nevertheless, if the goal of providing unique-looking output



WHY ELSE IS gmt_unix_time USED?

The consensus among implementors I've asked seems to be that it's
unwise to depend on any particular value or interpretation for the
field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
required to be set correctly by the basic TLS protocol; higher-level
or application protocols may define additional requirements."

Some implementations set the entire gmt_unix_time field randomly;
this appears not to have broken TLS on the internet.

At least one tool (tlsdate) uses the server-side value of the
field as an authenticated view of the current time.



PROPOSAL 1:

Declare that implementations MAY replace gmt_unix_time either with
four more random bytes, or four bytes of zeroes.

Rationale:
   * Some implementations (like TorBrowser) are already doing this
     in practice.

   * It's sensible and simple.  Implementors are quite unlikely to
     mess it up.



PROPOSAL 2:

Suppose that we do not accept the argument about the pointlessness
of gmt_unit_time that I make above, and we want to preserve the
security it allegedly provides.

In that case, we can allow the following approach instead:

Set the Random field, not to 32 bytes from your PRNG, but to the
HMAC-SHA256 of any high resolution timer that you have, using 32
bytes from your PRNG as a key.  In other words, replace this:

   Random.gmt_unix_time = time();
   Random.random_bytes = get_random_bytes(28)

with this:

   now = hires_time(); // clock_gettime(), or concatenate time()
                       // with a CPU timer, or process
                       // uptime, or whatever.
   key = get_random_bytes(32);
   Random = hmac_sha256(key, now);

This approach is better than the status quo on the following
counts:

   * It doesn't leak your view of the current time, assuming that
     your PRNG isn't busted.

   * It actually fixes the problem that gmt_unix_time purported to
     fix, by using a high-resolution time that's much less likely to
     be used twice.  Even if the PRNG is broken, the value is still
     nonrepeating.

I do not think this is not worse than the status quo:

   * It is unpredictable from an attacker's POV, assuming that the
     PRNG works.  (Because an HMAC, even of known data, with an
     unknown random key is supposed to look random).


PROPOSAL 3

As a hybrid alternative, one could set part of the ClientRandom
field (perhaps 12 bytes or so) based on the HMAC of the time, and
the rest of the ClientRandom field based on the PRNG:

   N = 12

   now = hires_time();
   key = get_random_bytes(32);
   mac = hmac_sha256(key, now)[0:N];  // First N bytes.
   rand = get_random_bytes(32 - N)
   Random = mac ++ rand               // concatenate.

But this seems to be getting pointlessly baroque.



CONSIDERATIONS:

I'd personally suggest proposal 1 (just set the field at random) for
most users.  Yes, it makes things a little worse if your PRNG can
generate repeat values... but nearly everything in cryptography
fails if your PRNG is broken.


We might want to apply this fix on clients only.  With a few
exceptions (like hidden services) the server's view of the current
time is not sensitive.


Implementors might want to make this feature optional and
on-by-default, just in case some higher-level application protocol
really does depend on it.

From alfredo@pironti.eu  Wed Sep 11 09:01:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96D421F8447 for ; Wed, 11 Sep 2013 09:01:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.426
X-Spam-Level: 
X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c9x2hbnjDZGW for ; Wed, 11 Sep 2013 09:01:54 -0700 (PDT)
Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 09E5821F9B85 for ; Wed, 11 Sep 2013 09:01:36 -0700 (PDT)
Received: by mail-ob0-f172.google.com with SMTP id er7so8675016obc.31 for ; Wed, 11 Sep 2013 09:01:34 -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=ML45jckKmiieBXUAexsO3KA4VmLZzVn/wQxfmWHXMcA=; b=XGBeb2dNTA2fgmq7dCKlTk/fba7qEGVO4I7aao0/P7znkH0UK8k8CFjFfqz8qKOJgE wYQ/UQqrQxDedRQc6wr+MqxfWRUgK7pdhW8AY+UKs53V/O+m7lHUPMW7Hc/KuowINL/g 1hnZDCKO16kzUH4/G2TaGdu0FQiZAQNIXUMR0=
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=ML45jckKmiieBXUAexsO3KA4VmLZzVn/wQxfmWHXMcA=; b=Y89PXLlHFIomqSjLcWRDmbsAmWfSKGyLqIXJtbn9g3kjEKvXCgc6sfCe/OnMqFGgD2 BM07sNRrdl0xa46AntffmK9FQTz7i3xjqRiwBMFh6rQ4LJYNXwFy4pmC0y0HeKO6R85+ SOaphesgCAaTEaEf9eDcHh2/ompTHnnJhsEvTfJLi8CPUgdSNa4NNNNdI57As6+vidOS ZbCBMsmldvxWq83Wn//C0iSo7Og5004OTDp52npeSjJ0g83skQ3CPH4PevVGcq6Wwohm /UJcMLvycBMZHN8Qi2Q3O0RPtfdfGqJNLqIOHEVZ9MElQ/W8tOFYnfUOxj65EEXU4TeM achw==
X-Gm-Message-State: ALoCoQlw3YGjtVT8mb1SD7mMor3awh91lsZt/V/lqHKI402wlLqWEaqsqpGotgRU/e8e8VRM9Ac9
MIME-Version: 1.0
X-Received: by 10.60.120.69 with SMTP id la5mr1469659oeb.86.1378915294027; Wed, 11 Sep 2013 09:01:34 -0700 (PDT)
Received: by 10.76.80.201 with HTTP; Wed, 11 Sep 2013 09:01:33 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: 
References: 
Date: Wed, 11 Sep 2013 18:01:33 +0200
Message-ID: 
From: Alfredo Pironti 
To: Nick Mathewson 
Content-Type: text/plain; charset=UTF-8
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:02:00 -0000

I'm in favor of proposal 1, and second the considerations about it;
essentially, a broken crypto implementation cannot be fixed by a
timestamp.

If proposal 2 (and 3) was to be implemented on a server, it would also
make DoS easier, because a cheap ClientHello (even generated with weak
randomness) would trigger an extra HMAC computation on the server,
with respect to the current server load.

Hence, relying on PRNG on both client and server sides looks like a
reasonable way to go. I also don't particularly like the asymmetry
that proposal 2 may bring: client generating randomness with HMAC, and
servers still using the timestamp in clear.

Cheers,
Alfredo

On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson  wrote:
> Hi, all.
>
> Here's something I wrote about removing a fingerprinting opportunity
> from the current TLS protocol.  I was going to just send it to the tls
> list, but Ben Laurie suggested that I send it to the perpass list as
> well.
>
> I have little standards-body experience; if this ought to turn into an
> RFC or something, I'd be happy to write a draft if need be.
>
>
> (Tor currently plans to implement this by patching OpenSSL; any
> feedback or advice would be appreciated.  The first three approaches
> below are implemented in OpenSSL branches named "no_client_timestamp",
> "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
> repository at https://github.com/nmathewson/openssl .  We have long
> shipped our privacy-enhanced browser with a feature like this enabled
> through an NSS patch.)
>
>
> ====
> SYNOPSIS:
>
> In TLS as currently specified, clients and servers each send their
> current view of "the time" in the clear as part of their handshake.
> This provides a fingerprint that can track users in spite of other
> attempts to make them untrackable.  I propose several ways to stop
> doing sending this cleartext timestamp; some trivial and some more
> complex.
>
>
> ACKNOWLEDGEMENTS:
>
> Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
> feedback here.
>
>
> PROBLEM:
>
> The gmt_unix_time field in the Random field in the TLS handshake
> provides a way for an observer to fingerprint clients.
>
> Despite the late date, much of the world is still not
> synchronized to the second via an ntp-like service. This means
> that different clients have different views of the current time,
> which provides a fingerprint that helps to track and distinguish
> them.  This fingerprint is useful for tracking clients as they
> move around.  It can also distinguish clients using a single VPN,
> NAT, or privacy network.  (Tor's modified firefox avoids this by
> not sending the time.)
>
> Worse, some implementations don't send the current time, but the
> process time, or the computer's uptime, both of which are far
> more distinguishing than the current time() value.
>
> The information fingerprint here is strong enough to uniquely
> identify some TLS users (the ones whose clocks are hours off).
> Even for the ones whose clocks are mostly right (within a second
> or two), the field leaks a bit of information, and it only takes
> so many bits to make a user unique.
>
> Of course, I realize that the gmt_unix_time fingerprint is not the
> only way to track a typical client as it moves from network to
> network, and not the only way to distinguish different clients
> behind a NAT.
>
>
>
> BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>
> According to third-hand reports (and correct me if I'm wrong!)
> gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
> in cases where the PRNG was completely broken, by making a part of
> the Random field that would definitely vary between TLS handshakes.
>
> I doubt that this goal is really achieved, for two reasons:
>
>    * On modern desktop environments, it's not really so strange to
>      start two or more TLS connections within the same second.  When
>      this occurs, the gmt_unix_time fails in its intended purpose of
>      preventing repeated Random values.
>
>    * Nonwithstanding the gmt_unix_time workaround, TLS in general
>      does not withstand broken PRNGs.  For one example, if an
>      implementation's PRNG is prone to repeating ClientRandom
>      values, it is probably prone to repeating those some values as
>      ephemeral Diffie-Hellman private values.
>
> Nevertheless, if the goal of providing unique-looking output
>
>
>
> WHY ELSE IS gmt_unix_time USED?
>
> The consensus among implementors I've asked seems to be that it's
> unwise to depend on any particular value or interpretation for the
> field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
> required to be set correctly by the basic TLS protocol; higher-level
> or application protocols may define additional requirements."
>
> Some implementations set the entire gmt_unix_time field randomly;
> this appears not to have broken TLS on the internet.
>
> At least one tool (tlsdate) uses the server-side value of the
> field as an authenticated view of the current time.
>
>
>
> PROPOSAL 1:
>
> Declare that implementations MAY replace gmt_unix_time either with
> four more random bytes, or four bytes of zeroes.
>
> Rationale:
>    * Some implementations (like TorBrowser) are already doing this
>      in practice.
>
>    * It's sensible and simple.  Implementors are quite unlikely to
>      mess it up.
>
>
>
> PROPOSAL 2:
>
> Suppose that we do not accept the argument about the pointlessness
> of gmt_unit_time that I make above, and we want to preserve the
> security it allegedly provides.
>
> In that case, we can allow the following approach instead:
>
> Set the Random field, not to 32 bytes from your PRNG, but to the
> HMAC-SHA256 of any high resolution timer that you have, using 32
> bytes from your PRNG as a key.  In other words, replace this:
>
>    Random.gmt_unix_time = time();
>    Random.random_bytes = get_random_bytes(28)
>
> with this:
>
>    now = hires_time(); // clock_gettime(), or concatenate time()
>                        // with a CPU timer, or process
>                        // uptime, or whatever.
>    key = get_random_bytes(32);
>    Random = hmac_sha256(key, now);
>
> This approach is better than the status quo on the following
> counts:
>
>    * It doesn't leak your view of the current time, assuming that
>      your PRNG isn't busted.
>
>    * It actually fixes the problem that gmt_unix_time purported to
>      fix, by using a high-resolution time that's much less likely to
>      be used twice.  Even if the PRNG is broken, the value is still
>      nonrepeating.
>
> I do not think this is not worse than the status quo:
>
>    * It is unpredictable from an attacker's POV, assuming that the
>      PRNG works.  (Because an HMAC, even of known data, with an
>      unknown random key is supposed to look random).
>
>
> PROPOSAL 3
>
> As a hybrid alternative, one could set part of the ClientRandom
> field (perhaps 12 bytes or so) based on the HMAC of the time, and
> the rest of the ClientRandom field based on the PRNG:
>
>    N = 12
>
>    now = hires_time();
>    key = get_random_bytes(32);
>    mac = hmac_sha256(key, now)[0:N];  // First N bytes.
>    rand = get_random_bytes(32 - N)
>    Random = mac ++ rand               // concatenate.
>
> But this seems to be getting pointlessly baroque.
>
>
>
> CONSIDERATIONS:
>
> I'd personally suggest proposal 1 (just set the field at random) for
> most users.  Yes, it makes things a little worse if your PRNG can
> generate repeat values... but nearly everything in cryptography
> fails if your PRNG is broken.
>
>
> We might want to apply this fix on clients only.  With a few
> exceptions (like hidden services) the server's view of the current
> time is not sensitive.
>
>
> Implementors might want to make this feature optional and
> on-by-default, just in case some higher-level application protocol
> really does depend on it.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From housley@vigilsec.com  Wed Sep 11 09:05:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3313F21E8051; Wed, 11 Sep 2013 09:05:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sv5lW-lLN62; Wed, 11 Sep 2013 09:05:30 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA1B11E81C8; Wed, 11 Sep 2013 09:04:47 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 6579EF241EB; Wed, 11 Sep 2013 12:05:27 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id bm1MdwRSFQfA; Wed, 11 Sep 2013 12:04:08 -0400 (EDT)
Received: from [192.168.2.100] (pool-96-231-164-210.washdc.fios.verizon.net [96.231.164.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 20153F240FD; Wed, 11 Sep 2013 12:05:25 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: 
Date: Wed, 11 Sep 2013 12:04:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com>
References: 
To: Nick Mathewson 
X-Mailer: Apple Mail (2.1085)
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:05:37 -0000

The tlsdate program (with origins in the TOR project) makes use of this =
value in the nonce portion of the handshake.

I think that the time is an important part of the nonce.  Even if the =
implementation has a crappy random number generator, the time value does =
a good job of ensuring that the nonce value is not repeated.  Obviously, =
the time value does not help with the unpredictability, but the random =
value is supposed to do that.

Russ


On Sep 11, 2013, at 11:43 AM, Nick Mathewson wrote:

> Hi, all.
>=20
> Here's something I wrote about removing a fingerprinting opportunity
> from the current TLS protocol.  I was going to just send it to the tls
> list, but Ben Laurie suggested that I send it to the perpass list as
> well.
>=20
> I have little standards-body experience; if this ought to turn into an
> RFC or something, I'd be happy to write a draft if need be.
>=20
>=20
> (Tor currently plans to implement this by patching OpenSSL; any
> feedback or advice would be appreciated.  The first three approaches
> below are implemented in OpenSSL branches named "no_client_timestamp",
> "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
> repository at https://github.com/nmathewson/openssl .  We have long
> shipped our privacy-enhanced browser with a feature like this enabled
> through an NSS patch.)
>=20
>=20
> =3D=3D=3D=3D
> SYNOPSIS:
>=20
> In TLS as currently specified, clients and servers each send their
> current view of "the time" in the clear as part of their handshake.
> This provides a fingerprint that can track users in spite of other
> attempts to make them untrackable.  I propose several ways to stop
> doing sending this cleartext timestamp; some trivial and some more
> complex.
>=20
>=20
> ACKNOWLEDGEMENTS:
>=20
> Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
> feedback here.
>=20
>=20
> PROBLEM:
>=20
> The gmt_unix_time field in the Random field in the TLS handshake
> provides a way for an observer to fingerprint clients.
>=20
> Despite the late date, much of the world is still not
> synchronized to the second via an ntp-like service. This means
> that different clients have different views of the current time,
> which provides a fingerprint that helps to track and distinguish
> them.  This fingerprint is useful for tracking clients as they
> move around.  It can also distinguish clients using a single VPN,
> NAT, or privacy network.  (Tor's modified firefox avoids this by
> not sending the time.)
>=20
> Worse, some implementations don't send the current time, but the
> process time, or the computer's uptime, both of which are far
> more distinguishing than the current time() value.
>=20
> The information fingerprint here is strong enough to uniquely
> identify some TLS users (the ones whose clocks are hours off).
> Even for the ones whose clocks are mostly right (within a second
> or two), the field leaks a bit of information, and it only takes
> so many bits to make a user unique.
>=20
> Of course, I realize that the gmt_unix_time fingerprint is not the
> only way to track a typical client as it moves from network to
> network, and not the only way to distinguish different clients
> behind a NAT.
>=20
>=20
>=20
> BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>=20
> According to third-hand reports (and correct me if I'm wrong!)
> gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
> in cases where the PRNG was completely broken, by making a part of
> the Random field that would definitely vary between TLS handshakes.
>=20
> I doubt that this goal is really achieved, for two reasons:
>=20
>   * On modern desktop environments, it's not really so strange to
>     start two or more TLS connections within the same second.  When
>     this occurs, the gmt_unix_time fails in its intended purpose of
>     preventing repeated Random values.
>=20
>   * Nonwithstanding the gmt_unix_time workaround, TLS in general
>     does not withstand broken PRNGs.  For one example, if an
>     implementation's PRNG is prone to repeating ClientRandom
>     values, it is probably prone to repeating those some values as
>     ephemeral Diffie-Hellman private values.
>=20
> Nevertheless, if the goal of providing unique-looking output
>=20
>=20
>=20
> WHY ELSE IS gmt_unix_time USED?
>=20
> The consensus among implementors I've asked seems to be that it's
> unwise to depend on any particular value or interpretation for the
> field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
> required to be set correctly by the basic TLS protocol; higher-level
> or application protocols may define additional requirements."
>=20
> Some implementations set the entire gmt_unix_time field randomly;
> this appears not to have broken TLS on the internet.
>=20
> At least one tool (tlsdate) uses the server-side value of the
> field as an authenticated view of the current time.
>=20
>=20
>=20
> PROPOSAL 1:
>=20
> Declare that implementations MAY replace gmt_unix_time either with
> four more random bytes, or four bytes of zeroes.
>=20
> Rationale:
>   * Some implementations (like TorBrowser) are already doing this
>     in practice.
>=20
>   * It's sensible and simple.  Implementors are quite unlikely to
>     mess it up.
>=20
>=20
>=20
> PROPOSAL 2:
>=20
> Suppose that we do not accept the argument about the pointlessness
> of gmt_unit_time that I make above, and we want to preserve the
> security it allegedly provides.
>=20
> In that case, we can allow the following approach instead:
>=20
> Set the Random field, not to 32 bytes from your PRNG, but to the
> HMAC-SHA256 of any high resolution timer that you have, using 32
> bytes from your PRNG as a key.  In other words, replace this:
>=20
>   Random.gmt_unix_time =3D time();
>   Random.random_bytes =3D get_random_bytes(28)
>=20
> with this:
>=20
>   now =3D hires_time(); // clock_gettime(), or concatenate time()
>                       // with a CPU timer, or process
>                       // uptime, or whatever.
>   key =3D get_random_bytes(32);
>   Random =3D hmac_sha256(key, now);
>=20
> This approach is better than the status quo on the following
> counts:
>=20
>   * It doesn't leak your view of the current time, assuming that
>     your PRNG isn't busted.
>=20
>   * It actually fixes the problem that gmt_unix_time purported to
>     fix, by using a high-resolution time that's much less likely to
>     be used twice.  Even if the PRNG is broken, the value is still
>     nonrepeating.
>=20
> I do not think this is not worse than the status quo:
>=20
>   * It is unpredictable from an attacker's POV, assuming that the
>     PRNG works.  (Because an HMAC, even of known data, with an
>     unknown random key is supposed to look random).
>=20
>=20
> PROPOSAL 3
>=20
> As a hybrid alternative, one could set part of the ClientRandom
> field (perhaps 12 bytes or so) based on the HMAC of the time, and
> the rest of the ClientRandom field based on the PRNG:
>=20
>   N =3D 12
>=20
>   now =3D hires_time();
>   key =3D get_random_bytes(32);
>   mac =3D hmac_sha256(key, now)[0:N];  // First N bytes.
>   rand =3D get_random_bytes(32 - N)
>   Random =3D mac ++ rand               // concatenate.
>=20
> But this seems to be getting pointlessly baroque.
>=20
>=20
>=20
> CONSIDERATIONS:
>=20
> I'd personally suggest proposal 1 (just set the field at random) for
> most users.  Yes, it makes things a little worse if your PRNG can
> generate repeat values... but nearly everything in cryptography
> fails if your PRNG is broken.
>=20
>=20
> We might want to apply this fix on clients only.  With a few
> exceptions (like hidden services) the server's view of the current
> time is not sensitive.
>=20
>=20
> Implementors might want to make this feature optional and
> on-by-default, just in case some higher-level application protocol
> really does depend on it.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From ekr@rtfm.com  Wed Sep 11 09:08:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976121E80CF for ; Wed, 11 Sep 2013 09:08:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uocMMN9syMrt for ; Wed, 11 Sep 2013 09:07:53 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id AC17C11E81CE for ; Wed, 11 Sep 2013 09:07:30 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id b12so2043511wgh.1 for ; Wed, 11 Sep 2013 09:07:29 -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=PXuKTSUqLQadNnVvH8wdbDmALMGv2tY6Kzc9qnnakoI=; b=Oq73Om/RJtVl2s8kSk+ocZ0zI8UrrDPoRnIQpQ0Gi59In3IXgYnOSgson3naqI7/Q+ aXggZgyuh1n4hYSnQ3geT5nvae5KA/tPN7gfCunVceEZXgtZ4q7BkraQ7fZ5OddbyoVL PRPOgMdiUzw6VvafqGEf1xBdVf62lmOhl8xVLfvehyOX6Lwu6wKGd6cf+CXvjEzpOxNZ pUfpuz0IaYEPsETIoM6edCCArjfNBgoF9oFFroYWEtymwA1RQOoV76OhPI16zGmqkzDw X8UoSRKgtBPkJ8WUwnjiD7hg1RF7gVqE3uMGXy0DapFivHP4csi/jHX1i2wGNduoO+Ql 3uaA==
X-Gm-Message-State: ALoCoQmSiKFaR0ZxMgqmkVJuYaaCW0C4mHdrYguubXSUAON0llHx3okbmkhE8g6lCGQ0JVdmKIi7
X-Received: by 10.194.250.6 with SMTP id yy6mr2183669wjc.13.1378915649516; Wed, 11 Sep 2013 09:07:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.84.68 with HTTP; Wed, 11 Sep 2013 09:06:49 -0700 (PDT)
X-Originating-IP: [63.245.220.240]
In-Reply-To: 
References:  
From: Eric Rescorla 
Date: Wed, 11 Sep 2013 09:06:49 -0700
Message-ID: 
To: Alfredo Pironti 
Content-Type: multipart/alternative; boundary=001a11c1ba4a77093704e61dd1d7
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:08:21 -0000

--001a11c1ba4a77093704e61dd1d7
Content-Type: text/plain; charset=ISO-8859-1

Before we discuss mechanisms, it would be good to verify that in general
clients and servers don't become unhappy if the timestamp is radically
wrong. Has someone done measurements to verify that this is in fact
the case at a broad scale?

-Ekr



On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti  wrote:

> I'm in favor of proposal 1, and second the considerations about it;
> essentially, a broken crypto implementation cannot be fixed by a
> timestamp.
>
> If proposal 2 (and 3) was to be implemented on a server, it would also
> make DoS easier, because a cheap ClientHello (even generated with weak
> randomness) would trigger an extra HMAC computation on the server,
> with respect to the current server load.
>
> Hence, relying on PRNG on both client and server sides looks like a
> reasonable way to go. I also don't particularly like the asymmetry
> that proposal 2 may bring: client generating randomness with HMAC, and
> servers still using the timestamp in clear.
>
> Cheers,
> Alfredo
>
> On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson 
> wrote:
> > Hi, all.
> >
> > Here's something I wrote about removing a fingerprinting opportunity
> > from the current TLS protocol.  I was going to just send it to the tls
> > list, but Ben Laurie suggested that I send it to the perpass list as
> > well.
> >
> > I have little standards-body experience; if this ought to turn into an
> > RFC or something, I'd be happy to write a draft if need be.
> >
> >
> > (Tor currently plans to implement this by patching OpenSSL; any
> > feedback or advice would be appreciated.  The first three approaches
> > below are implemented in OpenSSL branches named "no_client_timestamp",
> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
> > repository at https://github.com/nmathewson/openssl .  We have long
> > shipped our privacy-enhanced browser with a feature like this enabled
> > through an NSS patch.)
> >
> >
> > ====
> > SYNOPSIS:
> >
> > In TLS as currently specified, clients and servers each send their
> > current view of "the time" in the clear as part of their handshake.
> > This provides a fingerprint that can track users in spite of other
> > attempts to make them untrackable.  I propose several ways to stop
> > doing sending this cleartext timestamp; some trivial and some more
> > complex.
> >
> >
> > ACKNOWLEDGEMENTS:
> >
> > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
> > feedback here.
> >
> >
> > PROBLEM:
> >
> > The gmt_unix_time field in the Random field in the TLS handshake
> > provides a way for an observer to fingerprint clients.
> >
> > Despite the late date, much of the world is still not
> > synchronized to the second via an ntp-like service. This means
> > that different clients have different views of the current time,
> > which provides a fingerprint that helps to track and distinguish
> > them.  This fingerprint is useful for tracking clients as they
> > move around.  It can also distinguish clients using a single VPN,
> > NAT, or privacy network.  (Tor's modified firefox avoids this by
> > not sending the time.)
> >
> > Worse, some implementations don't send the current time, but the
> > process time, or the computer's uptime, both of which are far
> > more distinguishing than the current time() value.
> >
> > The information fingerprint here is strong enough to uniquely
> > identify some TLS users (the ones whose clocks are hours off).
> > Even for the ones whose clocks are mostly right (within a second
> > or two), the field leaks a bit of information, and it only takes
> > so many bits to make a user unique.
> >
> > Of course, I realize that the gmt_unix_time fingerprint is not the
> > only way to track a typical client as it moves from network to
> > network, and not the only way to distinguish different clients
> > behind a NAT.
> >
> >
> >
> > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
> >
> > According to third-hand reports (and correct me if I'm wrong!)
> > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
> > in cases where the PRNG was completely broken, by making a part of
> > the Random field that would definitely vary between TLS handshakes.
> >
> > I doubt that this goal is really achieved, for two reasons:
> >
> >    * On modern desktop environments, it's not really so strange to
> >      start two or more TLS connections within the same second.  When
> >      this occurs, the gmt_unix_time fails in its intended purpose of
> >      preventing repeated Random values.
> >
> >    * Nonwithstanding the gmt_unix_time workaround, TLS in general
> >      does not withstand broken PRNGs.  For one example, if an
> >      implementation's PRNG is prone to repeating ClientRandom
> >      values, it is probably prone to repeating those some values as
> >      ephemeral Diffie-Hellman private values.
> >
> > Nevertheless, if the goal of providing unique-looking output
> >
> >
> >
> > WHY ELSE IS gmt_unix_time USED?
> >
> > The consensus among implementors I've asked seems to be that it's
> > unwise to depend on any particular value or interpretation for the
> > field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
> > required to be set correctly by the basic TLS protocol; higher-level
> > or application protocols may define additional requirements."
> >
> > Some implementations set the entire gmt_unix_time field randomly;
> > this appears not to have broken TLS on the internet.
> >
> > At least one tool (tlsdate) uses the server-side value of the
> > field as an authenticated view of the current time.
> >
> >
> >
> > PROPOSAL 1:
> >
> > Declare that implementations MAY replace gmt_unix_time either with
> > four more random bytes, or four bytes of zeroes.
> >
> > Rationale:
> >    * Some implementations (like TorBrowser) are already doing this
> >      in practice.
> >
> >    * It's sensible and simple.  Implementors are quite unlikely to
> >      mess it up.
> >
> >
> >
> > PROPOSAL 2:
> >
> > Suppose that we do not accept the argument about the pointlessness
> > of gmt_unit_time that I make above, and we want to preserve the
> > security it allegedly provides.
> >
> > In that case, we can allow the following approach instead:
> >
> > Set the Random field, not to 32 bytes from your PRNG, but to the
> > HMAC-SHA256 of any high resolution timer that you have, using 32
> > bytes from your PRNG as a key.  In other words, replace this:
> >
> >    Random.gmt_unix_time = time();
> >    Random.random_bytes = get_random_bytes(28)
> >
> > with this:
> >
> >    now = hires_time(); // clock_gettime(), or concatenate time()
> >                        // with a CPU timer, or process
> >                        // uptime, or whatever.
> >    key = get_random_bytes(32);
> >    Random = hmac_sha256(key, now);
> >
> > This approach is better than the status quo on the following
> > counts:
> >
> >    * It doesn't leak your view of the current time, assuming that
> >      your PRNG isn't busted.
> >
> >    * It actually fixes the problem that gmt_unix_time purported to
> >      fix, by using a high-resolution time that's much less likely to
> >      be used twice.  Even if the PRNG is broken, the value is still
> >      nonrepeating.
> >
> > I do not think this is not worse than the status quo:
> >
> >    * It is unpredictable from an attacker's POV, assuming that the
> >      PRNG works.  (Because an HMAC, even of known data, with an
> >      unknown random key is supposed to look random).
> >
> >
> > PROPOSAL 3
> >
> > As a hybrid alternative, one could set part of the ClientRandom
> > field (perhaps 12 bytes or so) based on the HMAC of the time, and
> > the rest of the ClientRandom field based on the PRNG:
> >
> >    N = 12
> >
> >    now = hires_time();
> >    key = get_random_bytes(32);
> >    mac = hmac_sha256(key, now)[0:N];  // First N bytes.
> >    rand = get_random_bytes(32 - N)
> >    Random = mac ++ rand               // concatenate.
> >
> > But this seems to be getting pointlessly baroque.
> >
> >
> >
> > CONSIDERATIONS:
> >
> > I'd personally suggest proposal 1 (just set the field at random) for
> > most users.  Yes, it makes things a little worse if your PRNG can
> > generate repeat values... but nearly everything in cryptography
> > fails if your PRNG is broken.
> >
> >
> > We might want to apply this fix on clients only.  With a few
> > exceptions (like hidden services) the server's view of the current
> > time is not sensitive.
> >
> >
> > Implementors might want to make this feature optional and
> > on-by-default, just in case some higher-level application protocol
> > really does depend on it.
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a11c1ba4a77093704e61dd1d7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Before we discuss mechanisms, it would be good to verify t=
hat in general
clients and servers don't become unhappy if the time=
stamp is radically
wrong. Has someone done measurements to verify=
 that this is in fact



the case at a broad scale?

-Ekr


=
On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <alfredo@pironti.eu&=
gt; wrote:



I'm in favor of proposal 1, and second t=
he considerations about it;

essentially, a broken crypto implementation cannot be fixed by a

timestamp.



If proposal 2 (and 3) was to be implemented on a server, it would also

make DoS easier, because a cheap ClientHello (even generated with weak

randomness) would trigger an extra HMAC computation on the server,

with respect to the current server load.



Hence, relying on PRNG on both client and server sides looks like a

reasonable way to go. I also don't particularly like the asymmetry

that proposal 2 may bring: client generating randomness with HMAC, and

servers still using the timestamp in clear.



Cheers,

Alfredo




On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <nickm@torproject.org> wrote:

> Hi, all.

>

> Here's something I wrote about removing a fingerprinting opportuni=
ty

> from the current TLS protocol. =A0I was going to just send it to the t=
ls

> list, but Ben Laurie suggested that I send it to the perpass list as
> well.

>

> I have little standards-body experience; if this ought to turn into an=


> RFC or something, I'd be happy to write a draft if need be.

>

>

> (Tor currently plans to implement this by patching OpenSSL; any

> feedback or advice would be appreciated. =A0The first three approaches=


> below are implemented in OpenSSL branches named "no_client_timest=
amp",

> "no_client_timestamp_v2" , and "no_client_timestamp_v3&=
quot; in the git

> repository at https://github.com/nmathewson/openssl . =A0We have long

> shipped our privacy-enhanced browser with a feature like this enabled<=
br>
> through an NSS patch.)

>

>

> =3D=3D=3D=3D

> SYNOPSIS:

>

> In TLS as currently specified, clients and servers each send their

> current view of "the time" in the clear as part of their han=
dshake.

> This provides a fingerprint that can track users in spite of other

> attempts to make them untrackable. =A0I propose several ways to stop
> doing sending this cleartext timestamp; some trivial and some more

> complex.

>

>

> ACKNOWLEDGEMENTS:

>

> Thanks to Adam Langley, Ben Laurie, and everybody else who gave me

> feedback here.

>

>

> PROBLEM:

>

> The gmt_unix_time field in the Random field in the TLS handshake

> provides a way for an observer to fingerprint clients.

>

> Despite the late date, much of the world is still not

> synchronized to the second via an ntp-like service. This means

> that different clients have different views of the current time,

> which provides a fingerprint that helps to track and distinguish

> them. =A0This fingerprint is useful for tracking clients as they

> move around. =A0It can also distinguish clients using a single VPN,
> NAT, or privacy network. =A0(Tor's modified firefox avoids this by=


> not sending the time.)

>

> Worse, some implementations don't send the current time, but the
> process time, or the computer's uptime, both of which are far

> more distinguishing than the current time() value.

>

> The information fingerprint here is strong enough to uniquely

> identify some TLS users (the ones whose clocks are hours off).

> Even for the ones whose clocks are mostly right (within a second

> or two), the field leaks a bit of information, and it only takes

> so many bits to make a user unique.

>

> Of course, I realize that the gmt_unix_time fingerprint is not the

> only way to track a typical client as it moves from network to

> network, and not the only way to distinguish different clients

> behind a NAT.

>

>

>

> BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?

>

> According to third-hand reports (and correct me if I'm wrong!)

> gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
> in cases where the PRNG was completely broken, by making a part of

> the Random field that would definitely vary between TLS handshakes.
>

> I doubt that this goal is really achieved, for two reasons:

>

> =A0 =A0* On modern desktop environments, it's not really so strang=
e to

> =A0 =A0 =A0start two or more TLS connections within the same second. =
=A0When

> =A0 =A0 =A0this occurs, the gmt_unix_time fails in its intended purpos=
e of

> =A0 =A0 =A0preventing repeated Random values.

>

> =A0 =A0* Nonwithstanding the gmt_unix_time workaround, TLS in general<=
br>
> =A0 =A0 =A0does not withstand broken PRNGs. =A0For one example, if an<=
br>
> =A0 =A0 =A0implementation's PRNG is prone to repeating ClientRando=
m

> =A0 =A0 =A0values, it is probably prone to repeating those some values=
 as

> =A0 =A0 =A0ephemeral Diffie-Hellman private values.

>

> Nevertheless, if the goal of providing unique-looking output

>

>

>

> WHY ELSE IS gmt_unix_time USED?

>

> The consensus among implementors I've asked seems to be that it=
9;s

> unwise to depend on any particular value or interpretation for the

> field. =A0The TLS 1.2 standard, RFC 5246, says that "Clocks are n=
ot

> required to be set correctly by the basic TLS protocol; higher-level
> or application protocols may define additional requirements."

>

> Some implementations set the entire gmt_unix_time field randomly;

> this appears not to have broken TLS on the internet.

>

> At least one tool (tlsdate) uses the server-side value of the

> field as an authenticated view of the current time.

>

>

>

> PROPOSAL 1:

>

> Declare that implementations MAY replace gmt_unix_time either with

> four more random bytes, or four bytes of zeroes.

>

> Rationale:

> =A0 =A0* Some implementations (like TorBrowser) are already doing this=


> =A0 =A0 =A0in practice.

>

> =A0 =A0* It's sensible and simple. =A0Implementors are quite unlik=
ely to

> =A0 =A0 =A0mess it up.

>

>

>

> PROPOSAL 2:

>

> Suppose that we do not accept the argument about the pointlessness

> of gmt_unit_time that I make above, and we want to preserve the

> security it allegedly provides.

>

> In that case, we can allow the following approach instead:

>

> Set the Random field, not to 32 bytes from your PRNG, but to the

> HMAC-SHA256 of any high resolution timer that you have, using 32

> bytes from your PRNG as a key. =A0In other words, replace this:

>

> =A0 =A0Random.gmt_unix_time =3D time();

> =A0 =A0Random.random_bytes =3D get_random_bytes(28)

>

> with this:

>

> =A0 =A0now =3D hires_time(); // clock_gettime(), or concatenate time()=


> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// with a CPU timer, or=
 process

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0// uptime, or whatever.=


> =A0 =A0key =3D get_random_bytes(32);

> =A0 =A0Random =3D hmac_sha256(key, now);

>

> This approach is better than the status quo on the following

> counts:

>

> =A0 =A0* It doesn't leak your view of the current time, assuming t=
hat

> =A0 =A0 =A0your PRNG isn't busted.

>

> =A0 =A0* It actually fixes the problem that gmt_unix_time purported to=


> =A0 =A0 =A0fix, by using a high-resolution time that's much less l=
ikely to

> =A0 =A0 =A0be used twice. =A0Even if the PRNG is broken, the value is =
still

> =A0 =A0 =A0nonrepeating.

>

> I do not think this is not worse than the status quo:

>

> =A0 =A0* It is unpredictable from an attacker's POV, assuming that=
 the

> =A0 =A0 =A0PRNG works. =A0(Because an HMAC, even of known data, with a=
n

> =A0 =A0 =A0unknown random key is supposed to look random).

>

>

> PROPOSAL 3

>

> As a hybrid alternative, one could set part of the ClientRandom

> field (perhaps 12 bytes or so) based on the HMAC of the time, and

> the rest of the ClientRandom field based on the PRNG:

>

> =A0 =A0N =3D 12

>

> =A0 =A0now =3D hires_time();

> =A0 =A0key =3D get_random_bytes(32);

> =A0 =A0mac =3D hmac_sha256(key, now)[0:N]; =A0// First N bytes.

> =A0 =A0rand =3D get_random_bytes(32 - N)

> =A0 =A0Random =3D mac ++ rand =A0 =A0 =A0 =A0 =A0 =A0 =A0 // concatena=
te.

>

> But this seems to be getting pointlessly baroque.

>

>

>

> CONSIDERATIONS:

>

> I'd personally suggest proposal 1 (just set the field at random) f=
or

> most users. =A0Yes, it makes things a little worse if your PRNG can
> generate repeat values... but nearly everything in cryptography

> fails if your PRNG is broken.

>

>

> We might want to apply this fix on clients only. =A0With a few

> exceptions (like hidden services) the server's view of the current=


> time is not sensitive.

>

>

> Implementors might want to make this feature optional and

> on-by-default, just in case some higher-level application protocol

> really does depend on it.

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--001a11c1ba4a77093704e61dd1d7--

From agl@google.com  Wed Sep 11 09:13:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F395C21F9E73 for ; Wed, 11 Sep 2013 09:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.737
X-Spam-Level: 
X-Spam-Status: No, score=-1.737 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RDHwS23o865 for ; Wed, 11 Sep 2013 09:13:08 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CE26821F9E6B for ; Wed, 11 Sep 2013 09:12:23 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id uz19so8570831obc.21 for ; Wed, 11 Sep 2013 09:12:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QcupxjvZEUZg28NlvJUT4DWfbcm6PXiHMKqm2JaZVBs=; b=RGr/RrWJ4WBx98uVAlT6eKjRNcfd2up5ZX2z08aB7af4iyCbPw5SNkQsUVmhTwxa6y EsebbKZ1cWQ5GaxlGqtYDbrPYJ/lprQXBNjIjwLDw5g18+Q4Kz4eMPD+4I/5z4886OQV IwUPIR8/gmyeHuUmzuocYHn6Rkkm09GPkWBujG6vc17AImme+t+stVigFHGZTcbwYBhY hkpqeShUmKwp+mmjn+GkREoDKgfvqN5ZCChCn55VEXvWyD1aWMH9B33g9Sse5dj1qi3W KjbhYNHV+XLXbKCwRwjZzU/DMOFt2WI0m1uNCbO188+VrwX6oLfDnDZ+W8sP8tNBuSHe 2Rww==
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=QcupxjvZEUZg28NlvJUT4DWfbcm6PXiHMKqm2JaZVBs=; b=Eq3O+kAxFEvWfqjsFLPHjIFlqYxouRli1xIeRSahpufqlpe9be1GxJDw8bbjBcoAXG +R+jnMrB44FxFZNg0zAoOdF3MHA3dWJ7yBVieCIF0+90ozPSs8xXLLeHwHyqTmYt3uZM 94JJDlfAcLdDp4UBhaus+hy6lZZ+kDRwasLNK2Js7dx/fyZl/Luf9LDJ0lnZrBb8GNoe e1BvwZctmey6QTj1J8WVQpAoQy2JO9ViSh3CKbU4br/rPFEkUAkMtQ3IJLlmJZ1pREo2 LE9jsCKTB7xGmcs/kWuh+0+BwooIXc7/hZHpNqwtxfvHsJTDSvFJsU1xtmGTF9bLVct2 XEJA==
X-Gm-Message-State: ALoCoQmEZ/cWkXJ8OerrC5b0NW+J0uFHDwz9fB2A1HbN2VNYpfviZrKGjjO3r3nyIO8GOFhKRwo/hYWVoP9eGUhYHLX+R06AaJYh3l+h+fBXXq+MOtkSUnRijWIsQwKGTm7juG7DD98wkWSuMaZAU6O62msKJM8RYdltS/JaryGO5jxOZqJy708nZDaIwhBznosZnhC00EfZ
X-Received: by 10.60.132.142 with SMTP id ou14mr2245514oeb.58.1378915938206; Wed, 11 Sep 2013 09:12:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.79.105 with HTTP; Wed, 11 Sep 2013 09:11:58 -0700 (PDT)
In-Reply-To: 
References:   
From: Adam Langley 
Date: Wed, 11 Sep 2013 12:11:58 -0400
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: perpass@ietf.org, "tls@ietf.org" , Alfredo Pironti 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:13:09 -0000

On Wed, Sep 11, 2013 at 12:06 PM, Eric Rescorla  wrote:
> Before we discuss mechanisms, it would be good to verify that in general
> clients and servers don't become unhappy if the timestamp is radically
> wrong. Has someone done measurements to verify that this is in fact
> the case at a broad scale?

I've observed that some small fraction of traffic to Google puts
random bytes in the first-four bytes of the nonce. It was less than
1%, but some clients clearly do this already.


Cheers

AGL

From nick.a.mathewson@gmail.com  Wed Sep 11 09:15:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD121E813F; Wed, 11 Sep 2013 09:15:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.73
X-Spam-Level: 
X-Spam-Status: No, score=-1.73 tagged_above=-999 required=5 tests=[AWL=0.248,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2p9qw3w96Elp; Wed, 11 Sep 2013 09:15:10 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8FBC221E80B6; Wed, 11 Sep 2013 09:14:58 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id n4so2990391qcx.13 for ; Wed, 11 Sep 2013 09:14:57 -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:content-transfer-encoding; bh=0kJ9vsCEjKwxchKhmuongcbGoKhLmSVlP1J6u5wpXe4=; b=aKMrQxnEiX59F5ctAGnk9nKjb/jEIWg3g2ZeOzoOsJnnOQQsNlisZhRJXScSLkVKPA yrOVJ31e+yVlcvcJdVf6uBWkEPwMUxD/tPpXxlnaTvbn40CWGzvgdIkIdcv0/xRQ6OrQ smzpLz6ns2btfo4ssyIzHOeAOO8nknozQV+6pMSBQ82ar8algiv89bn1Pm3arx05mdTt ZsJEiIe2jhZYT3O6zSVqCERqChYJzNrfzilZf7vXijz4T77W1sBlXf0dWcbUfYOaN2lZ doIKThwkxd6BPj02PwOVNaqmCEBSkEkUndtjqr0QjVWoBZzNAkyP5ecictMblCK/JQkF 1sDA==
MIME-Version: 1.0
X-Received: by 10.49.71.106 with SMTP id t10mr4765327qeu.26.1378916097643; Wed, 11 Sep 2013 09:14:57 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 09:14:57 -0700 (PDT)
In-Reply-To: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com>
References:  <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com>
Date: Wed, 11 Sep 2013 12:14:57 -0400
X-Google-Sender-Auth: rF7Q4Kvo78gMWeWKIK0tSba9VYY
Message-ID: 
From: Nick Mathewson 
To: Russ Housley 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [perpass]  Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:15:22 -0000

On Wed, Sep 11, 2013 at 12:04 PM, Russ Housley  wrote=
:
> The tlsdate program (with origins in the TOR project) makes use of this v=
alue in the nonce portion of the handshake.

That's true, and it's one reason that I would propose this as a
client-only change (by default).

> I think that the time is an important part of the nonce.  Even if the imp=
lementation has a crappy random number generator, the time value does a goo=
d job of ensuring that the nonce value is not repeated.  Obviously, the tim=
e value does not help with the unpredictability, but the random value is su=
pposed to do that.

I discussed that a bit in this part of my proposal:

> I doubt that this goal is really achieved, for two reasons:
>
>   * On modern desktop environments, it's not really so strange to
>     start two or more TLS connections within the same second.  When
>     this occurs, the gmt_unix_time fails in its intended purpose of
>     preventing repeated Random values.
>
>   * Nonwithstanding the gmt_unix_time workaround, TLS in general
>     does not withstand broken PRNGs.  For one example, if an
>     implementation's PRNG is prone to repeating ClientRandom
>     values, it is probably prone to repeating those some values as
>     ephemeral Diffie-Hellman private values.

In other words, sending gmt_unix_time in the clear will not save you
from a bad RNG.  (Later in the proposal, in the HMAC-based section, I
explain how sending the gmt_unix_time in the clear is not necessary to
save you from a bad RNG.)

best wishes,
--=20
Nick

From ryan.hurst@globalsign.com  Wed Sep 11 09:20:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8AA21E816E for ; Wed, 11 Sep 2013 09:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level: 
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDVipL0jCJN9 for ; Wed, 11 Sep 2013 09:19:44 -0700 (PDT)
Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 2B17521E813D for ; Wed, 11 Sep 2013 09:19:19 -0700 (PDT)
Received: by mail-yh0-f52.google.com with SMTP id v1so3545829yhn.25 for ; Wed, 11 Sep 2013 09:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=globalsign.com; s=google; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CW27Ym4IxTmglMMGPlvf0q8b40jRRYeo/RgW7BUgXl4=; b=O4ZDCmauhxBhNXxypY82nbLb+Mc2qDvpz50wVD34QxF21uFsowmYV2M0fzfiyqjlHD hg4q7fok7rRLwJyJVR2jd+rspZsb890G1LvSS/ZSr5D93ntnWYKNIw3ifysNfjSfdV34 Us0/aSodiKVQS0NUIXbQ5+8Um/kHs8PjJlkHk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=CW27Ym4IxTmglMMGPlvf0q8b40jRRYeo/RgW7BUgXl4=; b=aIoQEX8wj7JCVqnqGxROBDOxCO+dMe9GOF0akNAjZ6n1XWUilQuH/wYQ8QzbW9Ho7I /H/kGu9vQiQeK9xsTcVZxB7/VmiPqUBxHDPPcdSHRUu2f1llL0QugJsPKQ/RTQvQ4DXq dkrtJyKTHv+V7uXozcDC7pr7e42qdVJxjnD5FOh5jnij5/k02+PGqFdRaPzcoKPBxqOZ 4k5yo8d2LMAK6YO6jBJFEnXugvFCy+Rk+PsEhKD5eSw29lrH2wBQuPi96JgRKo8HMzTx yXfqkCXYrAOvmbPg3Qv7S1sMVO+MWbF04NOKuSMuC980KYHlXhmEZ0IsmovWIJp9AAfY chSw==
X-Gm-Message-State: ALoCoQkibLXvYEz3SczE9SvjxVVKuFXMCET6QfKKY1RN5PStAC4dAB4s1KJlb8SUFaFjoHzW189X
X-Received: by 10.236.171.195 with SMTP id r43mr2180422yhl.56.1378916354477; Wed, 11 Sep 2013 09:19:14 -0700 (PDT)
Received: from [10.215.131.49] (mobile-166-147-082-236.mycingular.net. [166.147.82.236]) by mx.google.com with ESMTPSA id w42sm33505874yhb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 11 Sep 2013 09:19:12 -0700 (PDT)
References:   
Mime-Version: 1.0 (1.0)
In-Reply-To: 
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C; protocol="application/pkcs7-signature"
Content-Transfer-Encoding: 7bit
Message-Id: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com>
X-Mailer: iPhone Mail (10B329)
From: Ryan Hurst 
Date: Wed, 11 Sep 2013 09:19:06 -0700
To: Eric Rescorla 
Cc: "perpass@ietf.org" , "tls@ietf.org" , Alfredo Pironti 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:20:01 -0000

--Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C
Content-Type: multipart/alternative;
	boundary=Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507
Content-Transfer-Encoding: 7bit


--Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

I have looked at this some, network appliances such as F5s Big IP use a rand=
om value instead of time.

I recall seeing some clients also do this but I don't recall which ones.

Basically such a change should be safe.

That said as Russ has pointed out TPSDATE uses this mechanism and though it d=
oesn't solve a broken cryptographic subsystem it is kind of belt and suspend=
ers approach.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: ryan.hurst@globalsign.com
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

On Sep 11, 2013, at 9:06 AM, Eric Rescorla  wrote:

> Before we discuss mechanisms, it would be good to verify that in general
> clients and servers don't become unhappy if the timestamp is radically
> wrong. Has someone done measurements to verify that this is in fact
> the case at a broad scale?
>=20
> -Ekr
>=20
>=20
>=20
> On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti  wrot=
e:
>> I'm in favor of proposal 1, and second the considerations about it;
>> essentially, a broken crypto implementation cannot be fixed by a
>> timestamp.
>>=20
>> If proposal 2 (and 3) was to be implemented on a server, it would also
>> make DoS easier, because a cheap ClientHello (even generated with weak
>> randomness) would trigger an extra HMAC computation on the server,
>> with respect to the current server load.
>>=20
>> Hence, relying on PRNG on both client and server sides looks like a
>> reasonable way to go. I also don't particularly like the asymmetry
>> that proposal 2 may bring: client generating randomness with HMAC, and
>> servers still using the timestamp in clear.
>>=20
>> Cheers,
>> Alfredo
>>=20
>> On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson  wr=
ote:
>> > Hi, all.
>> >
>> > Here's something I wrote about removing a fingerprinting opportunity
>> > from the current TLS protocol.  I was going to just send it to the tls
>> > list, but Ben Laurie suggested that I send it to the perpass list as
>> > well.
>> >
>> > I have little standards-body experience; if this ought to turn into an
>> > RFC or something, I'd be happy to write a draft if need be.
>> >
>> >
>> > (Tor currently plans to implement this by patching OpenSSL; any
>> > feedback or advice would be appreciated.  The first three approaches
>> > below are implemented in OpenSSL branches named "no_client_timestamp",
>> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
>> > repository at https://github.com/nmathewson/openssl .  We have long
>> > shipped our privacy-enhanced browser with a feature like this enabled
>> > through an NSS patch.)
>> >
>> >
>> > =3D=3D=3D=3D
>> > SYNOPSIS:
>> >
>> > In TLS as currently specified, clients and servers each send their
>> > current view of "the time" in the clear as part of their handshake.
>> > This provides a fingerprint that can track users in spite of other
>> > attempts to make them untrackable.  I propose several ways to stop
>> > doing sending this cleartext timestamp; some trivial and some more
>> > complex.
>> >
>> >
>> > ACKNOWLEDGEMENTS:
>> >
>> > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
>> > feedback here.
>> >
>> >
>> > PROBLEM:
>> >
>> > The gmt_unix_time field in the Random field in the TLS handshake
>> > provides a way for an observer to fingerprint clients.
>> >
>> > Despite the late date, much of the world is still not
>> > synchronized to the second via an ntp-like service. This means
>> > that different clients have different views of the current time,
>> > which provides a fingerprint that helps to track and distinguish
>> > them.  This fingerprint is useful for tracking clients as they
>> > move around.  It can also distinguish clients using a single VPN,
>> > NAT, or privacy network.  (Tor's modified firefox avoids this by
>> > not sending the time.)
>> >
>> > Worse, some implementations don't send the current time, but the
>> > process time, or the computer's uptime, both of which are far
>> > more distinguishing than the current time() value.
>> >
>> > The information fingerprint here is strong enough to uniquely
>> > identify some TLS users (the ones whose clocks are hours off).
>> > Even for the ones whose clocks are mostly right (within a second
>> > or two), the field leaks a bit of information, and it only takes
>> > so many bits to make a user unique.
>> >
>> > Of course, I realize that the gmt_unix_time fingerprint is not the
>> > only way to track a typical client as it moves from network to
>> > network, and not the only way to distinguish different clients
>> > behind a NAT.
>> >
>> >
>> >
>> > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>> >
>> > According to third-hand reports (and correct me if I'm wrong!)
>> > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
>> > in cases where the PRNG was completely broken, by making a part of
>> > the Random field that would definitely vary between TLS handshakes.
>> >
>> > I doubt that this goal is really achieved, for two reasons:
>> >
>> >    * On modern desktop environments, it's not really so strange to
>> >      start two or more TLS connections within the same second.  When
>> >      this occurs, the gmt_unix_time fails in its intended purpose of
>> >      preventing repeated Random values.
>> >
>> >    * Nonwithstanding the gmt_unix_time workaround, TLS in general
>> >      does not withstand broken PRNGs.  For one example, if an
>> >      implementation's PRNG is prone to repeating ClientRandom
>> >      values, it is probably prone to repeating those some values as
>> >      ephemeral Diffie-Hellman private values.
>> >
>> > Nevertheless, if the goal of providing unique-looking output
>> >
>> >
>> >
>> > WHY ELSE IS gmt_unix_time USED?
>> >
>> > The consensus among implementors I've asked seems to be that it's
>> > unwise to depend on any particular value or interpretation for the
>> > field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
>> > required to be set correctly by the basic TLS protocol; higher-level
>> > or application protocols may define additional requirements."
>> >
>> > Some implementations set the entire gmt_unix_time field randomly;
>> > this appears not to have broken TLS on the internet.
>> >
>> > At least one tool (tlsdate) uses the server-side value of the
>> > field as an authenticated view of the current time.
>> >
>> >
>> >
>> > PROPOSAL 1:
>> >
>> > Declare that implementations MAY replace gmt_unix_time either with
>> > four more random bytes, or four bytes of zeroes.
>> >
>> > Rationale:
>> >    * Some implementations (like TorBrowser) are already doing this
>> >      in practice.
>> >
>> >    * It's sensible and simple.  Implementors are quite unlikely to
>> >      mess it up.
>> >
>> >
>> >
>> > PROPOSAL 2:
>> >
>> > Suppose that we do not accept the argument about the pointlessness
>> > of gmt_unit_time that I make above, and we want to preserve the
>> > security it allegedly provides.
>> >
>> > In that case, we can allow the following approach instead:
>> >
>> > Set the Random field, not to 32 bytes from your PRNG, but to the
>> > HMAC-SHA256 of any high resolution timer that you have, using 32
>> > bytes from your PRNG as a key.  In other words, replace this:
>> >
>> >    Random.gmt_unix_time =3D time();
>> >    Random.random_bytes =3D get_random_bytes(28)
>> >
>> > with this:
>> >
>> >    now =3D hires_time(); // clock_gettime(), or concatenate time()
>> >                        // with a CPU timer, or process
>> >                        // uptime, or whatever.
>> >    key =3D get_random_bytes(32);
>> >    Random =3D hmac_sha256(key, now);
>> >
>> > This approach is better than the status quo on the following
>> > counts:
>> >
>> >    * It doesn't leak your view of the current time, assuming that
>> >      your PRNG isn't busted.
>> >
>> >    * It actually fixes the problem that gmt_unix_time purported to
>> >      fix, by using a high-resolution time that's much less likely to
>> >      be used twice.  Even if the PRNG is broken, the value is still
>> >      nonrepeating.
>> >
>> > I do not think this is not worse than the status quo:
>> >
>> >    * It is unpredictable from an attacker's POV, assuming that the
>> >      PRNG works.  (Because an HMAC, even of known data, with an
>> >      unknown random key is supposed to look random).
>> >
>> >
>> > PROPOSAL 3
>> >
>> > As a hybrid alternative, one could set part of the ClientRandom
>> > field (perhaps 12 bytes or so) based on the HMAC of the time, and
>> > the rest of the ClientRandom field based on the PRNG:
>> >
>> >    N =3D 12
>> >
>> >    now =3D hires_time();
>> >    key =3D get_random_bytes(32);
>> >    mac =3D hmac_sha256(key, now)[0:N];  // First N bytes.
>> >    rand =3D get_random_bytes(32 - N)
>> >    Random =3D mac ++ rand               // concatenate.
>> >
>> > But this seems to be getting pointlessly baroque.
>> >
>> >
>> >
>> > CONSIDERATIONS:
>> >
>> > I'd personally suggest proposal 1 (just set the field at random) for
>> > most users.  Yes, it makes things a little worse if your PRNG can
>> > generate repeat values... but nearly everything in cryptography
>> > fails if your PRNG is broken.
>> >
>> >
>> > We might want to apply this fix on clients only.  With a few
>> > exceptions (like hidden services) the server's view of the current
>> > time is not sensitive.
>> >
>> >
>> > Implementors might want to make this feature optional and
>> > on-by-default, just in case some higher-level application protocol
>> > really does depend on it.
>> > _______________________________________________
>> > TLS mailing list
>> > TLS@ietf.org
>> > https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


I have looked at this some, network appliances such as F5s Big IP u=
se a random value instead of time.

I recall seeing s=
ome clients also do this but I don't recall which ones.

=

Basically such a change should be safe.

That s=
aid as Russ has pointed out TPSDATE uses this mechanism and though it doesn'=
t solve a broken cryptographic subsystem it is kind of belt and suspenders a=
pproach.

Ryan Hurst

twitter: @rmhrisk
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

O=
n Sep 11, 2013, at 9:06 AM, Eric Rescorla <ekr@rtfm.com> wrote:

Before we discuss mechanisms, it would be good to verify that=
 in general
clients and servers don't become unhappy if the timestamp is=
 radically
wrong. Has someone done measurements to verify that thi=
s is in fact



the case at a broad scale?

-Ekr

=



On=
 Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <alfredo@pironti.eu><=
/span> wrote:



I'm in favor of proposal 1, and second the con=
siderations about it;

essentially, a broken crypto implementation cannot be fixed by a

timestamp.



If proposal 2 (and 3) was to be implemented on a server, it would also

make DoS easier, because a cheap ClientHello (even generated with weak

randomness) would trigger an extra HMAC computation on the server,

with respect to the current server load.



Hence, relying on PRNG on both client and server sides looks like a

reasonable way to go. I also don't particularly like the asymmetry

that proposal 2 may bring: client generating randomness with HMAC, and

servers still using the timestamp in clear.



Cheers,

Alfredo




On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <nickm@torproject.org> wrote:

> Hi, all.

>

> Here's something I wrote about removing a fingerprinting opportunity
> from the current TLS protocol.  I was going to just send it to the=
 tls

> list, but Ben Laurie suggested that I send it to the perpass list as
> well.

>

> I have little standards-body experience; if this ought to turn into an<=
br>
> RFC or something, I'd be happy to write a draft if need be.

>

>

> (Tor currently plans to implement this by patching OpenSSL; any

> feedback or advice would be appreciated.  The first three approach=
es

> below are implemented in OpenSSL branches named "no_client_timestamp",<=
br>
> "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git

> repository at https://github.com/nmathewson/openssl .  We have long

> shipped our privacy-enhanced browser with a feature like this enabled
> through an NSS patch.)

>

>

> =3D=3D=3D=3D

> SYNOPSIS:

>

> In TLS as currently specified, clients and servers each send their

> current view of "the time" in the clear as part of their handshake.
=

> This provides a fingerprint that can track users in spite of other

> attempts to make them untrackable.  I propose several ways to stop=


> doing sending this cleartext timestamp; some trivial and some more

> complex.

>

>

> ACKNOWLEDGEMENTS:

>

> Thanks to Adam Langley, Ben Laurie, and everybody else who gave me

> feedback here.

>

>

> PROBLEM:

>

> The gmt_unix_time field in the Random field in the TLS handshake

> provides a way for an observer to fingerprint clients.

>

> Despite the late date, much of the world is still not

> synchronized to the second via an ntp-like service. This means

> that different clients have different views of the current time,

> which provides a fingerprint that helps to track and distinguish

> them.  This fingerprint is useful for tracking clients as they
=

> move around.  It can also distinguish clients using a single VPN,<=
br>
> NAT, or privacy network.  (Tor's modified firefox avoids this by
> not sending the time.)

>

> Worse, some implementations don't send the current time, but the

> process time, or the computer's uptime, both of which are far

> more distinguishing than the current time() value.

>

> The information fingerprint here is strong enough to uniquely

> identify some TLS users (the ones whose clocks are hours off).

> Even for the ones whose clocks are mostly right (within a second

> or two), the field leaks a bit of information, and it only takes

> so many bits to make a user unique.

>

> Of course, I realize that the gmt_unix_time fingerprint is not the

> only way to track a typical client as it moves from network to

> network, and not the only way to distinguish different clients

> behind a NAT.

>

>

>

> BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?

>

> According to third-hand reports (and correct me if I'm wrong!)

> gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
=

> in cases where the PRNG was completely broken, by making a part of

> the Random field that would definitely vary between TLS handshakes.
=

>

> I doubt that this goal is really achieved, for two reasons:

>

>    * On modern desktop environments, it's not really so stran=
ge to

>      start two or more TLS connections within the same s=
econd.  When

>      this occurs, the gmt_unix_time fails in its intende=
d purpose of

>      preventing repeated Random values.

>

>    * Nonwithstanding the gmt_unix_time workaround, TLS in gen=
eral

>      does not withstand broken PRNGs.  For one exam=
ple, if an

>      implementation's PRNG is prone to repeating ClientR=
andom

>      values, it is probably prone to repeating those som=
e values as

>      ephemeral Diffie-Hellman private values.

>

> Nevertheless, if the goal of providing unique-looking output

>

>

>

> WHY ELSE IS gmt_unix_time USED?

>

> The consensus among implementors I've asked seems to be that it's

> unwise to depend on any particular value or interpretation for the

> field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not<=
br>
> required to be set correctly by the basic TLS protocol; higher-level
> or application protocols may define additional requirements."

>

> Some implementations set the entire gmt_unix_time field randomly;

> this appears not to have broken TLS on the internet.

>

> At least one tool (tlsdate) uses the server-side value of the

> field as an authenticated view of the current time.

>

>

>

> PROPOSAL 1:

>

> Declare that implementations MAY replace gmt_unix_time either with

> four more random bytes, or four bytes of zeroes.

>

> Rationale:

>    * Some implementations (like TorBrowser) are already doing=
 this

>      in practice.

>

>    * It's sensible and simple.  Implementors are quite u=
nlikely to

>      mess it up.

>

>

>

> PROPOSAL 2:

>

> Suppose that we do not accept the argument about the pointlessness

> of gmt_unit_time that I make above, and we want to preserve the

> security it allegedly provides.

>

> In that case, we can allow the following approach instead:

>

> Set the Random field, not to 32 bytes from your PRNG, but to the

> HMAC-SHA256 of any high resolution timer that you have, using 32

> bytes from your PRNG as a key.  In other words, replace this:

>

>    Random.gmt_unix_time =3D time();

>    Random.random_bytes =3D get_random_bytes(28)

>

> with this:

>

>    now =3D hires_time(); // clock_gettime(), or concatenate t=
ime()

>                     &=
nbsp;  // with a CPU timer, or process

>                     &=
nbsp;  // uptime, or whatever.

>    key =3D get_random_bytes(32);

>    Random =3D hmac_sha256(key, now);

>

> This approach is better than the status quo on the following

> counts:

>

>    * It doesn't leak your view of the current time, assuming t=
hat

>      your PRNG isn't busted.

>

>    * It actually fixes the problem that gmt_unix_time purport=
ed to

>      fix, by using a high-resolution time that's much le=
ss likely to

>      be used twice.  Even if the PRNG is broken, th=
e value is still

>      nonrepeating.

>

> I do not think this is not worse than the status quo:

>

>    * It is unpredictable from an attacker's POV, assuming tha=
t the

>      PRNG works.  (Because an HMAC, even of known d=
ata, with an

>      unknown random key is supposed to look random).
=

>

>

> PROPOSAL 3

>

> As a hybrid alternative, one could set part of the ClientRandom

> field (perhaps 12 bytes or so) based on the HMAC of the time, and

> the rest of the ClientRandom field based on the PRNG:

>

>    N =3D 12

>

>    now =3D hires_time();

>    key =3D get_random_bytes(32);

>    mac =3D hmac_sha256(key, now)[0:N];  // First N bytes=
.

>    rand =3D get_random_bytes(32 - N)

>    Random =3D mac ++ rand           &=
nbsp;   // concatenate.

>

> But this seems to be getting pointlessly baroque.

>

>

>

> CONSIDERATIONS:

>

> I'd personally suggest proposal 1 (just set the field at random) for
> most users.  Yes, it makes things a little worse if your PRNG can<=
br>
> generate repeat values... but nearly everything in cryptography

> fails if your PRNG is broken.

>

>

> We might want to apply this fix on clients only.  With a few

> exceptions (like hidden services) the server's view of the current

> time is not sensitive.

>

>

> Implementors might want to make this feature optional and

> on-by-default, just in case some higher-level application protocol

> really does depend on it.

> _______________________________________________

> TLS mailing list

> TLS@ietf.org

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

_______________________________________________

TLS mailing list

TLS@ietf.org

http=
s://www.ietf.org/mailman/listinfo/tls





____________________=
___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis=
tinfo/tls
=

--Apple-Mail-6464FC36-C1BE-4E70-BAEC-A79B182D7507--

--Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFCjCCBQYw
ggPuoAMCAQICEhEhb640/F3CUxHuqwZT6bSC5TANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJC
RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25h
bFNpZ24gMiBDQSAtIEcyMB4XDTEyMDEyMzE2MzY1OVoXDTE1MDEyMzE2MzY1OVowgZQxCzAJBgNV
BAYTAlVTMRYwFAYDVQQIEw1OZXcgSGFtc3BoaXJlMRMwEQYDVQQHEwpQb3J0c21vdXRoMRkwFwYD
VQQKExBHbG9iYWxTaWduLCBJbmMuMRMwEQYDVQQDEwpSeWFuIEh1cnN0MSgwJgYJKoZIhvcNAQkB
FhlyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAuAEkk72r5rBUAKG+tLpEksDgC/Z0/7PfZbTVAgH+Xzx+YzXHjCsWkLHtpojpkUSF2spHKtaf
02yO9GbXHt/K9pmzsKgxxz1YtdxsSRMlF1oGkQbXgzLuThsljRtZHIVbBlqW7LU9GeL9JneZtQWB
Z8QdtHmycjkdpVw8bBStvJ5ylfuXjI++lPAaT0OEgh+8kzBustF17Ad3AqwSq9qN0zmIBCr/qDZ2
2qDLd1MTLfZ0n/Y8iLIY6n50+QHsNwlDTGrTueYORV13SLpAMHoNWEm9ZbNOalt7FtNE93e3ULPf
+zbsQoPwNnpZlSUqMvPjC0fCUhRH/2jIIzv08i4P4wIDAQABo4IBjzCCAYswDgYDVR0PAQH/BAQD
AgWgME0GA1UdIARGMEQwQgYKKwYBBAGgMgEoCjA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5n
bG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzAkBgNVHREEHTAbgRlyeWFuLmh1cnN0QGdsb2JhbHNp
Z24uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdHwQ8
MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3NwZXJzb25hbHNpZ24yZzIu
Y3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDovL3NlY3VyZS5nbG9iYWxzaWdu
LmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24yZzIuY3J0MB0GA1UdDgQWBBRVohAntPy+9nlWKnFm
Jy1ekko84TAfBgNVHSMEGDAWgBQ/FdJtfC/nMZ5DCgaolGwsO8XuZTANBgkqhkiG9w0BAQUFAAOC
AQEAIUIuoSz3rnZn9yAReCA8wr0SNBWmHQSn6a0pPx9Dw3muL6bC21qQNLdEmoo4iWLcSo5TOGz3
ftnIW+3o2rQ3cq2SM5g1cquHN9P8TJ4pxiqJKWANdf1Xvotnb47pbuuamrK7UERsmwLrmeu5a6fy
tzjBYI1eTQtwB2C87zVOA8HOEENQWjDoOis2EqymwAUWWo366Qvbonj7L+5gyFy8f7aAT8VjZWub
yZuQ62XZ+7h3bwQhOpDMpGzizeaZhCtFCJcCoekIuVw9Kc5VZBGZYhZATCYLm3f3he8XoO0yj1gu
ccjhafUnTKJSTOy0wt8J0jt36wQHr/qv5xrPV8cr7DGCAuowggLmAgEBMGowVDELMAkGA1UEBhMC
QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVyc29u
YWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMAkGBSsOAwIaBQCgggFVMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDkxMTE2MTkxMVowIwYJKoZI
hvcNAQkEMRYEFA9l55StJEHWXDenpxYkDBIbq2u7MHkGCSsGAQQBgjcQBDFsMGowVDELMAkGA1UE
BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExKjAoBgNVBAMTIUdsb2JhbFNpZ24gUGVy
c29uYWxTaWduIDIgQ0EgLSBHMgISESFvrjT8XcJTEe6rBlPptILlMHsGCyqGSIb3DQEJEAILMWyg
ajBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv
YmFsU2lnbiBQZXJzb25hbFNpZ24gMiBDQSAtIEcyAhIRIW+uNPxdwlMR7qsGU+m0guUwDQYJKoZI
hvcNAQEBBQAEggEAQrQEK8WGsJVldIBkiyuHse0q8y529bqlfeB6OtsnfDRhivnQ4eQLIbIOY6A0
KUPwBQSYYbUEGgMIU2lZ2S5TLmxltLDLcZY+2ZxPNcRj9H0jL1kMQmJXki16GeIsGxZL+Ixr7QXe
dPgr68Chxs/qTTY/q559l3s4CIbxMEMwhLrIam4BaUGcWk3Xb++cGhkXqu/pKELdGHtJR2EtuOFU
MgEN1uitlQKIv2ytprB9P8KQTW6c0kDesyhe8UVmdpieh8LhtS54+FQyhm/Kn2isH9Q/dCf7bhZH
4rkQVK7Pqu8JcpCSwpYa+S7LiVty0svAC+Fo3fQaEblrbzK9dyxRoAAAAAAAAA==

--Apple-Mail-92561D84-7739-4029-9D31-66A0E1FC071C--

From nick.a.mathewson@gmail.com  Wed Sep 11 09:32:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB60F21F9FFF; Wed, 11 Sep 2013 09:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.792
X-Spam-Level: 
X-Spam-Status: No, score=-1.792 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tw1tpgGlb2Nm; Wed, 11 Sep 2013 09:32:41 -0700 (PDT)
Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9DF21F9BC3; Wed, 11 Sep 2013 09:32:40 -0700 (PDT)
Received: by mail-qe0-f51.google.com with SMTP id ne12so5687623qeb.10 for ; Wed, 11 Sep 2013 09:32:40 -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=wirqVF+Yx86PmdTtJi1hAE+OXzeM0BKEclEh0aEKJ94=; b=FuPtkyRuJriqW1rSYlx6BNex4okopNTnml/uVhHkYi2WPL5m7yxXmXG5VsIytyUISe vtyKgFaxmueSnhvgh5Mu5K3rW2Rdk/qo7WAKNaeBp+YSK52SkYXgFqjG3Td9TBknK05M bUOKbHyg1YAyC3ByoRcAs0exCekxQEVFBSk1AmZWlsMMaEOu714bL7dxcbaLVaTyILgK ipNtAC0Rmgst5zrwZAjQZxDfgW0lWwCT5xOuoH88+i9SBI4d+DVuxdnnVZghZrNvrcLX QJLb+1bLn0EjY3249CxW2tSjlkvo0NN9Cx2LFUQtA9+WAHCf4NW2yhrOV5nsJA++MZIs J+iA==
MIME-Version: 1.0
X-Received: by 10.49.25.102 with SMTP id b6mr4555274qeg.91.1378917160355; Wed, 11 Sep 2013 09:32:40 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 09:32:40 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 11 Sep 2013 12:32:40 -0400
X-Google-Sender-Auth: INvwXlEciOoOBehffdxr1jiN6Pg
Message-ID: 
From: Nick Mathewson 
To: Eric Rescorla 
Content-Type: text/plain; charset=ISO-8859-1
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:32:41 -0000

On Wed, Sep 11, 2013 at 12:06 PM, Eric Rescorla  wrote:
> Before we discuss mechanisms, it would be good to verify that in general
> clients and servers don't become unhappy if the timestamp is radically
> wrong. Has someone done measurements to verify that this is in fact
> the case at a broad scale?

Tor Browser has omitted this field for over five years now to no ill effect.

It would appear (assuming that I'm reading old NSS source right, which
I might not be!) that from about 2000 to 2008, Firefox was sending the
time since the process started, not the unix time, and nobody noticed
until 2007:
     https://bugzilla.mozilla.org/show_bug.cgi?id=405652

So at least on the client side, there seems to be strong evidence that
sending something other than the correct time does not cause obvious
problems in the wild.

yrs,
-- 
Nick

From paul@nohats.ca  Wed Sep 11 09:40:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05CF411E8192; Wed, 11 Sep 2013 09:40:49 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrpSwwPcr80N; Wed, 11 Sep 2013 09:40:43 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0F03E11E80FF; Wed, 11 Sep 2013 09:40:42 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3cZpkm6Sj9z9HG; Wed, 11 Sep 2013 12:40:32 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bcVp358nAtXF; Wed, 11 Sep 2013 12:40:31 -0400 (EDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by mx.nohats.ca (Postfix) with ESMTP; Wed, 11 Sep 2013 12:40:31 -0400 (EDT)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 32180848E5; Wed, 11 Sep 2013 12:40:31 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0A888848E4; Wed, 11 Sep 2013 12:40:31 -0400 (EDT)
Date: Wed, 11 Sep 2013 12:40:31 -0400 (EDT)
From: Paul Wouters 
To: Russ Housley 
In-Reply-To: <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com>
Message-ID: 
References:  <49E21B63-C93A-450A-80EE-2050FFCDC0B4@vigilsec.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:40:49 -0000

On Wed, 11 Sep 2013, Russ Housley wrote:

> The tlsdate program (with origins in the TOR project) makes use of this value in the nonce portion of the handshake.
>
> I think that the time is an important part of the nonce.  Even if the implementation has a crappy random number generator, the time value does a good job of ensuring that the nonce value is not repeated.  Obviously, the time value does not help with the unpredictability, but the random value is supposed to do that.

Note that tlsdate is a stowaway on board a TLS server. If we can
accomodate, then fine. But we shouldn't go out of our way to support it.

Between making tls less vulnerable to fingerprinting (which helps tor)
and supporting tlsdate, I'd opt for the former.


Paul

From p.j.bakker@offspark.com  Wed Sep 11 09:42:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D031211E8192 for ; Wed, 11 Sep 2013 09:42:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFNf2zupvrrj for ; Wed, 11 Sep 2013 09:42:39 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D221E8149 for ; Wed, 11 Sep 2013 09:42:26 -0700 (PDT)
Received: from ip54507da9.speed.planet.nl ([84.80.125.169] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VJnP8-0000Ui-17 for tls@ietf.org; Wed, 11 Sep 2013 18:36:34 +0200
From: 
Sender: "Paul Bakker" 
To: 
References: 		 
In-Reply-To: 
Date: Wed, 11 Sep 2013 18:42:19 +0200
Message-ID: <004f01ceaf0d$e4f0e030$aed2a090$@polarssl.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQGw89OdAzuRzNVjwsYPHKl/X1BIawGYczkMAVpxk0MCAfYBDJnUivQw
Content-Language: nl
X-SA-Exim-Connect-IP: 84.80.125.169
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:48:15 -0000

I can confirm that PolarSSL has no issues with receiving random data instead
of the timestamp.

On Wed, Sep 11, 2013 at 12:06 PM, Eric Rescorla  wrote:
> Before we discuss mechanisms, it would be good to verify that in
> general clients and servers don't become unhappy if the timestamp is
> radically wrong. Has someone done measurements to verify that this is
> in fact the case at a broad scale?


From hanno@hboeck.de  Wed Sep 11 09:53:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A2721E8177 for ; Wed, 11 Sep 2013 09:53:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETKNe6vEjwYQ for ; Wed, 11 Sep 2013 09:53:43 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id B3DFB21E8126 for ; Wed, 11 Sep 2013 09:53:43 -0700 (PDT)
Received: from localhost (24-134-32-151-dynip.superkabel.de [::ffff:24.134.32.151]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 11 Sep 2013 18:53:39 +0200 id 000000000000004B.000000005230A013.000067AB
Date: Wed, 11 Sep 2013 18:53:29 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20130911185329.3dcd75db@hboeck.de>
In-Reply-To: 
References: 
X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-26539-1378918420-0001-2"
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 16:53:54 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-26539-1378918420-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 11 Sep 2013 11:43:53 -0400
Nick Mathewson  wrote:

> Despite the late date, much of the world is still not
> synchronized to the second via an ntp-like service. This means
> that different clients have different views of the current time,
> which provides a fingerprint that helps to track and distinguish
> them.  This fingerprint is useful for tracking clients as they
> move around.  It can also distinguish clients using a single VPN,
> NAT, or privacy network.  (Tor's modified firefox avoids this by
> not sending the time.)

I can't help getting the feeling that you're trying to fix the wrong
thing here. People use computers with a wrong clock. That's the problem
here. You should try to fix that and not workaround it.

My suggestion: Tor could detect on startup if the time is correct via
ntp (or even through the tor network itself with the next server). If
its not, it refuses to start unless an option like
"iknowmytimeisbrokenandidontcare" is set. For the gui, issue a warning
and an easy option to fix the time.


--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-26539-1378918420-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQIcBAEBCAAGBQJSMKALAAoJEKWIAHK7tR5CGQMQAJrX+u6M5H7s85htmw3jcUNE
Dh9MSMdyObLr2K9Ezx2fopo0cWh7utmz7sw08LFQNyGLk27wdjO6z1LJ+PKNXnSD
J3kBwy0AFrEeFn7ysxYynnkTUS0QKTnEX/GShOnI6XzjTIF8B70DPo6P7eFaRJw7
+4+RTyltxkv75oL32xQ25K8rdOyGe9Uu/qYVi357dMF3B5jKq0eQJmWZzT9lnKtQ
gD5cbsvWwof9ZeXgJ531st6Tpty2O5REn+MSL6FXFyE87y+7eF/PysyKe2qE2InX
XN12yExFLK0gmWUcE0lFAm6BgJYJJayeLeIOFyRRNfuyzFFHWYNtxJuOCQ8L/Cv0
a6v/onQwkzmfgG3xKPUjN5K2W5+BBJsgKkDzaJE09P3Bi8o9EX4M/gBFccEvSJAU
X/9blNCh3BU+q4L2FuIxs+nwaJS35S+S+TzYafz+J1pbM6XcszEwuLUxjfpWIjh4
FiXRuzmlTKDVmKg23ZsUtqP3t01jtWM2JtQ9ouXnxIqGlgtb3cymAeTdaxMut1Cn
oV0132Ua9kZIKaJWSoomrjZBxyDbor6wjdHeatFb1DwRAQTPEQDNzyxIPuiDYShY
TcBNPQCMvBsrXInDGm0Y+ti0M6mZ/Q7kR16NBGIDgsHjMKLGAp+6z1KxTYu5Q9B3
LR9H4gISNp4CwVX6Q/Xq
=RqJz
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-26539-1378918420-0001-2--

From dbrown@certicom.com  Wed Sep 11 10:12:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6ED221F8497 for ; Wed, 11 Sep 2013 10:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.392
X-Spam-Level: 
X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDRy19UjmtpO for ; Wed, 11 Sep 2013 10:12:39 -0700 (PDT)
Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id D9E2C11E81D7 for ; Wed, 11 Sep 2013 10:12:22 -0700 (PDT)
X-AuditID: 0a412830-b7f576d00000095e-1b-5230a4677308
Received: from XCT101CNC.rim.net (xct101cnc.rim.net [10.65.161.201]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 0D.84.02398.764A0325; Wed, 11 Sep 2013 12:12:07 -0500 (CDT)
Received: from XCT114CNC.rim.net (10.65.161.214) by XCT101CNC.rim.net (10.65.161.201) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 11 Sep 2013 13:12:06 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Wed, 11 Sep 2013 13:12:06 -0400
From: Dan Brown 
To: "'nickm@torproject.org'" 
Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
Thread-Index: AQHOrPzUSgKBdqWRokmt5ggMXGJ/7Zm9g/qAgABVnwCAAHtwAIAAHIYAgAJ5mQD//8fn4A==
Date: Wed, 11 Sep 2013 17:12:05 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BCF149@XMB116CNC.rim.net>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au>   <20130910012240.5595281.33313.3530@certicom.com> 
In-Reply-To: 
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.250]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01CEAEF0.830A2FB0"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNJsWRmVeSWpSXmKPExsXC5bjwpG76EoMgg5nvRSwuHN3AbnFu03sm i0/nuxgdmD2WLPnJ5LFn/Rc2j83rL7MFMEeJ2KSk5mSWpRbp2yFYCSIZR6acYi3YmFLR/2An ewNjV0wXIyeHhICJxI7Dv5khbDGJC/fWs3UxcnEICbQzSWzetBPKWckosX/XI7AqIYHZjBLL dvKC2GwCqhL3j54Di4sIGEus/v0EzGYWCJLYsnAaE4gtLBAtsfvIalaImhiJtX/WQNWHSXy+ vA0szgI051JzI1g9r4CbROvrnYxQu5glbp+XBrE5BQIlOv72gMUZBWQldp+9zgSxS1zi1pP5 TBAfiEg8vHiaDcIWlXj5+B8rhK0ocWLZCrBnmAV6GSW2/1jKDLFMUOLkzCcsEMsUJK5c38cy gVF8FpK5s5D1zELSM4uRAyihJ9G2kRGiXl5i+9s5zBC2rcT+qyuhbEWJKd0P2SFsU4nXRz8y LmDkWMUomJtRbGBmmJyXrFeUmauXl1qyiREc2xoGOxjfv7c4xCjAwajEwysyzSBIiDWxrLgy 9xCjCtCMRxtWX2CUYsnLz0tVEuFtnwCU5k1JrKxKLcqPLyrNSS0+xPiZERimE5mluJPzgQkp ryTe2MCAWI4ojGNoZGluaGlmbGZqYmg2eISVxHldVT4ECgmkJ5akZqemFqQWwbzNxMEp1cDI tcrz9NMFu76qP7+gN6/XUMdXV7bonp2QAesVMSXtzbnmFu9az5Umc0/KP/Doga7bDZMF0d7f Jm1zTQ7Of1E9deljti39RW+EO6w6AnL29ExpVZj00cd27d3H0+W/fTs0J2r1uldrNwW+88o+ Lu4sktSfK3dePM5zAfcD4wI9h62VX481JL1SYinOSDTUYi4qTgQACLjY7c4DAAA=
Cc: "'tls@ietf.org'" 
Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 17:12:52 -0000

------=_NextPart_000_0000_01CEAEF0.830A2FB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: nick.a.mathewson@gmail.com [mailto:nick.a.mathewson@gmail.com] On
> Behalf Of Nick Mathewson
> Sent: Wednesday, September 11, 2013 11:10 AM
> To: Dan Brown
> On Mon, Sep 9, 2013 at 9:22 PM, Dan Brown  wrote:
> >
> > The curve seed sources were not documented in ANSI or NIST docs. I've
> wondered about it a few times, but could never see a concrete problem.
> At least intuitively, it would only be a problem if:
> >
> > 1) a large fraction of elliptic curves were weak, or
> >
> > 2) sha1 preimages are easy to find and some unknown but rare class of
> elliptic curves are weak.
> >
> > Both of these would undermine more than just the curve choice, and
> seem extremely unlikely.
> 
> That's true, so long as "large fraction" and "rare" are defined
> appropriately.  But I think what most of the people who worry about
> this are worried about is something like:
> 
> 3) A small-ish fraction of elliptic curves (say, one in every
> quadrillion or quintillion or so) has some as-yet-unknown weakness,
> and building a sha1 brute-forcing engine to find seeds that would
> produce such curves was economically viable the late 1990s.
> 
[DB]  Good point.  My colleague Randy Tsang mentioned a similar point to me
yesterday.  

Your situation (3) is what I meant by my (1).  By a "large fraction", I
meant one with an inverse representing a feasible number of steps.  I should
have clarified this, because there are many other reasonable meanings of
large fraction.  Sorry.  More importantly, I should clarify why I consider
this to undermine more than just the curve choice.

Firstly, if the hypothetical weakness was that the DLP was easy, then
installing such a backdoor would be unwise, because it would backfire once
somebody else discovers the weakness.  I do not see how the hypothetical
weakness could be a high-entropy trapdoor, unless SHA1 inversion was
possible.  (This would be analogous to my scenario #2.)  So, an open
backdoor would be feasible for somebody else to discover the weakness, only
being a matter of insight.

Secondly, if we take the view that an undiscovered classes of weak curves
might exist, say with density 2^(-30), and needing research work 2^(40) to
find, then we must reduce the claimed security level of any given curve, to
a level appropriate to these levels, 70 bits in this example.  Given that
many people would be likely to use the same curve, this level may not be
acceptable.  In other words, the hypothesis of your scenario 3 above, also
mildly jeopardizes other curves (but not to the same extent as a
maliciously-chosen curve, of course).  

In other words, a simplistic viewpoint is to define security levels against
best-known attacks, which excludes all the situations above.  A more
sophisticated type of security level attempts to anticipate
as-yet-undiscovered or as-yet-undisclosed attacks, and by tracking the rate
of discovery, inferring from evidence whether attacks are undisclosed, and
so on.  

Aside: it should be comforting that NIST also recommends "Koblitz" curves
which have no wiggle room, and hence no opportunity for a backdoor.  (Some
articles on efficient scalar multiplication of Koblitz curves are
informative here.)  Such curves are canonical, rather than verifiably
random.  I believe that Curve25519 is also canonical in a similar way in
that it relies on small curve coefficients.   One security argument against
canonical curves is that they are special and would be more likely belong to
some weak class (but see (*) below).  (Similar special class: curves of
order p defined over Fp are weak.)  For various reasons, many have
gravitated away from Koblitz curves.

Perhaps the ideal is a combination of verifiably random and canonical, which
I mentioned in my previous message.  Again: hash a small value, or otherwise
wiggle-free value, to obtain the curve of desirable order, etc.  This might
be worthwhile, though not tremendously worthwhile by the arguments above.

(*) On the other hand, special cases may also resist some attacks. For
example, Jao recently proposed using supersingular curves to avoid
subexponential-time isogenies.




------=_NextPart_000_0000_01CEAEF0.830A2FB0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw
ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l
dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz
WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu
ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy
czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH
jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH
An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw
CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME
AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww
FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6
MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu
YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw
U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp
b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp
bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH
MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0
RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG
KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R
BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN
o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2
ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg
k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G
Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC
BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB
GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN
Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ
FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D
QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna
iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp
yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg
Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3
mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq
6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN
9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh
vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr
UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0
hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG
AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW
aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov
Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k
b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j
UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu
cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ
KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2
fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf
+ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi
fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9
aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8
rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ
jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog
dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s
FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z
bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD
ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx
EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT
dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx
jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV
mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X
Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa
99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p
036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w
HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE
AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe
CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg
MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys
Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz
LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp
b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew
MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu
Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy
MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp
Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG
Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93
cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB
AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK
PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f
aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG
E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6
xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2
6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k
q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg
jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0
KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts
MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt
MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D
AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTEx
MTcxMjA1WjAjBgkqhkiG9w0BCQQxFgQUm64qGtmqBmIf+t4q/wcg0bUcws4wZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw
EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi
b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR
BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv
cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgEhgY8rjAqdI
FJnuPLUFyESdyZFX82FohBhWnG8nRncKCjnT/tkCNXWau88w+VbXPkGP0lCd2UWC8Nv4kT7LYyQA
Nb43/HykdAGEL/IH/89yYj74fG0JivPGORdjAHNuZEpPDixKmM6+HvJvFPy7kQxMAjtPvg5fkVuw
AUEhh2MTAAAAAAAA

------=_NextPart_000_0000_01CEAEF0.830A2FB0--

From simon@josefsson.org  Wed Sep 11 10:13:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4855521F9950 for ; Wed, 11 Sep 2013 10:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPrPIc9MOzrP for ; Wed, 11 Sep 2013 10:13:30 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 3834C21F8616 for ; Wed, 11 Sep 2013 10:13:14 -0700 (PDT)
Received: from latte.josefsson.org ([38.111.151.140]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8BHCcjO000701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 11 Sep 2013 19:12:42 +0200
From: Simon Josefsson 
To: Rob Stradling 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:130911:tls@ietf.org::01n6l80lrWdj6XCy:Fu5S
X-Hashcash: 1:22:130911:code@funwithsoftware.org::IiuN+0cly6SCSmd5:K1Yb
X-Hashcash: 1:22:130911:rob.stradling@comodo.com::DhZ5y69jgTfDVS7G:Ezl0
Date: Wed, 11 Sep 2013 10:12:31 -0700
In-Reply-To: <522ED9A7.7080802@comodo.com> (Rob Stradling's message of "Tue, 10 Sep 2013 09:34:47 +0100")
Message-ID: <87fvtbi8ow.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 17:13:31 -0000

Rob Stradling  writes:

> Simon, thanks for creating this draft.
>
> draft-merkle-tls-brainpool-04 (on which you've based this new draft) says:
>    "While the ASN.1 object identifiers
>    defined in [RFC5639] already allow usage of the ECC Brainpool curves
>    for TLS (client or server) authentication through reference in X.509
>    certificates according to [RFC3279] and [RFC5480] , their negotiation
>    for key exchange according to [RFC4492] requires the definition and
>    assignment of additional NamedCurve IDs."
>
> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it
> to be used for key exchange.  But what about "(client or server)
> authentication through reference in X.509 certificates..."?
>
> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
> create one?  Or could we simply define some new ASN.1 Object
> Identifiers in your draft?

Yes perhaps.  What would the purpose of using Curve25519 in X.509
certificates be?  Performance is less critical there than for ECDH, but
if you or someone else has numbers indicating X.509 signature
verification being a performance bottle neck I would be convinced
otherwise.  There could be other reasons than performance though, but
they should be articulated and examined.

RFC 5639 contains a lot of things, is there anything other than the OID
and PKIX usage you think is relevant for Curve25519?

/Simon

From nick.a.mathewson@gmail.com  Wed Sep 11 10:18:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA211E80D3 for ; Wed, 11 Sep 2013 10:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.059
X-Spam-Level: 
X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNYarIVW8jJB for ; Wed, 11 Sep 2013 10:18:14 -0700 (PDT)
Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [IPv6:2607:f8b0:400d:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9B51611E81EA for ; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id r5so5403021qcx.23 for ; Wed, 11 Sep 2013 10:17:34 -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:content-transfer-encoding; bh=v2PbisQoJia3DGskho6Kgl1k6rzvayUiBP7iH3fyJQw=; b=ECw/0InN4HCbzGPvNuzyn31RLZVRuMZAY1h1LRsGjnsZJIE05k4gjWDigJAdz9lGXB /jXuRUYOOCMl6f4ZQonEfqeQgKfJDVX578jsdMNFw4vvGYBjMDu/ez/PUeyTCnaXLDE2 NJkR09euXdSyhtjT9ZTpQhGkj9uSx4hVCe8pMPjKDWBq8F64ZrwiQq9K3IJtLTxk4D9r C0JSdAI3ySZXV/1j+pdjOWWnSybFgnkoVBxCa+34wrTKEwiCCOP3ysj0EQ+Yzd2xp1ZG q5DeEUelHu4zHEz2nLfuDar+TMMIWfuQGZRgXtPoUP6ELTUwSnu+SsvMSOUlkW35D0tD Ynww==
MIME-Version: 1.0
X-Received: by 10.229.127.74 with SMTP id f10mr5238195qcs.16.1378919854287; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.140.22.81 with HTTP; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
In-Reply-To: <20130911185329.3dcd75db@hboeck.de>
References:  <20130911185329.3dcd75db@hboeck.de>
Date: Wed, 11 Sep 2013 13:17:34 -0400
X-Google-Sender-Auth: Vf5XxFFFEukN4IA3X-dJBeyQs68
Message-ID: 
From: Nick Mathewson 
To: =?ISO-8859-1?Q?Hanno_B=F6ck?= 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 17:18:16 -0000

On Wed, Sep 11, 2013 at 12:53 PM, Hanno B=F6ck  wrote:
> On Wed, 11 Sep 2013 11:43:53 -0400
> Nick Mathewson  wrote:
>
>> Despite the late date, much of the world is still not
>> synchronized to the second via an ntp-like service. This means
>> that different clients have different views of the current time,
>> which provides a fingerprint that helps to track and distinguish
>> them.  This fingerprint is useful for tracking clients as they
>> move around.  It can also distinguish clients using a single VPN,
>> NAT, or privacy network.  (Tor's modified firefox avoids this by
>> not sending the time.)
>
> I can't help getting the feeling that you're trying to fix the wrong
> thing here. People use computers with a wrong clock. That's the problem
> here. You should try to fix that and not workaround it.

I respect your argument, and I used to think the same way myself.
Unfortunately, this doesn't seem to work so well in practice.

Consider that NTP has been around since before the web, and yet
typical consumer computers in the wild still have seconds to minutes
of clock skew.  Consider also that authenticated NTP is even less well
deployed than regular NTP, and that the possibility of
adversary-introduced clock skew reintroduces the fingerprinting
problem.

Also, consider that although fingerprinting issue is worst with large
skew, even less than a second of skew can be used to partition users:
If Alice's clock is only .1 second behind Bob's, a passive observer
can still conclude of 10% of Alice's TLS connections that they could
not have been sent by Bob, and of 10% of Bob's TLS connections that
they could not have been sent by Alice.  Over time, little
observations like this can add up to a lot of information for a clever
attacker.


Also, one could as easily argue that a broken PRNG is a problem that
needs to be fixed and not worked-around, and so gmt_unix_time should
not be supported. ;)

> My suggestion: Tor could detect on startup if the time is correct via
> ntp (or even through the tor network itself with the next server). If
> its not, it refuses to start unless an option like
> "iknowmytimeisbrokenandidontcare" is set. For the gui, issue a warning
> and an easy option to fix the time.

This idea has some merit, although we would need to find a workaround
for the fact that the initial TLS connection to the Tor network would
leak what time the client had thought it was until their anonymous NTP
requests had told them the real time.

In the short term, however, removing gmt_unix_time seems like a much
simpler fix: it can be done with a one-line patch to OpenSSL and/or
NSS, to improve the privacy of a great number of users, even those who
do not yet have an authenticated anonymized byzantine-fault-tolerant
NTP client.


yrs,
--=20
Nick

From mrex@sap.com  Wed Sep 11 10:41:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C543A21F9CBF; Wed, 11 Sep 2013 10:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6-D2htg+pBb; Wed, 11 Sep 2013 10:41:37 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2151621F9A59; Wed, 11 Sep 2013 10:41:36 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8BHfZO7023037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Sep 2013 19:41:35 +0200 (MEST)
In-Reply-To: 
To: Nick Mathewson 
Date: Wed, 11 Sep 2013 19:41:35 +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: <20130911174135.455A01A960@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 11 Sep 2013 17:41:43 -0000

Nick Mathewson wrote:
> ====
> SYNOPSIS:
> 
> In TLS as currently specified, clients and servers each send their
> current view of "the time" in the clear as part of their handshake.
> This provides a fingerprint that can track users in spite of other
> attempts to make them untrackable.  I propose several ways to stop
> doing sending this cleartext timestamp; some trivial and some more
> complex.

I would really appreciate a different approach to the underlying
issue, and less throwing of smoke grenades here.

If you're worried about being slightly "distinguishable" from some
other clients, then there are a lot more reliable identifiers available
in the average TLS handshake, so claiming that sending the actual local
time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting
issue and sending random will solve the fingerprinting issue, is
bordering on lame for >99% of the clients.

Most of the time, repeated requests of the same TLS client can be
identified by the network connection having the same client IP address,
the TLS session proposed for resumption in ClientHello.session_id
or maybe someone still using TLS session tickets (rfc5077).


So rather than pointing to ClientHello.Random.gmt_unix_time as a
and claiming there would be a simple fix, one will likely have to
create and go through a long list of issues to determine which
features facilitate fingerprinting and tracking (cipher suites
and many TLS extensions (TLS caching extension, signature algorithms,
Next protocol negotiation, supported elliptic curves, etc.) may
all help in distinguishing clients, and would also have to be
taken care of.


-Martin

From X.Wu@F5.com  Wed Sep 11 11:23:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465811E81F2; Wed, 11 Sep 2013 11:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cBwXX7tGCeG; Wed, 11 Sep 2013 11:23:36 -0700 (PDT)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 817DA11E81D2; Wed, 11 Sep 2013 11:23:36 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.90,885,1371081600"; d="scan'208,217";a="81622733"
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 11 Sep 2013 18:23:35 +0000
Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS03.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 11 Sep 2013 11:23:34 -0700
From: Xiaoyong Wu 
To: Ryan Hurst , Eric Rescorla 
Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS
Thread-Index: AQHOrwriSahGkkxdq02hAgcmqMDbYJnA2WdA
Date: Wed, 11 Sep 2013 18:23:33 +0000
Message-ID: 
References:    <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com>
In-Reply-To: <19AD06BF-648C-43F7-A076-A98CFA0E85C7@globalsign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.16.250]
Content-Type: multipart/alternative; boundary="_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_"
MIME-Version: 1.0
Cc: "perpass@ietf.org" , "tls@ietf.org" , Alfredo Pironti 
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 18:23:40 -0000

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

WWVzLCB3ZSBoYXZlIGJlZW4gdXNpbmcgcmFuZG9tIHZhbHVlcyBhbmQgaGF2ZSBub3QgZ290IGlu
dG8gYW55IGlzc3VlcyB3aXRoIGNsaWVudHMvc2VydmVycy4NCg0KLVhpYW95b25nDQoNCkZyb206
IHRscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBSeWFuIEh1cnN0DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAxMSwgMjAxMyA5
OjE5IEFNDQpUbzogRXJpYyBSZXNjb3JsYQ0KQ2M6IHBlcnBhc3NAaWV0Zi5vcmc7IHRsc0BpZXRm
Lm9yZzsgQWxmcmVkbyBQaXJvbnRpDQpTdWJqZWN0OiBSZTogW1RMU10gTGV0J3MgcmVtb3ZlIGdt
dF91bml4X3RpbWUgZnJvbSBUTFMNCg0KSSBoYXZlIGxvb2tlZCBhdCB0aGlzIHNvbWUsIG5ldHdv
cmsgYXBwbGlhbmNlcyBzdWNoIGFzIEY1cyBCaWcgSVAgdXNlIGEgcmFuZG9tIHZhbHVlIGluc3Rl
YWQgb2YgdGltZS4NCg0KSSByZWNhbGwgc2VlaW5nIHNvbWUgY2xpZW50cyBhbHNvIGRvIHRoaXMg
YnV0IEkgZG9uJ3QgcmVjYWxsIHdoaWNoIG9uZXMuDQoNCkJhc2ljYWxseSBzdWNoIGEgY2hhbmdl
IHNob3VsZCBiZSBzYWZlLg0KDQpUaGF0IHNhaWQgYXMgUnVzcyBoYXMgcG9pbnRlZCBvdXQgVFBT
REFURSB1c2VzIHRoaXMgbWVjaGFuaXNtIGFuZCB0aG91Z2ggaXQgZG9lc24ndCBzb2x2ZSBhIGJy
b2tlbiBjcnlwdG9ncmFwaGljIHN1YnN5c3RlbSBpdCBpcyBraW5kIG9mIGJlbHQgYW5kIHN1c3Bl
bmRlcnMgYXBwcm9hY2guDQoNClJ5YW4gSHVyc3QNCkNoaWVmIFRlY2hub2xvZ3kgT2ZmaWNlcg0K
R01PIEdsb2JhbHNpZ24NCg0KdHdpdHRlcjogQHJtaHJpc2sNCmVtYWlsOiByeWFuLmh1cnN0QGds
b2JhbHNpZ24uY29tPG1haWx0bzpyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tPg0KcGhvbmU6IDIw
Ni02NTAtNzkyNg0KDQpTZW50IGZyb20gbXkgcGhvbmUsIHBsZWFzZSBmb3JnaXZlIHRoZSBicmV2
aXR5Lg0KDQpPbiBTZXAgMTEsIDIwMTMsIGF0IDk6MDYgQU0sIEVyaWMgUmVzY29ybGEgPGVrckBy
dGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4gd3JvdGU6DQpCZWZvcmUgd2UgZGlzY3VzcyBt
ZWNoYW5pc21zLCBpdCB3b3VsZCBiZSBnb29kIHRvIHZlcmlmeSB0aGF0IGluIGdlbmVyYWwNCmNs
aWVudHMgYW5kIHNlcnZlcnMgZG9uJ3QgYmVjb21lIHVuaGFwcHkgaWYgdGhlIHRpbWVzdGFtcCBp
cyByYWRpY2FsbHkNCndyb25nLiBIYXMgc29tZW9uZSBkb25lIG1lYXN1cmVtZW50cyB0byB2ZXJp
ZnkgdGhhdCB0aGlzIGlzIGluIGZhY3QNCnRoZSBjYXNlIGF0IGEgYnJvYWQgc2NhbGU/DQoNCi1F
a3INCg0KDQpPbiBXZWQsIFNlcCAxMSwgMjAxMyBhdCA5OjAxIEFNLCBBbGZyZWRvIFBpcm9udGkg
PGFsZnJlZG9AcGlyb250aS5ldTxtYWlsdG86YWxmcmVkb0BwaXJvbnRpLmV1Pj4gd3JvdGU6DQpJ
J20gaW4gZmF2b3Igb2YgcHJvcG9zYWwgMSwgYW5kIHNlY29uZCB0aGUgY29uc2lkZXJhdGlvbnMg
YWJvdXQgaXQ7DQplc3NlbnRpYWxseSwgYSBicm9rZW4gY3J5cHRvIGltcGxlbWVudGF0aW9uIGNh
bm5vdCBiZSBmaXhlZCBieSBhDQp0aW1lc3RhbXAuDQoNCklmIHByb3Bvc2FsIDIgKGFuZCAzKSB3
YXMgdG8gYmUgaW1wbGVtZW50ZWQgb24gYSBzZXJ2ZXIsIGl0IHdvdWxkIGFsc28NCm1ha2UgRG9T
IGVhc2llciwgYmVjYXVzZSBhIGNoZWFwIENsaWVudEhlbGxvIChldmVuIGdlbmVyYXRlZCB3aXRo
IHdlYWsNCnJhbmRvbW5lc3MpIHdvdWxkIHRyaWdnZXIgYW4gZXh0cmEgSE1BQyBjb21wdXRhdGlv
biBvbiB0aGUgc2VydmVyLA0Kd2l0aCByZXNwZWN0IHRvIHRoZSBjdXJyZW50IHNlcnZlciBsb2Fk
Lg0KDQpIZW5jZSwgcmVseWluZyBvbiBQUk5HIG9uIGJvdGggY2xpZW50IGFuZCBzZXJ2ZXIgc2lk
ZXMgbG9va3MgbGlrZSBhDQpyZWFzb25hYmxlIHdheSB0byBnby4gSSBhbHNvIGRvbid0IHBhcnRp
Y3VsYXJseSBsaWtlIHRoZSBhc3ltbWV0cnkNCnRoYXQgcHJvcG9zYWwgMiBtYXkgYnJpbmc6IGNs
aWVudCBnZW5lcmF0aW5nIHJhbmRvbW5lc3Mgd2l0aCBITUFDLCBhbmQNCnNlcnZlcnMgc3RpbGwg
dXNpbmcgdGhlIHRpbWVzdGFtcCBpbiBjbGVhci4NCg0KQ2hlZXJzLA0KQWxmcmVkbw0KDQpPbiBX
ZWQsIFNlcCAxMSwgMjAxMyBhdCA1OjQzIFBNLCBOaWNrIE1hdGhld3NvbiA8bmlja21AdG9ycHJv
amVjdC5vcmc8bWFpbHRvOm5pY2ttQHRvcnByb2plY3Qub3JnPj4gd3JvdGU6DQo+IEhpLCBhbGwu
DQo+DQo+IEhlcmUncyBzb21ldGhpbmcgSSB3cm90ZSBhYm91dCByZW1vdmluZyBhIGZpbmdlcnBy
aW50aW5nIG9wcG9ydHVuaXR5DQo+IGZyb20gdGhlIGN1cnJlbnQgVExTIHByb3RvY29sLiAgSSB3
YXMgZ29pbmcgdG8ganVzdCBzZW5kIGl0IHRvIHRoZSB0bHMNCj4gbGlzdCwgYnV0IEJlbiBMYXVy
aWUgc3VnZ2VzdGVkIHRoYXQgSSBzZW5kIGl0IHRvIHRoZSBwZXJwYXNzIGxpc3QgYXMNCj4gd2Vs
bC4NCj4NCj4gSSBoYXZlIGxpdHRsZSBzdGFuZGFyZHMtYm9keSBleHBlcmllbmNlOyBpZiB0aGlz
IG91Z2h0IHRvIHR1cm4gaW50byBhbg0KPiBSRkMgb3Igc29tZXRoaW5nLCBJJ2QgYmUgaGFwcHkg
dG8gd3JpdGUgYSBkcmFmdCBpZiBuZWVkIGJlLg0KPg0KPg0KPiAoVG9yIGN1cnJlbnRseSBwbGFu
cyB0byBpbXBsZW1lbnQgdGhpcyBieSBwYXRjaGluZyBPcGVuU1NMOyBhbnkNCj4gZmVlZGJhY2sg
b3IgYWR2aWNlIHdvdWxkIGJlIGFwcHJlY2lhdGVkLiAgVGhlIGZpcnN0IHRocmVlIGFwcHJvYWNo
ZXMNCj4gYmVsb3cgYXJlIGltcGxlbWVudGVkIGluIE9wZW5TU0wgYnJhbmNoZXMgbmFtZWQgIm5v
X2NsaWVudF90aW1lc3RhbXAiLA0KPiAibm9fY2xpZW50X3RpbWVzdGFtcF92MiIgLCBhbmQgIm5v
X2NsaWVudF90aW1lc3RhbXBfdjMiIGluIHRoZSBnaXQNCj4gcmVwb3NpdG9yeSBhdCBodHRwczov
L2dpdGh1Yi5jb20vbm1hdGhld3Nvbi9vcGVuc3NsIC4gIFdlIGhhdmUgbG9uZw0KPiBzaGlwcGVk
IG91ciBwcml2YWN5LWVuaGFuY2VkIGJyb3dzZXIgd2l0aCBhIGZlYXR1cmUgbGlrZSB0aGlzIGVu
YWJsZWQNCj4gdGhyb3VnaCBhbiBOU1MgcGF0Y2guKQ0KPg0KPg0KPiA9PT09DQo+IFNZTk9QU0lT
Og0KPg0KPiBJbiBUTFMgYXMgY3VycmVudGx5IHNwZWNpZmllZCwgY2xpZW50cyBhbmQgc2VydmVy
cyBlYWNoIHNlbmQgdGhlaXINCj4gY3VycmVudCB2aWV3IG9mICJ0aGUgdGltZSIgaW4gdGhlIGNs
ZWFyIGFzIHBhcnQgb2YgdGhlaXIgaGFuZHNoYWtlLg0KPiBUaGlzIHByb3ZpZGVzIGEgZmluZ2Vy
cHJpbnQgdGhhdCBjYW4gdHJhY2sgdXNlcnMgaW4gc3BpdGUgb2Ygb3RoZXINCj4gYXR0ZW1wdHMg
dG8gbWFrZSB0aGVtIHVudHJhY2thYmxlLiAgSSBwcm9wb3NlIHNldmVyYWwgd2F5cyB0byBzdG9w
DQo+IGRvaW5nIHNlbmRpbmcgdGhpcyBjbGVhcnRleHQgdGltZXN0YW1wOyBzb21lIHRyaXZpYWwg
YW5kIHNvbWUgbW9yZQ0KPiBjb21wbGV4Lg0KPg0KPg0KPiBBQ0tOT1dMRURHRU1FTlRTOg0KPg0K
PiBUaGFua3MgdG8gQWRhbSBMYW5nbGV5LCBCZW4gTGF1cmllLCBhbmQgZXZlcnlib2R5IGVsc2Ug
d2hvIGdhdmUgbWUNCj4gZmVlZGJhY2sgaGVyZS4NCj4NCj4NCj4gUFJPQkxFTToNCj4NCj4gVGhl
IGdtdF91bml4X3RpbWUgZmllbGQgaW4gdGhlIFJhbmRvbSBmaWVsZCBpbiB0aGUgVExTIGhhbmRz
aGFrZQ0KPiBwcm92aWRlcyBhIHdheSBmb3IgYW4gb2JzZXJ2ZXIgdG8gZmluZ2VycHJpbnQgY2xp
ZW50cy4NCj4NCj4gRGVzcGl0ZSB0aGUgbGF0ZSBkYXRlLCBtdWNoIG9mIHRoZSB3b3JsZCBpcyBz
dGlsbCBub3QNCj4gc3luY2hyb25pemVkIHRvIHRoZSBzZWNvbmQgdmlhIGFuIG50cC1saWtlIHNl
cnZpY2UuIFRoaXMgbWVhbnMNCj4gdGhhdCBkaWZmZXJlbnQgY2xpZW50cyBoYXZlIGRpZmZlcmVu
dCB2aWV3cyBvZiB0aGUgY3VycmVudCB0aW1lLA0KPiB3aGljaCBwcm92aWRlcyBhIGZpbmdlcnBy
aW50IHRoYXQgaGVscHMgdG8gdHJhY2sgYW5kIGRpc3Rpbmd1aXNoDQo+IHRoZW0uICBUaGlzIGZp
bmdlcnByaW50IGlzIHVzZWZ1bCBmb3IgdHJhY2tpbmcgY2xpZW50cyBhcyB0aGV5DQo+IG1vdmUg
YXJvdW5kLiAgSXQgY2FuIGFsc28gZGlzdGluZ3Vpc2ggY2xpZW50cyB1c2luZyBhIHNpbmdsZSBW
UE4sDQo+IE5BVCwgb3IgcHJpdmFjeSBuZXR3b3JrLiAgKFRvcidzIG1vZGlmaWVkIGZpcmVmb3gg
YXZvaWRzIHRoaXMgYnkNCj4gbm90IHNlbmRpbmcgdGhlIHRpbWUuKQ0KPg0KPiBXb3JzZSwgc29t
ZSBpbXBsZW1lbnRhdGlvbnMgZG9uJ3Qgc2VuZCB0aGUgY3VycmVudCB0aW1lLCBidXQgdGhlDQo+
IHByb2Nlc3MgdGltZSwgb3IgdGhlIGNvbXB1dGVyJ3MgdXB0aW1lLCBib3RoIG9mIHdoaWNoIGFy
ZSBmYXINCj4gbW9yZSBkaXN0aW5ndWlzaGluZyB0aGFuIHRoZSBjdXJyZW50IHRpbWUoKSB2YWx1
ZS4NCj4NCj4gVGhlIGluZm9ybWF0aW9uIGZpbmdlcnByaW50IGhlcmUgaXMgc3Ryb25nIGVub3Vn
aCB0byB1bmlxdWVseQ0KPiBpZGVudGlmeSBzb21lIFRMUyB1c2VycyAodGhlIG9uZXMgd2hvc2Ug
Y2xvY2tzIGFyZSBob3VycyBvZmYpLg0KPiBFdmVuIGZvciB0aGUgb25lcyB3aG9zZSBjbG9ja3Mg
YXJlIG1vc3RseSByaWdodCAod2l0aGluIGEgc2Vjb25kDQo+IG9yIHR3byksIHRoZSBmaWVsZCBs
ZWFrcyBhIGJpdCBvZiBpbmZvcm1hdGlvbiwgYW5kIGl0IG9ubHkgdGFrZXMNCj4gc28gbWFueSBi
aXRzIHRvIG1ha2UgYSB1c2VyIHVuaXF1ZS4NCj4NCj4gT2YgY291cnNlLCBJIHJlYWxpemUgdGhh
dCB0aGUgZ210X3VuaXhfdGltZSBmaW5nZXJwcmludCBpcyBub3QgdGhlDQo+IG9ubHkgd2F5IHRv
IHRyYWNrIGEgdHlwaWNhbCBjbGllbnQgYXMgaXQgbW92ZXMgZnJvbSBuZXR3b3JrIHRvDQo+IG5l
dHdvcmssIGFuZCBub3QgdGhlIG9ubHkgd2F5IHRvIGRpc3Rpbmd1aXNoIGRpZmZlcmVudCBjbGll
bnRzDQo+IGJlaGluZCBhIE5BVC4NCj4NCj4NCj4NCj4gQkFDS0dST1VORDogV0hZIGdtdF91bml4
X3RpbWUgSU4gVEhFIEZJUlNUIFBMQUNFPw0KPg0KPiBBY2NvcmRpbmcgdG8gdGhpcmQtaGFuZCBy
ZXBvcnRzIChhbmQgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmchKQ0KPiBnbXRfdW5peF90aW1lIHdh
cyBpbnRyb2R1Y2VkIGluIFNTTCAzLjAgdG8gcHJldmVudCBjb21wbGV0ZSBmYWlsdXJlDQo+IGlu
IGNhc2VzIHdoZXJlIHRoZSBQUk5HIHdhcyBjb21wbGV0ZWx5IGJyb2tlbiwgYnkgbWFraW5nIGEg
cGFydCBvZg0KPiB0aGUgUmFuZG9tIGZpZWxkIHRoYXQgd291bGQgZGVmaW5pdGVseSB2YXJ5IGJl
dHdlZW4gVExTIGhhbmRzaGFrZXMuDQo+DQo+IEkgZG91YnQgdGhhdCB0aGlzIGdvYWwgaXMgcmVh
bGx5IGFjaGlldmVkLCBmb3IgdHdvIHJlYXNvbnM6DQo+DQo+ICAgICogT24gbW9kZXJuIGRlc2t0
b3AgZW52aXJvbm1lbnRzLCBpdCdzIG5vdCByZWFsbHkgc28gc3RyYW5nZSB0bw0KPiAgICAgIHN0
YXJ0IHR3byBvciBtb3JlIFRMUyBjb25uZWN0aW9ucyB3aXRoaW4gdGhlIHNhbWUgc2Vjb25kLiAg
V2hlbg0KPiAgICAgIHRoaXMgb2NjdXJzLCB0aGUgZ210X3VuaXhfdGltZSBmYWlscyBpbiBpdHMg
aW50ZW5kZWQgcHVycG9zZSBvZg0KPiAgICAgIHByZXZlbnRpbmcgcmVwZWF0ZWQgUmFuZG9tIHZh
bHVlcy4NCj4NCj4gICAgKiBOb253aXRoc3RhbmRpbmcgdGhlIGdtdF91bml4X3RpbWUgd29ya2Fy
b3VuZCwgVExTIGluIGdlbmVyYWwNCj4gICAgICBkb2VzIG5vdCB3aXRoc3RhbmQgYnJva2VuIFBS
TkdzLiAgRm9yIG9uZSBleGFtcGxlLCBpZiBhbg0KPiAgICAgIGltcGxlbWVudGF0aW9uJ3MgUFJO
RyBpcyBwcm9uZSB0byByZXBlYXRpbmcgQ2xpZW50UmFuZG9tDQo+ICAgICAgdmFsdWVzLCBpdCBp
cyBwcm9iYWJseSBwcm9uZSB0byByZXBlYXRpbmcgdGhvc2Ugc29tZSB2YWx1ZXMgYXMNCj4gICAg
ICBlcGhlbWVyYWwgRGlmZmllLUhlbGxtYW4gcHJpdmF0ZSB2YWx1ZXMuDQo+DQo+IE5ldmVydGhl
bGVzcywgaWYgdGhlIGdvYWwgb2YgcHJvdmlkaW5nIHVuaXF1ZS1sb29raW5nIG91dHB1dA0KPg0K
Pg0KPg0KPiBXSFkgRUxTRSBJUyBnbXRfdW5peF90aW1lIFVTRUQ/DQo+DQo+IFRoZSBjb25zZW5z
dXMgYW1vbmcgaW1wbGVtZW50b3JzIEkndmUgYXNrZWQgc2VlbXMgdG8gYmUgdGhhdCBpdCdzDQo+
IHVud2lzZSB0byBkZXBlbmQgb24gYW55IHBhcnRpY3VsYXIgdmFsdWUgb3IgaW50ZXJwcmV0YXRp
b24gZm9yIHRoZQ0KPiBmaWVsZC4gIFRoZSBUTFMgMS4yIHN0YW5kYXJkLCBSRkMgNTI0Niwgc2F5
cyB0aGF0ICJDbG9ja3MgYXJlIG5vdA0KPiByZXF1aXJlZCB0byBiZSBzZXQgY29ycmVjdGx5IGJ5
IHRoZSBiYXNpYyBUTFMgcHJvdG9jb2w7IGhpZ2hlci1sZXZlbA0KPiBvciBhcHBsaWNhdGlvbiBw
cm90b2NvbHMgbWF5IGRlZmluZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cy4iDQo+DQo+IFNvbWUg
aW1wbGVtZW50YXRpb25zIHNldCB0aGUgZW50aXJlIGdtdF91bml4X3RpbWUgZmllbGQgcmFuZG9t
bHk7DQo+IHRoaXMgYXBwZWFycyBub3QgdG8gaGF2ZSBicm9rZW4gVExTIG9uIHRoZSBpbnRlcm5l
dC4NCj4NCj4gQXQgbGVhc3Qgb25lIHRvb2wgKHRsc2RhdGUpIHVzZXMgdGhlIHNlcnZlci1zaWRl
IHZhbHVlIG9mIHRoZQ0KPiBmaWVsZCBhcyBhbiBhdXRoZW50aWNhdGVkIHZpZXcgb2YgdGhlIGN1
cnJlbnQgdGltZS4NCj4NCj4NCj4NCj4gUFJPUE9TQUwgMToNCj4NCj4gRGVjbGFyZSB0aGF0IGlt
cGxlbWVudGF0aW9ucyBNQVkgcmVwbGFjZSBnbXRfdW5peF90aW1lIGVpdGhlciB3aXRoDQo+IGZv
dXIgbW9yZSByYW5kb20gYnl0ZXMsIG9yIGZvdXIgYnl0ZXMgb2YgemVyb2VzLg0KPg0KPiBSYXRp
b25hbGU6DQo+ICAgICogU29tZSBpbXBsZW1lbnRhdGlvbnMgKGxpa2UgVG9yQnJvd3NlcikgYXJl
IGFscmVhZHkgZG9pbmcgdGhpcw0KPiAgICAgIGluIHByYWN0aWNlLg0KPg0KPiAgICAqIEl0J3Mg
c2Vuc2libGUgYW5kIHNpbXBsZS4gIEltcGxlbWVudG9ycyBhcmUgcXVpdGUgdW5saWtlbHkgdG8N
Cj4gICAgICBtZXNzIGl0IHVwLg0KPg0KPg0KPg0KPiBQUk9QT1NBTCAyOg0KPg0KPiBTdXBwb3Nl
IHRoYXQgd2UgZG8gbm90IGFjY2VwdCB0aGUgYXJndW1lbnQgYWJvdXQgdGhlIHBvaW50bGVzc25l
c3MNCj4gb2YgZ210X3VuaXRfdGltZSB0aGF0IEkgbWFrZSBhYm92ZSwgYW5kIHdlIHdhbnQgdG8g
cHJlc2VydmUgdGhlDQo+IHNlY3VyaXR5IGl0IGFsbGVnZWRseSBwcm92aWRlcy4NCj4NCj4gSW4g
dGhhdCBjYXNlLCB3ZSBjYW4gYWxsb3cgdGhlIGZvbGxvd2luZyBhcHByb2FjaCBpbnN0ZWFkOg0K
Pg0KPiBTZXQgdGhlIFJhbmRvbSBmaWVsZCwgbm90IHRvIDMyIGJ5dGVzIGZyb20geW91ciBQUk5H
LCBidXQgdG8gdGhlDQo+IEhNQUMtU0hBMjU2IG9mIGFueSBoaWdoIHJlc29sdXRpb24gdGltZXIg
dGhhdCB5b3UgaGF2ZSwgdXNpbmcgMzINCj4gYnl0ZXMgZnJvbSB5b3VyIFBSTkcgYXMgYSBrZXku
ICBJbiBvdGhlciB3b3JkcywgcmVwbGFjZSB0aGlzOg0KPg0KPiAgICBSYW5kb20uZ210X3VuaXhf
dGltZSA9IHRpbWUoKTsNCj4gICAgUmFuZG9tLnJhbmRvbV9ieXRlcyA9IGdldF9yYW5kb21fYnl0
ZXMoMjgpDQo+DQo+IHdpdGggdGhpczoNCj4NCj4gICAgbm93ID0gaGlyZXNfdGltZSgpOyAvLyBj
bG9ja19nZXR0aW1lKCksIG9yIGNvbmNhdGVuYXRlIHRpbWUoKQ0KPiAgICAgICAgICAgICAgICAg
ICAgICAgIC8vIHdpdGggYSBDUFUgdGltZXIsIG9yIHByb2Nlc3MNCj4gICAgICAgICAgICAgICAg
ICAgICAgICAvLyB1cHRpbWUsIG9yIHdoYXRldmVyLg0KPiAgICBrZXkgPSBnZXRfcmFuZG9tX2J5
dGVzKDMyKTsNCj4gICAgUmFuZG9tID0gaG1hY19zaGEyNTYoa2V5LCBub3cpOw0KPg0KPiBUaGlz
IGFwcHJvYWNoIGlzIGJldHRlciB0aGFuIHRoZSBzdGF0dXMgcXVvIG9uIHRoZSBmb2xsb3dpbmcN
Cj4gY291bnRzOg0KPg0KPiAgICAqIEl0IGRvZXNuJ3QgbGVhayB5b3VyIHZpZXcgb2YgdGhlIGN1
cnJlbnQgdGltZSwgYXNzdW1pbmcgdGhhdA0KPiAgICAgIHlvdXIgUFJORyBpc24ndCBidXN0ZWQu
DQo+DQo+ICAgICogSXQgYWN0dWFsbHkgZml4ZXMgdGhlIHByb2JsZW0gdGhhdCBnbXRfdW5peF90
aW1lIHB1cnBvcnRlZCB0bw0KPiAgICAgIGZpeCwgYnkgdXNpbmcgYSBoaWdoLXJlc29sdXRpb24g
dGltZSB0aGF0J3MgbXVjaCBsZXNzIGxpa2VseSB0bw0KPiAgICAgIGJlIHVzZWQgdHdpY2UuICBF
dmVuIGlmIHRoZSBQUk5HIGlzIGJyb2tlbiwgdGhlIHZhbHVlIGlzIHN0aWxsDQo+ICAgICAgbm9u
cmVwZWF0aW5nLg0KPg0KPiBJIGRvIG5vdCB0aGluayB0aGlzIGlzIG5vdCB3b3JzZSB0aGFuIHRo
ZSBzdGF0dXMgcXVvOg0KPg0KPiAgICAqIEl0IGlzIHVucHJlZGljdGFibGUgZnJvbSBhbiBhdHRh
Y2tlcidzIFBPViwgYXNzdW1pbmcgdGhhdCB0aGUNCj4gICAgICBQUk5HIHdvcmtzLiAgKEJlY2F1
c2UgYW4gSE1BQywgZXZlbiBvZiBrbm93biBkYXRhLCB3aXRoIGFuDQo+ICAgICAgdW5rbm93biBy
YW5kb20ga2V5IGlzIHN1cHBvc2VkIHRvIGxvb2sgcmFuZG9tKS4NCj4NCj4NCj4gUFJPUE9TQUwg
Mw0KPg0KPiBBcyBhIGh5YnJpZCBhbHRlcm5hdGl2ZSwgb25lIGNvdWxkIHNldCBwYXJ0IG9mIHRo
ZSBDbGllbnRSYW5kb20NCj4gZmllbGQgKHBlcmhhcHMgMTIgYnl0ZXMgb3Igc28pIGJhc2VkIG9u
IHRoZSBITUFDIG9mIHRoZSB0aW1lLCBhbmQNCj4gdGhlIHJlc3Qgb2YgdGhlIENsaWVudFJhbmRv
bSBmaWVsZCBiYXNlZCBvbiB0aGUgUFJORzoNCj4NCj4gICAgTiA9IDEyDQo+DQo+ICAgIG5vdyA9
IGhpcmVzX3RpbWUoKTsNCj4gICAga2V5ID0gZ2V0X3JhbmRvbV9ieXRlcygzMik7DQo+ICAgIG1h
YyA9IGhtYWNfc2hhMjU2KGtleSwgbm93KVswOk5dOyAgLy8gRmlyc3QgTiBieXRlcy4NCj4gICAg
cmFuZCA9IGdldF9yYW5kb21fYnl0ZXMoMzIgLSBOKQ0KPiAgICBSYW5kb20gPSBtYWMgKysgcmFu
ZCAgICAgICAgICAgICAgIC8vIGNvbmNhdGVuYXRlLg0KPg0KPiBCdXQgdGhpcyBzZWVtcyB0byBi
ZSBnZXR0aW5nIHBvaW50bGVzc2x5IGJhcm9xdWUuDQo+DQo+DQo+DQo+IENPTlNJREVSQVRJT05T
Og0KPg0KPiBJJ2QgcGVyc29uYWxseSBzdWdnZXN0IHByb3Bvc2FsIDEgKGp1c3Qgc2V0IHRoZSBm
aWVsZCBhdCByYW5kb20pIGZvcg0KPiBtb3N0IHVzZXJzLiAgWWVzLCBpdCBtYWtlcyB0aGluZ3Mg
YSBsaXR0bGUgd29yc2UgaWYgeW91ciBQUk5HIGNhbg0KPiBnZW5lcmF0ZSByZXBlYXQgdmFsdWVz
Li4uIGJ1dCBuZWFybHkgZXZlcnl0aGluZyBpbiBjcnlwdG9ncmFwaHkNCj4gZmFpbHMgaWYgeW91
ciBQUk5HIGlzIGJyb2tlbi4NCj4NCj4NCj4gV2UgbWlnaHQgd2FudCB0byBhcHBseSB0aGlzIGZp
eCBvbiBjbGllbnRzIG9ubHkuICBXaXRoIGEgZmV3DQo+IGV4Y2VwdGlvbnMgKGxpa2UgaGlkZGVu
IHNlcnZpY2VzKSB0aGUgc2VydmVyJ3MgdmlldyBvZiB0aGUgY3VycmVudA0KPiB0aW1lIGlzIG5v
dCBzZW5zaXRpdmUuDQo+DQo+DQo+IEltcGxlbWVudG9ycyBtaWdodCB3YW50IHRvIG1ha2UgdGhp
cyBmZWF0dXJlIG9wdGlvbmFsIGFuZA0KPiBvbi1ieS1kZWZhdWx0LCBqdXN0IGluIGNhc2Ugc29t
ZSBoaWdoZXItbGV2ZWwgYXBwbGljYXRpb24gcHJvdG9jb2wNCj4gcmVhbGx5IGRvZXMgZGVwZW5k
IG9uIGl0Lg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3Jn
Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QN
ClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90bHMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExT
QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg==

--_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ
e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov
KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z
b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp
emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps
aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I
eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl
Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv
LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10
eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x
DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9
DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt
LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk
bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+
DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0
YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi
b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9
IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCB3ZSBoYXZlIGJlZW4gdXNpbmcgcmFuZG9tIHZh
bHVlcyBhbmQgaGF2ZSBub3QgZ290IGludG8gYW55IGlzc3VlcyB3aXRoIGNsaWVudHMvc2VydmVy
cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv
bG9yOiMxRjQ5N0QiPi1YaWFveW9uZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiB0bHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYu
b3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5SeWFuIEh1cnN0PGJyPg0KPGI+U2VudDo8L2I+IFdl
ZG5lc2RheSwgU2VwdGVtYmVyIDExLCAyMDEzIDk6MTkgQU08YnI+DQo8Yj5Ubzo8L2I+IEVyaWMg
UmVzY29ybGE8YnI+DQo8Yj5DYzo8L2I+IHBlcnBhc3NAaWV0Zi5vcmc7IHRsc0BpZXRmLm9yZzsg
QWxmcmVkbyBQaXJvbnRpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBMZXQncyByZW1v
dmUgZ210X3VuaXhfdGltZSBmcm9tIFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIGxvb2tlZCBhdCB0aGlzIHNvbWUs
IG5ldHdvcmsgYXBwbGlhbmNlcyBzdWNoIGFzIEY1cyBCaWcgSVAgdXNlIGEgcmFuZG9tIHZhbHVl
IGluc3RlYWQgb2YgdGltZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+SSByZWNhbGwgc2VlaW5nIHNvbWUgY2xpZW50cyBhbHNvIGRvIHRoaXMg
YnV0IEkgZG9uJ3QgcmVjYWxsIHdoaWNoIG9uZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhc2ljYWxseSBzdWNoIGEgY2hhbmdlIHNob3Vs
ZCBiZSBzYWZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5UaGF0IHNhaWQgYXMgUnVzcyBoYXMgcG9pbnRlZCBvdXQgVFBTREFURSB1c2VzIHRo
aXMgbWVjaGFuaXNtIGFuZCB0aG91Z2ggaXQgZG9lc24ndCBzb2x2ZSBhIGJyb2tlbiBjcnlwdG9n
cmFwaGljIHN1YnN5c3RlbSBpdCBpcyBraW5kIG9mIGJlbHQgYW5kIHN1c3BlbmRlcnMgYXBwcm9h
Y2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClJ5
YW4gSHVyc3Q8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+Q2hpZWYgVGVjaG5vbG9neSBPZmZpY2VyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HTU8gR2xvYmFsc2lnbjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50d2l0dGVyOiBAcm1ocmlzazxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZW1haWw6IDxh
IGhyZWY9Im1haWx0bzpyeWFuLmh1cnN0QGdsb2JhbHNpZ24uY29tIj5yeWFuLmh1cnN0QGdsb2Jh
bHNpZ24uY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+cGhvbmU6IDIwNi02NTAtNzkyNjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZW50IGZyb20gbXkgcGhvbmUsIHBsZWFzZSBmb3Jn
aXZlIHRoZSBicmV2aXR5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+
PGJyPg0KT24gU2VwIDExLCAyMDEzLCBhdCA5OjA2IEFNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBo
cmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7
bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PkJlZm9yZSB3ZSBkaXNjdXNzIG1lY2hhbmlzbXMsIGl0IHdvdWxkIGJlIGdvb2QgdG8gdmVyaWZ5
IHRoYXQgaW4gZ2VuZXJhbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPmNsaWVudHMgYW5kIHNlcnZlcnMgZG9uJ3QgYmVjb21lIHVuaGFwcHkgaWYgdGhlIHRpbWVz
dGFtcCBpcyByYWRpY2FsbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPndyb25nLiBIYXMgc29tZW9uZSBkb25lIG1lYXN1cmVtZW50cyB0byB2ZXJp
ZnkgdGhhdCB0aGlzIGlzIGluIGZhY3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBjYXNlIGF0IGEgYnJvYWQgc2NhbGU/PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgU2VwIDExLCAyMDEzIGF0IDk6MDEgQU0sIEFsZnJl
ZG8gUGlyb250aSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZnJlZG9AcGlyb250aS5ldSIgdGFyZ2V0
PSJfYmxhbmsiPmFsZnJlZG9AcGlyb250aS5ldTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGluIGZhdm9yIG9mIHByb3Bvc2FsIDEsIGFuZCBz
ZWNvbmQgdGhlIGNvbnNpZGVyYXRpb25zIGFib3V0IGl0Ozxicj4NCmVzc2VudGlhbGx5LCBhIGJy
b2tlbiBjcnlwdG8gaW1wbGVtZW50YXRpb24gY2Fubm90IGJlIGZpeGVkIGJ5IGE8YnI+DQp0aW1l
c3RhbXAuPGJyPg0KPGJyPg0KSWYgcHJvcG9zYWwgMiAoYW5kIDMpIHdhcyB0byBiZSBpbXBsZW1l
bnRlZCBvbiBhIHNlcnZlciwgaXQgd291bGQgYWxzbzxicj4NCm1ha2UgRG9TIGVhc2llciwgYmVj
YXVzZSBhIGNoZWFwIENsaWVudEhlbGxvIChldmVuIGdlbmVyYXRlZCB3aXRoIHdlYWs8YnI+DQpy
YW5kb21uZXNzKSB3b3VsZCB0cmlnZ2VyIGFuIGV4dHJhIEhNQUMgY29tcHV0YXRpb24gb24gdGhl
IHNlcnZlciw8YnI+DQp3aXRoIHJlc3BlY3QgdG8gdGhlIGN1cnJlbnQgc2VydmVyIGxvYWQuPGJy
Pg0KPGJyPg0KSGVuY2UsIHJlbHlpbmcgb24gUFJORyBvbiBib3RoIGNsaWVudCBhbmQgc2VydmVy
IHNpZGVzIGxvb2tzIGxpa2UgYTxicj4NCnJlYXNvbmFibGUgd2F5IHRvIGdvLiBJIGFsc28gZG9u
J3QgcGFydGljdWxhcmx5IGxpa2UgdGhlIGFzeW1tZXRyeTxicj4NCnRoYXQgcHJvcG9zYWwgMiBt
YXkgYnJpbmc6IGNsaWVudCBnZW5lcmF0aW5nIHJhbmRvbW5lc3Mgd2l0aCBITUFDLCBhbmQ8YnI+
DQpzZXJ2ZXJzIHN0aWxsIHVzaW5nIHRoZSB0aW1lc3RhbXAgaW4gY2xlYXIuPGJyPg0KPGJyPg0K
Q2hlZXJzLDxicj4NCkFsZnJlZG88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KT24gV2VkLCBTZXAgMTEsIDIwMTMgYXQgNTo0MyBQTSwgTmlj
ayBNYXRoZXdzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrbUB0b3Jwcm9qZWN0Lm9yZyI+bmlj
a21AdG9ycHJvamVjdC5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEhpLCBhbGwuPGJyPg0K
Jmd0Ozxicj4NCiZndDsgSGVyZSdzIHNvbWV0aGluZyBJIHdyb3RlIGFib3V0IHJlbW92aW5nIGEg
ZmluZ2VycHJpbnRpbmcgb3Bwb3J0dW5pdHk8YnI+DQomZ3Q7IGZyb20gdGhlIGN1cnJlbnQgVExT
IHByb3RvY29sLiAmbmJzcDtJIHdhcyBnb2luZyB0byBqdXN0IHNlbmQgaXQgdG8gdGhlIHRsczxi
cj4NCiZndDsgbGlzdCwgYnV0IEJlbiBMYXVyaWUgc3VnZ2VzdGVkIHRoYXQgSSBzZW5kIGl0IHRv
IHRoZSBwZXJwYXNzIGxpc3QgYXM8YnI+DQomZ3Q7IHdlbGwuPGJyPg0KJmd0Ozxicj4NCiZndDsg
SSBoYXZlIGxpdHRsZSBzdGFuZGFyZHMtYm9keSBleHBlcmllbmNlOyBpZiB0aGlzIG91Z2h0IHRv
IHR1cm4gaW50byBhbjxicj4NCiZndDsgUkZDIG9yIHNvbWV0aGluZywgSSdkIGJlIGhhcHB5IHRv
IHdyaXRlIGEgZHJhZnQgaWYgbmVlZCBiZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg
KFRvciBjdXJyZW50bHkgcGxhbnMgdG8gaW1wbGVtZW50IHRoaXMgYnkgcGF0Y2hpbmcgT3BlblNT
TDsgYW55PGJyPg0KJmd0OyBmZWVkYmFjayBvciBhZHZpY2Ugd291bGQgYmUgYXBwcmVjaWF0ZWQu
ICZuYnNwO1RoZSBmaXJzdCB0aHJlZSBhcHByb2FjaGVzPGJyPg0KJmd0OyBiZWxvdyBhcmUgaW1w
bGVtZW50ZWQgaW4gT3BlblNTTCBicmFuY2hlcyBuYW1lZCAmcXVvdDtub19jbGllbnRfdGltZXN0
YW1wJnF1b3Q7LDxicj4NCiZndDsgJnF1b3Q7bm9fY2xpZW50X3RpbWVzdGFtcF92MiZxdW90OyAs
IGFuZCAmcXVvdDtub19jbGllbnRfdGltZXN0YW1wX3YzJnF1b3Q7IGluIHRoZSBnaXQ8YnI+DQom
Z3Q7IHJlcG9zaXRvcnkgYXQgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25tYXRoZXdzb24v
b3BlbnNzbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9ubWF0aGV3c29uL29w
ZW5zc2w8L2E+IC4gJm5ic3A7V2UgaGF2ZSBsb25nPGJyPg0KJmd0OyBzaGlwcGVkIG91ciBwcml2
YWN5LWVuaGFuY2VkIGJyb3dzZXIgd2l0aCBhIGZlYXR1cmUgbGlrZSB0aGlzIGVuYWJsZWQ8YnI+
DQomZ3Q7IHRocm91Z2ggYW4gTlNTIHBhdGNoLik8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn
dDsgPT09PTxicj4NCiZndDsgU1lOT1BTSVM6PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gVExTIGFz
IGN1cnJlbnRseSBzcGVjaWZpZWQsIGNsaWVudHMgYW5kIHNlcnZlcnMgZWFjaCBzZW5kIHRoZWly
PGJyPg0KJmd0OyBjdXJyZW50IHZpZXcgb2YgJnF1b3Q7dGhlIHRpbWUmcXVvdDsgaW4gdGhlIGNs
ZWFyIGFzIHBhcnQgb2YgdGhlaXIgaGFuZHNoYWtlLjxicj4NCiZndDsgVGhpcyBwcm92aWRlcyBh
IGZpbmdlcnByaW50IHRoYXQgY2FuIHRyYWNrIHVzZXJzIGluIHNwaXRlIG9mIG90aGVyPGJyPg0K
Jmd0OyBhdHRlbXB0cyB0byBtYWtlIHRoZW0gdW50cmFja2FibGUuICZuYnNwO0kgcHJvcG9zZSBz
ZXZlcmFsIHdheXMgdG8gc3RvcDxicj4NCiZndDsgZG9pbmcgc2VuZGluZyB0aGlzIGNsZWFydGV4
dCB0aW1lc3RhbXA7IHNvbWUgdHJpdmlhbCBhbmQgc29tZSBtb3JlPGJyPg0KJmd0OyBjb21wbGV4
Ljxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBQ0tOT1dMRURHRU1FTlRTOjxicj4NCiZn
dDs8YnI+DQomZ3Q7IFRoYW5rcyB0byBBZGFtIExhbmdsZXksIEJlbiBMYXVyaWUsIGFuZCBldmVy
eWJvZHkgZWxzZSB3aG8gZ2F2ZSBtZTxicj4NCiZndDsgZmVlZGJhY2sgaGVyZS48YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDsgUFJPQkxFTTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZ210
X3VuaXhfdGltZSBmaWVsZCBpbiB0aGUgUmFuZG9tIGZpZWxkIGluIHRoZSBUTFMgaGFuZHNoYWtl
PGJyPg0KJmd0OyBwcm92aWRlcyBhIHdheSBmb3IgYW4gb2JzZXJ2ZXIgdG8gZmluZ2VycHJpbnQg
Y2xpZW50cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBEZXNwaXRlIHRoZSBsYXRlIGRhdGUsIG11Y2gg
b2YgdGhlIHdvcmxkIGlzIHN0aWxsIG5vdDxicj4NCiZndDsgc3luY2hyb25pemVkIHRvIHRoZSBz
ZWNvbmQgdmlhIGFuIG50cC1saWtlIHNlcnZpY2UuIFRoaXMgbWVhbnM8YnI+DQomZ3Q7IHRoYXQg
ZGlmZmVyZW50IGNsaWVudHMgaGF2ZSBkaWZmZXJlbnQgdmlld3Mgb2YgdGhlIGN1cnJlbnQgdGlt
ZSw8YnI+DQomZ3Q7IHdoaWNoIHByb3ZpZGVzIGEgZmluZ2VycHJpbnQgdGhhdCBoZWxwcyB0byB0
cmFjayBhbmQgZGlzdGluZ3Vpc2g8YnI+DQomZ3Q7IHRoZW0uICZuYnNwO1RoaXMgZmluZ2VycHJp
bnQgaXMgdXNlZnVsIGZvciB0cmFja2luZyBjbGllbnRzIGFzIHRoZXk8YnI+DQomZ3Q7IG1vdmUg
YXJvdW5kLiAmbmJzcDtJdCBjYW4gYWxzbyBkaXN0aW5ndWlzaCBjbGllbnRzIHVzaW5nIGEgc2lu
Z2xlIFZQTiw8YnI+DQomZ3Q7IE5BVCwgb3IgcHJpdmFjeSBuZXR3b3JrLiAmbmJzcDsoVG9yJ3Mg
bW9kaWZpZWQgZmlyZWZveCBhdm9pZHMgdGhpcyBieTxicj4NCiZndDsgbm90IHNlbmRpbmcgdGhl
IHRpbWUuKTxicj4NCiZndDs8YnI+DQomZ3Q7IFdvcnNlLCBzb21lIGltcGxlbWVudGF0aW9ucyBk
b24ndCBzZW5kIHRoZSBjdXJyZW50IHRpbWUsIGJ1dCB0aGU8YnI+DQomZ3Q7IHByb2Nlc3MgdGlt
ZSwgb3IgdGhlIGNvbXB1dGVyJ3MgdXB0aW1lLCBib3RoIG9mIHdoaWNoIGFyZSBmYXI8YnI+DQom
Z3Q7IG1vcmUgZGlzdGluZ3Vpc2hpbmcgdGhhbiB0aGUgY3VycmVudCB0aW1lKCkgdmFsdWUuPGJy
Pg0KJmd0Ozxicj4NCiZndDsgVGhlIGluZm9ybWF0aW9uIGZpbmdlcnByaW50IGhlcmUgaXMgc3Ry
b25nIGVub3VnaCB0byB1bmlxdWVseTxicj4NCiZndDsgaWRlbnRpZnkgc29tZSBUTFMgdXNlcnMg
KHRoZSBvbmVzIHdob3NlIGNsb2NrcyBhcmUgaG91cnMgb2ZmKS48YnI+DQomZ3Q7IEV2ZW4gZm9y
IHRoZSBvbmVzIHdob3NlIGNsb2NrcyBhcmUgbW9zdGx5IHJpZ2h0ICh3aXRoaW4gYSBzZWNvbmQ8
YnI+DQomZ3Q7IG9yIHR3byksIHRoZSBmaWVsZCBsZWFrcyBhIGJpdCBvZiBpbmZvcm1hdGlvbiwg
YW5kIGl0IG9ubHkgdGFrZXM8YnI+DQomZ3Q7IHNvIG1hbnkgYml0cyB0byBtYWtlIGEgdXNlciB1
bmlxdWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgT2YgY291cnNlLCBJIHJlYWxpemUgdGhhdCB0aGUg
Z210X3VuaXhfdGltZSBmaW5nZXJwcmludCBpcyBub3QgdGhlPGJyPg0KJmd0OyBvbmx5IHdheSB0
byB0cmFjayBhIHR5cGljYWwgY2xpZW50IGFzIGl0IG1vdmVzIGZyb20gbmV0d29yayB0bzxicj4N
CiZndDsgbmV0d29yaywgYW5kIG5vdCB0aGUgb25seSB3YXkgdG8gZGlzdGluZ3Vpc2ggZGlmZmVy
ZW50IGNsaWVudHM8YnI+DQomZ3Q7IGJlaGluZCBhIE5BVC48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDs8YnI+DQomZ3Q7IEJBQ0tHUk9VTkQ6IFdIWSBnbXRfdW5peF90aW1lIElOIFRIRSBG
SVJTVCBQTEFDRT88YnI+DQomZ3Q7PGJyPg0KJmd0OyBBY2NvcmRpbmcgdG8gdGhpcmQtaGFuZCBy
ZXBvcnRzIChhbmQgY29ycmVjdCBtZSBpZiBJJ20gd3JvbmchKTxicj4NCiZndDsgZ210X3VuaXhf
dGltZSB3YXMgaW50cm9kdWNlZCBpbiBTU0wgMy4wIHRvIHByZXZlbnQgY29tcGxldGUgZmFpbHVy
ZTxicj4NCiZndDsgaW4gY2FzZXMgd2hlcmUgdGhlIFBSTkcgd2FzIGNvbXBsZXRlbHkgYnJva2Vu
LCBieSBtYWtpbmcgYSBwYXJ0IG9mPGJyPg0KJmd0OyB0aGUgUmFuZG9tIGZpZWxkIHRoYXQgd291
bGQgZGVmaW5pdGVseSB2YXJ5IGJldHdlZW4gVExTIGhhbmRzaGFrZXMuPGJyPg0KJmd0Ozxicj4N
CiZndDsgSSBkb3VidCB0aGF0IHRoaXMgZ29hbCBpcyByZWFsbHkgYWNoaWV2ZWQsIGZvciB0d28g
cmVhc29uczo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7KiBPbiBtb2Rlcm4gZGVz
a3RvcCBlbnZpcm9ubWVudHMsIGl0J3Mgbm90IHJlYWxseSBzbyBzdHJhbmdlIHRvPGJyPg0KJmd0
OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0YXJ0IHR3byBvciBtb3JlIFRMUyBjb25uZWN0aW9ucyB3
aXRoaW4gdGhlIHNhbWUgc2Vjb25kLiAmbmJzcDtXaGVuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
ICZuYnNwO3RoaXMgb2NjdXJzLCB0aGUgZ210X3VuaXhfdGltZSBmYWlscyBpbiBpdHMgaW50ZW5k
ZWQgcHVycG9zZSBvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtwcmV2ZW50aW5nIHJl
cGVhdGVkIFJhbmRvbSB2YWx1ZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyog
Tm9ud2l0aHN0YW5kaW5nIHRoZSBnbXRfdW5peF90aW1lIHdvcmthcm91bmQsIFRMUyBpbiBnZW5l
cmFsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RvZXMgbm90IHdpdGhzdGFuZCBicm9r
ZW4gUFJOR3MuICZuYnNwO0ZvciBvbmUgZXhhbXBsZSwgaWYgYW48YnI+DQomZ3Q7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7aW1wbGVtZW50YXRpb24ncyBQUk5HIGlzIHByb25lIHRvIHJlcGVhdGluZyBD
bGllbnRSYW5kb208YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dmFsdWVzLCBpdCBpcyBw
cm9iYWJseSBwcm9uZSB0byByZXBlYXRpbmcgdGhvc2Ugc29tZSB2YWx1ZXMgYXM8YnI+DQomZ3Q7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZXBoZW1lcmFsIERpZmZpZS1IZWxsbWFuIHByaXZhdGUgdmFs
dWVzLjxicj4NCiZndDs8YnI+DQomZ3Q7IE5ldmVydGhlbGVzcywgaWYgdGhlIGdvYWwgb2YgcHJv
dmlkaW5nIHVuaXF1ZS1sb29raW5nIG91dHB1dDxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0
Ozxicj4NCiZndDsgV0hZIEVMU0UgSVMgZ210X3VuaXhfdGltZSBVU0VEPzxicj4NCiZndDs8YnI+
DQomZ3Q7IFRoZSBjb25zZW5zdXMgYW1vbmcgaW1wbGVtZW50b3JzIEkndmUgYXNrZWQgc2VlbXMg
dG8gYmUgdGhhdCBpdCdzPGJyPg0KJmd0OyB1bndpc2UgdG8gZGVwZW5kIG9uIGFueSBwYXJ0aWN1
bGFyIHZhbHVlIG9yIGludGVycHJldGF0aW9uIGZvciB0aGU8YnI+DQomZ3Q7IGZpZWxkLiAmbmJz
cDtUaGUgVExTIDEuMiBzdGFuZGFyZCwgUkZDIDUyNDYsIHNheXMgdGhhdCAmcXVvdDtDbG9ja3Mg
YXJlIG5vdDxicj4NCiZndDsgcmVxdWlyZWQgdG8gYmUgc2V0IGNvcnJlY3RseSBieSB0aGUgYmFz
aWMgVExTIHByb3RvY29sOyBoaWdoZXItbGV2ZWw8YnI+DQomZ3Q7IG9yIGFwcGxpY2F0aW9uIHBy
b3RvY29scyBtYXkgZGVmaW5lIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzLiZxdW90Ozxicj4NCiZn
dDs8YnI+DQomZ3Q7IFNvbWUgaW1wbGVtZW50YXRpb25zIHNldCB0aGUgZW50aXJlIGdtdF91bml4
X3RpbWUgZmllbGQgcmFuZG9tbHk7PGJyPg0KJmd0OyB0aGlzIGFwcGVhcnMgbm90IHRvIGhhdmUg
YnJva2VuIFRMUyBvbiB0aGUgaW50ZXJuZXQuPGJyPg0KJmd0Ozxicj4NCiZndDsgQXQgbGVhc3Qg
b25lIHRvb2wgKHRsc2RhdGUpIHVzZXMgdGhlIHNlcnZlci1zaWRlIHZhbHVlIG9mIHRoZTxicj4N
CiZndDsgZmllbGQgYXMgYW4gYXV0aGVudGljYXRlZCB2aWV3IG9mIHRoZSBjdXJyZW50IHRpbWUu
PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBQUk9QT1NBTCAxOjxicj4N
CiZndDs8YnI+DQomZ3Q7IERlY2xhcmUgdGhhdCBpbXBsZW1lbnRhdGlvbnMgTUFZIHJlcGxhY2Ug
Z210X3VuaXhfdGltZSBlaXRoZXIgd2l0aDxicj4NCiZndDsgZm91ciBtb3JlIHJhbmRvbSBieXRl
cywgb3IgZm91ciBieXRlcyBvZiB6ZXJvZXMuPGJyPg0KJmd0Ozxicj4NCiZndDsgUmF0aW9uYWxl
Ojxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyogU29tZSBpbXBsZW1lbnRhdGlvbnMgKGxpa2UgVG9y
QnJvd3NlcikgYXJlIGFscmVhZHkgZG9pbmcgdGhpczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDtpbiBwcmFjdGljZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7KiBJdCdz
IHNlbnNpYmxlIGFuZCBzaW1wbGUuICZuYnNwO0ltcGxlbWVudG9ycyBhcmUgcXVpdGUgdW5saWtl
bHkgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWVzcyBpdCB1cC48YnI+DQomZ3Q7
PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFBST1BPU0FMIDI6PGJyPg0KJmd0Ozxicj4N
CiZndDsgU3VwcG9zZSB0aGF0IHdlIGRvIG5vdCBhY2NlcHQgdGhlIGFyZ3VtZW50IGFib3V0IHRo
ZSBwb2ludGxlc3NuZXNzPGJyPg0KJmd0OyBvZiBnbXRfdW5pdF90aW1lIHRoYXQgSSBtYWtlIGFi
b3ZlLCBhbmQgd2Ugd2FudCB0byBwcmVzZXJ2ZSB0aGU8YnI+DQomZ3Q7IHNlY3VyaXR5IGl0IGFs
bGVnZWRseSBwcm92aWRlcy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbiB0aGF0IGNhc2UsIHdlIGNh
biBhbGxvdyB0aGUgZm9sbG93aW5nIGFwcHJvYWNoIGluc3RlYWQ6PGJyPg0KJmd0Ozxicj4NCiZn
dDsgU2V0IHRoZSBSYW5kb20gZmllbGQsIG5vdCB0byAzMiBieXRlcyBmcm9tIHlvdXIgUFJORywg
YnV0IHRvIHRoZTxicj4NCiZndDsgSE1BQy1TSEEyNTYgb2YgYW55IGhpZ2ggcmVzb2x1dGlvbiB0
aW1lciB0aGF0IHlvdSBoYXZlLCB1c2luZyAzMjxicj4NCiZndDsgYnl0ZXMgZnJvbSB5b3VyIFBS
TkcgYXMgYSBrZXkuICZuYnNwO0luIG90aGVyIHdvcmRzLCByZXBsYWNlIHRoaXM6PGJyPg0KJmd0
Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1JhbmRvbS5nbXRfdW5peF90aW1lID0gdGltZSgpOzxi
cj4NCiZndDsgJm5ic3A7ICZuYnNwO1JhbmRvbS5yYW5kb21fYnl0ZXMgPSBnZXRfcmFuZG9tX2J5
dGVzKDI4KTxicj4NCiZndDs8YnI+DQomZ3Q7IHdpdGggdGhpczo8YnI+DQomZ3Q7PGJyPg0KJmd0
OyAmbmJzcDsgJm5ic3A7bm93ID0gaGlyZXNfdGltZSgpOyAvLyBjbG9ja19nZXR0aW1lKCksIG9y
IGNvbmNhdGVuYXRlIHRpbWUoKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsv
LyB3aXRoIGEgQ1BVIHRpbWVyLCBvciBwcm9jZXNzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOy8vIHVwdGltZSwgb3Igd2hhdGV2ZXIuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7
a2V5ID0gZ2V0X3JhbmRvbV9ieXRlcygzMik7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7UmFuZG9t
ID0gaG1hY19zaGEyNTYoa2V5LCBub3cpOzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgYXBwcm9h
Y2ggaXMgYmV0dGVyIHRoYW4gdGhlIHN0YXR1cyBxdW8gb24gdGhlIGZvbGxvd2luZzxicj4NCiZn
dDsgY291bnRzOjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsqIEl0IGRvZXNuJ3Qg
bGVhayB5b3VyIHZpZXcgb2YgdGhlIGN1cnJlbnQgdGltZSwgYXNzdW1pbmcgdGhhdDxicj4NCiZn
dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt5b3VyIFBSTkcgaXNuJ3QgYnVzdGVkLjxicj4NCiZndDs8
YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsqIEl0IGFjdHVhbGx5IGZpeGVzIHRoZSBwcm9ibGVtIHRo
YXQgZ210X3VuaXhfdGltZSBwdXJwb3J0ZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7Zml4LCBieSB1c2luZyBhIGhpZ2gtcmVzb2x1dGlvbiB0aW1lIHRoYXQncyBtdWNoIGxlc3Mg
bGlrZWx5IHRvPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIHVzZWQgdHdpY2UuICZu
YnNwO0V2ZW4gaWYgdGhlIFBSTkcgaXMgYnJva2VuLCB0aGUgdmFsdWUgaXMgc3RpbGw8YnI+DQom
Z3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bm9ucmVwZWF0aW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7
IEkgZG8gbm90IHRoaW5rIHRoaXMgaXMgbm90IHdvcnNlIHRoYW4gdGhlIHN0YXR1cyBxdW86PGJy
Pg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyogSXQgaXMgdW5wcmVkaWN0YWJsZSBmcm9t
IGFuIGF0dGFja2VyJ3MgUE9WLCBhc3N1bWluZyB0aGF0IHRoZTxicj4NCiZndDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDtQUk5HIHdvcmtzLiAmbmJzcDsoQmVjYXVzZSBhbiBITUFDLCBldmVuIG9mIGtu
b3duIGRhdGEsIHdpdGggYW48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dW5rbm93biBy
YW5kb20ga2V5IGlzIHN1cHBvc2VkIHRvIGxvb2sgcmFuZG9tKS48YnI+DQomZ3Q7PGJyPg0KJmd0
Ozxicj4NCiZndDsgUFJPUE9TQUwgMzxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIGEgaHlicmlkIGFs
dGVybmF0aXZlLCBvbmUgY291bGQgc2V0IHBhcnQgb2YgdGhlIENsaWVudFJhbmRvbTxicj4NCiZn
dDsgZmllbGQgKHBlcmhhcHMgMTIgYnl0ZXMgb3Igc28pIGJhc2VkIG9uIHRoZSBITUFDIG9mIHRo
ZSB0aW1lLCBhbmQ8YnI+DQomZ3Q7IHRoZSByZXN0IG9mIHRoZSBDbGllbnRSYW5kb20gZmllbGQg
YmFzZWQgb24gdGhlIFBSTkc6PGJyPg0KJmd0Ozxicj4NCiZndDsgJm5ic3A7ICZuYnNwO04gPSAx
Mjxicj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtub3cgPSBoaXJlc190aW1lKCk7PGJy
Pg0KJmd0OyAmbmJzcDsgJm5ic3A7a2V5ID0gZ2V0X3JhbmRvbV9ieXRlcygzMik7PGJyPg0KJmd0
OyAmbmJzcDsgJm5ic3A7bWFjID0gaG1hY19zaGEyNTYoa2V5LCBub3cpWzA6Tl07ICZuYnNwOy8v
IEZpcnN0IE4gYnl0ZXMuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cmFuZCA9IGdldF9yYW5kb21f
Ynl0ZXMoMzIgLSBOKTxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1JhbmRvbSA9IG1hYyAmIzQzOyYj
NDM7IHJhbmQgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
IC8vIGNvbmNhdGVuYXRlLjxicj4NCiZndDs8YnI+DQomZ3Q7IEJ1dCB0aGlzIHNlZW1zIHRvIGJl
IGdldHRpbmcgcG9pbnRsZXNzbHkgYmFyb3F1ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZn
dDs8YnI+DQomZ3Q7IENPTlNJREVSQVRJT05TOjxicj4NCiZndDs8YnI+DQomZ3Q7IEknZCBwZXJz
b25hbGx5IHN1Z2dlc3QgcHJvcG9zYWwgMSAoanVzdCBzZXQgdGhlIGZpZWxkIGF0IHJhbmRvbSkg
Zm9yPGJyPg0KJmd0OyBtb3N0IHVzZXJzLiAmbmJzcDtZZXMsIGl0IG1ha2VzIHRoaW5ncyBhIGxp
dHRsZSB3b3JzZSBpZiB5b3VyIFBSTkcgY2FuPGJyPg0KJmd0OyBnZW5lcmF0ZSByZXBlYXQgdmFs
dWVzLi4uIGJ1dCBuZWFybHkgZXZlcnl0aGluZyBpbiBjcnlwdG9ncmFwaHk8YnI+DQomZ3Q7IGZh
aWxzIGlmIHlvdXIgUFJORyBpcyBicm9rZW4uPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7
IFdlIG1pZ2h0IHdhbnQgdG8gYXBwbHkgdGhpcyBmaXggb24gY2xpZW50cyBvbmx5LiAmbmJzcDtX
aXRoIGEgZmV3PGJyPg0KJmd0OyBleGNlcHRpb25zIChsaWtlIGhpZGRlbiBzZXJ2aWNlcykgdGhl
IHNlcnZlcidzIHZpZXcgb2YgdGhlIGN1cnJlbnQ8YnI+DQomZ3Q7IHRpbWUgaXMgbm90IHNlbnNp
dGl2ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgSW1wbGVtZW50b3JzIG1pZ2h0IHdh
bnQgdG8gbWFrZSB0aGlzIGZlYXR1cmUgb3B0aW9uYWwgYW5kPGJyPg0KJmd0OyBvbi1ieS1kZWZh
dWx0LCBqdXN0IGluIGNhc2Ugc29tZSBoaWdoZXItbGV2ZWwgYXBwbGljYXRpb24gcHJvdG9jb2w8
YnI+DQomZ3Q7IHJlYWxseSBkb2VzIGRlcGVuZCBvbiBpdC48YnI+DQomZ3Q7IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBUTFMgbWFpbGlu
ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5v
cmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vdGxzPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpU
TFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+
VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vdGxzIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs
czwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp
dj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_E774C81546D66E429BF56B1474C7EBBA010E33002ESEAEMBX01olym_--

From prvs=2966a68272=uri@ll.mit.edu  Wed Sep 11 11:24:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A60511E80A2 for ; Wed, 11 Sep 2013 11:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.349,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VYdpmgTmDiO for ; Wed, 11 Sep 2013 11:24:20 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id B39DB11E820F for ; Wed, 11 Sep 2013 11:24:18 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8BICmd0028888; Wed, 11 Sep 2013 14:24:08 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Peter Gutmann , "benl@google.com" , "tls@ietf.org" , Nikos Mavrogiannopoulos 
Date: Wed, 11 Sep 2013 14:23:27 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac6vHAPhQ6+K8df9RgeSa3vF12wT5g==
Message-ID: 
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735566CD97@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.7.130812
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3461754207_5404671"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-11_06:2013-09-11, 2013-09-11, 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-1305240000 definitions=main-1309110105
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 18:24:25 -0000

--B_3461754207_5404671
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 9/11/13 2:02 , "Peter Gutmann"  wrote:


>Nikos Mavrogiannopoulos 
>
>>Do you have any reference for that? RFC2104 and the paper it references
>>claim otherwise.
>
>Oh man, that'd require ploughing through 15-year-old email discussions...
>to see it in effect, look at section 2 of RFC 2402.

I see no presented evidence of having a clue.

There's nothing in RFC 2402 that would support your (unfounded)
speculation. On the other hand, section 6 of RFC 2402 refers to the two
mandatory-to-implement RFC 2403 (HMAC-MD5-96) and 2404 (HMAC-SHA-1-96).

RFC 2404 section 5 (Security Considerations, unsurprisingly), 4th
paragraph refers to RFC 2104 and explicitly mentions ADDITIONAL SECURITY
PROVIDED BY THE TRUNCATION OF THE RESULTING HASH.

Finally, RFC 2104 (HMAC) section 5 (Truncated output) describes the
cryptographic consequences of truncating the hash (less information on
hash result available to attacker vs. fewer bits to predict), with
reference to Preneel and Van Oorschot paper from Crypto'95 "Building fast
MACs from hash
           Functions".

Enough?

--B_3461754207_5404671
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD
F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0
B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p
rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr
i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8
11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB
BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw
PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/
inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd
XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq
oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5
48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ
/Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw
ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J
VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v
dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w
HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT
Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg
MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK
Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2
QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z
XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK
sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn
qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G
CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny
bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG
MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3
EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G
CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk
zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm
UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD
2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU
meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB
snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw
CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD
UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz
NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx
DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv
f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT
XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/
hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX
TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW
6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y
EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G
CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I
1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P
yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/
LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr
oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90
ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw
EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL
MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT
BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X
519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb
z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn
w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3
sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8
B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD
VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH
AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ
KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC
AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn
+t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f
NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU
3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ
aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw
ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv
cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg
hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAmgOTGH822cZ0ihw7zdkRAHAMCu2NZJm/l
WheuHa67rzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5
MTExODIzMjdaMA0GCSqGSIb3DQEBAQUABIIBAHsm/4K5XTH6J1uTbmaCs0oSSgjl6rb70RkA
b14UleNaFHFzK1Et13iC9cQgNllRAuo4qUW4/d10ww2ChBPsyv1HUMNqEnYlQYGWAIVlvkCW
jYA9ltu2RqtzbST++g+pFkwEt7OTQfh7axWkR+a6R4QOylXgQwl/j7/ae7ZEaIFMC+usnID9
4CZ+ocvWmzhwTLKYt8Z5oYeoGaTH/1+i5kz2K4Hvq914vOg29v1u/oQjrZ2VUIMTs171wgyg
+nDVJvvBBnsn9htfuQ4cyGdMp57zMa2a7ReqsG02M/OyR1h5fheKS94RrdNcOAMX3Eu3yoA0
jS7K7ipyjjO4QN6LlNY=

--B_3461754207_5404671--

From stebila@qut.edu.au  Wed Sep 11 16:33:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A895221F9A6C for ; Wed, 11 Sep 2013 16:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.484
X-Spam-Level: 
X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_05=-1.11, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327,  RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrlzX2Zcb8qw for ; Wed, 11 Sep 2013 16:33:22 -0700 (PDT)
Received: from QUTEXEDGE04.qut.edu.au (qutexedge04.qut.edu.au [131.181.191.21]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0511E8116 for ; Wed, 11 Sep 2013 16:33:21 -0700 (PDT)
Received: from QUTEXHUB04.qut.edu.au (131.181.186.100) by qutexedge04.qut.edu.au (131.181.191.21) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 12 Sep 2013 09:33:20 +1000
Received: from QUTEXMBX01.qut.edu.au ([131.181.107.108]) by QUTEXHUB04.qut.edu.au ([131.181.186.100]) with mapi; Thu, 12 Sep 2013 09:32:57 +1000
From: Douglas Stebila 
To: Nick Mathewson 
Date: Thu, 12 Sep 2013 09:32:57 +1000
Thread-Topic: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
Thread-Index: Ac6vRz7KkXi7q2yET0CiH4ksrYgQpw==
Message-ID: <834B655C-1C07-412F-B190-AE5DDE2942F1@qut.edu.au>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au>   <20130910012240.5595281.33313.3530@certicom.com> 
In-Reply-To: 
Accept-Language: en-US, en-AU
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US, en-AU
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Testing consensus for adding curve25519 to the EC named curve registry
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Sep 2013 23:33:28 -0000

On the topic of a smallish fraction of elliptic curves being weak, I asked =
Alfred Menezes, a prof at Waterloo who knows a lot about elliptic curves an=
d was active in the development of ECC in the late 90s; he wrote this to me=
:

> The idea at the time was to rule out the possibility of someone choosing
> *very* special curves. For example, if one knows that elliptic curves
> of a certain order N over a certain prime field GF(p) are weak, then it
> would not be possible to find a seed which gave such a curve. It was felt=
=20
> that if a significant proportion of elliptic curves (e.g. 1/10000000) ove=
r=20
> a fixed field GF(p) or GF(2^m) (with m prime) which meet the standard=20
> requirements (e.g. group order divisible by a large prime, sufficiently=20
> large embedding degree, etc.) was found to be weak, then that would in=20
> any case spell the end of ECC. Certainly if one has a weak curve then=20
> one can produce a much larger family of weak curves by low-degree=20
> isogeny walks.

This is quite similar to what Dan has said in his reply to your email, that=
 existence of a non-negligibly sized class of weak curves would jeopardize =
other randomly selected curves.

I agree with you that it would be more comforting to know where the seeds c=
ame from.  Alfred told me he didn't know.  And I can't see any discernible =
pattern in the seeds (nothing obvious in ASCII; not in the first few millio=
n decimal digits of e or the first 200 million decimal digits of pi). =20

But I also find convincing the argument that even one in 2^50 or 2^60 rando=
mly selected curves being weak would cause major doubts about the security =
of random 256-bit curves.  There are at least distinct 2^256 elliptic curve=
s over a 256-bit prime, and if even one in 2^60 was weak, then there would =
be roughly 2^200 weak elliptic curves over that prime. =20

To me, this is saying that either you reject all randomly generated curves =
of (near) prime order over a prime field, or you believe there is no non-ne=
gligbly sized class of weak curves. =20

Douglas


On 2013/09/12, at 01:10, Nick Mathewson  wrote:

> On Mon, Sep 9, 2013 at 9:22 PM, Dan Brown  wrote:
>> I'm the current editor of ANSI X9.62 and X9.63, but joined X9F1 a little=
 later than the time in question, so am not the best historical source.
>>=20
>> Anyway, I had thought the 15 NIST curves were included in ANSI X9.63 in =
2001, but most were not in X9.62 in its first 1998 version, and only added =
in the 2005 version.
>>=20
>> The curve seed sources were not documented in ANSI or NIST docs. I've wo=
ndered about it a few times, but could never see a concrete problem. At lea=
st intuitively, it would only be a problem if:
>>=20
>> 1) a large fraction of elliptic curves were weak, or
>>=20
>> 2) sha1 preimages are easy to find and some unknown but rare class of el=
liptic curves are weak.
>>=20
>> Both of these would undermine more than just the curve choice, and seem =
extremely unlikely.
>=20
> That's true, so long as "large fraction" and "rare" are defined
> appropriately.  But I think what most of the people who worry about
> this are worried about is something like:
>=20
> 3) A small-ish fraction of elliptic curves (say, one in every
> quadrillion or quintillion or so) has some as-yet-unknown weakness,
> and building a sha1 brute-forcing engine to find seeds that would
> produce such curves was economically viable the late 1990s.
>=20
> After a little time investigating SHA1 speeds on late-1990s FPGAs,
> special-purpose chips, and general purpose CPUs, a
> back-of-the-envelope calculation suggests that, given about ten
> million dollars of hardware and about half a year's worth of
> processing time, searching quintillions of seeds to find curves with
> desired properties wouldn't have been unrealistic.
>=20
> Now, none of this means that the seeds in question actually _were_
> chosen in any hostile way, of course. But it would make it more
> comforting if anybody could point out where the seeds actually came
> from.
>=20
> best wishes,
> --=20
> Nick Mathewson


From aerowolf@gmail.com  Wed Sep 11 17:03:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA3D11E811F for ; Wed, 11 Sep 2013 17:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.933
X-Spam-Level: 
X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArBXYOtFQEiW for ; Wed, 11 Sep 2013 17:03:58 -0700 (PDT)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E67D511E80FD for ; Wed, 11 Sep 2013 17:03:57 -0700 (PDT)
Received: by mail-we0-f175.google.com with SMTP id q59so8530284wes.20 for ; Wed, 11 Sep 2013 17:03: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=TFTfHL36LcA1ldvs7+MjNjsKRVhNeJxJj+p0hDiEIAE=; b=cUOtE5Eb05qtMyERfLuj4jyRI1WSTcmj08cU2tQGzsAbX98CvIoBfVFu8e3+9jiCFg w73jHQdnRYrXrgYsUyZdByLeVsr2xMGNDefqFI8ywUrtwfUnirQEgKrua+ok4vDkdA5B Cwl+FGH+f2butXOGYxq153sAPxJaT8NW7VHwBAVPH5SBQaWKl0pSDB8WdPitTgevJo+I 5RAMr+K6Bz8kqIfioJtuFB6l26eUp4el5Ux8/SQyBwn7JW3GE0gxCgbqTCT9KhHJOZrU uh9ljAqwqUd6r2u5urfOplY1OlmM6gFc6+xbGvxpUQB1eapRZNgvpUp3GLBBX1qbLA+r 6OKg==
MIME-Version: 1.0
X-Received: by 10.180.106.40 with SMTP id gr8mr3417022wib.11.1378944237097; Wed, 11 Sep 2013 17:03:57 -0700 (PDT)
Received: by 10.194.134.67 with HTTP; Wed, 11 Sep 2013 17:03:57 -0700 (PDT)
In-Reply-To: <522ED9A7.7080802@comodo.com>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com>
Date: Wed, 11 Sep 2013 17:03:57 -0700
Message-ID: 
From: Kyle Hamilton 
To: Rob Stradling 
Content-Type: multipart/alternative; boundary=f46d044519a96adc3704e62479b4
Cc: Simon Josefsson , Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 00:03:59 -0000

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

Curve25519 is not suitable for authentication.  Ed25519 would be more
appropriate, I think.

-Kyle H


On Tue, Sep 10, 2013 at 1:34 AM, Rob Stradling wrote:

> On 09/09/13 21:08, Simon Josefsson wrote:
>
>> Douglas Stebila  writes:
>>
>>  There are other reasons to support curve25519, including efficiency
>>> and resistance to side-channel attacks because constant-time
>>> implementations.
>>>
>>
>> I agree.  To be able to move forward with standardization of the idea,
>> an Internet Draft may help.  I have create one:
>>
>> http://www.ietf.org/id/draft-**josefsson-tls-curve25519-00.**txt
>>
>> Feedback most welcome!
>>
>
> Simon, thanks for creating this draft.
>
> draft-merkle-tls-brainpool-04 (on which you've based this new draft) says:
>    "While the ASN.1 object identifiers
>    defined in [RFC5639] already allow usage of the ECC Brainpool curves
>    for TLS (client or server) authentication through reference in X.509
>    certificates according to [RFC3279] and [RFC5480] , their negotiation
>    for key exchange according to [RFC4492] requires the definition and
>    assignment of additional NamedCurve IDs."
>
> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it to
> be used for key exchange.  But what about "(client or server)
> authentication through reference in X.509 certificates..."?
>
> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
> create one?  Or could we simply define some new ASN.1 Object Identifiers in
> your draft?
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>
>
> ______________________________**_________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/**listinfo/tls
>

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


Curve25519 is not suitable for authentication.=C2=A0 =
Ed25519 would be more appropriate, I think.

-Kyle H


On =
Tue, Sep 10, 2013 at 1:34 AM, Rob Stradling <rob.stradling@comodo=
.com> wrote:


On 09/09/13 21:08, Simon J=
osefsson wrote:



Douglas Stebila <stebila@qut.edu.au> writes:





There are other reasons to support curve25519, including efficiency

and resistance to side-channel attacks because constant-time

implementations.





I agree. =C2=A0To be able to move forward with standardization of the idea,=


an Internet Draft may help. =C2=A0I have create one:



http://www.ietf.org/id/draft-josefsson-tls-curve2551=
9-00.txt



Feedback most welcome!





Simon, thanks for creating this draft.



draft-merkle-tls-brainpool-04 (on which you've based this new draft) sa=
ys:

=C2=A0 =C2=A0"While the ASN.1 object identifiers

=C2=A0 =C2=A0defined in [RFC5639] already allow usage of the ECC Brainpool =
curves

=C2=A0 =C2=A0for TLS (client or server) authentication through reference in=
 X.509

=C2=A0 =C2=A0certificates according to [RFC3279] and [RFC5480] , their nego=
tiation

=C2=A0 =C2=A0for key exchange according to [RFC4492] requires the definitio=
n and

=C2=A0 =C2=A0assignment of additional NamedCurve IDs."



Your draft defines a NamedCurve ID for Curve25519, thereby enabling it to b=
e used for key exchange. =C2=A0But what about "(client or server) auth=
entication through reference in X.509 certificates..."?



I'm not aware of an equivalent of RFC5639 for Curve25519. =C2=A0Should =
we create one? =C2=A0Or could we simply define some new ASN.1 Object Identi=
fiers in your draft?



-- 

Rob Stradling

Senior Research & Development Scientist

COMODO - Creating Trust Online




_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d044519a96adc3704e62479b4--

From nick.a.mathewson@gmail.com  Wed Sep 11 20:51:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E65E21E8128; Wed, 11 Sep 2013 20:51:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.726
X-Spam-Level: 
X-Spam-Status: No, score=-1.726 tagged_above=-999 required=5 tests=[AWL=0.252,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j5P5BRAAzz2; Wed, 11 Sep 2013 20:51:30 -0700 (PDT)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9021E8122; Wed, 11 Sep 2013 20:51:28 -0700 (PDT)
Received: by mail-la0-f43.google.com with SMTP id ep20so8078574lab.2 for ; Wed, 11 Sep 2013 20:51:20 -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=pFrMfEaZLUQ0i0pHlHuaRqSUvR8ShZy7SbRVYvG2CRg=; b=zgorwEkDUCdmi7O6aTdFrwMSfWoJ2NkNhgFjZZHR2WQXup1+97sHC6+qhLAVrlYr1I x5bIdNi/g1hX0sqPwMyxXydEZvYjOPQeBRya85aOxWLzGyZSIw2irBLQ1x5zwsarPr1Z WLRIpxlYol+cy54N/n2/yioKR174i9QVU+Jy0LBVlp6dYZJQg2qZ/8QZi2DEhC+Y9do0 BwBfIix0qGS0yn04oImX0SI1/IZKOFVgcUy6Ig7mMxcA2YAAqILiPh2wXPHcCz2mOxCK KE/zjqEcJVENtHlnFFw+2oIFUBwQETMpXXhqNz/ouxM8hZJGmi3JGfJDHzsc3gGsxzVd +fnA==
MIME-Version: 1.0
X-Received: by 10.112.126.37 with SMTP id mv5mr5549191lbb.20.1378957880839; Wed, 11 Sep 2013 20:51:20 -0700 (PDT)
Sender: nick.a.mathewson@gmail.com
Received: by 10.112.30.166 with HTTP; Wed, 11 Sep 2013 20:51:20 -0700 (PDT)
In-Reply-To: <20130911174135.455A01A960@ld9781.wdf.sap.corp>
References:  <20130911174135.455A01A960@ld9781.wdf.sap.corp>
Date: Wed, 11 Sep 2013 23:51:20 -0400
X-Google-Sender-Auth: qrYdXjCpbpbr9boikU2391fFQu0
Message-ID: 
From: Nick Mathewson 
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [perpass]  Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 03:51:32 -0000

On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex  wrote:
> Nick Mathewson wrote:
>> ====
>> SYNOPSIS:
>>
>> In TLS as currently specified, clients and servers each send their
>> current view of "the time" in the clear as part of their handshake.
>> This provides a fingerprint that can track users in spite of other
>> attempts to make them untrackable.  I propose several ways to stop
>> doing sending this cleartext timestamp; some trivial and some more
>> complex.
>
> I would really appreciate a different approach to the underlying
> issue, and less throwing of smoke grenades here.

I assume good faith on your part; please do the favor of assuming good
faith on mine.

> If you're worried about being slightly "distinguishable" from some
> other clients, then there are a lot more reliable identifiers available
> in the average TLS handshake, so claiming that sending the actual local
> time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting
> issue and sending random will solve the fingerprinting issue, is
> bordering on lame for >99% of the clients.

Indeed, I never said this was a "severe" issue, or that it was the
only issue you need to solve to solve fingerprinting.  I said: "This
provides a fingerprint that can track users in spite of other attempts
to make them untrackable."

I know that reading perpass, one expects proposals to fundamentally
transform the Internet to make it more secure.  This is not such a
fundamental transformation. This is a little simple change to fix a
little simple little problem.

Of such simple little problems, client linkability is made.

> Most of the time, repeated requests of the same TLS client can be
> identified by the network connection having the same client IP address,
> the TLS session proposed for resumption in ClientHello.session_id
> or maybe someone still using TLS session tickets (rfc5077).

> So rather than pointing to ClientHello.Random.gmt_unix_time as a
> and claiming there would be a simple fix, one will likely have to
> create and go through a long list of issues to determine which
> features facilitate fingerprinting and tracking (cipher suites
> and many TLS extensions (TLS caching extension, signature algorithms,
> Next protocol negotiation, supported elliptic curves, etc.) may
> all help in distinguishing clients, and would also have to be
> taken care of.

That's all true; disabling gmt_unix_time is by no means sufficient to
make multiple TLS clients look the same on the wire, or to prevent an
observer distinguishing TLS instances.

In Tor's case, we mitigate this by disabling some TLS features,
specifying required values for others, rotating some identifiers more
frequently than most implementations, and shipping all of our clients
with the same crypto libraries.  Most of the fingerprinting issues in
TLS can be ameliorated, for a single application, by defining a
profile that all of that application's users should share.

My issue here right now that, even *after* taking all these
precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
doesn't make it optional.  Come heck or high water, Tor is going to
stop sending gmt_unix_time unless we find a really excellent reason to
send it.  We'd like to replace it with the best alternative we can. I
sent all the alternatives I could think of, because:

  1) I would like future versions of the TLS RFC to not require gmt_unix_time.
  2) I would like to know whether there's a truly legit reason to send
gmt_unx_time.
  3) I would like to know the best thing to do instead of gmt_unix_time.

(The IP address issue is important too, but not overriding here. The
issue here is that even after a client has changed its IP addresses
either through moving around the network or going behind a NAT or VPN
or by using an IP anonymization service, this fingerprint remains.)

-- 
Nick

From mrex@sap.com  Wed Sep 11 21:17:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C16421F9C06; Wed, 11 Sep 2013 21:17:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level: 
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13sas5iH2Gqx; Wed, 11 Sep 2013 21:17:36 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC7521F9E99; Wed, 11 Sep 2013 21:17:35 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8C4HXJi025819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 12 Sep 2013 06:17:33 +0200 (MEST)
In-Reply-To: 
To: Nick Mathewson 
Date: Thu, 12 Sep 2013 06:17:33 +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: <20130912041733.817521A961@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [perpass]  Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 12 Sep 2013 04:17:40 -0000

Nick Mathewson wrote:
> 
> My issue here right now that, even *after* taking all these
> precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
> doesn't make it optional.

Huh?  where in rfc6101, rfc2246, rfc4346 or rfc5246 do you find
_anything_at_all_ that could be remotely interpreted as a
requirement for ClientHello.Random.gmt_unix_time to have any
specific value or be within any particular value range -- 
in contradiction to what section 7.4.1.2 says?

(Same for ServerHello.Random.gmt_unix_time).

   http://tools.ietf.org/html/rfc2246#section-7.4.1.2

       Structure of this message:
           The client hello message includes a random structure, which is
           used later in the protocol.

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       gmt_unix_time
       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.


Which part of "Clocks are not required to be set correctly by the
basic TLS protocol" is unclear?  This explicitly spells out that
one can send _ANY_ pattern of 32 bits as gmt_unix_time, as far as
the SSLv3&TLS protocol specifications themselves are concerned.


-Martin

From pgut001@cs.auckland.ac.nz  Wed Sep 11 22:20:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C1621E812A; Wed, 11 Sep 2013 22:20: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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QiWtVMEBTDDE; Wed, 11 Sep 2013 22:20:53 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE721E812E; Wed, 11 Sep 2013 22:20:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378963248; x=1410499248; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uWlLEbZZLdgXpTrt1h0LVJnFiQyGwJvyg5uqJeWMM0k=; b=iU9FWhMKo1zv9hEvE+xShVsxhhk9ueYeClUO6iVRmsbrqeF836sSq+G8 QNTrB/hRtyTgMvg/Cs5XEQXnpTP5+H7oVlzPQyMLn5AZhrLs2BQSa5pkw jSQNFNpIwKQ0420Wy51X0sSERcCnWj735lOBFCvDFGGLv95VXaFtKTXXN I=;
X-IronPort-AV: E=Sophos;i="4.90,888,1371038400"; d="scan'208";a="211759492"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Sep 2013 17:20:44 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 17:20:44 +1200
From: Peter Gutmann 
To: Eric Rescorla , Alfredo Pironti , "perpass@ietf.org" , "tls@ietf.org" 
Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS
Thread-Index: Ac6vd9PFx71XQUH1RkGmUyB65MA//g==
Date: Thu, 12 Sep 2013 05:20:42 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 05:21:01 -0000

Eric Rescorla  writes:=0A=
=0A=
>Before we discuss mechanisms, it would be good to verify that in general =
=0A=
>clients and servers don't become unhappy if the timestamp is radically =0A=
>wrong. Has someone done measurements to verify that this is in fact the =
=0A=
>case at a broad scale?=0A=
=0A=
Yes.  I've been putting random noise in the timestamp field for about 15=0A=
years (or more specifically I've never put a timestamp in the timestamp=0A=
field), no user has ever reported problems with this.=0A=
=0A=
Peter.=0A=

From maray@microsoft.com  Thu Sep 12 01:26:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5D221E8160; Thu, 12 Sep 2013 01:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzMYVfRRUy63; Thu, 12 Sep 2013 01:25:55 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32B1121E8154; Thu, 12 Sep 2013 01:25:54 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Thu, 12 Sep 2013 08:25:49 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Thu, 12 Sep 2013 08:25:49 +0000
From: Marsh Ray 
To: Peter Gutmann , Eric Rescorla , Alfredo Pironti , "perpass@ietf.org" , "tls@ietf.org" 
Thread-Topic: [TLS] Let's remove gmt_unix_time from TLS
Thread-Index: Ac6vd9PFx71XQUH1RkGmUyB65MA//gAGLggg
Date: Thu, 12 Sep 2013 08:25:48 +0000
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735566D793@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
x-forefront-prvs: 0967749BC1
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(74316001)(74366001)(74876001)(19580405001)(19580395003)(83322001)(83072001)(81342001)(81542001)(80976001)(76482001)(81816001)(81686001)(65816001)(79102001)(54316002)(76576001)(76786001)(74502001)(56816003)(77096001)(56776001)(76796001)(31966008)(69226001)(74706001)(49866001)(4396001)(50986001)(47976001)(47736001)(53806001)(54356001)(63696002)(59766001)(77982001)(46102001)(80022001)(47446002)(33646001)(51856001)(74662001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB167; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 08:26:00 -0000

> Eric Rescorla  writes:
>Before we discuss mechanisms, it would be good to verify that in
>general clients and servers don't become unhappy if the timestamp is
>radically wrong. Has someone done measurements to verify that this is
>in fact the case at a broad scale?

I just checked and the current version doesn't do this, but ISTR older Inte=
rnet Explorer would populate the "GMT" field with the local time. If my rec=
ollection is true, this would probably represent "broad scale".

This would reveal the client's time zone. So particularly for clients trave=
rsing VPNs and proxies it would represent an info leak to a passive eavesdr=
opper positioned near the server.

- Marsh


From stephen.farrell@cs.tcd.ie  Thu Sep 12 01:57:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C54621E819C; Thu, 12 Sep 2013 01:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D78rxCz9yLOI; Thu, 12 Sep 2013 01:57:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 12B6D21E8194; Thu, 12 Sep 2013 01:57:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 97CD9BE8F; Thu, 12 Sep 2013 09:57:39 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ik0FrTZwrhCl; Thu, 12 Sep 2013 09:57:39 +0100 (IST)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 777FBBE8A; Thu, 12 Sep 2013 09:57:39 +0100 (IST)
Message-ID: <52318203.4070109@cs.tcd.ie>
Date: Thu, 12 Sep 2013 09:57:39 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nick Mathewson , mrex@sap.com
References:  <20130911174135.455A01A960@ld9781.wdf.sap.corp> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: perpass@ietf.org, "tls@ietf.org" 
Subject: Re: [TLS] [perpass]  Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 08:57:47 -0000

Hi Nick, Martin,

On 09/12/2013 04:51 AM, Nick Mathewson wrote:
> On Wed, Sep 11, 2013 at 1:41 PM, Martin Rex  wrote:
>> Nick Mathewson wrote:
>>> ====
>>> SYNOPSIS:
>>>
>>> In TLS as currently specified, clients and servers each send their
>>> current view of "the time" in the clear as part of their handshake.
>>> This provides a fingerprint that can track users in spite of other
>>> attempts to make them untrackable.  I propose several ways to stop
>>> doing sending this cleartext timestamp; some trivial and some more
>>> complex.
>>
>> I would really appreciate a different approach to the underlying
>> issue, and less throwing of smoke grenades here.
> 
> I assume good faith on your part; please do the favor of assuming good
> faith on mine.

I think its fair to say that Martin is not renowned for
taking a laid-back zen-like approach when making his
almost-always-good technical contributions:-)

But I didn't see him questioning good faith, I interpret
him as asking (forcefully:-) why this change is worth
doing.

(And that's a common pattern actually: someone says "if we
do X that'll make privacy a bit better" and someone else
says "but there are so many other ways to leak private
info, why bother just doing X?")

>> If you're worried about being slightly "distinguishable" from some
>> other clients, then there are a lot more reliable identifiers available
>> in the average TLS handshake, so claiming that sending the actual local
>> time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting
>> issue and sending random will solve the fingerprinting issue, is
>> bordering on lame for >99% of the clients.
> 
> Indeed, I never said this was a "severe" issue, or that it was the
> only issue you need to solve to solve fingerprinting.  I said: "This
> provides a fingerprint that can track users in spite of other attempts
> to make them untrackable."
> 
> I know that reading perpass, one expects proposals to fundamentally
> transform the Internet to make it more secure.  

Well, boiling oceans is definitely not the intent of this list.
My guess is that overbroad proposals will get the (lack of)
attention they deserve and will wither on the vine.

> This is not such a
> fundamental transformation. This is a little simple change to fix a
> little simple little problem.

I agree. And seems like a worthwhile one too. BTW, since
the TLS list discussion is up and running, I don't think
there's a need to cc perpass more for this. It was a good
idea to bring it here, but I suspect for this one, we can
let the TLS wg fire ahead and get someone to write up an
I-D if one is needed for this. (My guess is it'd be useful
to have a nice short RFC that updates the relevant bit of
5246 and says why.)

> Of such simple little problems, client linkability is made.
> 
>> Most of the time, repeated requests of the same TLS client can be
>> identified by the network connection having the same client IP address,
>> the TLS session proposed for resumption in ClientHello.session_id
>> or maybe someone still using TLS session tickets (rfc5077).
> 
>> So rather than pointing to ClientHello.Random.gmt_unix_time as a
>> and claiming there would be a simple fix, one will likely have to
>> create and go through a long list of issues to determine which
>> features facilitate fingerprinting and tracking (cipher suites
>> and many TLS extensions (TLS caching extension, signature algorithms,
>> Next protocol negotiation, supported elliptic curves, etc.) may
>> all help in distinguishing clients, and would also have to be
>> taken care of.
> 
> That's all true; disabling gmt_unix_time is by no means sufficient to
> make multiple TLS clients look the same on the wire, or to prevent an
> observer distinguishing TLS instances.
> 
> In Tor's case, we mitigate this by disabling some TLS features,
> specifying required values for others, rotating some identifiers more
> frequently than most implementations, and shipping all of our clients
> with the same crypto libraries.  Most of the fingerprinting issues in
> TLS can be ameliorated, for a single application, by defining a
> profile that all of that application's users should share.

I think that'd be a fine thing to document (and worthy of a
separate thread on the perpass list). Any chance we could get
that done? (Where "that" == document the implementation steps
to reduce fingerprinting opportunities as outlined above.)
I think it'd be really useful for folks doing other protocol
work to have an example of how its been done for Tor so they
could copy some of the relevant techniques when developing
other protocols. Ping me offlist if you'd like some help with
writing it up as an I-D and I can try find someone to help,
or if you've the energy just write it up and shoot it out
and I can help figure out how best to get it turned into an
RFC. If its already written up elsewhere then a pointer would
be good regardless.

Cheers,
S.

> 
> My issue here right now that, even *after* taking all these
> precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
> doesn't make it optional.  Come heck or high water, Tor is going to
> stop sending gmt_unix_time unless we find a really excellent reason to
> send it.  We'd like to replace it with the best alternative we can. I
> sent all the alternatives I could think of, because:
> 
>   1) I would like future versions of the TLS RFC to not require gmt_unix_time.
>   2) I would like to know whether there's a truly legit reason to send
> gmt_unx_time.
>   3) I would like to know the best thing to do instead of gmt_unix_time.
> 
> (The IP address issue is important too, but not overriding here. The
> issue here is that even after a client has changed its IP addresses
> either through moving around the network or going behind a NAT or VPN
> or by using an IP anonymization service, this fingerprint remains.)
> 

From pgut001@cs.auckland.ac.nz  Thu Sep 12 04:25:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377C211E8217; Thu, 12 Sep 2013 04:25:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Vx8d5CK7Jxs; Thu, 12 Sep 2013 04:25:07 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 98B6121E81E1; Thu, 12 Sep 2013 04:24:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1378985096; x=1410521096; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=MxTqlGTIFACzcPHvNyKAjNIxas0/xOu/uhqqMpS59gI=; b=Jr+xvggqAIqMiw6v9YIZUQ2r3NsiI8qqIB3z3EMx+kTBQaduzHyrd0FH OfJTVouYL1+91ZAuvB8DEOYLmOExmZB44EjbalKW3AACJn5t5QJKzn1ro Q+7PoMW93yVvWwdRtkhzXtGc3A3KVkn12fd+GYlHeXNeRb15TiWkihkxO Y=;
X-IronPort-AV: E=Sophos;i="4.90,890,1371038400"; d="scan'208";a="211785655"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 12 Sep 2013 23:24:49 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.187]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 23:24:49 +1200
From: Peter Gutmann 
To: Stephen Farrell , Nick Mathewson , "mrex@sap.com" , "perpass@ietf.org" , "tls@ietf.org" 
Thread-Topic: [TLS] [perpass]  Let's remove gmt_unix_time from TLS
Thread-Index: Ac6vqrCvzBRaStaeT72/wQJTAi/Ewg==
Date: Thu, 12 Sep 2013 11:24:48 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735566D9C3@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] [perpass]  Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 11:25:12 -0000

Stephen Farrell  writes:=0A=
=0A=
>(And that's a common pattern actually: someone says "if we do X that'll ma=
ke=0A=
>privacy a bit better" and someone else says "but there are so many other w=
ays=0A=
>to leak private info, why bother just doing X?")=0A=
=0A=
I've only partially seen it as a privacy issue but more as a security issue=
,=0A=
by telling an attacker that your clock is two weeks out you're letting them=
=0A=
know that they can reuse an expired cert or replay an old CRL.  Even in ter=
ms=0A=
of privacy it wasn't a specific user-tracking thing but more a question of =
why=0A=
you needed to tell the world what your system clock was set to.  So my code=
=0A=
has always populated the field with random noise, not an actual time.=0A=
=0A=
Peter.=0A=

From rob.stradling@comodo.com  Thu Sep 12 05:52:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FBD11E8113 for ; Thu, 12 Sep 2013 05:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6JVJWzvbWBL for ; Thu, 12 Sep 2013 05:52:01 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED8C11E8231 for ; Thu, 12 Sep 2013 05:52:00 -0700 (PDT)
Received: (qmail 26713 invoked from network); 12 Sep 2013 12:51:58 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 12 Sep 2013 12:51:58 -0000
Received: (qmail 9713 invoked by uid 1000); 12 Sep 2013 12:51:58 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 12 Sep 2013 13:51:58 +0100
Message-ID: <5231B8ED.7040301@comodo.com>
Date: Thu, 12 Sep 2013 13:51:57 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Simon Josefsson 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org>
In-Reply-To: <87fvtbi8ow.fsf@latte.josefsson.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 12:52:07 -0000

On 11/09/13 18:12, Simon Josefsson wrote:
> Rob Stradling  writes:
>
>> Simon, thanks for creating this draft.
>>
>> draft-merkle-tls-brainpool-04 (on which you've based this new draft) says:
>>     "While the ASN.1 object identifiers
>>     defined in [RFC5639] already allow usage of the ECC Brainpool curves
>>     for TLS (client or server) authentication through reference in X.509
>>     certificates according to [RFC3279] and [RFC5480] , their negotiation
>>     for key exchange according to [RFC4492] requires the definition and
>>     assignment of additional NamedCurve IDs."
>>
>> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it
>> to be used for key exchange.  But what about "(client or server)
>> authentication through reference in X.509 certificates..."?
>>
>> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
>> create one?  Or could we simply define some new ASN.1 Object
>> Identifiers in your draft?
>
> Yes perhaps.  What would the purpose of using Curve25519 in X.509
> certificates be?

I just thought it seemed like a logical thing to do.  We can already do 
ECDHE-ECDSA using the NIST curves for both keys in certs and for key 
exchange, so why wouldn't we allow Curve25519 to be used for both purposes?

Unless NIST can prove that their curves aren't backdoored, I think it's 
likely that some folks (rightly or wrongly) will want to do ECDHE-ECDSA 
without touching the NIST curves at all.  What options do they have?

> Performance is less critical there than for ECDH, but
> if you or someone else has numbers indicating X.509 signature
> verification being a performance bottle neck I would be convinced
> otherwise.  There could be other reasons than performance though, but
> they should be articulated and examined.

I don't have any performance figures, I'm afraid.

> RFC 5639 contains a lot of things, is there anything other than the OID
> and PKIX usage you think is relevant for Curve25519?

Pass.

> /Simon

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From ynir@checkpoint.com  Thu Sep 12 06:59:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C0911E8194 for ; Thu, 12 Sep 2013 06:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.768
X-Spam-Level: 
X-Spam-Status: No, score=-9.768 tagged_above=-999 required=5 tests=[AWL=0.830,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9hQ6HIapY6C for ; Thu, 12 Sep 2013 06:59:23 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA3611E8117 for ; Thu, 12 Sep 2013 06:59:00 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8CDwSGo006162; Thu, 12 Sep 2013 16:58:28 +0300
X-CheckPoint: {5231C884-15-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Thu, 12 Sep 2013 16:58:28 +0300
From: Yoav Nir 
To: Rob Stradling 
Thread-Topic: [TLS] Curve25519 in TLS
Thread-Index: AQHOrZiFYK+MfjUPYEadQ22tq6Y9cJm+c7uAgAJVsFaAARbTgIAAEpYA
Date: Thu, 12 Sep 2013 13:58:28 +0000
Message-ID: <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com>
In-Reply-To: <5231B8ED.7040301@comodo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.32]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Simon Josefsson , Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 13:59:42 -0000

On Sep 12, 2013, at 3:51 PM, Rob Stradling  wrote=
:

> On 11/09/13 18:12, Simon Josefsson wrote:
>> Rob Stradling  writes:
>>=20
>>> Simon, thanks for creating this draft.
>>>=20
>>> draft-merkle-tls-brainpool-04 (on which you've based this new draft) sa=
ys:
>>>    "While the ASN.1 object identifiers
>>>    defined in [RFC5639] already allow usage of the ECC Brainpool curves
>>>    for TLS (client or server) authentication through reference in X.509
>>>    certificates according to [RFC3279] and [RFC5480] , their negotiatio=
n
>>>    for key exchange according to [RFC4492] requires the definition and
>>>    assignment of additional NamedCurve IDs."
>>>=20
>>> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it
>>> to be used for key exchange.  But what about "(client or server)
>>> authentication through reference in X.509 certificates..."?
>>>=20
>>> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
>>> create one?  Or could we simply define some new ASN.1 Object
>>> Identifiers in your draft?
>>=20
>> Yes perhaps.  What would the purpose of using Curve25519 in X.509
>> certificates be?
>=20
> I just thought it seemed like a logical thing to do.  We can already do E=
CDHE-ECDSA using the NIST curves for both keys in certs and for key exchang=
e, so why wouldn't we allow Curve25519 to be used for both purposes?
>=20
> Unless NIST can prove that their curves aren't backdoored, I think it's l=
ikely that some folks (rightly or wrongly) will want to do ECDHE-ECDSA with=
out touching the NIST curves at all.  What options do they have?

Umm, the brainpool curves are available.

Also, I don't get why performance would be less critical than that of ECDHE=
. In a full handshake, you do both an ECDSA signature and the ECDHE operati=
ons. Why would one matter while the other does not?

Yoav


From dbrown@certicom.com  Thu Sep 12 07:44:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DCD11E81B1 for ; Thu, 12 Sep 2013 07:44:22 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.996
X-Spam-Level: 
X-Spam-Status: No, score=-3.996 tagged_above=-999 required=5 tests=[AWL=-1.397, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpGu7J1aDRTY for ; Thu, 12 Sep 2013 07:44:17 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8B011E8117 for ; Thu, 12 Sep 2013 07:44:17 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============0611908570=="
MIME-Version: 1.0
Received: from xct102cnc.rim.net ([10.65.161.202]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Sep 2013 10:44:10 -0400
Received: from XCT104CNC.rim.net (10.65.161.204) by XCT102CNC.rim.net (10.65.161.202) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 12 Sep 2013 10:44:10 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT104CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 10:44:10 -0400
From: Dan Brown 
To: "'rob.stradling@comodo.com'" , "'simon@josefsson.org'" 
Thread-Topic: [TLS] Curve25519 in TLS
Thread-Index: AQHOrZh+TZFlKeLBp0isVQ+VLxKJXJm+6ROAgAHgS7KAAYw5gP//2uyw
Date: Thu, 12 Sep 2013 14:44:09 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BCFD3C@XMB116CNC.rim.net>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org>	<522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com>
In-Reply-To: <5231B8ED.7040301@comodo.com>
Accept-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.250]
MIME-Version: 1.0
Cc: "'code@funwithsoftware.org'" , "'tls@ietf.org'" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 14:44:22 -0000

--===============0611908570==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0016_01CEAFA5.030D21E0"

------=_NextPart_000_0016_01CEAFA5.030D21E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit



> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Rob Stradling
> Sent: Thursday, September 12, 2013 8:52 AM
> 
> Unless NIST can prove that their curves aren't backdoored, I think it's

[DB] Five NIST curves are Koblitz curves, which are not backdoored.

> likely that some folks (rightly or wrongly) will want to do ECDHE-ECDSA
> without touching the NIST curves at all.  What options do they have?
> 

[DB] Koblitz curves.

------=_NextPart_000_0016_01CEAFA5.030D21E0
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw
ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l
dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz
WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu
ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy
czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH
jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH
An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw
CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME
AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww
FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6
MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu
YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw
U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp
b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp
bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH
MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0
RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG
KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R
BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN
o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2
ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg
k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G
Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC
BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB
GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN
Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ
FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D
QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna
iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp
yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg
Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3
mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq
6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN
9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh
vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr
UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0
hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG
AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW
aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov
Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k
b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j
UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu
cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ
KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2
fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf
+ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi
fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9
aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8
rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ
jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog
dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s
FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z
bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD
ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx
EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT
dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx
jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV
mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X
Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa
99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p
036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w
HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE
AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe
CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg
MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys
Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz
LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp
b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew
MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu
Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy
MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp
Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG
Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93
cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB
AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK
PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f
aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG
E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6
xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2
6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k
q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg
jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0
KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts
MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt
MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D
AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTEy
MTQ0NDA5WjAjBgkqhkiG9w0BCQQxFgQUus9kgRIV8lfl/NCEjwskSgPfZm0wZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw
EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi
b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR
BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv
cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgCpljyEOD/pE
QJjj+Z44Dm/FlFAgOmZhz//WsDAYNnr+FwGEu9nHt/B9A3RHiWyekBw9TnsZLYpWB0UqTbffbwYI
/nhXDysdScjfI8A1SqpD9vzZZUrIk67MHHmdPucof5jNzJ1d1Ie4MFhKGHNb4ikP71fFxga0BFJ0
llo6dng4AAAAAAAA

------=_NextPart_000_0016_01CEAFA5.030D21E0--

--===============0611908570==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
--===============0611908570==--

From lists@drh-consultancy.co.uk  Thu Sep 12 08:51:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8882021E8119 for ; Thu, 12 Sep 2013 08:51:37 -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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qovHrdc21FPM for ; Thu, 12 Sep 2013 08:51:33 -0700 (PDT)
Received: from claranet-outbound-smtp05.uk.clara.net (claranet-outbound-smtp05.uk.clara.net [195.8.89.38]) by ietfa.amsl.com (Postfix) with ESMTP id AF6B321E80D8 for ; Thu, 12 Sep 2013 08:51:29 -0700 (PDT)
Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:49213 helo=[192.168.7.9]) by relay05.mail.eu.clara.net (relay.clara.net [213.253.3.45]:10465) with esmtpa (authdaemon_plain:drh) id 1VK9Ar-0004mi-GD  (return-path ); Thu, 12 Sep 2013 15:51:19 +0000
Message-ID: <5231E2F2.6050302@drh-consultancy.co.uk>
Date: Thu, 12 Sep 2013 16:51:14 +0100
From: Dr Stephen Henson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Adam Langley 
References:  <52306269.7020200@drh-consultancy.co.uk> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 15:51:38 -0000

On 11/09/2013 15:08, Adam Langley wrote:
> 
> I would like to support only ECDHE-ECDSA at this point but RSA has
> significant inertia because of the CA system. On reflection, it does
> seem reasonable that some implementations might not want the weight of
> an ECC implementation given that they have to have
> multiplicative-modexp for RSA anyway. So I've spun version -01 with
> with a DHE_RSA ciphersuite too.
> 

Thanks. Some organisations are also ultra cautious about possible ECC patent
issues and wont use it at all.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From SRS0=BU/0=SY=acm.org=bmoeller@srs.kundenserver.de  Thu Sep 12 10:41:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B0B21E81F6 for ; Thu, 12 Sep 2013 10:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level: 
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdwvZZrsPQ6U for ; Thu, 12 Sep 2013 10:41:45 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 7B0E421E8151 for ; Thu, 12 Sep 2013 10:41:45 -0700 (PDT)
Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M2ndG-1WCPc603mQ-00svBw; Thu, 12 Sep 2013 19:41:44 +0200
Received: by mail-oa0-f44.google.com with SMTP id l17so136429oag.3 for ; Thu, 12 Sep 2013 10:41:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=EGEyqMX43T9RG8mttJHLp5hSgAORn7VTzCuKXqZ7VfE=; b=XkqFxpOFcanZAuSckpCNDphpO/yktVFEc2N2JLa7Q+xpvUQRhcdfUdsAn2y1l1nBVE uXNQwzrhPaUPffyiqWTi8LcN8uN7GE96ozEXZPYTjBrCzDDLUDOoQdpwFOJ4Igc3mDQd CPo2F/cek6RDZsoXDpyHnhQiDAxiIlbRk4y0iXaWbKlbnl/JQpFAHRohYCiMpqId3ZVF kgwNMiKgdzl4nW1kttTe3yqaCVU7q5sY6d5myNKzJcwqbi5LxBn2KK4OTmWaRfJddTC/ 3GTrQMLPMreKZXXdw7PgvjERhwi5PdHvovdfu2VAV2/2KfxuZpHxLe52fDBN8MPODmZf QaOg==
MIME-Version: 1.0
X-Received: by 10.60.43.131 with SMTP id w3mr7937004oel.10.1379007702782; Thu, 12 Sep 2013 10:41:42 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 12 Sep 2013 10:41:42 -0700 (PDT)
In-Reply-To: <810C31990B57ED40B2062BA10D43FBF5BCFD3C@XMB116CNC.rim.net>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <810C31990B57ED40B2062BA10D43FBF5BCFD3C@XMB116CNC.rim.net>
Date: Thu, 12 Sep 2013 19:41:42 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113346ce445cf404e633401d
X-Provags-ID: V02:K0:rL8/wvD/gA5A5WbBooM0R3s8u8IqcmqJB/sJoDX+ZU/ Hgg6XHFxJiBVX7Yua++zq2EKiF4ss4yAw/31XGd8lZtFeRhoaj nWP+BKSIdDfX2QqKcplNhXB9ZjKTc71QyJ+/ql13Q/htWOgljd DSW/7AXkjdWdtm5LU83Vp5IJ3bwx9O7t4TpA9Ekc1BhKXJF2Aa Tculb59PUUFc79oHLwPxyJUEle5x1eqvwZ0NW6SwvRvzNApc+H s3rBUawtH53SHXHQP6STXcFbdqliM22aa+TAWxE+tdU83FxSA6 mYgEEeS1uwOUmlLGRinSwwxAozklQwqIlWdWzV7yC+bemzZ96b 8FSb5dxMFyoqmfUc6pcAH+XWm8pJQV4wAY9Q3fqMuESaRp1jQM hVhMpbP8LIHSMeAMi7ENfXavh32Nkp3VNP/aJAIrFKEjDpHd4J yCxb0
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 17:44:33 -0000

--001a113346ce445cf404e633401d
Content-Type: text/plain; charset=ISO-8859-1

> > Unless NIST can prove that their curves aren't backdoored, I think it's
>


> [DB] Five NIST curves are Koblitz curves, which are not backdoored.
>

Personally I don't expect any of the NIST curves to be backdoored, but I
don't agree with the reasoning (which I've seen elsewhere before) that if
you have doubts about the pseudorandom NIST urves due to their unexplained
seeds, the NIST Koblitz curves are less suspect because that degree of
freedom is missing.

I won't repeat here why I'm not actually worried about the pseudorandom
curves (I don't think I could add anything to your and Douglas Stebila's
arguments in the thread "Testing consensus for adding curve25519 to the EC
named curve registry"). Now *if* one assumes that there's a (thin-spread
but non-negligible) class of weak curves among them (so that the seeds
could have been chosen to create backdoors), why would it be more
far-fetched to assume that the class of Koblitz curves is weak *in its
entirety*?  After all, these particular curves are known to have extra
structure by design!

Bodo

--001a113346ce445cf404e633401d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=




> Unless NIST can prove that their curves aren't backdoored, I think=
 it's
=A0




[DB] Five NIST curves are Koblitz curves, which are not backdoored.

Personally I don't expect any of the=
 NIST curves to be backdoored, but I don't agree with the reasoning (wh=
ich I've seen elsewhere before) that if you have doubts about the pseud=
orandom NIST urves due to their unexplained seeds, the NIST Koblitz curves =
are less suspect because that degree of freedom is missing.



I won't repeat here why I=
9;m not actually worried about the pseudorandom curves (I don't think I=
 could add anything to your and Douglas Stebila's arguments in the thre=
ad "Testing consensus for adding curve25519 to the EC named curve regi=
stry"). Now *if* one assumes that there's a (thin-spread but non-n=
egligible) class of weak curves among them (so that the seeds could have be=
en chosen to create backdoors), why would it be more far-fetched to assume =
that the class of Koblitz curves is weak *in its entirety*? =A0After all, t=
hese particular curves are known to have extra structure by design!



Bodo
<=
div class=3D"gmail_extra">



--001a113346ce445cf404e633401d--

From dbrown@certicom.com  Thu Sep 12 12:01:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA811E80F4 for ; Thu, 12 Sep 2013 12:01:19 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -3.53
X-Spam-Level: 
X-Spam-Status: No, score=-3.53 tagged_above=-999 required=5 tests=[AWL=-0.931,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbf6f0pH4uMb for ; Thu, 12 Sep 2013 12:01:06 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 248CF11E81D2 for ; Thu, 12 Sep 2013 12:00:33 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============0918104646=="
MIME-Version: 1.0
Received: from xct103cnc.rim.net ([10.65.161.203]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 12 Sep 2013 15:00:15 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT103CNC.rim.net ([fe80::b8:d5e:26a5:f4d6%17]) with mapi id 14.03.0123.003; Thu, 12 Sep 2013 15:00:14 -0400
From: Dan Brown 
To: "'bmoeller@acm.org'" , "'tls@ietf.org'" 
Thread-Topic: Koblitz curves [was RE: [TLS] Curve25519 in TLS]
Thread-Index: AQHOrZh+TZFlKeLBp0isVQ+VLxKJXJm+6ROAgAHgS7KAAYw5gP//2uywgAB2CQD//8J2IA==
Date: Thu, 12 Sep 2013 19:00:14 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BCFEEE@XMB116CNC.rim.net>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org>	<522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org>	<5231B8ED.7040301@comodo.com> <810C31990B57ED40B2062BA10D43FBF5BCFD3C@XMB116CNC.rim.net> 
In-Reply-To: 
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.250]
MIME-Version: 1.0
Subject: [TLS] Koblitz curves [was RE:  Curve25519 in TLS]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 19:01:19 -0000

--===============0918104646==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_00E5_01CEAFC8.C9229590"

------=_NextPart_000_00E5_01CEAFC8.C9229590
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_00E6_01CEAFC8.C9229590"


------=_NextPart_001_00E6_01CEAFC8.C9229590
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Bodo,

 

Aside: maybe discussion like this should move to CFRG, because its
generality could affect other WGs, and its theoretical what-if nature may
not interest many in TLS WG.  For now, I just changed the subject line.

 

To briefly recap: some people hypothesize (a) existence of an undisclosed
weak curve classes and (b) authorities pushing curves, via seed searches,
into the weak class.  Koblitz curves resist (b).  You said you do not
believe (b).  You raised the point again that Koblitz curves may be hit by
(a) alone.  (I tried to raise this point (a) for Koblitz curves, in the
other thread, noting them to be special, just like Curve25519.) I have said
before Koblitz curves provide evidence against (b) else: Why place a
backdoor on one curve, but not another? My argument was a little vague on
this point, so I will try to clarify it first

 

You are quite right that if Koblitz fall to a different version of (a), then
(b) would remain viable backdoor mechanism for the VR curves, because now
all NIST curves would be weak.  This event essentially presumes two
undisclosed weak classes of curves (or one, which contains both the Koblitz
curves and the all VR curves).  In other words, it assumes a larger class of
weak curves, so it is more unlikely.  It is more far-fetched, albeit only
slightly so.  And everything here is hypothetical, remember. 

 

Ignoring (b) completely is another hypothesis worthy of consideration.  In
this case, a highly informal argument that Koblitz are less likely than VR
curves to be affected by (a) is that the Koblitz curves slightly pre-date
the VR curves, and by virtue of their simple coefficients, are more amenable
to inspirational analysis.  Put another way, the VR curve coefficients are
not easy for a person to manipulate.  So, any human research efforts could
have targeted Koblitz but not VR curves.  Also, research efforts just to
find arbitrary weak classes of curves could be viewed as unlikely of hitting
a VR curve, and thus be viewed as having less incentive (exception: strong
believers in (b) would be much more likely to believe in a weak class
containing the VR curves).  So, it seems, at least to me, the fact that
Koblitz have would have been subjected to more effort, or at least more
incentive. (Indeed, your intuition, which is that a weak class is more
likely to include Koblitz, is an instance of researchers seeing Koblitz
curves as more likely target to achieve research success.)  From the lack of
published attacks, we can infer a lower probability of an undisclosed
attack, because there may be a greater number of samples: attempts to
discover such a class.  But then again, the Suite B VR curves may also
received quite a bit of scrutiny too.

 

Best regards,

 

Dan

 

 

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Bodo
Moeller
Sent: Thursday, September 12, 2013 1:42 PM
To: tls@ietf.org
Subject: Re: [TLS] Curve25519 in TLS

 

 

> Unless NIST can prove that their curves aren't backdoored, I think it's

 

[DB] Five NIST curves are Koblitz curves, which are not backdoored.

 

Personally I don't expect any of the NIST curves to be backdoored, but I
don't agree with the reasoning (which I've seen elsewhere before) that if
you have doubts about the pseudorandom NIST urves due to their unexplained
seeds, the NIST Koblitz curves are less suspect because that degree of
freedom is missing.

 

I won't repeat here why I'm not actually worried about the pseudorandom
curves (I don't think I could add anything to your and Douglas Stebila's
arguments in the thread "Testing consensus for adding curve25519 to the EC
named curve registry"). Now *if* one assumes that there's a (thin-spread but
non-negligible) class of weak curves among them (so that the seeds could
have been chosen to create backdoors), why would it be more far-fetched to
assume that the class of Koblitz curves is weak *in its entirety*?  After
all, these particular curves are known to have extra structure by design!

 

Bodo

 

 


------=_NextPart_001_00E6_01CEAFC8.C9229590
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hi Bodo,
 
Aside: maybe discussion like this should move to CFRG, because its =
generality could affect other WGs, and its theoretical what-if nature =
may not interest many in TLS WG.  For now, I just changed the =
subject line.
 
To briefly recap: some people hypothesize (a) existence of an =
undisclosed weak curve classes and (b) authorities pushing curves, via =
seed searches, into the weak class.  Koblitz curves resist =
(b).  You said you do not believe (b).  You raised the point =
again that Koblitz curves may be hit by (a) alone.  (I tried to =
raise this point (a) for Koblitz curves, in the other thread, noting =
them to be special, just like Curve25519.) I have said before Koblitz =
curves provide evidence against (b) else: Why place a backdoor on one =
curve, but not another? My argument was a little vague on this point, so =
I will try to clarify it first
 
You are quite right that if Koblitz fall to a different version of =
(a), then (b) would remain viable backdoor mechanism for the VR curves, =
because now all NIST curves would be weak.  This event essentially =
presumes two undisclosed weak classes of curves (or one, which contains =
both the Koblitz curves and the all VR curves).  In other words, it =
assumes a larger class of weak curves, so it is more unlikely.  It =
is more far-fetched, albeit only slightly so.  And everything here =
is hypothetical, remember. 
 
Ignoring (b) completely is another hypothesis worthy of =
consideration.  In this case, a highly informal argument that =
Koblitz are less likely than VR curves to be affected by (a) is that the =
Koblitz curves slightly pre-date the VR curves, and by virtue of their =
simple coefficients, are more amenable to inspirational analysis.  =
Put another way, the VR curve coefficients are not easy for a person to =
manipulate.  So, any human research efforts could have targeted =
Koblitz but not VR curves.  Also, research efforts just to find =
arbitrary weak classes of curves could be viewed as unlikely of hitting =
a VR curve, and thus be viewed as having less incentive (exception: =
strong believers in (b) would be much more likely to believe in a weak =
class containing the VR curves).  So, it seems, at least to me, the =
fact that Koblitz have would have been subjected to more effort, or at =
least more incentive. (Indeed, your intuition, which is that a weak =
class is more likely to include Koblitz, is an instance of researchers =
seeing Koblitz curves as more likely target to achieve research =
success.)  From the lack of published attacks, we can infer a lower =
probability of an undisclosed attack, because there may be a greater =
number of samples: attempts to discover such a class.  But then =
again, the Suite B VR curves may also received quite a bit of scrutiny =
too.
 
Best regards,
 
Dan
 
 
From:=
 =
tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of =
Bodo Moeller
Sent: Thursday, September 12, 2013 1:42 =
PM
To: tls@ietf.org
Subject: Re: [TLS] Curve25519 in =
TLS
 
 
> =
Unless NIST can prove that their curves aren't backdoored, I think =
it's
 
[DB] Five =
NIST curves are Koblitz curves, which are not =
backdoored.
 
Personally I don't expect any of the NIST curves to be =
backdoored, but I don't agree with the reasoning (which I've seen =
elsewhere before) that if you have doubts about the pseudorandom NIST =
urves due to their unexplained seeds, the NIST Koblitz curves are less =
suspect because that degree of freedom is =
missing.
 
I =
won't repeat here why I'm not actually worried about the pseudorandom =
curves (I don't think I could add anything to your and Douglas Stebila's =
arguments in the thread "Testing consensus for adding curve25519 to =
the EC named curve registry"). Now *if* one assumes that there's a =
(thin-spread but non-negligible) class of weak curves among them (so =
that the seeds could have been chosen to create backdoors), why would it =
be more far-fetched to assume that the class of Koblitz curves is weak =
*in its entirety*?  After all, these particular curves are known to =
have extra structure by design!
 
Bodo
 
 

------=_NextPart_001_00E6_01CEAFC8.C9229590--

------=_NextPart_000_00E5_01CEAFC8.C9229590
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw
ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l
dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz
WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu
ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy
czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH
jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH
An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw
CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME
AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww
FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6
MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu
YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw
U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp
b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp
bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH
MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0
RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG
KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R
BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN
o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2
ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg
k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G
Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC
BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB
GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN
Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ
FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D
QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna
iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp
yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg
Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3
mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq
6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN
9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh
vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr
UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0
hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG
AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW
aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov
Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k
b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j
UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu
cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ
KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2
fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf
+ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi
fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9
aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8
rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ
jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog
dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s
FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z
bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD
ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx
EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT
dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx
jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV
mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X
Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa
99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p
036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w
HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE
AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe
CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg
MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys
Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz
LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp
b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew
MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu
Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy
MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp
Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG
Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93
cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB
AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK
PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f
aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG
E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6
xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2
6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k
q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg
jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0
KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts
MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt
MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D
AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTEy
MTkwMDE0WjAjBgkqhkiG9w0BCQQxFgQUgvhHlYky2mbOkSP5/B7RHaqNRLIwZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw
EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi
b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR
BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv
cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgDsAI2ZF+nu5
U4ZkV3nD6mu+P+MMc87IQt59Oerad00uhjVIS+D70egB9YxK4Uw1R+aEi6VcQzyLtCj5B0SxCIlh
0322N5ogz+TxarSAAriSd5DG17pWK0kVdQ4Rjo7nfq5nzxPP45QKBdnQ2j3hlvSHUcNpKXu24T6e
+n1d8TInAAAAAAAA

------=_NextPart_000_00E5_01CEAFC8.C9229590--

--===============0918104646==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
--===============0918104646==--

From rob.stradling@comodo.com  Thu Sep 12 12:04:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB4B021F9DCB for ; Thu, 12 Sep 2013 12:04:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DA7vOvnkkA0f for ; Thu, 12 Sep 2013 12:04:33 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id E723221E8205 for ; Thu, 12 Sep 2013 12:04:27 -0700 (PDT)
Received: (qmail 8338 invoked from network); 12 Sep 2013 19:04:26 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 12 Sep 2013 19:04:26 -0000
Received: (qmail 26352 invoked by uid 1000); 12 Sep 2013 19:04:26 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 12 Sep 2013 20:04:26 +0100
Message-ID: <52321039.9060503@comodo.com>
Date: Thu, 12 Sep 2013 20:04:25 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com>
In-Reply-To: <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson , Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 19:04:39 -0000

On 12/09/13 14:58, Yoav Nir wrote:
> On Sep 12, 2013, at 3:51 PM, Rob Stradling  wrote:
>> On 11/09/13 18:12, Simon Josefsson wrote:

>>> Yes perhaps.  What would the purpose of using Curve25519 in X.509
>>> certificates be?
>>
>> I just thought it seemed like a logical thing to do.  We can already do ECDHE-ECDSA using the NIST curves for both keys in certs and for key exchange, so why wouldn't we allow Curve25519 to be used for both purposes?
>>
>> Unless NIST can prove that their curves aren't backdoored, I think it's likely that some folks (rightly or wrongly) will want to do ECDHE-ECDSA without touching the NIST curves at all.  What options do they have?
>
> Umm, the brainpool curves are available.

Yes, and the brainpool curves are also available for key exchange.

So why bother making curve25519 available for key exchange?

> Also, I don't get why performance would be less critical than that of ECDHE. In a full handshake, you do both an ECDSA signature and the ECDHE operations. Why would one matter while the other does not?

+1

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From simon@josefsson.org  Thu Sep 12 13:42:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3CB11E8249 for ; Thu, 12 Sep 2013 13:42:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTJ8dl9JgN7p for ; Thu, 12 Sep 2013 13:42:35 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 9D86A11E810B for ; Thu, 12 Sep 2013 13:42:34 -0700 (PDT)
Received: from [10.71.1.57] ([38.111.151.140]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8CKg3pg013578 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 12 Sep 2013 22:42:07 +0200
User-Agent: K-9 Mail for Android
In-Reply-To: <52321039.9060503@comodo.com>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com> <52321039.9060503@comodo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Simon Josefsson 
Date: Thu, 12 Sep 2013 13:41:56 -0700
To: Rob Stradling , Yoav Nir 
Message-ID: <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com>
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 20:42:35 -0000

Rob Stradling  skrev:
>On 12/09/13 14:58, Yoav Nir wrote:
>> On Sep 12, 2013, at 3:51 PM, Rob Stradling 
>wrote:
>>> On 11/09/13 18:12, Simon Josefsson wrote:
>
>>>> Yes perhaps.  What would the purpose of using Curve25519 in X.509
>>>> certificates be?
>>>
>>> I just thought it seemed like a logical thing to do.  We can already
>do ECDHE-ECDSA using the NIST curves for both keys in certs and for key
>exchange, so why wouldn't we allow Curve25519 to be used for both
>purposes?
>>>
>>> Unless NIST can prove that their curves aren't backdoored, I think
>it's likely that some folks (rightly or wrongly) will want to do
>ECDHE-ECDSA without touching the NIST curves at all.  What options do
>they have?
>>
>> Umm, the brainpool curves are available.
>
>Yes, and the brainpool curves are also available for key exchange.
>
>So why bother making curve25519 available for key exchange?

For performance reasons?  It is more efficient.

/Simon
>
>> Also, I don't get why performance would be less critical than that of
>ECDHE. In a full handshake, you do both an ECDSA signature and the
>ECDHE operations. Why would one matter while the other does not?
>
>+1


From rob.stradling@comodo.com  Thu Sep 12 13:57:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EADD321E808E for ; Thu, 12 Sep 2013 13:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koq+tVeLrOR0 for ; Thu, 12 Sep 2013 13:57:27 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id AFB1411E80AD for ; Thu, 12 Sep 2013 13:57:11 -0700 (PDT)
Received: (qmail 18765 invoked from network); 12 Sep 2013 20:57:08 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 12 Sep 2013 20:57:08 -0000
Received: (qmail 9814 invoked by uid 1000); 12 Sep 2013 20:57:08 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 12 Sep 2013 21:57:08 +0100
Message-ID: <52322AA3.4080503@comodo.com>
Date: Thu, 12 Sep 2013 21:57:07 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Simon Josefsson 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com> <52321039.9060503@comodo.com> <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com>
In-Reply-To: <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 20:57:36 -0000

On 12/09/13 21:41, Simon Josefsson wrote:

>>> Umm, the brainpool curves are available.
>>
>> Yes, and the brainpool curves are also available for key exchange.
>>
>> So why bother making curve25519 available for key exchange?
>
> For performance reasons?  It is more efficient.

So then...

>>> Also, I don't get why performance would be less critical than that of
>> ECDHE. In a full handshake, you do both an ECDSA signature and the
>> ECDHE operations. Why would one matter while the other does not?

...it sounds like it does make sense, for performance reasons, to allow 
Curve25519 (or Ed25519, presumably) to be used for keys in certs too.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From nico@cryptonector.com  Thu Sep 12 14:12:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C00B111E822F for ; Thu, 12 Sep 2013 14:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.927
X-Spam-Level: 
X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsaQiHaM1NYG for ; Thu, 12 Sep 2013 14:12:49 -0700 (PDT)
Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id D222B11E813B for ; Thu, 12 Sep 2013 14:12:49 -0700 (PDT)
Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id DB30242807A for ; Thu, 12 Sep 2013 14:12:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=LW7kih1ASUld6W02CKh8 p7IGAHw=; b=LeqtuBk+Dzc5s4W9EblVAM4BHUo1enbeuXju7VsFDAGTA5d4iQgq NMs2aKrzpl53lS2FGgd8JsidAQ5pR5ub5uNXGu77CyhXdRPGYpkslBhJNbHHLFy/ wYa5SLOkOi4hoXY9/AlfpcF7b0Lld0zA62v+rC6PN9Spj6Bo+3/LSxY=
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 1BC5B428075 for ; Thu, 12 Sep 2013 14:12:42 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w62so360412wes.15 for ; Thu, 12 Sep 2013 14:12:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sg/db+Qzm6KzkCK9WalD1SmwfiLcUnvk66yuZ1nK8qs=; b=hL9Cs8yb4kcwcMOiY6qNMWKNDbBn5SOh5OrYA8eaeMmHeI/m8sBLM7dkX9UOIopt2K MjHGpkOffBhNo5bKG7od/nXRnhuYRXPNhK0Qu6RLSQN+9K4drGqV6plKwTWg9I364UAu wiMQjkToWls9oMWSP8wsLWArGNgTdxRXnL0R9kzg8zfun8K4DFMPMVwKYBf3LbMLVQJ0 b2I7ql2SqvCTNR0Ao+XpajHG/LI2OSDQY7oFunhhIYolRr2xSMseogE3ph+JI2FjFlkW ltBGTTNJ3uVS5JS/1r4DJNqr6mFViyGdUQzymlO4cB0sT6Eo7pNHhU4xe0FO4srkm5K7 ZEag==
MIME-Version: 1.0
X-Received: by 10.180.206.244 with SMTP id lr20mr7505994wic.45.1379020361698;  Thu, 12 Sep 2013 14:12:41 -0700 (PDT)
Received: by 10.216.240.70 with HTTP; Thu, 12 Sep 2013 14:12:41 -0700 (PDT)
In-Reply-To: <52322AA3.4080503@comodo.com>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com> <52321039.9060503@comodo.com> <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com> <52322AA3.4080503@comodo.com>
Date: Thu, 12 Sep 2013 16:12:41 -0500
Message-ID: 
From: Nico Williams 
To: Rob Stradling 
Content-Type: text/plain; charset=UTF-8
Cc: Simon Josefsson , Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 21:12:54 -0000

On Thu, Sep 12, 2013 at 3:57 PM, Rob Stradling  wrote:
> On 12/09/13 21:41, Simon Josefsson wrote:
>>> So why bother making curve25519 available for key exchange?
>>
>> For performance reasons?  It is more efficient.
>
> So then...
>
> ...it sounds like it does make sense, for performance reasons, to allow
> Curve25519 (or Ed25519, presumably) to be used for keys in certs too.

Yes.

Of course, in practice it's much easier to deploy new ECDH curves for
key agreement than new signature algorithms because the former are
easily negotiated in actual protocols, while the latter are less so.
But, yes.

Nico
--

From turners@ieca.com  Thu Sep 12 14:54:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB5711E8134 for ; Thu, 12 Sep 2013 14:54:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id is4Yt7dS0R9P for ; Thu, 12 Sep 2013 14:54:28 -0700 (PDT)
Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [70.85.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5642111E8197 for ; Thu, 12 Sep 2013 14:54:28 -0700 (PDT)
Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 06A8B3E9A6FD6; Thu, 12 Sep 2013 16:53:27 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id DFD503E9A6F7F for ; Thu, 12 Sep 2013 16:53:26 -0500 (CDT)
Received: from [96.231.225.44] (port=62773 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VKEqH-0007Um-IJ for tls@ietf.org; Thu, 12 Sep 2013 16:54:25 -0500
Message-ID: <52323810.3020905@ieca.com>
Date: Thu, 12 Sep 2013 17:54:24 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: <20130912213246.25227.45009.idtracker@ietfa.amsl.com>
In-Reply-To: <20130912213246.25227.45009.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130912213246.25227.45009.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [96.231.225.44]:62773
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 7
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Subject: [TLS] Fwd: Last Call:  (AES-CCM ECC Cipher Suites for TLS) to Informational RFC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Sep 2013 21:54:36 -0000

FYI ...


-------- Original Message --------
Subject: Last Call:  (AES-CCM ECC 
Cipher Suites for TLS) to Informational RFC
Date: Thu, 12 Sep 2013 14:32:46 -0700
From: The IESG 
Reply-To: ietf@ietf.org
To: IETF-Announce 


The IESG has received a request from an individual submitter to consider
the following document:
- 'AES-CCM ECC Cipher Suites for TLS'
    as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


    This memo describes the use of the Advanced Encryption Standard (AES)
    in the Counter and CBC-MAC Mode (CCM) of operation within Transport
    Layer Security (TLS) to provide confidentiality and data origin
    authentication.  The AES-CCM algorithm is amenable to compact
    implementations, making it suitable for constrained environments.
    The ciphersuites defined in this document use Elliptic Curve
    Cryptography (ECC), and are advantageous in networks with limited
    bandwidth.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm-ecc/ballot/


The following IPR Declarations may be related to this I-D:

    http://datatracker.ietf.org/ipr/1352/
    http://datatracker.ietf.org/ipr/1443/







From rob.stradling@comodo.com  Fri Sep 13 02:27:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B52021E8097 for ; Fri, 13 Sep 2013 02:27:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fbodmglnSRH for ; Fri, 13 Sep 2013 02:27:41 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 118A821F89A5 for ; Fri, 13 Sep 2013 02:27:39 -0700 (PDT)
Received: (qmail 7754 invoked from network); 13 Sep 2013 09:27:37 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Sep 2013 09:27:37 -0000
Received: (qmail 15517 invoked by uid 1000); 13 Sep 2013 09:27:37 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 13 Sep 2013 10:27:37 +0100
Message-ID: <5232DA89.8090000@comodo.com>
Date: Fri, 13 Sep 2013 10:27:37 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nico Williams 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com> <52321039.9060503@comodo.com> <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com> <52322AA3.4080503@comodo.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson , Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Sep 2013 09:27:47 -0000

On 12/09/13 22:12, Nico Williams wrote:

> Of course, in practice it's much easier to deploy new ECDH curves for
> key agreement than new signature algorithms because the former are
> easily negotiated in actual protocols, while the latter are less so.

Disagree, I think.  Doesn't the "Supported Elliptic Curves Extension" 
make it easy enough for TLS?

RFC4492 (Section 5.3) says:
   "If the client has used a
    Supported Elliptic Curves Extension, the public key in the server's
    certificate MUST respect the client's choice of elliptic curves;"

So if a TLS Client advertises support for Simon's proposed Curve25519 
NamedCurve, then surely that Client is implying that it supports both 
Curve25519 for key exchange _and_ Curve25519 keys in certs?

> But, yes.
>
> Nico
> --

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online


From p.j.bakker@offspark.com  Fri Sep 13 02:45:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E052421F9E6B for ; Fri, 13 Sep 2013 02:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAiYu6KtbIrt for ; Fri, 13 Sep 2013 02:45:46 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 282DE21F9E5B for ; Fri, 13 Sep 2013 02:45:46 -0700 (PDT)
Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VKPqq-0006x3-AG; Fri, 13 Sep 2013 11:39:44 +0200
From: "Paul Bakker" 
To: "'Rob Stradling'" , "'Nico Williams'" 
References: 	<522D25B9.7010506@funwithsoftware.org>	<56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au>	<87zjrl21wp.fsf_-_@latte.josefsson.org>	<522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org>	<5231B8ED.7040301@comodo.com>	<9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com>	<52321039.9060503@comodo.com>	<5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com>	<52322AA3.4080503@comodo.com>	 <5232DA89.8090000@comodo.com>
In-Reply-To: <5232DA89.8090000@comodo.com>
Date: Fri, 13 Sep 2013 11:45:33 +0200
Message-ID: <02be01ceb066$00b83cb0$0228b610$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQF+hyNKgY88m1ZujYYD6edFPqeJKQIqcoOeAt6xqG4B2Z5cqgHcfQ+ZAcPDkyoB/D4HyAJDyPCKAoDfsvsB5MSjywI9HwvmAsxMgAMCMuWhqZmQlY2Q
Content-Language: nl
X-SA-Exim-Connect-IP: 82.161.132.220
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Cc: 'Simon Josefsson' , 'Patrick Pelletier' , tls@ietf.org
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Sep 2013 09:45:51 -0000

> On 12/09/13 22:12, Nico Williams wrote:
> 
> > Of course, in practice it's much easier to deploy new ECDH curves for
> > key agreement than new signature algorithms because the former are
> > easily negotiated in actual protocols, while the latter are less so.
> 
> Disagree, I think.  Doesn't the "Supported Elliptic Curves Extension"
> make it easy enough for TLS?
> 
> RFC4492 (Section 5.3) says:
>    "If the client has used a
>     Supported Elliptic Curves Extension, the public key in the server's
>     certificate MUST respect the client's choice of elliptic curves;"
> 
> So if a TLS Client advertises support for Simon's proposed Curve25519
> NamedCurve, then surely that Client is implying that it supports both
> Curve25519 for key exchange _and_ Curve25519 keys in certs?

I think what Nico means is that the ServerKeyExchange message allows for the
TLS protocol to handle yet-unnamed curves for key-exchange with any client
(that properly handles them).
(http://tools.ietf.org/html/rfc4492#section-5.4)

For the "Supported Elliptic Curves Extension" to 'work' you need the client
to know about the curve beforehand. It has to be named already.
Thus deployment is harder as client actually need to be upgraded.

Regards,
Paul Bakker


From ynir@checkpoint.com  Fri Sep 13 07:10:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A076811E80F1 for ; Fri, 13 Sep 2013 07:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.861
X-Spam-Level: 
X-Spam-Status: No, score=-9.861 tagged_above=-999 required=5 tests=[AWL=0.738,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVaMMkAuJCdn for ; Fri, 13 Sep 2013 07:10:37 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1E50411E80EA for ; Fri, 13 Sep 2013 07:10:36 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8DEA2pT013035; Fri, 13 Sep 2013 17:10:07 +0300
X-CheckPoint: {52331CBA-19-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Fri, 13 Sep 2013 17:10:02 +0300
From: Yoav Nir 
To: Rob Stradling 
Thread-Topic: [TLS] Curve25519 in TLS
Thread-Index: AQHOrZiFYK+MfjUPYEadQ22tq6Y9cJm+c7uAgAJVsFaAARbTgIAAEpYAgABVe4CAABs/AIAABD6AgAAEWYCAAM1XgIAATuoA
Date: Fri, 13 Sep 2013 14:10:01 +0000
Message-ID: <9DCF45B3-84DA-4228-8752-3EA8761B4BDE@checkpoint.com>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com> <52321039.9060503@comodo.com> <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com> <52322AA3.4080503@comodo.com>  <5232DA89.8090000@comodo.com>
In-Reply-To: <5232DA89.8090000@comodo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.240]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Patrick Pelletier , "tls@ietf.org" , Simon Josefsson 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Sep 2013 14:10:43 -0000

On Sep 13, 2013, at 12:27 PM, Rob Stradling  wrot=
e:

> On 12/09/13 22:12, Nico Williams wrote:
> 
>> Of course, in practice it's much easier to deploy new ECDH curves for
>> key agreement than new signature algorithms because the former are
>> easily negotiated in actual protocols, while the latter are less so.
>=20
> Disagree, I think.  Doesn't the "Supported Elliptic Curves Extension" mak=
e it easy enough for TLS?

No, because the key that I use is the private key that matches the public k=
ey in the certificate I got from some vendor. If I got a certificate with t=
he NIST P-256 curve, I can't use the Curve25519 signatures. I can only use =
the NIST P-256 curve, because that is what is in my certificate. For ECDHE =
I can support multiple curves.

This also affects the CAs. They can't deploy certificates with Curve25519 u=
nless all browsers support those curves, so in reality, only the NIST curve=
s are currently viable for signatures.

Yoav


From rob.stradling@comodo.com  Fri Sep 13 15:37:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BABC11E81B4 for ; Fri, 13 Sep 2013 15:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW0Oc9tXg5rc for ; Fri, 13 Sep 2013 15:37:40 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1D211E81A0 for ; Fri, 13 Sep 2013 15:37:39 -0700 (PDT)
Received: (qmail 11431 invoked from network); 13 Sep 2013 22:37:36 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 13 Sep 2013 22:37:36 -0000
Received: (qmail 1292 invoked by uid 1000); 13 Sep 2013 22:37:36 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Fri, 13 Sep 2013 23:37:36 +0100
Message-ID: <523393B0.40508@comodo.com>
Date: Fri, 13 Sep 2013 23:37:36 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <87fvtbi8ow.fsf@latte.josefsson.org> <5231B8ED.7040301@comodo.com> <9330004B-0BC3-4EDB-91EE-5BA14A4A6CEF@checkpoint.com> <52321039.9060503@comodo.com> <5050f932-9321-449a-be2d-0ad8b667f2f2@email.android.com> <52322AA3.4080503@comodo.com>  <5232DA89.8090000@comodo.com> <9DCF45B3-84DA-4228-8752-3EA8761B4BDE@checkpoint.com>
In-Reply-To: <9DCF45B3-84DA-4228-8752-3EA8761B4BDE@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Patrick Pelletier , "tls@ietf.org" , Simon Josefsson 
Subject: Re: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Sep 2013 22:37:51 -0000

On 13/09/13 15:10, Yoav Nir wrote:
>
> On Sep 13, 2013, at 12:27 PM, Rob Stradling  wrote:
>
>> On 12/09/13 22:12, Nico Williams wrote:
>> 
>>> Of course, in practice it's much easier to deploy new ECDH curves for
>>> key agreement than new signature algorithms because the former are
>>> easily negotiated in actual protocols, while the latter are less so.
>>
>> Disagree, I think.  Doesn't the "Supported Elliptic Curves Extension" make it easy enough for TLS?
>
> No, because the key that I use is the private key that matches the public key in the certificate I got from some vendor. If I got a certificate with the NIST P-256 curve, I can't use the Curve25519 signatures. I can only use the NIST P-256 curve, because that is what is in my certificate. For ECDHE I can support multiple curves.

Sure.

> This also affects the CAs. They can't deploy certificates with Curve25519 unless all browsers support those curves,

Disagree.  If only one browser signals support for the Curve25519 
NamedCurve in the "Supported Elliptic Curves Extension", then (suitably 
enhanced) servers could send Curve25519/Ed25519 certs to this browser 
and RSA/DSA/P-256/whatever certs to other browsers.

> so in reality, only the NIST curves are currently viable for signatures.

Agreed, but I'm thinking about the future.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From pgut001@cs.auckland.ac.nz  Fri Sep 13 21:03:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCAB21F8F67 for ; Fri, 13 Sep 2013 21:03:47 -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=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CcvSLjpXf1S for ; Fri, 13 Sep 2013 21:03:42 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4A121F8EC3 for ; Fri, 13 Sep 2013 21:03:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379131416; x=1410667416; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0Uc3TR+hEvhqUpK4XNsyv3cohIXD+d748ROoKf0kGGI=; b=mxCnXMW7o6C/MEJX0HrPnpa4KVxO0K84P/1L/l3ic4N8QCDD2FJtdvnW 5u4rnhReomAk69OTi27B1XpQxFktjy91Wix47Np8ZB9F5iF7600TPDclT 9xX7ZUPK+1EUu9AWtHKnoNYKJQCRzRYOGF41JrQKjyQpXpUQUM3ORO00n E=;
X-IronPort-AV: E=Sophos;i="4.90,902,1371038400"; d="scan'208";a="212029011"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 14 Sep 2013 16:03:32 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 14 Sep 2013 16:03:31 +1200
From: Peter Gutmann 
To: "TLS@ietf.org (tls@ietf.org)" 
Thread-Topic: DHE-PSK interop testing
Thread-Index: Ac6w/2ArhtbBRxiTStGrVd/Y5pkidQ==
Date: Sat, 14 Sep 2013 04:03:31 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73556716B5@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [TLS] DHE-PSK interop testing
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Sep 2013 04:03:47 -0000

Does anyone have a test server running that implements the DHE-PSK suites?=
=0A=
I've never actually tested my implementation against anything (for lack of=
=0A=
anything to test against), but it'd probably be a good idea to test it agai=
nst=0A=
someone else's code.=0A=
=0A=
Peter.=0A=

From p.j.bakker@offspark.com  Fri Sep 13 23:23:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D499811E80D1 for ; Fri, 13 Sep 2013 23:23:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.47
X-Spam-Level: 
X-Spam-Status: No, score=-0.47 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMVMzGKwZ-mS for ; Fri, 13 Sep 2013 23:23:55 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 413B921F93BA for ; Fri, 13 Sep 2013 23:23:50 -0700 (PDT)
Received: from ip54507da9.speed.planet.nl ([84.80.125.169] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VKjAx-0001Yx-MO; Sat, 14 Sep 2013 08:17:48 +0200
From: "Paul Bakker" 
To: "'Peter Gutmann'" , "'TLS@ietf.org'" 
References: <9A043F3CF02CD34C8E74AC1594475C73556716B5@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73556716B5@uxcn10-6.UoA.auckland.ac.nz>
Date: Sat, 14 Sep 2013 08:23:38 +0200
Message-ID: <002c01ceb112$f616f370$e244da50$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFfuiuCD5BAtZzeWojcTz85E/5hvJqisWIA
Content-Language: nl
X-SA-Exim-Connect-IP: 84.80.125.169
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Subject: Re: [TLS] DHE-PSK interop testing
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 14 Sep 2013 06:23:59 -0000

Yeah. I'll mail you the details off the list.

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Peter
> Gutmann
> Sent: zaterdag 14 september 2013 6:04
> To: TLS@ietf.org (tls@ietf.org)
> Subject: [TLS] DHE-PSK interop testing
> 
> Does anyone have a test server running that implements the DHE-PSK
> suites?
> I've never actually tested my implementation against anything (for lack of
> anything to test against), but it'd probably be a good idea to test it
against
> someone else's code.
> 
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From yaronf.ietf@gmail.com  Sun Sep 15 12:11:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C8411E8198 for ; Sun, 15 Sep 2013 12:11:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9rxTQng9+nHm for ; Sun, 15 Sep 2013 12:11:23 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 86EDB11E8192 for ; Sun, 15 Sep 2013 12:11:23 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id m14so1591134eaj.6 for ; Sun, 15 Sep 2013 12:11:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=gL80D3oE6NP8yQg0R7VwVNb5L7fJ7sO/8MZGGp8YE9I=; b=ICatv3EiINuf7JLpl+Jh0ftZOaamTl9KUMgah8tofr+0oyHzSRG+FIuorP1sRNDLZ5 s6JirWo29657DN138+t1EpNPUwE4xeYn4Aoj6ll/09N8giR2keU+Sdo6qUTMKPClUq/u 85nuVToE9UxR4jZUxJg03Ostz6zs84xbI26z73PUBfdGk++6C49Ig1fubQXAD6eT/zmt HVCVfZf0wQnt8H/01fw24n6wra7XL6xrMG8gb521Q6VwVZJWQ3n5vdSUsAlyWGnTFIRE 0tbUb63nHcdR4aPW64zmOK1Hvg0GtGtcN/hrSEqQIMMXetaWMLGX8vHR/ENlY5dqP5J5 VnMg==
X-Received: by 10.14.180.73 with SMTP id i49mr4899189eem.55.1379272282605; Sun, 15 Sep 2013 12:11:22 -0700 (PDT)
Received: from [10.0.0.8] (bzq-79-181-201-37.red.bezeqint.net. [79.181.201.37]) by mx.google.com with ESMTPSA id n48sm35369925eeg.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 12:11:22 -0700 (PDT)
Message-ID: <52360658.7050203@gmail.com>
Date: Sun, 15 Sep 2013 22:11:20 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list 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, 15 Sep 2013 19:11:25 -0000

Hi,

I've been working with Ralph Holz on -01, and we would like the group's 
opinion before we publish.

Several people proposed that we recommend parameter lengths for RSA and 
for Diffie Hellman. RSA is easy enough, and we will recommend 2048 bits. 
The situation with DH is extremely messy, and if we're not careful, we 
might actually hurt security by recommending a reasonable parameter length!

Basic facts and assumptions:

- Brute force difficulty is similar for RSA and DH parameters of the 
same length.
- When using DHE, the TLS master key depends on the DH exchange only, 
and the certificate size doesn't matter.
- 1024 bit DH (or RSA) is still very common, but is too weak to 
recommend for the next few years.

We would like to recommend using 2048-bit DH by both client and server 
(maybe 1536 bits for performance, but for sure not 1024). But reading 
[1] and similar posts, this could have two undesirable consequences.

1. Some older clients will break (abort the negotiation) if they offer 
DHE, the server accepts it but sends a DH value whose length they don't 
support (e.g. higher than 1024). You might end up with a non-TLS 
connection or a 404, rather than the client retrying with no DHE.

2. New clients will follow our recommendation and offer DHE, but then 
will only receive 1024-bit DH parameters from (an older) server and will 
end up negotiating a weaker session than they would have negotiated if 
they'd avoided DHE, if the server happens to use 2048-bit RSA. (Yes, 
whether this is "weaker" depends on your threat model).

Problem #1 goes away if we say that the server only sends 2048-bit DH 
parameters to "new" clients (those that offer TLS 1.2), and assume these 
can all deal with DH of any length. Our draft recommends a TLS 1.2-only 
cipher suite anyway. And since new clients are still rare, this could work.

This partial solution is complicated by IE10, which (AFAIK) supports TLS 
1.2, but has this support off by default, and does not support larger 
than 1024-bit DH.

Problem #2 is mitigated if we suggest that clients fall back to non-DHE 
if the server cert is long enough, specifically to 
TLS_RSA_WITH_AES_128_GCM_SHA256. That is, if the client doesn't like the 
returned DH parameters, it aborts the session and re-negotiates it 
instead of choosing the 1024-bit DH option.

This extra logic is ugly. But if we cannot recommend >1024 DH, we may be 
better off giving up on PFS for now. Long term, I believe that TLS 
should negotiate DH explicitly.

Your thoughts, opinions and even facts :-) are most welcome.

     Yaron

[1] 
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

From ynir@checkpoint.com  Sun Sep 15 12:56:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6EB11E81B6 for ; Sun, 15 Sep 2013 12:56:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.124
X-Spam-Level: 
X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id co14lSEGOqD2 for ; Sun, 15 Sep 2013 12:56:33 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D24FC11E81B4 for ; Sun, 15 Sep 2013 12:56:32 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8FJuG8I025924; Sun, 15 Sep 2013 22:56:16 +0300
X-CheckPoint: {523610E0-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.173]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sun, 15 Sep 2013 22:56:15 +0300
From: Yoav Nir 
To: Yaron Sheffer 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: AQHOskdo5dKKYJ0xmEuWRIX4Ztx5/ZnHBG8A
Date: Sun, 15 Sep 2013 19:56:15 +0000
Message-ID: 
References: <52360658.7050203@gmail.com>
In-Reply-To: <52360658.7050203@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.71]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6D3D5DA76C92FC4C93E7752960852EED@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list 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, 15 Sep 2013 19:56:38 -0000

Hi, Yaron

Why do we need to give up on PFS? There are ECDHE ciphersuites that are sup=
ported by nearly all browsers as well as well as OpenSSL (which means also =
Apache), IIS and others. Connect from any browser other than Opera to a Goo=
gle server, and you'll be using a ECDHE-RSA ciphersuite.

So why do we need to give up on PFS?

Also, you are right that it depends on your threat model, but I think under=
 most reasonable threat models, it's easier to steal a long-term private ke=
y (even if it's 2048-bit) than to calculate a discrete log in a 1024-bit gr=
oup. Even harder to calculate a discrete log once for each session (it is e=
phemeral D-H), than to steal a single private key that is stored on a hard =
disk for at least a year.=20

So no, I don't think we should give up of PFS.

Yoav

On Sep 15, 2013, at 10:11 PM, Yaron Sheffer  wrote:

> Hi,
>=20
> I've been working with Ralph Holz on -01, and we would like the group's o=
pinion before we publish.
>=20
> Several people proposed that we recommend parameter lengths for RSA and f=
or Diffie Hellman. RSA is easy enough, and we will recommend 2048 bits. The=
 situation with DH is extremely messy, and if we're not careful, we might a=
ctually hurt security by recommending a reasonable parameter length!
>=20
> Basic facts and assumptions:
>=20
> - Brute force difficulty is similar for RSA and DH parameters of the same=
 length.
> - When using DHE, the TLS master key depends on the DH exchange only, and=
 the certificate size doesn't matter.
> - 1024 bit DH (or RSA) is still very common, but is too weak to recommend=
 for the next few years.
>=20
> We would like to recommend using 2048-bit DH by both client and server (m=
aybe 1536 bits for performance, but for sure not 1024). But reading [1] and=
 similar posts, this could have two undesirable consequences.
>=20
> 1. Some older clients will break (abort the negotiation) if they offer DH=
E, the server accepts it but sends a DH value whose length they don't suppo=
rt (e.g. higher than 1024). You might end up with a non-TLS connection or a=
 404, rather than the client retrying with no DHE.
>=20
> 2. New clients will follow our recommendation and offer DHE, but then wil=
l only receive 1024-bit DH parameters from (an older) server and will end u=
p negotiating a weaker session than they would have negotiated if they'd av=
oided DHE, if the server happens to use 2048-bit RSA. (Yes, whether this is=
 "weaker" depends on your threat model).
>=20
> Problem #1 goes away if we say that the server only sends 2048-bit DH par=
ameters to "new" clients (those that offer TLS 1.2), and assume these can a=
ll deal with DH of any length. Our draft recommends a TLS 1.2-only cipher s=
uite anyway. And since new clients are still rare, this could work.
>=20
> This partial solution is complicated by IE10, which (AFAIK) supports TLS =
1.2, but has this support off by default, and does not support larger than =
1024-bit DH.
>=20
> Problem #2 is mitigated if we suggest that clients fall back to non-DHE i=
f the server cert is long enough, specifically to TLS_RSA_WITH_AES_128_GCM_=
SHA256. That is, if the client doesn't like the returned DH parameters, it =
aborts the session and re-negotiates it instead of choosing the 1024-bit DH=
 option.
>=20
> This extra logic is ugly. But if we cannot recommend >1024 DH, we may be =
better off giving up on PFS for now. Long term, I believe that TLS should n=
egotiate DH explicitly.
>=20
> Your thoughts, opinions and even facts :-) are most welcome.
>=20
>    Yaron
>=20
> [1] http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.=
html
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From stephen.farrell@cs.tcd.ie  Sun Sep 15 13:04:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61B11E81C3 for ; Sun, 15 Sep 2013 13:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj5S0J0UYRH9 for ; Sun, 15 Sep 2013 13:04:50 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id CC35211E81C1 for ; Sun, 15 Sep 2013 13:04:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F07F4BE70; Sun, 15 Sep 2013 21:04:47 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zZ+pKexfpzKg; Sun, 15 Sep 2013 21:04:47 +0100 (IST)
Received: from [10.87.48.11] (unknown [86.41.59.233]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0D394BE6E; Sun, 15 Sep 2013 21:04:47 +0100 (IST)
Message-ID: <523612DE.9010901@cs.tcd.ie>
Date: Sun, 15 Sep 2013 21:04:46 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir 
References: <52360658.7050203@gmail.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list 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, 15 Sep 2013 20:04:55 -0000

On 09/15/2013 08:56 PM, Yoav Nir wrote:
> So no, I don't think we should give up of PFS.

+1024 :-)

S.

From yaronf.ietf@gmail.com  Sun Sep 15 14:16:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EC111E81D7 for ; Sun, 15 Sep 2013 14:16:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.442
X-Spam-Level: 
X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN-ukL7HCWgz for ; Sun, 15 Sep 2013 14:16:11 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 90C4111E81D5 for ; Sun, 15 Sep 2013 14:16:10 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id m15so2940996wgh.33 for ; Sun, 15 Sep 2013 14:16:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8J6D9kiwB0GaIAP9GpY9NCY/srlXiYTzO/vIom9WfTI=; b=Xa+0EQac8YCDBU7Ijl7EF0REv0fteYUz+/NyJj/RkzjuKydRQXD8TRqpmNqqYqxJls JgEmntW5hCvFGZW4u+WNzaUe9gswSnDFQlpih6jXFLL37KS7+m6G1iRn445D+EI2exlJ zN+02xgDxB0yDXsPpj9cnGhl0Y6jfDwb0vZUStRgv9P0ZeljaNeqYbcGJi2Wn/eBZKi9 3pEWYKb3U/oRGBCQVH+O5dkKPlaOR+SK7LwOxA/JufmHUxUZ6bDFcDwyes9tfvRFz5iL xdN6Kqa8FMtbxJWjbQ2XWAwSgfOZBhA3FD9XeJn5FG02Bcizi9tyJ3sqoIQxOcDqQYg7 tQcQ==
X-Received: by 10.180.106.40 with SMTP id gr8mr10732778wib.11.1379279769657; Sun, 15 Sep 2013 14:16:09 -0700 (PDT)
Received: from [10.0.0.8] (bzq-79-181-201-37.red.bezeqint.net. [79.181.201.37]) by mx.google.com with ESMTPSA id dx7sm18982341wib.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Sep 2013 14:16:09 -0700 (PDT)
Message-ID: <52362397.3080609@gmail.com>
Date: Mon, 16 Sep 2013 00:16:07 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir 
References: <52360658.7050203@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list 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, 15 Sep 2013 21:16:11 -0000

Hi Yoav,

ECDH groups are negotiated using RFC 4492 extensions, which surely makes 
them more usable today, and allows for crypto-agility in the future.

There are worries about the way the NIST curves were generated. AFAIU, 
most everybody uses P-256. Currently this is plain FUD, no-one can say 
whether and how you can backdoor ECDH if you control generation of the 
curves. But you can bet this research topic has suddenly become very 
popular.

If we assume that the adversary hoards millions of terabytes of network 
traffic for later decryption, perhaps in 10 years, then we need to worry 
about the strength of the curves we recommend today.

I guess for the time being we could recommend ECDHE with P-256, 
migrating later to a verifiably random curve like Brainpool.

Thanks,
	Yaron



On 09/15/2013 10:56 PM, Yoav Nir wrote:
> Hi, Yaron
>
> Why do we need to give up on PFS? There are ECDHE ciphersuites that are supported by nearly all browsers as well as well as OpenSSL (which means also Apache), IIS and others. Connect from any browser other than Opera to a Google server, and you'll be using a ECDHE-RSA ciphersuite.
>
> So why do we need to give up on PFS?
>
> Also, you are right that it depends on your threat model, but I think under most reasonable threat models, it's easier to steal a long-term private key (even if it's 2048-bit) than to calculate a discrete log in a 1024-bit group. Even harder to calculate a discrete log once for each session (it is ephemeral D-H), than to steal a single private key that is stored on a hard disk for at least a year.
>
> So no, I don't think we should give up of PFS.
>
> Yoav
>
> On Sep 15, 2013, at 10:11 PM, Yaron Sheffer  wrote:
>
>> Hi,
>>
>> I've been working with Ralph Holz on -01, and we would like the group's opinion before we publish.
>>
>> Several people proposed that we recommend parameter lengths for RSA and for Diffie Hellman. RSA is easy enough, and we will recommend 2048 bits. The situation with DH is extremely messy, and if we're not careful, we might actually hurt security by recommending a reasonable parameter length!
>>
>> Basic facts and assumptions:
>>
>> - Brute force difficulty is similar for RSA and DH parameters of the same length.
>> - When using DHE, the TLS master key depends on the DH exchange only, and the certificate size doesn't matter.
>> - 1024 bit DH (or RSA) is still very common, but is too weak to recommend for the next few years.
>>
>> We would like to recommend using 2048-bit DH by both client and server (maybe 1536 bits for performance, but for sure not 1024). But reading [1] and similar posts, this could have two undesirable consequences.
>>
>> 1. Some older clients will break (abort the negotiation) if they offer DHE, the server accepts it but sends a DH value whose length they don't support (e.g. higher than 1024). You might end up with a non-TLS connection or a 404, rather than the client retrying with no DHE.
>>
>> 2. New clients will follow our recommendation and offer DHE, but then will only receive 1024-bit DH parameters from (an older) server and will end up negotiating a weaker session than they would have negotiated if they'd avoided DHE, if the server happens to use 2048-bit RSA. (Yes, whether this is "weaker" depends on your threat model).
>>
>> Problem #1 goes away if we say that the server only sends 2048-bit DH parameters to "new" clients (those that offer TLS 1.2), and assume these can all deal with DH of any length. Our draft recommends a TLS 1.2-only cipher suite anyway. And since new clients are still rare, this could work.
>>
>> This partial solution is complicated by IE10, which (AFAIK) supports TLS 1.2, but has this support off by default, and does not support larger than 1024-bit DH.
>>
>> Problem #2 is mitigated if we suggest that clients fall back to non-DHE if the server cert is long enough, specifically to TLS_RSA_WITH_AES_128_GCM_SHA256. That is, if the client doesn't like the returned DH parameters, it aborts the session and re-negotiates it instead of choosing the 1024-bit DH option.
>>
>> This extra logic is ugly. But if we cannot recommend >1024 DH, we may be better off giving up on PFS for now. Long term, I believe that TLS should negotiate DH explicitly.
>>
>> Your thoughts, opinions and even facts :-) are most welcome.
>>
>>     Yaron
>>
>> [1] http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>

From mike-list@pobox.com  Sun Sep 15 14:21:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7349811E81DE for ; Sun, 15 Sep 2013 14:21:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MHW4ac6sPs6 for ; Sun, 15 Sep 2013 14:21:14 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 1757911E81C6 for ; Sun, 15 Sep 2013 14:21:13 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0F576DF4B; Sun, 15 Sep 2013 17:21:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=4jCcsVre+cv7 nSxpKQheklTcUiw=; b=DviyXAQ1quwXBPwPN6HYhCuzuKiBNUZBS5qsgPrETr+V p6/oL0KyTw3RcQ9Pr6z+vmFarOc2F82I9/T+xAfphLC8znZourr43McHgw/EVGO0 9KvegcDBYMnh0wveT7aGtpraMTgTNO1Q0ySc1UP7oQPQckuJn1i/B9j+gG+Nofg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=HikRDM kgUGnl6XohrxCM3cs9ThJQ48C50gDwxKpxtGtNJVtZVCOqDjgZj/LifmUOzlmrMv rU+2QSc+akpyLuBiFNJVx+R0Yamp+Z0PoEmxQA3BMEje+RAWJbv4CspqgAUkeiOi 7e/nLPNFLyAA2YeeHfuDrZFYehwDbMTkozsDo=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 06729DF4A; Sun, 15 Sep 2013 17:21:12 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4C082DF49; Sun, 15 Sep 2013 17:21:11 -0400 (EDT)
Message-ID: <523624C6.8050006@pobox.com>
Date: Sun, 15 Sep 2013 14:21:10 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Stephen Farrell 
References: <52360658.7050203@gmail.com>	 <523612DE.9010901@cs.tcd.ie>
In-Reply-To: <523612DE.9010901@cs.tcd.ie>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: BE9F5B2E-1E4C-11E3-997F-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list 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, 15 Sep 2013 21:21:24 -0000

DH can be sped up if you incorporate a medium-sized (e.g.
256-bit) prime q into the parameters.  See for example
Cryptography Engineering, pages 187-188.  Since q is
missing from the signed ServerDHParams, adding it would
require an extension.

We all know how hard it is to new get extensions deployed,
but perhaps there's now sufficient incentive....

Mike


Stephen Farrell wrote:
> 
> On 09/15/2013 08:56 PM, Yoav Nir wrote:
>> So no, I don't think we should give up of PFS.
> 
> +1024 :-)
> 
> S.

From code@funwithsoftware.org  Mon Sep 16 00:55:53 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D3421F9123 for ; Mon, 16 Sep 2013 00:55:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level: 
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_05=-1.11]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGTzTHEW9-1O for ; Mon, 16 Sep 2013 00:55:46 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id D84E511E8102 for ; Mon, 16 Sep 2013 00:55:45 -0700 (PDT)
Received: from mail1.sea5.speakeasy.net (mail1.sea5.speakeasy.net [69.17.117.39]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id A02001EE53AD for ; Mon, 16 Sep 2013 03:55:36 -0400 (EDT)
Received: (qmail 7524 invoked from network); 16 Sep 2013 07:55:36 -0000
Received: by simscan 1.4.0 ppid: 28287, pid: 17416, t: 1.2115s scanners: clamav: m:
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail1.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 16 Sep 2013 07:55:35 -0000
Message-ID: <5236B975.9040808@funwithsoftware.org>
Date: Mon, 16 Sep 2013 00:55:33 -0700
From: Patrick Pelletier 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: tls@ietf.org
References: <52360658.7050203@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 07:55:53 -0000

On 9/15/13 12:56 PM, Yoav Nir wrote:

> There are ECDHE ciphersuites that are supported by nearly all browsers as well as well as OpenSSL (which means also Apache), IIS and others.

Supported in the source, sure.  But Red Hat will disable it when it 
builds packages:

https://bugzilla.redhat.com/show_bug.cgi?id=319901

--Patrick


From xuelei.fan@vimino.com  Mon Sep 16 03:43:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543F211E80FD for ; Mon, 16 Sep 2013 03:43:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPX42vcrWe5b for ; Mon, 16 Sep 2013 03:43:15 -0700 (PDT)
Received: from mail-pd0-f169.google.com (mail-pd0-f169.google.com [209.85.192.169]) by ietfa.amsl.com (Postfix) with ESMTP id BD44A11E80FE for ; Mon, 16 Sep 2013 03:43:13 -0700 (PDT)
Received: by mail-pd0-f169.google.com with SMTP id r10so3983173pdi.28 for ; Mon, 16 Sep 2013 03:43:13 -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=pdtrZh8vUakilqIpUbXwRRbCjLxe2dQzhBhEP/NtuQ0=; b=dkDCp3tWESWOqfxTInmCnl1RsU9s1s6/KIaK0caZHvzGu+tEa3zEZq4rRUyQe7xwoE NALEB9oP9UQwhqIhVaBJ0zvk3yaenDv0kQ5QBpkIiB2ioZ/hYWBbHQW+IgZ5o5acb4P5 79bdlnZMQ9thbjMkzYRVvV74aTxunEN/MIZoV3KL5BRHiVfOkDk1JCr5OeuVBw2dn6Gm RxmMCOE0RLpW9/UJ8QWRZMX0IPcOr7+uGsKyXpjQBswi84ErDzzkE4itcKaPAR8QhCzf hrFmBtB8bY/XFN2IcqlJuDhDBsJyGGcjdFXyVrlzh3gKOqjleZ+/iE+ITziDI0uXEPl/ RZ9w==
X-Gm-Message-State: ALoCoQlr4miUu49foohmQ99w7MLLml6GJscCaD2b60bjnhpXStfiJl0TS/dXWR1RXvRgRP1knDJK
X-Received: by 10.68.162.194 with SMTP id yc2mr2001535pbb.141.1379328193463; Mon, 16 Sep 2013 03:43:13 -0700 (PDT)
Received: from [192.168.1.105] ([124.64.63.103]) by mx.google.com with ESMTPSA id bb1sm30344937pbc.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 03:43:12 -0700 (PDT)
Message-ID: <5236E0BD.3090903@Vimino.COM>
Date: Mon, 16 Sep 2013 18:43:09 +0800
From: Xuelei Fan 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Michael D'Errico 
References: <52360658.7050203@gmail.com>	 <523612DE.9010901@cs.tcd.ie> <523624C6.8050006@pobox.com>
In-Reply-To: <523624C6.8050006@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 10:43:21 -0000

It's another worry that there is no way to negotiate the ephemeral DH 
key size.  A robust client may have to support 756/1024/1536/2048-bit 
keys. And a wildly deployed server may have to always use the wildly 
supported DH key sizes, for example 1024-bit, in order to server more 
clients.  If we want a new extension for ephemeral DH keys, it would be 
nice to support ephemeral DH key size negotiation.

Xuelei

On 9/16/2013 5:21 AM, Michael D'Errico wrote:
> DH can be sped up if you incorporate a medium-sized (e.g.
> 256-bit) prime q into the parameters.  See for example
> Cryptography Engineering, pages 187-188.  Since q is
> missing from the signed ServerDHParams, adding it would
> require an extension.
>
> We all know how hard it is to new get extensions deployed,
> but perhaps there's now sufficient incentive....
>
> Mike
>
>
> Stephen Farrell wrote:
>>
>> On 09/15/2013 08:56 PM, Yoav Nir wrote:
>>> So no, I don't think we should give up of PFS.
>>
>> +1024 :-)
>>
>> S.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From mrex@sap.com  Mon Sep 16 14:17:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E602511E81C8 for ; Mon, 16 Sep 2013 14:17:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.063
X-Spam-Level: 
X-Spam-Status: No, score=-10.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxF6KY8bEu6v for ; Mon, 16 Sep 2013 14:17:27 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9073911E81BE for ; Mon, 16 Sep 2013 14:17:27 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8GLHPqZ016735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 16 Sep 2013 23:17:25 +0200 (MEST)
In-Reply-To: <52360658.7050203@gmail.com>
To: Yaron Sheffer 
Date: Mon, 16 Sep 2013 23:17:25 +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: <20130916211725.6E5E21A971@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 16 Sep 2013 21:17:33 -0000

Yaron Sheffer wrote:
> 
> Problem #1 goes away if we say that the server only sends 2048-bit DH 
> parameters to "new" clients (those that offer TLS 1.2), and assume these 
> can all deal with DH of any length. Our draft recommends a TLS 1.2-only 
> cipher suite anyway. And since new clients are still rare, this could work.
> 
> This partial solution is complicated by IE10, which (AFAIK) supports TLS 
> 1.2, but has this support off by default, and does not support larger 
> than 1024-bit DH.

IE10 is an awkward way to refer to an implementation.
What matters is what Microsoft's SChannel from the underlying OS supports.
And Microsoft seems to not support DHE with RSA
(only DHE_DSA, ECDHE_RSA and ECDHE_ECDSA).


Windows 7 & 2008R2 
http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx 

Windows Vista & 2008:
http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx

Windows XP & 2003
http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx



-Martin

From juraj.somorovsky@rub.de  Mon Sep 16 15:47:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4D711E8105 for ; Mon, 16 Sep 2013 15:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeqzRByPHcUg for ; Mon, 16 Sep 2013 15:47:30 -0700 (PDT)
Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id 4A36711E8106 for ; Mon, 16 Sep 2013 15:47:29 -0700 (PDT)
X-Queued: (qmail 20846 invoked by alias); 16 Sep 2013 22:47:28 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 20779 invoked by uid 108); 16 Sep 2013 22:47:27 -0000
X-Qmailscanner: from 134.147.42.227 by mx6.rz.ruhr-uni-bochum.de (envelope-from , uid 102) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88.   Clear:RC:1(134.147.42.227):.  Processed in 0.060924 secs); 16 Sep 2013 22:47:27 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx6.rz.ruhr-uni-bochum.de with SMTP; 16 Sep 2013 22:47:27 -0000
X-Queued: (qmail 30565 invoked by uid 992); 16 Sep 2013 22:47:27 -0000
X-Qmailscanner: from 178.201.6.234 (7Cil8M2CiUx4WqKSFE7Ynw==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de (envelope-from , uid 0) with qmail-scanner-2.01  (sophie: 3.06/3.45.0/4.91.  Clear:RC:1(178.201.6.234):.  Processed in 0.033144 secs); 16 Sep 2013 22:47:27 -0000
Received: from ip-178-201-6-234.unitymediagroup.de (HELO ?192.168.0.103?) (7Cil8M2CiUx4WqKSFE7Ynw==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 16 Sep 2013 22:47:27 -0000
Date: 17 Sep 2013 00:47:03 +0200
Message-ID: <52378A67.9010903@rub.de>
From: "Juraj Somorovsky" 
To: "Michael StJohns" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References: <522955BC.8000407@nthpermutation.com>
In-Reply-To: <522955BC.8000407@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 22:47:36 -0000

Hi Mike,

On 09/06/2013 06:10 AM, Michael StJohns wrote:
> That still leaves a second problem.  The "key expansion" stage produces
> both private (key material) and public (iv data) by producing a key
> stream and then splitting up (based on the sizes of keys needed) into
> the 4 keys and 2 IVs.
> 
> o Consider  an application that needs to produce 2 128 bit AES keys and
> 2 IVs (for say GCM).
> o Consider that an attacker (or a hacked program that's being used to
> extract keys) re-runs the derivation using the same master key and same
> random data, this time specifying zero length keys (or 64 bits of keys
> etc), but still asks for the IV material.
> 
Just a quick questions:
I do not know if I understand this scenario correctly...but how can this
be achieved in TLS?
New key/IV material is always generated from client's as well as
server's random. The attacker can choose the same client random, but he
cannot influence the server random... thus always new key/IV material is
generated.

Maybe in a PKCS11 scenario this is different?
> The part of the key stream previously assigned to the encryption keys is
> now assigned to the IV material.  Since IVs by their nature are public,
> the attacker now has direct access to the key material previously used
> for encryption.
> 
> Fortunately, TLS1.1 changed the way IVs were calculated making it
> possible to prohibit that leaking.  Unfortunately, the CCM and GCM
> mechanisms for TLS1.2 decided to use the IV values making impossible to
> prohibit the leaking.
> 
> For the current PKCS11 draft, we finessed it by creating two mechanisms
> - one that created only key material, and one that created key material
> and IVs.  PKCS11 allows a specific key to be constrained to a specific
> mechanism so that permits some security for the non-AEAD suites.  It's
> not ideal, but its a beginning
I would propose to make it more concrete for PKCS11 and generate the
keys depending on the algorithms they are used in. For example, if you
have a master_secret used to generate keys for AES_GCM and AES_CBC, you
would use:
k_GCM = PRF(master_secret, "AES_GCM", [further params])
k_CBC = PRF(master_secret, "AES_CBC", [further params])

This ensures that the attacker cannot enforce the same key is used for
two different algorithms, which could lead to some specific attacks (for
more information see our paper on Backwards compatibility attacks:
http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/)

Best Regards
Juraj

From msj@nthpermutation.com  Mon Sep 16 16:37:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C7F11E814F for ; Mon, 16 Sep 2013 16:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R3FWrC3CJl1v for ; Mon, 16 Sep 2013 16:37:40 -0700 (PDT)
Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id ED35711E8151 for ; Mon, 16 Sep 2013 16:37:34 -0700 (PDT)
Received: by mail-oa0-f41.google.com with SMTP id i4so637335oah.0 for ; Mon, 16 Sep 2013 16:37:27 -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=Ck5GNLcVoRav7R4UC2Ajoe5DqK/kC5lS2jrXITN/9Yw=; b=lSYFB5nia7VzHHZ88jJEmMzFHixTWQCJmrlbLZIQKIG/uqhsgyDth/wRWAohccmxuc 0DS1TyNv0cuMLwTj4np0P7W3+Xgc0Y5kyNxjY8FqGNB7wytzuwuplCa4UzAoVjQbNp7+ 4DLYUJ2QnHypyntbjfIyCtYoyNEnp1eAndp1drmv5BXUQS7LWGzCWdxC8nzSJsQta/5u DltOL7av6WvUX4d/7o9wmfG68zLCQEh9K0T71N8j1EIsruXpH3X27t1TexDEgBmlSDaN uv+sEfy4mqmrbHDkACV8QPCYMnsRs8c29Fn3c6SUjWo/VfL6FZ2Dc1fbqC9FlDhAJfae ElQg==
X-Gm-Message-State: ALoCoQmmdK0uvkkrAvTi4d61pwdVPqD9HISL76e575kBbEswA1KSbLJTUpYE/bVtEcO6Xi00GlMg
X-Received: by 10.60.15.234 with SMTP id a10mr1345167oed.53.1379374646297; Mon, 16 Sep 2013 16:37:26 -0700 (PDT)
Received: from [10.151.99.209] ([148.87.13.5]) by mx.google.com with ESMTPSA id rl1sm34845314oeb.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Sep 2013 16:37:26 -0700 (PDT)
Message-ID: <52379643.7070705@nthpermutation.com>
Date: Mon, 16 Sep 2013 19:37:39 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Juraj Somorovsky 
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de>
In-Reply-To: <52378A67.9010903@rub.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Sep 2013 23:37:45 -0000

On 9/16/2013 6:47 PM, Juraj Somorovsky wrote:
> Hi Mike,
>
> On 09/06/2013 06:10 AM, Michael StJohns wrote:
>> That still leaves a second problem.  The "key expansion" stage produces
>> both private (key material) and public (iv data) by producing a key
>> stream and then splitting up (based on the sizes of keys needed) into
>> the 4 keys and 2 IVs.
>>
>> o Consider  an application that needs to produce 2 128 bit AES keys and
>> 2 IVs (for say GCM).
>> o Consider that an attacker (or a hacked program that's being used to
>> extract keys) re-runs the derivation using the same master key and same
>> random data, this time specifying zero length keys (or 64 bits of keys
>> etc), but still asks for the IV material.
>>
> Just a quick questions:
> I do not know if I understand this scenario correctly...but how can this
> be achieved in TLS?
> New key/IV material is always generated from client's as well as
> server's random. The attacker can choose the same client random, but he
> cannot influence the server random... thus always new key/IV material is
> generated.

This isn't about influencing the new key, but being able to extract the 
old key.  Assume the attacker a) has use of the master key (either 
because he's running as hacked code, or because he managed to capture 
the PKCS11 pin and has access to the PKCS11 module), b) has captured all 
the necessary public data (e.g. has the previous random values from 
listening to the TLS exchange).   He then calls PKCS11 with the master 
key, the random data, but specifies that he needs smaller (e.g. no) mac 
and encryption keys.  The part of the key stream previously assigned to 
the mac and encryption keys (and safely protected inside the PKCS11 
module) is now assigned to the IV part of the structure and is now 
accessible to the attacker/caller of the module.   That attacker then 
takes that data and sends it off to someone who can intercept the 
traffic somewhere in the middle. There are a number of sub-scenarios 
which are dependent on where the PKCS11 module is, and where the 
attacker is and where the data is intercepted.

>
> Maybe in a PKCS11 scenario this is different?
>> The part of the key stream previously assigned to the encryption keys is
>> now assigned to the IV material.  Since IVs by their nature are public,
>> the attacker now has direct access to the key material previously used
>> for encryption.
>>
>> Fortunately, TLS1.1 changed the way IVs were calculated making it
>> possible to prohibit that leaking.  Unfortunately, the CCM and GCM
>> mechanisms for TLS1.2 decided to use the IV values making impossible to
>> prohibit the leaking.
>>
>> For the current PKCS11 draft, we finessed it by creating two mechanisms
>> - one that created only key material, and one that created key material
>> and IVs.  PKCS11 allows a specific key to be constrained to a specific
>> mechanism so that permits some security for the non-AEAD suites.  It's
>> not ideal, but its a beginning
> I would propose to make it more concrete for PKCS11 and generate the
> keys depending on the algorithms they are used in. For example, if you
> have a master_secret used to generate keys for AES_GCM and AES_CBC, you
> would use:
> k_GCM = PRF(master_secret, "AES_GCM", [further params])
> k_CBC = PRF(master_secret, "AES_CBC", [further params])

As long as you can control the length of the encryption and mac key in 
the call to PKCS11, you have an issue if you can produce IV material 
from the same key stream you use to produce encryption or mac keys.    
If you're suggesting using the above for generating IV material, it's 
doable, but maybe a bit of overkill.  I'd rather generate the IV from 
the public information only (e.g. only use the random data as the PRF seed).

Mike


>
> This ensures that the attacker cannot enforce the same key is used for
> two different algorithms, which could lead to some specific attacks (for
> more information see our paper on Backwards compatibility attacks:
> http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/)
>
> Best Regards
> Juraj
>
>


From trevp@trevp.net  Mon Sep 16 21:16:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696B111E8330 for ; Mon, 16 Sep 2013 21:16:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB3JjODjV6sx for ; Mon, 16 Sep 2013 21:16:26 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 30A9111E80DF for ; Mon, 16 Sep 2013 21:16:25 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hn9so4393214wib.11 for ; Mon, 16 Sep 2013 21:16:25 -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:date:message-id:subject:from:to :content-type; bh=GRBuALpym6eCi62atLYkBMgTAYwCAP62HwAps1Js6Xw=; b=SRML+lTuQeTuAtr/MGhtArIyPxmpcg930daB3DqMZ1w3/BDjaBMLA/jaAd3BnfQze5 B4/kTrka9zXAEnI7tbZ4fNWVXPHqkNWFbjYhsLIZqBfQkpiG1cvCc7RWfqSQugL0Ch9R wTGl9neVHvs3c+aZ2k+QUJ34IczPH/vcQKLsBNH0MVrz1vD5tX6olN81Ao2EEejuW4O+ vWBlXDw1wT+RrZsL44b1p6iHcYo/M5EAEsNt5gJZAMqP4vrKl/x0vByrvk05jak17qOu 6VWUHgw7AehHFseZBNuczkmhpb9mwi/3UVsKoFGsQZjglA/cKokExwmvLqbKmn5QXF9h WKOQ==
X-Gm-Message-State: ALoCoQnOTMG8tYnvS6YVTmv2RCGGIPSth1hRFCp0+20eHzFCseBuR8nrtVGdXAAGqNyYlb2QWW3V
MIME-Version: 1.0
X-Received: by 10.180.160.203 with SMTP id xm11mr692403wib.17.1379391385092; Mon, 16 Sep 2013 21:16:25 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Mon, 16 Sep 2013 21:16:24 -0700 (PDT)
X-Originating-IP: [166.137.214.169]
Date: Mon, 16 Sep 2013 21:16:24 -0700
Message-ID: 
From: Trevor Perrin 
To: "tls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 04:16:32 -0000

Hi,

Does anyone know of a reason to use RFC 5878?  Extension data can
already be sent in TLS handshakes:

Client -> Server : ClientHello Extension
Client <- Server : ServerHello Extension
Client -> Server : SupplementalData (RFC 4680)


5878 just adds another extension structure inside existing ones:

Client -> Server : ClientHello Extension signalling AuthorizationData
Client <- Server : ServerHello Extension signalling AuthorizationData,
                            SupplementalData containing AuthorizationData
Client -> Server : SupplementalData containing AuthorizationData


Seems like a bunch of added parsing for nothing?  What is this for?


Trevor

From maray@microsoft.com  Mon Sep 16 23:53:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C33D911E81C3 for ; Mon, 16 Sep 2013 23:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZxtAv0gwftB for ; Mon, 16 Sep 2013 23:53:39 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id DFAF911E822C for ; Mon, 16 Sep 2013 23:53:38 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB167.namprd03.prod.outlook.com (10.255.212.143) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 17 Sep 2013 06:53:36 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Tue, 17 Sep 2013 06:53:36 +0000
From: Marsh Ray 
To: Trevor Perrin , "tls@ietf.org" 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y6IKGSQTOxB0uEDKlWZcM0bZnJfDCw
Date: Tue, 17 Sep 2013 06:53:36 +0000
Message-ID: <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 0972DEC1D9
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(377454003)(199002)(51704005)(80976001)(81542001)(81342001)(83072001)(81816001)(81686001)(74876001)(74316001)(79102001)(83322001)(76482001)(56776001)(76796001)(74502001)(56816003)(33646001)(51856001)(80022001)(47446002)(74662001)(46102001)(77982001)(59766001)(76576001)(54316002)(76786001)(31966008)(77096001)(69226001)(47736001)(53806001)(54356001)(4396001)(47976001)(49866001)(74706001)(63696002)(65816001)(50986001)(74366001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB167; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 06:53:47 -0000

> Trevor Perrin
> Sent: Monday, September 16, 2013 9:16 PM
> Subject: [TLS] RFC 5878 - why?
>=20
> Hi,
>=20
> Does anyone know of a reason to use RFC 5878?  Extension data can already
> be sent in TLS handshakes:
>=20
> Seems like a bunch of added parsing for nothing?  What is this for?

One useful thing it does is acquires an extension code point from IANA as w=
ell as defines a few values for specific types of authZ data.

But probably the bigger reason is that some percentage of TLS servers in th=
e wild will crash or (worse) hang when they receive a Client Hello with too=
 much data. Nobody is really sure how much data is safe to send in the Clie=
nt Hello, so getting preapproved with a small extension is safest.

- Marsh


From trevp@trevp.net  Tue Sep 17 00:12:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6331411E8226 for ; Tue, 17 Sep 2013 00:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtzmnKQz0vbx for ; Tue, 17 Sep 2013 00:12:01 -0700 (PDT)
Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by ietfa.amsl.com (Postfix) with ESMTP id 46E9B21F8F4D for ; Tue, 17 Sep 2013 00:12:00 -0700 (PDT)
Received: by mail-wg0-f47.google.com with SMTP id f12so4552884wgh.26 for ; Tue, 17 Sep 2013 00:12:00 -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 :content-transfer-encoding; bh=lOvFS4IM9uJkmzsTFIhH8XcypQ6/OYiFTtPcN8D4WaQ=; b=faaL1Srq6F0/4ZGGFw6WP6kWyAs0m34r4BH7mSh+keU5Q0tyMON8GKnULCCpOcGVDH 2z9wHLocNWBi558TtJ0spdsmCTNhdlXvDBkWcIykDqWuiCMxQ8Zl+O2Sc4cg6akvEzeV KMo+Bw+kii/l7QJlfW/zk1oPitG9ECl0VN8a1fifIm/RAOpBKE7k+9RCcR7LDr6FkS9Q ghayWwsJftce47aZbCcmMeULVfMGgHT5mSNA6/b/7kfNMteZRoaT+tpIvUDBJG7Po5ET 0lIAWkHm4u7xGKD9TbwaOkZ0RnJTpBD0fatf0lDmzEYOXJ+a1oyLqzDJVyerY+W1BN/v ISZw==
X-Gm-Message-State: ALoCoQk5/XofQ8wA/79kDXB5p081WBlfc3CSsgWnIA01UtbDMD7zF3IDYGO/71rTluNIGiTRrwSw
MIME-Version: 1.0
X-Received: by 10.194.10.193 with SMTP id k1mr95170wjb.50.1379401920152; Tue, 17 Sep 2013 00:12:00 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 00:12:00 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Tue, 17 Sep 2013 00:12:00 -0700
Message-ID: 
From: Trevor Perrin 
To: Marsh Ray 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 07:12:07 -0000

On Mon, Sep 16, 2013 at 11:53 PM, Marsh Ray  wrote:
>> Trevor Perrin
>> Sent: Monday, September 16, 2013 9:16 PM
>> Subject: [TLS] RFC 5878 - why?
>>
>> Hi,
>>
>> Does anyone know of a reason to use RFC 5878?  Extension data can alread=
y
>> be sent in TLS handshakes:
>>
>> Seems like a bunch of added parsing for nothing?  What is this for?
>
> One useful thing it does is acquires an extension code point from IANA as=
 well as defines a few values for specific types of authZ data.

But those specific types (or any others) could just have been defined
as TLS Extensions.  (Does anyone actually use SAML in TLS??  or X.509
Authorization certs?).

Also, note 5878 only has an 8-bit space for "authZ types", which seems
*much worse* than just using 16-bit TLS extension numbers in terms of
number exhaustion or risk of collision.


> But probably the bigger reason is that some percentage of TLS servers in =
the wild will crash or (worse) hang when they receive a Client Hello with t=
oo much data. Nobody is really sure how much data is safe to send in the Cl=
ient Hello, so getting preapproved with a small extension is safest.

OK, but see my first diagram:
 - The server can send whatever it wants as a ServerHello extension
 - The client can send whatever it wants in response as RFC 4680
SupplementalData

So that problem is easily avoided without 5878.

Still not seeing the point...


Trevor

From maray@microsoft.com  Tue Sep 17 00:31:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D766611E8391 for ; Tue, 17 Sep 2013 00:31:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8lyYukors6V for ; Tue, 17 Sep 2013 00:31:00 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id AD75F11E8390 for ; Tue, 17 Sep 2013 00:31:00 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB165.namprd03.prod.outlook.com (10.255.212.139) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 17 Sep 2013 07:30:58 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Tue, 17 Sep 2013 07:30:58 +0000
From: Marsh Ray 
To: Trevor Perrin 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y6IKGSQTOxB0uEDKlWZcM0bZnJfDCwgAAHfQCAAAKG8A==
Date: Tue, 17 Sep 2013 07:30:57 +0000
Message-ID: <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e0:ee43::2]
x-forefront-prvs: 0972DEC1D9
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(51704005)(81542001)(53806001)(46102001)(51856001)(33646001)(83072001)(56776001)(65816001)(74706001)(54356001)(80022001)(81686001)(81816001)(83322001)(19580405001)(19580395003)(80976001)(47976001)(47736001)(50986001)(49866001)(4396001)(54316002)(76482001)(63696002)(74876001)(59766001)(79102001)(77982001)(31966008)(74662001)(74502001)(47446002)(81342001)(76786001)(74316001)(76796001)(76576001)(77096001)(69226001)(74366001)(56816003)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB165; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 07:31:06 -0000

> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Tuesday, September 17, 2013 12:12 AM
> Subject: Re: [TLS] RFC 5878 - why?
>
> But those specific types (or any others) could just have been defined as =
TLS
> Extensions.
> Also, note 5878 only has an 8-bit space for "authZ types", which seems
> *much worse* than just using 16-bit TLS extension numbers in terms of
> number exhaustion or risk of collision.

The WG must have felt that it was worth establishing a separate IANA regist=
ry for this specific purpose rather than piling them into the extension reg=
istry. An entire protocol could be defined in terms of exchanging sets of (=
ID, optional scalar value) pairs, but TLS tends to like structures that are=
 nested a little deeper according to their semantics.

I agree, a single octet seems stingy. But if it runs out the code space can=
 be extended with only minor ugly.

> (Does anyone actually use SAML in TLS??  or X.509 Authorization certs?).

Well, it'd be a lot harder without an interoperable spec for it! :-)

- Marsh


From pgut001@cs.auckland.ac.nz  Tue Sep 17 00:34:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4911E8391 for ; Tue, 17 Sep 2013 00:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBD4RY+o5cOz for ; Tue, 17 Sep 2013 00:34:00 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id D63BA11E8230 for ; Tue, 17 Sep 2013 00:33:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379403240; x=1410939240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FPzZlT6WMmMW6UdcoP5dYqPG8Fakso5zxEkFRcI6qZE=; b=RQQHVVUMuYJC9zXEvB/43cwCDZP1wEb1sNyrV66xx/LVACJpcsyTdb+m v5PaTr5r+2I4UNHhGdbOeUxhSZuwRTxCP4SF3ucEG9e8k2e6lvVr9SRiy C7kByvk9cmx02qFJ7D/FMKZH46CqVm0iM/1e4b3GVlmInPORzGWx4J3el Q=;
X-IronPort-AV: E=Sophos;i="4.90,921,1371038400"; d="scan'208";a="212560846"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Sep 2013 19:33:59 +1200
Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 17 Sep 2013 19:33:58 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 17 Sep 2013 19:33:58 +1200
From: Peter Gutmann 
To: Marsh Ray , Trevor Perrin 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y6IKGSQTOxB0uEDKlWZcM0bZnJfDCwgAAHfQCAAAKG8IAAA4lq
Date: Tue, 17 Sep 2013 07:33:58 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355672CD0@uxcn10-6.UoA.auckland.ac.nz>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com> , <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
In-Reply-To: <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 07:34:05 -0000

Trevor Perrin  writes:=0A=
=0A=
>Still not seeing the point...=0A=
=0A=
It does seem like a pretty clunky way to do a kitchen-sink extension.  OTOH=
=0A=
since it's marked as Experimental, does anyone care?=0A=
=0A=
Peter.=0A=

From ynir@checkpoint.com  Tue Sep 17 01:13:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA20C11E83A6 for ; Tue, 17 Sep 2013 01:13:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.191
X-Spam-Level: 
X-Spam-Status: No, score=-10.191 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ygJipJ1jef for ; Tue, 17 Sep 2013 01:13:04 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 38E1B11E83A4 for ; Tue, 17 Sep 2013 01:12:55 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8H8CqZS028301; Tue, 17 Sep 2013 11:12:52 +0300
X-CheckPoint: {52380F04-4-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Tue, 17 Sep 2013 11:12:52 +0300
From: Yoav Nir 
To: Marsh Ray 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y8abmHM3OiDk6g9BgUFzOgq5nJTD8AgAAFJACAAAVLgIAAC7qA
Date: Tue, 17 Sep 2013 08:12:51 +0000
Message-ID: <101DBCB0-FA04-42C3-B370-1979D5726292@checkpoint.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
In-Reply-To: <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.201]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 08:13:11 -0000

On Sep 17, 2013, at 10:30 AM, Marsh Ray  wrote:

>> From: Trevor Perrin [mailto:trevp@trevp.net]
>> Sent: Tuesday, September 17, 2013 12:12 AM
>> Subject: Re: [TLS] RFC 5878 - why?
>>=20
>> But those specific types (or any others) could just have been defined as=
 TLS
>> Extensions.
>> Also, note 5878 only has an 8-bit space for "authZ types", which seems
>> *much worse* than just using 16-bit TLS extension numbers in terms of
>> number exhaustion or risk of collision.
>=20
> The WG must have felt that it was worth establishing a separate IANA regi=
stry for this specific purpose rather than piling them into the extension r=
egistry. An entire protocol could be defined in terms of exchanging sets of=
 (ID, optional scalar value) pairs, but TLS tends to like structures that a=
re nested a little deeper according to their semantics.

s/WG/Authors/ - This was not a product of the TLS working group. It also ha=
s some interesting history, and was the cause for some quite heated debate =
on the IETF list:
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg05617.html

Yoav


From yaronf.ietf@gmail.com  Tue Sep 17 02:25:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F5B11E83C5 for ; Tue, 17 Sep 2013 02:25:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8VYF8+LL4hK for ; Tue, 17 Sep 2013 02:25:38 -0700 (PDT)
Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 1E30111E83C1 for ; Tue, 17 Sep 2013 02:25:37 -0700 (PDT)
Received: by mail-bk0-f48.google.com with SMTP id my13so1984967bkb.21 for ; Tue, 17 Sep 2013 02:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=VCaI1miH2eyBfAbgBDXcm7/zgGbExX08ZubbHvFUQ2E=; b=s2Wt+lqEH2i4JdhlJuOczgwpK4N3y4TU5SLYoHjKajEST6k8uDIKY+UQQ8+4AJBSq8 oDb9tKPzqoZqwsDrHzqJbTkVa4NeqCj61NAIYeY78v7Pl9U8qJdpUpaxYS4guN81LhGx LJ6OdTwvpOAJItXn5F5C3CZn9LxkBQGh6+jbjayW0e5nZKZH2SRK3Fd3rdYxeeG8z8C3 aKK8tn6Du5jQtFtjTIgvlkwAOag2eMO0UcC5Q7qYzhropyi5aSv1PooWmyrZNRJFRUdo tg+2VYqp4n8QTZVvtnUZPVgug6OPKhxe/NpY/wyoP4xBV90WHEjB66d377Vh806oRMr8 EvAg==
X-Received: by 10.204.168.197 with SMTP id v5mr28368282bky.24.1379409937206; Tue, 17 Sep 2013 02:25:37 -0700 (PDT)
Received: from [10.0.0.140] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id jt14sm9485241bkb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 02:25:36 -0700 (PDT)
Message-ID: <5238200E.70500@gmail.com>
Date: Tue, 17 Sep 2013 12:25:34 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: mrex@sap.com
References: <20130916211725.6E5E21A971@ld9781.wdf.sap.corp>
In-Reply-To: <20130916211725.6E5E21A971@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 09:25:40 -0000

Hi Martin,

you are right about Windows of course.

More generally, the draft is not trying to make recommendations that are 
actually implemented today by all browsers. We all know that 
implementation of TLS 1.2 is patchy to say the least. But we also know 
that the industry is in fact moving there. My personal goal is to make 
recommendations that will be useful (using real production software) 
mid-2014 or so, for people who are willing to update to the latest 
product releases.

Thanks,
	Yaron

On 09/17/2013 12:17 AM, Martin Rex wrote:
> Yaron Sheffer wrote:
>>
>> Problem #1 goes away if we say that the server only sends 2048-bit DH
>> parameters to "new" clients (those that offer TLS 1.2), and assume these
>> can all deal with DH of any length. Our draft recommends a TLS 1.2-only
>> cipher suite anyway. And since new clients are still rare, this could work.
>>
>> This partial solution is complicated by IE10, which (AFAIK) supports TLS
>> 1.2, but has this support off by default, and does not support larger
>> than 1024-bit DH.
>
> IE10 is an awkward way to refer to an implementation.
> What matters is what Microsoft's SChannel from the underlying OS supports.
> And Microsoft seems to not support DHE with RSA
> (only DHE_DSA, ECDHE_RSA and ECDHE_ECDSA).
>
>
> Windows 7 & 2008R2
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx
>
> Windows Vista & 2008:
> http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx
>
> Windows XP & 2003
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx
>
>
>
> -Martin
>

From ynir@checkpoint.com  Tue Sep 17 05:41:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171CC11E81C4 for ; Tue, 17 Sep 2013 05:41:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.213
X-Spam-Level: 
X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6IH9Lq+ilZLe for ; Tue, 17 Sep 2013 05:41:27 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 876F011E842B for ; Tue, 17 Sep 2013 05:41:26 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8HCfNvr014169; Tue, 17 Sep 2013 15:41:23 +0300
X-CheckPoint: {52384DF3-11-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Tue, 17 Sep 2013 15:41:23 +0300
From: Yoav Nir 
To: Yaron Sheffer 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: AQHOskdo5dKKYJ0xmEuWRIX4Ztx5/ZnIrW6AgADLcQCAADa7gA==
Date: Tue, 17 Sep 2013 12:41:23 +0000
Message-ID: <07AC3415-536F-4260-B726-476DFFE57F8F@checkpoint.com>
References: <20130916211725.6E5E21A971@ld9781.wdf.sap.corp> <5238200E.70500@gmail.com>
In-Reply-To: <5238200E.70500@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.187]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 12:41:32 -0000

Hi Yaron

OK, so on the one hand we have DHE with 2048 bits which, (a) doubles the co=
st of a handshake with an 2048-bit RSA key, and (b) doesn't work in Apache =
and Windows.
On the other hand with have ECDH with P-256, which (a) far less than double=
s the cost of the handshake, and (b) is implemented everywhere but disabled=
 in a few places (clients running on RedHat)

To get DHE-2048, we'd need to patch Apache, change Windows, get everyone to=
 use the new Windows, probably some more I forgot.

To get ECDH we need to change a compilation option of RedHat (and probably =
some other distributions).=20

I think the choice is pretty much a no-brainer.

And if you're worried about NIST curves, there are people pushing brainpool=
 and other curves on the TLS list.=20

Yoav

On Sep 17, 2013, at 12:25 PM, Yaron Sheffer 
 wrote:

> Hi Martin,
>=20
> you are right about Windows of course.
>=20
> More generally, the draft is not trying to make recommendations that are =
actually implemented today by all browsers. We all know that implementation=
 of TLS 1.2 is patchy to say the least. But we also know that the industry =
is in fact moving there. My personal goal is to make recommendations that w=
ill be useful (using real production software) mid-2014 or so, for people w=
ho are willing to update to the latest product releases.
>=20
> Thanks,
> 	Yaron
>=20
> On 09/17/2013 12:17 AM, Martin Rex wrote:
>> Yaron Sheffer wrote:
>>>=20
>>> Problem #1 goes away if we say that the server only sends 2048-bit DH
>>> parameters to "new" clients (those that offer TLS 1.2), and assume thes=
e
>>> can all deal with DH of any length. Our draft recommends a TLS 1.2-only
>>> cipher suite anyway. And since new clients are still rare, this could w=
ork.
>>>=20
>>> This partial solution is complicated by IE10, which (AFAIK) supports TL=
S
>>> 1.2, but has this support off by default, and does not support larger
>>> than 1024-bit DH.
>>=20
>> IE10 is an awkward way to refer to an implementation.
>> What matters is what Microsoft's SChannel from the underlying OS support=
s.
>> And Microsoft seems to not support DHE with RSA
>> (only DHE_DSA, ECDHE_RSA and ECDHE_ECDSA).
>>=20
>>=20
>> Windows 7 & 2008R2
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=3Dv=
s.85%29.aspx
>>=20
>> Windows Vista & 2008:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=3Dv=
s.85%29.aspx
>>=20
>> Windows XP & 2003
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=3Dv=
s.85%29.aspx
>>=20
>>=20
>>=20
>> -Martin
>>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


From mrex@sap.com  Tue Sep 17 05:50:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167F211E8440 for ; Tue, 17 Sep 2013 05:50:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Level: 
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV3z95YhY3O8 for ; Tue, 17 Sep 2013 05:50:02 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2895911E8429 for ; Tue, 17 Sep 2013 05:49:49 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8HCnmAF012464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 14:49:48 +0200 (MEST)
In-Reply-To: <52379643.7070705@nthpermutation.com>
To: Michael StJohns 
Date: Tue, 17 Sep 2013 14:49:48 +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: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 12:50:07 -0000

I fail to understand what you're trying to protect.

The master secret of a session is never a secret that is hidding
within the hardware module, instead, it is something known to the
calling TLS protocol stack and part of the TLS session cache.

For vanilla RSA cipher suites, it is deterministically derived
from randomness generated by the client and conveyed under
RSA encryption, deterministically combined with data known
in plain to the TLS protocol stack.

-Martin

From pascal.urien@gmail.com  Tue Sep 17 05:57:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B853111E8242 for ; Tue, 17 Sep 2013 05:57:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MiCrIJq2EX7 for ; Tue, 17 Sep 2013 05:57:46 -0700 (PDT)
Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id F111B11E8441 for ; Tue, 17 Sep 2013 05:57:09 -0700 (PDT)
Received: by mail-bk0-f50.google.com with SMTP id mz11so2104942bkb.23 for ; Tue, 17 Sep 2013 05:57:00 -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=tvOUry6XVisiHWXBv2bM8w3LJXIbZ82mHhPN5GcgLI4=; b=xy71haz3o5gPONtkcCdMgxmAkbUskw41bqpNU7f42HzPs8AtXkAYtvhfzWyM02MJW8 HqFHJyOs77aNghVXaX44pMD0sb9UyM3SNiFFvOMD979dm0kWl+QCzmWxrfZPXHolO8as oO/4cHzVTSUwurP4BzJ8FMcBlWmSGTrw3CgHDpYjYZxB7PpIiLuMJi5OMPtE9c2j1jHa 3Y8wFOnlKdhEPsfqoy9Hzxj0cSFaaL3GvaSRbQ1+spU0zID5f4R9jPjXlU3F8sispVo+ s0cc/vxa+e73lNIeQYCCHjCOKealAng0hNCjq5C7XXLPWsYlzzt5c+bQmoXnDU8Zp+dt Ar3g==
MIME-Version: 1.0
X-Received: by 10.205.105.73 with SMTP id dp9mr1517627bkc.33.1379422620627; Tue, 17 Sep 2013 05:57:00 -0700 (PDT)
Received: by 10.204.171.207 with HTTP; Tue, 17 Sep 2013 05:57:00 -0700 (PDT)
In-Reply-To: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
References: <52379643.7070705@nthpermutation.com> <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
Date: Tue, 17 Sep 2013 14:57:00 +0200
Message-ID: 
From: Pascal Urien 
To: mrex@sap.com
Content-Type: multipart/alternative; boundary=f46d042186ad4c6f1204e693db73
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 12:57:51 -0000

--f46d042186ad4c6f1204e693db73
Content-Type: text/plain; charset=ISO-8859-1

Why don't you realize a TLS stack in a secure element ?. For both full and
resume mode , in order to protect the master secret

see
http://www.ethertrust.com/wp-content/themes/ethertrust/about_ethertrust.pdf

Pascal


2013/9/17 Martin Rex 

> I fail to understand what you're trying to protect.
>
> The master secret of a session is never a secret that is hidding
> within the hardware module, instead, it is something known to the
> calling TLS protocol stack and part of the TLS session cache.
>
> For vanilla RSA cipher suites, it is deterministically derived
> from randomness generated by the client and conveyed under
> RSA encryption, deterministically combined with data known
> in plain to the TLS protocol stack.
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--f46d042186ad4c6f1204e693db73
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Why don't you realize a TLS stack in a secure ele=
ment ?. For both full and resume mode , in order to protect the master secr=
et
=A0


=A0
Pascal


2013/9/17 Martin Rex <mrex@sap.com>
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
I fail to understand what you're trying to protect.



The master secret of a session is never a secret that is hidding

within the hardware module, instead, it is something known to the

calling TLS protocol stack and part of the TLS session cache.



For vanilla RSA cipher suites, it is deterministically derived

from randomness generated by the client and conveyed under

RSA encryption, deterministically combined with data known

in plain to the TLS protocol stack.



-Martin


_____________________=
__________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--f46d042186ad4c6f1204e693db73--

From mrex@sap.com  Tue Sep 17 06:01:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC0C111E811D for ; Tue, 17 Sep 2013 06:01:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.125
X-Spam-Level: 
X-Spam-Status: No, score=-10.125 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k719nlz3EwkK for ; Tue, 17 Sep 2013 06:01:07 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 996A911E8242 for ; Tue, 17 Sep 2013 06:00:59 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8HD0pMu011093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 15:00:51 +0200 (MEST)
In-Reply-To: <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>
To: Marsh Ray 
Date: Tue, 17 Sep 2013 15:00:50 +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: <20130917130050.E26CF1A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 13:01:13 -0000

Marsh Ray wrote:
> > Trevor Perrin
> > Sent: Monday, September 16, 2013 9:16 PM
> > Subject: [TLS] RFC 5878 - why?
> > 
> > Does anyone know of a reason to use RFC 5878?  Extension data can already
> > be sent in TLS handshakes:
> 
> But probably the bigger reason is that some percentage of TLS servers
> in the wild will crash or (worse) hang when they receive a Client Hello
> with too much data. Nobody is really sure how much data is safe to send
> in the Client Hello, so getting preapproved with a small extension is
> safest.

I hope that, rather than crashing, the most widespread behaviour among
servers will be to simply abort the handshake with a fatal Handshake
failure alert when the ClientHello handshake message exceeds some
reasonable size (maybe 16 KByte).  Ours does.

-Martin

From yaronf.ietf@gmail.com  Tue Sep 17 06:05:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5708311E824D for ; Tue, 17 Sep 2013 06:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2SbFAD9agZGm for ; Tue, 17 Sep 2013 06:05:53 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id ED93611E823F for ; Tue, 17 Sep 2013 06:05:46 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id e11so2177902bkh.11 for ; Tue, 17 Sep 2013 06:05:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ghCcKfQnm3K1IAvScbYf4G0YPzatl2E/LsQxYx0yAE4=; b=BNJuGHeavvUWapGUKQSZFC4vdryHFwUugX5x5a+/in+zs5oMUn4yw/kf0VGtxG44F6 CKT1xv20yRA4jp6gLvrs01P1jRGxLDpfmGyDC4Qh23RHmqWQWVXA+XxOxlDbcHl1cFRz fjxei9CzM3DBU58ZzAzDVrD43gn+GBmj+/5hGjzhyEiAcnuCZUbTyzonLMRvWL8mmdmm ccai/hKQq8J1/y3IyMy/bPblc0PdY7yKkvDBRihtRAPFT7hHwXnKNc44icLy4YRrOrKd /Pw463fkPkuJVp3c91YoPhPyeDWHc0c6NgrgU5zV/tknJ7Jvyjq3CrH6eJ8Y04oztjws kpcQ==
X-Received: by 10.204.68.142 with SMTP id v14mr28689294bki.18.1379423145677; Tue, 17 Sep 2013 06:05:45 -0700 (PDT)
Received: from [10.0.0.141] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id jt14sm10113691bkb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 06:05:45 -0700 (PDT)
Message-ID: <523853A7.3070002@gmail.com>
Date: Tue, 17 Sep 2013 16:05:43 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir 
References: <20130916211725.6E5E21A971@ld9781.wdf.sap.corp> <5238200E.70500@gmail.com> <07AC3415-536F-4260-B726-476DFFE57F8F@checkpoint.com>
In-Reply-To: <07AC3415-536F-4260-B726-476DFFE57F8F@checkpoint.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 13:05:58 -0000

So yes, I agree. Here's from our work-in-progress -01 version:

As currently specified and implemented, elliptic curve groups are 
preferable over modular DH groups: they are easier and safer to use 
within TLS.

[...]

[RFC4492] allows clients and servers to negotiate ECDH parameters 
(curves). We recommend that clients and servers prefer verifiably random 
curves (specifically Brainpool P-256, brainpoolp256r1 
[I-D.merkle-tls-brainpool]), and fall back to the commonly used NIST 
P-256 (secp256r1) [RFC4492].

Thanks,
	Yaron

On 09/17/2013 03:41 PM, Yoav Nir wrote:
> Hi Yaron
>
> OK, so on the one hand we have DHE with 2048 bits which, (a) doubles the cost of a handshake with an 2048-bit RSA key, and (b) doesn't work in Apache and Windows.
> On the other hand with have ECDH with P-256, which (a) far less than doubles the cost of the handshake, and (b) is implemented everywhere but disabled in a few places (clients running on RedHat)
>
> To get DHE-2048, we'd need to patch Apache, change Windows, get everyone to use the new Windows, probably some more I forgot.
>
> To get ECDH we need to change a compilation option of RedHat (and probably some other distributions).
>
> I think the choice is pretty much a no-brainer.
>
> And if you're worried about NIST curves, there are people pushing brainpool and other curves on the TLS list.
>
> Yoav
>
> On Sep 17, 2013, at 12:25 PM, Yaron Sheffer 
>   wrote:
>
>> Hi Martin,
>>
>> you are right about Windows of course.
>>
>> More generally, the draft is not trying to make recommendations that are actually implemented today by all browsers. We all know that implementation of TLS 1.2 is patchy to say the least. But we also know that the industry is in fact moving there. My personal goal is to make recommendations that will be useful (using real production software) mid-2014 or so, for people who are willing to update to the latest product releases.
>>
>> Thanks,
>> 	Yaron
>>
>> On 09/17/2013 12:17 AM, Martin Rex wrote:
>>> Yaron Sheffer wrote:
>>>>
>>>> Problem #1 goes away if we say that the server only sends 2048-bit DH
>>>> parameters to "new" clients (those that offer TLS 1.2), and assume these
>>>> can all deal with DH of any length. Our draft recommends a TLS 1.2-only
>>>> cipher suite anyway. And since new clients are still rare, this could work.
>>>>
>>>> This partial solution is complicated by IE10, which (AFAIK) supports TLS
>>>> 1.2, but has this support off by default, and does not support larger
>>>> than 1024-bit DH.
>>>
>>> IE10 is an awkward way to refer to an implementation.
>>> What matters is what Microsoft's SChannel from the underlying OS supports.
>>> And Microsoft seems to not support DHE with RSA
>>> (only DHE_DSA, ECDHE_RSA and ECDHE_ECDSA).
>>>
>>>
>>> Windows 7 & 2008R2
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx
>>>
>>> Windows Vista & 2008:
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/ff468651%28v=vs.85%29.aspx
>>>
>>> Windows XP & 2003
>>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx
>>>
>>>
>>>
>>> -Martin
>>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>

From mrex@sap.com  Tue Sep 17 06:08:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95AB11E811D for ; Tue, 17 Sep 2013 06:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.143
X-Spam-Level: 
X-Spam-Status: No, score=-10.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwMSYO2QazLV for ; Tue, 17 Sep 2013 06:08:31 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5513721F9C4A for ; Tue, 17 Sep 2013 06:08:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8HD8UCx012781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 15:08:30 +0200 (MEST)
In-Reply-To: <20130917130050.E26CF1A974@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Tue, 17 Sep 2013 15:08: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: <20130917130830.1EB191A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 13:08:36 -0000

Martin Rex wrote:
> Marsh Ray wrote:
> > > Trevor Perrin
> > > Sent: Monday, September 16, 2013 9:16 PM
> > > Subject: [TLS] RFC 5878 - why?
> > > 
> > > Does anyone know of a reason to use RFC 5878?  Extension data can already
> > > be sent in TLS handshakes:
> > 
> > But probably the bigger reason is that some percentage of TLS servers
> > in the wild will crash or (worse) hang when they receive a Client Hello
> > with too much data. Nobody is really sure how much data is safe to send
> > in the Client Hello, so getting preapproved with a small extension is
> > safest.
> 
> I hope that, rather than crashing, the most widespread behaviour among
> servers will be to simply abort the handshake with a fatal Handshake
> failure alert when the ClientHello handshake message exceeds some
> reasonable size (maybe 16 KByte).  Ours does.


Actually, another reason that comes to mind when looking at the
handshake message flowchart here:

  http://tools.ietf.org/html/rfc5878#page-4

taking into account the last sentence before that chart:

   Successful session resumption uses the same authorization information
   as the original session.

and compare it with the handshake message flowchart for the
abbreviated TLS handshake (aka session resume):

  http://tools.ietf.org/html/rfc2246#page-32


For a potentially large TLS extension that carries fairly static data,
you might not want to have to send it on every proposed TLS session resume.

-Martin

From mrex@sap.com  Tue Sep 17 06:15:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EFD11E843C for ; Tue, 17 Sep 2013 06:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.156
X-Spam-Level: 
X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+JziSnqLYBT for ; Tue, 17 Sep 2013 06:14:58 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5A36F11E8455 for ; Tue, 17 Sep 2013 06:14:43 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8HDEZ2c013859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 15:14:35 +0200 (MEST)
In-Reply-To: <523853A7.3070002@gmail.com>
To: Yaron Sheffer 
Date: Tue, 17 Sep 2013 15:14:35 +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: <20130917131435.8AE601A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 13:15:03 -0000

Yaron Sheffer wrote:
> So yes, I agree. Here's from our work-in-progress -01 version:
> 
> As currently specified and implemented, elliptic curve groups are 
> preferable over modular DH groups: they are easier and safer to use 
> within TLS.

Elliptic curve crypto is still fenced with non-expired patent claims,
requires an implementation of elliptic curve algorithms and the
relevant TLS extensions (something which is FAR from universally
available) and elliptic curve technology is considerably more
sensitive to side channel (=timing) attacks that DH, RSA & DSA.

-Martin

From prvs=29725b1cf4=uri@ll.mit.edu  Tue Sep 17 06:29:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECFA11E8122 for ; Tue, 17 Sep 2013 06:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.99
X-Spam-Level: 
X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=-0.143,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbf3rgx1Qo1W for ; Tue, 17 Sep 2013 06:29:45 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79511E8221 for ; Tue, 17 Sep 2013 06:29:44 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8HDQ1O3000908; Tue, 17 Sep 2013 09:29:36 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "'mrex@sap.com'" , "'yaronf.ietf@gmail.com'" 
Date: Tue, 17 Sep 2013 09:29:28 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac6zp+6qwObFjsMHQnSsSBdCp+ytugAAfoV1
In-Reply-To: <20130917131435.8AE601A974@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_05:2013-09-17, 2013-09-17, 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-1305240000 definitions=main-1309170048
Message-Id: <20130917132945.0D79511E8221@ietfa.amsl.com>
Cc: "'tls@ietf.org'" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 13:29:50 -0000

 Sure I'd agree with ECC implementations being more vulnerable to side-chan=
nel attacks than say RSA.

Patent-wise, the ECC situation now reminds me that of pre-pre-2000 RSA, whe=
n IETF and especially implementers wouldn't touch it with a 10-foot pole.=20

I wish NSA lawyers did a better job negotiating with Certicom.=20

My personal $0.02.=20
--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: 
Lexington, MA  02420-9185      =20

Web:  http://www.ll.mit.edu/CST/

=20

MIT LL Root CA:=20

 


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Martin Rex [mailto:mrex@sap.com]
Sent: Tuesday, September 17, 2013 09:14 AM=0A=
To: Yaron Sheffer 
Cc: tls@ietf.org 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Yaron Sheffer wrote:
> So yes, I agree. Here's from our work-in-progress -01 version:
>=20
> As currently specified and implemented, elliptic curve groups are=20
> preferable over modular DH groups: they are easier and safer to use=20
> within TLS.

Elliptic curve crypto is still fenced with non-expired patent claims,
requires an implementation of elliptic curve algorithms and the
relevant TLS extensions (something which is FAR from universally
available) and elliptic curve technology is considerably more
sensitive to side channel (=3Dtiming) attacks that DH, RSA & DSA.

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

From prvs=29725b1cf4=uri@ll.mit.edu  Tue Sep 17 06:31:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091B611E83F0 for ; Tue, 17 Sep 2013 06:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.954
X-Spam-Level: 
X-Spam-Status: No, score=-5.954 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfqNRF5OEvoW for ; Tue, 17 Sep 2013 06:31:23 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id D33BF11E8221 for ; Tue, 17 Sep 2013 06:31:22 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8HDQ1QM000908; Tue, 17 Sep 2013 09:31:21 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "'mrex@sap.com'" , "'yaronf.ietf@gmail.com'" 
Date: Tue, 17 Sep 2013 09:31:11 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac6zp+6qwObFjsMHQnSsSBdCp+ytugAAfoV1AAAPbLg=
In-Reply-To: <20130917132945.0D79511E8221@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_05:2013-09-17, 2013-09-17, 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-1305240000 definitions=main-1309170048
Message-Id: <20130917133122.D33BF11E8221@ietfa.amsl.com>
Cc: "'tls@ietf.org'" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 13:31:32 -0000

Darn. It meant to say "I'm NOT sure I'd agree..."

:-(
--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: 
Lexington, MA  02420-9185      =20

Web:  http://www.ll.mit.edu/CST/

=20

MIT LL Root CA:=20

 


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Blumenthal, Uri - 0558 - MITLL [mailto:uri@ll.mit.edu]
Sent: Tuesday, September 17, 2013 09:29 AM=0A=
To: 'mrex@sap.com' ; 'yaronf.ietf@gmail.com' 
Cc: 'tls@ietf.org' 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

 Sure I'd agree with ECC implementations being more vulnerable to side-chan=
nel attacks than say RSA.

Patent-wise, the ECC situation now reminds me that of pre-pre-2000 RSA, whe=
n IETF and especially implementers wouldn't touch it with a 10-foot pole.=20

I wish NSA lawyers did a better job negotiating with Certicom.=20

My personal $0.02.=20
--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: 
Lexington, MA  02420-9185      =20

Web:  http://www.ll.mit.edu/CST/

=20

MIT LL Root CA:=20

 


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Martin Rex [mailto:mrex@sap.com]
Sent: Tuesday, September 17, 2013 09:14 AM
To: Yaron Sheffer 
Cc: tls@ietf.org 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Yaron Sheffer wrote:
> So yes, I agree. Here's from our work-in-progress -01 version:
>=20
> As currently specified and implemented, elliptic curve groups are=20
> preferable over modular DH groups: they are easier and safer to use=20
> within TLS.

Elliptic curve crypto is still fenced with non-expired patent claims,
requires an implementation of elliptic curve algorithms and the
relevant TLS extensions (something which is FAR from universally
available) and elliptic curve technology is considerably more
sensitive to side channel (=3Dtiming) attacks that DH, RSA & DSA.

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

From turners@ieca.com  Tue Sep 17 08:08:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAD711E8473 for ; Tue, 17 Sep 2013 08:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.26
X-Spam-Level: 
X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MwgRgybYccb for ; Tue, 17 Sep 2013 08:08:26 -0700 (PDT)
Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.56.216.19]) by ietfa.amsl.com (Postfix) with ESMTP id 86A8C11E8295 for ; Tue, 17 Sep 2013 08:08:26 -0700 (PDT)
Received: by gateway01.websitewelcome.com (Postfix, from userid 5007) id DF27F242F876; Tue, 17 Sep 2013 10:08:25 -0500 (CDT)
Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway01.websitewelcome.com (Postfix) with ESMTP id A87DF242F782 for ; Tue, 17 Sep 2013 10:08:25 -0500 (CDT)
Received: from [96.231.225.44] (port=55035 helo=thunderfish.local) by gator3286.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1VLwt6-0003uL-Uz; Tue, 17 Sep 2013 10:08:25 -0500
Message-ID: <52387068.2050802@ieca.com>
Date: Tue, 17 Sep 2013 11:08:24 -0400
From: Sean Turner 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yaron Sheffer 
References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com>
In-Reply-To: <522C3497.9020301@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: (thunderfish.local) [96.231.225.44]:55035
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 1
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20=
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 15:08:32 -0000

On 9/8/13 4:25 AM, Yaron Sheffer wrote:
> This is an early version of my proposal for a BCP-like document, to
> inform the industry on what can be done with existing implementations,
> while TLS 1.3 is still not ready.
>
> I would appreciate your comments of course. Specifically,
> I would like to fill in the Implementation Status table (Sec. 5) and
> would be glad to receive solid information (dates, planned dates,
> version numbers) from implementers.
>
> Thanks,
>      Yaron

Yaron,

Thanks for this draft, I'm supportive of it, and hope that the WG adopts 
it.  They've not had a history of adopting algorithm drafts, but this is 
one I think they should strongly consider adopting especially because it 
impacts the base specification.

A couple of things come to mind:

1. TLS isn't just used by browsers, but Brian Smith is also proposing 
some changes to the cipher suites offered by browsers 
(https://briansmith.org/browser-ciphersuites-01.html).  It'd be good to 
review those recommendations especially since he's recommending a few 
TLS_ECDHE suites ahead of TLS_DHE suites (assuming I'm reading the 
recommendation properly).  Also note that there's some information about 
implementation support there as well.

2. An implication of your draft is that version TLS 1.2 is preferred 
over other TLS versions.  That is kind of already done with the 
obsoletes trail from 1.0 to 1.1 to 1.2, but maybe it's time to dust off 
the issue of whether it's worth providing guidance on SHOULD NOT use SSL 
3.0/ TLS version 1.0/1.1.  Two caveats: 1) Unsure if it is practical to 
knock off older versions based on an algorithm recommendation given the 
deployment numbers, and 2) I'm also not sure this kind of recommendation 
needs to go in this draft.

3. (not specific to the draft) Going forward for TLS 1.3 maybe we should 
consider splitting out the MTI algorithms from the base specification so 
that we can update the MTIs on a regular basis without having to revise 
the base specification, which is what IPsec, S/MIME, PKIX, etc. have done.

4. I like Stephen's idea of explaining why PFS is needed.  Note that 
there's some information in RFC 4949 about PFS that you could start from.

5. Providing BCP algorithms for earlier TLS versions is okay in my mind 
essentially because those versions are still out there.

6. I'm torn on the idea of adding an appendix on how to 
add/remove/configure algorithms.  If it's information that's not readily 
available then I'd say it'd be worth documenting, but whether it goes in 
this draft or another I'd leave to the authors/wg.  (i.e., not sure we'd 
need to have a death match over the commands to input to apache to get 
this draft done)

On the procedural notes:

1. Don't worry about whether the draft's intended status is BCP or 
standards track.  I'd have no problem sponsoring it regardless; I've 
been down this path before, BCPs can document what is being done already 
or what we want to done now and in the future.

2. Feel free to use 2119 language, but depending on how you write it it 
might not be necessary.

spt

From trevp@trevp.net  Tue Sep 17 08:21:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F0611E8474 for ; Tue, 17 Sep 2013 08:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POJvcaa4V6Bf for ; Tue, 17 Sep 2013 08:21:22 -0700 (PDT)
Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by ietfa.amsl.com (Postfix) with ESMTP id D315311E848B for ; Tue, 17 Sep 2013 08:21:21 -0700 (PDT)
Received: by mail-we0-f182.google.com with SMTP id q59so5394410wes.27 for ; Tue, 17 Sep 2013 08:21: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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K2K/Rmh5If580SRewOxrfMdXaC0m0g+7wqG4GUU5Pbk=; b=PQBLdydHhkggaLpXiLd9bpnM1CJrcCFK7MTflXv0Bh7r9zqbJJziG+6Jd5yV/KP/HB U4KTNjSP8B38Gx1FIA8PafkIRT9tWT6i6KTuLlu2dCfRPOJV+QLNnVyrin/Dn/ydL6mV +UbEALT//TtB6AGfG/Vt1R00yzX6+4sBprj5/c9Ubvg7Ka0QMHDvuJIAVSW88WTR2YEC GWu/x8jGyZClfRvxj5RbFidULhQx7pgHaRliBwNdU0InQlgnMJ68GZpkQOyfztVUn1W2 QKs9FxFRjLKPndCKh1uh0ebf8K+XnqzeLZ5kHBGuUa440IE5t48FpVTbwR+sAcaOtcFC 7FRw==
X-Gm-Message-State: ALoCoQmjvljoDYfiLPG09ftKqW+ecr0bXJyhb6azT+5jmgXmL+IblqNlBiu5GE8KdMX7kKSRO28+
MIME-Version: 1.0
X-Received: by 10.180.160.203 with SMTP id xm11mr2955388wib.17.1379431280950;  Tue, 17 Sep 2013 08:21:20 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 08:21:20 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <20130917130830.1EB191A974@ld9781.wdf.sap.corp>
References: <20130917130050.E26CF1A974@ld9781.wdf.sap.corp> <20130917130830.1EB191A974@ld9781.wdf.sap.corp>
Date: Tue, 17 Sep 2013 08:21:20 -0700
Message-ID: 
From: Trevor Perrin 
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 15:21:27 -0000

On Tue, Sep 17, 2013 at 6:08 AM, Martin Rex  wrote:
> Martin Rex wrote:
>> Marsh Ray wrote:
>> > > Trevor Perrin
>> > > Sent: Monday, September 16, 2013 9:16 PM
>> > > Subject: [TLS] RFC 5878 - why?
>> > >
>> > > Does anyone know of a reason to use RFC 5878?  Extension data can already
>> > > be sent in TLS handshakes:
>> >
>> > But probably the bigger reason is that some percentage of TLS servers
>> > in the wild will crash or (worse) hang when they receive a Client Hello
>> > with too much data. Nobody is really sure how much data is safe to send
>> > in the Client Hello, so getting preapproved with a small extension is
>> > safest.
>>
>> I hope that, rather than crashing, the most widespread behaviour among
>> servers will be to simply abort the handshake with a fatal Handshake
>> failure alert when the ClientHello handshake message exceeds some
>> reasonable size (maybe 16 KByte).  Ours does.
>
>
> Actually, another reason that comes to mind when looking at the
> handshake message flowchart here:
>
>   http://tools.ietf.org/html/rfc5878#page-4
>
> taking into account the last sentence before that chart:
>
>    Successful session resumption uses the same authorization information
>    as the original session.
>
> and compare it with the handshake message flowchart for the
> abbreviated TLS handshake (aka session resume):
>
>   http://tools.ietf.org/html/rfc2246#page-32
>
>
> For a potentially large TLS extension that carries fairly static data,
> you might not want to have to send it on every proposed TLS session resume.


Like I said to Marsh, see the flowchart in my first message.

It's trivial to exchange "authorization data" - or any sort of
extension data - in the ServerHello extension, and also in a 4680
SupplementalData message sent by the client after receiving
ServerHelloDone.

5878 is not needed to avoid sending large items in ClientHello.


Trevor

From trevp@trevp.net  Tue Sep 17 08:32:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372DB11E80F7 for ; Tue, 17 Sep 2013 08:32:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcDUJTvakfl1 for ; Tue, 17 Sep 2013 08:32:18 -0700 (PDT)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 466F121F9AED for ; Tue, 17 Sep 2013 08:32:10 -0700 (PDT)
Received: by mail-we0-f170.google.com with SMTP id w62so5368852wes.29 for ; Tue, 17 Sep 2013 08:32:09 -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 :content-transfer-encoding; bh=k5GXAQTEbcF+y1hkvo3n+xCd1iprAz09yrtsJ/gn72Y=; b=X1ePa2exx7/vU2OI4BSMwrRTZXBjn0r4s2DOJ9DQA17ayYWOUeYAZLs3YEWht1ywqk 6fXmUocOlvN+8/G8M7VTRqLfvQtBrhQFpJFZmcW2LX7A7syjTRO2Q2QnCZwEyd+TmPkM 2gYlQHbKWBvsZ+owUPW6GV8bMy+NRwgZ5NUMVhkwkRbZf1TeD3815W8svF2zODfKrkFq LoaK0MAii8mXFwyXmxYzumSQsrss0t2ue57wC7miswd8AbkA27VBxIGsOSuhG+wlFpMK C8/GTQc/W6nE2b6L3bl1sD+vOimqMaWXFyayow/psxkssq2mXZYk8IVku0E/GBUPgtzu kuCw==
X-Gm-Message-State: ALoCoQlj/7XimwGBUmrPFovNKYYFPIwRHP1lhKAcsG7D9XCNVobL/yLODLFGheU6SjvAqzj+c0XM
MIME-Version: 1.0
X-Received: by 10.180.205.236 with SMTP id lj12mr3077877wic.22.1379431929392;  Tue, 17 Sep 2013 08:32:09 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 08:32:09 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Tue, 17 Sep 2013 08:32:09 -0700
Message-ID: 
From: Trevor Perrin 
To: Marsh Ray 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 15:32:23 -0000

On Tue, Sep 17, 2013 at 12:30 AM, Marsh Ray  wrote:
>> From: Trevor Perrin [mailto:trevp@trevp.net]
>> Sent: Tuesday, September 17, 2013 12:12 AM
>> Subject: Re: [TLS] RFC 5878 - why?
>>
>> But those specific types (or any others) could just have been defined as=
 TLS
>> Extensions.
>> Also, note 5878 only has an 8-bit space for "authZ types", which seems
>> *much worse* than just using 16-bit TLS extension numbers in terms of
>> number exhaustion or risk of collision.
>
> The WG must have felt that it was worth establishing a separate IANA regi=
stry for this specific purpose rather than piling them into the extension r=
egistry. An entire protocol could be defined in terms of exchanging sets of=
 (ID, optional scalar value) pairs, but TLS tends to like structures that a=
re nested a little deeper according to their semantics.
>
> I agree, a single octet seems stingy. But if it runs out the code space c=
an be extended with only minor ugly.

5878 itself is quite ugly, and riddled with errors and design flaws.
Which is why I'm bringing this up.

http://www.rfc-editor.org/errata_search.php?rfc=3D5878

I don't know how you could "extend" it to a larger code space.  I
suppose we could nest another extension structure *inside* the 5878
structure, to see how many parsing layers we can bury extensions
inside...

Or, we could just ignore it and use TLS Extensions and 4680 directly.
Why not that?


>> (Does anyone actually use SAML in TLS??  or X.509 Authorization certs?).
>
> Well, it'd be a lot harder without an interoperable spec for it! :-)

Does anyone care?  Has anyone written independent, interoperating
versions of these?


Trevor

From msj@nthpermutation.com  Tue Sep 17 08:45:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F14F911E8110 for ; Tue, 17 Sep 2013 08:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8eJ3jM7xhU4 for ; Tue, 17 Sep 2013 08:45:31 -0700 (PDT)
Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 8163011E8297 for ; Tue, 17 Sep 2013 08:45:31 -0700 (PDT)
Received: by mail-pa0-f43.google.com with SMTP id hz10so6982620pad.30 for ; Tue, 17 Sep 2013 08:45:29 -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=TR/abPq18wo9l+GLYVVHepI3Q0D1FxL61SZ1fnyaoRk=; b=VH1GExkML4mV6uyMzv58X8SDLiUGTxe2StwC08zDW9e3hnwR0WjMSktoqLlvWjpyVx DUyPmVhp6P3X3imVdjpu5wNqNw6jF1zs/TsI8BXoEj2p5qEv+zlsuvHEB1JGoFcmHjPX 2KulUUcuHqkH4GqlYUltd3cblA11jmZcsR6+4KFJSNQgPPSKV4QU+gXwksnXtCxa3L94 klrI5Yjy0gWdXjwNFgEE+olMiyLi+Gj6YY3C3bSdfrN4WHhBz38qfo0N4HQRcov/tdEn Akxv+sQXqnvNxCqqLgtcs907a9v2Ny28QDIPoWcpxZYh02ACeFDmu1P01Fv5dw4MZCpH IsCw==
X-Gm-Message-State: ALoCoQmXJJD5ZNmx64R7zlsYCV/OcGWOrCMQRcAz8zoRXKHBaHVvYp3Fzb+t9AMWEN9qYM9fC7gA
X-Received: by 10.68.164.228 with SMTP id yt4mr35036634pbb.77.1379432729544; Tue, 17 Sep 2013 08:45:29 -0700 (PDT)
Received: from [10.151.100.170] ([148.87.13.6]) by mx.google.com with ESMTPSA id ab4sm25054453pbc.43.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 08:45:28 -0700 (PDT)
Message-ID: <52387927.4030007@nthpermutation.com>
Date: Tue, 17 Sep 2013 11:45:43 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: mrex@sap.com
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
In-Reply-To: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 15:45:38 -0000

On 9/17/2013 8:49 AM, Martin Rex wrote:
> I fail to understand what you're trying to protect.
>
> The master secret of a session is never a secret that is hidding
> within the hardware module, instead, it is something known to the
> calling TLS protocol stack and part of the TLS session cache.

Um.  No, not if you designed things properly.  It should be possible for 
any protocol the IETF designs to do all the crypto operation inside a 
hardware module and not depend on the weak security of a general purpose 
computer.

I want to protect inside of the HSM all of the following:

a) the private keys related to the server or client identity
b) the pre-master key
c) the master key
d) the session keys.

I want to be able to do all the cryptographic processing inside that 
module and only allow out true plain text.

> For vanilla RSA cipher suites, it is deterministically derived
> from randomness generated by the client and conveyed under
> RSA encryption, deterministically combined with data known
> in plain to the TLS protocol stack.

I think you're talking about the pre-master secret?  If so, yes, but 
so?  The encrypted pre-master secret goes to the HSM where it's 
decrypted, run through a KDF and used to produce the master secret. 
Ideally, that master secret may be retained within the HSM and protected 
from disclosure.

Later, Mike

>
> -Martin


From msj@nthpermutation.com  Tue Sep 17 08:52:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA5411E848B for ; Tue, 17 Sep 2013 08:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAo2i3BleNkV for ; Tue, 17 Sep 2013 08:52:05 -0700 (PDT)
Received: from mail-vc0-f174.google.com (mail-vc0-f174.google.com [209.85.220.174]) by ietfa.amsl.com (Postfix) with ESMTP id D5F2211E829E for ; Tue, 17 Sep 2013 08:52:00 -0700 (PDT)
Received: by mail-vc0-f174.google.com with SMTP id gd11so4220921vcb.33 for ; Tue, 17 Sep 2013 08:51: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:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=Hcsy9l1OJx7aVlcIMSj3ki4W74LBYzMk0YLfe4Bd2T4=; b=X2nzO4Uz1lbUUbjmV/AgMzAL8z9RQT98CxrVoZc008vT8rymRx/glx6OA5h2fYU3hg NGYZPO5zkaIYqfZ2+PRCiOo58dA+nvTbahEqoERVf3/hQzUbXsu5Zw0Sv9cvNPsS9XCB m2fOnfiXqvuMbyoRZbpibYNVGtK0djvtgxizPpBNgZWbQuxxOdOePAvXG/GFqBujEOCR N0zcngHOLKyTFCNtCMK7EBYg0t7ol3aG/ke1aYpiJwEGaesELgymJdQdMy1JUkIceG29 evoFIOz/+wJHUY0EGagQ8/SWatJpvUuC3kfoCurCN0pGlssqBgYNPgIvWul0qVl6gX3x BGfQ==
X-Gm-Message-State: ALoCoQkURPcdIxLa1fDidjtJtzKk9Juo+HZ866wbPueIzj+i/6xz+Y5aQCWLORJRYFsmuz1DcubI
X-Received: by 10.52.108.161 with SMTP id hl1mr210364vdb.62.1379433119784; Tue, 17 Sep 2013 08:51:59 -0700 (PDT)
Received: from [10.151.100.170] ([148.87.13.6]) by mx.google.com with ESMTPSA id zn4sm11017054vdb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 08:51:59 -0700 (PDT)
Message-ID: <52387AAA.107@nthpermutation.com>
Date: Tue, 17 Sep 2013 11:52:10 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Pascal Urien 
References: <52379643.7070705@nthpermutation.com> <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020806090100020909080701"
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 15:52:09 -0000

This is a multi-part message in MIME format.
--------------020806090100020909080701
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 9/17/2013 8:57 AM, Pascal Urien wrote:
> Why don't you realize a TLS stack in a secure element ?. For both full 
> and resume mode , in order to protect the master secret
> see 
> http://www.ethertrust.com/wp-content/themes/ethertrust/about_ethertrust.pdf
> Pascal

This is a valid solution, but doesn't actually match what PKCS11 is 
designed to do - e.g. provide generic access to cryptographic functions, 
rather than build the TLS stack inside the token.

Also, the above doesn't provide any support for TLS key material 
exporters. (And wasn't that a problem to solve with PKCS11 safely).

The nice thing about PKCS11 is that its a toolkit that can be used for a 
lot of things - not just TLS.

Mike


>
>
> 2013/9/17 Martin Rex >
>
>     I fail to understand what you're trying to protect.
>
>     The master secret of a session is never a secret that is hidding
>     within the hardware module, instead, it is something known to the
>     calling TLS protocol stack and part of the TLS session cache.
>
>     For vanilla RSA cipher suites, it is deterministically derived
>     from randomness generated by the client and conveyed under
>     RSA encryption, deterministically combined with data known
>     in plain to the TLS protocol stack.
>
>     -Martin
>     _______________________________________________
>     TLS mailing list
>     TLS@ietf.org 
>     https://www.ietf.org/mailman/listinfo/tls
>
>


--------------020806090100020909080701
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 9/17/2013 8:57 AM, Pascal Urien
      wrote:

    

    

      

        
Why don't you realize a TLS stack in a secure element ?.
          For both full and resume mode , in order to protect the master
          secret

        
 

        
        
 

        
Pascal

      

    

    

    This is a valid solution, but doesn't actually match what PKCS11 is
    designed to do - e.g. provide generic access to cryptographic
    functions, rather than build the TLS stack inside the token.  

    

    Also, the above doesn't provide any support for TLS key material
    exporters. (And wasn't that a problem to solve with PKCS11 safely).

    

    The nice thing about PKCS11 is that its a toolkit that can be used
    for a lot of things - not just TLS. 

    

    Mike

    

    

    

      


        

        
2013/9/17 Martin Rex <mrex@sap.com>

          

            I fail to understand what you're trying to protect.

            

            The master secret of a session is never a secret that is
            hidding

            within the hardware module, instead, it is something known
            to the

            calling TLS protocol stack and part of the TLS session
            cache.

            

            For vanilla RSA cipher suites, it is deterministically
            derived

            from randomness generated by the client and conveyed under

            RSA encryption, deterministically combined with data known

            in plain to the TLS protocol stack.

            

                -Martin

              
            

              
_______________________________________________

                TLS mailing list

                TLS@ietf.org

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

              

            

          

        

        

      

    

    

  


--------------020806090100020909080701--

From rsalz@akamai.com  Tue Sep 17 09:01:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E291611E8289 for ; Tue, 17 Sep 2013 09:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfvgFOtpbykc for ; Tue, 17 Sep 2013 09:00:51 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9FA11E8491 for ; Tue, 17 Sep 2013 09:00:50 -0700 (PDT)
Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CDD00280E3; Tue, 17 Sep 2013 16:00:49 +0000 (GMT)
Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id BBF82280AE; Tue, 17 Sep 2013 16:00:49 +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 B3A6F2047; Tue, 17 Sep 2013 16:00:49 +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; Tue, 17 Sep 2013 12:00:42 -0400
From: "Salz, Rich" 
To: Michael StJohns 
Date: Tue, 17 Sep 2013 12:00:41 -0400
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: Ac6zvQ4+nnHvqRhaQ0KPbczYXRDsRAAATLLw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>
In-Reply-To: <52387927.4030007@nthpermutation.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 16:01:00 -0000

>I want to protect inside of the HSM all of the following:
>a) the private keys related to the server or client identity
>b) the pre-master key
>c) the master key
>d) the session keys.
>I want to be able to do all the cryptographic processing inside that modul=
e and only allow out true plain text.

The programming model for such a beast is probably more like an I/O process=
or than an HSM.  You need input and output "local plaintext" data streams, =
and the same for "to/from the network crypto streams."  And ways to signal =
"I can't give you more plaintext until you write this on the network and ge=
t more data back from the other side."  And so on.

Have you seen a market need for this kind of thing?  Have you got an API de=
signed?  I'd be curious about both.

I also don't understand why you do not trust the host software with the abi=
lity to decrypt its own data (i.e,. session) when you don't have control ov=
er what it does with the plaintext, like copy it over to an adversary direc=
tly.

	/r$
=20
-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA

From prvs=29725b1cf4=uri@ll.mit.edu  Tue Sep 17 09:13:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5D11E82A5 for ; Tue, 17 Sep 2013 09:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.308
X-Spam-Level: 
X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.290,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDsw+U1G0Rbx for ; Tue, 17 Sep 2013 09:13:39 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id DB45B11E80EA for ; Tue, 17 Sep 2013 09:13:35 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8HFQ28S015574; Tue, 17 Sep 2013 12:13:31 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "Salz, Rich" , Michael StJohns 
Date: Tue, 17 Sep 2013 12:13:09 -0400
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: Ac6zwM9byrP1+FwtQumO+QuhQ3/qlg==
Message-ID: 
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.7.130812
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3462264789_36040718"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_06:2013-09-17, 2013-09-17, 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-1305240000 definitions=main-1309170066
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 16:13:44 -0000

--B_3462264789_36040718
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

On 9/17/13 12:00 , "Salz, Rich"  wrote:


>>I want to protect inside of the HSM all of the following:
>>a) the private keys related to the server or client identity
>>b) the pre-master key
>>c) the master key
>>d) the session keys.
>>I want to be able to do all the cryptographic processing inside that
>>module and only allow out true plain text.
>
>The programming model for such a beast is probably more like an I/O
>processor than an HSM.  You need input and output "local plaintext" data
>streams, and the same for "to/from the network crypto streams."  And ways
>to signal "I can't give you more plaintext until you write this on the
>network and get more data back from the other side."  And so on.
>
>Have you seen a market need for this kind of thing?  Have you got an API
>designed?  I'd be curious about both.

Doesn't HAIPE do something like that?

http://en.wikipedia.org/wiki/High_Assurance_Internet_Protocol_Encryptor



>I also don't understand why you do not trust the host software with the
>ability to decrypt its own data (i.e,. session) when you don't have
>control over what it does with the plaintext, like copy it over to an
>adversary directly.

I guess this is more about protecting the cryptographic keys and
infrastructure rather than protecting plaintext of a given session (which
belongs to the application who is free to do with it whatever it wishes).

--B_3462264789_36040718
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD
F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0
B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p
rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr
i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8
11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB
BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw
PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/
inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd
XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq
oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5
48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ
/Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw
ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J
VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v
dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w
HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT
Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg
MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK
Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2
QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z
XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK
sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn
qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G
CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny
bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG
MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3
EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G
CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk
zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm
UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD
2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU
meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB
snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw
CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD
UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz
NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx
DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv
f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT
XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/
hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX
TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW
6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y
EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G
CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I
1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P
yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/
LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr
oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90
ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw
EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL
MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT
BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X
519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb
z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn
w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3
sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8
B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD
VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH
AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ
KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC
AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn
+t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f
NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU
3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ
aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw
ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv
cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg
hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAARgGgz9+gthWZGx51kg/xXPJcR8KdBzKu
H5zMV2OG4TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5
MTcxNjEzMDlaMA0GCSqGSIb3DQEBAQUABIIBAN1Ip0KxU7YaRP4yOOzJSCSu5S9BZ7GMhMTU
2QwU8tNpMyJL/zbVh5D/OE36xW/T83xtmGT3Lf94tT/FPs5Wyp52K7Nq9uLhYRkzUoYVt6cN
qCeTluKKhh142NRDrrcfoNEMYifgxZDmc1OUNpS8Mm/79QEeX/sfcMmfvUhVqYo3DY6lRFG+
f2hEvqeyg/d7XVp6g694S/tzzklMKnKg3U57fAonN8KGgT1I4HBko/P07Q7isZP7p1L3Y3Df
k8ISYSnlY1X4Mk1dRuJ9W+KiJTLUy0NTpYnI17jVerAvitjr0SwMxyHxPNz6a1VUbIPdnrQQ
7EoGWo5v9WAquvKSIC8=

--B_3462264789_36040718--

From mrex@sap.com  Tue Sep 17 09:14:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF5411E8129 for ; Tue, 17 Sep 2013 09:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.166
X-Spam-Level: 
X-Spam-Status: No, score=-10.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzFO70G9nJJZ for ; Tue, 17 Sep 2013 09:14:54 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8311E829A for ; Tue, 17 Sep 2013 09:14:50 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8HGEmqY019765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 18:14:48 +0200 (MEST)
In-Reply-To: <52387927.4030007@nthpermutation.com>
To: Michael StJohns 
Date: Tue, 17 Sep 2013 18:14:48 +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: <20130917161448.65E011A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 16:14:59 -0000

Michael StJohns wrote:
> On 9/17/2013 8:49 AM, Martin Rex wrote:
> > I fail to understand what you're trying to protect.
> >
> > The master secret of a session is never a secret that is hidding
> > within the hardware module, instead, it is something known to the
> > calling TLS protocol stack and part of the TLS session cache.
> 
> Um.  No, not if you designed things properly.  It should be possible for 
> any protocol the IETF designs to do all the crypto operation inside a 
> hardware module and not depend on the weak security of a general purpose 
> computer.
> 
> I want to protect inside of the HSM all of the following:
> 
> a) the private keys related to the server or client identity
> b) the pre-master key
> c) the master key
> d) the session keys.
> 
> I want to be able to do all the cryptographic processing inside that 
> module and only allow out true plain text.
> 
> > For vanilla RSA cipher suites, it is deterministically derived
> > from randomness generated by the client and conveyed under
> > RSA encryption, deterministically combined with data known
> > in plain to the TLS protocol stack.
> 
> I think you're talking about the pre-master secret?  If so, yes, but 
> so?  The encrypted pre-master secret goes to the HSM where it's 
> decrypted, run through a KDF and used to produce the master secret. 
> Ideally, that master secret may be retained within the HSM and protected 
> from disclosure.

Typically, the PKCS#11 module will export an RSA PKCS#1 v1.5 decryption
primitive, and the server will typically be able to pass the encrypted
premaster-secret, reference his strongly protected server credentials
and obtain the RSA-decrypted output.  Once that decrypted pre-master
secret is obtained, everything else is deterministic.

-Martin

From rsalz@akamai.com  Tue Sep 17 09:17:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B396211E829A for ; Tue, 17 Sep 2013 09:17:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDA37uxtsBuH for ; Tue, 17 Sep 2013 09:16:59 -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 0210C11E84A6 for ; Tue, 17 Sep 2013 09:16:41 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4AD7D481ED; Tue, 17 Sep 2013 16:16:38 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 3E7A848166; Tue, 17 Sep 2013 16:16:38 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 20A042FD51; Tue, 17 Sep 2013 16:16:38 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([172.27.107.26]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 17 Sep 2013 12:16:30 -0400
From: "Salz, Rich" 
To: "Blumenthal, Uri - 0558 - MITLL" 
Date: Tue, 17 Sep 2013 12:16:28 -0400
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: Ac6zwM9byrP1+FwtQumO+QuhQ3/qlgAAEwNg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594351@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 16:17:05 -0000

>Doesn't HAIPE do something like that?
> http://en.wikipedia.org/wiki/High_Assurance_Internet_Protocol_Encryptor

I didn't see any mention of TLS.

> I guess this is more about protecting the cryptographic keys and
> infrastructure rather than protecting plaintext of a given session (which
> belongs to the application who is free to do with it whatever it wishes).

Yes, but why protect the *session key* from the application?


From msj@nthpermutation.com  Tue Sep 17 09:26:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1188B11E8526 for ; Tue, 17 Sep 2013 09:26:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQ2ys35MN+lz for ; Tue, 17 Sep 2013 09:26:23 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id D484611E8522 for ; Tue, 17 Sep 2013 09:26:11 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hv10so1937371vcb.8 for ; Tue, 17 Sep 2013 09:26:11 -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=rhstycX4wp+r76reXnoTbnEZ3UMbnI/bFTv+CGRNFJU=; b=GBorsOTLhrP/khLyEerMOvK21pcHG4CxD8atwrXa2rvCiREtDK244ufBjnMYpKVVg9 550QAZStXzl+I8ooWIW5HOPp6x/5a94UIQyJ/MndFtkUTc2JVp2/KLnhPmI0B0U2C1aA rdGxHPb9EJ7vslOv++pheO4UHfYX/QW1Kkvm1UtaMS+JJMgBR7KpK3gbqyvzwa1DiBOg y6b3NThGhEks4R9dcoqffAVGQzhupe2xTob5WmIpVvtdqEsPBe0OQHdo5n+bPBwqb2GN DOOeFONaJ3Y2FnpNFsB93UwyDueN3jviQv/iBaL80O03cORIyxhBIo1AoM0E0rrhb9Em WB6Q==
X-Gm-Message-State: ALoCoQnTXpVOKBu3saW21PJYepzLZtoVCsPhkA7hkVwMEBWjk6pMsgtHrX28wzc72GIplaNo683/
X-Received: by 10.58.74.38 with SMTP id q6mr17181229vev.9.1379435171117; Tue, 17 Sep 2013 09:26:11 -0700 (PDT)
Received: from [10.151.100.170] ([148.87.13.6]) by mx.google.com with ESMTPSA id p5sm24663216vek.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 09:26:10 -0700 (PDT)
Message-ID: <523882B0.1020308@nthpermutation.com>
Date: Tue, 17 Sep 2013 12:26:24 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Salz, Rich" 
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com> <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594339@USMBX1.msg.corp.akamai.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 16:26:31 -0000

On 9/17/2013 12:00 PM, Salz, Rich wrote:
>> I want to protect inside of the HSM all of the following:
>> a) the private keys related to the server or client identity
>> b) the pre-master key
>> c) the master key
>> d) the session keys.
>> I want to be able to do all the cryptographic processing inside that module and only allow out true plain text.
> The programming model for such a beast is probably more like an I/O processor than an HSM.  You need input and output "local plaintext" data streams, and the same for "to/from the network crypto streams."  And ways to signal "I can't give you more plaintext until you write this on the network and get more data back from the other side."  And so on.

What?  No.

TLS is pretty much a two stage beast:

1) Figure out the keys. (TLS handshaking, data gathering, key transport 
and/key derivation).
2) use the crypto suite and the keys from (1) to encrypt and decrypt the 
messages.

Both of these are general purpose crypto operations.  How you get there 
is wrapped in TLS protocols, but the HSM doesn't actually need to know 
anything about TLS except its defined cryptographic operations (e.g., 
PKCS11 implements all of the various cipher and mac modes, implements 
signature creation and verification, and in addition, implements the TLS 
specific KDF (the TLS PRF in its various uses)).


>
> Have you seen a market need for this kind of thing?  Have you got an API designed?  I'd be curious about both.
>
> I also don't understand why you do not trust the host software with the ability to decrypt its own data (i.e,. session) when you don't have control over what it does with the plaintext, like copy it over to an adversary directly.

Small amounts of data (e.g. recovered keys) might be missed.  Harder to 
miss pretty much a doubling in traffic (e.g. a complete copy of the 
decrypted stream now being sent to the adversary).

Mike


>
> 	/r$
>   
> --
> Principal Security Engineer
> Akamai Technology
> Cambridge, MA
>
>


From mrex@sap.com  Tue Sep 17 10:00:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB85B11E82AB for ; Tue, 17 Sep 2013 10:00:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.175
X-Spam-Level: 
X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFJsEG6xWOse for ; Tue, 17 Sep 2013 10:00:40 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4374F11E8528 for ; Tue, 17 Sep 2013 10:00:32 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8HH0Skp000507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 17 Sep 2013 19:00:28 +0200 (MEST)
In-Reply-To: 
To: Adam Langley 
Date: Tue, 17 Sep 2013 19: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: <20130917170028.43B0B1A974@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] ChaCha20 + Poly1305 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 17 Sep 2013 17:00:45 -0000

Adam Langley wrote:
>
> > Which versions of TLS is this aimed at, TLS 1.2 (and later) only or earlier
> > versions too?
> 
> Since it's defined as an AEAD, technically it's only compatible with
> TLS 1.2 - same as AES-GCM.
> 
> However, the reality, at least for browsers, is that we cannot depend
> on TLS's version negotiation because of bugs in servers. Therefore, in
> practice, I'm planning on making some or all AES-GCM and
> Chacha20-Poly1305 ciphersuites work for all versions. For SSLv3,
> ECDHE/ECDSA variants will implicitly indicate support for
> P-{256,384,521} and uncompressed points since SSLv3 cannot carry the
> EC extensions needed to indicate that.

Only those incarnations of SSLv3 that are "TLS extensions intolerant"
can not carry TLS extensions.  For all other implementations of SSLv3
(i.e. those based on the ssl302 draft that became rfc6101), support
for TLS extensions is no different from what it is in TLSv1.0 onward.

-Martin

From n.mavrogiannopoulos@gmail.com  Tue Sep 17 10:05:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A95211E8540 for ; Tue, 17 Sep 2013 10:05:34 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBMvZs9KZwtq for ; Tue, 17 Sep 2013 10:05:33 -0700 (PDT)
Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8611E853F for ; Tue, 17 Sep 2013 10:05:28 -0700 (PDT)
Received: by mail-la0-f52.google.com with SMTP id ev20so4487478lab.25 for ; Tue, 17 Sep 2013 10:05:27 -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=GXLT9e30FRDGlPaRQWhbcv+T00p/nmof5xfUbMWK4KY=; b=DzceU6FsygT10I87gL7H5QqLQk5HjwDvODuOwtoPdSg7vqfQiDLqabgs3dmWfx4KDB 2oagq4KU5+i75S9AQbPQJvjWNsaAsd5is0SQamAMl5YKfrrDS111hgkPMLutQ2Lt4wrk qqui1NsyYzBV6o0HzPEksEpq8Ycf0juFjSEAR2LyIUfuAQxFRN0Eshhsr7UGgby7miSs HQlqejB0yYQxMPXa4BrBGA+ATZXU+oVaosDz8ULEhdz98UY2f3msZ4qetVupjPg2vj52 OYDKkbAAznVXfZqTeDz6FjK9UEvPuAkTbz/vKFkzYvsk+VsTpRYxacihcJ8c4pK71rLs TMhg==
MIME-Version: 1.0
X-Received: by 10.112.14.3 with SMTP id l3mr7352052lbc.27.1379437527570; Tue, 17 Sep 2013 10:05:27 -0700 (PDT)
Sender: n.mavrogiannopoulos@gmail.com
Received: by 10.112.133.196 with HTTP; Tue, 17 Sep 2013 10:05:27 -0700 (PDT)
In-Reply-To: <52387927.4030007@nthpermutation.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>
Date: Tue, 17 Sep 2013 19:05:27 +0200
X-Google-Sender-Auth: csSIneBcgKQ7Opn-CoN_lIgOPd8
Message-ID: 
From: Nikos Mavrogiannopoulos 
To: Michael StJohns 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 17:05:35 -0000

On Tue, Sep 17, 2013 at 5:45 PM, Michael StJohns  wrote:

>> The master secret of a session is never a secret that is hidding
>> within the hardware module, instead, it is something known to the
>> calling TLS protocol stack and part of the TLS session cache.
> Um.  No, not if you designed things properly.  It should be possible for any
> protocol the IETF designs to do all the crypto operation inside a hardware
> module and not depend on the weak security of a general purpose computer.

What you care is protection of the long term keys by the security
module. Are you really sure you want to protect the temporal session
keys (i.e. TLS master key) as well? What do you gain if you do that?
If you want to protect the key from a software vulnerability that
gives access to the system to an adversary, then you have succeeded
your goal to protect the key but failed on the goal to protect the
data the key is encrypting/decrypting. Thus making the effort to
protect the session key pretty futile, as it is as important as the
data it protects.

> I want to protect inside of the HSM all of the following:
> a) the private keys related to the server or client identity

This makes sense because a private key is used more than one sessions
and can be used to attack future (and in some cases past sessions).

> b) the pre-master key
> c) the master key
> d) the session keys.

All of these are session-specific keys and protect the data that are
exchanged in that particular session. IMO there is no much sense
trying to isolate them from the software handling the data.

regards,
Nikos

From yaronf.ietf@gmail.com  Tue Sep 17 12:10:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AF111E82D5 for ; Tue, 17 Sep 2013 12:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.547
X-Spam-Level: 
X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjmoAJIoOVag for ; Tue, 17 Sep 2013 12:10:09 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5916111E82CD for ; Tue, 17 Sep 2013 12:10:09 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id hn9so5430254wib.5 for ; Tue, 17 Sep 2013 12:10:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DX7Wyh9dDtOfGX3DVvcXB1nQU44Ilx68RxEcteMsAY8=; b=Tauhb2vvvenqtGVe2fotoXa7NU6CIQr4pcdS9tFs2GyKHeNQV/PTabYDQJ1LZDZBhP TVQHAy/TfCTHF0Y9/8A7oD6vYzhCREEzqk26aRJW5jSVPycu2yjfpj+iFPVwuVhANZsX VgEEiEYV7nMKt2nACGtKTi5KBrnUZv+62XnxIQbWL0QO+AyfZbcG2XepROD5Q6prTsHm jj6EY21UGGxNLLIO//VAFZX6VUq6PhmTRAciAeKKZYAXlXypAHXH6Z2udWgRC3jJqbcP vGmxBHXRuwwBVg1rntJflfrr3Um48X/C65QgQaYFLW33x+6p2Vh9B9kmxJD3aPZVvloK TC+g==
X-Received: by 10.180.39.242 with SMTP id s18mr3675048wik.47.1379445008406; Tue, 17 Sep 2013 12:10:08 -0700 (PDT)
Received: from [10.0.0.8] (bzq-79-181-188-99.red.bezeqint.net. [79.181.188.99]) by mx.google.com with ESMTPSA id fz8sm6593445wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 12:10:08 -0700 (PDT)
Message-ID: <5238A90E.5090100@gmail.com>
Date: Tue, 17 Sep 2013 22:10:06 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Sean Turner 
References: <20130907224638.32356.96972.idtracker@ietfa.amsl.com> <522C3497.9020301@gmail.com> <52387068.2050802@ieca.com>
In-Reply-To: <52387068.2050802@ieca.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 19:10:10 -0000

Hi Sean,

Thanks for your review. Please see my comments below.

	Yaron

On 09/17/2013 06:08 PM, Sean Turner wrote:
> On 9/8/13 4:25 AM, Yaron Sheffer wrote:
[...]
>
> Yaron,
>
> Thanks for this draft, I'm supportive of it, and hope that the WG adopts
> it.  They've not had a history of adopting algorithm drafts, but this is
> one I think they should strongly consider adopting especially because it
> impacts the base specification.
>
> A couple of things come to mind:
>
> 1. TLS isn't just used by browsers, but Brian Smith is also proposing
> some changes to the cipher suites offered by browsers
> (https://briansmith.org/browser-ciphersuites-01.html).  It'd be good to
> review those recommendations especially since he's recommending a few
> TLS_ECDHE suites ahead of TLS_DHE suites (assuming I'm reading the
> recommendation properly).  Also note that there's some information about
> implementation support there as well.

Thanks for pointing it out. It is very useful. And it agrees on the #1 
cipher suite with our upcoming -01 (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

>
> 2. An implication of your draft is that version TLS 1.2 is preferred
> over other TLS versions.  That is kind of already done with the
> obsoletes trail from 1.0 to 1.1 to 1.2, but maybe it's time to dust off
> the issue of whether it's worth providing guidance on SHOULD NOT use SSL
> 3.0/ TLS version 1.0/1.1.  Two caveats: 1) Unsure if it is practical to
> knock off older versions based on an algorithm recommendation given the
> deployment numbers, and 2) I'm also not sure this kind of recommendation
> needs to go in this draft.

TLS 1.2 is sort-of implicit in the draft. Also, there have been 
proposals to backport GCM to 1.0 and 1.1. I'm not sure if it makes sense 
(vs. wholesale transition to 1.2), but if that happens, fine.

>
> 3. (not specific to the draft) Going forward for TLS 1.3 maybe we should
> consider splitting out the MTI algorithms from the base specification so
> that we can update the MTIs on a regular basis without having to revise
> the base specification, which is what IPsec, S/MIME, PKIX, etc. have done.
>

I agree.
> 4. I like Stephen's idea of explaining why PFS is needed.  Note that
> there's some information in RFC 4949 about PFS that you could start from.
>

Ralph contributed excellent text on PFS for -01.

> 5. Providing BCP algorithms for earlier TLS versions is okay in my mind
> essentially because those versions are still out there.

Except that nobody wants to come forward with a proposal for such 
algorithms, because so much is unfortunately broken. E.g. I don't think 
you can recommend AES-CBC without some of the mitigations people have 
implemented.

>
> 6. I'm torn on the idea of adding an appendix on how to
> add/remove/configure algorithms.  If it's information that's not readily
> available then I'd say it'd be worth documenting, but whether it goes in
> this draft or another I'd leave to the authors/wg.  (i.e., not sure we'd
> need to have a death match over the commands to input to apache to get
> this draft done)

I simply don't have the time to do it. But here's someone who did: 
http://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/

>
> On the procedural notes:

Let's go into this when we discuss WG adoption. Currently the draft is 
strictly lower case.

>
> 1. Don't worry about whether the draft's intended status is BCP or
> standards track.  I'd have no problem sponsoring it regardless; I've
> been down this path before, BCPs can document what is being done already
> or what we want to done now and in the future.
>
> 2. Feel free to use 2119 language, but depending on how you write it it
> might not be necessary.
>
> spt

From yaronf.ietf@gmail.com  Tue Sep 17 12:21:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6825511E82C3 for ; Tue, 17 Sep 2013 12:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level: 
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsUnvIn627Zi for ; Tue, 17 Sep 2013 12:21:28 -0700 (PDT)
Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id A407511E82B2 for ; Tue, 17 Sep 2013 12:21:28 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id l18so4823725wgh.0 for ; Tue, 17 Sep 2013 12:21:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=g5osdhLM3YMx7XD/oAXh1nj6/8/PBY+5oT4Lf0fFoQc=; b=zSiWo1rU8hSFlZr7AmMiypYswPgyl0oerK3L5D2sU/JOkfJwEcoB+JHAVxCsWLCdZ5 7kDMfpkmQ54r6SBrQAquNYhXMqzqoH5MhElUWyPkd+ulywZtcJjyjU0JfxNr0rvSMP/n xYFH2jtrZZKPuxPN9cS225sYuLyp2UyZ6SteyXyEfxYtlBAkvei/arQIxL2jZgZ42Hhc awDhmWW8Zjpg1JbsAtpztD4stKmRekGXouNt3j1kJnkYQb2tl19e46oMOgJ31bmrJU0Y lcUUWHK9MfRNWPFntuLhu00mKKvqXR2f7j81uSCNTSVvC7K3IaBBqZnVjcL/e8mnyQKh Gv2g==
X-Received: by 10.180.229.103 with SMTP id sp7mr3895774wic.2.1379445687803; Tue, 17 Sep 2013 12:21:27 -0700 (PDT)
Received: from [10.0.0.8] (bzq-79-181-188-99.red.bezeqint.net. [79.181.188.99]) by mx.google.com with ESMTPSA id z13sm6667198wib.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Sep 2013 12:21:27 -0700 (PDT)
Message-ID: <5238ABB0.4090106@gmail.com>
Date: Tue, 17 Sep 2013 22:21:20 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: mrex@sap.com
References: <20130917131435.8AE601A974@ld9781.wdf.sap.corp>
In-Reply-To: <20130917131435.8AE601A974@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 19:21:29 -0000

Hi Martin,

IMHO this is far from clear-cut.

There is some IPR mess surrounding ECC. But I know of vendors who are 
avoiding it by interpreting the IPR statement as referring to CAs 
(rather than endpoints), with the NSA license and RFC 6090 serving as 
fallback (NSA is your friend :-). As an example, Red Hat and Canonical 
are arguably in a similar position, but Canonical includes OpenSSL with 
ECC while RH disables it.

Our -00 draft proposed MODP DH, because it is simpler and more widely 
implemented. But I now prefer ECDH despite the drawbacks of ECC, because:

- Important implementations are broken, and will abort the connection 
when receiving >1024-bits DH.
- Modular DH cannot be negotiated, so there's no way for the server to 
know what the client supports and whether it'll break.

Thanks,
	Yaron

On 09/17/2013 04:14 PM, Martin Rex wrote:
> Yaron Sheffer wrote:
>> So yes, I agree. Here's from our work-in-progress -01 version:
>>
>> As currently specified and implemented, elliptic curve groups are
>> preferable over modular DH groups: they are easier and safer to use
>> within TLS.
>
> Elliptic curve crypto is still fenced with non-expired patent claims,
> requires an implementation of elliptic curve algorithms and the
> relevant TLS extensions (something which is FAR from universally
> available) and elliptic curve technology is considerably more
> sensitive to side channel (=timing) attacks that DH, RSA & DSA.
>
> -Martin
>

From maray@microsoft.com  Tue Sep 17 14:28:17 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3813011E81A7 for ; Tue, 17 Sep 2013 14:28:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1TPHpgM4Hif for ; Tue, 17 Sep 2013 14:28:07 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id 5808D11E80D9 for ; Tue, 17 Sep 2013 14:28:05 -0700 (PDT)
Received: from BLUPR03MB166.namprd03.prod.outlook.com (10.255.212.142) by BLUPR03MB165.namprd03.prod.outlook.com (10.255.212.139) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 17 Sep 2013 21:28:00 +0000
Received: from BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) by BLUPR03MB166.namprd03.prod.outlook.com ([169.254.4.249]) with mapi id 15.00.0775.005; Tue, 17 Sep 2013 21:28:00 +0000
From: Marsh Ray 
To: Trevor Perrin 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y6IKGSQTOxB0uEDKlWZcM0bZnJfDCwgAAHfQCAAAKG8IAAiTiAgABVTBA=
Date: Tue, 17 Sep 2013 21:27:59 +0000
Message-ID: <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ee31::2]
x-forefront-prvs: 0972DEC1D9
x-forefront-antispam-report: SFV:NSPM; SFS:(199002)(189002)(377454003)(51704005)(33646001)(46102001)(53806001)(81542001)(83072001)(65816001)(80022001)(74706001)(51856001)(54356001)(81686001)(81816001)(19580405001)(83322001)(19580395003)(80976001)(47976001)(47736001)(50986001)(49866001)(63696002)(74876001)(79102001)(54316002)(76482001)(4396001)(59766001)(77982001)(31966008)(74662001)(74502001)(47446002)(56776001)(81342001)(76796001)(74316001)(76786001)(76576001)(77096001)(69226001)(56816003)(74366001)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB165; H:BLUPR03MB166.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ee31::2; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 21:28:17 -0000

> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: Tuesday, September 17, 2013 8:32 AM
>=20
> 5878 itself is quite ugly, and riddled with errors and design flaws.
> Which is why I'm bringing this up.

Now, now, be nice.

Alternatively, if you know something exploitable please drop it while it's =
hot.

> I don't know how you could "extend" it to a larger code space.  I suppose=
 we
> could nest another extension structure *inside* the 5878 structure, to se=
e
> how many parsing layers we can bury extensions inside...

254 authZ data formats ought to be enough for anyone. But if not, sure, we =
could indeed use 255 as a value to indicate a multi-byte value follows.

> Or, we could just ignore it and use TLS Extensions and 4680 directly.
> Why not that?

We could. But at least now the RFC 5878 authors and implementers have their=
 own little kitchen sink to experiment in.

> Does anyone care?  Has anyone written independent, interoperating
> versions of these?

You must be new here ...  :-)

- Marsh

P.s. I'm glad you're here


From frantz@pwpconsult.com  Tue Sep 17 17:21:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2304011E81DC for ; Tue, 17 Sep 2013 17:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qgd0ZYKXxG20 for ; Tue, 17 Sep 2013 17:21:09 -0700 (PDT)
Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0863F11E81CC for ; Tue, 17 Sep 2013 17:21:08 -0700 (PDT)
Received: from [173.75.83.246] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VM5Vx-00067i-Mi; Tue, 17 Sep 2013 20:21:05 -0400
Date: Tue, 17 Sep 2013 17:21:05 -0700
From: Bill Frantz 
To: Michael StJohns 
X-Priority: 3
In-Reply-To: <52387927.4030007@nthpermutation.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c641fde1af3a04011e78c5c14636ce9c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.246
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 00:21:14 -0000

On 9/17/13 at 8:45 AM, msj@nthpermutation.com (Michael StJohns) wrote:

>Um.  No, not if you designed things properly.  It should be=20
>possible for any protocol the IETF designs to do all the crypto=20
>operation inside a hardware module and not depend on the weak=20
>security of a general purpose computer.

While I have no objections to this requirement, I'm not sure=20
that hardware is more secure than software if your attacker is a=20
large country national crypto agency or sophisticated criminal=20
gangs. I worry about Russia, England, China, France etc. as well=20
as the USA.

Without taking the chips apart, even validated hardware can be=20
replaced at the chip foundry with a different implementation=20
which leaks keys via paths such as IVs or uses bogus random numbers.

These attacks can be minimized by using forward security -- more=20
keys to attack/leak; making IVs deterministic based on the plain=20
text and checked; using a cypher in counter mode for IVs,=20
calculating them separately at each end, and not transmitting=20
them etc.

There is no real safe heaven these days.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345=20
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos,=20
CA 95032


From trevp@trevp.net  Tue Sep 17 17:37:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8C11E8264 for ; Tue, 17 Sep 2013 17:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltB89xubJf7i for ; Tue, 17 Sep 2013 17:37:24 -0700 (PDT)
Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by ietfa.amsl.com (Postfix) with ESMTP id 85D5B11E8156 for ; Tue, 17 Sep 2013 17:37:24 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id m15so5810742wgh.19 for ; Tue, 17 Sep 2013 17:37:23 -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=Rmj38ha1w/Q+pA9PYVE2zsHP51KYiFiBchUiPsOHRCI=; b=W1726xw3XThQhZ1AmhmMy7E/ngG0818XzBtqQeaoSfp4TnRWm0kDolRyigYKDBozC/ wo/zgZu0+Eah/ZQJ9Yq00t750Y51tkyqUkc33FYJriOVcH9Z6scHfZJKtT9092gsGddD J7aholZ4pNS6m1SVbg9nIx7d8u6j78c8mbt+EZUmp4O1WfjR4HvpeYGZrFeHgnNlSPp8 WCJbdM1+oXuJFOaZkVlCHAJ00A4kZ6ZBHFjC//UpLZVryzfGf3hyGP8f/QmIJe6jnqIv wu3mptZwgXgvwvsim4dWxC92HaE8g08+uIDQ/lG8TNxAOFDpxXIxFtMJ5M2QeIHbwcS+ y4Lg==
X-Gm-Message-State: ALoCoQmM11RJ/1TNrpV+uBZJmRdzlH+bYwRXoLOZjHsd9gIDO7/FleYtOmZvNJdu+3MIZBl8zblh
MIME-Version: 1.0
X-Received: by 10.194.11.38 with SMTP id n6mr30092100wjb.25.1379464643572; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 17:37:23 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>  <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com>
Date: Tue, 17 Sep 2013 17:37:23 -0700
Message-ID: 
From: Trevor Perrin 
To: Marsh Ray 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 00:37:31 -0000

On Tue, Sep 17, 2013 at 2:27 PM, Marsh Ray  wrote:
>> From: Trevor Perrin [mailto:trevp@trevp.net]
>> Sent: Tuesday, September 17, 2013 8:32 AM
>>
>> 5878 itself is quite ugly, and riddled with errors and design flaws.
>> Which is why I'm bringing this up.
>
> Now, now, be nice.

Did you see the errata?

 * It's a weird extension structure, instead of having the standard
2-byte type / 2-byte length fields, like TLS Extensions and 4680
SupplementalDataEntry, each AuthorizationDataEntry has a (too-small)
1-byte type field, and no length field.

 * Without the length fields it's not generically parseable (Ben
suggests fixing that in the errata, but that breaks compatibility with
the 5878 URLandHash structure).

 * The structure definitions in section 3 are wrong.

 * The submitted errata also argue that the length field for
authz_data_list should be removed.  While I agree its redundant,
that's another compatibility-breaking change, so I'm not sure about
that.

So I'm asking:  Is there a legitimate reason for the community to
spend time fixing this RFC, implementing it in TLS libraries (it's not
currently present in any libraries, I believe), and adapting new
standards to use it?

If not, can we mark it as "obsoleted" or similar?

Projects like TACK, CT, and OpenSSL have wasted a lot of time
evaluating 5878 and doing trial implementations before backing away
from it.  I worry that people (like DTCP) [1] are going to keep making
that mistake, as on the surface this seems like the
"officially-condoned", IETF way to exchange new data through TLS.


> Alternatively, if you know something exploitable please drop it while it's hot.
>
>> I don't know how you could "extend" it to a larger code space.  I suppose we
>> could nest another extension structure *inside* the 5878 structure, to see
>> how many parsing layers we can bury extensions inside...
>
> 254 authZ data formats ought to be enough for anyone. But if not, sure, we could indeed use 255 as a value to indicate a multi-byte value follows.

Don't we have some 65000+ unused TLS extensions?

If you really want a few hundred numbers for "Private Use" or
"Specification Required" extensions, why don't we just carve that out
of the existing TLS Extension space?


Trevor

[1] http://tools.ietf.org/html/draft-dthakore-tls-authz-04

From ynir@checkpoint.com  Tue Sep 17 20:55:17 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3F8411E828B for ; Tue, 17 Sep 2013 20:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.283
X-Spam-Level: 
X-Spam-Status: No, score=-10.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzmtZWcFfV+1 for ; Tue, 17 Sep 2013 20:55:12 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6591E11E82DA for ; Tue, 17 Sep 2013 20:55:11 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8I3t5ro014799; Wed, 18 Sep 2013 06:55:05 +0300
X-CheckPoint: {52392418-33-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 18 Sep 2013 06:55:04 +0300
From: Yoav Nir 
To: Trevor Perrin 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1y8abmHM3OiDk6g9BgUFzOgq5nJTD8AgAAFJACAAAVLgIAAhnKAgABja4CAADTrgIAAN0eA
Date: Wed, 18 Sep 2013 03:55:04 +0000
Message-ID: <0866AA3B-DB43-44C6-95BC-03DCC2C0ADA7@checkpoint.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>  <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.153]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0D8993ECC6988440B19992F9713F3EA3@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 03:55:18 -0000

On Sep 18, 2013, at 3:37 AM, Trevor Perrin  wrote:

> On Tue, Sep 17, 2013 at 2:27 PM, Marsh Ray  wrote:
>>> From: Trevor Perrin [mailto:trevp@trevp.net]
>>> Sent: Tuesday, September 17, 2013 8:32 AM
>>>=20
>>> 5878 itself is quite ugly, and riddled with errors and design flaws.
>>> Which is why I'm bringing this up.
>>=20
>> Now, now, be nice.
>=20
> Did you see the errata?
>=20
> * It's a weird extension structure, instead of having the standard
> 2-byte type / 2-byte length fields, like TLS Extensions and 4680
> SupplementalDataEntry, each AuthorizationDataEntry has a (too-small)
> 1-byte type field, and no length field.
>=20
> * Without the length fields it's not generically parseable (Ben
> suggests fixing that in the errata, but that breaks compatibility with
> the 5878 URLandHash structure).
>=20
> * The structure definitions in section 3 are wrong.
>=20
> * The submitted errata also argue that the length field for
> authz_data_list should be removed.  While I agree its redundant,
> that's another compatibility-breaking change, so I'm not sure about
> that.
>=20
> So I'm asking:  Is there a legitimate reason for the community to
> spend time fixing this RFC, implementing it in TLS libraries (it's not
> currently present in any libraries, I believe), and adapting new
> standards to use it?
>=20
> If not, can we mark it as "obsoleted" or similar?
>=20
> Projects like TACK, CT, and OpenSSL have wasted a lot of time
> evaluating 5878 and doing trial implementations before backing away
> from it.  I worry that people (like DTCP) [1] are going to keep making
> that mistake, as on the surface this seems like the
> "officially-condoned", IETF way to exchange new data through TLS.

RFC 5878 is an experimental RFC. If you've looked at its history, it was ap=
proved by the IESG in 2006, and an IPR issue surfaced, so approval was with=
drawn, and the draft lay dormant for 3 years. If during those three years a=
nyone had come up with some other draft describing an authorization extensi=
on, I think that would have been approved instead. But nobody did.=20

I took that to mean that there was very little interest in passing authoriz=
ation information in the TLS handshake. So after three years, the IESG agre=
ed to publish it anyway, and as the errata show, it received very little re=
view.

In any case, it's an experimental RFC and if the DTCP want to send informat=
ion (whether authorization-related or not) in an extension, they can use it=
 or not use it as they see fit.

Yoav



From trevp@trevp.net  Tue Sep 17 21:25:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97E6F11E80F1 for ; Tue, 17 Sep 2013 21:25:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBtWPviZERcH for ; Tue, 17 Sep 2013 21:25:10 -0700 (PDT)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7FE11E80C5 for ; Tue, 17 Sep 2013 21:25:09 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u57so6014036wes.9 for ; Tue, 17 Sep 2013 21:25:07 -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 :content-transfer-encoding; bh=yA9rrmqwFiavpwcrnpbmq1PlBgkYUfVzEfGejmeZUQA=; b=JA4SBToQR5SlI5a9a/CXlRX4EhIirHwAMsQZLVbrc1X/R/6DOWMLovt5u65/vKDvos ktX4wZBWSSfJSjiflAyagf4PRdaEx1ulbjAvcKBGYtWZ7KIR1dvNPccPtSUr6mh+zKq0 MoU48MyU0LvKi3U+EgJk1Y/O0U7hdLSDYEo+KHmtHHgNTH+naBqg5ZOypndmZPAN44eI 9qZ4osbFaZfbPNLz4FpAIV7/md90SPyCnt3KePGugRNsfHJ+VOgq1XP8qUN8e2Clz1u7 Wjq6tdWoFhOecpngfzhCIuwL0P+RefbdHU0nz+VcqC9LmQhrTqRex42xNX9CxR9T5pUH jm2g==
X-Gm-Message-State: ALoCoQnxczlZcPAHmJs8bPC+9pD1Wd5NnkMNSHhOcpg6SlAVat2rlF5nhCR6hIZeyxC/mX+Fz2Xk
MIME-Version: 1.0
X-Received: by 10.194.89.233 with SMTP id br9mr29714456wjb.15.1379478307662; Tue, 17 Sep 2013 21:25:07 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 21:25:07 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: <0866AA3B-DB43-44C6-95BC-03DCC2C0ADA7@checkpoint.com>
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>  <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com>  <0866AA3B-DB43-44C6-95BC-03DCC2C0ADA7@checkpoint.com>
Date: Tue, 17 Sep 2013 21:25:07 -0700
Message-ID: 
From: Trevor Perrin 
To: Yoav Nir 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 04:25:16 -0000

On Tue, Sep 17, 2013 at 8:55 PM, Yoav Nir  wrote:
>
> RFC 5878 is an experimental RFC. If you've looked at its history, it was =
approved by the IESG in 2006, and an IPR issue surfaced, so approval was wi=
thdrawn, and the draft lay dormant for 3 years. If during those three years=
 anyone had come up with some other draft describing an authorization exten=
sion, I think that would have been approved instead.

Why is there need of an "authorization extension"?

TLS already has well-designed, standards-track ways of passing
extension data back and forth:

Client -> Server : ClientHello Extension
Client <- Server : ServerHello Extension
Client -> Server : SupplementalData (RFC 4680)

Why is that not sufficient?


Trevor

From d.thakore@cablelabs.com  Tue Sep 17 22:04:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3611E80F7 for ; Tue, 17 Sep 2013 22:04:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Level: 
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5b09pe2cLvP for ; Tue, 17 Sep 2013 22:04:27 -0700 (PDT)
Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 31DB811E80DF for ; Tue, 17 Sep 2013 22:04:26 -0700 (PDT)
Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id r8I54L7u020760; Tue, 17 Sep 2013 23:04:21 -0600
Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 17 Sep 2013 23:04:21 -0600 (MDT)
X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com)
Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Tue, 17 Sep 2013 23:04:21 -0600
From: Darshak Thakore 
To: Trevor Perrin , "tls@ietf.org" 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: AQHOs1zD1tB51ocLGUiZYCyZ8N3SHpnJ4x4AgAAFJQCAAAVLgIAAhnKAgABja4CAADTrgP//5gCA
Date: Wed, 18 Sep 2013 05:04:19 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.7.130812
x-originating-ip: [10.5.0.27]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <16C519FA1D86784EB177763E634A94B2@cablelabs.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Approved: ondar
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 05:04:31 -0000

I'm trying to understand if the primary issue being pointed out here is
about the errata in RFC5878 or the extension model that RFC5878 provides.
This thread started off with the primary question being what does RFC5878
provide and seems to be turning into a bashing of how bad it is. While i
agree that RFC5878 needs to be "fixed" in order to be usable, if we go
back to the original question of:

why this:

Client -> Server : ClientHello Extension signalling AuthorizationData
Client <- Server : ServerHello Extension signalling AuthorizationData,
                            SupplementalData containing AuthorizationData
Client -> Server : SupplementalData containing AuthorizationData

instead of this:

Client -> Server : ClientHello Extension
Client <- Server : ServerHello Extension
Client -> Server : SupplementalData (RFC 4680)


then:

1. You seem to be assuming that data is always flowing from the Client to
the Server and that anything that a server may want to send can always be
carried in the extension. That's not the only case. While it is possible
(and in most scenarios sufficient) to carry data in the extension itself,
certain extensions may require that actual data be passed in a specific
MessageType (based on certain aspects of the handshake being
accomplished). In such situations, the extension and the data in the
extension serves as triggers/extension code points to indicate what type
of data is to be expected in the subsequent messages. In order to achieve
that, if you do not define an extension code point, then your
extensionType registry starts exploding (with corner case extensions
littered around). While it is possible that way, IMHO, having a separate
code point and having a separate registry that provides a
categorization/registration of specific data types seems cleaner and
provides better management.

RFC4681 also does the same thing. It defines an extension and establishes
a registry to allow registering new UserMappings.

Going back to the problems of RFC5878 itself, the lack of length field
definitely needs to be fixed but the AuthorizationDataEntry being 1 byte
(while weird as you put it) is not really an issue.

Also as Yoav pointed out, due to lack of interest or whatever historic
reasons, there wasn't any other alternative/interest so RFC5878 was
published. When I actually had the need to pass DTCP data as authorization
data, RFC5878 provided the closest option (for better or for worse).

=20
So my (very biased :) counter question is if RFC5878 is fixable, why not
fix it and leverage the registry already defined. If it is obsoleted,
wouldn't an alternative still be needed?


Darshak



On 9/17/13 6:37 PM, "Trevor Perrin"  wrote:

>On Tue, Sep 17, 2013 at 2:27 PM, Marsh Ray  wrote:
>>> From: Trevor Perrin [mailto:trevp@trevp.net]
>>> Sent: Tuesday, September 17, 2013 8:32 AM
>>>
>>> 5878 itself is quite ugly, and riddled with errors and design flaws.
>>> Which is why I'm bringing this up.
>>
>> Now, now, be nice.
>
>Did you see the errata?
>
> * It's a weird extension structure, instead of having the standard
>2-byte type / 2-byte length fields, like TLS Extensions and 4680
>SupplementalDataEntry, each AuthorizationDataEntry has a (too-small)
>1-byte type field, and no length field.
>
> * Without the length fields it's not generically parseable (Ben
>suggests fixing that in the errata, but that breaks compatibility with
>the 5878 URLandHash structure).
>
> * The structure definitions in section 3 are wrong.
>
> * The submitted errata also argue that the length field for
>authz_data_list should be removed.  While I agree its redundant,
>that's another compatibility-breaking change, so I'm not sure about
>that.
>
>So I'm asking:  Is there a legitimate reason for the community to
>spend time fixing this RFC, implementing it in TLS libraries (it's not
>currently present in any libraries, I believe), and adapting new
>standards to use it?
>
>If not, can we mark it as "obsoleted" or similar?
>
>Projects like TACK, CT, and OpenSSL have wasted a lot of time
>evaluating 5878 and doing trial implementations before backing away
>from it.  I worry that people (like DTCP) [1] are going to keep making
>that mistake, as on the surface this seems like the
>"officially-condoned", IETF way to exchange new data through TLS.
>
>
>> Alternatively, if you know something exploitable please drop it while
>>it's hot.
>>
>>> I don't know how you could "extend" it to a larger code space.  I
>>>suppose we
>>> could nest another extension structure *inside* the 5878 structure, to
>>>see
>>> how many parsing layers we can bury extensions inside...
>>
>> 254 authZ data formats ought to be enough for anyone. But if not, sure,
>>we could indeed use 255 as a value to indicate a multi-byte value
>>follows.
>
>Don't we have some 65000+ unused TLS extensions?
>
>If you really want a few hundred numbers for "Private Use" or
>"Specification Required" extensions, why don't we just carve that out
>of the existing TLS Extension space?
>
>
>Trevor
>
>[1] http://tools.ietf.org/html/draft-dthakore-tls-authz-04
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls


From trevp@trevp.net  Tue Sep 17 22:52:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BB811E8122 for ; Tue, 17 Sep 2013 22:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pz4iEAtm2A66 for ; Tue, 17 Sep 2013 22:52:35 -0700 (PDT)
Received: from mail-we0-f178.google.com (mail-we0-f178.google.com [74.125.82.178]) by ietfa.amsl.com (Postfix) with ESMTP id 021D911E8116 for ; Tue, 17 Sep 2013 22:52:34 -0700 (PDT)
Received: by mail-we0-f178.google.com with SMTP id u57so5843889wes.23 for ; Tue, 17 Sep 2013 22:52: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:date :message-id:subject:from:to:cc:content-type; bh=qLe8ehki7/FfcZMxVnMIIid7umKqreQHsmyZM+nAl04=; b=ediNWcdSNHaMEYUM36i18j2w5BJoBGQ3zVh8Wjl6MriV0lWYGVClTMpMjUALlljFgV glcRlOu7zGB6uqw1DDF5L4K7hzADDCUq4R9ALs/ooruIf76onfBNcz6R+jj4/qHsiqoZ sw/hwylNGV22BdNReRYV/n7GDZvlmUQUjWOXkYn5PY4AlC82XyqiGHSQlnlRURy8Eulg tqvclaeTXntobruqC4DOlf0A/NoCkPSjJFyogdir/5IjTrLbLYrD8pj9re007q7Y0U9z IYcT2L4A1iMFJVESEHnARPyPWRskj3hPWXiPrQ2QSEo57a8iEO2A2QEH5sImq5ShnsQ3 TJFw==
X-Gm-Message-State: ALoCoQnDxI9QgCC9/izzE42St8X9n4RBgLxfX24I+MROIkth8xk+RA7yycBrSAI8TunZ0mZQL0+2
MIME-Version: 1.0
X-Received: by 10.194.21.131 with SMTP id v3mr292788wje.44.1379483553892; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Tue, 17 Sep 2013 22:52:33 -0700 (PDT)
X-Originating-IP: [199.83.223.81]
In-Reply-To: 
References:  
Date: Tue, 17 Sep 2013 22:52:33 -0700
Message-ID: 
From: Trevor Perrin 
To: Darshak Thakore 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 05:52:41 -0000

On Tue, Sep 17, 2013 at 10:04 PM, Darshak Thakore
 wrote:
> I'm trying to understand if the primary issue being pointed out here is
> about the errata in RFC5878 or the extension model that RFC5878 provides.

My primary question is what value (if any) 5878 provides.


> 1. You seem to be assuming that data is always flowing from the Client to
> the Server and that anything that a server may want to send can always be
> carried in the extension. That's not the only case. While it is possible
> (and in most scenarios sufficient) to carry data in the extension itself,
> certain extensions may require that actual data be passed in a specific
> MessageType (based on certain aspects of the handshake being
> accomplished).

I don't see your point.

A TLS ServerHello Extension can carry ~64 KB, same as the 5878
AuthorizationDataEntry.

If that's not sufficient and you need to modify the TLS Handshake
somehow based on signalling in the ClientHello and ServerHello, I
still don't see how 5878 makes any difference.


 In such situations, the extension and the data in the
> extension serves as triggers/extension code points to indicate what type
> of data is to be expected in the subsequent messages. In order to achieve
> that, if you do not define an extension code point, then your
> extensionType registry starts exploding (with corner case extensions
> littered around).

You're worried about excess consumption of code points?  Switching
from a 16-bit space to an 8-bit space *exacerbates* that problem, it
doesn't solve it.


> So my (very biased :) counter question is if RFC5878 is fixable, why not
> fix it and leverage the registry already defined. If it is obsoleted,
> wouldn't an alternative still be needed?

The alternative is to pass data via the standards-track mechanisms of
Hello Extensions and RFC 4680

Trevor

From pgut001@cs.auckland.ac.nz  Wed Sep 18 02:23:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF9D11E8210 for ; Wed, 18 Sep 2013 02:23:28 -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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgZ-gHfgV4hf for ; Wed, 18 Sep 2013 02:23:23 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 512CF11E81CF for ; Wed, 18 Sep 2013 02:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379496198; x=1411032198; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=f8RRB/XnFlFa/1aSh9n1BWeocMOdtu00zHosOSvNe2U=; b=Jtm8tPKrT7K66zvyaiVqmgxCIsd7KpSKCt8c5Ox2DlfaDKUP0whJ3bLx O89rwnSbQkmE/ShqkS7nnjP0My1DBQIgRCNCGA7ERyM8zmK4j8wO0apu5 AyyJFjcyHYQfZ6C1X1AXm9TBMB9AlQyR5GjuFaBJPt4Z9kgBAyb4JQKT/ Y=;
X-IronPort-AV: E=Sophos;i="4.90,929,1371038400"; d="scan'208";a="212795877"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Sep 2013 21:23:15 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 21:23:15 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60ULPV80i4g7SSR8+ETVJPfizk+A==
Date: Wed, 18 Sep 2013 09:23:14 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355673796@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 09:23:28 -0000

Yaron Sheffer  writes:=0A=
=0A=
>We would like to recommend using 2048-bit DH by both client and server=0A=
=0A=
Why 2048?  It's completely unnecessary, all it's going to do is discourage =
use=0A=
of PFS suites.=0A=
=0A=
Peter.=0A=

From yaronf.ietf@gmail.com  Wed Sep 18 02:32:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1367611E8215 for ; Wed, 18 Sep 2013 02:32:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.099
X-Spam-Level: 
X-Spam-Status: No, score=-103.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rzv0GFaYnmBD for ; Wed, 18 Sep 2013 02:32:53 -0700 (PDT)
Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE5211E821A for ; Wed, 18 Sep 2013 02:32:49 -0700 (PDT)
Received: by mail-bk0-f45.google.com with SMTP id mx11so2642700bkb.18 for ; Wed, 18 Sep 2013 02:32:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1sDuYnctWkHUW0TAIc5dtP+EtSgOdFG+0IeFvAdR618=; b=BMecS5whs3GHVWTkBharueVu0iHHcttGVyjepBF9tRoif5cDvXX96RG5EOFqZwRChc cwW6VQtvmehtN+fs6GNZdlEJXTOxlxANRJ/p7PcVuR5gSprkBtIQL28plib0Vs3QnIfi i6lcILCFfK2Dk/W9HuO5D88i1aHLV+Fota7IUPcfsYSFVwVhiutTsSOYoNYtJy13hcyF eNDX0nknGY0jB9R+YQo89N5vcdFWK5EWdVhRJ1FZDYP2lct56poMBXAcsyLA0rlNnVW5 AKDeB8QlIKTd/A5SzNmiB0Liqs+d3g/au29X7bquLrLvUXCNp8n7kINNILuoqZS7B7Xq CoUg==
X-Received: by 10.204.168.197 with SMTP id v5mr33419654bky.24.1379496753498; Wed, 18 Sep 2013 02:32:33 -0700 (PDT)
Received: from [10.0.0.140] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id jt14sm398449bkb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 02:32:32 -0700 (PDT)
Message-ID: <52397329.1080700@gmail.com>
Date: Wed, 18 Sep 2013 12:32:25 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C7355673796@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355673796@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 09:32:58 -0000

Hi Peter,

Please see the later discussion, in particular 
http://www.ietf.org/mail-archive/web/tls/current/msg09924.html.

Thanks,
	Yaron

On 09/18/2013 12:23 PM, Peter Gutmann wrote:
> Yaron Sheffer  writes:
>
>> We would like to recommend using 2048-bit DH by both client and server
>
> Why 2048?  It's completely unnecessary, all it's going to do is discourage use
> of PFS suites.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From pgut001@cs.auckland.ac.nz  Wed Sep 18 02:46:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6257111E8226 for ; Wed, 18 Sep 2013 02:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HPUucVgeT1x for ; Wed, 18 Sep 2013 02:46:01 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0855A11E821C for ; Wed, 18 Sep 2013 02:46:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379497561; x=1411033561; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=h5dRBKQ6SQ6Dwp7iigZXx7LjzzfxgQ6wo2q7G7/wSjk=; b=Z6qSpuOWrf0SdvfXJ0Uf0IgO+H8fUUNhvv1XBQtyZ62yOvd+UiVWWfcM REY1CVjKE8JEM5zx5bb6zvBpUkE5xD+y3u+mgeg24+QGW2iKVaSk/aUv1 fieZ19O/EyTFg68wR/rkXegmZDxTenccQDexFRLZaIpsWhZvufO0XGIgb Q=;
X-IronPort-AV: E=Sophos;i="4.90,929,1371038400"; d="scan'208";a="212797721"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Sep 2013 21:45:44 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 21:45:43 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: Ac60U9ewQ3I5YcUBQM2v2BwxednX3A==
Date: Wed, 18 Sep 2013 09:45:43 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73556737AA@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 09:46:14 -0000

Trevor Perrin  writes:=0A=
=0A=
>Does anyone care?  Has anyone written independent, interoperating versions=
 of=0A=
>these?=0A=
=0A=
Since it's an Experimental, does it really matter much?  The Experimental=
=0A=
tagging should already serve as a fairly strong here-be-dragons.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Wed Sep 18 02:54:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A8D11E821D for ; Wed, 18 Sep 2013 02:54:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnTCufqERmce for ; Wed, 18 Sep 2013 02:54:17 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 04BAB11E81C1 for ; Wed, 18 Sep 2013 02:54:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379498057; x=1411034057; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=e1I+n8tFKARGURvLCGrefMYPcNQea516y6uWPjhFR7c=; b=WhRfO766nBrln6W6IQsY8m5KtK/FDgJGhtXlGP77nzm2m7X1J5XedH2z j+1wKOzCudMd5HeXDqn4D+//+flMntTvDyqpXBsQ+23/tHUQPKg+dw9et jKX5IHRxocVivuNXFl4BG7U6WXQu6S3DPqbk7dYCq6qBbmRUvmh3s0DPZ Y=;
X-IronPort-AV: E=Sophos;i="4.90,929,1371038400"; d="scan'208";a="212798307"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 18 Sep 2013 21:54:14 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Wed, 18 Sep 2013 21:54:13 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60VQbt8ifxJYfMTlCcs4/yVb9S2A==
Date: Wed, 18 Sep 2013 09:54:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 09:54:22 -0000

Yaron Sheffer  writes:=0A=
=0A=
>Please see the later discussion, in particular=0A=
>http://www.ietf.org/mail-archive/web/tls/current/msg09924.html.=0A=
=0A=
I've been following the discussion, but none of it really supports going to=
=0A=
2048 rather than just 1280 or 1536.  In addition, as Yoav pointed out, ther=
e's=0A=
a big different between solving the DLP in 1024 bits and stealing an any-si=
ze-=0A=
you-want long-term RSA key.=0A=
=0A=
Peter.=0A=

From yaronf.ietf@gmail.com  Wed Sep 18 03:08:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 479B711E821F for ; Wed, 18 Sep 2013 03:08:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.199
X-Spam-Level: 
X-Spam-Status: No, score=-103.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwlVLS7pkTlE for ; Wed, 18 Sep 2013 03:08:18 -0700 (PDT)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by ietfa.amsl.com (Postfix) with ESMTP id 9A68211E8130 for ; Wed, 18 Sep 2013 03:08:16 -0700 (PDT)
Received: by mail-bk0-f53.google.com with SMTP id d7so2663477bkh.26 for ; Wed, 18 Sep 2013 03:08:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=b/XZ5RhaocaRFw2CqiI1oRdrxnSwHGdLQeYF0jiT+Bk=; b=ikjluru4eTIqGGacLxSHIAF6bQ0vw+70PmUThbqpGTJdKanb8qKelNmszi9wEW2oD4 RuXEJqjn47kbIgB/MrhR63a0MrXrwye4Yk+nDWEpentej6QsxCHPmxT5QQBB0iA+9iBV 4gdpCPTx5kg4We/VTTUOw+Ws5FzjcKk7w24yefDlVcsSicUxzifdKdVEiRbKtXU4ajNz ixh4BMiM0WKBqe9SZMdM10+IDRgcWvqpw38I9hUf7/C1j8NxH1qXnnbAsu2vOCAKOgkQ TilFYUYBAUT4h00XNehSnZe5mFlKn8Y1PKUclJBtTzKVlsbJhumB0RTf10NIIc1Q4PS5 4Oyg==
X-Received: by 10.204.102.136 with SMTP id g8mr951197bko.34.1379498880720; Wed, 18 Sep 2013 03:08:00 -0700 (PDT)
Received: from [10.0.0.140] (93-173-253-212.bb.netvision.net.il. [93.173.253.212]) by mx.google.com with ESMTPSA id b7sm489358bkg.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 03:08:00 -0700 (PDT)
Message-ID: <52397B7E.70204@gmail.com>
Date: Wed, 18 Sep 2013 13:07:58 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 10:08:25 -0000

Hi Peter,

I fully agree that PFS is indeed important. There are multiple issues 
with MODP DH in TLS (performance is just one of them). So I'd like to 
recommend EC DHE instead - which makes this discussion moot.

Thanks,
	Yaron

On 09/18/2013 12:54 PM, Peter Gutmann wrote:
> Yaron Sheffer  writes:
>
>> Please see the later discussion, in particular
>> http://www.ietf.org/mail-archive/web/tls/current/msg09924.html.
>
> I've been following the discussion, but none of it really supports going to
> 2048 rather than just 1280 or 1536.  In addition, as Yoav pointed out, there's
> a big different between solving the DLP in 1024 bits and stealing an any-size-
> you-want long-term RSA key.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From michael@stroeder.com  Wed Sep 18 07:22:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4022E11E82FB for ; Wed, 18 Sep 2013 07:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnkLggshU+LZ for ; Wed, 18 Sep 2013 07:22:00 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 26C1F11E811E for ; Wed, 18 Sep 2013 07:21:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 0878C60470; Wed, 18 Sep 2013 16:21:54 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnaUXwMrsIq9; Wed, 18 Sep 2013 16:21:49 +0200 (CEST)
Received: from srv1.stroeder.com (unknown [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 9767860400; Wed, 18 Sep 2013 14:21:49 +0000 (UTC)
To: Peter Gutmann , Yaron Sheffer 
In-Reply-To: <52397B7E.70204@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>, <52397B7E.70204@gmail.com>
From: "Michael =?UTF-8?B?U3Ryw7ZkZXI=?=" 
Date: Wed, 18 Sep 2013 16:21:49 +0200
Content-Type: text/plain; charset=UTF-8; format=fixed
MIME-Version: 1.0
Message-id: <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com>
Content-Transfer-Encoding: 8bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 14:22:13 -0000

On Wed, 18 Sep 2013 13:07:58 +0300 Yaron Sheffer  wrote
> There are multiple issues 
> with MODP DH in TLS (performance is just one of them).

Could you please elaborate on this.

Ciao, Michael.



From yaronf.ietf@gmail.com  Wed Sep 18 07:27:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B526611E8254 for ; Wed, 18 Sep 2013 07:27:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.68
X-Spam-Level: 
X-Spam-Status: No, score=-102.68 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfuDmvTJZvCI for ; Wed, 18 Sep 2013 07:27:37 -0700 (PDT)
Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) by ietfa.amsl.com (Postfix) with ESMTP id D10B111E811E for ; Wed, 18 Sep 2013 07:27:36 -0700 (PDT)
Received: by mail-bk0-f43.google.com with SMTP id mz13so2817336bkb.2 for ; Wed, 18 Sep 2013 07:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=XVedeHdy8P/+/Af+UcCMVklwYIQU1QI5WRc7GmDFbFw=; b=TtPXCFtibDoMFFdUjOACac1YAjCOO77VCFQdUtRxdRWUEIrfBaPyYfwmRJRbYhra6z cU2YXWTBh7cZNMgtLEwEPJAXa9v5GS7o8da+Mu39TG9m/UkWrboRlUxlOAPPqOOusHBR 3I3dX8c+dQWXjR62cyDTq07QU6YCZg7TDgfLqtSou7Ihn9bPS7BKfDoSHsQW4clWv+fj hYaKHCs2N/t8JjJFBJBpE1j/hVQRVezzYMHh3eWbgeHeZGmPoYKBRd3svCy7TKipY5xx m0+oBT+V2TwVVHE4vBvzRh7LJZm6Okb4lUoIH4ObDHVeVVYyQTZIecqO+qINfxo7vaHh scRQ==
X-Received: by 10.205.42.66 with SMTP id tx2mr576729bkb.43.1379514439342; Wed, 18 Sep 2013 07:27:19 -0700 (PDT)
Received: from [10.0.0.8] ([109.67.213.61]) by mx.google.com with ESMTPSA id pn6sm1034013bkb.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 07:27:18 -0700 (PDT)
Message-ID: <5239B845.6010606@gmail.com>
Date: Wed, 18 Sep 2013 17:27:17 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>, <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com>
In-Reply-To: <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 14:27:41 -0000

Hi Michael,

please see my mail message that started this thread, way back on Sunday :-)

http://www.ietf.org/mail-archive/web/tls/current/msg09903.html

Thanks,
	Yaron

On 09/18/2013 05:21 PM, Michael Ströder wrote:
> On Wed, 18 Sep 2013 13:07:58 +0300 Yaron Sheffer  wrote
>> There are multiple issues
>> with MODP DH in TLS (performance is just one of them).
>
> Could you please elaborate on this.
>
> Ciao, Michael.
>
>

From prvs=29737ce98b=uri@ll.mit.edu  Wed Sep 18 09:14:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DDD11E8126 for ; Wed, 18 Sep 2013 09:14:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.981
X-Spam-Level: 
X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IcJ3HgKCavgF for ; Wed, 18 Sep 2013 09:14:05 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id EA71511E8124 for ; Wed, 18 Sep 2013 09:14:04 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8IFxX89030565; Wed, 18 Sep 2013 12:14:01 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Yaron Sheffer 
Date: Wed, 18 Sep 2013 12:13:48 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60ig63ugMoRrr3S2a9jXXHeZxvZw==
Message-ID: <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu>
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>, <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com>
In-Reply-To: <5239B845.6010606@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail=_EBC0DA6A-C2B2-46C2-BC50-7FF26795999D"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_07:2013-09-18, 2013-09-18, 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-1305240000 definitions=main-1309180075
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 16:14:10 -0000

--Apple-Mail=_EBC0DA6A-C2B2-46C2-BC50-7FF26795999D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

I believe that for ephemeral DH 2048 bits is a huge overkill. In fact, =
1536 is likely to be an overkill as well. I think 1280 bits would be =
sufficient for the next few years, and perhaps ECC patents will expire =
by then? In any case, I'd vote against anything (ephemeral DH-related :) =
larger than 1536 bits.

TNX!

P.S. It should be obvious that PFS is *far* more important than =
protecting one session key.
--
Regards,
Uri               



On Sep 18, 2013, at 10:27 , Yaron Sheffer  wrote:

> Hi Michael,
>=20
> please see my mail message that started this thread, way back on =
Sunday :-)
>=20
> http://www.ietf.org/mail-archive/web/tls/current/msg09903.html
>=20
> Thanks,
> 	Yaron
>=20
> On 09/18/2013 05:21 PM, Michael Str=F6der wrote:
>> On Wed, 18 Sep 2013 13:07:58 +0300 Yaron Sheffer =
 wrote
>>> There are multiple issues
>>> with MODP DH in TLS (performance is just one of them).
>>=20
>> Could you please elaborate on this.
>>=20
>> Ciao, Michael.
>>=20
>>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_EBC0DA6A-C2B2-46C2-BC50-7FF26795999D
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 - http://gpgtools.org

iQEcBAEBAgAGBQJSOdE8AAoJEAUj5dJ7jKh7/vAH/2exOadGbvyl9Q8UszVNjwJK
FBqKHJVO8UuO8kjtbS1NZ2TzmxPl5GPoblHlVAXCNFiwQTJGMNXGNKrmxqM0DmPK
K5Hbes4iuXjf4N9AGBfKjx3ioqM9p7er5pOsv/tm0jRHK6tJgQ3T6h+9FR8GmbAr
2VBanL4QFKTcr+4oOvcpFRYYrWtFTfyM/Ld3dJ4d2Y14BaRthQPbslFDh1VKpAPO
AvEW92XQDOIECUTwb8M7wXJEgggw5PpDlMqoHlEJnA0tdvXdM8GuEKPRgu9qlVQR
ZcwQY1Cj6hf2shbDmTYeDM7Xo6DxLcz7O0jcNIOrw4ZfDA3rDiJLYcI7/EvGdIc=
=PjvH
-----END PGP SIGNATURE-----

--Apple-Mail=_EBC0DA6A-C2B2-46C2-BC50-7FF26795999D--

From hughejp@mac.com  Wed Sep 18 09:46:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE3011E8241 for ; Wed, 18 Sep 2013 09:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level: 
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swJILF9Pf6W8 for ; Wed, 18 Sep 2013 09:46:02 -0700 (PDT)
Received: from st11p06mm-asmtp001.mac.com (st11p06mm-asmtpout004.mac.com [17.172.124.249]) by ietfa.amsl.com (Postfix) with ESMTP id EDF6C11E80E4 for ; Wed, 18 Sep 2013 09:46:01 -0700 (PDT)
Received: from [10.0.1.4] (unknown [184.69.15.210]) by st11p06mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTB00JD6YKGYHC0@st11p06mm-asmtp001.mac.com> for tls@ietf.org; Wed, 18 Sep 2013 16:45:55 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-18_07:2013-09-18, 2013-09-18, 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-1308280000 definitions=main-1309180080
Content-type: multipart/alternative; boundary="Apple-Mail=_E43AAAAE-A015-45A5-B87F-9BFDF8179327"
MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: james hughes 
In-reply-to: <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu>
Date: Wed, 18 Sep 2013 09:45:51 -0700
Message-id: <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com>
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz> <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu>
To: "Blumenthal, Uri - 0558 - MITLL" 
X-Mailer: Apple Mail (2.1508)
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 16:46:07 -0000

--Apple-Mail=_E43AAAAE-A015-45A5-B87F-9BFDF8179327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1



On Sep 18, 2013, at 9:13 AM, "Blumenthal, Uri - 0558 - MITLL" =
 wrote:

> I believe that for ephemeral DH 2048 bits is a huge overkill. In fact, =
1536 is likely to be an overkill as well. I think 1280 bits would be =
sufficient for the next few years, and perhaps ECC patents will expire =
by then? In any case, I'd vote against anything (ephemeral DH-related :) =
larger than 1536 bits.
>=20
> TNX!
>=20
> P.S. It should be obvious that PFS is *far* more important than =
protecting one session key.

Please read my posting of 9/10. 2048 is required now. In this case it =
seems that the French government is providing sound advice.=20

On Sep 10, 2013, at 9:00 AM, james hughes  wrote:

> Lastly, going a partial step seems strange also. Why do we what to put =
ourselves through this again so soon? The French government suggests =
2048 now (for both RSA and DHE), and will only last 6 years. =46rom=20
> 	http://www.ssi.gouv.fr/IMG/pdf/RGS_B_1.pdf
>=20
>> La taille minimale du module est de 2048 bits, pour une utilisation =
ne devant pas depasser lannee 2020.
> The minimum size of the modulus is 2048 bits for use not to exceed =
2020.
>=20
>> Pour une utilisation au-dela de 2020, la taille minimale du module =
est de 4096 bits
> For use beyond a 2020, the minimum module size is 4096 bits
>=20
>=20
> Pardon the bad cut/paste and google translate, but I believe you get =
the point.=20




--Apple-Mail=_E43AAAAE-A015-45A5-B87F-9BFDF8179327
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

uri@ll.mit.edu> wrote:
I believe =
that for ephemeral DH 2048 bits is a huge overkill. In fact, 1536 is =
likely to be an overkill as well. I think 1280 bits would be sufficient =
for the next few years, and perhaps ECC patents will expire by then? In =
any case, I'd vote against anything (ephemeral DH-related :) larger than =
1536 bits.

TNX!

P.S. It should be obvious that PFS is =
*far* more important than protecting one session =
key.

Please read my posting of 9/10. 2048 =
is required now. In this case it seems that the French government is =
providing sound advice. 

On Sep =
10, 2013, at 9:00 AM, james hughes <hughejp@me.com> wrote:

Lastly,=
 going a partial step seems strange also. Why do we what to put =
ourselves through this again so soon? The French government suggests =
2048 now (for both RSA and DHE), and will only last 6 years. =
From 

La taille minimale du module est de 2048 bits, pour une =
utilisation ne devant pas depasser lannee 2020.
The minimum =
size of the modulus is 2048 bits for use not to exceed =
2020.

Pour une utilisation au-dela de =
2020, la taille minimale du module est de 4096 bits
For use =
beyond a 2020, the minimum module size is 4096 bits

Pardon the bad =
cut/paste and google translate, but I believe you get the =
point. 


=

--Apple-Mail=_E43AAAAE-A015-45A5-B87F-9BFDF8179327--

From hughejp@mac.com  Wed Sep 18 10:14:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C504211E810B for ; Wed, 18 Sep 2013 10:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.447
X-Spam-Level: 
X-Spam-Status: No, score=0.447 tagged_above=-999 required=5 tests=[AWL=-3.294,  BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294,  HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byAYOfnejYsO for ; Wed, 18 Sep 2013 10:14:06 -0700 (PDT)
Received: from st11p06mm-asmtp002.mac.com (st11p06mm-asmtpout005.mac.com [17.172.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id 61A3311E826E for ; Wed, 18 Sep 2013 10:14:04 -0700 (PDT)
Received: from [10.0.1.4] (unknown [184.69.15.210]) by st11p06mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTB00CX7ZV705B0@st11p06mm-asmtp002.mac.com> for tls@ietf.org; Wed, 18 Sep 2013 10:14:02 -0700 (PDT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 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-1308280000 definitions=main-1309180084
Content-type: multipart/alternative; boundary="Apple-Mail=_9BB56C4A-6A24-4E69-8041-CB8237894538"
MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: james hughes 
In-reply-to: <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com>
Date: Wed, 18 Sep 2013 10:13:54 -0700
Message-id: 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz> <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu> <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com>
To: "Blumenthal, Uri - 0558 - MITLL" 
X-Mailer: Apple Mail (2.1508)
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 17:14:19 -0000

--Apple-Mail=_9BB56C4A-6A24-4E69-8041-CB8237894538
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Sep 18, 2013, at 9:13 AM, "Blumenthal, Uri - 0558 - MITLL" =
 wrote:

> I believe that for ephemeral DH 2048 bits is a huge overkill. In fact, =
1536 is likely to be an overkill as well. I think 1280 bits would be =
sufficient for the next few years,


Why are we suggesting something that will be sufficient for the next few =
years? IMHO, it will take a few years to implement this change. By the =
time this has been adopted, will be in trouble again.

>  and perhaps ECC patents will expire by then?=20


But the trust in ECC will not have recovered by then.

Is the complaint speed?  We are arguing about a key exchange that goes =
from ~1ms to ~3ms. Yes, this is more but this is absolutely not a =
problem for PCs or even phones or tablets especially in the light of =
session keep alive and other techniques that allow a key exchange to =
last a while.=20

On Sep 9, 2013, at 7:30 PM, Michael Str=F6der  =
wrote:


> MBA-2:tmp synp$ openssl speed dsa1024 dsa2048
[=85]
>                  sign    verify    sign/s verify/s
> dsa 1024 bits 0.000445s 0.000515s   2247.6   1941.8
> dsa 2048 bits 0.001416s 0.001733s    706.4    577.2


Is the complaint that the server load is too high?=20

Why are you suggesting such a partial step in light of Moore's law? If =
1024 is not large enough, how long will 1200 last? Do we think that =
Moore's law is not relevant (massively parallel operations already =
dominate the time to recover a key, so single thread performance is a =
moot point). Do you assume that the value of data goes down so fast that =
using a key that will be easy to recover in 5 years is "good enough"?=

--Apple-Mail=_9BB56C4A-6A24-4E69-8041-CB8237894538
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

uri@ll.mit.edu> =
wrote:
I believe that for ephemeral DH 2048 bits is a huge =
overkill. In fact, 1536 is likely to be an overkill as well. I think =
1280 bits would be sufficient for the next few =
years,

Why are we suggesting =
something that will be sufficient for the next few years? IMHO, it will =
take a few years to implement this change. By the time this has been =
adopted, will be in trouble =
again.

 and =
perhaps ECC patents will expire by =
then? 

But the trust in =
ECC will not have recovered by then.

Is the =
complaint speed?  We are arguing about a key exchange that =
goes from ~1ms to ~3ms. Yes, this is more but this is absolutely not a =
problem for PCs or even phones or tablets especially in the light of =
session keep alive and other techniques that allow a key exchange to =
last a while. 

On Sep 9, 2013, at =
7:30 PM, Michael Str=F6der <michael at stroeder.com> =
wrote:

MBA-2:tmp synp$ openssl speed dsa1024 =
dsa2048
[=85]
                =
 sign    verify    sign/s =
verify/s
dsa 1024 bits 0.000445s =
0.000515s   2247.6   1941.8
dsa 2048 bits 0.001416s 0.001733s    706.4 =
   577.2

Is =
the complaint that the server load is too =
high? 

Why are you suggesting such a =
partial step in light of Moore's law? If 1024 is not large enough, how =
long will 1200 last? Do we think that Moore's law is not relevant =
(massively parallel operations already dominate the time to recover a =
key, so single thread performance is a moot point). Do you assume =
that the value of data goes down so fast that using a key that will be =
easy to recover in 5 years is "good enough"?
=

--Apple-Mail=_9BB56C4A-6A24-4E69-8041-CB8237894538--

From prvs=29737ce98b=uri@ll.mit.edu  Wed Sep 18 10:15:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D944711E826E for ; Wed, 18 Sep 2013 10:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.962
X-Spam-Level: 
X-Spam-Status: No, score=-5.962 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGzLTPIjytE1 for ; Wed, 18 Sep 2013 10:15:31 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 491BE11E810B for ; Wed, 18 Sep 2013 10:15:24 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8IHCd7v004615; Wed, 18 Sep 2013 13:15:15 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Bill Frantz 
Date: Wed, 18 Sep 2013 13:15:10 -0400
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: Ac60kqF2u8z+UsLiSAODUTVQL14a8w==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail=_38F6A994-5086-4360-8415-0DEEAA9DBF88"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_07:2013-09-18, 2013-09-18, 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-1305240000 definitions=main-1309180082
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related	to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 17:15:36 -0000

--Apple-Mail=_38F6A994-5086-4360-8415-0DEEAA9DBF88
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Bill,

In short, I concur. Though some hardware is known to be more secure than =
the other. ;)
--
Regards,
Uri               



On Sep 17, 2013, at 20:21 , Bill Frantz  wrote:

> On 9/17/13 at 8:45 AM, msj@nthpermutation.com (Michael StJohns) wrote:
>=20
>> Um.  No, not if you designed things properly.  It should be=20
>> possible for any protocol the IETF designs to do all the crypto=20
>> operation inside a hardware module and not depend on the weak=20
>> security of a general purpose computer.
>=20
> While I have no objections to this requirement, I'm not sure=20
> that hardware is more secure than software if your attacker is a=20
> large country national crypto agency or sophisticated criminal=20
> gangs. I worry about Russia, England, China, France etc. as well=20
> as the USA.
>=20
> Without taking the chips apart, even validated hardware can be=20
> replaced at the chip foundry with a different implementation=20
> which leaks keys via paths such as IVs or uses bogus random numbers.
>=20
> These attacks can be minimized by using forward security -- more=20
> keys to attack/leak; making IVs deterministic based on the plain=20
> text and checked; using a cypher in counter mode for IVs,=20
> calculating them separately at each end, and not transmitting=20
> them etc.
>=20
> There is no real safe heaven these days.
>=20
> Cheers - Bill
>=20
> =
-----------------------------------------------------------------------
> Bill Frantz        | Truth and love must prevail  | Periwinkle
> (408)356-8506      | over lies and hate.          | 16345=20
> Englewood Ave
> www.pwpconsult.com |               - Vaclav Havel | Los Gatos,=20
> CA 95032
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


--Apple-Mail=_38F6A994-5086-4360-8415-0DEEAA9DBF88
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 - http://gpgtools.org

iQEcBAEBAgAGBQJSOd+eAAoJEAUj5dJ7jKh7yF8IAKLyjAtADrWICjoOfy0CIB+E
DLvvv7Jjt0dxiMYxUmtSibsKio2qFdUg5piACpgmuyuk9Yl4bTSAD1NGD5bUgSJK
z5tnvmuZtxJiC4/Ttdz2vTaSdHud7VzLBa4viVaB5mIrnc9IYIV/uhT9sUflgNcn
UzyaoTQBANUP9ngt0FGGLa933J+uod08phKie/OMwmGuVW1QpAs+SXONbD7GKZOP
kyjtCWUFrSHd52FLHnhbYaxtVQPgmYhvX86HqZcxP6syabu1GzqPzFE9Xh5uJWKv
vwVVjW6IveG/A1FLbEL3XZ4b5fm2gHwXtNT1wtinxS5+7GlkBVBPaEyg+6rl80c=
=NwGO
-----END PGP SIGNATURE-----

--Apple-Mail=_38F6A994-5086-4360-8415-0DEEAA9DBF88--

From prvs=29737ce98b=uri@ll.mit.edu  Wed Sep 18 10:34:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33D411E810B for ; Wed, 18 Sep 2013 10:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.653
X-Spam-Level: 
X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=-3.395, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GubaNOxqjhR for ; Wed, 18 Sep 2013 10:34:37 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 320B811E80E4 for ; Wed, 18 Sep 2013 10:34:36 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8IHY6Ot002348; Wed, 18 Sep 2013 13:34:35 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: james hughes 
Date: Wed, 18 Sep 2013 13:34:31 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60lVUp7r4tWQATQ+uVwEBw3sx87g==
Message-ID: <8E95757A-5DBB-4FBC-8EBC-2F28F47903CB@ll.mit.edu>
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz> <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu> <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail=_44B2CA37-DAE2-4612-8537-EBFF198561BD"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 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-1305240000 definitions=main-1309180087
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 17:34:42 -0000

--Apple-Mail=_44B2CA37-DAE2-4612-8537-EBFF198561BD
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6D131F17-8114-4185-98BA-FB488A06F54A"


--Apple-Mail=_6D131F17-8114-4185-98BA-FB488A06F54A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

On Sep 18, 2013, at 13:13 , james hughes  wrote:
> On Sep 18, 2013, at 9:13 AM, "Blumenthal, Uri - 0558 - MITLL" =
 wrote:
>=20
>> I believe that for ephemeral DH 2048 bits is a huge overkill. In =
fact, 1536 is likely to be an overkill as well. I think 1280 bits would =
be sufficient for the next few years,
>=20
>=20
> Why are we suggesting something that will be sufficient for the next =
few years? IMHO, it will take a few years to implement this change. By =
the time this has been adopted, will be in trouble again.

I personally think that for *ephemeral* DH even 1024 bits still is =
enough. And would *much* prefer having PFS now with individual session =
keys at somewhat greater risk, over a system that is very secure and =
completely useless because nobody bothered to deploy it.

>>  and perhaps ECC patents will expire by then?=20
>=20
>=20
> But the trust in ECC will not have recovered by then.

I trust ECC. My only problem with it is its set of patents. Whoever =
doesn't trust ECC - feel free to go to 10K RSA keys. :-)


> Is the complaint speed?  We are arguing about a key exchange that goes =
from ~1ms to ~3ms. Yes, this is more but this is absolutely not a =
problem for PCs or even phones or tablets especially in the light of =
session keep alive and other techniques that allow a key exchange to =
last a while.=20

What about servers? An individual PC (and its user :) with one TLS =
connection can afford 30 seconds of session establishment time, no big =
deal. A server might not like it.


> On Sep 9, 2013, at 7:30 PM, Michael Str=F6der  wrote:
>=20
>> MBA-2:tmp synp$ openssl speed dsa1024 dsa2048
> [=85]
>>                  sign    verify    sign/s verify/s
>> dsa 1024 bits 0.000445s 0.000515s   2247.6   1941.8
>> dsa 2048 bits 0.001416s 0.001733s    706.4    577.2
>=20
>=20
> Is the complaint that the server load is too high?=20

It probably is. But I'll let Michael speak for himself. ;)

> Why are you suggesting such a partial step in light of Moore's law? If =
1024 is not large enough, how long will 1200 last? Do we think that =
Moore's law is not relevant (massively parallel operations already =
dominate the time to recover a key, so single thread performance is a =
moot point). Do you assume that the value of data goes down so fast that =
using a key that will be easy to recover in 5 years is "good enough"?

To repeat myself, I personally think that 1024 bits is large enough for =
*ephemeral* DH. And yes, I assume that value of individual sessions =
would go down fast enough, faster than the ability to scoop them all and =
crack in bulk. So with PFS, an ordinary session's security lifetime of 5 =
years (please note, that we don't know whether in 5 years 1024-bit DH =
would be crackable that easily, let alone 1280) would be fine with me. =
If you think that in 5 years 1024-bit DH will be trivially crackable - =
I'd like to see some evidence to support it.

--Apple-Mail=_6D131F17-8114-4185-98BA-FB488A06F54A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

hughejp@mac.com> =
wrote:
On Sep 18, 2013, at 9:13 AM, "Blumenthal, =
Uri - 0558 - MITLL" <uri@ll.mit.edu> wrote:

I believe =
that for ephemeral DH 2048 bits is a huge overkill. In fact, 1536 is =
likely to be an overkill as well. I think 1280 bits would be sufficient =
for the next few years,

Why are we =
suggesting something that will be sufficient for the next few years? =
IMHO, it will take a few years to implement this change. By the time =
this has been adopted, will be in trouble =
again.

I personally think that =
for *ephemeral* DH even 1024 bits still is enough. And would *much* =
prefer having PFS now with individual session keys at somewhat greater =
risk, over a system that is very secure and completely useless because =
nobody bothered to deploy it.

 and perhaps ECC patents will expire by =
then? 

But the trust in ECC =
will not have recovered by =
then.

I trust ECC. My only =
problem with it is its set of patents. Whoever doesn't trust ECC - feel =
free to go to 10K RSA keys. =
:-)


Is the complaint =
speed?  We are arguing about a key exchange that goes from =
~1ms to ~3ms. Yes, this is more but this is absolutely not a problem for =
PCs or even phones or tablets especially in the light of session keep =
alive and other techniques that allow a key exchange to last a =
while. 

What about =
servers? An individual PC (and its user :) with one TLS connection can =
afford 30 seconds of session establishment time, no big deal. A server =
might not like it.


On Sep 9, 2013, at 7:30 =
PM, Michael Str=F6der <michael at stroeder.com> =
wrote:
MBA-2:tmp =
synp$ openssl speed dsa1024 dsa2048
[=85]
        =
         sign    verify   =
 sign/s verify/s
dsa 1024 =
bits 0.000445s 0.000515s   2247.6   =
1941.8
dsa 2048 bits 0.001416s =
0.001733s    706.4   =
 577.2

Is the =
complaint that the server load is too =
high? 

It probably is. But =
I'll let Michael speak for himself. ;)

Why are you =
suggesting such a partial step in light of Moore's law? If 1024 is not =
large enough, how long will 1200 last? Do we think that Moore's law is =
not relevant (massively parallel operations already dominate the time to =
recover a key, so single thread performance is a moot point). Do =
you assume that the value of data goes down so fast that using a key =
that will be easy to recover in 5 years is "good =
enough"?

To repeat myself, I =
personally think that 1024 bits is large enough for *ephemeral* DH. And =
yes, I assume that value of individual sessions would go down fast =
enough, faster than the ability to scoop them all and crack in bulk. So =
with PFS, an ordinary session's security lifetime of 5 years (please =
note, that we don't know whether in 5 years 1024-bit DH would be =
crackable that easily, let alone 1280) would be fine with me. If you =
think that in 5 years 1024-bit DH will be trivially crackable - I'd like =
to see some evidence to support it.
=

--Apple-Mail=_6D131F17-8114-4185-98BA-FB488A06F54A--

--Apple-Mail=_44B2CA37-DAE2-4612-8537-EBFF198561BD
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 - http://gpgtools.org

iQEcBAEBAgAGBQJSOeQnAAoJEAUj5dJ7jKh7h/EH/3e9sLMd/EyNvUkacGJkytnD
JMQpDusfztu3Mh55EcLBZPbjwjixovkBPVWP62cAjOvM7zAnaUiSmrPBFeZbytDh
qpFnzOhM87+h+1N/PnZD9An/91YNq0+kEgr8okTlPfoVFueo8HDkb/f+H7Ozt+jY
cpjRrhP0h61CmkLzc8TWBggeV6fsIySHX3rP3ROX3YSIRFj4Y1Okqt5oEbXba3TE
8s4WxWOHUZW8urST/I57o+UXi2glcK3Shtq12xw1PQlO5wQo5ugOjUnG3qnu7k/7
JjulzVYwktTX9R+eP8elDyXkCVXb2gKJqD2pq7W4PsTYGrQdevVJFVMa1R34elI=
=ZYx4
-----END PGP SIGNATURE-----

--Apple-Mail=_44B2CA37-DAE2-4612-8537-EBFF198561BD--

From mrex@sap.com  Wed Sep 18 10:51:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C428B11E80EC for ; Wed, 18 Sep 2013 10:51:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.187
X-Spam-Level: 
X-Spam-Status: No, score=-10.187 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5q27MzGErXBz for ; Wed, 18 Sep 2013 10:51:28 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3211D11E80A2 for ; Wed, 18 Sep 2013 10:51:27 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8IHpIeu010995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Sep 2013 19:51:18 +0200 (MEST)
In-Reply-To: 
To: Trevor Perrin 
Date: Wed, 18 Sep 2013 19:51:18 +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: <20130918175118.A853A1A97F@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 18 Sep 2013 17:51:47 -0000
X-List-Received-Date: Wed, 18 Sep 2013 17:51:47 -0000

Trevor Perrin wrote:
>
> Yoav Nir  wrote:
> >
> > RFC 5878 is an experimental RFC. If you've looked at its history,
> > it was approved by the IESG in 2006, and an IPR issue surfaced,
> > so approval was withdrawn, and the draft lay dormant for 3 years.
> > If during those three years anyone had come up with some other
> > draft describing an authorization extension, I think that would
> > have been approved instead.
> 
> Why is there need of an "authorization extension"?

The rfc5878 seemed to have a use case, might have documented what they
had implemented, and just wanted to get this published.

Quoting from the Title page of rfc5878:

  http://tools.ietf.org/html/rfc5878

   Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for examination, experimental implementation, and
   evaluation.

If a document is published by the IETF, "Experimental" is the biggest
warning sign that we have to caution consumers, except for refusing
to publish.


housley-tls-authz-extns specifically had an IPR issue, which by itself
caused active _disinterest_ in the document, I assume:

  http://www.ietf.org/mail-archive/web/tls/current/msg01523.html


Btw. there was an announcement of an implementation of both
rfc4680 and housley-tls-authz-extns in GnuTLS in 2007:
  http://www.ietf.org/mail-archive/web/tls/current/msg01518.html


> 
> TLS already has well-designed, standards-track ways of passing
> extension data back and forth:
> 
> Client -> Server : ClientHello Extension
> Client <- Server : ServerHello Extension
> Client -> Server : SupplementalData (RFC 4680)
> 
> Why is that not sufficient?

It would be sufficient.

If the stuff described in rfc5878 would have been proposed after
rfc4680 existed, it probably would have used it.  But the history
of both documents suggests that housley-tls-authz-00 is actually older
than the initial draft for rfc4680:

  https://datatracker.ietf.org/doc/rfc5878/history/
  https://datatracker.ietf.org/doc/rfc4680/history/

If you combine this kind of history with a combination of
"lack of interest" and "active disinterest because of IPR issue",
then rfc5878@Experimental is what might happen.  I naively assume that
tls-authz-extns would have died silently if Russ had not been a coauthor.


If you want to create an alternative to rfc5878 that makes proper use
of rfc4680 -- go ahead.  But such an alternative might subject to the same
IPR claims as rfc5878, so it might be the same hard sell as tls-authz-extns.


-Martin

From michael@stroeder.com  Wed Sep 18 11:25:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1E11E81D5 for ; Wed, 18 Sep 2013 11:25:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.005
X-Spam-Level: 
X-Spam-Status: No, score=-0.005 tagged_above=-999 required=5 tests=[AWL=-3.294, BAYES_00=-2.599, FB_WORD1_END_DOLLAR=3.294, FB_WORD2_END_DOLLAR=3.294, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkneNsL9qSmC for ; Wed, 18 Sep 2013 11:25:33 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 44DD211E80F6 for ; Wed, 18 Sep 2013 11:25:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 1C7FF60234 for ; Wed, 18 Sep 2013 20:25:19 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzZKipLud2Xt for ; Wed, 18 Sep 2013 20:25:12 +0200 (CEST)
Received: from nb2.stroeder.local (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id BD6136017F for ; Wed, 18 Sep 2013 18:25:11 +0000 (UTC)
Message-ID: <5239F008.5000208@stroeder.com>
Date: Wed, 18 Sep 2013 20:25:12 +0200
From: =?windows-1252?Q?Michael_Str=F6der?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>	<52397B7E.70204@gmail.com>	<98ca985ffce946c42315e4e03db57747@srv1.stroeder.com>	<5239B845.6010606@gmail.com>	<958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu>	<4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090106010207060309060903"
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 18:25:37 -0000

This is a cryptographically signed message in MIME format.

--------------ms090106010207060309060903
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

James,

you got the citation wrong:

james hughes wrote:
> On Sep 9, 2013, at 7:30 PM, Michael Str=F6der =
 wrote:
>=20
>> MBA-2:tmp synp$ openssl speed dsa1024 dsa2048
> [=85]
>>                  sign    verify    sign/s verify/s
>> dsa 1024 bits 0.000445s 0.000515s   2247.6   1941.8
>> dsa 2048 bits 0.001416s 0.001733s    706.4    577.2
>=20
>=20
> Is the complaint that the server load is too high?=20

Numbers above were provided by Yoav as follow-up to my question. [1]

Personally I'm not scared by server load.

Ciao, Michael.

[1] http://www.ietf.org/mail-archive/web/tls/current/msg09836.html


--------------ms090106010207060309060903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE4MTgyNTEyWjAj
BgkqhkiG9w0BCQQxFgQUWCxPFLB6R+GItm4BYIeVOC3YftcwbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAFp637btuC0xnTXZfNGc5MOQ8NoY6DDw/
5Fk/TlhIdU3QL5jbBtZ3dZPOvVFFyEnvOWM46pYORHlog6XDWTh3hLy0niQnMRq2tvNUd11/
lECeQyCSahRKJGvIXhwTQ20OV3Nwp1L2sTBTbRViHFpFqsOYE73nO2ZiJl1cfp6oysKq87GA
VBELxmGMt9Bb0+24Kdc4FV5WEOfB+YaPftiCd4BrmO+I7WwCUAagfMiP+EWEJ8kT2EjX1O84
3+2shZ18l1okhwv4iLlYkRMhNnXQ2VkBQRFSupG/gz0iY5+lD5lWq07gWM6f6HFTzDDM5bAz
fBTtpbyk3Rut0iNfOSM/FwAAAAAAAA==
--------------ms090106010207060309060903--

From trevp@trevp.net  Wed Sep 18 11:37:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770CE11E8119 for ; Wed, 18 Sep 2013 11:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXrDej4iFovu for ; Wed, 18 Sep 2013 11:37:01 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7C711E8108 for ; Wed, 18 Sep 2013 11:37:01 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id w61so6992776wes.31 for ; Wed, 18 Sep 2013 11:37:00 -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=at1HhawljOPOKyZTtm053+oKzew6s+NuDEcenqb0hwQ=; b=TFi1tI6EFPSdXjwLffC9II7h8TpWMONt/SQmNW8tow+jl0qBdfDTnLZt0Oj7txINnn NxzkUnIFL2POjZp5YgdWIC5plotVZqwI1TrBzUM0PAClBxEmDWJuCpNT4mhclU3OAnG1 P7HO+As5DVfxhDe+14vjn0stLUFNNTeYQ5jLUWOqM/H3PmOfqjVkMZ8J7BVt1P6ocU6U z7nZij6E/DJoXVDdkiclXPYs9goblqtak+C9SAsVv7vTNiiaX9Q27g29MbjXaLkLVp96 mwN721omLoOjasrZ5n80ChiVN6QTEl4cJiq0vmnCV1iAe+NpsbpEpvXjOyTgiYRrFdab ZwKQ==
X-Gm-Message-State: ALoCoQlmAQze57yVZvuqRs0I4wNIOMYMWsRIDNnxsSuvS4iJR1P9Jb/c/v7eNzLf6wOA0qKTiL+9
MIME-Version: 1.0
X-Received: by 10.180.160.165 with SMTP id xl5mr8251816wib.48.1379529420526; Wed, 18 Sep 2013 11:37:00 -0700 (PDT)
Received: by 10.216.61.13 with HTTP; Wed, 18 Sep 2013 11:37:00 -0700 (PDT)
X-Originating-IP: [76.14.67.86]
In-Reply-To: <20130918175118.A853A1A97F@ld9781.wdf.sap.corp>
References:  <20130918175118.A853A1A97F@ld9781.wdf.sap.corp>
Date: Wed, 18 Sep 2013 11:37:00 -0700
Message-ID: 
From: Trevor Perrin 
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 18:37:06 -0000

On Wed, Sep 18, 2013 at 10:51 AM, Martin Rex  wrote:
> Trevor Perrin wrote:
>>
>
> If a document is published by the IETF, "Experimental" is the biggest
> warning sign that we have to caution consumers, except for refusing
> to publish.

The "Experimental" marking wasn't enough to prevent people like CT,
TACK, DTCP, and OpenSSL wasting a lot of time evaluating this and
trying to use it in the last couple of years.

A bunch of code was submitted into OpenSSL for this, then had to be
ripped out, CT specs were written for it, then rewritten,  and DTCP is
still grappling with this (see Darshak's email in this thread).

If 5878 is truly redundant with RFC 5246 and 4680 then I think this
group should consider marking it "obsoleted" to steer people away from
these mistakes.


> housley-tls-authz-extns specifically had an IPR issue, which by itself
> caused active _disinterest_ in the document, I assume:
>
>   http://www.ietf.org/mail-archive/web/tls/current/msg01523.html

Sure, I assume that's why no-one reviewed it carefully.


> Btw. there was an announcement of an implementation of both
> rfc4680 and housley-tls-authz-extns in GnuTLS in 2007:
>   http://www.ietf.org/mail-archive/web/tls/current/msg01518.html

GnuTLS support of authz-extns was removed several months later, and
the implementor opposed publication as an RFC:

http://www.ietf.org/mail-archive/web/ietf/current/msg48545.html


> If the stuff described in rfc5878 would have been proposed after
> rfc4680 existed, it probably would have used it.

5878 *DOES* use 4680, that's why it's so pointless.  It's a (bad)
extension mechanism nested inside of better ones.


> If you want to create an alternative to rfc5878 that makes proper use
> of rfc4680 -- go ahead.  But such an alternative might subject to the same
> IPR claims as rfc5878, so it might be the same hard sell as tls-authz-extns.

There's no need for an alternative.

TLS already has well-designed, standards-track extension mechanisms,
in the form of Hello Extensions and 4680 SupplementalData.


Trevor

From mike-list@pobox.com  Wed Sep 18 11:45:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C7A11E8108 for ; Wed, 18 Sep 2013 11:45:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idWG-K0sH1ul for ; Wed, 18 Sep 2013 11:45:42 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D999D11E810B for ; Wed, 18 Sep 2013 11:45:40 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F33ABD810 for ; Wed, 18 Sep 2013 14:45:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:content-type :content-transfer-encoding; s=sasl; bh=8HBc6TBs3XMOPESeUohJD7dae Rk=; b=oGjJIjejxY4Yc6fzGVsTPCb/t8d8yMWYqwoX2wUDAPKzZmx+fHVWToWU5 xQRbk+GoUqbJpYb9M6Lkhvx7ZyG2+/0L8hL7w0GD81vW87pi5e3vvAZUTT2uGQAX QSXL3BLpoV1ZrYPTsSBkcAOTGNdAxgi7BndicoxBoBdaZ41S1I=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:content-type :content-transfer-encoding; q=dns; s=sasl; b=wLDNngo7gOeNz/Ea+m5 sOjrqru9YenDlmItvZ8WpYOr1xn3cxyeYj66GrkQy08GfF48WRdgMBGKVHpliGiY CEduij0htEw7fi4RnxsvQsMkIq6ycXZV4Ao1FBLl/xLpzPRy/sYrJrfUZx/M83Pn VbLjH4mznwFrahimIft6qgLE=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EA477D80F for ; Wed, 18 Sep 2013 14:45:31 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 34C8AD80C for ; Wed, 18 Sep 2013 14:45:31 -0400 (EDT)
Message-ID: <5239F4C9.5090805@pobox.com>
Date: Wed, 18 Sep 2013 11:45:29 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: TLS Mailing List 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 7EB03A0E-2092-11E3-A206-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Subject: [TLS] TLS 1.3 wishlist
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 18:45:46 -0000

A "wish list" for an upcoming new version of TLS is available
online (I found it via a message on Twitter):

https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf

Is it appropriate to discuss this now, prior to rechartering?

Mike

From michael@stroeder.com  Wed Sep 18 11:46:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6422011E820E for ; Wed, 18 Sep 2013 11:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.201
X-Spam-Level: 
X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=1.098,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-JVuM+TK3CZ for ; Wed, 18 Sep 2013 11:46:34 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id CF59711E8164 for ; Wed, 18 Sep 2013 11:46:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 8A2EE6023E for ; Wed, 18 Sep 2013 20:46:11 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdhzDUPCQvil for ; Wed, 18 Sep 2013 20:46:00 +0200 (CEST)
Received: from nb2.stroeder.local (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id A12366023A for ; Wed, 18 Sep 2013 18:45:59 +0000 (UTC)
Message-ID: <5239F4E8.7070007@stroeder.com>
Date: Wed, 18 Sep 2013 20:46:00 +0200
From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>, <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com>
In-Reply-To: <5239B845.6010606@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060909090006000906080109"
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 18:46:38 -0000

This is a cryptographically signed message in MIME format.

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

Yaron Sheffer wrote:
> please see my mail message that started this thread, way back on Sunday=
 :-)
>=20
> http://www.ietf.org/mail-archive/web/tls/current/msg09903.html

Reading this posting your main objections against MODP DH are interop iss=
ues
of today's implementation. Right? This leads me to a more general questio=
n...

First, I really appreciate that you write down this BCP document.
But I wonder what the exact scope should be.

In the abstract you say "existing standards and implementations", I guess=
 to
exclude approaches yet to be defined in a new standard. Agreed.
But does that also exclude pushing implementors to slightly improve their=

software? The "deployers rather than for implementers" in the introductio=
n
sounds like it.

If that's the scope you're stuck into recommending the least common
denominator of today's implementations and implementors can take your RFC=
 as
excuse to stop improving their implementations.
Also you're in the trap of choosing "widely-used" implementations for you=
r
"Implementation Status" section which is always questionable depending on=

personal deployments, especially since the main focus now seems to be web=

servers and browsers.

Frankly I have no idea how to get out of this though.

Ciao, Michael.

> On 09/18/2013 05:21 PM, Michael Str=C3=B6der wrote:
>> On Wed, 18 Sep 2013 13:07:58 +0300 Yaron Sheffer  wrote
>>> There are multiple issues
>>> with MODP DH in TLS (performance is just one of them).
>>
>> Could you please elaborate on this.
>>
>> Ciao, Michael.


--------------ms060909090006000906080109
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE4MTg0NjAwWjAj
BgkqhkiG9w0BCQQxFgQUxWeY6pEPi/BMKiPFTAi3u1AoZVEwbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAje44ZZUze0HMYxdqNvgZdfywn6WDFr/U
svQiEiIumFCNPtd8JLDxfi2SJx4cN9tx3A0lSNNJPGFqB+FIE4xYAFXBWje4wJrvEE/CPiq6
vvIB+NHD5/+z+CCm2IJwCdM056GdW95YZZUU4lZXxc2bOwHv5Mex5vuZwEpj5zdCJD2BwzT3
L6utrbNuQEIQuprzDxqC8ucUIdJk29kKAMje3kho+eXM16/OSAUuO4zAjkdInUF9s7BBoRQN
OHoKd1k5vsqPl90Iq4q/Vl674ul4an+plUbRZpkHSmHM36HMUd9wvvKrYiDFiuqb+SeiSLEp
BkIWiMdHEU0rJKrWuBS7KQAAAAAAAA==
--------------ms060909090006000906080109--

From hughejp@mac.com  Wed Sep 18 12:16:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2DE11E8108 for ; Wed, 18 Sep 2013 12:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level: 
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[AWL=1.647, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhWQLb7SFKPa for ; Wed, 18 Sep 2013 12:16:02 -0700 (PDT)
Received: from st11p06mm-asmtp003.mac.com (st11p06mm-asmtp003.mac.com [17.172.124.248]) by ietfa.amsl.com (Postfix) with ESMTP id DA90921F9A90 for ; Wed, 18 Sep 2013 12:16:01 -0700 (PDT)
Received: from [10.0.1.4] (unknown [184.69.15.210]) by st11p06mm-asmtp003.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTC009JV5IGGW10@st11p06mm-asmtp003.mac.com> for tls@ietf.org; Wed, 18 Sep 2013 19:15:55 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 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-1308280000 definitions=main-1309180098
Content-type: multipart/alternative; boundary="Apple-Mail=_08480775-A85E-4A7F-B83B-93B951AF7BEF"
MIME-version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: james hughes 
In-reply-to: <8E95757A-5DBB-4FBC-8EBC-2F28F47903CB@ll.mit.edu>
Date: Wed, 18 Sep 2013 12:15:51 -0700
Message-id: <2EF88965-50F2-44C3-862F-F9B92BD51D66@mac.com>
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz> <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu> <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com>  <8E95757A-5DBB-4FBC-8EBC-2F28F47903CB@ll.mit.edu>
To: "Blumenthal, Uri - 0558 - MITLL" 
X-Mailer: Apple Mail (2.1508)
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 19:16:08 -0000

--Apple-Mail=_08480775-A85E-4A7F-B83B-93B951AF7BEF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL" =
 wrote:

> If you think that in 5 years 1024-bit DH will be trivially crackable - =
I'd like to see some evidence to support it.

There is a different between "trivially crackable" and routinely =
exploitable. In 5 years this will be routinely exploitable.=20

It seems to me that the standards process does not need NSA to subvert =
the process, the standards people seem to be doing this fine by =
themselves. Anyway, speaking as someone working in this field (more =
factoring than discreet log) the professional recommendation is 2048.=20

I am not baiting here, but the argument that 2048 is "too much" given =
that a PC can do a complete authenticated PFS key exchange in 3ms of CPU =
time seems "interesting".=20



--Apple-Mail=_08480775-A85E-4A7F-B83B-93B951AF7BEF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

uri@ll.mit.edu> =
wrote:

It seems =
to me that the standards process does not need NSA to subvert the =
process, the standards people seem to be doing this fine by themselves. =
Anyway, speaking as someone working in this field (more factoring than =
discreet log) the professional recommendation is =
2048. 

I am not baiting here, but the =
argument that 2048 is "too much" given that a PC can do a complete =
authenticated PFS key exchange in 3ms of CPU time seems =
"interesting". 


=

--Apple-Mail=_08480775-A85E-4A7F-B83B-93B951AF7BEF--

From prvs=29737ce98b=uri@ll.mit.edu  Wed Sep 18 12:24:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B709111E8108 for ; Wed, 18 Sep 2013 12:24:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.872
X-Spam-Level: 
X-Spam-Status: No, score=-4.872 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jt7CXitGFDKV for ; Wed, 18 Sep 2013 12:24:36 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 539DE11E8119 for ; Wed, 18 Sep 2013 12:24:33 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8IJNS2n015120; Wed, 18 Sep 2013 15:24:26 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: james hughes 
Date: Wed, 18 Sep 2013 15:24:18 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60pK0TJ8+ukqRvTbef8uY9L0Iwaw==
Message-ID: 
In-Reply-To: <2EF88965-50F2-44C3-862F-F9B92BD51D66@mac.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.7.130812
acceptlanguage: en-US
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3462362658_41927692"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-18_08:2013-09-18, 2013-09-18, 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-1305240000 definitions=main-1309180098
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 19:24:41 -0000

--B_3462362658_41927692
Content-type: multipart/alternative;
	boundary="B_3462362658_41942152"


--B_3462362658_41942152
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit


From:  james hughes 
> On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL"
>  wrote:
>> If you think that in 5 years 1024-bit DH will be trivially crackable - I'd
>> like to see some evidence to support it.
> There is a different between "trivially crackable" and routinely exploitable.
> In 5 years this will be routinely exploitable.

If you mean "exploitable in bulk", then I'd buy your argument.  (Though
we've no idea what may happen in 5 years.)

> It seems to me that the standards process does not need NSA to subvert the
> process, the standards people seem to be doing this fine by themselves.
> Anyway, speaking as someone working in this field (more factoring than
> discreet log) the professional recommendation is 2048.

Recommendation noted. I almost remember myself many years ago trying to
convince SNMP WG that HMAC is a better choice than just keyed hash, and
SHA-1 should replace MD5 as "MUST". The arguments against it were "it would
hurt performance too badly".

> I am not baiting here, but the argument that 2048 is "too much" given that a
> PC can do a complete authenticated PFS key exchange in 3ms of CPU time seems
> "interesting". 

As I said, if the exchange takes 3 seconds on my PC (or on my smartphone :)
I'm OK with it. The complaints are likely to come from the server folks. You
can guess why.




--B_3462362658_41942152
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable



From:  james hughes <hu=
ghejp@mac.com>
On Sep 18, 2013, at 10:34 AM, "Blumenthal,=
 Uri - 0558 - MITLL" <uri@ll.mit.edu&=
gt; wrote:
If
 you think that in 5 years 1024-bit DH will be trivially crackable - I'd li=
ke to see some evidence to support it.
There i=
s a different between "trivially crackable" and routinely exploitable. In 5 =
years this will be routinely exploitable. 

If you mean "exploitable in bulk", then I'=
d buy your argument.  (Though we've no idea what may happen in 5 years.=
)

It seems to me that =
the standards process does not need NSA to subvert the process, the standard=
s people seem to be doing this fine by themselves. Anyway, speaking as someo=
ne working in this field (more factoring than discreet log) the professional=
 recommendation
 is 2048. 

Recommen=
dation noted. I almost remember myself many years ago trying to convince SNM=
P WG that HMAC is a better choice than just keyed hash, and SHA-1 should rep=
lace MD5 as "MUST". The arguments against it were "it would hurt performance=
 too badly".

I am not =
baiting here, but the argument that 2048 is "too much" given that a PC can d=
o a complete authenticated PFS key exchange in 3ms of CPU time seems "intere=
sting". 

As I said, =
if the exchange takes 3 seconds on my PC (or on my smartphone :) I'm OK with=
 it. The complaints are likely to come from the server folks. You can guess =
why.



--B_3462362658_41942152--

--B_3462362658_41927692
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIIUFAYJKoZIhvcNAQcCoIIUBTCCFAECAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B
BwGgghHjMIIEyzCCA7OgAwIBAgIKZmfFegAAAABv3jANBgkqhkiG9w0BAQsFADBRMQswCQYD
VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ
MRMwEQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDYwNTE3NDg1NVoXDTE0MDYwNTE3NDg1NVow
YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV
BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQD0pxreUKJmz3cYObjwcqXaTyUCzAwXTeB7BABDIopD
F0wfCHEAhf3lZCftQRtrN6lcvk2d530ESc00q11bwFjiifpTGVTJoxiumHVgFInWHrECeQy0
B9BWM4XiWY3MXvqFjsQJ8HmqQTGqLk9+0/4/CyEXEnwNqAWNYA2K2uLWuJb/WSiimxfcBc/p
rIn+ObsIpkDnACG2jWRkE41GklcmaTexUTQetGRFVfYwrC73+4EQs32IKDVnJ+Rd2/yqwHgr
i0kNwR8tu/5qIux4j0YVAwucQF43Mj2LmVhwCqHxHm4mVVJQQLJkS5ZA9wycKyze3Fm7k6h8
11i7laYKWiyvAgMBAAGjggGTMIIBjzAdBgNVHQ4EFgQUxkrbqy+gJYz6KplY/VQJigLNuzMw
DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1Ud
HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYB
BQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD
QTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAw
PQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhcveMof/
inMCAWQCAQUwIgYDVR0lAQH/BBgwFgYIKwYBBQUHAwQGCisGAQQBgjcKAwwwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAUpfpR1Sa9nInr3dVDOMvGcxg7GwHdSoCD9xCTXfPxqAkzI3UdOm6fLPUE7Wd
XtaLsoInWIK/gP2uRTONUNbUScH21ia+J0UjZj5t2cbU+akefQkeobYXGAsa1BxIFSjaRQrq
oLuZocef2ut8FjFeiU+YmNH4DAMGqtcg54Yq5PTdLVzZKJv8Z6vsJVcWgb/pLNIZ2dByb8K5
48A/rjUeJcBL/Gy0EveUYJAWTQvbCjZwFFdubfjoPDu2qFuhgAhAlER/fzTcq5bapjYnfEHZ
/Yx6Tmg5hUl5zNhr6dQY7p3yb+koIiTz7gJCQFc/FZSGxfD4ScPTnCJZXhMPFOUbSDCCBLcw
ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1J
VCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9v
dCBDQTAeFw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8w
HQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT
Ck1JVExMIENBLTIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7Deg
MwcFYWZM6OknYzRgEO5gNgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDK
Ip5UX5N2BCzwu7BJJMwUJHFaS4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2
QhPlNmk4ONpL/80Kx9wKKhV/NThe54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0z
XPQ70LYwOWXLlpxAolKcgwRVsS6/cse8YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yK
sORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1RNLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8E
CDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGINFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRn
qnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMCAYYwYQYIKwYBBQUHAQEEVTBTMC0G
CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8/TExSQ0EwIgYIKwYBBQUH
MAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2Ny
bC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEG
MA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3
EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0G
CyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8QXAqk
zSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm
UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD
2o67Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AU
meFH7xl0E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWB
snsX3nVTRdHCVi+Cf3Cx4YDWMIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQsw
CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMD
UEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIz
NTk1OVowVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkx
DDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAMVOKRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKv
f9VSQToAsA6q1bACtZUcMv5ZKx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXT
XYQIdp1DgjtdADKVLAjXaYpD2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/
hipJ6+sI/ZtrFRmsKGhuwAKobFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpX
TZFcM9SOX0f7wmsYi1yFuKFMnQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW
6oMCAwEAAaNgMF4wDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3y
EMND7SkwHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0G
CSqGSIb3DQEBBQUAA4IBAQA+G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I
1Nf02qDU/GO2H9ETvnvTYhvfgQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8P
yYtZtngb6DgeEUv+SwFnzcLO1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/
LbPjNuPdgJfO3d1WrHr1Etaaa0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/Yr
oyqWFnH2KkNxRn9+2Ar7g3rnrOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90
ivQAMIIEzjCCA7agAwIBAgIKLRt82QAAAABhCDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQG
EwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw
EQYDVQQDEwpNSVRMTCBDQS0yMB4XDTEzMDIyODE2MTcxNFoXDTE0MDIyODE2MTcxNFowYTEL
MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsT
BlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCqgQaJR3nurw/TB1Gm3yRezeYoc6BXhdtn9ZToWjJA044X
519aJBKnWyVpLdTgGMmT1uX48QQrKT6WT6QyIqPlpPqZpq9Ex+ZPKOfbk5Jl1Pw5SnceFZQb
z1EIMgvz8JX2vhfMrr6DCDk1YIQY+F9ox/iTZTlLwWthnor6FhNLWCz0Rg+d5IPrTWfTzWSn
w71hQb6iY8xmrtCJ5njGJUUx1Z6xQ4v26vSvAGLqg9NsAHdaHuQkTCEzDIyRZ9QzfA8+Bti3
sB40yHSTgORE1BQ1wa5+CwyitHq4sSb8NOW41tQ0OnE+QL+rW9anJYkbOzBWHvMbWgo3p1Q8
B8yGuZlnAgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUdbttDhxCbk/gVL/0gcb3CagQkHQwDgYD
VR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQs
MCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUH
AQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIw
IwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJ
KwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SAC
AWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEw
DzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B
AQsFAAOCAQEAWHiBeNYY8PIHTsg1fyOX8E3PpnPiKvRyNpYEQ29ZWfgcEZo9OKtyeque14vn
+t2jWRp+c7XQvmy0JUZO8Zz3RFFfjezTLfY6LCFWltJoRwGZRyhRC0SWOEsRzcFKrYFB/S5f
NYjV69Id9UCNSnlSUTr+NxbVIczfs9TlbYstjamllfrms+XHhzH/xfLQ4bB8HOdxunlgsqBU
3jS7H7hpafBbWhL1Mt5685pAbj1hSAVy4bd1JkJSWi7O6M5Ca4KRp7l0XSZX6Au5h6eoy8IQ
aC5xtxVNSUTWSI6ysoH0AzyZUH9nSu3iOM+sMYzKENqijk/pzM7vCDEb89M4S5ffhjGCAfUw
ggHxAgEBMF8wUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv
cnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMgIKZmfFegAAAABv3jANBglg
hkgBZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCDO5AqqVegJUeDkAdAPrtC4V4N+oGkWsjmy
foNHhHoZhzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMzA5
MTgxOTI0MThaMA0GCSqGSIb3DQEBAQUABIIBAGo6jJdir2YkvMqv8GVkd78FDzyJVdq/tvEd
fYvsTVYW8z+5MDbe6SOMs+lrBLGijEqNLfdKN9afx3sk72r3Nsptl9GxI7nin2l2C4bdzuv8
D8lYyTfLJMquFKC1xzsEj04KGEpiOAziiM2vVu3301dxIiDdcmpz1Doftrz5HZLRZpcX/8k8
svjg6n077FZWTy/kfMbOuoK5jS9yMhHpOQpI9MBzXheZvJiUItLu72S1l3cS63y5JQwcSRrw
W7W3uAt2BOKaFRJomFJOBwqa82rj99oJGKTutMyz0AOjRylYxJ0Fn2O2jS674x4+oX9P6ykK
Z2udDHcyp7L0lTWnBvc=

--B_3462362658_41927692--

From ynir@checkpoint.com  Wed Sep 18 12:47:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C576B11E8140 for ; Wed, 18 Sep 2013 12:47:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.934
X-Spam-Level: 
X-Spam-Status: No, score=-9.934 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsOcSYdC08dK for ; Wed, 18 Sep 2013 12:47:31 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BE34311E825A for ; Wed, 18 Sep 2013 12:47:05 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8IJkvK7009334; Wed, 18 Sep 2013 22:47:01 +0300
X-CheckPoint: {523A0331-7-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Wed, 18 Sep 2013 22:46:57 +0300
From: Yoav Nir 
To: james hughes 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac60VQbt5dKKYJ0xmEuWRIX4Ztx5/f//0Y0AgABG7YCAAAGHgIAAHcMAgAAI9ICAAAfWAIAABcOAgAAcUICAAAivAA==
Date: Wed, 18 Sep 2013 19:46:57 +0000
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz> <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <958F40E0-8978-4C4F-BB2E-2519B66470D9@ll.mit.edu> <4EEA8B22-183D-41E0-A7E2-E784A92F7185@mac.com>  <8E95757A-5DBB-4FBC-8EBC-2F28F47903CB@ll.mit.edu> <2EF88965-50F2-44C3-862F-F9B92BD51D66@mac.com>
In-Reply-To: <2EF88965-50F2-44C3-862F-F9B92BD51D66@mac.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.158]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: multipart/alternative; boundary="_000_E9939285E47A4D4C8EA35F2924559897checkpointcom_"
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 19:47:37 -0000

--_000_E9939285E47A4D4C8EA35F2924559897checkpointcom_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable


On Sep 18, 2013, at 10:15 PM, james hughes >
 wrote:


On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL" > wrote:

If you think that in 5 years 1024-bit DH will be trivially crackable - I'd =
like to see some evidence to support it.

There is a different between "trivially crackable" and routinely exploitabl=
e. In 5 years this will be routinely exploitable.

Based on what? There's been a paper ([1]) describing how to produce a SHA-1=
 collision in 2^61 steps for two years, and nobody's produced a collision y=
et. This should be within the powers of a moderately well-funded company or=
 university, not just government agencies. Sure, the NSA has the resources =
to produce a SHA-1 collision. But if they had to produce one for *each* ses=
sion they wanted to break, they would have to be very picky with choosing t=
he sessions that they break.

1024-bit RSA and DSA are usually considered equivalent to 80-bit security, =
so half a million times more difficult to crack than producing a SHA-1 coll=
ision (an effort no civilian has yet dared to take). DHE with 1024-bit keys=
 means that our favorite pervasive attacker would need that much effort to =
crack a single connection. It's much better to deploy that than to not depl=
oy 2048-bit DHE because so many of the servers and clients don't support it=
.


It seems to me that the standards process does not need NSA to subvert the =
process, the standards people seem to be doing this fine by themselves. Any=
way, speaking as someone working in this field (more factoring than discree=
t log) the professional recommendation is 2048.

Yes, and where it's possible (RSA keys) we've all migrated. But the profess=
ional recommendation that I'm hearing is to move to ECC.

I am not baiting here, but the argument that 2048 is "too much" given that =
a PC can do a complete authenticated PFS key exchange in 3ms of CPU time se=
ems "interesting".

Moving from 1 ms to 3 ms is trivial for a client, but may require buying mo=
re hardware for the server. As someone in the field of selling hardware, th=
at's great! But it does slow adoption.

But that is not the argument you hear from me. My argument is that it's poi=
ntless to change implementation to support a better DHE, when (a) the curre=
nt DHE implementation is OK for now, and (b) ECDHE is the future and alread=
y implemented in most codebases.

Yoav


--_000_E9939285E47A4D4C8EA35F2924559897checkpointcom_
Content-Type: text/html; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable











On Sep 18, 2013, at 10:15 PM, james hughes <hughejp@mac.com>


 wrote:












On Sep 18, 2013, at 10:34 AM, "Blumenthal, Uri - 0558 - MITLL&quo=
t; <uri@ll.mit.edu> wrote:



If
 you think that in 5 years 1024-bit DH will be trivially crackable - I'd li=
ke to see some evidence to support it.






There is a different between "trivially crackable" and routi=
nely exploitable. In 5 years this will be routinely exploitable. =












Based on what? There's been a paper ([1]) describing how to produce a =
SHA-1 collision in 2^61 steps for two years, and nobody's produced a collis=
ion yet. This should be within the powers of a moderately well-funded compa=
ny or university, not just government
 agencies. Sure, the NSA has the resources to produce a SHA-1 collision. Bu=
t if they had to produce one for *each* session they wanted to break, they =
would have to be very picky with choosing the sessions that they break.






1024-bit RSA and DSA are usually considered equivalent to 80-bit secur=
ity, so half a million times more difficult to crack than producing a SHA-1=
 collision (an effort no civilian has yet dared to take). DHE with 1024-bit=
 keys means that our favorite pervasive
 attacker would need that much effort to crack a single connection. It's mu=
ch better to deploy that than to not deploy 2048-bit DHE because so many of=
 the servers and clients don't support it.












It seems to me that the standards process does not need NSA to subvert the =
process, the standards people seem to be doing this fine by themselves. Any=
way, speaking as someone working in this field (more factoring than discree=
t log) the professional recommendation
 is 2048. 








Yes, and where it's possible (RSA keys) we've all migrated. But the profess=
ional recommendation that I'm hearing is to move to ECC.








I am not baiting here, but the argument that 2048 is "too much" g=
iven that a PC can do a complete authenticated PFS key exchange in 3ms of C=
PU time seems "interesting". 








Moving from 1 ms to 3 ms is trivial for a client, but may require buyi=
ng more hardware for the server. As someone in the field of selling hardwar=
e, that's great! But it does slow adoption.







But that is not the argument you hear from me. My argument is that it'=
s pointless to change implementation to support a better DHE, when (a) the =
current DHE implementation is OK for now, and (b) ECDHE is the future and a=
lready implemented in most codebases.







Yoav









--_000_E9939285E47A4D4C8EA35F2924559897checkpointcom_--

From yaronf.ietf@gmail.com  Wed Sep 18 13:32:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A0411E8111 for ; Wed, 18 Sep 2013 13:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3dKmYUu5ZpZ for ; Wed, 18 Sep 2013 13:32:58 -0700 (PDT)
Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20C11E810B for ; Wed, 18 Sep 2013 13:32:58 -0700 (PDT)
Received: by mail-wi0-f173.google.com with SMTP id hq15so7012864wib.0 for ; Wed, 18 Sep 2013 13:32:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=594J/HA1kZRQi3ral7RTT6/gqcburKvLvUG5pKlk56o=; b=yTxkgom1cfI3erJlaiSARQIHtpeyca4OT+4k4Swf/lKEzcn3IbOQ9sxLmPMjfatLzu +a6GQo2En0sI/skeWfTSd5+uWF/HDo///QrrORR3WxAD7ZMRRy7z7bLa8RisA+et0nQo Y9y64UnknwGjky7mNrJ/CPyDAgaPFP3m2yzObISqkoo9v4QOT/gmQSwUHu37v84pbfRQ ffZOuWJCPuxYENqRgepPeo1plgWE1JvNbGQ6bV1/i+CmYLctBN8bKUX2vm06COecL2mB qT8N1mBuZ3fNP/YAJRUk4zDcMRLbzXVs20zx58sXzZJ83GT4HAc5nEg0jNtimj71tCLH PsnQ==
X-Received: by 10.194.175.66 with SMTP id by2mr3067851wjc.59.1379536377217; Wed, 18 Sep 2013 13:32:57 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id jf2sm4915799wic.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Sep 2013 13:32:56 -0700 (PDT)
Message-ID: <523A0DF2.30606@gmail.com>
Date: Wed, 18 Sep 2013 23:32:50 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 
References: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>, <52397B7E.70204@gmail.com> <98ca985ffce946c42315e4e03db57747@srv1.stroeder.com> <5239B845.6010606@gmail.com> <5239F4E8.7070007@stroeder.com>
In-Reply-To: <5239F4E8.7070007@stroeder.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 20:32:59 -0000

Hi Michael,

Please see below.

	Yaron

On 09/18/2013 09:46 PM, Michael Ströder wrote:
> Yaron Sheffer wrote:
>> please see my mail message that started this thread, way back on Sunday :-)
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg09903.html
>
> Reading this posting your main objections against MODP DH are interop issues
> of today's implementation. Right? This leads me to a more general question...
>
> First, I really appreciate that you write down this BCP document.
> But I wonder what the exact scope should be.
>
> In the abstract you say "existing standards and implementations", I guess to
> exclude approaches yet to be defined in a new standard. Agreed.
> But does that also exclude pushing implementors to slightly improve their
> software? The "deployers rather than for implementers" in the introduction
> sounds like it.

This is just my personal opinion (as long as this doc has not been 
adopted by the working group). But I think we are in violent agreement. 
I do not want to depend on any new standards, extensions etc., because 
this could take forever. I do want to be aware of existing 
implementations as a *baseline*, but definitely to help steer the 
industry in a direction that will improve the overall security of the 
Internet. So, I include a table listing existing implementations, so 
that we know what the current situation is. But I certainly am *not* 
pushing towards a least common denominator of today's implementations 
(which would be TLS 1.0, alas).
>
> If that's the scope you're stuck into recommending the least common
> denominator of today's implementations and implementors can take your RFC as
> excuse to stop improving their implementations.
> Also you're in the trap of choosing "widely-used" implementations for your
> "Implementation Status" section which is always questionable depending on
> personal deployments, especially since the main focus now seems to be web
> servers and browsers.

I don't understand this point. Browsers and Web servers are obviously 
important, probably the most important "customers" of this document. 
Moreover, other uses (such as Web services) are IMHO much easier to 
improve. Taking as an example the Amazon Web Services set of RESTful 
APIs, they would have a much easier time migrating the finite number of 
SDKs that access them towards more secure TLS, compared with a general 
purpose Web server like Yahoo!.

>
> Frankly I have no idea how to get out of this though.
>
> Ciao, Michael.
>
>> On 09/18/2013 05:21 PM, Michael Ströder wrote:
>>> On Wed, 18 Sep 2013 13:07:58 +0300 Yaron Sheffer  wrote
>>>> There are multiple issues
>>>> with MODP DH in TLS (performance is just one of them).
>>>
>>> Could you please elaborate on this.
>>>
>>> Ciao, Michael.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From frantz@pwpconsult.com  Wed Sep 18 14:10:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CAB11E810A for ; Wed, 18 Sep 2013 14:10:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.369
X-Spam-Level: 
X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLPMVlL52Mm7 for ; Wed, 18 Sep 2013 14:10:54 -0700 (PDT)
Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 320F811E810B for ; Wed, 18 Sep 2013 14:10:53 -0700 (PDT)
Received: from [173.75.83.246] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VMP1O-0004LL-L6 for tls@ietf.org; Wed, 18 Sep 2013 17:10:50 -0400
Date: Wed, 18 Sep 2013 14:10:50 -0700
From: Bill Frantz 
To: tls@ietf.org
X-Priority: 3
In-Reply-To: <5239F4E8.7070007@stroeder.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec794c640c7c373eabf556b357cc1a4a4d8e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.246
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 21:10:59 -0000

On 9/18/13 at 11:46 AM, michael@stroeder.com (Michael Str=C3=B6der) wrote:

>First, I really appreciate that you write down this BCP document.
>But I wonder what the exact scope should be.
>
>In the abstract you say "existing standards and implementations", I guess =
to
>exclude approaches yet to be defined in a new standard. Agreed.
>But does that also exclude pushing implementors to slightly improve their
>software? The "deployers rather than for implementers" in the introduction
>sounds like it.
>
>If that's the scope you're stuck into recommending the least common
>denominator of today's implementations and implementors can take your RFC =
as
>excuse to stop improving their implementations.
>Also you're in the trap of choosing "widely-used" implementations for your
>"Implementation Status" section which is always questionable depending on
>personal deployments, especially since the main focus now seems to be web
>servers and browsers.
>
>Frankly I have no idea how to get out of this though.

I would address the issue of DHE keys that are limited to 1024=20
bits by saying that the use of 1024 bits is the best current=20
practical practice. I would also follow that recommendation with=20
a note that 1024 bits is smaller than the best current practice,=20
but is the limit provided by current implementations, so=20
following the best current practice will change when=20
implementors get off their butts.

A section in the document listing some of the implementations=20
that can't perform to best current crypto practice and where=20
they are deficient might also be a useful goad.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | Re: Computer reliability, performance, and security:
408-356-8506       | The guy who *is* wearing a parachute is=20
*not* the
www.pwpconsult.com | first to reach the ground.  - Terence Kelly


From holz@net.in.tum.de  Tue Sep 17 06:38:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325B311E8120 for ; Tue, 17 Sep 2013 06:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVUxP+EmVfHl for ; Tue, 17 Sep 2013 06:38:46 -0700 (PDT)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB411E81EB for ; Tue, 17 Sep 2013 06:38:45 -0700 (PDT)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 76E3480A17; Tue, 17 Sep 2013 15:38:44 +0200 (CEST)
Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 0389C809A9 for ; Tue, 17 Sep 2013 15:38:38 +0200 (CEST)
Message-ID: <52385B94.5020102@net.in.tum.de>
Date: Tue, 17 Sep 2013 15:39:32 +0200
From: Ralph Holz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: <20130916211725.6E5E21A971@ld9781.wdf.sap.corp> <5238200E.70500@gmail.com> <07AC3415-536F-4260-B726-476DFFE57F8F@checkpoint.com>
In-Reply-To: <07AC3415-536F-4260-B726-476DFFE57F8F@checkpoint.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
X-Mailman-Approved-At: Wed, 18 Sep 2013 14:12:51 -0700
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Sep 2013 13:38:51 -0000

Hi,

> To get DHE-2048, we'd need to patch Apache, change Windows, get
> everyone to use the new Windows, probably some more I forgot.
> 
> To get ECDH we need to change a compilation option of RedHat (and
> probably some other distributions).
> 
> I think the choice is pretty much a no-brainer.

I do think we should mention DHE-2048. It's the classic, well-understood
concept. I take a very conservative POV here, but ECC is younger and
less tested. Add to that the NSA speculations.

You're right about the Apaches, but Windows users, I think, should not
be too much of a problem once Microsoft decides to enable DHE-2048 and
push it out with their update mechanism.

> And if you're worried about NIST curves, there are people pushing
> brainpool and other curves on the TLS list.

Brainpool and/or djb's curves will take some time for adaption, too,
especially for secure implementations. Another reason to mention the
classic DHE alternative.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

From peter@akayla.com  Wed Sep 18 17:40:50 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E76E11E815A for ; Wed, 18 Sep 2013 17:40:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8bczJxeWAky for ; Wed, 18 Sep 2013 17:40:45 -0700 (PDT)
Received: from p3plwbeout04-01.prod.phx3.secureserver.net (p3plsmtp04-01-2.prod.phx3.secureserver.net [72.167.218.222]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBBE11E813A for ; Wed, 18 Sep 2013 17:40:45 -0700 (PDT)
Received: from localhost ([72.167.218.245]) by p3plwbeout04-01.prod.phx3.secureserver.net with bizsmtp id Sogk1m0025JG3DC01ogkGu; Wed, 18 Sep 2013 17:40:44 -0700
X-SID: Sogk1m0025JG3DC01
Received: (qmail 26832 invoked by uid 99); 19 Sep 2013 00:40:44 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0a00516958e0aa81483ef21eb18ad8aa"
To: "Michael D'Errico" , "TLS Mailing List" 
From: peter@akayla.com
In-Reply-To: <5239F4C9.5090805@pobox.com>
Date: Wed, 18 Sep 2013 17:40:44 -0700
Message-Id: <20130918174044.00a6de0cd6b6d9d1a625f0bea31fb72f.00d4ab38ec.mailapi@email04.secureserver.net>
X-Originating-IP: 61.132.63.50
User-Agent: MailAPI 24838
X-Sender: peter@akayla.com
Subject: Re: [TLS] TLS 1.3 wishlist
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 00:40:50 -0000

--=_0a00516958e0aa81483ef21eb18ad8aa
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=utf-8

I'd suggest yes.  Such a discussion would serve as input to
both the rechartering as well as the actual work (assuming
the rechartering takes place).
=20
-Peter
=20
--------- Original Message ---------
Subject: [TLS] TLS 1.3 wishlist
From: "Michael D'Errico" 
Date: 9/18/13 11:45 am
To: "TLS Mailing List" 

A "wish list" for an upcoming new version of TLS is available
online (I found it via a message on Twitter):

https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf

Is it appropriate to discuss this now, prior to rechartering?

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

--=_0a00516958e0aa81483ef21eb18ad8aa
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
 charset=utf-8


I'd suggest yes.  Such a discussion would serve as input to


both the rechartering as well as the actual work (assuming


the rechartering takes place).


 


-Peter


 


--------- Original Message ---------


Subject: [TLS] TLS 1.3 wishlist
From: "Michael D'Errico" <mike=
-list@pobox.com>
Date: 9/18/13 11:45 am
To: "TLS Mailing List"=
 <tls@ietf.org>

A "wish list" for an upcoming new version =
of TLS is available
online (I found it via a message on Twitter):

https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
=

Is it appropriate to discuss this now, prior to rechartering?
Mike
_______________________________________________
TLS mail=
ing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--=_0a00516958e0aa81483ef21eb18ad8aa--

From mrex@sap.com  Wed Sep 18 18:33:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBAA11E81DE for ; Wed, 18 Sep 2013 18:33:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.192
X-Spam-Level: 
X-Spam-Status: No, score=-10.192 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOEkH0V43g5e for ; Wed, 18 Sep 2013 18:33:20 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 87A8211E81E1 for ; Wed, 18 Sep 2013 18:33:20 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8J1X4mh001184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 03:33:04 +0200 (MEST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73556737D0@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann 
Date: Thu, 19 Sep 2013 03:33:04 +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: <20130919013304.1D5EB1A983@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 19 Sep 2013 01:33:25 -0000

Peter Gutmann wrote:
> Yaron Sheffer  writes:
> 
> >Please see the later discussion, in particular
> >http://www.ietf.org/mail-archive/web/tls/current/msg09924.html.
> 
> I've been following the discussion, but none of it really supports going to
> 2048 rather than just 1280 or 1536.  In addition, as Yoav pointed out, there's
> a big different between solving the DLP in 1024 bits and stealing an any-size-
> you-want long-term RSA key.


The TLS WG could have easly provided an adequate PFS solution
many years ago that could be trivially enabled for all existing
implementations.  Ephermeral RSA.  99% of the code is already
present in all implementations, because this is used in the
RSA_EXP cipher suites.

  http://www.ietf.org/mail-archive/web/tls/current/msg01541.html

(EC)DHE is a mess, because both, servers and clients will regularly
have to regenerate new keys, and there are going to be severl 
different keys necessary for the preferences of various servers
and sometimes, the client-side key generation will have to be
performed inline.  How many different keys will clients need
for ECDHE?

With Ephemeral RSA, only the server has to generate the temporary
RSA keypair, and can *ALWAYS* generate the ephemeral RSA keypair out-of-band.


I'm not a cryptographer, but I'm actually not convinced that
counter modes of AES are a road I want to travel.  (I'm wondering:
do we actually know the length of the cycles of AES in counter mode?
Is there a paper describing what assumption the security of counter
modes are based on, and formal proofs that AES actually has all
these properties?)

I have not yet seen anything worrisome about AES-CBC.  And the
CBC padding oracle that Vaudenay complained about could have
trivially been fixed in TLSv1.1 already, since the problem, and
its solution, were described in Vaudenay's paper.  We can still
fix it with Peter's proposal. 


-Martin

From mrex@sap.com  Wed Sep 18 19:06:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA7811E8170 for ; Wed, 18 Sep 2013 19:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.196
X-Spam-Level: 
X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWIXxZ8zJQtv for ; Wed, 18 Sep 2013 19:06:52 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4B211E80D7 for ; Wed, 18 Sep 2013 19:06:52 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8J26gIE020554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 04:06:43 +0200 (MEST)
In-Reply-To: <20130919013304.1D5EB1A983@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Thu, 19 Sep 2013 04:06:42 +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: <20130919020642.8F5621A983@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 19 Sep 2013 02:06:57 -0000

Following up to myself:

> 
> The TLS WG could have easly provided an adequate PFS solution
> many years ago that could be trivially enabled for all existing
> implementations.  Ephermeral RSA.  99% of the code is already
> present in all implementations, because this is used in the
> RSA_EXP cipher suites.
> 
>   http://www.ietf.org/mail-archive/web/tls/current/msg01541.html
> 
> (EC)DHE is a mess, because both, servers and clients will regularly
> have to regenerate new keys, and there are going to be severl 
> different keys necessary for the preferences of various servers
> and sometimes, the client-side key generation will have to be
> performed inline.  How many different keys will clients need
> for ECDHE?
> 
> With Ephemeral RSA, only the server has to generate the temporary
> RSA keypair, and can *ALWAYS* generate the ephemeral RSA keypair out-of-band.

What I had not remembered from the past discussion, and just
found in a later reply from EKR:
   http://www.ietf.org/mail-archive/web/tls/current/msg01556.html

was the design "feature" (I believe it is a defect), that
the ephemeral key exchange in the server key exchange handshake
message exists only in a an exteremely paranoid variant, requiring
an additional private key operation for every handshake.

It would really help if client and server could negotiate the use
of alternative "signed parameters format" for ephemeral (RSA) keys
that do not require a seperate signature (=private key operation)
for each handshake, but where the signed parameters could be reused
for several hours, maybe using a time-based indicator for the
freshness of the ephemeral keypair.


-Martin

From mrex@sap.com  Wed Sep 18 19:47:17 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B16A11E8171 for ; Wed, 18 Sep 2013 19:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.199
X-Spam-Level: 
X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZcSsfsyAsSK for ; Wed, 18 Sep 2013 19:47:13 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B6A2E11E80E2 for ; Wed, 18 Sep 2013 19:47:11 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8J2l316009736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 04:47:03 +0200 (MEST)
In-Reply-To: <20130919013304.1D5EB1A983@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Thu, 19 Sep 2013 04:47: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: <20130919024703.3222C1A983@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 19 Sep 2013 02:47:17 -0000

Martin Rex wrote:
> 
> I'm not a cryptographer, but I'm actually not convinced that
> counter modes of AES are a road I want to travel.  (I'm wondering:
> do we actually know the length of the cycles of AES in counter mode?
> Is there a paper describing what assumption the security of counter
> modes are based on, and formal proofs that AES actually has all
> these properties?)

I should have first read what counter mode actually means,
such as http://tools.ietf.org/html/rfc3686#section-2

I'm sorry.

-Martin

From hughejp@mac.com  Wed Sep 18 23:10:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DF21F9BA4 for ; Wed, 18 Sep 2013 23:10:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.927
X-Spam-Level: 
X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=2.276,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKD14QMwUa5g for ; Wed, 18 Sep 2013 23:10:45 -0700 (PDT)
Received: from nk11p03mm-asmtp001.mac.com (nk11p03mm-asmtpout001.mac.com [17.158.232.236]) by ietfa.amsl.com (Postfix) with ESMTP id 4793921F9B91 for ; Wed, 18 Sep 2013 23:10:45 -0700 (PDT)
Received: from [10.0.1.3] (unknown [184.69.15.210]) by nk11p03mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTC00A8ZZTSC8A0@nk11p03mm-asmtp001.mac.com> for tls@ietf.org; Thu, 19 Sep 2013 06:10:41 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-19_02:2013-09-18, 2013-09-19, 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-1308280000 definitions=main-1309180209
References: <20130919024703.3222C1A983@ld9781.wdf.sap.corp>
In-reply-to: <20130919024703.3222C1A983@ld9781.wdf.sap.corp>
MIME-version: 1.0 (1.0)
Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=us-ascii
Message-id: <2AC3F10D-21A9-400E-9A5C-7281F1FB9537@mac.com>
X-Mailer: iPad Mail (11A465)
From: james hughes 
Date: Wed, 18 Sep 2013 22:54:26 -0700
To: "mrex@sap.com" 
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 06:10:51 -0000

> On Sep 18, 2013, at 7:47 PM, mrex@sap.com (Martin Rex) wrote:
>>=20
>> I'm not a cryptographer, but I'm actually not convinced that
>> counter modes of AES are a road I want to travel.  (I'm wondering:
>> do we actually know the length of the cycles of AES in counter mode?

Hmmm, I am, and, yes, we do. It is a well known proven fact that a properly c=
hosen IV with a symmetric block cipher is full length, in that it is 2^128 b=
locks (for 128 bit AES) before recycling. I have a question for you... Do yo=
u have the patience to understand what "properly chosen" really means?=20

This is a serious question.

I realize that there are a lot of politics within the TLS community that "re=
al" cryptographers are not willing to play, and I may well be one of those w=
hom you will wash away...=20

Do you really want to hear, or are your own sound bites enough?




From juraj.somorovsky@rub.de  Thu Sep 19 00:39:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825CF21F992B for ; Thu, 19 Sep 2013 00:39:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsNIx4x06KqD for ; Thu, 19 Sep 2013 00:39:00 -0700 (PDT)
Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id CAE3C21F97C7 for ; Thu, 19 Sep 2013 00:38:59 -0700 (PDT)
X-Queued: (qmail 23066 invoked by alias); 19 Sep 2013 07:38:58 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 22984 invoked by uid 109); 19 Sep 2013 07:38:56 -0000
X-Qmailscanner: from 134.147.42.227 by mx4.rz.ruhr-uni-bochum.de (envelope-from , uid 103) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88.   Clear:RC:1(134.147.42.227):.  Processed in 0.05432 secs); 19 Sep 2013 07:38:56 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx4.rz.ruhr-uni-bochum.de with SMTP; 19 Sep 2013 07:38:56 -0000
X-Queued: (qmail 889 invoked by uid 992); 19 Sep 2013 07:38:56 -0000
X-Qmailscanner: from 178.201.6.234 (7Cil8M2CiUwoiuklz5GN4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de (envelope-from , uid 0) with qmail-scanner-2.01  (sophie: 3.06/3.45.0/4.91.  Clear:RC:1(178.201.6.234):.  Processed in 0.022493 secs); 19 Sep 2013 07:38:56 -0000
Received: from ip-178-201-6-234.unitymediagroup.de (HELO ?192.168.0.103?) (7Cil8M2CiUwoiuklz5GN4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 19 Sep 2013 07:38:55 -0000
Date: 19 Sep 2013 09:38:54 +0200
Message-ID: <523AAA0E.2020105@rub.de>
From: "Juraj Somorovsky" 
To: "Michael StJohns" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de> <52379643.7070705@nthpermutation.com>
In-Reply-To: <52379643.7070705@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 07:39:06 -0000

On 09/17/2013 01:37 AM, Michael StJohns wrote:
> On 9/16/2013 6:47 PM, Juraj Somorovsky wrote:
>> Just a quick questions:
>> I do not know if I understand this scenario correctly...but how can this
>> be achieved in TLS?
>> New key/IV material is always generated from client's as well as
>> server's random. The attacker can choose the same client random, but he
>> cannot influence the server random... thus always new key/IV material is
>> generated.
> 
> This isn't about influencing the new key, but being able to extract the
> old key.  Assume the attacker a) has use of the master key (either
> because he's running as hacked code, or because he managed to capture
> the PKCS11 pin and has access to the PKCS11 module), b) has captured all
> the necessary public data (e.g. has the previous random values from
> listening to the TLS exchange).   He then calls PKCS11 with the master
> key, the random data, but specifies that he needs smaller (e.g. no) mac
> and encryption keys.  The part of the key stream previously assigned to
> the mac and encryption keys (and safely protected inside the PKCS11
> module) is now assigned to the IV part of the structure and is now
> accessible to the attacker/caller of the module.   That attacker then
> takes that data and sends it off to someone who can intercept the
> traffic somewhere in the middle. There are a number of sub-scenarios
> which are dependent on where the PKCS11 module is, and where the
> attacker is and where the data is intercepted.

Thanks for the explanation, I understand it now. If this is how PKCS11
modules could be used in SSL, I admit this is a threat and agree with
your changes.

>> I would propose to make it more concrete for PKCS11 and generate the
>> keys depending on the algorithms they are used in. For example, if you
>> have a master_secret used to generate keys for AES_GCM and AES_CBC, you
>> would use:
>> k_GCM = PRF(master_secret, "AES_GCM", [further params])
>> k_CBC = PRF(master_secret, "AES_CBC", [further params])
> 
> As long as you can control the length of the encryption and mac key in
> the call to PKCS11, you have an issue if you can produce IV material
> from the same key stream you use to produce encryption or mac keys.   
> If you're suggesting using the above for generating IV material, it's
> doable, but maybe a bit of overkill.  I'd rather generate the IV from
> the public information only (e.g. only use the random data as the PRF
> seed).
Let me please extend your scenario:
o Consider  an application that needs to produce 2 128 bit AES keys.
o Consider that an attacker (or a hacked program that's being used to
extract keys) re-runs the derivation using the same master key and same
random data, this time specifying 64 bits of DES keys.
o Consider that the attacker can "break" DES (can get key from
plaintext-ciphertext pairs), but cannot break AES.

The part of the key stream previously used for AES is now assigned to
the DES keys. If the PKCS11 module now produces some
plaintext-ciphertext pairs, the attacker can break DES and thus gets
part of the key stream previously assigned to AES.

I admit I am not that familiar with PKCS11 modules used in
TLS...However, would this be a valid scenario?

My previous point was to extend your algorithm to force different keys
for different security algorithms.

Thanks
Juraj

From pgut001@cs.auckland.ac.nz  Thu Sep 19 01:50:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228FF21F853A for ; Thu, 19 Sep 2013 01:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxZiNoPtYDzD for ; Thu, 19 Sep 2013 01:50:19 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF5121F943C for ; Thu, 19 Sep 2013 01:50:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379580618; x=1411116618; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=FaTJHN6tOIpXbJfIc+1aZr+34l5S46tT5hdtbScyc8A=; b=qE708JqqPd3M57pCqkjHN+Gj/LrwsH6Jgnq3+5L4TCW7HiF6ItUc7GYD 4R4ZYQ6+PXaSo+UmeK4yIM6PVt57dxzHMie9HbkjZ6mV2jZT7NlgoAGmf X8Hzl8bl5VfYKTOyTWrWwd3Pc7RNzUfGhSq84DLnFafG/6P2xi/xERPRN k=;
X-IronPort-AV: E=Sophos;i="4.90,936,1371038400"; d="scan'208";a="213030565"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Sep 2013 20:50:06 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 20:50:05 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac61FTyMzOCwOl5kS0aueBIeUMTlKw==
Date: Thu, 19 Sep 2013 08:50:05 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355674007@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 08:50:25 -0000

Yaron Sheffer  writes:=0A=
=0A=
>There are multiple issues with MODP DH in TLS (performance is just one of=
=0A=
>them). So I'd like to recommend EC DHE instead - which makes this discussi=
on=0A=
>moot.=0A=
=0A=
There are even more issues with ECC, namely their brittleness, paranoia=0A=
(whether justified or not) about NSA meddling, and patent issues.  DH is=0A=
simple in comparison.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Thu Sep 19 01:56:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B1A21F9967 for ; Thu, 19 Sep 2013 01:56:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZHNnpgTl2lF for ; Thu, 19 Sep 2013 01:55:56 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4DB21F9962 for ; Thu, 19 Sep 2013 01:55:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379580948; x=1411116948; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Tjkd5xH+pPSEthVttZXIJ+JS5GsfAtyk4kiWGwyBpz8=; b=dn7dZ8jn511DZH7nW2jyrPPAemznbJOV5ODGmlfI88mww1z2FU5HCF4c 45etwEwWxLVSCCag8eKNJ0Slda1L5PC6oYKHG/gq6TgwG86gufr3FhomG YWS3zzaIkoqzJJe0pIvSlYY3aFVP2USt4GQzQ0k4Ijpc9iRWn7Macb5Yq o=;
X-IronPort-AV: E=Sophos;i="4.90,936,1371038400"; d="scan'208";a="213030864"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Sep 2013 20:55:47 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 20:55:46 +1200
From: Peter Gutmann 
To: "TLS@ietf.org (tls@ietf.org)" 
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: Ac61FgeV7FuS2V+MQFyIfXCx13e6Xg==
Date: Thu, 19 Sep 2013 08:55:46 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355674018@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 08:56:01 -0000

Trevor Perrin  writes:=0A=
=0A=
>I assume that's why no-one reviewed it carefully.=0A=
=0A=
[...]=0A=
=0A=
>The "Experimental" marking wasn't enough to prevent people like CT, TACK,=
=0A=
>DTCP, and OpenSSL wasting a lot of time evaluating this and trying to use =
it=0A=
>in the last couple of years.=0A=
=0A=
This seems to combine the worst of both worlds, no-one was really intereste=
d=0A=
in it so it passed without review, but then there was enough interest in it=
=0A=
later for people to try and implement it.  Can anyone who tried to implemen=
t=0A=
it explain why they did so?=0A=
=0A=
Peter.=0A=
=0A=

From mrex@sap.com  Thu Sep 19 02:54:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48BD821F93E1 for ; Thu, 19 Sep 2013 02:54:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.208
X-Spam-Level: 
X-Spam-Status: No, score=-10.208 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGqQ5OuP8-je for ; Thu, 19 Sep 2013 02:54:37 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id D976921F93E4 for ; Thu, 19 Sep 2013 02:54:36 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8J9sYq3023145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 19 Sep 2013 11:54:35 +0200 (MEST)
To: tls@ietf.org
Date: Thu, 19 Sep 2013 11:54:34 +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: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Subject: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 19 Sep 2013 09:54:42 -0000

I'm wondering which ssl/tls alert would be the most appropriate
for a TLS server to send if the server requested a client cert
and the client presents a certificate with a keyUsage that
does not have digitalSignature asserted.

OpenSSL seems to send "illegal parameter" alert when processing
CertificateVerify.  I might have chosen "bad certificate" alert.


A related issue would be that a TLS server is using a server
certificate with an RSA key and a keyUsage attribute with just
keyEncipherment.  Such a TLS server cert seems to preclude
its use for DHE_RSA and ECDHE_RSA cipher suites.  What would
be the appropriate alert (for the client to send) if the server
had such a certificate and chose a DHE_RSA or ECDHE_RSA cipher
suite anyway?

It is my impression that there exists CA software that creates
RSA certificates with ExtendedKeyUsage id-kp-serverAuth and
keyUsage limited to keyEncipherment by default.

Do we have a rough idea how common such TLS server certs are
(e.g. from SSL Observatory database)?


-Martin

From pgut001@cs.auckland.ac.nz  Thu Sep 19 02:56:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD58B21F9425 for ; Thu, 19 Sep 2013 02:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4B7LT36pnRVQ for ; Thu, 19 Sep 2013 02:56:15 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 507DA21F93E1 for ; Thu, 19 Sep 2013 02:56:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379584576; x=1411120576; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=b65qJ9MVti7gQETg4cf9MLQMBauZw4gdxfnFbnldZZg=; b=puj/e1eycUefNboPFVFfRRzp4GXzE5A2yTmTtlOv+d457xX9ZjbfCnBP pN/MrJsLz6+0jwFncCc0U/nLsYzZ+DWtJLdNlJNgE3nQSJoyYkAgrzC1a Hf8PK+pvyyOPKaxKWWH/wZ9InY13VFEBB7SXz9mU8opz93Xcx5gAkou/p M=;
X-IronPort-AV: E=Sophos;i="4.90,936,1371038400"; d="scan'208";a="213036194"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 19 Sep 2013 21:56:14 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 21:56:13 +1200
From: Peter Gutmann 
To: "TLS@ietf.org (tls@ietf.org)" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac61HnofVs3kv5NUTXSs0s2pfqNT8w==
Date: Thu, 19 Sep 2013 09:56:14 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 09:56:20 -0000

"Blumenthal, Uri - 0558 - MITLL"  writes:=0A=
=0A=
>I personally think that for *ephemeral* DH even 1024 bits still is enough.=
=0A=
>And would *much* prefer having PFS now with individual session keys at=0A=
>somewhat greater risk, over a system that is very secure and completely=0A=
>useless because nobody bothered to deploy it.=0A=
=0A=
Exactly.  We don't need theoretically perfect security in ten years when we=
've=0A=
finished arguing about it and have upgraded every system on the planet to=
=0A=
support it, we just need good enough right now.  That's DH-1024, and when w=
e=0A=
have that turned on everywhere we've got some breathing space to worry abou=
t=0A=
what to do next.=0A=
=0A=
Peter.=0A=
=0A=

From yaronf.ietf@gmail.com  Thu Sep 19 02:59:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 335CB21F850D for ; Thu, 19 Sep 2013 02:59:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFLvxBhVgoY1 for ; Thu, 19 Sep 2013 02:59:11 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7E11621F84F9 for ; Thu, 19 Sep 2013 02:59:11 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id w62so7766493wes.32 for ; Thu, 19 Sep 2013 02:59:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=51HhTY9gewNJ0R5qB1AFikXglm9dKgMhd7wHyCUUUF0=; b=RCf4YdID5/MLeV9aD6YuNHvI+/QqvEtyxboocf9w4g0+gJcpHQkjqwqi6nSpAkr9g6 2Iys7Ts3oUC5XvTmEem+je0iLTfbMnm2nTvOE+9DV7wsQuNtzZR0hCg79j7WIqQQWkkd 6MxdEh7jD2SP7GlxRqX0JBy7rk/Oxwn+LLy9nhS8hU+3/C55spD7U70PH3svapC617b5 vt4uFc5PIbGGhVi3DLKqYiCqjS6PdnVqPl0rS2M6+lRsjwCDcVwYLjpdw0bNlSOArbUV MLVB/xQymcc8PipvncCD8JVLlpm/Oou/kKqAxpeAqC+PfkOb39woHLJPES4lT5qqcG6M 5/VQ==
X-Received: by 10.180.210.243 with SMTP id mx19mr10752121wic.35.1379584750665;  Thu, 19 Sep 2013 02:59:10 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id l9sm17550920wif.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 02:59:10 -0700 (PDT)
Message-ID: <523ACAEC.6070801@gmail.com>
Date: Thu, 19 Sep 2013 12:59:08 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C7355674007@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674007@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 09:59:12 -0000

Hi Peter,

I think we've been through all these arguments (on both sides of the 
issue) over the last week, with the exception of "ECC brittleness". Can 
you please clarify what you mean by that?

Thanks,
	Yaron

On 09/19/2013 11:50 AM, Peter Gutmann wrote:
> Yaron Sheffer  writes:
>
>> There are multiple issues with MODP DH in TLS (performance is just one of
>> them). So I'd like to recommend EC DHE instead - which makes this discussion
>> moot.
>
> There are even more issues with ECC, namely their brittleness, paranoia
> (whether justified or not) about NSA meddling, and patent issues.  DH is
> simple in comparison.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From michael@stroeder.com  Thu Sep 19 03:18:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506C021F999D for ; Thu, 19 Sep 2013 03:18:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.476
X-Spam-Level: 
X-Spam-Status: No, score=-2.476 tagged_above=-999 required=5 tests=[AWL=0.824,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hen7ASI04Hof for ; Thu, 19 Sep 2013 03:18:05 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD9E21F99CC for ; Thu, 19 Sep 2013 03:18:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5C821602E1; Thu, 19 Sep 2013 12:18:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSZpI8ZMlHRY; Thu, 19 Sep 2013 12:17:55 +0200 (CEST)
Received: from srv1.stroeder.com (unknown [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id BE3516023E; Thu, 19 Sep 2013 10:17:55 +0000 (UTC)
To: "tls@ietf.org" , Peter Gutmann 
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674007@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7355674007@uxcn10-6.UoA.auckland.ac.nz>
From: "Michael =?UTF-8?B?U3Ryw7ZkZXI=?=" 
Date: Thu, 19 Sep 2013 12:17:55 +0200
Content-Type: text/plain; charset=UTF-8; format=fixed
MIME-Version: 1.0
Message-id: 
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 10:18:10 -0000

On Thu, 19 Sep 2013 08:50:05 +0000 Peter Gutmann 
wrote
> Yaron Sheffer  writes:
> 
> >There are multiple issues with MODP DH in TLS (performance is just one of
> >them). So I'd like to recommend EC DHE instead - which makes this discussion
> >moot.
> 
> There are even more issues with ECC, namely their brittleness, paranoia
> (whether justified or not) about NSA meddling, and patent issues.  DH is
> simple in comparison.

I tend to concur with Peter here.

Especially if only the limited param length of MODP DH in current
implementations rules out its recommendation in the draft.

Ciao, Michael.



From benl@google.com  Thu Sep 19 03:26:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAEF621F91AB for ; Thu, 19 Sep 2013 03:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Level: 
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.500,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDQoUeBcqi8L for ; Thu, 19 Sep 2013 03:26:21 -0700 (PDT)
Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by ietfa.amsl.com (Postfix) with ESMTP id 52B6E21F9196 for ; Thu, 19 Sep 2013 03:26:21 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so15325297ief.29 for ; Thu, 19 Sep 2013 03:26:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rTjR+Uy+Fh/A55GBptPmfvDs8Gwphd9Mlkb/OejCJdc=; b=pgD5fujjvnJ0rkS0Qq9v0Eg+OipH5l1kh9N+INYyhvCaR0IkJwUw/5EdoDOk5V0nDr ilPP6iOB+tpOVT1V9hXZBuUI3LUb756Sv/6HcH/4hBdZUdP3M+SLbtYh0XunwJU1yv1S 8S3pD+jzYKedYwjhfOL8sjZoau0JUPyQeEV/qhEltdTQ3tIWVzQ3Fe+Z8HGeegkePGhJ OThf0pd6Koe1/V4mw3rHE1t2mmF+VNtJAP/+FwrnOqmWG0PQ0vbLbPV2wPldqSDa/BVO 8A2Mq5nhKLJKc2dhcnloINGFLFLgAD95+q2G/zi1IJ7a1r+yT0CexYCIFBxRogKtEAsj /UNw==
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=rTjR+Uy+Fh/A55GBptPmfvDs8Gwphd9Mlkb/OejCJdc=; b=jv8ViYH4Zo9Ah9eCXFymLrbRyaeodwEk5PFYQE5nhARhMKMB862s/74DthG28uQqSQ PaZAct7j620BCw5rEbtbDwB+k6mbPethtYBqfZY3JCQDcMlyz089uYFBT7yG2JfxPzxC orN8wdup00re+9oxavZ3qSucbFvHN1KzMNj17SIutoS2M+Gfwtl8AB95mIAvpcXJUrGL 1ZEF+M5oZj0zFBfSgPP0s7OZ7I9M5eew5TeJo53B0cysFhEE7jvMnmkCCKpH9O2YBGnI LXdfuFbCICUpGj7XW9Pe5kR3sHt22FM5sEdI1wO6uj5i9jN+joLEXsAy6zjXnLoIu/Pk avyw==
X-Gm-Message-State: ALoCoQlXZEkqTGOQIRbqP1SxPnJ/bVXHca5EXUxxtZ/bULe3iiG5L4gK1fKm8Gy9wj3euEFFC1zjtHnVsvIJMRLtLf4V8FerQsQIjzGFo3/VpzmuBl/zKz+YHBCk4HXzBV4aZO3JqVz1Vss/ru4dA7pdRjTKDBQLLAXz3p0DU4L9rj90bQ3cdzl/2xYio6XE9ydQiyEOOcwQ
MIME-Version: 1.0
X-Received: by 10.42.51.6 with SMTP id c6mr450675icg.3.1379586363658; Thu, 19 Sep 2013 03:26:03 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Thu, 19 Sep 2013 03:26:03 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674018@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7355674018@uxcn10-6.UoA.auckland.ac.nz>
Date: Thu, 19 Sep 2013 11:26:03 +0100
Message-ID: 
From: Ben Laurie 
To: Peter Gutmann 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 10:26:29 -0000

On 19 September 2013 09:55, Peter Gutmann  wrote:
> Trevor Perrin  writes:
>
>>I assume that's why no-one reviewed it carefully.
>
> [...]
>
>>The "Experimental" marking wasn't enough to prevent people like CT, TACK,
>>DTCP, and OpenSSL wasting a lot of time evaluating this and trying to use it
>>in the last couple of years.
>
> This seems to combine the worst of both worlds, no-one was really interested
> in it so it passed without review, but then there was enough interest in it
> later for people to try and implement it.  Can anyone who tried to implement
> it explain why they did so?

In CT's case it was because it seemed convenient at the time - we need
to send authz data during the TLS handshake, and here was a way
already defined to do it. We debated allocating a new extension for
it, but decided against it. In the end, because 5878 had errors that
we did not have the power to correct, we decided to abandon it.

I notice that the authors have not responded to the corrections,
either. So I guess they've abandoned it, too.

From yaronf.ietf@gmail.com  Thu Sep 19 03:33:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D221421F93BF for ; Thu, 19 Sep 2013 03:33:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.899
X-Spam-Level: 
X-Spam-Status: No, score=-102.899 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvWXrlxJHCm8 for ; Thu, 19 Sep 2013 03:33:47 -0700 (PDT)
Received: from mail-bk0-f41.google.com (mail-bk0-f41.google.com [209.85.214.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0DECD21F93E4 for ; Thu, 19 Sep 2013 03:33:45 -0700 (PDT)
Received: by mail-bk0-f41.google.com with SMTP id na10so3436950bkb.28 for ; Thu, 19 Sep 2013 03:33:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=kPhpsIsJqOBlyJinJbgloVYEKCUhLJNgzELzba+vffg=; b=SI5Eljm1BDxXq5WLR2hgAWwzbuufBYC2GpmHwBzJvGOaGR0v//KqfDM/r1/c49V0B+ 1xesGvnKgrolZTgLBZnHFX6amJBWvNhyMkwZ4okp7NEJJObE+evWtWx8rVCEYs7+TDg7 VrpLKLu441gSuFXeDyluIfWykO+mI8Odfmq0Jnt2josnSLZ1fNRmDJ/BXgNZQhi+ZbNo rZCnkjbjLRTfF8/CCgLGo8Y8VQgjHckgjWvrceAwAnnThCCW5ka3KyP2xqS5VfBkT1KL i7mUEM0UzCBL/QWBPA95577v44Wml63wpEFAjdalYHBILw3Bds2jAkkUdZQTHyA912UJ CwdQ==
X-Received: by 10.204.226.71 with SMTP id iv7mr539784bkb.32.1379586810115; Thu, 19 Sep 2013 03:33:30 -0700 (PDT)
Received: from [10.0.0.8] (bzq-109-64-175-213.red.bezeqint.net. [109.64.175.213]) by mx.google.com with ESMTPSA id b7sm2625158bkg.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 03:33:29 -0700 (PDT)
Message-ID: <523AD2F5.90206@gmail.com>
Date: Thu, 19 Sep 2013 13:33:25 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= 
References: <9A043F3CF02CD34C8E74AC1594475C7355674007@uxcn10-6.UoA.auckland.ac.nz> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 10:33:52 -0000

I'm afraid you're ignoring facts here. Both Chrome and Firefox on my 
machine connect to Google using ECDHE by default. Together they make up 
36% of the browser market share [1]. And for both of them, as opposed to 
IE, people tend to use the latest browser versions. To put it bluntly, 
people who are still using IE8 are not the target audience for this draft.

So client-side support, at least, is not an issue.

Thanks,
	Yaron

[1] 
http://thenextweb.com/insider/2013/08/01/ie9-falls-below-10-market-share-firefox-hits-50-month-low-and-chrome-again-gains-the-most/

On 09/19/2013 01:17 PM, Michael Ströder wrote:
> On Thu, 19 Sep 2013 08:50:05 +0000 Peter Gutmann 
> wrote
>> Yaron Sheffer  writes:
>>
>>> There are multiple issues with MODP DH in TLS (performance is just one of
>>> them). So I'd like to recommend EC DHE instead - which makes this discussion
>>> moot.
>>
>> There are even more issues with ECC, namely their brittleness, paranoia
>> (whether justified or not) about NSA meddling, and patent issues.  DH is
>> simple in comparison.
>
> I tend to concur with Peter here.
>
> Especially if only the limited param length of MODP DH in current
> implementations rules out its recommendation in the draft.
>
> Ciao, Michael.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From rsalz@akamai.com  Thu Sep 19 05:22:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F3621F97C7 for ; Thu, 19 Sep 2013 05:22:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBXarWCHS1iw for ; Thu, 19 Sep 2013 05:22:23 -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 AB1DF21F96EF for ; Thu, 19 Sep 2013 05:22:23 -0700 (PDT)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A253A48191; Thu, 19 Sep 2013 12:22:20 +0000 (GMT)
Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 95AAD48139; Thu, 19 Sep 2013 12:22:20 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 7B62B2FD51; Thu, 19 Sep 2013 12:22:20 +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; Thu, 19 Sep 2013 08:22:12 -0400
From: "Salz, Rich" 
To: Ben Laurie , Peter Gutmann 
Date: Thu, 19 Sep 2013 08:22:12 -0400
Thread-Topic: [TLS] RFC 5878 - why?
Thread-Index: Ac61IrKqzn9QFpgTRhWRIMuO/r4fNgAD/3Mg
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711D4594B66@USMBX1.msg.corp.akamai.com>
References: <9A043F3CF02CD34C8E74AC1594475C7355674018@uxcn10-6.UoA.auckland.ac.nz> 
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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 12:22:39 -0000

> I notice that the authors have not responded to the corrections, either. =
So I guess they've abandoned it, too.

I am always reluctant to take such passive response as sign of anything.

I suggest Travis contact the authors and/or submit an errata that says "we =
wish to mark this RFC as a failed experiment for the following reasons" or =
something like that.

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA


From mike-list@pobox.com  Thu Sep 19 08:39:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D597C21F90E5 for ; Thu, 19 Sep 2013 08:39:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eSkpcGY8J6ru for ; Thu, 19 Sep 2013 08:39:46 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9B66921F8F9A for ; Thu, 19 Sep 2013 08:39:46 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 945F9D0F9; Thu, 19 Sep 2013 11:39:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=hjbJnPpnOA6v 8rRJCltQDuzNMOw=; b=EhmgFXAYSob1h8nBtIVTA8/fY7+2u91TWUCOhL9LUllU CzIDqpCmZ4KDuY0WLZT2WE9pKGCjy6sepcAhcRdzOmGJw+fFrHM+hMY6kCF/uyHA AI7Anmq5Dyrxm0C/wagkgefFu6nNkEYHfFHAU3z8wc4st8tSAPD6wqK9jaagDhQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=CQEkxI l6OnGnf1gS35M5ro9/g0M4+L06ziRQ0q/Vtiq9rOjHmcTS+TASEAwWj5/ZY3Ff/K TLJh9GCVt23zs00iohaynhIGgE/pFP2HRR8TTurt5MCDsLpPKzn6Qh4J1pRFoxMt i5/FJpva1tAciNZ/7ohThIsI8juZNFhuFyMCo=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 8A523D0F8; Thu, 19 Sep 2013 11:39:33 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id B456AD0F7; Thu, 19 Sep 2013 11:39:32 -0400 (EDT)
Message-ID: <523B1AB3.1060001@pobox.com>
Date: Thu, 19 Sep 2013 08:39:31 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: mrex@sap.com
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
In-Reply-To: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: AE1F1026-2141-11E3-B4F9-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 15:39:52 -0000

Martin Rex wrote:
> I'm wondering which ssl/tls alert would be the most appropriate
> for a TLS server to send if the server requested a client cert
> and the client presents a certificate with a keyUsage that
> does not have digitalSignature asserted.
> 
> OpenSSL seems to send "illegal parameter" alert when processing
> CertificateVerify.  I might have chosen "bad certificate" alert.

BadCertificate seems better since it points the client toward the
encountered problem....

Mike

From wtc@google.com  Thu Sep 19 08:43:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB3521F9399 for ; Thu, 19 Sep 2013 08:43:36 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WvG-ybjO1YN for ; Thu, 19 Sep 2013 08:43:35 -0700 (PDT)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B103521F8F9A for ; Thu, 19 Sep 2013 08:43:35 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id k4so3683514qaq.6 for ; Thu, 19 Sep 2013 08:43:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d42lvA/I4a7W7NeAjF4Yx0bODKOphSHuL9fqVwKhP4Y=; b=c2VtJSVx9anpItyay2RwDgsqtqy4BBDDDmUZzFiANXj0uBLpNJAAT08ItOxxjJV9tu XyJiKwBIyZMyG2lP+ZU25OggRZJ7hUcmkSwgooZ85tdXIHHEW3L2l07U1Hw9tw8V05vM RWgVERkLWsTk+YM3mIfJPf+Pqyp+9aPoqwR9XNu65zuFNsiI5M6FKSkt0GQ8OxdMaCto 6Sv5LJVgf/NDzAJCJtoneJxEY+0vtjZjPSts1jMc0LsCpDgrjkO50rLO6K1TjCzkNZiI QtDG+gVuWIkuodS24T6Jmk9zojTpSFyQJLEWQuohNu9SB7mx0ZkkQE+RY5cHs7vmR335 /HFw==
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=d42lvA/I4a7W7NeAjF4Yx0bODKOphSHuL9fqVwKhP4Y=; b=ifI3NTDMzDESqRysA8BJ6P8Sqedld4pFss/VUAAvPHSqnXQAYQ5DcPa5R0zAjg3zc6 YEJyC3HJVvH6doZO0w5ziXO87b5NdDTxZMgkAhPbvRsDd3GLpRdPa4J+IziFLLvu9khs pyC0fywx3T2yyxd01yp7OguJ76E65lu05YsBC510MRTyvFyYdKKq6lOI9u2fVOpHebpM 12uliein2eV9d7+fcJVTeZyqsqJktnnVZzzRcQv2UUiQKPTm+ADxVZXbzaNJW6q0XoUV eIIf3BmCxkKyCnfKPTLmzMjhI/UKn3MfWsOoLddw/V+vYqHqFyGwA9y2ESLY4vmNumc4 4ubw==
X-Gm-Message-State: ALoCoQkQOUWLRiHCKISC0nf70lRbJf465zc4b9IfK3pVYSgbfywT/tQFBPMoe8smTQHYEOPTpEdqz2oGmQ2EIx37+MNumYQIqTAiFwtdZmnll4KVHokpgph9oJ1Z2JkUZPMxpYTdhQ00jL/+QyemAjK3Iq6pTQ2JtujgGOvaQk5BQ0NuMPcOsDtcIaRjUYJtrr7ozlIMusQD
MIME-Version: 1.0
X-Received: by 10.49.58.174 with SMTP id s14mr4724994qeq.73.1379605412992; Thu, 19 Sep 2013 08:43:32 -0700 (PDT)
Received: by 10.229.176.133 with HTTP; Thu, 19 Sep 2013 08:43:32 -0700 (PDT)
In-Reply-To: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp>
Date: Thu, 19 Sep 2013 08:43:32 -0700
Message-ID: 
From: Wan-Teh Chang 
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 15:43:36 -0000

On Thu, Sep 19, 2013 at 2:54 AM, Martin Rex  wrote:
> I'm wondering which ssl/tls alert would be the most appropriate
> for a TLS server to send if the server requested a client cert
> and the client presents a certificate with a keyUsage that
> does not have digitalSignature asserted.
>
> OpenSSL seems to send "illegal parameter" alert when processing
> CertificateVerify.  I might have chosen "bad certificate" alert.

I would also choose an alert related to certificates, such as
bad_certificate, unsupported_certificate, or certificate_unknown.

As far as I can tell, NSS intends to send certificate_unknown under
this condition (and similarly for a server certificate with the wrong
keyUsage), but I don't know if it actually does that.

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/ssl3con.c&rev=1.207&mark=2886,2895-2897#2885

> A related issue would be that a TLS server is using a server
> certificate with an RSA key and a keyUsage attribute with just
> keyEncipherment.  Such a TLS server cert seems to preclude
> its use for DHE_RSA and ECDHE_RSA cipher suites.

Yes. The TLS 1.0 RFC says:

       Key Exchange Algorithm  Certificate Key Type

       RSA                     RSA public key; the certificate must
                               allow the key to be used for encryption.

       ...

       DHE_RSA                 RSA public key which can be used for
                               signing.

RFC 4492 says:

          Key Exchange Algorithm  Server Certificate Type
          ----------------------  -----------------------

          ...

          ECDHE_RSA               Certificate MUST contain an
                                  RSA public key authorized for
                                  use in digital signatures.  It
                                  MUST be signed with RSA.

Note: I don't understand why RFC 4492 says "It MUST be signed with RSA."

Wan-Teh Chang

From mike-list@pobox.com  Thu Sep 19 09:11:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3AD21F995A for ; Thu, 19 Sep 2013 09:11:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a3-iCkKftwu for ; Thu, 19 Sep 2013 09:10:49 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 9D82421F8BFD for ; Thu, 19 Sep 2013 09:10:49 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A5B92D2C4; Thu, 19 Sep 2013 12:10:47 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=O1PWbIUtH75t g/bGyFibwx4FQSo=; b=Hab/7x5UPuaZmRy/0n4DpaZOFwkETYJHLupfTWblvRx+ TQS/nFZUFPf9aCMceaWREM2vdcRVEIGRznqEPXj4m2iw2I39vHWCwSW9UwkCqdRk rj0dL87Ge7uPTC08kohiXB1BYhL4KlgC9+RuWPLZ2JQCngMiMNZB8S6Cszc5bBA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=xAmupW uEA1uxd4tmQUQHOcx3eX7znCSdUA1N2T5YANm9ZrOZXoaMmMZjRoTBNrhjUF60z+ Ka6/+B6uNxH5oK+tWRglCSbYeF5BYGPhH+VnHb/ec0lTTVgJfVBBduV1ACOovojL W3Wtid/yqv8A8I//f/glUbxeNuRHGu1lDMVyM=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 9BB7DD2C3; Thu, 19 Sep 2013 12:10:47 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id CFF0DD2C2; Thu, 19 Sep 2013 12:10:46 -0400 (EDT)
Message-ID: <523B2205.1040103@pobox.com>
Date: Thu, 19 Sep 2013 09:10:45 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Wan-Teh Chang 
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 0B39E96C-2146-11E3-87FE-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage	digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 16:11:01 -0000

Wan-Teh Chang wrote:
> 
> RFC 4492 says:
> 
>           Key Exchange Algorithm  Server Certificate Type
>           ----------------------  -----------------------
> 
>           ...
> 
>           ECDHE_RSA               Certificate MUST contain an
>                                   RSA public key authorized for
>                                   use in digital signatures.  It
>                                   MUST be signed with RSA.
> 
> Note: I don't understand why RFC 4492 says "It MUST be signed with RSA."

A certificate authority could, in theory, sign a certificate using
any algorithm it chooses.  Since the client is known to have code
for dealing with RSA (it asked for ECDHE_RSA) but not whether it
has code to validate any other type of signature algorithm, it makes
(practical) sense to limit the CA signature to RSA.

Mike

From dkg@fifthhorseman.net  Thu Sep 19 09:18:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFF221F92B7 for ; Thu, 19 Sep 2013 09:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j7Zq42lE87a for ; Thu, 19 Sep 2013 09:18:27 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 0657021F8B9C for ; Thu, 19 Sep 2013 09:18:27 -0700 (PDT)
Received: from [192.168.13.183] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1AD11F983; Thu, 19 Sep 2013 12:18:21 -0400 (EDT)
Message-ID: <523B23C7.4010704@fifthhorseman.net>
Date: Thu, 19 Sep 2013 12:18:15 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: Michael D'Errico 
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp>  <523B2205.1040103@pobox.com>
In-Reply-To: <523B2205.1040103@pobox.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2XHSOXQWBLSGKKAACAABK"
Cc: "tls@ietf.org" 
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage	digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 16:18:33 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2XHSOXQWBLSGKKAACAABK
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/19/2013 12:10 PM, Michael D'Errico wrote:
> Wan-Teh Chang wrote:
>> Note: I don't understand why RFC 4492 says "It MUST be signed with RSA=
=2E"
>=20
> A certificate authority could, in theory, sign a certificate using
> any algorithm it chooses.  Since the client is known to have code
> for dealing with RSA (it asked for ECDHE_RSA) but not whether it
> has code to validate any other type of signature algorithm, it makes
> (practical) sense to limit the CA signature to RSA.

But do we limit the certificate signature in any other context?  if not,
why limit it here?  for example, if the EE certificate is signed by an
intermediate CA using RSA, but that CA's own cert is signed using DSA or
ECDSA, is that OK?

Why haven't we applied these same-algorithm constraints to EE certs used
in DHE_RSA or RSA key exchanges for that matter?

I can see why the spec might recommend the use of RSA signatures on
certs that supply RSA keys (for the implementation-simplifying reasons
you propose), but making it an RFC 2119 MUST is pretty strong stuff, and
weirdly inconsistent with the rest of the specs, as i understand them.

	--dkg


------enig2XHSOXQWBLSGKKAACAABK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSOyPHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc4koQALZpLOKbwQAQdhOygJfsJUob
VQf8d/lIOi6PJFEvLFaTMOZuI87ziytAQkPHwa9Tss+p9eISkb/5Os1UiKowgB4d
3lkRAvzeQfQvlf7SUm/eT5s0s1UymQN2lCTinPtNywxI7PrDOhy87zX+jvSS5Dnz
FWy7LZFtiJbBuPTDOSjU69oxbtOLSr3BarYUYVRn3066kpFAInTYICEHfi3Lr4kw
bwNIS7ug/P8ciLqT57kw0i/gc6fxMk0ijYQVZuUBCuoPJ5hxPmiIc/qjbTOUy+IC
4n161LVNkehFZXpqvsDZzWXeSMJQhEa6EaXSKuYS4f56Y5W3q7klIKXhDbvT7XHS
kl7co3uJW0OkYaybppUlyB5l2fSjw6CHvHLDE4pFnWfNBSbi9oJHdKdflbntG0q2
nKc2q5ntQX9kJDa6hS1r5AmvmVypGW8x4BvaMk3yqky17JB15Orn3b5P7LslnKyi
SGCHsczhuXjM+Dfg6zRuYvWrb+mA2CtUWNOTVPKDC3ClVoTUMBfyAUDyZOUTyWKX
7fJDNs1euf3vNxV9iYOGYBvnEuIRLDagnAI5UL7FJSfqAsWIwE21YpOOHMWjP0VN
NB1Y9ZpfVMWQTP2CnVX55gyb3q2jT9lOiGpZzgO39ZW8lC/1HqK7fxJErk0sAGof
GN+EF0WuoMw7ahlHZC+9
=FhLv
-----END PGP SIGNATURE-----

------enig2XHSOXQWBLSGKKAACAABK--

From fabrice.gautier@gmail.com  Thu Sep 19 09:40:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B7021F958A for ; Thu, 19 Sep 2013 09:40:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0pTRVYlgrWr for ; Thu, 19 Sep 2013 09:40:41 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 72EDB21F949F for ; Thu, 19 Sep 2013 09:40:41 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id cb5so8323734wib.10 for ; Thu, 19 Sep 2013 09:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=oGBwmqZEn/jkmFtc7Vhaw47mfk4rMlKfAN2xI5K6vfE=; b=oFdymPLRNXZgYKAoK4HPxl3KNqb9tB7ZVFK/Bx908aoTx1ZvnS0QXvg1wAc9rzQJVV HaiSqFQG3aM5Lu/unVeHZ/EaDK4vnd5mcvq7i8No/ayWgv0bXVqeQCM60uRfm+tIdXOF hJQt9JWWhsKxiea81zJWICARJe8KW19o++7ueq4vy3j4DlWb+3qtkE2gsOuHF1a5x8P8 sLAQMNdYPJpwkzKMKSN/U7X1a1nF9pKO69XjzyqiEOKWBpbYv57Xa0YjP1mU8bD2Ko6Y Ik4VXtXTIY55L/JhoAvokVPEFfh5bgrhZciRbxvGQ3eArY5vNoE3phqmiP6WJaF7sh7T MMyQ==
X-Received: by 10.194.193.4 with SMTP id hk4mr2176773wjc.29.1379608840509; Thu, 19 Sep 2013 09:40:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.50.12 with HTTP; Thu, 19 Sep 2013 09:40:20 -0700 (PDT)
From: Fabrice Gautier 
Date: Thu, 19 Sep 2013 09:40:20 -0700
Message-ID: 
To: tls@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [TLS] Resuming a session as part of a renegotiation.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 16:40:42 -0000

Hi,

Is there anything in the TLS RFCs that prohibit using a resumed
session as a result of a renegotiation handshake ?

I haven't found anything, but I can't think of an interesting use case
for that behavior either.


-- Fabrice

From mike-list@pobox.com  Thu Sep 19 10:01:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8B321F93D4 for ; Thu, 19 Sep 2013 10:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1yULM+gfJn0K for ; Thu, 19 Sep 2013 10:01:33 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 58CB521F93C4 for ; Thu, 19 Sep 2013 10:01:32 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id EA941D5C6; Thu, 19 Sep 2013 13:01:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=1KbgnwsmRYGr lWSaqUKHsnZJbGI=; b=GCulLxhMFG6Nat0mSNZt5aN8rcDtpVHiK6xgrinaLYPQ QVx0Bwv4Fk4jomHm1nBAZU3QOLoYl+D/JaYTW2zclYwb+MEj5WJTf8kRQiFS95NH wX+pgbvzEbbwq0PAr5l6EK51z+OJ8U+xL+BdDO70XtvQTRopKqQmYFPu1eByQgA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=TbbPWS dcWdv5bYLjm7lLmeBhXzLq54SWsGuazc74yOeLNxdHpEwwUUXqWq2Z03sb4HNE+q n4Vvvs+ie5YZTMoG6aWqzWTWAMDPjb9wvyHuQhMXMNa9FY9FY+7YxmMjs22T7xQ4 FSDcfOOkbTx658e9xrWK/md6o0KdDFbpDvC5g=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E0C48D5C5; Thu, 19 Sep 2013 13:01:31 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id DBAB4D5C4; Thu, 19 Sep 2013 13:01:30 -0400 (EDT)
Message-ID: <523B2DE9.8090403@pobox.com>
Date: Thu, 19 Sep 2013 10:01:29 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Daniel Kahn Gillmor 
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp>  <523B2205.1040103@pobox.com> <523B23C7.4010704@fifthhorseman.net>
In-Reply-To: <523B23C7.4010704@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 21A2A1CE-214D-11E3-B4EC-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage	digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 17:01:38 -0000

Daniel Kahn Gillmor wrote:
> On 09/19/2013 12:10 PM, Michael D'Errico wrote:
>> Wan-Teh Chang wrote:
>>> Note: I don't understand why RFC 4492 says "It MUST be signed with RSA."
>> A certificate authority could, in theory, sign a certificate using
>> any algorithm it chooses.  Since the client is known to have code
>> for dealing with RSA (it asked for ECDHE_RSA) but not whether it
>> has code to validate any other type of signature algorithm, it makes
>> (practical) sense to limit the CA signature to RSA.
> 
> But do we limit the certificate signature in any other context?  if not,
> why limit it here?  for example, if the EE certificate is signed by an
> intermediate CA using RSA, but that CA's own cert is signed using DSA or
> ECDSA, is that OK?
> 
> Why haven't we applied these same-algorithm constraints to EE certs used
> in DHE_RSA or RSA key exchanges for that matter?
> 
> I can see why the spec might recommend the use of RSA signatures on
> certs that supply RSA keys (for the implementation-simplifying reasons
> you propose), but making it an RFC 2119 MUST is pretty strong stuff, and
> weirdly inconsistent with the rest of the specs, as i understand them.

Page 47 of RFC 5246 hints at these rules:

    If the client does not send the signature_algorithms extension, the
    server MUST do the following:

    -  If the negotiated key exchange algorithm is one of (RSA, DHE_RSA,
       DH_RSA, RSA_PSK, ECDH_RSA, ECDHE_RSA), behave as if client had
       sent the value {sha1,rsa}.

    -  If the negotiated key exchange algorithm is one of (DHE_DSS,
       DH_DSS), behave as if the client had sent the value {sha1,dsa}.

    -  If the negotiated key exchange algorithm is one of (ECDH_ECDSA,
       ECDHE_ECDSA), behave as if the client had sent value {sha1,ecdsa}.

Prior to TLS 1.2 it could be assumed that all clients supported RSA, and
if any supported DSA, they would be asking for DSS cipher suites.  Once
people started wanting to use new algorithms (ECC), it became necessary
to have a way for a client to indicate which algorithms it could process.

Mike

From mike-list@pobox.com  Thu Sep 19 10:05:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6F121F96EF for ; Thu, 19 Sep 2013 10:05:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3XhUhEY7oi3 for ; Thu, 19 Sep 2013 10:05:37 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D587621F970E for ; Thu, 19 Sep 2013 10:05:37 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 63DA7D606; Thu, 19 Sep 2013 13:05:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=hlldp0tC4Gu9 g3ZsNFJPYapIPUc=; b=kzVaRN+tZNzMJb12vGJryQXI3mmH2qVUjEXOomiXFJ3e 94PZoYpb9YtMqDXtrYSq+SqS2/4PQv1sSuSxyqtuOWBkQ9rZNomgv3VFwifrxFVs MKadpOwGIZT358NKxq5M0aOjg1IUfjabem3aJXOORJIJLWiwBniCDILANHQ54Kc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=G2IYBv VARvpVqUKdtRfVAniEzQex0lHQ3eFkZPiAKpyy48my4ifdlYpHwRfIFPa1p1iJIT CMWEOz8/jfltuRIh+vxfRdcZm8Kz/TZjz6uzJNNfhUrJ2PZJHvGP/s52pcX+zszz 09TO6dfbYyHBwCB8t2dxbr0edG02yW9AgolZQ=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5CCC1D605; Thu, 19 Sep 2013 13:05:37 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id AF22FD602; Thu, 19 Sep 2013 13:05:36 -0400 (EDT)
Message-ID: <523B2EDF.7010501@pobox.com>
Date: Thu, 19 Sep 2013 10:05:35 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Fabrice Gautier 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: B419968E-214D-11E3-8905-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] Resuming a session as part of a renegotiation.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 17:05:42 -0000

Fabrice Gautier wrote:
> 
> Is there anything in the TLS RFCs that prohibit using a resumed
> session as a result of a renegotiation handshake ?

No.

> I haven't found anything, but I can't think of an interesting use case
> for that behavior either.

Not sure if it's interesting, but you get fresh session keys.

One possible use case: if you negotiated a block cipher with a
small internal state and are sending large quantities of data,
security might be improved by periodically renegotiating.

Mike

From fabrice.gautier@gmail.com  Thu Sep 19 11:30:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD1721F92C2 for ; Thu, 19 Sep 2013 11:30:16 -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=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GiuLicuOYcdl for ; Thu, 19 Sep 2013 11:30:16 -0700 (PDT)
Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D601321F9228 for ; Thu, 19 Sep 2013 11:30:15 -0700 (PDT)
Received: by mail-we0-f173.google.com with SMTP id w62so8439268wes.32 for ; Thu, 19 Sep 2013 11:30: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:from:date:message-id:subject:to :cc:content-type; bh=4jb7brNtTNvVEgeGaXRGjhWp3j8cMGiFtcG2yLg/ZhA=; b=y/l5DVNdw3kEiFuunDfnfCpOiVf0pIdsHonE2jmV/teFO2NZcF/DllDzkEp54+lL1/ S87+w3t+zaQNUmoelq0J/ssmoHXiE8eGz78EwdzPg25u0O0hfrskvpL83RQ3uOA+iPJh +++dUj8URlpt/l/PXJFz4W0u/JXiOo5ZfB3BP1iQ8Z5cp5uePAwL9di5yUkr2Il8QiEt KQ/4qBRjSGIUrdpaw05nrZMFB1FePg+HMrqKTM7v0znj05aB5WnD9oMy8qeMC7MCv2lp PiNB+VrwuA1ntdAK9rLhvZNtcjdzDIVwwgLd9OOJw84c684mmJ1+1SayLn9GqLREpLiY z5VQ==
X-Received: by 10.194.240.129 with SMTP id wa1mr2558207wjc.31.1379615415060; Thu, 19 Sep 2013 11:30:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.50.12 with HTTP; Thu, 19 Sep 2013 11:29:54 -0700 (PDT)
In-Reply-To: <523B2EDF.7010501@pobox.com>
References:  <523B2EDF.7010501@pobox.com>
From: Fabrice Gautier 
Date: Thu, 19 Sep 2013 11:29:54 -0700
Message-ID: 
To: "Michael D'Errico" 
Content-Type: text/plain; charset=ISO-8859-1
Cc: tls@ietf.org
Subject: Re: [TLS] Resuming a session as part of a renegotiation.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 18:30:16 -0000

On Thu, Sep 19, 2013 at 10:05 AM, Michael D'Errico  wrote:
> Fabrice Gautier wrote:
>>
>>
>> Is there anything in the TLS RFCs that prohibit using a resumed
>> session as a result of a renegotiation handshake ?
>
>
> No.
>
>
>> I haven't found anything, but I can't think of an interesting use case
>> for that behavior either.
>
>
> Not sure if it's interesting, but you get fresh session keys.

Hum, I guess it depends your definition of 'fresh'. They might be
different after the renegotiation. But if you are resuming an old
session as part of a renegotiation, the freshness depends on how much
that particular resumed session has been used before.

Imagine the case where a server request renegotiation, but the client
send back a ClientHello with the same session ID as previously


> One possible use case: if you negotiated a block cipher with a
> small internal state and are sending large quantities of data,
> security might be improved by periodically renegotiating.

Thats only benefit a full handshake renegotiation.

The way I understand it, renegotiation allows you to have several
session in the same connection, and session resumption allows you to
have the same session across multiple connections.

Mixing the two gives you... well, I don't know if it gives you
anything useful...


-- Fabrice

From ynir@checkpoint.com  Thu Sep 19 11:50:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BCA21F94FF for ; Thu, 19 Sep 2013 11:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.306
X-Spam-Level: 
X-Spam-Status: No, score=-10.306 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhGNdkd4GueX for ; Thu, 19 Sep 2013 11:50:15 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 39FC921F949F for ; Thu, 19 Sep 2013 11:50:13 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8JIo2XD022276; Thu, 19 Sep 2013 21:50:02 +0300
X-CheckPoint: {523B475A-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Thu, 19 Sep 2013 21:50:02 +0300
From: Yoav Nir 
To: Fabrice Gautier 
Thread-Topic: [TLS] Resuming a session as part of a renegotiation.
Thread-Index: AQHOtVcKv1CYPPdg20+k8rtQdCDoEpnNF/CAgAAXjwCAAAWlAA==
Date: Thu, 19 Sep 2013 18:50:01 +0000
Message-ID: <582A57A2-C452-463D-8B79-6CF6E3804732@checkpoint.com>
References:  <523B2EDF.7010501@pobox.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.151]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <368B4F775CBF3D44BD0E86AA2C86592D@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] Resuming a session as part of a renegotiation.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 18:50:21 -0000

On Sep 19, 2013, at 9:29 PM, Fabrice Gautier  wr=
ote:
>> One possible use case: if you negotiated a block cipher with a
>> small internal state and are sending large quantities of data,
>> security might be improved by periodically renegotiating.
>=20
> Thats only benefit a full handshake renegotiation.
>=20
> The way I understand it, renegotiation allows you to have several
> session in the same connection, and session resumption allows you to
> have the same session across multiple connections.

Renegotiation just means doing the handshake again. The end result is new k=
eys. So if you believe that 3DES keys should not be used for more than 0.5G=
B of data, just doing a renegotiation gives you fresh keys (because they ar=
e mixed with the new nonces). If you resume the session, you don't get new =
client and/or server identities, you don't get re-authentication, and you d=
on't get a new master key, so someone who has managed to get your old maste=
r key can figure out both your old and new encryption keys. But if the only=
 reason you're renegotiating is that you need fresh keys, that's good enoug=
h.

So renegotiation+resumption gives you the same session, but new keys. Sort =
of like "phase II" in IKE.

Yoav


From alfredo@pironti.eu  Thu Sep 19 12:07:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E133021F943C for ; Thu, 19 Sep 2013 12:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.479
X-Spam-Level: 
X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qv4PO5ECJ85p for ; Thu, 19 Sep 2013 12:07:17 -0700 (PDT)
Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id AB70021F9433 for ; Thu, 19 Sep 2013 12:07:16 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id hu16so3909111qab.0 for ; Thu, 19 Sep 2013 12:07:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=3VJYH6gVwlC28jzVO+pyu9PyIr+JY1TLwSS6s26bhg8=; b=Wy7CRYJ0Wsf3xsnetucr28kZ3drAXYMVp/VnIwPS36e18zXgNdfzz+C74V+r+0hJla FoFGXbeExXHwRRy5NlhVXI5fpqbxhp71Z667Xj29zleJ6z+HnGay2DSy7hQIC/vENK8K WcMvCTk41iTTRGOcFSOd5ZlpEl3ejGOdLhx4M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=3VJYH6gVwlC28jzVO+pyu9PyIr+JY1TLwSS6s26bhg8=; b=VlZ7KJ4ApAJ+DVHbo1MCo3wN41cOunWIHq+g91HhQUm9cN/wbNhPdeSYCsSSXx3hWQ GsvFbpbDY5F57bSOcmCgAwKcNBjiss6xpS89UHEDrV6ab7Ou1r4Y7dVZeCNMlmNEnYOl CoNJq80Q8D3BC4PK+BCHcIFc4DGKk+hvMAI8sfGN5jCPmocfAgCVt8CwvYPmavSiGcZE Fsz56qz/tWo7TnI3xixksbX0cG96ipkqdMIcUk5lP33w5MfCyj3a8MImOjOjJMoKfq4f gVB6onoEdWSFHkttb09wgkQSC0Ti8D728Q9p0h+pcbt7LQpmWzByha7VBS6duCsU/1jv LxqQ==
X-Gm-Message-State: ALoCoQlZcC5sI6hVVtx7pOVH10KLlKN3OB1EMnY4a+e9KHQjMpOdbKH74Q4ywQE3I1kKAmYDn8M0
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr302019qam.92.1379617635611; Thu, 19 Sep 2013 12:07:15 -0700 (PDT)
Sender: alfredo@pironti.eu
Received: by 10.49.108.103 with HTTP; Thu, 19 Sep 2013 12:07:15 -0700 (PDT)
X-Originating-IP: [82.224.193.99]
In-Reply-To: <582A57A2-C452-463D-8B79-6CF6E3804732@checkpoint.com>
References:  <523B2EDF.7010501@pobox.com>  <582A57A2-C452-463D-8B79-6CF6E3804732@checkpoint.com>
Date: Thu, 19 Sep 2013 21:07:15 +0200
X-Google-Sender-Auth: huzr4xZq6DuNUdsrply1VtnhTR4
Message-ID: 
From: Alfredo Pironti 
To: Yoav Nir 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [TLS] Resuming a session as part of a renegotiation.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 19:07:33 -0000

I'd say that, over an existing connection, you'd mostly run an
abbreviated handshake resuming the current session to refresh keys.
You could also use it to reset sequence numbers, in case they're soon
going to overflow. I know no implementation doing that; all of them
seem to happily let the sequence number overflow, assuming the
connection will be tear down way sooner this happens (which is
probably true in most scenarios).

According to the spec, you could even run an abbreviated handshake
resuming a different connection form the current one. In a scenario
which I discourage (because it's asking for trouble confusing the
application), you could have a pool of established TLS sessions, each
using a different identity, and "swap" between them with abbreviated
re-handshakes over the same connection. Again, I'd take this as a
non-forbidden behavior, rather than a largely useful one.

On Thu, Sep 19, 2013 at 8:50 PM, Yoav Nir  wrote:
>
> On Sep 19, 2013, at 9:29 PM, Fabrice Gautier  =
wrote:
>>> One possible use case: if you negotiated a block cipher with a
>>> small internal state and are sending large quantities of data,
>>> security might be improved by periodically renegotiating.
>>
>> Thats only benefit a full handshake renegotiation.
>>
>> The way I understand it, renegotiation allows you to have several
>> session in the same connection, and session resumption allows you to
>> have the same session across multiple connections.
>
> Renegotiation just means doing the handshake again. The end result is new=
 keys. So if you believe that 3DES keys should not be used for more than 0.=
5GB of data, just doing a renegotiation gives you fresh keys (because they =
are mixed with the new nonces). If you resume the session, you don't get ne=
w client and/or server identities, you don't get re-authentication, and you=
 don't get a new master key, so someone who has managed to get your old mas=
ter key can figure out both your old and new encryption keys. But if the on=
ly reason you're renegotiating is that you need fresh keys, that's good eno=
ugh.
>
> So renegotiation+resumption gives you the same session, but new keys. Sor=
t of like "phase II" in IKE.
>
> Yoav
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From fabrice.gautier@gmail.com  Thu Sep 19 13:01:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B101F21F866E for ; Thu, 19 Sep 2013 13:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VZAZD8DYgGz for ; Thu, 19 Sep 2013 13:01:56 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id EA8AA21F864D for ; Thu, 19 Sep 2013 13:01:54 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id m15so8673712wgh.9 for ; Thu, 19 Sep 2013 13:01:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=JAPPI3vAfH5czzb0vvcx4dHZqbsnItSjXMasVVlnQfw=; b=ULMkf5DeGesL88d75vdtUUTAakpa5lfeGqvsdOBTrkTGjcjwi1QKSeFhxWqnqM6xgv jfnbNj8jAB5UgOBbYMhVXiLAaQ9ws3yNX0SLl/Z3Lt0l56cHIsvV5Jr1v6AEfT3s1hFl XNM7lv92wZHpM+fre3iUh3D2oNdkziQoMyFO4HKVEioD5kDmjoSyz2j/V12c9wb7AZpH MD3mc9h4KJlroerLJ6iGZBtWaLpNaiT3uCTUUM8og65jwq14eJd9PwmGld2ysXAnugLo XZgx4Xo4UN1ug1iKd7Vdgn9YtVtfH0/VvKqcDY1OgN8mJOvaAj7+B+YT7kGAOmTpbd3A K6PQ==
X-Received: by 10.194.63.228 with SMTP id j4mr2922576wjs.34.1379620914124; Thu, 19 Sep 2013 13:01:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.216.50.12 with HTTP; Thu, 19 Sep 2013 13:01:34 -0700 (PDT)
In-Reply-To: <582A57A2-C452-463D-8B79-6CF6E3804732@checkpoint.com>
References:  <523B2EDF.7010501@pobox.com>  <582A57A2-C452-463D-8B79-6CF6E3804732@checkpoint.com>
From: Fabrice Gautier 
Date: Thu, 19 Sep 2013 13:01:34 -0700
Message-ID: 
To: Yoav Nir 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" 
Subject: Re: [TLS] Resuming a session as part of a renegotiation.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 20:01:56 -0000

On Thu, Sep 19, 2013 at 11:50 AM, Yoav Nir  wrote:
>
> On Sep 19, 2013, at 9:29 PM, Fabrice Gautier  =
wrote:
>>> One possible use case: if you negotiated a block cipher with a
>>> small internal state and are sending large quantities of data,
>>> security might be improved by periodically renegotiating.
>>
>> Thats only benefit a full handshake renegotiation.
>>
>> The way I understand it, renegotiation allows you to have several
>> session in the same connection, and session resumption allows you to
>> have the same session across multiple connections.
>
> Renegotiation just means doing the handshake again. The end result is new=
 keys. So if you believe that 3DES keys should not be used for more than 0.=
5GB of data, just doing a renegotiation gives you fresh keys (because they =
are mixed with the new nonces). If you resume the session, you don't get ne=
w client and/or server identities, you don't get re-authentication, and you=
 don't get a new master key, so someone who has managed to get your old mas=
ter key can figure out both your old and new encryption keys. But if the on=
ly reason you're renegotiating is that you need fresh keys, that's good eno=
ugh.
>
> So renegotiation+resumption gives you the same session, but new keys. Sor=
t of like "phase II" in IKE.

Oh I see... Same master secret but refreshed cipher keys.

Thanks

-- Fabrice

From rob.stradling@comodo.com  Thu Sep 19 14:19:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECE5021F85C9 for ; Thu, 19 Sep 2013 14:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.854
X-Spam-Level: 
X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gte5GGtKBMF for ; Thu, 19 Sep 2013 14:18:58 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7439521F88FB for ; Thu, 19 Sep 2013 14:18:57 -0700 (PDT)
Received: (qmail 13472 invoked from network); 19 Sep 2013 21:18:56 -0000
Received: from ian.brad.office.comodo.net (192.168.0.202) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 19 Sep 2013 21:18:56 -0000
Received: (qmail 7932 invoked by uid 1000); 19 Sep 2013 21:18:56 -0000
Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Thu, 19 Sep 2013 22:18:56 +0100
Message-ID: <523B6A3F.7000003@comodo.com>
Date: Thu, 19 Sep 2013 22:18:55 +0100
From: Rob Stradling 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <20130919095434.D99621A986@ld9781.wdf.sap.corp>  <523B2205.1040103@pobox.com> <523B23C7.4010704@fifthhorseman.net> <523B2DE9.8090403@pobox.com>
In-Reply-To: <523B2DE9.8090403@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage	digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 19 Sep 2013 21:19:04 -0000

On 19/09/13 18:01, Michael D'Errico wrote:
>>> Wan-Teh Chang wrote:
>>>> Note: I don't understand why RFC 4492 says "It MUST be signed with
>>>> RSA."

> Page 47 of RFC 5246 hints at these rules:


RFC 5246 relaxes the "It MUST be signed with RSA" rule, doesn't it?

Appendix A.7 (Changes to RFC 4492) says:
   "As described in Sections 7.4.2 and 7.4.6, the restrictions on the
    signature algorithms used to sign certificates are no longer tied to
    the cipher suite (when used by the server) or the
    ClientCertificateType (when used by the client).  Thus, the
    restrictions on the algorithm used to sign certificates specified in
    Sections 2 and 3 of RFC 4492 are also relaxed."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

From pgut001@cs.auckland.ac.nz  Fri Sep 20 06:29:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D21021F995B for ; Fri, 20 Sep 2013 06:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBNsKBpNUmIv for ; Fri, 20 Sep 2013 06:29:38 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 002B521F9767 for ; Fri, 20 Sep 2013 06:29:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379683778; x=1411219778; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rlackX4M0VS47GrRl4HKRW0Y3tM+Vo0ftulKnEkNl9M=; b=i3t+I93CZAuFbmCuPfGzrlEhlLBRAYkoc05J/jAak737AKMpFgIQP8Sq 2kSKvDvo5EKYkLmQgrvLtbxJyS3G8gL9NdAa03YxYMtDUKVEQ8mYJIB24 jHaCdrm8Afz6eClo54B0yD6u3BEiu4Cgi/ibIgsg+P08YRV1Mgis5RcH/ s=;
X-IronPort-AV: E=Sophos;i="4.90,944,1371038400"; d="scan'208";a="213251377"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Sep 2013 01:29:35 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 21 Sep 2013 01:29:35 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac62BXKJPwFODXUbTnCN6PSCJqCALg==
Date: Fri, 20 Sep 2013 13:29:35 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 13:29:43 -0000

Eric Rescorla  writes:=0A=
=0A=
>Of course, this naturally raises the question of whether this document wil=
l=0A=
>be accepted by the TLS WG.=0A=
=0A=
It seems to be accepted by everyone except the WG chairs, who point to:=0A=
=0A=
>However, as I think recent discussion indicates, there are a number of=0A=
>proposed approaches and there isn't really consensus to adopt this particu=
lar=0A=
>one=0A=
=0A=
Can you provide concrete examples of this lack of consensus?  It's already=
=0A=
present in deployed implementations (as I mentioned a while back, the respo=
nse=0A=
of one SSL library developer was "this should have been done ten years ago"=
).=0A=
So lets reverse this, if the WG chairs think that there are viable alternat=
ive=0A=
approaches could they please point to *currently active RFC drafts* (not an=
=0A=
expired six-month-old text but a current draft) with authors willing to=0A=
actively champion their approaches on the list?=0A=
=0A=
If this isn't possible, can we just go ahead and adopt it?  This is a decad=
e-=0A=
old problem with a fairly trivial fix, and yet the NSA doesn't even need to=
=0A=
resort to BULLRUN-style subversion if the WG chairs are determined to block=
=0A=
its adoption.=0A=
=0A=
Peter.=

From mrex@sap.com  Fri Sep 20 06:38:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A13E21F9A19 for ; Fri, 20 Sep 2013 06:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.91
X-Spam-Level: 
X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=-0.261,  BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw1QEJEnNGza for ; Fri, 20 Sep 2013 06:38:03 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C549721F99FB for ; Fri, 20 Sep 2013 06:37:56 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8KDbsw8002340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Sep 2013 15:37:54 +0200 (MEST)
In-Reply-To: 
To: Wan-Teh Chang 
Date: Fri, 20 Sep 2013 15:37:54 +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: <20130920133754.2AFE51A98B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Sep 2013 13:38:07 -0000

Wan-Teh Chang wrote:
> 
> RFC 4492 says:
> 
>           Key Exchange Algorithm  Server Certificate Type
>           ----------------------  -----------------------
> 
>           ...
> 
>           ECDHE_RSA               Certificate MUST contain an
>                                   RSA public key authorized for
>                                   use in digital signatures.  It
>                                   MUST be signed with RSA.
> 
> Note: I don't understand why RFC 4492 says "It MUST be signed with RSA."


On my scorecard, this is a clear defect of rfc4492.  But it is a defect
that it inherited from a non-obvious statement in TLSv1.0 (rfc2246):

http://tools.ietf.org/html/rfc2246#section-7.4.2

  7.4.2. Server certificate

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
*      method, as follows. Unless otherwise specified, the signing
*      algorithm for the certificate must be the same as the algorithm
       for the certificate key.


This unreasonable restriction is *NOT* present in SSLv3:

http://tools.ietf.org/html/rfc6101#section-5.6.2

5.6.2. Server Certificate


   If the server is to be authenticated (which is generally the case),
   the server sends its certificate immediately following the server
   hello message.  The certificate type must be appropriate for the
   selected cipher suite's key exchange algorithm, and is generally an
   X.509.v3 certificate (or a modified X.509 certificate in the case of
   FORTEZZA(tm) [FOR]).  The same message type will be used for the
   client's response to a certificate request message.


So this artificial limitation is a hidden backwards-incompatible change
in TLSv1.0, that should have never existed in the first place--and
I'm not aware of a TLS implementation which "enforces" this stupidity.


What is particularly strange about this defect is that EVERYONE has
been using RSA certificates for SSL&TLS Servers since 1996, and the
TLSv1.0 spec that was published in 1999 has (due to crypto-political
reasons of that area) mandatates a DHE_DSS cipher suite:

  9. Mandatory Cipher Suites

TLSv1.0  http://tools.ietf.org/html/rfc2246#section-9

  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA


TLSv1.1  http://tools.ietf.org/html/rfc4346#section-9

  TLS_RSA_WITH_3DES_EDE_CBC_SHA


This limitation should be seen as a guidance to CAs to promote interop
rather than a self-imposed crippling of TLS implementations.

-Martin

From mrex@sap.com  Fri Sep 20 06:51:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6CC21F943C for ; Fri, 20 Sep 2013 06:51:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.197
X-Spam-Level: 
X-Spam-Status: No, score=-10.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugjqZCr+zezt for ; Fri, 20 Sep 2013 06:51:17 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 6B40C21F93F8 for ; Fri, 20 Sep 2013 06:51:17 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8KDp4QR003906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Sep 2013 15:51:04 +0200 (MEST)
In-Reply-To: <523B6A3F.7000003@comodo.com>
To: Rob Stradling 
Date: Fri, 20 Sep 2013 15:51:04 +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: <20130920135104.1EE501A98B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 20 Sep 2013 13:51:24 -0000

Rob Stradling wrote:
> On 19/09/13 18:01, Michael D'Errico wrote:
> >>> Wan-Teh Chang wrote:
> >>>> Note: I don't understand why RFC 4492 says "It MUST be signed with
> >>>> RSA."
> 
> > Page 47 of RFC 5246 hints at these rules:
> 
> 
> RFC 5246 relaxes the "It MUST be signed with RSA" rule, doesn't it?
> 
> Appendix A.7 (Changes to RFC 4492) says:
>    "As described in Sections 7.4.2 and 7.4.6, the restrictions on the
>     signature algorithms used to sign certificates are no longer tied to
>     the cipher suite (when used by the server) or the
>     ClientCertificateType (when used by the client).  Thus, the
>     restrictions on the algorithm used to sign certificates specified in
>     Sections 2 and 3 of RFC 4492 are also relaxed."
 

Not really.  Actually, it makes things worse,

because rather than the "hidden" backwards-incompatible self-imposed
limitiation from TLSv1.0, rfc5246 now contains a very explicit limitation
to those algorithms negotiated by the signature algorithms TLS extension,
and stupidly asks TLS implementations to enforce this for the entire
certificate chain up to the root.  In TLSv1.0 this limitiation, for
anyone who actually noticed it, was clearly limited to the signature
algorithm on the EE cert itself, but not signature algorithms of
any intermediate and cross-CA certificates further up the chain.


-Martin


From yaronf.ietf@gmail.com  Fri Sep 20 07:34:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C970421F99D5 for ; Fri, 20 Sep 2013 07:34:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.632
X-Spam-Level: 
X-Spam-Status: No, score=-102.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiYnxeQgavAG for ; Fri, 20 Sep 2013 07:34:35 -0700 (PDT)
Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0612721F968B for ; Fri, 20 Sep 2013 07:34:34 -0700 (PDT)
Received: by mail-wg0-f54.google.com with SMTP id m15so608278wgh.9 for ; Fri, 20 Sep 2013 07:34:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=EFVKp4ir9+mLG1562BN3bK27lZbYW1EC5o9U7uNgx0g=; b=zsW3/0EVOlRnmeIS2i83Sx+UD8u+R5tvXolfhJVGrHV4AvhHtDTF6yNAL/vhil7f8R DowsRJE4G/5yHqP0SROdKu8cwBx7zCwvChbjsAmNQK6kUjcRU5esMfUhIOlEGLP4ihGt D++vFd/1SSFAr6tUyXiqAFc8ePC9oxzOGGT8Q8MbzbyGQ2QJnJCRcmU7jPwP/mFvoz50 qdP/Y//wWLoDxO8bVRkk1arNsPbRKONSignIb/7rvwuT48e4/sXJtLvxe7tcr5dI+OyV ad1gFr518dtYJyNgbFaQTWqUObwRR88jKxOuX9cILxPeSfotYjhCqKPXdHBOO4Y6/lEA WA/Q==
X-Received: by 10.180.9.69 with SMTP id x5mr2998088wia.41.1379687674042; Fri, 20 Sep 2013 07:34:34 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id ey2sm5359188wib.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 07:34:33 -0700 (PDT)
Message-ID: <523C5CF6.2040401@gmail.com>
Date: Fri, 20 Sep 2013 17:34:30 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" 
References: <20130920142728.15100.58320.idtracker@ietfa.amsl.com>
In-Reply-To: <20130920142728.15100.58320.idtracker@ietfa.amsl.com>
X-Forwarded-Message-Id: <20130920142728.15100.58320.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 14:34:35 -0000

Hi,

Ralph Holz and myself just submitted version -01 of the draft, with a 
large number of changes based on the lively discussion on the mailing 
list. Further comments are of course very welcome.

Change log:

    o  Clarified our motivation in the introduction.
    o  Added a section justifying the need for PFS.
    o  Added recommendations for RSA and DH parameter lengths.  Moved
       from DHE to ECDHE, with a discussion on whether/when DHE is
       appropriate.
    o  Recommendation to avoid fallback to SSLv3.
    o  Initial information about browser support - more still needed!
    o  More clarity on compression.
    o  Client can offer stronger cipher suites.
    o  Discussion of the regular TLS mandatory cipher suite.

In addition, we request that the TLS working group adopt this document. 
We believe it can be most effective as a working group document, far 
more than it can ever be as an AD-sponsored RFC.

Thanks,
	Yaron

-------- Original Message --------
Subject: New Version Notification for draft-sheffer-tls-bcp-01.txt
Date: Fri, 20 Sep 2013 07:27:28 -0700
From: internet-drafts@ietf.org
To: Yaron Sheffer , Ralph Holz 


A new version of I-D, draft-sheffer-tls-bcp-01.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Filename:	 draft-sheffer-tls-bcp
Revision:	 01
Title:		 Recommendations for Secure Use of TLS and DTLS
Creation date:	 2013-09-20
Group:		 Individual Submission
Number of pages: 12
URL: 
http://www.ietf.org/internet-drafts/draft-sheffer-tls-bcp-01.txt
Status:          http://datatracker.ietf.org/doc/draft-sheffer-tls-bcp
Htmlized:        http://tools.ietf.org/html/draft-sheffer-tls-bcp-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-bcp-01

Abstract:
    Over the last few years there have been several serious attacks on
    TLS, including attacks on its most commonly used ciphers and modes of
    operation.  This document offers recommendations on securely using
    the TLS and DTLS protocols, given existing standards and
    implementations.

 



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




From ekr@rtfm.com  Fri Sep 20 08:53:53 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7A321F9AE2 for ; Fri, 20 Sep 2013 08:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.559
X-Spam-Level: 
X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7+Cn13cmuGO for ; Fri, 20 Sep 2013 08:53:34 -0700 (PDT)
Received: from mail-qa0-f50.google.com (mail-qa0-f50.google.com [209.85.216.50]) by ietfa.amsl.com (Postfix) with ESMTP id 303EA21F9AFE for ; Fri, 20 Sep 2013 08:53:31 -0700 (PDT)
Received: by mail-qa0-f50.google.com with SMTP id j7so553501qaq.2 for ; Fri, 20 Sep 2013 08:53:30 -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=nYlieQuvtMKrFXsaCS+vLclQAoL99XvNXq525FIGgiE=; b=AaGUnV4YhWdH5ElpsPhVWUMte800pg7OAVD14A49WUBicV+8BK9KCFkpvKPyiR8Ctg Bv5m7vR/R+Cul66wC0Aa+nteJXyY7DAMkHtKk03sRJMmTHriIMjoFLHjPFz0jptuzA/f +COvYqCZqWVQARFQ0ZVvGEH8nnPDAWuebHYGZ22OtQZ27QDCBjybhtEMnURHBQ62Accf khrLeejF0bcF3O5c/Y5MXGkcBHdVjbORcejZ4Ux4Wn8hAnaoSNdPZEMfNFIypLBTpFmr v6bfPBVLtT72S1P+9jo1ymq4wmXwvI6tRya/kwIvJnHYrikKPxD+NbyPSvGl9ek28f56 j3Bw==
X-Gm-Message-State: ALoCoQmayFab9YSwHuAJ4XS+PXJ4oO9OKQ2x8/1aOt1kapiadOq+Pgdj5C+fbeYR7iPYMkaeUMhU
X-Received: by 10.49.3.194 with SMTP id e2mr11711741qee.21.1379692410605; Fri, 20 Sep 2013 08:53:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.42.68 with HTTP; Fri, 20 Sep 2013 08:52:50 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz>
From: Eric Rescorla 
Date: Fri, 20 Sep 2013 08:52:50 -0700
Message-ID: 
To: Peter Gutmann 
Content-Type: multipart/alternative; boundary=047d7bb0473408a2d104e6d2ac3e
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 15:53:53 -0000

--047d7bb0473408a2d104e6d2ac3e
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 20, 2013 at 6:29 AM, Peter Gutmann wrote:

> Eric Rescorla  writes:
>
> >Of course, this naturally raises the question of whether this document
> will
> >be accepted by the TLS WG.
>
> It seems to be accepted by everyone except the WG chairs, who point to:
>
> >However, as I think recent discussion indicates, there are a number of
> >proposed approaches and there isn't really consensus to adopt this
> particular
> >one
>
> Can you provide concrete examples of this lack of consensus?


These messages from Nikos look negative to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09809.html
http://www.ietf.org/mail-archive/web/tls/current/msg09520.html

This looks like "meh" to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09826.html

Privately, I've also heard objections to attempting to prolong the
life of CBC as a primitive. Perhaps those who expressed this
would speak up on the list?


 It's already
> present in deployed implementations (as I mentioned a while back, the
> response
> of one SSL library developer was "this should have been done ten years
> ago").
> So lets reverse this, if the WG chairs think that there are viable
> alternative
> approaches could they please point to *currently active RFC drafts* (not an
> expired six-month-old text but a current draft) with authors willing to
> actively champion their approaches on the list?
>

We have drafts for AEAD w/ CBC:
http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01

And I have heard a variety of suggestions for pushing AEAD down into
TLS 1.2 (there's no technical problem here). If we were to do that, the
draft would presumably be trivial and then we could simply directly
adopt the McGrew draft.

If we were to abandon CBC entirely we would mostly want some
new stream ciphers. E.g.,

http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02

So, certainly if we wanted to to adopt a "triage and selectively replace"
strategy, we have the drafts to do it. In addition, we do have a

Pad then encrypt then MAC draft that is recent.
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01

That is not to say that the WG could not also adopt your draft, but as I
said
above, it's not the only alternative.

We think this would benefit from F2F discussion and I would invite you or
someone else in favor of this draft (or another approach) to present in
November in Vancouver. If there is WG consensus for this, we can adopt
it then.

Best,
-Ekr

P.S. I am about to go mostly offline through Monday night. Apologies in
advance for slow/non-response.

--047d7bb0473408a2d104e6d2ac3e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, Sep 20, 2013 at 6:29 AM, Peter Gutmann &l=
t;pgut001@cs=
.auckland.ac.nz> wrote:



Eric Rescorla <ekr@rtfm=
.com> writes:





>Of course, this naturally raises the question of whether this document =
will

>be accepted by the TLS WG.



It seems to be accepted by everyone except the WG chairs, who point to:



>However, as I think recent discussion indicates, there are a number of<=
br>
>proposed approaches and there isn't really consensus to adopt this =
particular

>one



Can you provide concrete examples of this lack of consensus? 
<=
div>
These messages from Nikos look negative to me:
http://www.ietf.org/mail-archive/web/tls/current/msg09809.html




This looks like "meh" to me:



Privately, I've also heard objections to atte=
mpting to prolong the



life of CBC as a primitive. Perhaps those who expressed this
would speak up on the list?




=A0It's already

present in deployed implementations (as I mentioned a while back, the respo=
nse

of one SSL library developer was "this should have been done ten years=
 ago").

So lets reverse this, if the WG chairs think that there are viable alternat=
ive

approaches could they please point to *currently active RFC drafts* (not an=


expired six-month-old text but a current draft) with authors willing to

actively champion their approaches on the list?

We have drafts for AEAD w/ CBC:

And I have heard a variety of suggestions for pus=
hing AEAD down into
TLS 1.2 (there's no technical problem her=
e). If we were to do that, the
draft would presumably be trivial =
and then we could simply directly



adopt the McGrew draft.

If we were to abandon=
 CBC entirely we would mostly want some
new stream ciphers. E.g.,=


=A0
So, certainly if we wanted to to adopt a "triage =
and selectively replace"



strategy, we have the drafts to do it. In addition, we do have a=A0

Pad then encrypt then MAC draft that is recent.

That is not to say that the WG could not also ado=
pt your draft, but as I said
above, it's not the only alterna=
tive.

We think this would benefit from F2F discuss=
ion and I would invite you or



someone else in favor of this draft (or another approach) to present i=
n
November in Vancouver. If there is WG consensus for this, we ca=
n adopt
it then.

Best,
-Ekr



P.S. I am about to go mostly offline through Monday nig=
ht. Apologies in
advance for slow/non-response.



--047d7bb0473408a2d104e6d2ac3e--

From ekr@rtfm.com  Fri Sep 20 08:53:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B81221F9B6A for ; Fri, 20 Sep 2013 08:53:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.643
X-Spam-Level: 
X-Spam-Status: No, score=-102.643 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPyOT7GrRp5l for ; Fri, 20 Sep 2013 08:53:53 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4877D21F9A99 for ; Fri, 20 Sep 2013 08:53:39 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id k4so552345qaq.18 for ; Fri, 20 Sep 2013 08:53:38 -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=cV3DiUMLsSE4PAmRMWc7Gw4Nrpt94GlPrfVxRr5gkAI=; b=U2NjTcd7qC6IqcbLZ8dRPcAu6/u1ePnh5Ig9woWV8PaBkhmMwH/jd+tPZ93ZgQXpll c5pK0I0jIL+Q2Gbz14wSos15P8CjchFy4kjiqOBz+h+XVDZjF6OgeZBXGy4bJKfC3scE 1/6cMFGwneYNkvUxdTEQROTw3pEIkGBjpbzJnbH2ZtHFOtOTxDPpy3r9timcr4Ornayr zm9K481WcXXQOGGZG4c566HMJxi/iKhjSryyM06Vp8+HeYbwssCJpcoUITgEj9OAj/3N CZvRcJnS0NTgGjsMW6ivkwcGEaFlcGadmdDc6x6GWdeeg7NpKejB0wWn6A3BfuNK9lZG BTHQ==
X-Gm-Message-State: ALoCoQkcA+GmHortHCAfqDK+fRHVixBTGzp1yn49ax661vhLxGKF12pHSo+UQa3jSPzh5a8nMCn+
X-Received: by 10.224.20.132 with SMTP id f4mr6454995qab.42.1379692418766; Fri, 20 Sep 2013 08:53:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.42.68 with HTTP; Fri, 20 Sep 2013 08:52:58 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
From: Eric Rescorla 
Date: Fri, 20 Sep 2013 08:52:58 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11336248852a0b04e6d2acd4
Subject: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 15:53:58 -0000

--001a11336248852a0b04e6d2acd4
Content-Type: text/plain; charset=ISO-8859-1

Peter,

After reviewing this document I have a few comments/questions:

- Because this draft relies on extensions, it seems not to resist
  active attack when clients do insecure version fallback
  (see for instance:
http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
  The existing attacks appear to principally be active attacks on the
browser
  environment, which is where fallback tends to happen.

- Maybe I am misreading the draft, but I'm unclear on how you get
   the TLSCompressed.length for the MAC computation in Section 3.
   Does this have the same issue as was raised for McGrew's CBC AEAD
   draft?

Am I missing something here?

Thanks,
-Ekr

--001a11336248852a0b04e6d2acd4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Peter,

After reviewing this document I =
have a few comments/questions:

- Because this draf=
t relies on extensions, it seems not to resist
=A0 active attack =
when clients do insecure version fallback



=A0 The existing attacks appear to princip=
ally be active attacks on the browser



=A0 environment, which is where fallback tends to happen.
- Maybe I am misreading the draft, but I'm unclear on how =
you get
=A0 =A0the TLSCompressed.length for the MAC computation i=
n Section 3.



=A0 =A0Does this have the same issue as was raised for McGrew's CB=
C AEAD
=A0 =A0draft?

Am I missing someth=
ing here?

Thanks,
-Ekr





--001a11336248852a0b04e6d2acd4--

From ekr@rtfm.com  Fri Sep 20 08:57:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3AC21F9B66 for ; Fri, 20 Sep 2013 08:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.698
X-Spam-Level: 
X-Spam-Status: No, score=-102.698 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WeyNukRpdVkL for ; Fri, 20 Sep 2013 08:57:02 -0700 (PDT)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id C741E21F9A99 for ; Fri, 20 Sep 2013 08:56:52 -0700 (PDT)
Received: by mail-qc0-f178.google.com with SMTP id r5so378230qcx.23 for ; Fri, 20 Sep 2013 08:56:41 -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=o+QD9JChB0Wpy9fXyKv4pN13l7OtpKvhJR0SAMJ/Vws=; b=gOuE8Mw8pL4IpMGc1rpSz3qMPMsCSYrch1U2A30xN6c+gaBg/J9A6iSqU7e/4RrpWF +Ra+GMD3Zp5DAe5Gof/Q9SgQgKzUbZAzGirzsvL7AW0qy1mGTDBV8g55t6Wr3eEB2PLU PWe1FlhAiF0FOdnlCr/2uhoVavze37el5aJSia3lnIKVIVnHS8jQP+lv+k3UU6I5umaL C7CC6y8mDpjCBe6JA96RGDESmjjKjrHCrISYSPNGM2HwjmXXC/G/AF3Ay22BEuGUbBMq t5oud2hSoi1HWhN3Nl2io48tRGgCdyHxwH1ajbSR1NPvxituLgcPDY6QRgwHSjyY/vxZ 130g==
X-Gm-Message-State: ALoCoQl0YDGVGrqSYAUGxX1gJuxv9CPQmPXGSZMyk1vqHxg8XmJ5OEerw5G1q7+/VKFzfYDURWaS
X-Received: by 10.224.20.132 with SMTP id f4mr6472670qab.42.1379692601776; Fri, 20 Sep 2013 08:56:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.42.68 with HTTP; Fri, 20 Sep 2013 08:56:01 -0700 (PDT)
X-Originating-IP: [74.95.2.168]
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz> 
From: Eric Rescorla 
Date: Fri, 20 Sep 2013 08:56:01 -0700
Message-ID: 
To: Peter Gutmann 
Content-Type: multipart/alternative; boundary=001a113362486da0a504e6d2b751
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 15:57:19 -0000

--001a113362486da0a504e6d2b751
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Sep 20, 2013 at 8:52 AM, Eric Rescorla  wrote:

>
>
>
> On Fri, Sep 20, 2013 at 6:29 AM, Peter Gutmann wrote:
>
>> Eric Rescorla  writes:
>>
>> >Of course, this naturally raises the question of whether this document
>> will
>> >be accepted by the TLS WG.
>>
>> It seems to be accepted by everyone except the WG chairs, who point to:
>>
>> >However, as I think recent discussion indicates, there are a number of
>> >proposed approaches and there isn't really consensus to adopt this
>> particular
>> >one
>>
>> Can you provide concrete examples of this lack of consensus?
>
>
> These messages from Nikos look negative to me:
> http://www.ietf.org/mail-archive/web/tls/current/msg09809.html
> http://www.ietf.org/mail-archive/web/tls/current/msg09520.html
>
> This looks like "meh" to me:
> http://www.ietf.org/mail-archive/web/tls/current/msg09826.html
>
> Privately, I've also heard objections to attempting to prolong the
> life of CBC as a primitive. Perhaps those who expressed this
> would speak up on the list?
>
>
>  It's already
>> present in deployed implementations (as I mentioned a while back, the
>> response
>> of one SSL library developer was "this should have been done ten years
>> ago").
>> So lets reverse this, if the WG chairs think that there are viable
>> alternative
>> approaches could they please point to *currently active RFC drafts* (not
>> an
>> expired six-month-old text but a current draft) with authors willing to
>> actively champion their approaches on the list?
>>
>
> We have drafts for AEAD w/ CBC:
> http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2-01
>
> And I have heard a variety of suggestions for pushing AEAD down into
> TLS 1.2 (there's no technical problem here). If we were to do that, the
>

This should say below TLS 1.2.

-Ekr



> draft would presumably be trivial and then we could simply directly
> adopt the McGrew draft.
>
> If we were to abandon CBC entirely we would mostly want some
> new stream ciphers. E.g.,
>
> http://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-01
> http://tools.ietf.org/html/draft-josefsson-salsa20-tls-02
>
> So, certainly if we wanted to to adopt a "triage and selectively replace"
> strategy, we have the drafts to do it. In addition, we do have a
>
> Pad then encrypt then MAC draft that is recent.
> http://tools.ietf.org/html/draft-pironti-tls-length-hiding-01
>
> That is not to say that the WG could not also adopt your draft, but as I
> said
> above, it's not the only alternative.
>
> We think this would benefit from F2F discussion and I would invite you or
> someone else in favor of this draft (or another approach) to present in
> November in Vancouver. If there is WG consensus for this, we can adopt
> it then.
>
> Best,
> -Ekr
>
> P.S. I am about to go mostly offline through Monday night. Apologies in
> advance for slow/non-response.
>
>

--001a113362486da0a504e6d2b751
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable





On Fri, Sep 20, 2013 at 8:52 AM, Eric Rescorla &l=
t;ekr@rtfm.com> wrote:






On Fri, Sep 20, 20=
13 at 6:29 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:




Eric Rescorla <ekr@rtfm.com> writes:






>Of course, this naturally raises the question of whether this document =
will

>be accepted by the TLS WG.



It seems to be accepted by everyone except the WG chairs, who point to:



>However, as I think recent discussion indicates, there are a number of<=
br>
>proposed approaches and there isn't really consensus to adopt this =
particular

>one



Can you provide concrete examples of this lack of consensus? 
<=
div>
These messages from Nikos look negative to me:

This looks like "meh=
" to me:





Privately, I've also heard =
objections to attempting to prolong the




life of CBC as a primitive. Perhaps those who expressed this
would speak up on the list?




=A0It's already

present in deployed implementations (as I mentioned a while back, the respo=
nse

of one SSL library developer was "this should have been done ten years=
 ago").

So lets reverse this, if the WG chairs think that there are viable alternat=
ive

approaches could they please point to *currently active RFC drafts* (not an=


expired six-month-old text but a current draft) with authors willing to

actively champion their approaches on the list?

We have drafts for AEAD w/ CBC:

And I have heard a variety of suggestions for pus=
hing AEAD down into
TLS 1.2 (there's no technical problem her=
e). If we were to do that, the



This should say below TLS 1.2.

-Ekr=


=A0



draft would pres=
umably be trivial and then we could simply directly


adopt the McGrew draft.

If we were to abandon=
 CBC entirely we would mostly want some
new stream ciphers. E.g.,=


=A0
So, certainly if we wanted to to ado=
pt a "triage and selectively replace"




strategy, we have the drafts to do it. In addition, we do have a=A0

Pad then encrypt then MAC draft that is recent.

That is not to say that the WG could not also ado=
pt your draft, but as I said
above, it's not the only alterna=
tive.

We think this would benefit from F2F discuss=
ion and I would invite you or




someone else in favor of this draft (or another approach) to present i=
n
November in Vancouver. If there is WG consensus for this, we ca=
n adopt
it then.

Best,
-Ekr




P.S. I am about to go mostly offline through Monday nig=
ht. Apologies in
advance for slow/non-response.






--001a113362486da0a504e6d2b751--

From karl@petzent.com  Wed Sep 18 16:07:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC9BE11E82EB for ; Wed, 18 Sep 2013 16:07:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.775
X-Spam-Level: 
X-Spam-Status: No, score=0.775 tagged_above=-999 required=5 tests=[AWL=0.856,  BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888,  HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmrekyDQjLYa for ; Wed, 18 Sep 2013 16:07:13 -0700 (PDT)
Received: from mail.petzent.com (50-201-233-2-static.hfc.comcastbusiness.net [50.201.233.2]) by ietfa.amsl.com (Postfix) with ESMTP id DB26611E82E9 for ; Wed, 18 Sep 2013 16:07:13 -0700 (PDT)
Received: from MAIL2010.petzent.com (89.0.1.75) by mail.petzent.com (64.162.14.5) with Microsoft SMTP Server (TLS) id 14.0.722.0; Wed, 18 Sep 2013 16:07:23 -0700
Received: from MAIL2010.petzent.com ([89.0.1.75]) by mail2010 ([89.0.1.75]) with mapi id 14.03.0123.003; Wed, 18 Sep 2013 16:07:23 -0700
From: Karl Malbrain 
To: "tls@ietf.org" 
Thread-Topic: Working Draft on getting TLS strong authentication deployed
Thread-Index: Ac60w9HsdX9wYYfJRYaQSfnCjjWq7g==
Date: Wed, 18 Sep 2013 23:07:22 +0000
Message-ID: <65EEC6E375AA474A847D510D5B7E837480F59929@mail2010>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [89.0.1.162]
Content-Type: multipart/alternative; boundary="_000_65EEC6E375AA474A847D510D5B7E837480F59929mail2010_"
MIME-Version: 1.0
X-Mailman-Approved-At: Fri, 20 Sep 2013 09:03:57 -0700
Subject: [TLS] Working Draft on getting TLS strong authentication deployed
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 18 Sep 2013 23:07:19 -0000

--_000_65EEC6E375AA474A847D510D5B7E837480F59929mail2010_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am working off of an Internet Draft for perpass on defeating MITM, https:=
//datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication, to doc=
ument and analyze where we're at in relation to widespread deployment of TL=
S strong authentication.

I would appreciate any additional facts/analysis/opinions that members of t=
he TLS working group can add to this effort.

Thanks,
Karl Malbrain

--_000_65EEC6E375AA474A847D510D5B7E837480F59929mail2010_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I am working off of an Internet Draft for perpass on=
 defeating MITM,

https://datatracker.ietf.org/doc/draft-malbrain-tls-strong-authentication, to document and analyze where we’re at in relation to widespread =
deployment of TLS strong authentication. 



 


I would appreciate any additional facts/analysis/opi=
nions that members of the TLS working group can add to this effort.


 


Thanks,


Karl Malbrain






--_000_65EEC6E375AA474A847D510D5B7E837480F59929mail2010_--

From agl@google.com  Fri Sep 20 09:27:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ACD21F9CAF for ; Fri, 20 Sep 2013 09:27:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.777
X-Spam-Level: 
X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.201,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10x3O8Zv39e9 for ; Fri, 20 Sep 2013 09:27:44 -0700 (PDT)
Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 5228121F9CC7 for ; Fri, 20 Sep 2013 09:27:44 -0700 (PDT)
Received: by mail-ob0-f176.google.com with SMTP id uy5so822581obc.21 for ; Fri, 20 Sep 2013 09:27:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+0WGKNN54LT5XXuFq8tcaquRgfi2Xt8O3MjG7KwRBpc=; b=FNaE5MWsYVGVQ7Y8vMAHCDt6UyQVzRDLTJ5V365G2Sn0yv9OIqGmCa3xs6djilK19v R2Q3U5CcGLQg8e5UCJA5xSkVBeHw8t7lxan0EZS2c9r+1NJ8X9lLvLiu3JaW+5BUlNWH hMmukhAREz2pGgwBPKpeYh8KhvGdRSHzfq0wWfzBQdnQA61GscWd57QjeG10WzsK0y2J OVzQkkdjCP2YNp+gyhkTutz9UqLfY+HlJB962PsjIhlfgpEN3BLZ5V1bMSi0XhDs4HyB avjMnAw+gn6EoyhCG1m4prPX55LdGBMe9nVzhuxGe59zYzXj9hchXcO0UB4c2V9MzUTD DTvQ==
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=+0WGKNN54LT5XXuFq8tcaquRgfi2Xt8O3MjG7KwRBpc=; b=iK+r4QGhCigXR6HlF1htQLdrRiSAkpQB1Dnb/J5uuiNwyqqAibhMB6L9/6tPjhgCRo Rt8Ea/NyIMasx1rScS/d7gywgw9kyWBzpMs65sU/hwRWV7AsCYDOxgXF0NndroJ5tmBk li0EYTE3JhXRQ8aaqgPcEQmS9vnmftrZbJ/mTs8U7J+odkT1i7Cz8/ud9OK/Nm8fom4U FBdFAdwNSUJrH8Kdqjj0bdwqpw7iR7radnHfDdSldEW/hSshludiNgyu8S58JREMwtzp UD/YHX1BfVYpF8dPegfMfH9FqG7P7QclrfOK9pY4nipBiDdLbttsjJOSfAlmrZvyKB6E aaRA==
X-Gm-Message-State: ALoCoQm8NoGveqZ46+dU/lJ644XmUUrCHGBTb4/KrMEMwITZOLX6otTfCDUfPWsFyXgA4BuhMuHctKBDWGq2CbqSVadLoYZ+1DIW+cf927wGxc2Z5xsy/wQf9Hd+/lYsmn0puUxdoBEd3H0W1RyFZ0LD8ZlZi0Nlye8VE57takRm9QF0iwi1+iRf51+qjcrQcniLLaMyB/BR
X-Received: by 10.60.62.4 with SMTP id u4mr6610538oer.35.1379694463825; Fri, 20 Sep 2013 09:27:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.79.105 with HTTP; Fri, 20 Sep 2013 09:27:22 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C7355674A34@uxcn10-6.UoA.auckland.ac.nz> 
From: Adam Langley 
Date: Fri, 20 Sep 2013 12:27:22 -0400
Message-ID: 
To: Eric Rescorla 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 16:27:45 -0000

On Fri, Sep 20, 2013 at 11:52 AM, Eric Rescorla  wrote:
> This looks like "meh" to me:
> http://www.ietf.org/mail-archive/web/tls/current/msg09826.html

I think that "meh" is probably a reasonable summary of my post, yes.

If we accept that making any change costs about the same, because the
cost overwhelmingly consists of the amount of time that we have to
wait for deployment, then I'd very much like a better change than
warming up CBC's corpse again.

There is one case where this might not be the case however: an Acme
TLS stack that is basically unmaintained but might be able to hack in
an extension like this. Although I can certainly believe that
something like that exists, nothing is coming to mind but I find cases
of ten year old copies of OpenSSL pretty often.

So I've no objection to this ID, but nor am I esp excited by it.


Cheers

AGL

From hughejp@mac.com  Fri Sep 20 23:57:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DA211E810D for ; Fri, 20 Sep 2013 23:57:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.248
X-Spam-Level: 
X-Spam-Status: No, score=-0.248 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BsYAYqmG4bR for ; Fri, 20 Sep 2013 23:57:47 -0700 (PDT)
Received: from st11p06mm-asmtp001.mac.com (st11p06mm-asmtpout004.mac.com [17.172.124.249]) by ietfa.amsl.com (Postfix) with ESMTP id B0D5D11E8115 for ; Fri, 20 Sep 2013 23:57:44 -0700 (PDT)
Received: from [10.0.1.9] (209-82-80-116.dedicated.allstream.net [209.82.80.116]) by st11p06mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTG00LJMRC40C00@st11p06mm-asmtp001.mac.com> for tls@ietf.org; Sat, 21 Sep 2013 06:57:42 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-21_01:2013-09-20, 2013-09-21, 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-1308280000 definitions=main-1309200188
Content-type: text/plain; charset=us-ascii
MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: james hughes 
In-reply-to: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>
Date: Fri, 20 Sep 2013 23:57:39 -0700
Content-transfer-encoding: quoted-printable
Message-id: 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann 
X-Mailer: Apple Mail (2.1510)
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 06:57:52 -0000

On Sep 19, 2013, at 2:56 AM, Peter Gutmann  =
wrote:

> "Blumenthal, Uri - 0558 - MITLL"  writes:
>=20
>> I personally think that for *ephemeral* DH even 1024 bits still is =
enough.
>> And would *much* prefer having PFS now with individual session keys =
at
>> somewhat greater risk, over a system that is very secure and =
completely
>> useless because nobody bothered to deploy it.
>=20
> Exactly.  We don't need theoretically perfect security in ten years =
when we've
> finished arguing about it and have upgraded every system on the planet =
to
> support it, we just need good enough right now.  That's DH-1024, and =
when we
> have that turned on everywhere we've got some breathing space to worry =
about
> what to do next.


"theoretically perfect security in ten years", really? You think that =
1024 is "good enough"? I do not know a single reputable source that says =
1024 bit is "secure" (outside the people on this list). Not even NIST. =
If you are going to step forward for PFS, do it right. Raise the D-H key =
size to 2048. 2048 bit is required now and will give you security for =
only 7 years (Thank you France).=20

What is wrong with having a a reasonable amount padding between what is =
known to be vulnerable and what is known to be secure, especially when =
the cost is an extra 2 milliseconds of CPU?


It seems like the members of this list are saying 1024 is enough. Why? =
What is their science? Where is their proof? Repeatedly saying "We don't =
need theoretically perfect security" is a proof by assertion =
[http://en.wikipedia.org/wiki/Proof_by_assertion]. The French equivelant =
of NSA (number 2 in the world?) is quite capable and this is their =
recommendation is 2048 NOW. Clearly, the TLS standards community must be =
smarter to say so unequivocally that 1024 is "enough".

This sounds a lot like the same arguments that were given to the =
cryptographers arguing against using MD5 by certificate authorities =
after a collision was found.

Why does the burden of proof seem to be so high on the cryptographers to =
prove that an algorithm (or key size) is not secure enough? Stated =
differently, why must crypto community, who knows something is, or will =
soon be, breakable have to shame the standards bodies into reasonable =
action with a pie in the face  [for the non-english speakers, for a =
definition of "pie in the face" see =
http://en.wikipedia.org/wiki/Pieing]?

Maybe the assumption is that the Cryptanalysists are lunatics and we are =
better off ignoring them. I get that, but Is this the best thing for the =
internet?


Why not a 2048 Diffie Hellman exchange? Why not even allow it to be an =
option?=

From pgut001@cs.auckland.ac.nz  Sat Sep 21 01:42:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B1F21F9F31 for ; Sat, 21 Sep 2013 01:42:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NNG+E1+5Hyp for ; Sat, 21 Sep 2013 01:42:15 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B4A1921F9F23 for ; Sat, 21 Sep 2013 01:42:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379752935; x=1411288935; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=NOzA+a3hW/N1WP3Qfl8ki9PEVpCAQqmcOapUb5mjfXo=; b=UcAl8AOVMhCQM5XXR4FX4B2mQUhP7331WLjRjOmkRIAgQwgQkUzJTbAw kvQLziJPFV7NHJg3c508jJH8jNol0APintNMoHiJKsobP20Ft7GVG+RKN W5npTE1LBVR/Xw6wWo35Hap+UvAcT9Gf5VIf/pody6uQUIjxKFWmKHGPa s=;
X-IronPort-AV: E=Sophos;i="4.90,951,1371038400"; d="scan'208";a="213315268"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 21 Sep 2013 20:42:11 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Sat, 21 Sep 2013 20:42:10 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac62pnXrb7/i0DxYQ4+uyNbGLzUQnQ==
Date: Sat, 21 Sep 2013 08:42:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 08:42:20 -0000

Yaron Sheffer  writes:=0A=
=0A=
>I think we've been through all these arguments (on both sides of the issue=
)=0A=
>over the last week, with the exception of "ECC brittleness". Can you pleas=
e=0A=
>clarify what you mean by that?=0A=
=0A=
So with RSA-authenticated DH all you need to do is use a constant-time mode=
xp=0A=
on the server when you sign and pre-encode the PKCS #1 expected result and =
use=0A=
a constant-time memcmp() on the client when you verify and you're OK.  If y=
ou=0A=
did that ten years ago then you're safe against pretty much everything that=
's=0A=
come along since then.=0A=
=0A=
With ECDLP-based algorithms in contrast there's a whole range of issues you=
=0A=
need to take into account, the worst of which is the distressing propensity=
 of=0A=
the DLP algorithms to leak the private key if you get even the tiniest deta=
il=0A=
wrong.  Not only do you have to get all of these finicky details exactly=0A=
right, but every now and then someone points out a new issue that you then=
=0A=
need to retroactively patch into your existing code base.  For example if y=
ou=0A=
used the recommended (until not too long ago) way to generate your k for =
=0A=
(EC)DSA then you'd leak a tiny bit of your private key on each signature=0A=
(again, that nasty propensity of DLP algorithms to leak the private key).=
=0A=
That's what I meant by ECC, and DLP in general, brittleness.=0A=
=0A=
Peter.=

From michael@stroeder.com  Sat Sep 21 06:37:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD0C11E81C5 for ; Sat, 21 Sep 2013 06:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.560,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hZUpw6z3z9x for ; Sat, 21 Sep 2013 06:37:29 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id D4FEB11E81C3 for ; Sat, 21 Sep 2013 06:37:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 64712602E9; Sat, 21 Sep 2013 15:37:26 +0200 (CEST)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJCKGGbMc48F; Sat, 21 Sep 2013 15:37:20 +0200 (CEST)
Received: from nb2.stroeder.local (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id B94D0602DC; Sat, 21 Sep 2013 13:37:19 +0000 (UTC)
Message-ID: <523DA10F.7010308@stroeder.com>
Date: Sat, 21 Sep 2013 15:37:19 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20
MIME-Version: 1.0
To: james hughes 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030302050703090805030003"
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 13:37:34 -0000

This is a cryptographically signed message in MIME format.

--------------ms030302050703090805030003
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

james hughes wrote:
>=20
> On Sep 19, 2013, at 2:56 AM, Peter Gutmann  =
wrote:
>=20
>> "Blumenthal, Uri - 0558 - MITLL"  writes:
>>
>>> I personally think that for *ephemeral* DH even 1024 bits still is en=
ough.
>>> And would *much* prefer having PFS now with individual session keys a=
t
>>> somewhat greater risk, over a system that is very secure and complete=
ly
>>> useless because nobody bothered to deploy it.
>>
>> Exactly.  We don't need theoretically perfect security in ten years wh=
en we've
>> finished arguing about it and have upgraded every system on the planet=
 to
>> support it, we just need good enough right now.  That's DH-1024, and w=
hen we
>> have that turned on everywhere we've got some breathing space to worry=
 about
>> what to do next.
>=20
>=20
> "theoretically perfect security in ten years", really? You think that 1=
024
> is "good enough"? I do not know a single reputable source that says 102=
4
> bit is "secure" (outside the people on this list). Not even NIST. If yo=
u
> are going to step forward for PFS, do it right. Raise the D-H key size =
to
> 2048. 2048 bit is required now and will give you security for only 7 ye=
ars
> (Thank you France).

I personally would prefer D-H key size 2048 bit everywhere and I don't wo=
rry
about performance. (Did you ever notice that most SSL/TLS connections are=

going to ad servers?)

But the problem in the context of draft-sheffer-tls-bcp is that existing
implementations do not support D-H key size of 2048 bits. And the author(=
s) of
this draft take this fact to rule out DH completely and recommend EC-base=
d
cipher suites. IMHO ECs seem to be a can of worms. I don't trust those
complicated cipher suites.

Ciao, Michael.


--------------ms030302050703090805030003
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC
BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w
HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu
ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw
MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj
MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA
A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd
NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV
hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/
0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ
NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH
AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91
ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj
ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC
BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG
CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0
dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8
q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b
zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP
yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB
OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF
pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb
4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn
BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP
MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK
d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl
2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93
d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G
CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ
KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTIxMTMzNzE5WjAj
BgkqhkiG9w0BCQQxFgQU2m2Mx1NSIiuJ3c+K/ejbIbVM2dowbAYJKoZIhvcNAQkPMV8wXTAL
BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN
BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD
MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y
ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS
c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV
BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ
Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl
cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAqtU0Pw+5bg7mgWGb/f7Cj++IARZSJ6IQ
v2HK6LN25c8yYR5v0HJKShuYNJI7+7AmX+3r9gnHr+6OYa3hyFLQ3iRT3LqwwY9cXkLxrBGM
R20LhXfMZufEKn4mqsdsnIObPQVtq0cIlCdmE4Hy8/GWV2BpyULHHBQzKw8eb2WU2RGItGFw
QUL6BqUT6qqFjvwjgCjVSqNZlhGbwE2eXjwlJv+3NIEFl9avDBoWRfG958aGFIibRxERI2UV
ld2pTVFza5LpRK1aJ03VVUWLwJ1z5nrf8shrhp3fv5FwnzKhpQOOwz3gKIh7pEfLy9/kIcjA
+M32S3z5kNiAw0BeWLcaWQAAAAAAAA==
--------------ms030302050703090805030003--

From mike-list@pobox.com  Sat Sep 21 09:42:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6FB11E8132 for ; Sat, 21 Sep 2013 09:42:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBCx4J6Ycqtq for ; Sat, 21 Sep 2013 09:42:11 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id B6F8B21F9C53 for ; Sat, 21 Sep 2013 09:42:10 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5F51ED37F; Sat, 21 Sep 2013 12:42:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=n8nHUsUHt7Kg q7wmrRe82NpgOh8=; b=I1l17e85ZKh7joDFNqaJ/gBP5Ll0x3dHpyqb42uH4yxN AV7aaxZyIA8F1gkuGnkQE7TYFYt1tp6zbEmoM/y6oGAqqPg4mgDbvHhXC380RuqY r7dPpIJzMoMxRGHAkXAwImH1JMv93CNoXB42/CIPYhdDvNzQq01qj2jdg7ZR+o8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=DAN89x Bnphq5b4YTxMS4XxV8SctG4E7OLdl3dTa07i0OemNMNN1von1uc4+T2ypexcHg+O fbhTvhSk9pcsTb7uZRXMQhjnuqhrm3LIRU6v6IQ9l8r8gWuVIjIXzkM9j9iXuJUF 1zGFQ0HZxB9EyKLXCn/27pb/AC45C1AFq4ffY=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4FC27D375; Sat, 21 Sep 2013 12:42:08 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 66A02D373; Sat, 21 Sep 2013 12:42:07 -0400 (EDT)
Message-ID: <523DCC5D.9040707@pobox.com>
Date: Sat, 21 Sep 2013 09:42:05 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: james hughes 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: C0F71E68-22DC-11E3-AD32-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 16:42:16 -0000

James,

The problem is that there apparently is lots of TLS code which can only handle
1024-bit DH parameters and would break if a server sent larger parameters.

The idea that 1024 is big enough stems from the fact that many many connections
don't use DH at all, and would benefit if RSA was replaced by EDH.  Thus an
attacker would need to break 1024-bit DH for each connection of interest.

Remember that this is an Engineering group (the "E" in IETF) which has to keep
the Internet working while we attempt to improve security for everyone.  If we
knew how to move to 2048 bits without breaking anything we would.

Mike



james hughes wrote:
> On Sep 19, 2013, at 2:56 AM, Peter Gutmann  wrote:
> 
>> "Blumenthal, Uri - 0558 - MITLL"  writes:
>>
>>> I personally think that for *ephemeral* DH even 1024 bits still is enough.
>>> And would *much* prefer having PFS now with individual session keys at
>>> somewhat greater risk, over a system that is very secure and completely
>>> useless because nobody bothered to deploy it.
>> Exactly.  We don't need theoretically perfect security in ten years when we've
>> finished arguing about it and have upgraded every system on the planet to
>> support it, we just need good enough right now.  That's DH-1024, and when we
>> have that turned on everywhere we've got some breathing space to worry about
>> what to do next.
> 
> 
> "theoretically perfect security in ten years", really? You think that 1024 is "good enough"? I do not know a single reputable source that says 1024 bit is "secure" (outside the people on this list). Not even NIST. If you are going to step forward for PFS, do it right. Raise the D-H key size to 2048. 2048 bit is required now and will give you security for only 7 years (Thank you France). 
> 
> What is wrong with having a a reasonable amount padding between what is known to be vulnerable and what is known to be secure, especially when the cost is an extra 2 milliseconds of CPU?
> 
> 
> It seems like the members of this list are saying 1024 is enough. Why? What is their science? Where is their proof? Repeatedly saying "We don't need theoretically perfect security" is a proof by assertion [http://en.wikipedia.org/wiki/Proof_by_assertion]. The French equivelant of NSA (number 2 in the world?) is quite capable and this is their recommendation is 2048 NOW. Clearly, the TLS standards community must be smarter to say so unequivocally that 1024 is "enough".
> 
> This sounds a lot like the same arguments that were given to the cryptographers arguing against using MD5 by certificate authorities after a collision was found.
> 
> Why does the burden of proof seem to be so high on the cryptographers to prove that an algorithm (or key size) is not secure enough? Stated differently, why must crypto community, who knows something is, or will soon be, breakable have to shame the standards bodies into reasonable action with a pie in the face  [for the non-english speakers, for a definition of "pie in the face" see http://en.wikipedia.org/wiki/Pieing]?
> 
> Maybe the assumption is that the Cryptanalysists are lunatics and we are better off ignoring them. I get that, but Is this the best thing for the internet?
> 
> 
> Why not a 2048 Diffie Hellman exchange? Why not even allow it to be an option?

From msj@nthpermutation.com  Sat Sep 21 11:50:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A4A21F9CAD for ; Sat, 21 Sep 2013 11:50:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5Lfa6cOS8cu for ; Sat, 21 Sep 2013 11:49:55 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4152E21F9CA5 for ; Sat, 21 Sep 2013 11:49:55 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id x12so1066412qcv.22 for ; Sat, 21 Sep 2013 11:49:53 -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=PanvOF8/rlCcrDRYlWKX9uhKzHSeLCoKy4q0X8+A3dM=; b=NvXpe7+KHeAAG6A1kP7hsVhMOjAKhWSw2u5GK+sP2IZY9wWCsLU7/bvEBQ34OboH3H S2IH6vO949E5p5rye7QpltqMNLjqcaHCMC8nIq+pxbQUAxRDwjFwp9QhtqPBKYpishQL mNnpUSJSWOf8ZjxTTaF45iBH0zbUXnSYq1TVm/N9KeRDaov3j3j3huKV6djY20b32cyz Q5u46rUnFeZnM+a0yEhSGCz8lXdrBI9yX6ye4ackWPYrWG4z1l1kWbWcy5rUUHYZZvGO r0iMwnFVyvzrByu7seVr/yNCzSAnx8pMIQ1iLcvtTJMsC/WcF2ARWotrivr3MHBOq86o 0hNg==
X-Gm-Message-State: ALoCoQndQOs+Z3y/sDllmQaxw5xCp6/zDhAQ4ZwU+OX14wwmu4b0QKjep2K80b8hKbHcUiPlhdOV
X-Received: by 10.229.229.70 with SMTP id jh6mr19746363qcb.12.1379789393625; Sat, 21 Sep 2013 11:49:53 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id d3sm29542468qad.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 11:49:53 -0700 (PDT)
Message-ID: <523DEA51.9050701@nthpermutation.com>
Date: Sat, 21 Sep 2013 14:49:53 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos 
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 18:50:01 -0000

I'm going to top post - this is a general response to three messages 
with the gist "why do you want to protect the session keys inside the HSM"?

The threat model I'm trying to protect against is an authorized user of 
the HSM (hardware security module) keys who is none the less illegitimate:

  o someone who stole the PIN or credential to access the HSM
  o a hacked program that is doing everything the original program was 
designed to do, but is also extracting and relaying data to a third party.

In both of these cases, assume that the design of the TLS protocol (or 
the HSM module) is such that the session keys can be extracted (either 
by design, or as a side effect of things like how the key expansion 
stage was defined).

Assume that an attacker can extract the session keys and send them to a 
third party.

Assume that the sending of a few key blobs (containing the extracted 
session keys) is less detectable than sending the entire stream of a TLS 
connection.

Assume that the third party can capture the TLS  packet stream at some 
point between the originator and destination.

Given these assumptions: an attacker can use the combination of key 
extraction and packet interception to do virtually undetectable 
interception of the decrypted stream.  Worse, it may be able to change 
the bits actually received in an undetectable manner.

Continuing on this - a smart attacker can decouple the key capture in 
time from the delivery of the key to an attacker.  E.g. batches up the 
capture of 50-100 key states and sends it to the third party maybe once 
a day.  Or publishes it as a steno on on the web server that was hacked. 
or... you get the idea.   As long as the attacker has a copy of the 
encrypted stream of data, he can do the decryption any time after he 
retrieves the key.


I'm of the opinion that it makes sense to make things harder on an 
attacker, and that means doing virtually all of the cryptographic 
operations within a cryptographic boundary.     There are times where 
this is neither necessary nor desirable, but for TLS, I would say that 
this should apply to most communications where there is real-world value 
involved, especially at the server side.

With respect to the specific TLS protocols and my suggestions about the 
key expansion stages, I'm hoping to get it to the point where the 
trivial key extraction attacks enabled by the current key expansion 
mechanism no longer exist.

Mike



On 9/17/2013 1:05 PM, Nikos Mavrogiannopoulos wrote:
> On Tue, Sep 17, 2013 at 5:45 PM, Michael StJohns  wrote:
>
>>> The master secret of a session is never a secret that is hidding
>>> within the hardware module, instead, it is something known to the
>>> calling TLS protocol stack and part of the TLS session cache.
>> Um.  No, not if you designed things properly.  It should be possible for any
>> protocol the IETF designs to do all the crypto operation inside a hardware
>> module and not depend on the weak security of a general purpose computer.
> What you care is protection of the long term keys by the security
> module. Are you really sure you want to protect the temporal session
> keys (i.e. TLS master key) as well? What do you gain if you do that?
> If you want to protect the key from a software vulnerability that
> gives access to the system to an adversary, then you have succeeded
> your goal to protect the key but failed on the goal to protect the
> data the key is encrypting/decrypting. Thus making the effort to
> protect the session key pretty futile, as it is as important as the
> data it protects.
>
>> I want to protect inside of the HSM all of the following:
>> a) the private keys related to the server or client identity
> This makes sense because a private key is used more than one sessions
> and can be used to attack future (and in some cases past sessions).
>
>> b) the pre-master key
>> c) the master key
>> d) the session keys.
> All of these are session-specific keys and protect the data that are
> exchanged in that particular session. IMO there is no much sense
> trying to isolate them from the software handling the data.
>
> regards,
> Nikos
>
>


From msj@nthpermutation.com  Sat Sep 21 12:09:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F71011E8180 for ; Sat, 21 Sep 2013 12:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jU+eYgu8QHbw for ; Sat, 21 Sep 2013 12:09:31 -0700 (PDT)
Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4F29E21F9B10 for ; Sat, 21 Sep 2013 12:09:11 -0700 (PDT)
Received: by mail-qc0-f173.google.com with SMTP id c3so1079857qcv.18 for ; Sat, 21 Sep 2013 12:09:10 -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=mPVXnhLh+lID9l5iLN6CEAgGgy/57co8PviWH9wamZg=; b=nGVRZTgmM+JSCP2lAbTb6uVV+xKOOoBgTURs04pFZID/bCK9M+GlhlaQDiJm7f0mQB II0rZOzyXNHDt/8ouFTMzdOlwHVIUYJF088Da3wK+JEIwjaY0VeowxeWdR3zVp4c+dYa 3usov03XYwpmTxXTNL4BNHfNr86KkoJQsgQaCYij5xPXW9hZfiKdpdpcwnbmI9D6V/Qp g1j67vH18s92TeC20eVQpV8Na2DTaDIu/l1WDQ12GYAcFixoUbnpH6rwKIn7ciIXH6MQ liow3Qt17kDQbzuiX/eJh2Q7pnOPO9QF4MQlJ2jVZ2loOj5w06292dcIyvIlbSjhs79V z01w==
X-Gm-Message-State: ALoCoQmhJ4wdKR/zsF//qFwOGWZWaOImEHYFDipDNK/dwTLN+jO+DB8Du7jBKgnlvnHp6qBYttwO
X-Received: by 10.49.42.101 with SMTP id n5mr12080365qel.31.1379790550793; Sat, 21 Sep 2013 12:09:10 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id d3sm29688457qad.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 12:09:10 -0700 (PDT)
Message-ID: <523DEED6.1060501@nthpermutation.com>
Date: Sat, 21 Sep 2013 15:09:10 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Juraj Somorovsky 
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de> <52379643.7070705@nthpermutation.com> <523AAA0E.2020105@rub.de>
In-Reply-To: <523AAA0E.2020105@rub.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 19:09:37 -0000

On 9/19/2013 3:38 AM, Juraj Somorovsky wrote:
> Let me please extend your scenario:
> o Consider  an application that needs to produce 2 128 bit AES keys.
> o Consider that an attacker (or a hacked program that's being used to
> extract keys) re-runs the derivation using the same master key and same
> random data, this time specifying 64 bits of DES keys.
> o Consider that the attacker can "break" DES (can get key from
> plaintext-ciphertext pairs), but cannot break AES.
>
> The part of the key stream previously used for AES is now assigned to
> the DES keys. If the PKCS11 module now produces some
> plaintext-ciphertext pairs, the attacker can break DES and thus gets
> part of the key stream previously assigned to AES.
>
> I admit I am not that familiar with PKCS11 modules used in
> TLS...However, would this be a valid scenario?

Yes and yes.

Yes - PKCS11 doesn't actually get any information on the specific TLS 
suite, so it doesn't know what keys are required or their length.   And 
the suites are all over the place in required keys and lengths - the 
null encryption suites don't require encryption keys, and the AEAD 
suites don't require MAC keys, so PKCS11 can't really enforce minimum 
lengths there.

Yes - yuck - I didn't even consider this.  Even if you don't leak out 
into the IV, there are crypto algorithms still in use with way too short 
key lengths.  You could do exactly what you said and use this to brute 
force the DES 56 bit keys (plus 8 parity) and then concatenate the 
individual results to get the AES keys.


Thanks for this.  I think it can be fixed though and relatively simply, 
but will require changes to the key expansion step that are a bit more 
than I suggested:

E.g. in addition to the master_key, label and random data being fed into 
the KDF, also feed in - in order for each output key - 2 or 4 bytes each 
that describe the length of the key.  And that's taken directly from the 
inputs for the key lengths requested.

That means that any time you vary the length of ANY key in the key 
expansion, the entire key stream changes.

It also means that there isn't a need for a separate IV sub key for the 
key expansion stage (I think....)

I'll write it up.

Mike




From ynir@checkpoint.com  Sat Sep 21 12:15:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D285821F9D31 for ; Sat, 21 Sep 2013 12:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.338
X-Spam-Level: 
X-Spam-Status: No, score=-10.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i5N1jKB19Zbq for ; Sat, 21 Sep 2013 12:15:40 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8867121F9D33 for ; Sat, 21 Sep 2013 12:15:39 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8LJFWD1023318; Sat, 21 Sep 2013 22:15:36 +0300
X-CheckPoint: {523DF054-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sat, 21 Sep 2013 22:15:33 +0300
From: Yoav Nir 
To: "Michael D'Errico" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac61Hnof5dKKYJ0xmEuWRIX4Ztx5/QBYDy2AABRpPoAABVvNgA==
Date: Sat, 21 Sep 2013 19:15:31 +0000
Message-ID: <8B499338-45C3-4680-892B-880135BEF7F3@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com>
In-Reply-To: <523DCC5D.9040707@pobox.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.217]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 19:15:46 -0000

On Sep 21, 2013, at 7:42 PM, Michael D'Errico  wrote:

> James,
>=20
> The problem is that there apparently is lots of TLS code which can only h=
andle
> 1024-bit DH parameters and would break if a server sent larger parameters=
.
>=20
> The idea that 1024 is big enough stems from the fact that many many conne=
ctions
> don't use DH at all, and would benefit if RSA was replaced by EDH.  Thus =
an
> attacker would need to break 1024-bit DH for each connection of interest.

Many websites cannot deploy 2048-bit EDH because of limitations in their so=
ftware, and those who can won't, because of interop issues with many of the=
 browsers that are out there.

OTOH 2048-bit RSA keys work well pretty much everywhere. So we're left with=
 three choices:

 1. 2048-bit RSA keying. That's good security, but no forward secrecy.
 2. 1024-bit EDH, which gives forward secrecy, but may be breakable now or =
in 5 years.
 3. 256-bit ECDH, which gives forward secrecy, but some people feel uneasy =
about.

There are good arguments for and against each of these. I don't think we ha=
ve a measure of whether it's easier to compromise a single RSA private key,=
 or to calculate the DL for several 1024-bit EDH. I don't like how #1 creat=
es an attractive, shiny target for attackers - a single file stolen from a =
web server, and all the traffic can be decrypted in Wireshark. OTOH assumin=
g that an agency such as the NSA or French equivalent is able to break any =
1024-bit EDH (that's not a given) they will be able to decrypt any single c=
onnection that they would like, but I don't believe they have the resources=
 to decrypt every one. That's good for people who are not near the top of t=
he list of threats to national security, but kind of not so good for those =
who are.

As I've said before, I'd rather we chose #3.

Yoav=

From msj@nthpermutation.com  Sat Sep 21 12:29:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3811E8180 for ; Sat, 21 Sep 2013 12:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGN0WqTs6Y3i for ; Sat, 21 Sep 2013 12:29:53 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id 708B321F9302 for ; Sat, 21 Sep 2013 12:29:53 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id n9so1077880qcw.19 for ; Sat, 21 Sep 2013 12:29:51 -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:content-type; bh=MYX6oAPuUfvPOhSBaOKBDDJwFpVGR6DN9imTSc2bkfk=; b=iCS9kfygbbwPSpgmqF0SoBnP/wRAgvzaE2JlbiiQE2s9Ku62uwCzdSQiTsimHLKIq+ 06CtltgpLgliw+8qdhEIT1G24ag70VRS8tKGpAS5nv3kqUvC5puCNQskWjlTDfZlPbTZ 6xbif9oz39T2v4UkndTJd49/xcsiBvBkgjQhjZ1OT6LgsaMBonDPwOtywY3Ge71CO8UN KdsJyI6DhBEhYFDON32/wEgZooqn5pygyHZ1mwF+8GzxZc6GqGixHbo8L3FC8jF2bqkD xFfkKZom9WYb9X6lwkLIo53ZIXMrSydb7QzGa19A4M61t0n2zngx4A2G32lvLEj9ofrn UNqw==
X-Gm-Message-State: ALoCoQnrvUiLPz4yRxgNn88ECQyc/RcuEtd3kM/z527BUy8Y8MQtgCtP9kCDPt/JelvtQop7OSGP
X-Received: by 10.49.30.5 with SMTP id o5mr3134132qeh.80.1379791791725; Sat, 21 Sep 2013 12:29:51 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id h20sm28873748qen.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 12:29:51 -0700 (PDT)
Message-ID: <523DF3AF.6060208@nthpermutation.com>
Date: Sat, 21 Sep 2013 15:29:51 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="------------080100040501050403080001"
Subject: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 19:29:59 -0000

This is a multi-part message in MIME format.
--------------080100040501050403080001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Following up on the previous discussion, I propose the following changes 
to the key derivation steps for TLS.  This adds a length field for each 
key being derived to the PRF seed value.  For the pre-master to master 
secret derivation, this is a single 32 bit length field of value 48.  
For the master to key expansion derivation, these are 6 32 bit fields 
each representing the length of one of the keys (or IVs to be derived).

By doing this, varying the length of any one of the sub keys completely 
changes the key stream.  That prevents the type of attack described by 
Juraj.

I spec'd 6 fields for the key expansion derivation instead of three to 
make this completely general - and to allow it to be used with the key 
material export RFCs.


As a side note, most of the KDFs spec'd by NIST require the key length 
to be included as part of the public information fed into the Key 
Derivation Function (KDF).

Mike


>       Computing the Master Secret
>
>
>
>     For all key exchange methods, the same algorithm is used to convert
>     the pre_master_secret into the master_secret.  The pre_master_secret
>     should be deleted from memory once the master_secret has been
>     computed.
>
>        master_secret = PRF(pre_master_secret, "master secret",
>                            ClientHello.random + ServerHello.random +
48  (expressed as 32 bit NBO)
> )
>                            [0..47];
>
>     The master secret is always exactly 48 bytes in length.  The length
>     of the premaster secret will vary depending on key exchange method.



Key Calculation
> When keys and MAC keys are generated, the master secret is used as an
>     entropy source.
>
>     To generate the key material, compute
>
>        key_block = PRF(SecurityParameters.master_secret,
>                        "key expansion",
>                        SecurityParameters.server_random +
>                        SecurityParameters.client_random +
SecurityParameters.mac_key_length +
SecurityParameters.mac_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.fixed_iv_length +
SecurityParameters.fixed_iv_length
> );
>
>     until enough output has been generated.  Then, the key_block is
>     partitioned as follows:
>
>        client_write_MAC_key[SecurityParameters.mac_key_length]
>        server_write_MAC_key[SecurityParameters.mac_key_length]
>        client_write_key[SecurityParameters.enc_key_length]
>        server_write_key[SecurityParameters.enc_key_length]
>        client_write_IV[SecurityParameters.fixed_iv_length]
>        server_write_IV[SecurityParameters.fixed_iv_length]




--------------080100040501050403080001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  

    
  
  
    Following up on the previous discussion, I propose the following
    changes to the key derivation steps for TLS.  This adds a length
    field for each key being derived to the PRF seed value.  For the
    pre-master to master secret derivation, this is a single 32 bit
    length field of value 48.  For the master to key expansion
    derivation, these are 6 32 bit fields each representing the length
    of one of the keys (or IVs to be derived).  

    

    By doing this, varying the length of any one of the sub keys
    completely changes the key stream.  That prevents the type of attack
    described by Juraj.

    

    I spec'd 6 fields for the key expansion derivation instead of three
    to make this completely general - and to allow it to be used with
    the key material export RFCs.

    

    

    As a side note, most of the KDFs spec'd by NIST require the key
    length to be included as part of the public information fed into the
    Key Derivation Function (KDF).

    

    Mike

    

    

    

      
 Computing the Master Secret


   For all key exchange methods, the same algorithm is used to convert
   the pre_master_secret into the master_secret.  The pre_master_secret
   should be deleted from memory once the master_secret has been
   computed.

      master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random + 

    

    48  (expressed as 32 bit NBO)

    

      
)
                          [0..47];

   The master secret is always exactly 48 bytes in length.  The length
   of the premaster secret will vary depending on key exchange method.

    

    

    

    

    Key Calculation

    

      
When keys and MAC keys are generated, the master secret is used as an
   entropy source.

   To generate the key material, compute

      key_block = PRF(SecurityParameters.master_secret,
                      "key expansion",
                      SecurityParameters.server_random +
                      SecurityParameters.client_random +

    

    SecurityParameters.mac_key_length +

    SecurityParameters.mac_key_length +

    SecurityParameters.enc_key_length +

    SecurityParameters.enc_key_length +

    SecurityParameters.fixed_iv_length +

    SecurityParameters.fixed_iv_length 

    

      
);

   until enough output has been generated.  Then, the key_block is
   partitioned as follows:

      client_write_MAC_key[SecurityParameters.mac_key_length]
      server_write_MAC_key[SecurityParameters.mac_key_length]
      client_write_key[SecurityParameters.enc_key_length]
      server_write_key[SecurityParameters.enc_key_length]
      client_write_IV[SecurityParameters.fixed_iv_length]
      server_write_IV[SecurityParameters.fixed_iv_length]

    

    

    

    

    

      

    

  


--------------080100040501050403080001--

From msj@nthpermutation.com  Sat Sep 21 12:43:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4A721F99E7 for ; Sat, 21 Sep 2013 12:43:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vlr9UF9NGzPz for ; Sat, 21 Sep 2013 12:43:33 -0700 (PDT)
Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2611E8137 for ; Sat, 21 Sep 2013 12:43:32 -0700 (PDT)
Received: by mail-qa0-f53.google.com with SMTP id k4so541314qaq.5 for ; Sat, 21 Sep 2013 12:43:32 -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:content-type; bh=lku0O5vFnuZCYStCOlJBmFmBnKJjmg5smXpAYFefL04=; b=lYuvSdqB+TfCjoPOQnYTWo0EOxIdEnN+f3wEKDjoq56TLNjZoqs0Ra/0/VOU0Hhipv 2EbD1fHNURMIeLrsnF3TNGyMp+Y6ifm1Fcs7jVDluiCSGcV1QHzMcHLQLt0qCwIFoWKg wTlnL6N1EUF/6Wh6IhLsFlBR0d9nd/xMnU47/BKwa36Um4DpwTDLWw8YOZ0aBCKmOVw1 1vIvjq9vP627YvVP49/Xp6IOrDZN8d0+HlDhNgafVVSpET9kO6Ju+IyeGeazGyV3QbVT FA/TPlw9vUI79R5AYad8lkRg1ij5jX9nrQKlaaiKW2x4j4BMhQqIfUDTpoGLHMBxoNTl klNg==
X-Gm-Message-State: ALoCoQnfi8Y6kbT73b51XVqUq0242UrhaNZpSjaIXs5aGVBbvOI1QD5lRwYr2PyMNfRjC+jgJqNY
X-Received: by 10.49.52.74 with SMTP id r10mr12385722qeo.28.1379792612256; Sat, 21 Sep 2013 12:43:32 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id a2sm28979510qek.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 12:43:31 -0700 (PDT)
Message-ID: <523DF6E3.70408@nthpermutation.com>
Date: Sat, 21 Sep 2013 15:43:31 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary="------------030300090309060304090504"
Subject: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 19:43:39 -0000

This is a multi-part message in MIME format.
--------------030300090309060304090504
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Following up on the previous discussion, I propose the following changes 
to the key derivation steps for TLS.  This adds a length field for each 
key being derived to the PRF seed value.  For the pre-master to master 
secret derivation, this is a single 32 bit length field of value 48.  
For the master to key expansion derivation, these are 6 32 bit fields 
each representing the length of one of the keys (or IVs to be derived).

By doing this, varying the length of any one of the sub keys completely 
changes the key stream.  That prevents the type of attack described by 
Juraj.

I spec'd 6 fields for the key expansion derivation instead of three to 
make this completely general - and to allow it to be used with the key 
material export RFCs.


As a side note, most of the KDFs spec'd by NIST require the key length 
to be included as part of the public information fed into the Key 
Derivation Function (KDF).

Mike


>       Computing the Master Secret
>
>
>
>     For all key exchange methods, the same algorithm is used to convert
>     the pre_master_secret into the master_secret.  The pre_master_secret
>     should be deleted from memory once the master_secret has been
>     computed.
>
>        master_secret = PRF(pre_master_secret, "master secret",
>                            ClientHello.random + ServerHello.random +
48  (expressed as 32 bit NBO)
> )
>                            [0..47];
>
>     The master secret is always exactly 48 bytes in length.  The length
>     of the premaster secret will vary depending on key exchange method.



Key Calculation
> When keys and MAC keys are generated, the master secret is used as an
>     entropy source.
>
>     To generate the key material, compute
>
>        key_block = PRF(SecurityParameters.master_secret,
>                        "key expansion",
>                        SecurityParameters.server_random +
>                        SecurityParameters.client_random +
SecurityParameters.mac_key_length +
SecurityParameters.mac_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.enc_key_length +
SecurityParameters.fixed_iv_length +
SecurityParameters.fixed_iv_length
> );
>
>     until enough output has been generated.  Then, the key_block is
>     partitioned as follows:
>
>        client_write_MAC_key[SecurityParameters.mac_key_length]
>        server_write_MAC_key[SecurityParameters.mac_key_length]
>        client_write_key[SecurityParameters.enc_key_length]
>        server_write_key[SecurityParameters.enc_key_length]
>        client_write_IV[SecurityParameters.fixed_iv_length]
>        server_write_IV[SecurityParameters.fixed_iv_length]




--------------030300090309060304090504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    Following up on the previous discussion, I propose the following
    changes to the key derivation steps for TLS.  This adds a length
    field for each key being derived to the PRF seed value.  For the
    pre-master to master secret derivation, this is a single 32 bit
    length field of value 48.  For the master to key expansion
    derivation, these are 6 32 bit fields each representing the length
    of one of the keys (or IVs to be derived).  

    

    By doing this, varying the length of any one of the sub keys
    completely changes the key stream.  That prevents the type of attack
    described by Juraj.

    

    I spec'd 6 fields for the key expansion derivation instead of three
    to make this completely general - and to allow it to be used with
    the key material export RFCs.

    

    

    As a side note, most of the KDFs spec'd by NIST require the key
    length to be included as part of the public information fed into the
    Key Derivation Function (KDF).

    

    Mike

    

    

    

      
 Computing the Master Secret


   For all key exchange methods, the same algorithm is used to convert
   the pre_master_secret into the master_secret.  The pre_master_secret
   should be deleted from memory once the master_secret has been
   computed.

      master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random + 

    

    48  (expressed as 32 bit NBO)

    

      
)
                          [0..47];

   The master secret is always exactly 48 bytes in length.  The length
   of the premaster secret will vary depending on key exchange method.

    

    

    

    

    Key Calculation

    

      
When keys and MAC keys are generated, the master secret is used as an
   entropy source.

   To generate the key material, compute

      key_block = PRF(SecurityParameters.master_secret,
                      "key expansion",
                      SecurityParameters.server_random +
                      SecurityParameters.client_random +

    

    SecurityParameters.mac_key_length +

    SecurityParameters.mac_key_length +

    SecurityParameters.enc_key_length +

    SecurityParameters.enc_key_length +

    SecurityParameters.fixed_iv_length +

    SecurityParameters.fixed_iv_length 

    

      
);

   until enough output has been generated.  Then, the key_block is
   partitioned as follows:

      client_write_MAC_key[SecurityParameters.mac_key_length]
      server_write_MAC_key[SecurityParameters.mac_key_length]
      client_write_key[SecurityParameters.enc_key_length]
      server_write_key[SecurityParameters.enc_key_length]
      client_write_IV[SecurityParameters.fixed_iv_length]
      server_write_IV[SecurityParameters.fixed_iv_length]

    

    

    

    

    
 

  


--------------030300090309060304090504--

From yaronf.ietf@gmail.com  Sat Sep 21 14:43:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50611E81A3 for ; Sat, 21 Sep 2013 14:43:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.952
X-Spam-Level: 
X-Spam-Status: No, score=-100.952 tagged_above=-999 required=5 tests=[AWL=-1.704, BAYES_00=-2.599, MANGLED_TOOL=2.3, MIME_8BIT_HEADER=0.3, SARE_OBFU_ALL=0.751, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al3H2LtRfQXd for ; Sat, 21 Sep 2013 14:43:51 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 8A77F11E81A1 for ; Sat, 21 Sep 2013 14:43:41 -0700 (PDT)
Received: by mail-wi0-f169.google.com with SMTP id hj3so914500wib.0 for ; Sat, 21 Sep 2013 14:43:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=KPOax2zguS+PPEpNpMoR5dQiHgYTWkG9sXzZ8UXhbMU=; b=B6Pl5lh4F1gz8uKkTUNf+nNYfF28TW4ahVub+7T6tUaD2TV1eMmqL362hO16sNWOp2 Pyq7wohi1cTwNCQxAVrXE3V4aYMQZCIfF2kt71RdAhWBiPeyanlPy7268pdvi77R13PD pbsP8137JCjfv90b9i+qSfsWpvvpQy8ED4pH4QsnJc/4yok9+4JM9dcIDutrMC2voWCc KPt8pxg13lrN4EqcXAhotSvIIj/Hlnwr9a1JS3sTlZZYp60a4cSfznb1Pl8Nuk4ICjPG lcD0i6g76uvGh8FxToMPXmD6hrQZuj7wXeywz304X+5e284ZxuKhmD0Al7sc4XT8tb6j krkw==
X-Received: by 10.194.110.138 with SMTP id ia10mr11387793wjb.3.1379799818359;  Sat, 21 Sep 2013 14:43:38 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id i8sm14709513wiy.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 14:43:37 -0700 (PDT)
Message-ID: <523E1308.2010501@gmail.com>
Date: Sun, 22 Sep 2013 00:43:36 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= ,  james hughes 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DA10F.7010308@stroeder.com>
In-Reply-To: <523DA10F.7010308@stroeder.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 21:43:52 -0000

Hi James, Michael,

please read the section we just added to -01, 
http://tools.ietf.org/html/draft-sheffer-tls-bcp-01#section-4.4. In 
particular the last sentence.

Thanks,
	Yaron

On 09/21/2013 04:37 PM, Michael Ströder wrote:
> james hughes wrote:
>>
>> On Sep 19, 2013, at 2:56 AM, Peter Gutmann  wrote:
>>
>>> "Blumenthal, Uri - 0558 - MITLL"  writes:
>>>
>>>> I personally think that for *ephemeral* DH even 1024 bits still is enough.
>>>> And would *much* prefer having PFS now with individual session keys at
>>>> somewhat greater risk, over a system that is very secure and completely
>>>> useless because nobody bothered to deploy it.
>>>
>>> Exactly.  We don't need theoretically perfect security in ten years when we've
>>> finished arguing about it and have upgraded every system on the planet to
>>> support it, we just need good enough right now.  That's DH-1024, and when we
>>> have that turned on everywhere we've got some breathing space to worry about
>>> what to do next.
>>
>>
>> "theoretically perfect security in ten years", really? You think that 1024
>> is "good enough"? I do not know a single reputable source that says 1024
>> bit is "secure" (outside the people on this list). Not even NIST. If you
>> are going to step forward for PFS, do it right. Raise the D-H key size to
>> 2048. 2048 bit is required now and will give you security for only 7 years
>> (Thank you France).
>
> I personally would prefer D-H key size 2048 bit everywhere and I don't worry
> about performance. (Did you ever notice that most SSL/TLS connections are
> going to ad servers?)
>
> But the problem in the context of draft-sheffer-tls-bcp is that existing
> implementations do not support D-H key size of 2048 bits. And the author(s) of
> this draft take this fact to rule out DH completely and recommend EC-based
> cipher suites. IMHO ECs seem to be a can of worms. I don't trust those
> complicated cipher suites.
>
> Ciao, Michael.
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From yaronf.ietf@gmail.com  Sat Sep 21 15:02:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2994A11E81A3 for ; Sat, 21 Sep 2013 15:02:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.415
X-Spam-Level: 
X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0jrkX76YquT for ; Sat, 21 Sep 2013 15:02:26 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 607F211E81A2 for ; Sat, 21 Sep 2013 15:02:26 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id n12so1747155wgh.3 for ; Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IkiS/cWXTRt+FtLvYJ48LxjZhyOgSP+oP7LeQ0GnYxY=; b=zs/7aka9ehgQyL4OAkpbfuOC5yPN5LpkqQZtSx49musbvgj+dRYygzTkB4W+xi6yU2 YKiXjxiDMuu+ohFfaTRmeK5/upY4bosyAIgZ4HX/0zAScXF5PN3TPxCPk2MK3ufbIdLd 1yORgKCToRrqlIkx/HXuJVnAC39sjTgCuDgikzrL9biNX/2OhVpDikkTr8aWSsSk5Gd4 IVgXTQ24RUivOIhahTjeIS1c8P6avjFfUhhmxzFNXuMNuIaHk8UsawPEIl/GJyc8rEoc 3gdCTNZWetiu0yPqS+ly9uzm1qHOnVlFYJKBVpZ58WvVIWZbIqepbXO26EHDhzTpxqv/ Dduw==
X-Received: by 10.180.108.199 with SMTP id hm7mr7687246wib.31.1379800945427; Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id fz8sm14391404wic.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 15:02:25 -0700 (PDT)
Message-ID: <523E176F.3050304@gmail.com>
Date: Sun, 22 Sep 2013 01:02:23 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 22:02:27 -0000

Hi Peter,

Thanks for the clarification. Two questions:

- Does any of this brittleness still apply when talking about ECDH (as 
opposed to ECDSA), with fixed parameters?

- Further supporting the brittleness argument... We recently specified 
recipient tests in IKEv2, that apply (and are actually 
security-critical) when either side reuses its DH private key [1]. The 
recipient needs to test that the received point is actually on the 
relevant curve. Are these mandated for ECDHE in TLS? I would have 
expected to see this requirement in [2] (reuse of DH keys is allowed in 
this RFC), but it ain't.

Thanks,
	Yaron

[1] http://tools.ietf.org/html/rfc6989#section-2.3
[2] http://tools.ietf.org/html/rfc4492#section-5.4

On 09/21/2013 11:42 AM, Peter Gutmann wrote:
> Yaron Sheffer  writes:
>
>> I think we've been through all these arguments (on both sides of the issue)
>> over the last week, with the exception of "ECC brittleness". Can you please
>> clarify what you mean by that?
>
> So with RSA-authenticated DH all you need to do is use a constant-time modexp
> on the server when you sign and pre-encode the PKCS #1 expected result and use
> a constant-time memcmp() on the client when you verify and you're OK.  If you
> did that ten years ago then you're safe against pretty much everything that's
> come along since then.
>
> With ECDLP-based algorithms in contrast there's a whole range of issues you
> need to take into account, the worst of which is the distressing propensity of
> the DLP algorithms to leak the private key if you get even the tiniest detail
> wrong.  Not only do you have to get all of these finicky details exactly
> right, but every now and then someone points out a new issue that you then
> need to retroactively patch into your existing code base.  For example if you
> used the recommended (until not too long ago) way to generate your k for
> (EC)DSA then you'd leak a tiny bit of your private key on each signature
> (again, that nasty propensity of DLP algorithms to leak the private key).
> That's what I meant by ECC, and DLP in general, brittleness.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From stephen.farrell@cs.tcd.ie  Sat Sep 21 15:21:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D7721F9B12 for ; Sat, 21 Sep 2013 15:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQ9Nz6L0owjX for ; Sat, 21 Sep 2013 15:21:26 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0246321F9A45 for ; Sat, 21 Sep 2013 15:21:23 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3CE02BE6F; Sat, 21 Sep 2013 23:21:21 +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 ExPr2cokKsW8; Sat, 21 Sep 2013 23:21:20 +0100 (IST)
Received: from [10.87.48.3] (unknown [86.42.23.253]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 31FEDBE62; Sat, 21 Sep 2013 23:21:20 +0100 (IST)
Message-ID: <523E1BDA.7060503@cs.tcd.ie>
Date: Sat, 21 Sep 2013 23:21:14 +0100
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yaron Sheffer 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DA10F.7010308@stroeder.com> <523E1308.2010501@gmail.com>
In-Reply-To: <523E1308.2010501@gmail.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 22:21:32 -0000

Hi Yaron,

Thanks again for the draft. Without any hats, I think the
WG should adopt it too. (With a hat, if they don't, then I'd
AD sponsor it, and so I bet would Sean, but doing this makes
so much sense I bet the WG do adopt it:-)

I'd suggest merging 4.1 and 4.4, since setting out the set
of ciphersuites and the issues faced is really the meat of
the whole thing.

However, regardless of hows its organised, I'd have no
problem if the meat of the recommendation was
"use 1) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or
2) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256" plus some guidance
as to good lengths for everything that can vary.

On the DHE length, I think a bit more information would be
useful if we can get it - exactly which clients or servers
have problems if DH values longer than 1024 are used? (Sorry
if I missed that earlier.)

But I'm firmly in the camp that thinks that 1024 DHE used
now is worthwhile and better than no PFS.

S.

From code@funwithsoftware.org  Sat Sep 21 16:45:14 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1321F9468 for ; Sat, 21 Sep 2013 16:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.353
X-Spam-Level: 
X-Spam-Status: No, score=-1.353 tagged_above=-999 required=5 tests=[AWL=-1.168, BAYES_40=-0.185]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZEcMFOZkx9h for ; Sat, 21 Sep 2013 16:44:38 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2E27921F90A7 for ; Sat, 21 Sep 2013 16:44:37 -0700 (PDT)
Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.50]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id E1FA61EE50A3 for ; Sat, 21 Sep 2013 19:44:31 -0400 (EDT)
Received: (qmail 29200 invoked from network); 21 Sep 2013 23:44:31 -0000
Received: by simscan 1.4.0 ppid: 2509, pid: 31350, t: 0.3914s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 21 Sep 2013 23:44:31 -0000
Message-ID: <523E2F56.9040307@funwithsoftware.org>
Date: Sat, 21 Sep 2013 16:44:22 -0700
From: Patrick Pelletier 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com>
In-Reply-To: <523DCC5D.9040707@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 21 Sep 2013 23:45:15 -0000

On 9/21/13 9:42 AM, Michael D'Errico wrote:

> The problem is that there apparently is lots of TLS code which can only
> handle
> 1024-bit DH parameters and would break if a server sent larger parameters.

Doesn't this "lots of TLS code" boil down to just Java?  That's the only 
implementation I've heard of that supports DHE_RSA but chokes on 2048 
DH.  Is there another?

My understanding of the Windows (SChannel) situation is that Windows has 
a limit of 1024 for DHE_DSS, but doesn't support DHE_RSA at all. 
Although it's unfortunate in some ways that it doesn't support DHE_RSA, 
it's actually a good thing in disguise, since it means that the cipher 
suite negotiation will take care of the problem.

> Remember that this is an Engineering group (the "E" in IETF) which has
> to keep
> the Internet working while we attempt to improve security for everyone.
> If we
> knew how to move to 2048 bits without breaking anything we would.

We *do* know how to move to 2048 bits without breaking anything: add an 
extension to negotiate DH size, just like how ECC curves are negotiated. 
  Although yes, this will take a while to deploy universally, it at 
least means early adopters can start using 2048 now, without breaking 
the stragglers like Java.

(I'd rather just leave Java in the dust and switch to 2048 now.  But if 
we really want to avoid breaking Java, this is how to do it.)

--Patrick


From ynir@checkpoint.com  Sat Sep 21 21:00:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D1411E81FF for ; Sat, 21 Sep 2013 21:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.347
X-Spam-Level: 
X-Spam-Status: No, score=-10.347 tagged_above=-999 required=5 tests=[AWL=0.252, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0EyBR1t+teY for ; Sat, 21 Sep 2013 21:00:10 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id EE11611E80D7 for ; Sat, 21 Sep 2013 21:00:09 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8M403W9019934; Sun, 22 Sep 2013 07:00:03 +0300
X-CheckPoint: {523E6B43-7-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.246]) with mapi id 14.02.0347.000; Sun, 22 Sep 2013 07:00:01 +0300
From: Yoav Nir 
To: Patrick Pelletier 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac61Hnof5dKKYJ0xmEuWRIX4Ztx5/QBYDy2AABRpPoAADr+CAAAI7iMA
Date: Sun, 22 Sep 2013 04:00:02 +0000
Message-ID: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org>
In-Reply-To: <523E2F56.9040307@funwithsoftware.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.204]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4DC508EB7CFE634EA033FBD09EAAAD18@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 04:00:16 -0000

On Sep 22, 2013, at 2:44 AM, Patrick Pelletier  w=
rote:

> On 9/21/13 9:42 AM, Michael D'Errico wrote:
>=20
>> The problem is that there apparently is lots of TLS code which can only
>> handle
>> 1024-bit DH parameters and would break if a server sent larger parameter=
s.
>=20
> Doesn't this "lots of TLS code" boil down to just Java?  That's the only =
implementation I've heard of that supports DHE_RSA but chokes on 2048 DH.  =
Is there another?

There's also Apache, the most common web server on the web, that doesn't ha=
ve configuration parameters for EDH key lengths, and tells OpenSSL to use 1=
024 bits.

> My understanding of the Windows (SChannel) situation is that Windows has =
a limit of 1024 for DHE_DSS, but doesn't support DHE_RSA at all. Although i=
t's unfortunate in some ways that it doesn't support DHE_RSA, it's actually=
 a good thing in disguise, since it means that the cipher suite negotiation=
 will take care of the problem.
>=20
>> Remember that this is an Engineering group (the "E" in IETF) which has
>> to keep
>> the Internet working while we attempt to improve security for everyone.
>> If we
>> knew how to move to 2048 bits without breaking anything we would.
>=20
> We *do* know how to move to 2048 bits without breaking anything: add an e=
xtension to negotiate DH size, just like how ECC curves are negotiated.  Al=
though yes, this will take a while to deploy universally, it at least means=
 early adopters can start using 2048 now, without breaking the stragglers l=
ike Java.

Perhaps it would be better to have the client suggest the actual group rath=
er than bit length in that case. Perhaps we could reuse the IKE numbering o=
f groups, or else have the client specify it similar to ServerDHParams stru=
ct.

> (I'd rather just leave Java in the dust and switch to 2048 now.  But if w=
e really want to avoid breaking Java, this is how to do it.)

There's lots of Java code out there, and servers have no control over what =
clients access them. Unfortunately, people tend to stay with old JVMs for a=
 long time.

Yoav=

From mike-list@pobox.com  Sat Sep 21 21:47:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32D521F8F4A for ; Sat, 21 Sep 2013 21:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.545
X-Spam-Level: 
X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0JGy5xrWyWY for ; Sat, 21 Sep 2013 21:46:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2582621F8F2E for ; Sat, 21 Sep 2013 21:46:57 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 3047CEAB7; Sun, 22 Sep 2013 00:46:54 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=q00bSPBN37SX bzQKiE/pyLg8fJA=; b=UOsq13/tVjztPyVDmJCdOaaLVoXusEFYsKzjyO9Nr73C SoFo9m/R5vfBt1IRcC/w45vzVOb139Szn0BNkfj4pmbJh+G25XpZS1tFBDbzNBFs pktmFsLXuDLmKQOL4whiAyUUcXl4tJKZiAMnziUhPLA6QMKrExiHVBsF5gHuYxg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=L5BDi1 NdgqMVBl6hjkmEbG/hTxLapXobCkgdpV6TKGM786bHxO6Z1x3RnymAnzJOMOCg8r 7zPYGj1j10/nue91vjlzaA6VTXafjIvf0kpGQ8jrdwqzQqChWtpnPTwY0OtDyZkx AFFWqYxtuefUOC0WCQQNU+4Pg9AvLXxNGVUVk=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2944FEAB6; Sun, 22 Sep 2013 00:46:54 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9B7ECEAB5; Sun, 22 Sep 2013 00:46:53 -0400 (EDT)
Message-ID: <523E763C.1010701@pobox.com>
Date: Sat, 21 Sep 2013 21:46:52 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yoav Nir 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>		<523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
In-Reply-To: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 00B76A48-2342-11E3-BE7B-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: TLS Mailing List 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 04:47:02 -0000

Yoav Nir wrote:
> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier  wrote:
> 
>> We *do* know how to move to 2048 bits without breaking anything: add an extension to negotiate DH size, just like how ECC curves are negotiated.  Although yes, this will take a while to deploy universally, it at least means early adopters can start using 2048 now, without breaking the stragglers like Java.
> 
> Perhaps it would be better to have the client suggest the actual group rather than bit length in that case. Perhaps we could reuse the IKE numbering of groups, or else have the client specify it similar to ServerDHParams struct.

If the client chooses, then I'd prefer they choose from a list of
standardized groups similar to RFC 3526 rather than requiring the
server to (try to) verify that the parameters are usable.  We could
also sneak in a 256-bit q parameter to speed up the computations.

Mike

From yaronf.ietf@gmail.com  Sat Sep 21 22:34:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA6DE21F9BF3 for ; Sat, 21 Sep 2013 22:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.435
X-Spam-Level: 
X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooyjaU-NHEQ5 for ; Sat, 21 Sep 2013 22:34:29 -0700 (PDT)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0B65A21F9BF1 for ; Sat, 21 Sep 2013 22:34:25 -0700 (PDT)
Received: by mail-ee0-f49.google.com with SMTP id d41so1021426eek.22 for ; Sat, 21 Sep 2013 22:34:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hiT2uWFJH5cMhtEsGsFBkVksB+3w3eIdnmvZRS1QeHE=; b=zpK1RYZoa+HYBU0itLfxuU6rWau0wrru0WdSFOMj3B8HA9goeEVSMlli0tFv9balOX /Awim9I9QStUWI7ohkKn3By6+vVfPrVcTq9lcP/hp7nYOSNuryZSBIBL/kTuw30f6ulQ gnWM34l1UwbMNwN6PNZh4n2mffO9P1ttivpLEFmTaiSGZ8RXW1O8wtlxtg0KBUp6cGk8 6ENbaHVwQsJR9u0sPmg4to/sNxSAR+T7ZK2TlxHLZ54EYziSTjaJ+e79ghdHwLVHJpNM i/9NkqPtDDY/VxWkgJS1/FS2r56UwpepkC8VtwEz9h9nhRc2gOv7FVmTBuY11jAHVL2Q cG8A==
X-Received: by 10.14.210.8 with SMTP id t8mr24760934eeo.39.1379828065196; Sat, 21 Sep 2013 22:34:25 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id a43sm31692748eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 22:34:24 -0700 (PDT)
Message-ID: <523E815E.8080902@gmail.com>
Date: Sun, 22 Sep 2013 08:34:22 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Yoav Nir 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
In-Reply-To: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Patrick Pelletier , "" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 05:34:29 -0000

It's not "only" Java, it's Windows (Internet Explorer), too. See 
http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html, 
last paragraph.

Thanks,
	Yaron

On 09/22/2013 07:00 AM, Yoav Nir wrote:
>
> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier  wrote:
>
>> On 9/21/13 9:42 AM, Michael D'Errico wrote:
>>
>>> The problem is that there apparently is lots of TLS code which can only
>>> handle
>>> 1024-bit DH parameters and would break if a server sent larger parameters.
>>
>> Doesn't this "lots of TLS code" boil down to just Java?  That's the only implementation I've heard of that supports DHE_RSA but chokes on 2048 DH.  Is there another?
>
> There's also Apache, the most common web server on the web, that doesn't have configuration parameters for EDH key lengths, and tells OpenSSL to use 1024 bits.
>

From yaronf.ietf@gmail.com  Sat Sep 21 22:39:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5FF21F9CB1 for ; Sat, 21 Sep 2013 22:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.451
X-Spam-Level: 
X-Spam-Status: No, score=-102.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tvc59+ObTTGz for ; Sat, 21 Sep 2013 22:39:04 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8985021F9FAB for ; Sat, 21 Sep 2013 22:38:58 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id q16so1018827ead.7 for ; Sat, 21 Sep 2013 22:38:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pWPTjduEvqgltsLIDdCYzzBBfxf3eEqLfC1iQIvmdy4=; b=Fv39qwugIqrlpl3tcVWJ2RoF1l5k/r74imNMIQFF/JH2KhDfYqCb8PoXQrwug4cG8A nxwxgPktwXDF3ZWN5YtS16sJg5sqpUCMAmzHX2hurPSuJVnAlvG8Dh+xogrXyrS5lKi0 8rFZWWOT3hg9C5mg8bPvhpcRBElTcVFss3DUlkAiGpPufmI6deBFuNQ1uRCT+btvPGOv O1bsggiUQC5qVIT3Fevfj4ie6wxsc3/olYoYLg33l8qUuXwz1Np+0cbavkUPVBdIOLjs pidl2uQQ7ltGQkynZFGsdKWJJx3V7Gf+bWU+VsK2Kcozd7co2n1Xo64RYr7OfYuIDVnX 48dQ==
X-Received: by 10.14.109.66 with SMTP id r42mr935619eeg.43.1379828337409; Sat, 21 Sep 2013 22:38:57 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id a1sm31748380eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 22:38:57 -0700 (PDT)
Message-ID: <523E826F.2060500@gmail.com>
Date: Sun, 22 Sep 2013 08:38:55 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Michael D'Errico 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>		<523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E763C.1010701@pobox.com>
In-Reply-To: <523E763C.1010701@pobox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: TLS Mailing List 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 05:39:06 -0000

I'm all for negotiating DH parameters. Life would have been much easier 
if we had it in TLS today.

But new extensions are out of scope for draft-sheffer-tls-bcp. We need a 
set of best common practices that people can actually deploy within the 
coming year, hopefully earlier.

Thanks,
	Yaron

On 09/22/2013 07:46 AM, Michael D'Errico wrote:
> Yoav Nir wrote:
>> On Sep 22, 2013, at 2:44 AM, Patrick Pelletier
>>  wrote:
>>
>>> We *do* know how to move to 2048 bits without breaking anything: add
>>> an extension to negotiate DH size, just like how ECC curves are
>>> negotiated.  Although yes, this will take a while to deploy
>>> universally, it at least means early adopters can start using 2048
>>> now, without breaking the stragglers like Java.
>>
>> Perhaps it would be better to have the client suggest the actual group
>> rather than bit length in that case. Perhaps we could reuse the IKE
>> numbering of groups, or else have the client specify it similar to
>> ServerDHParams struct.
>
> If the client chooses, then I'd prefer they choose from a list of
> standardized groups similar to RFC 3526 rather than requiring the
> server to (try to) verify that the parameters are usable.  We could
> also sneak in a 256-bit q parameter to speed up the computations.
>
> Mike
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From holz@net.in.tum.de  Sun Sep 22 06:03:15 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D81B21F9FF0 for ; Sun, 22 Sep 2013 06:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL1OYjzu7Ina for ; Sun, 22 Sep 2013 06:03:11 -0700 (PDT)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 1538C21F9FBF for ; Sun, 22 Sep 2013 06:03:10 -0700 (PDT)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 6FCE0809FB; Sun, 22 Sep 2013 15:03:09 +0200 (CEST)
Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id A00B1809A5; Sun, 22 Sep 2013 15:03:07 +0200 (CEST)
Message-ID: <523EEAC2.7010707@net.in.tum.de>
Date: Sun, 22 Sep 2013 15:04:02 +0200
From: Ralph Holz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Michael_Str=F6der?= 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DA10F.7010308@stroeder.com>
In-Reply-To: <523DA10F.7010308@stroeder.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 13:03:15 -0000

Hi Michael, all,

> But the problem in the context of draft-sheffer-tls-bcp is that existing
> implementations do not support D-H key size of 2048 bits. And the author(s) of

This is not true. DHE-1024 is the second option in the draft, but 2nd
and 3rd option are described in 4.4, not 4.1. I agree with Stephen
Farell that 4.1 and 4.4 should be merged.

It seems a certain consensus has been reached concerning what can be
easily deployed and what is supported by OS. ECDHE and DHE-1024 seem to
be roughly on the same level, with different problems of their own,
while DHE-2048 is hard to deploy. And we do not want RSA without PFS.

The remaining question, in my opinion, is only whether
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 should be the only "best practice"
or whether TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 should be mentioned as an
equivalent alternative.

I am still undecided on this issue. Heninger et al. have shown last year
what can happen if you have poor entropy in your devices, and they also
gave advice that programmers should not use the non-blocking RNG on
Linux devices. Won't keep programmers from doing it. Similarly, I remain
doubtful about EC implementations.

Ralph


-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

From hughejp@mac.com  Sun Sep 22 07:43:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30D11E80F1 for ; Sun, 22 Sep 2013 07:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level: 
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=2.478,  BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9VF7CTpo5omC for ; Sun, 22 Sep 2013 07:43:22 -0700 (PDT)
Received: from nk11p03mm-asmtp001.mac.com (nk11p03mm-asmtp001.mac.com [17.158.232.236]) by ietfa.amsl.com (Postfix) with ESMTP id C620011E80E4 for ; Sun, 22 Sep 2013 07:43:21 -0700 (PDT)
Received: from [10.0.1.3] (209-82-80-116.dedicated.allstream.net [209.82.80.116]) by nk11p03mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit (built Aug 22 2013)) with ESMTPSA id <0MTJ00C4B7JZHH50@nk11p03mm-asmtp001.mac.com> for tls@ietf.org; Sun, 22 Sep 2013 14:43:12 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794,1.0.431,0.0.0000 definitions=2013-09-22_01:2013-09-22, 2013-09-22, 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-1308280000 definitions=main-1309220078
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DA10F.7010308@stroeder.com> <523EEAC2.7010707@net.in.tum.de>
In-reply-to: <523EEAC2.7010707@net.in.tum.de>
MIME-version: 1.0 (1.0)
Content-transfer-encoding: quoted-printable
Content-type: text/plain; charset=utf-8
Message-id: <6F1E2BE6-23D0-4F6C-A999-07986DB24AD5@mac.com>
X-Mailer: iPad Mail (11A465)
From: james hughes 
Date: Sun, 22 Sep 2013 07:41:13 -0700
To: Ralph Holz 
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 14:43:28 -0000

> On Sep 22, 2013, at 6:04 AM, Ralph Holz  wrote:
>=20
> Hi Michael, all,
>=20
>> But the problem in the context of draft-sheffer-tls-bcp is that existing
>> implementations do not support D-H key size of 2048 bits. And the author(=
s) of
>=20
> This is not true. DHE-1024 is the second option in the draft, but 2nd
> and 3rd option are described in 4.4, not 4.1. I agree with Stephen
> Farell that 4.1 and 4.4 should be merged.

A clearer statement in the draft about what the implementation should do wou=
ld be enabled by the merging of these sections.

> It seems a certain consensus has been reached concerning what can be
> easily deployed and what is supported by OS. ECDHE and DHE-1024 seem to
> be roughly on the same level, with different problems of their own,
> while DHE-2048 is hard to deploy. And we do not want RSA without PFS.

Parameter negotiation seems to be a reasonable (obvious?) bridge to higher l=
evels of security. The fact that the server (or the client, and even sometim=
e a MITM) can reject these higher key lengths seems to be OK with me, the cl=
ient can choose that to fail a connection instead of accepting being downgra=
ded. Even if this results in additional round trips, this would be something=
 that people will work at removing.

The following is probably a na=C3=AFve attempt at a compromise.

To do a better job of "future proofing" the protocol, why aren't we talking a=
bout the key length negotiation of ECDHE? Stated differently, why is the key=
 length hard coded at 256 with the curves being negotiated? Isn't that what g=
ot us into this mess?

If we want to stay with negotiating the complete cypher suites (which I thin=
k is a good thing to avoid ISAKMP style negotiation hell) why not put the ke=
y sizes in the suites like we do for AES and SHA?

We can define two new ones=20
TLS_ECDHE256_RSA2048_GCMAES128_SHA256
TLS_DHE2048_RSA2048_GCMAES128_SHA256

And create an alias for the existing DHE using 1024 as TLS_DHE1024_RSA1024_G=
CMAES128_SHA256.

Naming is one of the two hardest things in Computer Science.

Again, I apologize if this is an overly simplistic solution.




From holz@net.in.tum.de  Sun Sep 22 07:51:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D52021F9E98 for ; Sun, 22 Sep 2013 07:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.528
X-Spam-Level: 
X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HELO_EQ_DE=0.35, MISSING_HEADERS=1.292]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZV06V9yhwoPN for ; Sun, 22 Sep 2013 07:51:30 -0700 (PDT)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6821F9E91 for ; Sun, 22 Sep 2013 07:51:29 -0700 (PDT)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 3698480B92; Sun, 22 Sep 2013 16:51:28 +0200 (CEST)
Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id CC86B80B8C for ; Sun, 22 Sep 2013 16:51:27 +0200 (CEST)
Message-ID: <523F0426.4010901@net.in.tum.de>
Date: Sun, 22 Sep 2013 16:52:22 +0200
From: Ralph Holz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
CC: "TLS@ietf.org (tls@ietf.org)" 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DA10F.7010308@stroeder.com> <523EEAC2.7010707@net.in.tum.de> <6F1E2BE6-23D0-4F6C-A999-07986DB24AD5@mac.com>
In-Reply-To: <6F1E2BE6-23D0-4F6C-A999-07986DB24AD5@mac.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 14:51:35 -0000

Hi,

> Parameter negotiation seems to be a reasonable (obvious?) bridge to
> higher levels of security. The fact that the server (or the client,
> and even sometime a MITM) can reject these higher key lengths seems
> to be OK with me, the client can choose that to fail a connection
> instead of accepting being downgraded. Even if this results in
> additional round trips, this would be something that people will work
> at removing.
> 
> The following is probably a naïve attempt at a compromise.

[...]

That wouldn't be the scope of the BCP. As Yaron has stated, the aim is a
recommendation that can be followed with what we have, striking a
compromise between PFS (near-must), support in software, and security of
AES. We leave the definition of new extension, or use thereof, to other
drafts.

When we're talking about other ciphers, I'd personally much rather see
Peter's proposal of encrypt-then-MAC, although not as an extension, please.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

From christian.kahlo@ageto.net  Fri Sep 20 09:11:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDAA621F9BDB for ; Fri, 20 Sep 2013 09:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.739
X-Spam-Level: 
X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uedGW8bgX04f for ; Fri, 20 Sep 2013 09:10:57 -0700 (PDT)
Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id AA0C921F9BD0 for ; Fri, 20 Sep 2013 09:10:56 -0700 (PDT)
Received: by mail-bk0-f47.google.com with SMTP id mx12so270520bkb.34 for ; Fri, 20 Sep 2013 09:10: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:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version:content-type :thread-index:content-language; bh=8dgAAa1Jk2nQYmHX4z/bsHlMs88tElB2XrnqhHSnGtE=; b=YHhD6kIDiW9KZrL1T48kninyewQ0bP1IldKgiGSo+I2TG0HNA+v7+DAhMKKXD+zQ5O xdq+7SToT5pAtFPQjn5UreUSy4i9XNbnRgoNvbC7FXYEKSYWhkP4Lq+QLyIa2ql+Olr0 WvieeC5aUldLTFP0AYKLduy+tKsiuoytwryBaKnx2ZljcNZEZxx/xG5eMsVL9yBfksNp RQZd5wroGepVOqDcoN5ODSTkHPDAKDWvzlxBkG55A0RzcS1dmDCdkMpAEZq95Qco6G2Z V8CGLsX5ydsN0E50TCtBAktPGEbwWD7/nVpb4cUG6uXRBZ2PA5X7oCieP6C2PxzjOcjf MLDQ==
X-Gm-Message-State: ALoCoQk9TEs0l3YqHQnWDGBX1eDZUg6Q0wQdjJXZxfk5V1x9AQi/7VfCiR+tYtq3ogzS/VFfLOX/
X-Received: by 10.204.78.8 with SMTP id i8mr6050015bkk.3.1379693455459; Fri, 20 Sep 2013 09:10:55 -0700 (PDT)
Received: from THINK2 (cable-62-117-11-172.cust.telecolumbus.net. [62.117.11.172]) by mx.google.com with ESMTPSA id b7sm4871940bkg.1.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 20 Sep 2013 09:10:55 -0700 (PDT)
From: "Christian Kahlo" 
To: "'Eric Rescorla'" , 
References: 
In-Reply-To: 
Date: Fri, 20 Sep 2013 18:10:56 +0200
Organization: AGETO Innovation GmbH
Message-ID: <523c738f.0733cc0a.41a0.3096@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CEB62C.C1473A50"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac62GbeJWByUsfvQQOecd2O6aVfcqgAAI1lQ
Content-Language: de
X-Mailman-Approved-At: Sun, 22 Sep 2013 10:52:04 -0700
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 20 Sep 2013 16:13:56 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01CEB62C.C1473A50
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Eric,

=20

just as side note. The Germen Federal Office for Information Security =
also
had a look

on this. See BSI TR-03116-4.

=20

https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Technis=
che
Richtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=3DpublicationFile

=20

I'm sorry, there is no english translation yet. But it will be =
translated
later.

On page 8, chapter 2.3, "Weitere Vorgaben" / "More specifications", 4th
bullet.

It reads that Encrypt-then-Mac should be preferred instead of
Mac-then-Encrypt.

The reasons are rather simple: GCM is not yet available everywhere. One

example are Java/JDK environments without additional crypto providers =
used

with many application servers.

Even some other standards bodies like ISO, CEN, BSI, etc. agreed on
CBC-modes

(with or without EtM) as a lowest common factor with TLS.

=20

So CBC WILL(!) exist regardless what you're specifying here. ;-)

There also at least implementations in our Federal project, OpenSSL, =
Bouncy

Castle and as I heard CyaSSL, too.

=20

The discussion isn't about AEAD or not, the discussion is about a =
protocol
design

flaw lasting now for more than FOURTEEN YEARS.

Just compare it to ISO7816-4 secure messaging. EtM has been there from =
the

beginning.

=20

Cheers,

Christian

=20

--=20

Christian Kahlo, Research Manager IT-Security,  
http://www.ageto.de

c.kahlo@ageto.de, Tel. +49-3641-3678-305, Fax +49-3641-3678-101

AGETO Innovation GmbH, Winzerlaer Stra=DFe 2, D-07745 Jena

Gesch=E4ftsf=FChrung: P. Israel, S. Sauer, S. Scheppe HR: Amtsgericht =
Jena, HRB
210399

=20

=20

Von: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] Im Auftrag von =
Eric
Rescorla
Gesendet: Freitag, 20. September 2013 17:53
An: tls@ietf.org
Betreff: [TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt

=20

Peter,

=20

After reviewing this document I have a few comments/questions:

=20

- Because this draft relies on extensions, it seems not to resist

  active attack when clients do insecure version fallback

  (see for instance:
http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)

  The existing attacks appear to principally be active attacks on the
browser

  environment, which is where fallback tends to happen.

=20

- Maybe I am misreading the draft, but I'm unclear on how you get

   the TLSCompressed.length for the MAC computation in Section 3.

   Does this have the same issue as was raised for McGrew's CBC AEAD

   draft?

=20

Am I missing something here?

=20

Thanks,

-Ekr

=20


------=_NextPart_000_000F_01CEB62C.C1473A50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable



Hi Eric,
 
just as side note. The Germen Federal Office for Information Security =
also had a look
on this. See BSI TR-03116-4.
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikat=
ionen/TechnischeRichtlinien/TR03116/BSI-TR-03116-4.pdf?__blob=3Dpublicati=
onFile
 
I'm sorry, there is no english translation yet. But it will be =
translated later.
On page 8, chapter 2.3, "Weitere Vorgaben" / "More =
specifications", 4th bullet.
It reads that Encrypt-then-Mac should be preferred instead of =
Mac-then-Encrypt.
The reasons are rather simple: GCM is not yet available everywhere. =
One
example are Java/JDK environments without additional crypto providers =
used
with many application servers.
Even some other standards bodies like ISO, CEN, BSI, etc. agreed on =
CBC-modes
(with or without EtM) as a lowest common factor with =
TLS.
 
So CBC WILL(!) exist regardless what you're specifying here. =
;-)
There also at least implementations in our Federal project, OpenSSL, =
Bouncy
Castle and as I heard CyaSSL, too.
 
The discussion isn't about AEAD or not, the discussion is about a =
protocol design
flaw lasting now for more than FOURTEEN =
YEARS.
Just compare it to ISO7816-4 secure messaging. EtM has been there =
from the
beginning.
 
Cheers,
Christian
 
-- 
Christian Kahlo, Research Manager IT-Security, http://www.ageto.de
c.kahlo@ageto.de, Tel. =
+49-3641-3678-305, Fax +49-3641-3678-101
AGETO Innovation GmbH, Winzerlaer Straße 2, D-07745 =
Jena
Geschäftsführung: P. Israel, S. Sauer, S. Scheppe HR: =
Amtsgericht Jena, HRB 210399
 
 
Von:<=
/b> =
tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] Im Auftrag von =
Eric Rescorla
Gesendet: Freitag, 20. September 2013 =
17:53
An: tls@ietf.org
Betreff: [TLS] =
Comments/Questions on =
draft-gutmann-tls-encrypt-then-mac-00.txt
 
Peter,
 
After reviewing this document I have a few =
comments/questions:
 
- =
Because this draft relies on extensions, it seems not to =
resist
  active =
attack when clients do insecure version =
fallback
  The existing attacks =
appear to principally be active attacks on the =
browser
  =
environment, which is where fallback tends to =
happen.
 
- =
Maybe I am misreading the draft, but I'm unclear on how you =
get
   the =
TLSCompressed.length for the MAC computation in Section =
3.
   Does this =
have the same issue as was raised for McGrew's CBC =
AEAD
  =
 draft?
 
Am I missing something =
here?
 
Thanks,
-Ekr
 

------=_NextPart_000_000F_01CEB62C.C1473A50--


From lists@drh-consultancy.co.uk  Sun Sep 22 11:34:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19621F9C8E for ; Sun, 22 Sep 2013 11:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level: 
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BCgajLqOFh0 for ; Sun, 22 Sep 2013 11:34:46 -0700 (PDT)
Received: from claranet-outbound-smtp01.uk.clara.net (claranet-outbound-smtp01.uk.clara.net [195.8.89.34]) by ietfa.amsl.com (Postfix) with ESMTP id C215821F9C55 for ; Sun, 22 Sep 2013 11:34:46 -0700 (PDT)
Received: from dab-bas1-h-18-10.dab.02.net ([82.132.215.183]:29915 helo=[10.133.31.245]) by relay01.mail.eu.clara.net (relay.clara.net [213.253.3.41]:10465) with esmtpa (authdaemon_plain:drh) id 1VNoUQ-0004s0-4d for tls@ietf.org (return-path ); Sun, 22 Sep 2013 18:34:38 +0000
Message-ID: <523F383A.20803@drh-consultancy.co.uk>
Date: Sun, 22 Sep 2013 19:34:34 +0100
From: Dr Stephen Henson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References:  <523c738f.0733cc0a.41a0.3096@mx.google.com>
In-Reply-To: <523c738f.0733cc0a.41a0.3096@mx.google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 18:34:51 -0000

On 20/09/2013 17:10, Christian Kahlo wrote:
> 
> Even some other standards bodies like ISO, CEN, BSI, etc. agreed on CBC-modes
> 
> (with or without EtM) as a lowest common factor with TLS.
> 
> So CBC WILL(!) exist regardless what you're specifying here. ;-)
> 
> There also at least implementations in our Federal project, OpenSSL, Bouncy
> 
> Castle and as I heard CyaSSL, too.
> 

This has some interesting parallels with FIPS 140-2. Currently the only approved
symmetric algorithms for FIPS 140-2 and TLS are AES-GCM, AES-CBC and DES3-CBC.
If you can't deploy TLS 1.2 you're then stuck with CBC.

Getting new algorithms approved by a standards body wont happen overnight and
might not happen at all. Algorithms tests and implementation guidance,
discussion periods etc will be needed all of which takes time.

On top of that adding new algorithms to an existing module requires retesting,
typically on every platform affected. That is expensive and laborious but wont
dent larger corporations budgets much. What will hurt more is that getting a new
validation done might take 9 months to a year after submission (more in some
cases) to get final approval.

What that means in practice is that when ciphersuites using new algorithms are
approved for TLS expect a delay of 1-2 years before they can be deployed with
FIPS 140-2 and they may not even get approved at all.

By contrast Peter's ETM spec, as it doesn't need any new algorithms, could be
deployed as soon as it is approved.

I'm not saying that we don't approve new algorithms and ciphers suites. I'm
saying we need ETM as well.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shenson@drh-consultancy.co.uk, PGP key: via homepage.

From n.mavrogiannopoulos@gmail.com  Sun Sep 22 14:28:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBFF21F9D1F for ; Sun, 22 Sep 2013 14:28:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbKxvcJTvk17 for ; Sun, 22 Sep 2013 14:28:58 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 01A5C21F9D1E for ; Sun, 22 Sep 2013 14:28:57 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id m14so1327982eaj.34 for ; Sun, 22 Sep 2013 14:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=+Xi5UsOvh4Ruu688ps7WoAAk2dzPha98//LJJuUWE2Q=; b=ut6OIDLiTSYyHTKz7x3rz+n0HjlkSJ4rptqCPLAbhtMrOMPkAjHRc5cF6QlH4N3eQl sqkSSYUtnrrCmL3e5sCQ7cFYsCywIsNZlFxoo0XCiFlMKGmu0O74hDcv9DZLXZxBW4Cr kxkU8wkgvsi2X+rxNEugRuLVEN4YWS1TvxKh8+xTN165H5zQCl/8egIHs4+mqNGyx3s0 zf0CD1r70UVomYilFLb6tCrnC/hyGFkF6g4pAHm49b8CiFQ7/g2eWQF//N3BRTekQPbU aJ4Vj2mJuyQoFNQGyYpsgA+XUEO8InJH1JlrcOt2YxuiowRiagRkqMJWawA1ws+KOsUf 6ftA==
X-Received: by 10.14.113.137 with SMTP id a9mr30859843eeh.3.1379885337058; Sun, 22 Sep 2013 14:28:57 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id k7sm36928186eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 22 Sep 2013 14:28:56 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <523F6112.9040306@gnutls.org>
Date: Sun, 22 Sep 2013 23:28:50 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: james hughes 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 21:28:59 -0000

On 09/21/2013 08:57 AM, james hughes wrote:

> "theoretically perfect security in ten years", really? You think that
> 1024 is "good enough"? I do not know a single reputable source that
> says 1024 bit is "secure" (outside the people on this list). Not even
> NIST. If you are going to step forward for PFS, do it right. Raise
> the D-H key size to 2048. 2048 bit is required now and will give you
> security for only 7 years (Thank you France).
[...]
> Why does the burden of proof seem to be so high on the cryptographers
> to prove that an algorithm (or key size) is not secure enough? Stated
> differently, why must crypto community, who knows something is, or
> will soon be, breakable have to shame the standards bodies into
> reasonable action with a pie in the face  [for the non-english
> speakers, for a definition of "pie in the face" see
> http://en.wikipedia.org/wiki/Pieing]?

I couldn't agree more. The fact that 1024-bits is the only option in
some implementation that doesn't make it the best practice. It was the
best practice 13 years ago.

What would be reasonable would be to keep 2048 as the recommended value
(so the implementations with issues have an incentive to fix) and
additionally mention the issues that some implementations have, and
recommend that if short term protection is sufficient 1024-bit DH groups
offer better compatibility. Mentioning anything else than that will
mislead non-crypto experts (all key length studies list 1024-bit DH
groups as suitable for short-term data protection, nothing more).

regards,
Nikos


From frantz@pwpconsult.com  Sun Sep 22 15:10:02 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147F821F9D17 for ; Sun, 22 Sep 2013 15:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.184
X-Spam-Level: 
X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbQAjhoDBQ31 for ; Sun, 22 Sep 2013 15:09:57 -0700 (PDT)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC6321F9D11 for ; Sun, 22 Sep 2013 15:09:56 -0700 (PDT)
Received: from [173.75.83.246] (helo=Williams-MacBook-Pro.local) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1VNrqj-0002D4-V6 for tls@ietf.org; Sun, 22 Sep 2013 18:09:54 -0400
Date: Sun, 22 Sep 2013 15:09:54 -0700
From: Bill Frantz 
To: tls@ietf.org
X-Priority: 3
In-Reply-To: <523F383A.20803@drh-consultancy.co.uk>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7981485ffd69705a2b1928a2d7e24d3dd9350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 173.75.83.246
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 22 Sep 2013 22:10:02 -0000

On 9/22/13 at 11:34 AM, lists@drh-consultancy.co.uk (Dr Stephen Henson) wro=
te:

> By contrast Peter's ETM spec, as it doesn't need any new algorithms, coul=
d be
> deployed as soon as it is approved.
>=20
> I'm not saying that we don't approve new algorithms and ciphers suites. I=
'm
> saying we need ETM as well.

I would also like to see Peter's ETM spec move forward.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        |Security, like correctness, is| Periwinkle
(408)356-8506      |not an add-on feature. - Attr-| 16345 Englewood Ave
www.pwpconsult.com |ibuted to Andrew Tanenbaum    | Los Gatos, CA 95032


From code@funwithsoftware.org  Sun Sep 22 21:16:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4647F21F968B for ; Sun, 22 Sep 2013 21:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.484
X-Spam-Level: 
X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX-joArnTiz3 for ; Sun, 22 Sep 2013 21:16:35 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 0482B21F9C99 for ; Sun, 22 Sep 2013 21:16:30 -0700 (PDT)
Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 85A761EE53D5 for ; Mon, 23 Sep 2013 00:16:26 -0400 (EDT)
Received: (qmail 2862 invoked from network); 23 Sep 2013 04:16:26 -0000
Received: by simscan 1.4.0 ppid: 3061, pid: 5523, t: 1.2530s scanners: clamav: 0.88.2/m:52/d:13495 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Sep 2013 04:16:24 -0000
Message-ID: <523FC097.1070503@funwithsoftware.org>
Date: Sun, 22 Sep 2013 21:16:23 -0700
From: Patrick Pelletier 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Ralph Holz 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DA10F.7010308@stroeder.com> <523EEAC2.7010707@net.in.tum.de>
In-Reply-To: <523EEAC2.7010707@net.in.tum.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "TLS@ietf.org \(tls@ietf.org\)" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 04:16:41 -0000

On 9/22/13 6:04 AM, Ralph Holz wrote:

> I am still undecided on this issue. Heninger et al. have shown last year
> what can happen if you have poor entropy in your devices, and they also
> gave advice that programmers should not use the non-blocking RNG on
> Linux devices. Won't keep programmers from doing it. Similarly, I remain
> doubtful about EC implementations.

Possibly off-topic for TLS list, but: I don't think the answer is quite 
as simple as "use /dev/random" instead of "/dev/urandom".  The issue is 
only at boot time.  Once the system has been seeded with sufficient 
entropy, /dev/urandom is fine, because the entropy doesn't actually get 
"used up."  Search for "crying wolf" in the Heninger paper.

Perhaps the answer is to check the uptime, and use /dev/random if the 
system has been up for less than 3 (or 5, or something) minutes, and use 
/dev/urandom otherwise.

This has been discussed extensively in the "random vs urandom" thread on 
the randombit cryptography list last month.

--Patrick


From code@funwithsoftware.org  Sun Sep 22 21:27:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5164311E8192 for ; Sun, 22 Sep 2013 21:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level: 
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uyob-XSCrlFz for ; Sun, 22 Sep 2013 21:27:23 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 95EDB11E818E for ; Sun, 22 Sep 2013 21:27:23 -0700 (PDT)
Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.49]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id D280F1EE53D9 for ; Mon, 23 Sep 2013 00:27:22 -0400 (EDT)
Received: (qmail 29930 invoked from network); 23 Sep 2013 04:27:22 -0000
Received: by simscan 1.4.0 ppid: 2965, pid: 22137, t: 1.2656s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Sep 2013 04:27:21 -0000
Message-ID: <523FC31D.2040708@funwithsoftware.org>
Date: Sun, 22 Sep 2013 21:27:09 -0700
From: Patrick Pelletier 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Yaron Sheffer 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523E815E.8080902@gmail.com>
In-Reply-To: <523E815E.8080902@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 04:27:29 -0000

On 9/21/13 10:34 PM, Yaron Sheffer wrote:
> It's not "only" Java, it's Windows (Internet Explorer), too. See
> http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html,
> last paragraph.

Yes, that's one of the sources I've been using, but I guess I'm 
interpreting it differently than you are.  My reading is based on the 
last sentence of that last paragraph, "IE does not support DHE in 
combination with RSA, and will never negotiate a DHE suite, anyway."

So, my interpretation is that the 1024-bit limit only applies to DSS in 
IE.  Since IE doesn't support DHE_RSA, the 1024-bit limit doesn't matter 
there.  So yes, that means you can't actually use DHE_RSA with Internet 
Explorer (regardless of bit length), but the important point is that it 
doesn't hurt for the server to support DHE_RSA, since IE won't offer it. 
  This is in contrast to the Java situation, where Java will offer 
DHE_RSA, the server will choose it, and then Java will bail because it 
doesn't support the DH length.  This results in a failed handshake, 
while the Windows situation doesn't.

--Patrick


From code@funwithsoftware.org  Sun Sep 22 21:37:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9413321F999B for ; Sun, 22 Sep 2013 21:37:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.358
X-Spam-Level: 
X-Spam-Status: No, score=-2.358 tagged_above=-999 required=5 tests=[AWL=0.241,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dbu686-i5h-l for ; Sun, 22 Sep 2013 21:37:29 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF511E818E for ; Sun, 22 Sep 2013 21:37:25 -0700 (PDT)
Received: from mail4.sea5.speakeasy.net (mail4.sea5.speakeasy.net [69.17.117.48]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 70CBB1EE5084 for ; Mon, 23 Sep 2013 00:37:24 -0400 (EDT)
Received: (qmail 25745 invoked from network); 23 Sep 2013 04:37:24 -0000
Received: by simscan 1.4.0 ppid: 13057, pid: 25134, t: 1.3224s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO PatrickMBP.local) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail4.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 23 Sep 2013 04:37:22 -0000
Message-ID: <523FC581.3090103@funwithsoftware.org>
Date: Sun, 22 Sep 2013 21:37:21 -0700
From: Patrick Pelletier 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Yoav Nir 
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
In-Reply-To: <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 04:37:34 -0000

On 9/21/13 9:00 PM, Yoav Nir wrote:

> There's also Apache, the most common web server on the web, that doesn't have configuration parameters for EDH key lengths, and tells OpenSSL to use 1024 bits.

I view the Apache situation as an entirely different thing, since it's 
on the server side, rather than the client side, and the server is the 
one who gets to choose the parameters in the first place.  If the BCP 
says "you should configure your server to use 2048 bits" and the server 
only supports 1024 bits, then the sysadmin will just configure it to use 
1024 bits, and we'll be no worse off than if the BCP had said to use 
1024 bits.  The point is that this doesn't actually break anything.

This is in contrast to the situation where the server picks 2048 bits, 
and the *client* only supports 1024 bits.  In that case, the handshake 
will fail.  So I see the Java (client side) issue as much worse than the 
Apache (server side) issue.

Also, of course, this is easy to fix, since one can recompile Apache to 
support larger DH:

http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html

(Hey, this isn't any worse than suggesting that everyone on Red Hat 
needs to recompile to get ECC support.)

It's also worth pointing out that technically this is an issue with 
mod_ssl, not with Apache itself.  You could always use mod_gnutls instead.

--Patrick


From ynir@checkpoint.com  Sun Sep 22 22:22:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531D811E8186 for ; Sun, 22 Sep 2013 22:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.355
X-Spam-Level: 
X-Spam-Status: No, score=-10.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5W-qGbwBenn for ; Sun, 22 Sep 2013 22:22:00 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB411E80D7 for ; Sun, 22 Sep 2013 22:21:59 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8N5Lr4a011397; Mon, 23 Sep 2013 08:21:54 +0300
X-CheckPoint: {523FCFF1-F-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Mon, 23 Sep 2013 08:21:53 +0300
From: Yoav Nir 
To: Patrick Pelletier 
Thread-Topic: draft-sheffer-tls-bcp: DH recommendations
Thread-Index: AQHOuBaedQwzN3MPlUCJDzO8Os+PB5nSlycA
Date: Mon, 23 Sep 2013 05:21:53 +0000
Message-ID: <83FC5008-BB1A-4CC9-9DB5-4F14CF52FA06@checkpoint.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523FC581.3090103@funwithsoftware.org>
In-Reply-To: <523FC581.3090103@funwithsoftware.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.139]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <5F80E6B39083B6478A39ED025D00F5E9@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 05:22:05 -0000

On Sep 23, 2013, at 7:37 AM, Patrick Pelletier  w=
rote:

> On 9/21/13 9:00 PM, Yoav Nir wrote:
>=20
>> There's also Apache, the most common web server on the web, that doesn't=
 have configuration parameters for EDH key lengths, and tells OpenSSL to us=
e 1024 bits.
>=20
> I view the Apache situation as an entirely different thing, since it's on=
 the server side, rather than the client side, and the server is the one wh=
o gets to choose the parameters in the first place.  If the BCP says "you s=
hould configure your server to use 2048 bits" and the server only supports =
1024 bits, then the sysadmin will just configure it to use 1024 bits, and w=
e'll be no worse off than if the BCP had said to use 1024 bits.  The point =
is that this doesn't actually break anything.

Some people are suggesting that clients break the connection if offered a 1=
024-bit group. It does make sense that they would break the connection if o=
ffered, say, a 512-bit group, no?

> This is in contrast to the situation where the server picks 2048 bits, an=
d the *client* only supports 1024 bits.  In that case, the handshake will f=
ail.  So I see the Java (client side) issue as much worse than the Apache (=
server side) issue.
>=20
> Also, of course, this is easy to fix, since one can recompile Apache to s=
upport larger DH:
>=20
> http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html
>=20
> (Hey, this isn't any worse than suggesting that everyone on Red Hat needs=
 to recompile to get ECC support.)

No, it's different asking a vendor to change something vs asking end users =
to recompile Apache.

> It's also worth pointing out that technically this is an issue with mod_s=
sl, not with Apache itself.  You could always use mod_gnutls instead.

You can, but then hardly anyone does.

Yoav=

From pgut001@cs.auckland.ac.nz  Sun Sep 22 23:38:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A741621F9E02 for ; Sun, 22 Sep 2013 23:38:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJbRGkk5BnhF for ; Sun, 22 Sep 2013 23:38:41 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 13BDF21F9DD6 for ; Sun, 22 Sep 2013 23:38:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379918321; x=1411454321; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5ZKUt55FVjvj3zYPsZ6o6a8W0tTKvlaOu39HKBiD8WY=; b=B/UtP5UkHDS34s033lz+wC7sXtL14qzWmX3HX4LahZlHRXp0QSCFoRYT pPR/Ms+8pvgSaX18uZdNiTw5fRZT0XZG90nww4CRLpZuC8ZRZ/QT+AIFx Md8DakefEKJOVcXpZN45hmfPRa+6o+sHTg8VXx88jHDWCfYtgl65n+Evx M=;
X-IronPort-AV: E=Sophos;i="4.90,960,1371038400"; d="scan'208";a="213641460"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 23 Sep 2013 18:38:40 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 18:38:39 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac64J4nFQU7WNIrxTjaI1+yfnBwiuQ==
Date: Mon, 23 Sep 2013 06:38:39 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355675958@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 06:38:46 -0000

Patrick Pelletier  writes:=0A=
=0A=
>So, my interpretation is that the 1024-bit limit only applies to DSS in IE=
.=0A=
=0A=
That would make sense, since FIPS 186 for many years limited DSS to 1024 bi=
ts=0A=
it wasn't possible to go over that size anyway.=0A=
=0A=
>This is in contrast to the Java situation, where Java will offer DHE_RSA, =
the=0A=
>server will choose it, and then Java will bail because it doesn't support =
the=0A=
>DH length.=0A=
=0A=
Since anyone running Java is pretty much pre-0wned out of the box, I don't=
=0A=
know if this one is that critical :-).=0A=
=0A=
Peter.=0A=

From code@funwithsoftware.org  Sun Sep 22 23:43:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B148F11E819C for ; Sun, 22 Sep 2013 23:43:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.38
X-Spam-Level: 
X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IpWIIMlYC4wZ for ; Sun, 22 Sep 2013 23:43:15 -0700 (PDT)
Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by ietfa.amsl.com (Postfix) with ESMTP id C1AD911E81A1 for ; Sun, 22 Sep 2013 23:43:12 -0700 (PDT)
Received: from mail6.sea5.speakeasy.net (mail6.sea5.speakeasy.net [69.17.117.50]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 294C61EE53E6 for ; Mon, 23 Sep 2013 02:43:11 -0400 (EDT)
Received: (qmail 12010 invoked from network); 23 Sep 2013 06:43:10 -0000
Received: by simscan 1.4.0 ppid: 762, pid: 5592, t: 1.2494s scanners: clamav: 0.88.2/m:52/d:10739 spam: 3.0.4
Received: from dsl017-096-185.lax1.dsl.speakeasy.net (HELO [192.168.11.2]) (ppelleti@[69.17.96.185]) (envelope-sender ) by mail6.sea5.speakeasy.net (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 23 Sep 2013 06:43:09 -0000
Message-Id: 
From: Patrick Pelletier 
To: Yoav Nir 
In-Reply-To: <83FC5008-BB1A-4CC9-9DB5-4F14CF52FA06@checkpoint.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 22 Sep 2013 23:43:07 -0700
References: <9A043F3CF02CD34C8E74AC1594475C735567407D@uxcn10-6.UoA.auckland.ac.nz>  <523DCC5D.9040707@pobox.com> <523E2F56.9040307@funwithsoftware.org> <3E26A3FE-2491-4D48-BBE9-A11B995CD28D@checkpoint.com> <523FC581.3090103@funwithsoftware.org> <83FC5008-BB1A-4CC9-9DB5-4F14CF52FA06@checkpoint.com>
X-Mailer: Apple Mail (2.936)
Cc: tls@ietf.org
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 06:43:22 -0000

On Sep 22, 2013, at 10:21 PM, Yoav Nir wrote:

> Some people are suggesting that clients break the connection if  
> offered a 1024-bit group. It does make sense that they would break  
> the connection if offered, say, a 512-bit group, no?

True, I think it's reasonable to break the connection for 512, but not  
for 1024.  1024 is "not great security, but not utterly laughable,  
either," so the client ought to accept 1024 if the server offers it.

> No, it's different asking a vendor to change something vs asking end  
> users to recompile Apache.

I think the difference is that the mod_ssl issue is just a matter of  
inertia and might eventually be fixed upstream, while the Red Hat ECC  
position is an institutional policy formulated by lawyers, and is  
unlikely to change.

--Patrick


From n.mavrogiannopoulos@gmail.com  Mon Sep 23 00:03:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EC121F9E96 for ; Mon, 23 Sep 2013 00:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.392
X-Spam-Level: 
X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.207,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LiHcYcRpLohJ for ; Mon, 23 Sep 2013 00:03:26 -0700 (PDT)
Received: from mail-ee0-x22c.google.com (mail-ee0-x22c.google.com [IPv6:2a00:1450:4013:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id F3DE521F9E9F for ; Mon, 23 Sep 2013 00:03:25 -0700 (PDT)
Received: by mail-ee0-f44.google.com with SMTP id b47so1490845eek.17 for ; Mon, 23 Sep 2013 00:03:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=Aw02dNQlpJHVAt4OTQorWKYWVH8YJI8hAbeJwPoYWiw=; b=Wzk15vXeAMfJ+/Uppz97ZiIszRfe0XWXYjqCfuGLehgyS/L3nK/061GpXzconHCMOT SV8LURpD0B4fIUIFdAjGczAFbPATyEebFED+TLqrxBL9AGN2Va07pH1N8mAxxGoT+86+ ynA7QMWObt0TzyYkSdUG2jiBsqNjz5GNOY5rh/oVBNG+7ehLeB5Q7uOKLPghPhWpnkvk 7e07eJqYYsQUrRmf/4ouctIrJKQ8On6CrWzfRzfslReHc0DM2Q3/79svyKA4lcm6pv5X RQIZQObUP6nPOhN4pVmx64Hpxz4OCX1LgOslsLscI4Akia1dKOrPVV4tCim9vYdbgixK CRbA==
X-Received: by 10.14.5.3 with SMTP id 3mr1501082eek.49.1379919804868; Mon, 23 Sep 2013 00:03:24 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id r48sm39492054eev.14.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 00:03:24 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <523FE7B6.10501@gnutls.org>
Date: Mon, 23 Sep 2013 09:03:18 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: tls@ietf.org
References:  <523c738f.0733cc0a.41a0.3096@mx.google.com> <523F383A.20803@drh-consultancy.co.uk>
In-Reply-To: <523F383A.20803@drh-consultancy.co.uk>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 07:03:27 -0000

On 09/22/2013 08:34 PM, Dr Stephen Henson wrote:

> This has some interesting parallels with FIPS 140-2. Currently the only approved
> symmetric algorithms for FIPS 140-2 and TLS are AES-GCM, AES-CBC and DES3-CBC.
> If you can't deploy TLS 1.2 you're then stuck with CBC.
[...]
> spec, as it doesn't need any new algorithms, could be
> deployed as soon as it is approved.
> 
> I'm not saying that we don't approve new algorithms and ciphers suites. I'm
> saying we need ETM as well.

What we need is a solution for the issue with the unauthenticated
padding in the CBC ciphersuites. ETM is not the only way to solve the
issue, and even if it is used, it would be highly recommendable to
follow the existing good practices. TLS isn't the first protocol to use
this mode, thus there isn't a need to innovate.

regards,
Nikos


From juraj.somorovsky@rub.de  Mon Sep 23 02:24:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218FA21F9946 for ; Mon, 23 Sep 2013 02:24:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pg+CZMRlBaAW for ; Mon, 23 Sep 2013 02:24:36 -0700 (PDT)
Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id 9E47411E81AF for ; Mon, 23 Sep 2013 02:23:15 -0700 (PDT)
X-Queued: (qmail 13638 invoked by alias); 23 Sep 2013 09:21:48 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 10111 invoked by uid 108); 23 Sep 2013 09:20:39 -0000
X-Qmailscanner: from 134.147.42.227 by mx6.rz.ruhr-uni-bochum.de (envelope-from , uid 102) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88.   Clear:RC:1(134.147.42.227):.  Processed in 0.057764 secs); 23 Sep 2013 09:20:39 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx6.rz.ruhr-uni-bochum.de with SMTP; 23 Sep 2013 09:20:39 -0000
X-Queued: (qmail 22253 invoked by uid 992); 23 Sep 2013 09:20:38 -0000
X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUwAdij50vwJ6A==@134.147.40.78) by mail1.mail.ruhr-uni-bochum.de (envelope-from , uid 0) with qmail-scanner-2.01  (sophie: 3.06/3.45.0/4.91.  Clear:RC:1(134.147.40.78):.  Processed in 0.0229 secs); 23 Sep 2013 09:20:38 -0000
Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUwAdij50vwJ6A==@134.147.40.78) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 23 Sep 2013 09:20:38 -0000
Date: 23 Sep 2013 11:20:36 +0200
Message-ID: <524007E4.5080303@rub.de>
From: "Juraj Somorovsky" 
To: "Michael StJohns" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de> <52379643.7070705@nthpermutation.com> <523AAA0E.2020105@rub.de> <523DEED6.1060501@nthpermutation.com>
In-Reply-To: <523DEED6.1060501@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 09:24:45 -0000

On 09/21/2013 09:09 PM, Michael StJohns wrote:
> Thanks for this.  I think it can be fixed though and relatively simply,
> but will require changes to the key expansion step that are a bit more
> than I suggested:
> 
> E.g. in addition to the master_key, label and random data being fed into
> the KDF, also feed in - in order for each output key - 2 or 4 bytes each
> that describe the length of the key.  And that's taken directly from the
> inputs for the key lengths requested.
> 
> That means that any time you vary the length of ANY key in the key
> expansion, the entire key stream changes.
> 
> It also means that there isn't a need for a separate IV sub key for the
> key expansion stage (I think....)
I do not think this is enough to solve this problem. There are
algorithms that have the same key and IV lengths....e.g. an AES-128 key
has the same length as the IV used in AES-CBC. I think this would break
your key derivation???

An additional problem is that the same key would be used for the same
block ciphers in different modes of operation, e.g. AES-CBC would use
the same key as AES-GCM.

As mentioned in my previous post, a solution would be to derive the
material based on the master secret and the encryption scheme / IV it is
used for. For example you could derive :
- a symmetric key for AES-GCM:
k_GCM = PRF(master_secret, "AES_GCM", [further params])
- a symmetric key for AES-CBC:
k_CBC = PRF(master_secret, "AES_CBC", [further params])
- initialization vector:
IV = PRF(master_secret, "IV", [further params])

This solution however assumes that if k_GCM is generated, the attacker
cannot enforce the PKCS11 module to use it for the AES-CBC computation.
Again, I am not that familiar with PKCS11...can this be achieved in a
typical PKCS11 module?

In other words: can a PKCS11 module admin/user enforce that if a
specific material is derived with a "AES-GCM" parameter, the resulted
key can only be used in AES-GCM?

Thanks
Juraj


From n.mavrogiannopoulos@gmail.com  Mon Sep 23 06:53:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3621921F9F99 for ; Mon, 23 Sep 2013 06:53:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level: 
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, SARE_URI_OEM=0.533]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42jbsxExcDJT for ; Mon, 23 Sep 2013 06:53:28 -0700 (PDT)
Received: from mail-ee0-x22b.google.com (mail-ee0-x22b.google.com [IPv6:2a00:1450:4013:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 21DB421F9FB5 for ; Mon, 23 Sep 2013 06:53:27 -0700 (PDT)
Received: by mail-ee0-f43.google.com with SMTP id e52so1761570eek.16 for ; Mon, 23 Sep 2013 06:53:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=DPH4YysGyVWBT/CF8Z6RbcytUYX8MH407a7XO1Vvp0Y=; b=ljqq0kwQpXsuSgSmnN/iuOPjpJyYU7lDVOSywMFH8ZGfLURajyPrJ6jKWPPzCO7x0p w6LOj1CD5OkZ+2EettnR/uFFWZtIXBwwsIQsfpYq4ScRFSfDuF3FA6vbMUySnYSSOo+d 8LsXbcC0+nN+d4WUO0RhjltmGp/Pq1LsYssRdzde2d41X5IUYDHSVBHcwrdNnl53igZ9 Z47W5bc8T68IRkVHv2YJDbkNLDTV7DCOJLwDf9jOmk5IQBzYpzwtJeiJI0x3koktW+7S Kg/ZOvQenXIlXFXJea9XF8ss1Kn1YxpdpB9Rm4W4H3ZmSKsYX2QN6zq8ewV3Pl5qjjsR qfFA==
X-Received: by 10.14.175.73 with SMTP id y49mr3855207eel.50.1379944407208; Mon, 23 Sep 2013 06:53:27 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id a1sm42327472eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 06:53:26 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <524047D1.7040601@gnutls.org>
Date: Mon, 23 Sep 2013 15:53:21 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: c.kahlo@ageto.net
References:  <523c738f.0733cc0a.41a0.3096@mx.google.com> <523F383A.20803@drh-consultancy.co.uk> <523FE7B6.10501@gnutls.org> <524038fa.c402cd0a.127a.ffffc841@mx.google.com>
In-Reply-To: <524038fa.c402cd0a.127a.ffffc841@mx.google.com>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Christian Kahlo , 'Team Neuer Personalausweis' , tls@ietf.org
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 13:53:29 -0000

On 09/23/2013 02:50 PM, Christian Kahlo wrote:

>>> I'm not saying that we don't approve new algorithms and ciphers
>> suites. I'm
>>> saying we need ETM as well.
>>
>> What we need is a solution for the issue with the unauthenticated
>> padding in the CBC ciphersuites. ETM is not the only way to solve the
>> issue, and even if it is used, it would be highly recommendable to
>> follow the existing good practices. TLS isn't the first protocol to use
>> this mode, thus there isn't a need to innovate.
> 
> maybe you want to read http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
> and http://www.iacr.org/archive/crypto2001/21390309.pdf.
> Both mentioned within this thread:
> http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-
> encrypt-then-mac

Have you actually read the papers you mention? For example have you seen
theorem 2 of the second paper? The issue is with the unauthenticated
padding used in TLS not AtE. There are only philosophical advantages of
EtA over AtE when the latter is implemented properly (i.e., as not in
TLS). Today we have more clues on the issues of AtE than it was at the
time TLS was designed.

> Please tell us which protocols are still using Mac-then-Encrypt today
> without running into any security trouble (esp. chosen ciphertext
> attacks). MtE is considered as a design fail by many researchers.

TLS with stream ciphers. It is authenticate-pad-then-Encrypt that has
issues, please check the literature more carefully.

> As we discussed earlier AEAD might be a solution, but AEAD is not the
> only one. I would encourage everbody to also have a look into
> ISO7816-4 secure messaging. That's the way most electronic ID cards,
> electronic purse cards, credit cards, small HSMs, etc. do communicate.
> And now think about that there's a reason for that it's an EtM-
> scheme.
> Sorry, your attitude "there isn't a need to innovate" sounds
> somewhat unfamiliar with cryptographic primitives to me.

Please read my mail again. The innovate refers to how the current EtA
proposal by Peter ignores all best practices in implementing EtA in
protocols. Existing EtA protocols like IPSec truncate the HMAC to avoid
revealing the whole internal state of the hash algorithm. The
Preneel-van-Oorschot paper referenced previously in the thread gives a
detailed treatment of the issues (admittedly HMAC was designed to
discourage these attacks, but being conservative is a good design practice).

regards,
Nikos


From rsalz@akamai.com  Mon Sep 23 07:37:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB8B21F9E76 for ; Mon, 23 Sep 2013 07:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 342fPiI7tvVT for ; Mon, 23 Sep 2013 07:37:39 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 64DBE21F8AD5 for ; Mon, 23 Sep 2013 07:37:39 -0700 (PDT)
Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9E9D8165523; Mon, 23 Sep 2013 14:37:36 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 936DD16547D; Mon, 23 Sep 2013 14:37:36 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 190C247BEE; Mon, 23 Sep 2013 14:37:36 +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; Mon, 23 Sep 2013 10:37:27 -0400
From: "Salz, Rich" 
To: Yaron Sheffer , "tls@ietf.org" 
Date: Mon, 23 Sep 2013 10:37:26 -0400
Thread-Topic: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-01.txt
Thread-Index: Ac62DoYzoQJGm6p4Q2Sy8rs0AqgiOgCW9rcw
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711D4F64D84@USMBX1.msg.corp.akamai.com>
References: <20130920142728.15100.58320.idtracker@ietfa.amsl.com> <523C5CF6.2040401@gmail.com>
In-Reply-To: <523C5CF6.2040401@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 14:37:46 -0000

> In addition, we request that the TLS working group adopt this document.

+1  This is an important document.

	/r$

-- =20
Principal Security Engineer
Akamai Technology
Cambridge, MA


From christian.kahlo@ageto.net  Mon Sep 23 05:50:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1844C21F8423 for ; Mon, 23 Sep 2013 05:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.066
X-Spam-Level: 
X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_OEM=0.533]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iIroiIrnK89 for ; Mon, 23 Sep 2013 05:50:06 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E4BA821F9EB5 for ; Mon, 23 Sep 2013 05:50:04 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id mz10so1186049bkb.3 for ; Mon, 23 Sep 2013 05:50:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=JO7U94VMQdvt/zHRdk8yBQ1whu2Fty3vaQBSFJSXzcg=; b=VsCisIUWC6xIaAeRpxXG5Kyzai0POVI6kIwrXOXLaPyx7FkHwf/ymxcv9SRjN4W8IJ wr3pRpeAdtHTTdbpcMOd/QPm47moJnHiDAqbgxeOAFgn1uvkPGpK3J7RMz4OQ4floe1c KSdDrCjASi9GTUuTse5ER+xH+mvodqhwZuLnSl1XsJlL2MrG/kzESjo5z4a+ngX0jwQq wGus+agjnebvFUz2Hhew4fCne3DdodyAo2lLmv4KDRHyxAoG8bjsvgsK/yJYRmFBZKoI dYmDiJeA2nB2+cSJRtWF7Kxyl06EIIoKSm/9mCcka1o9wSnRRH+BXtDGBOx0833h7YdD YP4g==
X-Gm-Message-State: ALoCoQl3m/HNhKkJGqq5tThtCUm1x1U43iu2vSjhObqA09gPdQhzQ72J3T/8DLARs/+ad3YKNNUm
X-Received: by 10.205.76.133 with SMTP id ze5mr286048bkb.37.1379940603448; Mon, 23 Sep 2013 05:50:03 -0700 (PDT)
Received: from THINK2 (cable-82-119-12-81.cust.telecolumbus.net. [82.119.12.81]) by mx.google.com with ESMTPSA id nv4sm8663372bkb.3.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Sep 2013 05:50:02 -0700 (PDT)
From: "Christian Kahlo" 
To: "'Nikos Mavrogiannopoulos'" , 
References:  <523c738f.0733cc0a.41a0.3096@mx.google.com> <523F383A.20803@drh-consultancy.co.uk> <523FE7B6.10501@gnutls.org>
In-Reply-To: <523FE7B6.10501@gnutls.org>
Date: Mon, 23 Sep 2013 14:50:07 +0200
Organization: AGETO Innovation GmbH
Message-ID: <524038fa.c402cd0a.127a.ffffc841@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac64Kw6yuxSnT91ZT7WZgfNnfC1+5QALsRaQ
Content-Language: de
X-Mailman-Approved-At: Mon, 23 Sep 2013 08:46:02 -0700
Cc: 'Team Neuer Personalausweis' 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 12:50:12 -0000

Nikos,

> > This has some interesting parallels with FIPS 140-2. Currently the
> only approved
> > symmetric algorithms for FIPS 140-2 and TLS are AES-GCM, AES-CBC and
> DES3-CBC.
> > If you can't deploy TLS 1.2 you're then stuck with CBC.
> [...]
> > spec, as it doesn't need any new algorithms, could be
> > deployed as soon as it is approved.
> >
> > I'm not saying that we don't approve new algorithms and ciphers
> suites. I'm
> > saying we need ETM as well.
> 
> What we need is a solution for the issue with the unauthenticated
> padding in the CBC ciphersuites. ETM is not the only way to solve the
> issue, and even if it is used, it would be highly recommendable to
> follow the existing good practices. TLS isn't the first protocol to use
> this mode, thus there isn't a need to innovate.

maybe you want to read http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
and http://www.iacr.org/archive/crypto2001/21390309.pdf.
Both mentioned within this thread:
http://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-
encrypt-then-mac

Please tell us which protocols are still using Mac-then-Encrypt today
without running into any security trouble (esp. chosen ciphertext
attacks). MtE is considered as a design fail by many researchers.

As we discussed earlier AEAD might be a solution, but AEAD is not the
only one. I would encourage everbody to also have a look into
ISO7816-4 secure messaging. That's the way most electronic ID cards,
electronic purse cards, credit cards, small HSMs, etc. do communicate.
And now think about that there's a reason for that it's an EtM-
scheme.

Sorry, your attitude "there isn't a need to innovate" sounds
somewhat unfamiliar with cryptographic primitives to me.

Cheers,
Christian



From mrex@sap.com  Mon Sep 23 09:22:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2144C21F86B2 for ; Mon, 23 Sep 2013 09:22:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.455
X-Spam-Level: 
X-Spam-Status: No, score=-9.455 tagged_above=-999 required=5 tests=[AWL=-0.695, BAYES_05=-1.11, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 225mVgWNZpCJ for ; Mon, 23 Sep 2013 09:22:29 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id EC26E21F9EAD for ; Mon, 23 Sep 2013 09:22:24 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8NGML9H027622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Sep 2013 18:22:21 +0200 (MEST)
In-Reply-To: <523E826F.2060500@gmail.com>
To: Yaron Sheffer 
Date: Mon, 23 Sep 2013 18:22:21 +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: <20130923162221.6773D1A992@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: TLS Mailing List 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 23 Sep 2013 16:22:38 -0000

Yaron Sheffer wrote:
> 
> But new extensions are out of scope for draft-sheffer-tls-bcp. We need a 
> set of best common practices that people can actually deploy within the 
> coming year, hopefully earlier.


Personally, I believe that the cipher suites currently listed
in the document are *FAR* from realistic.

They're based on _several_ flawed assumptions:
  1) that optional EC crypto is available in deployed implementations
  2) that optional TLSv1.2 is available in deployed implementations
  3) that optional AES-GCM is available in deployed implementations
  4) that TLS clients universally have re-connect fallbacks to
     cope with TLS servers that are TLSv1.2-intolerant.

For a huge number of communication scenarios, all 4 of this list
apply only to one side, for a non-marginal, all 4 of this apply
to neither side.

Please do not underestimate problem (4).  There are currently
SSL accellerators sold (and widely used) that are limited to
TLSv1.0 and will abort connections when ClientHello contains
TLSv1.1 or TLSv1.2.  This year, the fiscal authority of Portugal (IRS)
launched Web-Services scenarios, where such TLSv1.2-intolerant
SSL Accelerators are being used in production.

What I really would appreciate is a recommendation that works
in the real world, providing a path forward that is realistic
to get added through a software update to *EXISTING* implementations,
which clearly rules out all 4 on the above list.

-Martin

From msj@nthpermutation.com  Mon Sep 23 09:29:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22F7121F9FBF for ; Mon, 23 Sep 2013 09:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wQd3dhrD7WRq for ; Mon, 23 Sep 2013 09:29:32 -0700 (PDT)
Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id C864E11E80ED for ; Mon, 23 Sep 2013 09:29:32 -0700 (PDT)
Received: by mail-qe0-f50.google.com with SMTP id a11so2287701qen.9 for ; Mon, 23 Sep 2013 09:29:32 -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=RGU+SrUQQBMAxeZC5yZPg4WDkrIVwNt+97fgKZ95mj4=; b=lyJUuP0hpAqFkbKJfAkOfpGlnHRXjEBA+2xwXGP/zDSlnlvtqXdSw3LPjGnDDLr86m LszO17FalZC8ZUiBdX2fD56pe6mF/j4Ya+ygnwpzGh4J8LLFDXP0fs/4w5rDuTdbhtD4 GxXls0zKWt9DXsmkj7zPP9vp45EDVVatZNDFjY65u0Vp6blzhS1Bj/mJGAe4lmuUKTrn vBgVERwzjsgR7M8an2ZX1mIkFwGUTmPcxtqfW6/p/KTKLGosg4GLN9gary9T0Qm+ZNlK xEhTvw/4Tv0o1DntbziiOjvKXbi3UgQW39g1elCTkbESWWTIo2pN9zgalzav/O7DnHsr NklQ==
X-Gm-Message-State: ALoCoQlyQKjK+Cd10bMPY9CvCN2hSiq2HYl7BNW50W3C+Ey4ARbyCQE1iXPmHeSGoVawyqrmM7eh
X-Received: by 10.224.89.1 with SMTP id c1mr3297248qam.100.1379953771289; Mon, 23 Sep 2013 09:29:31 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id x1sm45269353qai.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 09:29:30 -0700 (PDT)
Message-ID: <52406C6A.6080202@nthpermutation.com>
Date: Mon, 23 Sep 2013 12:29:30 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Juraj Somorovsky 
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de> <52379643.7070705@nthpermutation.com> <523AAA0E.2020105@rub.de> <523DEED6.1060501@nthpermutation.com> <524007E4.5080303@rub.de>
In-Reply-To: <524007E4.5080303@rub.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 16:29:45 -0000

On 9/23/2013 5:20 AM, Juraj Somorovsky wrote:
> On 09/21/2013 09:09 PM, Michael StJohns wrote:
>> Thanks for this.  I think it can be fixed though and relatively simply,
>> but will require changes to the key expansion step that are a bit more
>> than I suggested:
>>
>> E.g. in addition to the master_key, label and random data being fed into
>> the KDF, also feed in - in order for each output key - 2 or 4 bytes each
>> that describe the length of the key.  And that's taken directly from the
>> inputs for the key lengths requested.
>>
>> That means that any time you vary the length of ANY key in the key
>> expansion, the entire key stream changes.
>>
>> It also means that there isn't a need for a separate IV sub key for the
>> key expansion stage (I think....)
> I do not think this is enough to solve this problem. There are
> algorithms that have the same key and IV lengths....e.g. an AES-128 key
> has the same length as the IV used in AES-CBC. I think this would break
> your key derivation???

The general problem here is that pretty much all encryption modes are 
based on ECB - if you can do ECB, you can do the operations that make up 
the mode.

I don't think this is as much of an issue.  The DES key issue was of 
more interest because its substantially easier to brute force 2 keys of 
length 64 than it is a single key of length 128.  This appears to be no 
change in the attack surface to extract the key.



> An additional problem is that the same key would be used for the same
> block ciphers in different modes of operation, e.g. AES-CBC would use
> the same key as AES-GCM.
>
> As mentioned in my previous post, a solution would be to derive the
> material based on the master secret and the encryption scheme / IV it is
> used for. For example you could derive :
> - a symmetric key for AES-GCM:
> k_GCM = PRF(master_secret, "AES_GCM", [further params])
> - a symmetric key for AES-CBC:
> k_CBC = PRF(master_secret, "AES_CBC", [further params])
> - initialization vector:
> IV = PRF(master_secret, "IV", [further params])

The issue with the above approach is that the KDF is currently pretty 
generic - a key plus some public data (e.g. the label, the random 
stuff.  I can't prevent a re-derivation using whatever label the 
attacker wants to use.  So it would be pretty easy to generate either 
k_GCM or k_CBC given the master secret and the random stuff.

But mostly, I don't see this as a large threat  - how would this benefit 
an attacker with access to the master key?

The arguments against CBC tend to be with respect to attacks to recover 
the plain text, not the key.  The question I would ask for the above is 
whether being able to use the same AES key in multiple encryption modes 
provides additional attack surface to recover the key?  If not, then 
it's a don't care for PKCS11 I think.

>
> This solution however assumes that if k_GCM is generated, the attacker
> cannot enforce the PKCS11 module to use it for the AES-CBC computation.
> Again, I am not that familiar with PKCS11...can this be achieved in a
> typical PKCS11 module?
>
> In other words: can a PKCS11 module admin/user enforce that if a
> specific material is derived with a "AES-GCM" parameter, the resulted
> key can only be used in AES-GCM?

The admin can restrict a specific key to a specific set of mechanisms - 
e.g. CKM_AES_GCM.  There are some problems with this approach which 
we're working through having to do with how the restrictions are set and 
how they're retained across derivations.

Mike


>
> Thanks
> Juraj
>


From Kenny.Paterson@rhul.ac.uk  Mon Sep 23 09:51:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F75921F9FEE for ; Mon, 23 Sep 2013 09:51:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN7F2sB1qfQi for ; Mon, 23 Sep 2013 09:51:46 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4813F21F9E70 for ; Mon, 23 Sep 2013 09:51:36 -0700 (PDT)
Received: from mail160-va3-R.bigfish.com (10.7.14.242) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Mon, 23 Sep 2013 16:51:35 +0000
Received: from mail160-va3 (localhost [127.0.0.1])	by mail160-va3-R.bigfish.com (Postfix) with ESMTP id BEFBF4400B2; Mon, 23 Sep 2013 16:51:35 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT004.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: PS-7(zzbb2dI98dI9371I1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah1de097h186068h5eeeK8275bhz2dh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(51704005)(377454003)(479174003)(199002)(189002)(24454002)(243025003)(19580395003)(83322001)(19580405001)(76176001)(36756003)(81542001)(83072001)(65816001)(80976001)(63696002)(56776001)(54316002)(83506001)(15975445006)(74482001)(47446002)(74662001)(74502001)(31966008)(15202345003)(81816001)(4396001)(47976001)(47736001)(49866001)(50986001)(56816003)(81686001)(69226001)(74876001)(77982001)(76786001)(76796001)(59766001)(76482001)(79102001)(80022001)(51856001)(66066001)(46102001)(81342001)(74706001)(74366001)(54356001)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB277; H:AMXPR03MB277.eurprd03.prod.outlook.com; CLIP:134.219.227.30; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en; 
Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3 (MessageSwitch) id 1379955093597116_21162; Mon, 23 Sep 2013 16:51:33 +0000 (UTC)
Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.246])	by mail160-va3.bigfish.com (Postfix) with ESMTP id 78A933C0053; Mon, 23 Sep 2013 16:51:33 +0000 (UTC)
Received: from AM2PRD0311HT004.eurprd03.prod.outlook.com (157.56.249.149) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 23 Sep 2013 16:51:33 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AM2PRD0311HT004.eurprd03.prod.outlook.com (10.255.162.39) with Microsoft SMTP Server (TLS) id 14.16.359.1; Mon, 23 Sep 2013 16:51:32 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) with Microsoft SMTP Server (TLS) id 15.0.775.9; Mon, 23 Sep 2013 16:51:31 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com ([10.242.69.140]) by AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.89]) with mapi id 15.00.0775.005; Mon, 23 Sep 2013 16:51:31 +0000
From: "Paterson, Kenny" 
To: Michael StJohns , Juraj Somorovsky 
Thread-Topic: [TLS] TLS and hardware security modules - some issues related to PKCS11
Thread-Index: AQHOsy7JUoLoDGnX60Kfyac6xLAxJ5nJBRiAgAOrHwCAA+WFAIACgDgAgAB31gCAACepgA==
Date: Mon, 23 Sep 2013 16:51:31 +0000
Message-ID: 
In-Reply-To: <52406C6A.6080202@nthpermutation.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [134.219.227.30]
x-forefront-prvs: 09781D4C35
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 16:51:52 -0000

Comments in-line.

On 23/09/2013 17:29, "Michael StJohns"  wrote:

>On 9/23/2013 5:20 AM, Juraj Somorovsky wrote:
>> On 09/21/2013 09:09 PM, Michael StJohns wrote:
>>> Thanks for this.  I think it can be fixed though and relatively simply,
>>> but will require changes to the key expansion step that are a bit more
>>> than I suggested:
>>>
>>> E.g. in addition to the master_key, label and random data being fed
>>>into
>>> the KDF, also feed in - in order for each output key - 2 or 4 bytes
>>>each
>>> that describe the length of the key.  And that's taken directly from
>>>the
>>> inputs for the key lengths requested.
>>>
>>> That means that any time you vary the length of ANY key in the key
>>> expansion, the entire key stream changes.
>>>
>>> It also means that there isn't a need for a separate IV sub key for the
>>> key expansion stage (I think....)
>> I do not think this is enough to solve this problem. There are
>> algorithms that have the same key and IV lengths....e.g. an AES-128 key
>> has the same length as the IV used in AES-CBC. I think this would break
>> your key derivation???
>
>The general problem here is that pretty much all encryption modes are
>based on ECB - if you can do ECB, you can do the operations that make up
>the mode.
>
>I don't think this is as much of an issue.  The DES key issue was of
>more interest because its substantially easier to brute force 2 keys of
>length 64 than it is a single key of length 128.  This appears to be no
>change in the attack surface to extract the key.
>

Agreed. But this is not the only attack of interest. See below.


>> An additional problem is that the same key would be used for the same
>> block ciphers in different modes of operation, e.g. AES-CBC would use
>> the same key as AES-GCM.
>>
>> As mentioned in my previous post, a solution would be to derive the
>> material based on the master secret and the encryption scheme / IV it is
>> used for. For example you could derive :
>> - a symmetric key for AES-GCM:
>> k_GCM =3D PRF(master_secret, "AES_GCM", [further params])
>> - a symmetric key for AES-CBC:
>> k_CBC =3D PRF(master_secret, "AES_CBC", [further params])
>> - initialization vector:
>> IV =3D PRF(master_secret, "IV", [further params])
>
>The issue with the above approach is that the KDF is currently pretty
>generic - a key plus some public data (e.g. the label, the random
>stuff.  I can't prevent a re-derivation using whatever label the
>attacker wants to use.  So it would be pretty easy to generate either
>k_GCM or k_CBC given the master secret and the random stuff.
>
>But mostly, I don't see this as a large threat  - how would this benefit
>an attacker with access to the master key?

Juraj was too polite to point out this paper from NDSS 2013:

http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf


for an example of what can go wrong when the same key is used in two
different modes one of which
is subject to plaintext recovery attacks (full disclosure: Juraj and I are
co-authors on this paper along
with Tibor Jager).

TL;DR: you can recover low entropy GCM plaintexts if the same key is used
in a mode like CBC.

>The arguments against CBC tend to be with respect to attacks to recover
>the plain text, not the key.  The question I would ask for the above is
>whether being able to use the same AES key in multiple encryption modes
>provides additional attack surface to recover the key?

Not as far as we know. But if I can recover your AES-GCM plaintext,
wouldn't you
just be a little bit concerned?


>If not, then=20
>it's a don't care for PKCS11 I think.

So, do you care now? :-)

Cheers,

Kenny



From mike-list@pobox.com  Mon Sep 23 11:18:36 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43E111E80EA for ; Mon, 23 Sep 2013 11:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level: 
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aABI74O35e6w for ; Mon, 23 Sep 2013 11:18:32 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D725A21F9F3A for ; Mon, 23 Sep 2013 11:18:28 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F26B2D58C; Mon, 23 Sep 2013 14:18:26 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=iuA+1+q8kjcL ITXh3VntazRlMpI=; b=Cd3IdOh69CfNWDnsudr7/BT+q2OawyT4ZGJqiGnpkkgG bkG4PfaEQg7w3tus8xwmgAR7Tmhq9FD8l8xBmNh7PnjkNfdKNZ7flg6ml5nGEU+a hQit22O1yKLicka705+wZVBoNq+kPIkBtiFW83kM/NeSz/yBLv3LSTyUW2TfFh8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=iZeWtN flnjjLmljQdZTqBPVBgpXph3uDagaktr7EciN/opabgzWzCEj4Jqvcs1wLi+Bl/1 nz3LoUogMd5s4OQr3qqpxEAWT8OvbHV/qjipK1YmHEzerFkodvfKDllPHmecUTYS 8FN8sRBUPPnrFTurVzMx8NukXazyDS6UTtRwM=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E3530D58B; Mon, 23 Sep 2013 14:18:26 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 3F446D58A; Mon, 23 Sep 2013 14:18:26 -0400 (EDT)
Message-ID: <524085F1.4080700@pobox.com>
Date: Mon, 23 Sep 2013 11:18:25 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Michael StJohns 
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de>	<52379643.7070705@nthpermutation.com> <523AAA0E.2020105@rub.de>	<523DEED6.1060501@nthpermutation.com> <524007E4.5080303@rub.de> <52406C6A.6080202@nthpermutation.com>
In-Reply-To: <52406C6A.6080202@nthpermutation.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 8A3248F2-247C-11E3-81B7-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 18:18:36 -0000

I've been trying to follow this discussion and it appears to me that the
goal is to have a HSM that protects the master secret and session keys
internally, yet also allows for extractors to ask the HSM to run the PRF
for them.  The problem is that a naive HSM might be tricked into revealing
the session keys.

Couldn't this be dealt with by having the HSM simply refuse to compute the
PRF given a label of "key expansion"?  Any other label should cause the
output to differ wildly from the session keys, right?

Mike

From nico@cryptonector.com  Mon Sep 23 13:27:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350AA21F9D2E for ; Mon, 23 Sep 2013 13:27:28 -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=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLX9U6GPswNu for ; Mon, 23 Sep 2013 13:27:22 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 618C121F9D3B for ; Mon, 23 Sep 2013 13:27:22 -0700 (PDT)
Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id B0FF11DE155 for ; Mon, 23 Sep 2013 13:23:29 -0700 (PDT)
Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 510F11DE192 for ; Mon, 23 Sep 2013 13:00:36 -0700 (PDT)
Received: by mail-ie0-f169.google.com with SMTP id tp5so7325075ieb.14 for ; Mon, 23 Sep 2013 13:00:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=e48CPQ4SirGJ8sw8mlgfClM7wcs/+dNdupIZamoLdcE=; b=Bapktvn3f/AXnZblNYkn05ewxuZFp5+M/YLHJ1g+7WEtcgdhQdfYDlfMweaL7qH2Zw Bt6ueH1B2pWiIcztVnl0b0cDT7/AivDwokcftwV6bGlqtnxl/A+gR4bMk42QxS4DGSs4 JCGeUalw5lsbynXTcl4cHzwSFE+OF7K6Y1Frkbvg3ysy7mOs9XKbo2Ln4CefloR1grrH V1k2QIM/WamV2s4IU9XT4Kj9CMvjvj/RtWDBAatD4ezZxHdXksfiRlnbxzdmQYffgdqj Z/q/WHI7pMFAJNfuDbkZjo8+XBRot4ZKFzFuS8RYGoTlT4DS9APVAF3BJinLiRTMGJNz jugQ==
MIME-Version: 1.0
X-Received: by 10.42.250.201 with SMTP id mp9mr15172827icb.0.1379966435436; Mon, 23 Sep 2013 13:00:35 -0700 (PDT)
Received: by 10.64.128.225 with HTTP; Mon, 23 Sep 2013 13:00:35 -0700 (PDT)
In-Reply-To: <52387927.4030007@nthpermutation.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>
Date: Mon, 23 Sep 2013 15:00:35 -0500
Message-ID: 
From: Nico Williams 
To: Michael StJohns 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 20:27:28 -0000

On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
 wrote:
> On 9/17/2013 8:49 AM, Martin Rex wrote:
>>
>> I fail to understand what you're trying to protect.
>>
>> The master secret of a session is never a secret that is hidding
>> within the hardware module, instead, it is something known to the
>> calling TLS protocol stack and part of the TLS session cache.
>
>
> Um.  No, not if you designed things properly.  It should be possible for any
> protocol the IETF designs to do all the crypto operation inside a hardware
> module and not depend on the weak security of a general purpose computer.

But evidently you must care about the application plaintext.  Why not
move the application into the HSM as well then?

That deserves a tongue-in-cheek smiley, of course :^)

> I want to protect inside of the HSM all of the following:
>
> a) the private keys related to the server or client identity

Sure.

> b) the pre-master key
> c) the master key
> d) the session keys.
>
> I want to be able to do all the cryptographic processing inside that module
> and only allow out true plain text.

Why?  The HSM will become a cryptographic decelerator if you do that,
unless it's a fantastically expensive HSM anyways, and even then there
will be latency costs.  Meanwhile the session keys are of little or no
additional value to the application plaintext, and you're leaving the
application outside the HSM (of course, for obvious reasons).

So why do this?  The one answer that comes to mind is: to make sure
you get the crypto right, without possibility of screwups/backdoors in
various OS components (e.g., RNG).  But the performance cost more than
outweighs that answer in most of the use cases I can think of.

Nico
--

From msj@nthpermutation.com  Mon Sep 23 13:31:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563721F9D56 for ; Mon, 23 Sep 2013 13:31:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRy8GJ+JTKRK for ; Mon, 23 Sep 2013 13:31:11 -0700 (PDT)
Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by ietfa.amsl.com (Postfix) with ESMTP id E797A21F9D3B for ; Mon, 23 Sep 2013 13:31:10 -0700 (PDT)
Received: by mail-yh0-f47.google.com with SMTP id l109so1575965yhq.20 for ; Mon, 23 Sep 2013 13:31:10 -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=P2+EHEk4H6Mz6bKmGUhUCxi4HNVFW2t3nFC7IAz1gPs=; b=S/zpl6Z3MuBrn0ElZuOwsJqozY2IyyvTB+9XazB1AoI7hMREjA+855jWBwmA2gy0j4 XxWjQ1tgtgkobf9Lz7Gs71KOu+b9n2AXksGtMxkNh2491uiTmvqYSM7yFXUTZJicuFeS KSD6zfmLwiBa9Y63dVKHwgHNxq28y/hann30vIjOMuJ5B+2AXcNuQr9SWITa9q9Az7c3 H5q4UaTTSwIhZkivG17VBfKM394cZn9QiYFcoSaVFqUYqoSJDyrpvMEUYAh2Sa9nDOfH D59YhCWxEXBKSIrdMaEP3I0HzNMfRftcsOlL5chhfmEWq6+lzAuaY1Vwo7/V+WT+B2T2 zteQ==
X-Gm-Message-State: ALoCoQnD5NiIWq0XBc64dRxZKGc7wttGWJSyslZw5q3dO8nkhqthRaEYbpZMGU8D5p0brckn4Gpa
X-Received: by 10.236.207.200 with SMTP id n48mr2009492yho.99.1379968249425; Mon, 23 Sep 2013 13:30:49 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id 9sm38816753yhd.19.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:30:48 -0700 (PDT)
Message-ID: <5240A4F9.2020308@nthpermutation.com>
Date: Mon, 23 Sep 2013 16:30:49 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Paterson, Kenny" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 20:31:16 -0000

Comments in line.  Previous text omitted.

On 9/23/2013 12:51 PM, Paterson, Kenny wrote:
> Comments in-line.
>
> On 23/09/2013 17:29, "Michael StJohns"  wrote:
>
>>
>> I don't think this is as much of an issue.  The DES key issue was of
>> more interest because its substantially easier to brute force 2 keys of
>> length 64 than it is a single key of length 128.  This appears to be no
>> change in the attack surface to extract the key.
>>
> Agreed. But this is not the only attack of interest. See below.
>
>
>>
>> But mostly, I don't see this as a large threat  - how would this benefit
>> an attacker with access to the master key?
> Juraj was too polite to point out this paper from NDSS 2013:
>
> http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf
>
>
> for an example of what can go wrong when the same key is used in two
> different modes one of which
> is subject to plaintext recovery attacks (full disclosure: Juraj and I are
> co-authors on this paper along
> with Tibor Jager).
>
> TL;DR: you can recover low entropy GCM plaintexts if the same key is used
> in a mode like CBC.

Right.  But you can't recover the key.

Let me reiterate the threat model:

1) All keys are kept in an HSM (not supposed to be extracted - but TLS 
KDF trivially allows this)
2) Attacker has access to use the keys (e.g. either has HSM credentials, 
or has hacked the program using the HSM that has HSM credentials - the 
TLS stack for example).

Because of (2), the attacker can directly decrypt the cipher text (or 
already has access to the plain text), so an attack where I can force 
the HSM to use multiple cipher modes for the same key is no worse than 
what's already happening.  I'm trying to prevent key recovery attacks 
with this change, NOT plaintext recovery attacks.

I agree that it would be useful to prevent (by HSM policy) a key from 
being used with both CBC and GCM, but the actual threat is a protocol 
one, rather than solely an HSM one assuming the attacker already has 
access to use the key in the HSM.  PKCS11 *does* have some of this, but 
it turns out that its difficult to employ on derived keys (e.g. by ECDH, 
DH or by KDFs) in a manner that prevents attacks based on re-derivation 
of the key.

In some respect,  the selection of IVs for GCM - e.g. no repeats - could 
be viewed as an HSM problem (rather than a protocol problem), but the 
HSM may not (and generally does not) have knowledge of each and every 
previously IV used with the key.  The current PKCS11 API doesn't 
actually provide for the ability to have the HSM link the IV state to 
the key used to the encryption mode - it's one of the things we're 
considering for 3.0 though.

Right now I'm trying to deal with the wide range of problems a piece at 
a time.  In this case, the TLS KDF mechanism has substantial challenges 
with being implemented securely in an HSM - unless the HSM is really a 
TLS accelerator and all the TLS negotiation  and encryption is done 
inside the HSM.  That's one implementation choice - but PKCS11 is 
defined for a more general model where it can be plugged in to support 
lots of different protocols.

>
>> The arguments against CBC tend to be with respect to attacks to recover
>> the plain text, not the key.  The question I would ask for the above is
>> whether being able to use the same AES key in multiple encryption modes
>> provides additional attack surface to recover the key?
> Not as far as we know. But if I can recover your AES-GCM plaintext,
> wouldn't you
> just be a little bit concerned?

See above.

>
>
>> If not, then
>> it's a don't care for PKCS11 I think.
> So, do you care now? :-)

Still no I think.

Mike

>
> Cheers,
>
> Kenny
>
>
>
>


From msj@nthpermutation.com  Mon Sep 23 13:31:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34321F9D5D for ; Mon, 23 Sep 2013 13:31:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TA1TR8CNbC1 for ; Mon, 23 Sep 2013 13:31:14 -0700 (PDT)
Received: from mail-qe0-f51.google.com (mail-qe0-f51.google.com [209.85.128.51]) by ietfa.amsl.com (Postfix) with ESMTP id 00F7E21F9D53 for ; Mon, 23 Sep 2013 13:31:13 -0700 (PDT)
Received: by mail-qe0-f51.google.com with SMTP id ne12so2519422qeb.38 for ; Mon, 23 Sep 2013 13:31:13 -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=1OOCpCmkVBi/JCwXKNrFpVUhTXy4ZEnh/RwoyQzqKlU=; b=ED9nFgF/P6OD8VnkmPbRULA3tCyFI7CIyuDCJaxiXOZu0EKK2PKWmT+/jT7ksew0js cEXzizQy+L3HNf3nPKjrrpZAUq6bKNJXumCh5FyCyJ6aNkDClikGcH1/a6tGLbrgcYi8 mjFP052mJ3OBcosy18UIpGTYqfpiYm037iM8DGBRDKD31qCDnYhbf3CNzdDFxrNyhlwj P1mhtboeMkwnHki+fXYmiRuXtRfFJxPdElsd/5XsJGBGJif0FYL55C6QKE1ur/OMXkso iKnPPwzBzQ0J4F8JY9iBb+BDOtEnYUOHOUr0076XRt/t7Lci7wIKpQJwFDz95CL8VjDx x+mg==
X-Gm-Message-State: ALoCoQlxibypgFcKQMZKOVKuThRyA9ZP8aTQ5JU89Rl9QYPkVNFJUgj471tDO5g+RUdcLNMBRqAq
X-Received: by 10.229.191.7 with SMTP id dk7mr32465792qcb.4.1379968273348; Mon, 23 Sep 2013 13:31:13 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id d3sm47074030qad.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:31:12 -0700 (PDT)
Message-ID: <5240A511.1040206@nthpermutation.com>
Date: Mon, 23 Sep 2013 16:31:13 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "Paterson, Kenny" 
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 20:31:19 -0000

On 9/23/2013 12:51 PM, Paterson, Kenny wrote:
> Juraj was too polite to point out this paper from NDSS 2013:
>
> http://www.isg.rhul.ac.uk/~kp/BackwardsCompatibilityAttacks.pdf

By the way - nice paper.

Mike


From msj@nthpermutation.com  Mon Sep 23 13:47:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3810F21F9E69 for ; Mon, 23 Sep 2013 13:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.441
X-Spam-Level: 
X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V093RUS-eS5f for ; Mon, 23 Sep 2013 13:47:45 -0700 (PDT)
Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 343AB21F9D74 for ; Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
Received: by mail-qa0-f46.google.com with SMTP id j7so1884975qaq.12 for ; Mon, 23 Sep 2013 13:47: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=TH+vrfloit1EihkDhlEBaIqBDbi4bi4yaMj1Ydr7Ir4=; b=EVJGSnJmSNQt/ih3lAg9b9ie/WCSe64oYmTkkIp2nad18XRCwt7xHuoVJxsIOsWgSS uX3us+XywX5hFo1PMoCQy4U4OEpafqKm+Jio0VxiPbcC0GKvM6AfDwtB0hcXBbica/Wz YKjWv0WkwDRuTZXHbAViz0Y+DvzewdpxSZNFZB6yDFg24fTVfa15ERpsrh+6cbVnBL+f 4n3sVbbO72u88MlH5pFL0SOS7dVCgoria4MdnRs9BGU9QA1bE74Stc6cmBpxswhwGOvs Hsxbm/X57Uia6ucTWr/LE571jwlVwz+UGT5yn3tpJyDUJW3aYaYR4XPn5KNaz2hBaP+P n5Ag==
X-Gm-Message-State: ALoCoQmQd0wbmsrNV0Q8tIVRwT2OXGzk0SNy4oqG5KE8izb7qFAiCx98a9x3jgK1ThU3/hPPN5Qq
X-Received: by 10.224.157.14 with SMTP id z14mr4546959qaw.90.1379969264442; Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id i4sm47208902qan.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:47:44 -0700 (PDT)
Message-ID: <5240A8F0.2020001@nthpermutation.com>
Date: Mon, 23 Sep 2013 16:47:44 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nico Williams 
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 20:47:51 -0000

On 9/23/2013 4:00 PM, Nico Williams wrote:
> On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
>  wrote:
>> On 9/17/2013 8:49 AM, Martin Rex wrote:
>>> I fail to understand what you're trying to protect.
>>>
>>> The master secret of a session is never a secret that is hidding
>>> within the hardware module, instead, it is something known to the
>>> calling TLS protocol stack and part of the TLS session cache.
>>
>> Um.  No, not if you designed things properly.  It should be possible for any
>> protocol the IETF designs to do all the crypto operation inside a hardware
>> module and not depend on the weak security of a general purpose computer.
> But evidently you must care about the application plaintext.  Why not
> move the application into the HSM as well then?
>
> That deserves a tongue-in-cheek smiley, of course :^)

There are SSL/TLS accelerators that move a whole bunch more of the 
crypto stuff inside the HSM, but PKCS11 is designed to be useful for 
more than just TLS.

>
>> I want to protect inside of the HSM all of the following:
>>
>> a) the private keys related to the server or client identity
> Sure.
>
>> b) the pre-master key
>> c) the master key
>> d) the session keys.
>>
>> I want to be able to do all the cryptographic processing inside that module
>> and only allow out true plain text.
> Why?  The HSM will become a cryptographic decelerator if you do that,
> unless it's a fantastically expensive HSM anyways, and even then there
> will be latency costs.  Meanwhile the session keys are of little or no
> additional value to the application plaintext, and you're leaving the
> application outside the HSM (of course, for obvious reasons).
>
> So why do this?  The one answer that comes to mind is: to make sure
> you get the crypto right, without possibility of screwups/backdoors in
> various OS components (e.g., RNG).  But the performance cost more than
> outweighs that answer in most of the use cases I can think of.

Consider a specific field of use - 10s of Millions of smart grid capable 
electric power meters.  Consider that I have a back office system that 
talks to each and every one of them securely.  Consider that I'm worried 
about insider threats with respect to reading and controlling (e.g. 
remote disconnection of the meters) these devices.  Consider that I 
never ever ever want a control key to be present outside of an HSM in 
plaintext form.  Consider that some smart grid technologies are using 
TLS as the sole credential layer for controlling substantial amounts of 
power.

For TLS, I agree with you about performance, BUT, security is always a 
tradeoff with performance.  I may not always want to keep the session 
keys inside the HSM, but there are some times that prudence and good 
practice require this.

TLS should be designed so this is possible.  I believe it currently has 
a limitation that makes this goal difficult or impossible to achieve.


Mike

>
> Nico
> --
>
>


From msj@nthpermutation.com  Mon Sep 23 14:00:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0592A21F9E8B for ; Mon, 23 Sep 2013 14:00:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level: 
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPfmF9GlQBA1 for ; Mon, 23 Sep 2013 14:00:04 -0700 (PDT)
Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47621F9E5A for ; Mon, 23 Sep 2013 14:00:03 -0700 (PDT)
Received: by mail-qa0-f48.google.com with SMTP id hu16so1913672qab.14 for ; Mon, 23 Sep 2013 14:00:03 -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=UXxceapIXvsfmMCFdttkJih/8S/sGVGZLvR67LpH53g=; b=XlM2Dl/kNNpSmmOxWH5+6wWMZdccy+7d3C30ODKGsvWdSSueaDAvs1912Fyh//uYnu XM5E3D2onF8KRR837v+M3jqQ76aCiVK2Wjd0ogsDbzYOym3L6jYHbjkVs8mOwZHmlhKC BCi8V0ma6zwHUjLmVmFsCIx/ey8s8nFY5CcFTB6GvYopAYwRPg+ZMAjCkQdcPQmiOW+8 fR+DFzV1mJDftsbkO01gSYmpE8hBk/2CaYM/wp3OAuj1MLGcbPhihFDEa91/lxBTsORl 0fQ+uYVFzpjFlGZ02Jl+8r61mOYKJvsDIe9v4q4a7qbZSYfkseDlMi+Pyc64bkNc44RY J+Lw==
X-Gm-Message-State: ALoCoQlrwAYU1aP+97T++SdyfA9k2Z8QeCWyC2XZOsHrh5q8rvie8vxtx336EZRSD8UxrReIm5/o
X-Received: by 10.224.98.200 with SMTP id r8mr26317089qan.26.1379969997812; Mon, 23 Sep 2013 13:59:57 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id y9sm47262064qaj.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 13:59:57 -0700 (PDT)
Message-ID: <5240ABCD.3060804@nthpermutation.com>
Date: Mon, 23 Sep 2013 16:59:57 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Michael D'Errico 
References: <522955BC.8000407@nthpermutation.com> <52378A67.9010903@rub.de>	<52379643.7070705@nthpermutation.com> <523AAA0E.2020105@rub.de>	<523DEED6.1060501@nthpermutation.com> <524007E4.5080303@rub.de> <52406C6A.6080202@nthpermutation.com> <524085F1.4080700@pobox.com>
In-Reply-To: <524085F1.4080700@pobox.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 21:00:10 -0000

On 9/23/2013 2:18 PM, Michael D'Errico wrote:
> I've been trying to follow this discussion and it appears to me that the
> goal is to have a HSM that protects the master secret and session keys
> internally, yet also allows for extractors to ask the HSM to run the PRF
> for them.  The problem is that a naive HSM might be tricked into 
> revealing
> the session keys.
>
> Couldn't this be dealt with by having the HSM simply refuse to compute 
> the
> PRF given a label of "key expansion"?  Any other label should cause the
> output to differ wildly from the session keys, right?
>
> Mike
>
>

Nope.  Even if you restrict this, you still have the problem in that the 
mac and encryption keys can be caused to "leak" into the part of the key 
stream used for IVs.

I think TLS should have been spec'd with a KDF  and a MAC as distinct 
functions rather than as simple composites of the PRF function.  Also 
using the master secret both as the secret to the KDF  (key expansion) 
and to the MAC (finish message integrity tag) has some issues as well 
(not cryptographically, but in getting a PKCS11 module to enforce use 
separation on the key).

The actual way we dealt with your comment above in PKCS11 v2.40 was to 
deprecate the PRF function from direct use, create a TLS KDF function 
(which could be used with any label and random and produced only keys - 
and the IVs) and create a TLS MAC function (which internally used only 
the two server and client finish message labels and didn't allow any 
others) which produces the public integrity tag.

Because of the IV leaking problem and because the AEAD ciphers still 
require the production of an IV through the TLS PRF, we created a second 
KDF function which *doesn't* produce IV material.  That at least allowed 
a specific key to be marked so that it wasn't subject to the key 
extraction through the IV attack.

Mike




From nico@cryptonector.com  Mon Sep 23 16:01:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D18A21F9E62 for ; Mon, 23 Sep 2013 16:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.82
X-Spam-Level: 
X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[AWL=-0.158,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FPzis+Kh362 for ; Mon, 23 Sep 2013 16:01:13 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id DED1D21F9E50 for ; Mon, 23 Sep 2013 16:01:12 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 1579D200D300C;  Mon, 23 Sep 2013 16:01:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=idrjtbPLQ0a2xd 7vA4wGHOppSio=; b=YbVT5RO7N30wT6sJEtJs/m6HXFRUivKEFIVLLKT69W5Xvk cLBXdJ1NxgK9rqepKriTEg9tfL/G/GJQIKJUa5nVCb09iAw12XzWF06/3NdQGMbx FM7Y9NG5NbarQpM7e3Xqpv8NdZBe49gLPdTWEn/hMQJ28SD3/I9FTg2Ds4tbk=
Received: from gmail.com (unknown [186.136.131.234]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 004FF200D3005; Mon, 23 Sep 2013 16:01:04 -0700 (PDT)
Date: Mon, 23 Sep 2013 18:00:58 -0500
From: Nico Williams 
To: Michael StJohns 
Message-ID: <20130923230057.GB15037@gmail.com>
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>  <5240A8F0.2020001@nthpermutation.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5240A8F0.2020001@nthpermutation.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 23:01:18 -0000

On Mon, Sep 23, 2013 at 04:47:44PM -0400, Michael StJohns wrote:
> On 9/23/2013 4:00 PM, Nico Williams wrote:
> >On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
> > wrote:
> >
> >But evidently you must care about the application plaintext.  Why not
> >move the application into the HSM as well then?
> >
> >That deserves a tongue-in-cheek smiley, of course :^)
> 
> There are SSL/TLS accelerators that move a whole bunch more of the
> crypto stuff inside the HSM, but PKCS11 is designed to be useful for
> more than just TLS.

That's not responsive though.  The fundamental question is: why should
anyone treat session keys as more valuable than the plaintext they are
used to protect?

I think there is an acceptable answer, namely: where the TLS (or
whatever) channel carries some data that is not trusted and where you
want privilege separation, and where you really just don't trust the
hardware furnishing the plaintext.  But you kinda have to say that
that's what you're after, and then consider other issues that come up as
a result.  For example, you might actually need a significant part of
your application to live in the HSM.

> Consider a specific field of use - 10s of Millions of smart grid
> capable electric power meters.  Consider that I have a back office
> system that talks to each and every one of them securely.  Consider
> that I'm worried about insider threats with respect to reading and
> controlling (e.g. remote disconnection of the meters) these devices.
> Consider that I never ever ever want a control key to be present
> outside of an HSM in plaintext form.  Consider that some smart grid
> technologies are using TLS as the sole credential layer for
> controlling substantial amounts of power.

I've considered these things.  See above.

> TLS should be designed so this is possible.  I believe it currently
> has a limitation that makes this goal difficult or impossible to
> achieve.

Or you could design a better HSM.  Why isn't that an answer?  PKCS#11
may not be the hammer that you're looking for.

Nico
-- 

From pgut001@cs.auckland.ac.nz  Mon Sep 23 21:45:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795A521F9385 for ; Mon, 23 Sep 2013 21:45:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpRdk6ST5iVu for ; Mon, 23 Sep 2013 21:45:36 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3C121F8D90 for ; Mon, 23 Sep 2013 21:45:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379997935; x=1411533935; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=t1PiqpYD2k/L70WuBFfU223NsF5f5UqixbVL6dDujCc=; b=Hf1Zraby/WV6q1f1QLSjZeEzy/bw11xuTFF1BVNqy3tPchJew8Epcq2L c+drdOoAg+lRcvRuq3SCS/ySMclWNj7qWi4pF4PEX3nTI5q8neV8ptM8/ 2mjcyETXXP162l2wxEhG4blgAlM6Z+y481NmkbHUYejuA3q4bf2NYvaWL k=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213846775"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 16:45:32 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 16:45:31 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac644OZtN2dnW93GRayVY4eMNcQBdA==
Date: Tue, 24 Sep 2013 04:45:31 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355676085@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 04:45:44 -0000

Yaron Sheffer  writes:=0A=
=0A=
>- Does any of this brittleness still apply when talking about ECDH (as=0A=
>opposed to ECDSA), with fixed parameters?=0A=
=0A=
Probably not, in terms of brittleness.  But then if you're using fixed ECDH=
=0A=
parameters (rather than, say, regenerating them once an hour and discarding=
=0A=
the old ones) you've got potentially NSA-influenced values like P256 that t=
he=0A=
NSA has been awfully keen to get everyone to use, and that even without NSA=
=0A=
skullduggery make a nice single target for attack.  So that's an entirely=
=0A=
different problem.=0A=
=0A=
If you do want to generate your own ECDH parameters (i.e. curves), that's=
=0A=
another huge mess to deal with.  For DH you just use Lim-Lee and you're don=
e=0A=
(although the fact that TLS doesn't communicate the 'q' value is something =
I'd=0A=
really like to see corrected), while for ECC you need to get an awful lot o=
f=0A=
special-case checks and conditions just right.=0A=
=0A=
Then, once you've done that, you get to find out how many implementations=
=0A=
support the arbitrary_explicit_prime_curves format, which I suspect is pret=
ty=0A=
close to zero.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Mon Sep 23 21:52:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E48F21F9C9B for ; Mon, 23 Sep 2013 21:52:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZLMBaYw5Cix for ; Mon, 23 Sep 2013 21:52:46 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9992D21F99E7 for ; Mon, 23 Sep 2013 21:52:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379998366; x=1411534366; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=86lSi61AfLSU/FkpjUN3xFDzoo1YLDBm2h/SouqgA88=; b=T0631YqKBCFzkb2j/0ufvZWM87eUMhCo4QoCgiAzs+ogOuAXdYsl/+Hm Qe2jORJ2RV/OU9Y0J6DtlVbDfB+Dojz3nUqCriFrCfq3wLCraMBfIcb0r I0AjQWodbUsq464MfzWkpDF/VjTad4kvVfqYNvb4ntyA00rWd+OaQpSsI U=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213848518"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 16:52:43 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 16:52:42 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac644ec6SWGYiizlRSe+ZS0RmDI5Jw==
Date: Tue, 24 Sep 2013 04:52:42 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C7355676092@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 04:52:51 -0000

Nikos Mavrogiannopoulos  writes:=0A=
=0A=
>The innovate refers to how the current EtA proposal by Peter ignores all b=
est=0A=
>practices in implementing EtA in protocols.=0A=
=0A=
You seem to be saying there that HMAC has security problems unless it's=0A=
truncated, which is something that AFAIK no other cryptographer has ever=0A=
noticed.  Perhaps you could clarify the weakness for the list, and then=0A=
consider publishing a conference paper on it.  It sounds like an amazing=0A=
breakthrough in the cryptanalysis of HMAC.=0A=
=0A=
>Existing EtA protocols like IPSec truncate the HMAC to avoid revealing the=
=0A=
>whole internal state of the hash algorithm.=0A=
=0A=
S/MIME doesn't truncate it.  TLS doesn't truncate it.  PGP (although that=
=0A=
doesn't really use a MAC, but still...) doesn't truncate it.=0A=
=0A=
In any case TLS has, for some years now, allowed for truncated MACs.  If=0A=
anyone really feels this is an issue, they can use truncated_hmac to requir=
e=0A=
truncation to any length they feel comfortable with.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Mon Sep 23 22:02:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623D821F915C for ; Mon, 23 Sep 2013 22:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.578
X-Spam-Level: 
X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmpYXyP3OKJT for ; Mon, 23 Sep 2013 22:01:59 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id B7BF311E810F for ; Mon, 23 Sep 2013 22:01:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379998902; x=1411534902; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1I/R7D5d26zpfQGrgHrgQfzzgKBXMSiflSeWQEKxPPg=; b=N/fLI+hui2nc50FWkFzpJNkX11BvvSU0MCM1FJnVHFbfQM5Mav6b0+Zf Gj/l+hIoHACdxWMQRSGZd7RVckCFHE9jFokXIKhOk5PJC46B+hdIb15xS NBsSiXefmYDvbcYKnrsCq898Nq0XfRNXQHBkWcy42H/UTJjJIGFvgRGM7 g=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213850200"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 17:01:41 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 17:01:40 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac644yexka+JHcxaQ6OFXY9dkTUeRA==
Date: Tue, 24 Sep 2013 05:01:40 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73556760B8@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 05:02:04 -0000

Eric Rescorla  writes:=0A=
=0A=
>These messages from Nikos look negative to me:=0A=
>http://www.ietf.org/mail-archive/web/tls/current/msg09809.html=0A=
>http://www.ietf.org/mail-archive/web/tls/current/msg09520.html=0A=
=0A=
That's just Nikos complaining (as Ben Laurie put it, "I've seen no objectio=
n=0A=
that makes any sense").  I've just responded to Nikos yet again, see my=0A=
message of a few minutes ago.=0A=
=0A=
>We think this would benefit from F2F discussion and I would invite you or=
=0A=
>someone else in favor of this draft (or another approach) to present in=0A=
>November in Vancouver. If there is WG consensus for this, we can adopt it=
=0A=
>then.=0A=
=0A=
Well if you guys are willing to pay my air fares to Canada to repeat, yet=
=0A=
again, all the stuff that's already been gone through on the list, then I=
=0A=
guess I can do it.=0A=
=0A=
This work has been stalled now since the start of the year.  Nothing else h=
as=0A=
moved forward.  So it's not a matter of chosing between several competing=
=0A=
viable proposals, it's a choice between (A) "adopt a simple fix for a decad=
e-=0A=
old problem that's been repeatedly exploited" and (B) "don't fix the proble=
m,=0A=
allowing further exploitation in the future".=0A=
=0A=
I want to apply the simple fix, and I get the feeling the rest of the WG do=
es=0A=
too.  It appears that the WG chairs don't care about fixing it, or at least=
 in=0A=
nine months they've shown no interest in moving it forward.=0A=
=0A=
So I'd like to adopt Ben's proposal:=0A=
=0A=
  How about we take a vote?=0A=
=0A=
Could people please indicate on the list whether they'd prefer option (A), =
fix=0A=
the problem with EtM, or option (B), which appears to be "do nothing", or a=
t=0A=
least "delay indefinitely", which amounts to the same thing.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Mon Sep 23 22:17:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C6321F9D2E for ; Mon, 23 Sep 2013 22:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.579
X-Spam-Level: 
X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Me0EF55z3SV for ; Mon, 23 Sep 2013 22:17:19 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF1021F9D21 for ; Mon, 23 Sep 2013 22:17:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1379999839; x=1411535839; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=qeILQjKyMgESaisM20VNb8XY3eI/LX+O0CbTfKLTKZc=; b=JA7qlSv3W2aivBhkRrQ8qhGXWB7C9TC81pvK0+f3KehCH7TJ0oTGHcS/ JxjKxXbedtArvVew6C3sFFFVz4iZV7OhGE8p1vl78ku2QjQ1j/1CzQU6v ALhKOyanlIqTi6LDmxgDvJyLgjNg168H1GJVjdqERZkQ/0AMZICnyJ3hg A=;
X-IronPort-AV: E=Sophos;i="4.90,968,1371038400"; d="scan'208";a="213852447"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 24 Sep 2013 17:17:15 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.158]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 17:17:15 +1200
From: Peter Gutmann 
To: "tls@ietf.org" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac645VSjNW2YXHybRmayhq43QBCisg==
Date: Tue, 24 Sep 2013 05:17:14 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 05:17:24 -0000

Just a small amount of Schadenfreude here when I point out that as I was=0A=
reading through the long list of GnuTLS security advisories at=0A=
http://www.gnutls.org/security.html it seems that a number of them would ha=
ve=0A=
been avoided through the use of the EtM that Nikos has been so strongly=0A=
opposed to :-).=0A=
=0A=
Peter.=0A=

From yaronf.ietf@gmail.com  Mon Sep 23 23:30:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7998C21F9C52 for ; Mon, 23 Sep 2013 23:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.465
X-Spam-Level: 
X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uF0oziLFBbEz for ; Mon, 23 Sep 2013 23:30:32 -0700 (PDT)
Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69F21F9C47 for ; Mon, 23 Sep 2013 23:30:32 -0700 (PDT)
Received: by mail-ee0-f45.google.com with SMTP id c50so2224772eek.18 for ; Mon, 23 Sep 2013 23:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QjTIfMiAxVzGfcExiB5pziZeDcd8iwELKT2fB7LRzrM=; b=qre056ch8ad/mXacOgKxmtZVN7BbN6effGlux2AbRd2ov4WIYORT+lbBC+w+DjmF2E 5s+vKJv+5T+bm13YoOXtePGAfW27KxN7Vkxm13rcYGN1G/cS6itvS2mj1zY2+5rRFtqW +thiNDv9PPJInqNeSCZW93sSeywG+N+Kpk+YUmyFb2YyHF0OOMVBOHLKtvlDxNywVP3P SlCzGCaFdL5AwCIPGxsoXvxfWqulTuWHMc7jbBX6dg5MFkDQ/FalHVM1EG2wkJ3dr7y4 69Sn3HoKqXqCTGno7QgFwJfLzZDFasM4yr9PIvnHs74WlUgixPRH4+p6uiUg1RuJK1K0 uJNA==
X-Received: by 10.15.76.68 with SMTP id m44mr202152eey.78.1380004231754; Mon, 23 Sep 2013 23:30:31 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id n48sm49718858eeg.17.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 23:30:31 -0700 (PDT)
Message-ID: <52413186.9000609@gmail.com>
Date: Tue, 24 Sep 2013 09:30:30 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Peter Gutmann , "tls@ietf.org" 
References: <9A043F3CF02CD34C8E74AC1594475C7355676085@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355676085@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 06:30:33 -0000

Just to clarify my sloppy terminology: I was asking about ECDH with 
named curves (which today means P-256 in practice, but in the future 
will allow non-NIST curves, e.g. Brainpool). Of course the "parameters" 
(DH public key) are generated periodically or even on each connection.

Thanks,
	Yaron

On 09/24/2013 07:45 AM, Peter Gutmann wrote:
> Yaron Sheffer  writes:
>
>> - Does any of this brittleness still apply when talking about ECDH (as
>> opposed to ECDSA), with fixed parameters?
>
> Probably not, in terms of brittleness.  But then if you're using fixed ECDH
> parameters (rather than, say, regenerating them once an hour and discarding
> the old ones) you've got potentially NSA-influenced values like P256 that the
> NSA has been awfully keen to get everyone to use, and that even without NSA
> skullduggery make a nice single target for attack.  So that's an entirely
> different problem.
>
> If you do want to generate your own ECDH parameters (i.e. curves), that's
> another huge mess to deal with.  For DH you just use Lim-Lee and you're done
> (although the fact that TLS doesn't communicate the 'q' value is something I'd
> really like to see corrected), while for ECC you need to get an awful lot of
> special-case checks and conditions just right.
>
> Then, once you've done that, you get to find out how many implementations
> support the arbitrary_explicit_prime_curves format, which I suspect is pretty
> close to zero.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From n.mavrogiannopoulos@gmail.com  Tue Sep 24 01:06:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B239021F9CCA for ; Tue, 24 Sep 2013 01:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level: 
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.177,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSpyDO1wVSt1 for ; Tue, 24 Sep 2013 01:06:27 -0700 (PDT)
Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id AAAB621F9C33 for ; Tue, 24 Sep 2013 01:06:17 -0700 (PDT)
Received: by mail-ea0-f175.google.com with SMTP id m14so2249561eaj.6 for ; Tue, 24 Sep 2013 01:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=jtY8CLX/7lRkYEpRoRr6MEH15/BUJcrCYxz3dFUZMsY=; b=c8mhxqoaT+KkkRxHtFOCUCkAhI2MyIWRh/sO7UVPknVfdXD0wW+woO0jfsegvitqOS OWwyqjyDSdgVhrRSHanNGRvc0lDzhb1g0qmC4aq2Ru+cp47n4JGjK/ep+18ceHJ/pHV2 lteV+RX+F7RoFvCXHxp1GPg0Sy1+x1guLSW9iFfh7u7FOYqd8w9scBNPAmn8NkDUVUlj fSOQr+oT5qwRW6Q7v93EBzFF2yvMhMHhfjGC6LQ998IDCK0QJa2BnzANy5GchhYFp/zu mhJN9E0p5CQYvkWtCT0nI0Q0IE9DZZMquoWujobFWWVGbAE+XJNAoWPPB/qsXjlWziLB iOIQ==
X-Received: by 10.15.42.70 with SMTP id t46mr1892844eev.58.1380009975025; Tue, 24 Sep 2013 01:06:15 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id a1sm50555602eem.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 01:06:14 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <524147F0.1040507@gnutls.org>
Date: Tue, 24 Sep 2013 10:06:08 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C7355676092@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355676092@uxcn10-6.UoA.auckland.ac.nz>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 08:06:36 -0000

On 09/24/2013 06:52 AM, Peter Gutmann wrote:

>> The innovate refers to how the current EtA proposal by Peter 
>> ignores all best practices in implementing EtA in protocols.
> You seem to be saying there that HMAC has security problems unless 
> it's truncated, which is something that AFAIK no other cryptographer 
> has ever noticed.  Perhaps you could clarify the weakness for the 
> list, and then consider publishing a conference paper on it.  It 
> sounds like an amazing breakthrough in the cryptanalysis of HMAC.

No I am not saying that and please do not twist my words to make a
point. I say that best current practice in protocols is to follow the
Preneel-van-Oorschot advice and do a truncation on the hash-based-mac to
prevent certain attacks (described in their paper). You do not follow
this advice on your proposal and you give no reasons why.

The only reason I've heard against truncation is some story you repeat
about IP headers space. Both the IPSec RFCs and people who participated
in the discussions say otherwise, and thus make your claim not convincing.

I may be wrong and truncation may not be needed, but you give not
convincing reasons why.

>> Existing EtA protocols like IPSec truncate the HMAC to avoid 
>> revealing the whole internal state of the hash algorithm.
> S/MIME doesn't truncate it.  TLS doesn't truncate it.  PGP (although 
> that doesn't really use a MAC, but still...) doesn't truncate it.

TLS doesn't truncate it because it uses the AtE mode which means it is
encrypted (and thus the simple hash-based-MAC attacks don't directly
apply). S/MIME and PGP aren't online protocols and use the MAC key for a
single message, thus several attacks don't apply to them.

regards,
Nikos


From n.mavrogiannopoulos@gmail.com  Tue Sep 24 01:09:42 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB421F9CF5 for ; Tue, 24 Sep 2013 01:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.451
X-Spam-Level: 
X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp+eHlybL7QG for ; Tue, 24 Sep 2013 01:09:41 -0700 (PDT)
Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0C821F9CF3 for ; Tue, 24 Sep 2013 01:09:41 -0700 (PDT)
Received: by mail-ea0-f178.google.com with SMTP id a15so2263742eae.23 for ; Tue, 24 Sep 2013 01:09:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=LKP8swsVXvcmkgn87xOYvSFhAn6Mwm7j1tU+tujxqLk=; b=OAd9JSAAxtwna7Tlf1JLJlGkizt0GNYBfc3Ywq5kZShBSx9xSLGj610qbmrJYe9zH6 jfjD1U/IuCfRKkk1O1X0wFUuJDJ4OP5Xa0A8fXFmfMfzEzgF/PF0uftziPWZ2r/LW2+c OFbZy8UCahMqiJgBK0knrnZwoENvuCIulvxQ0l9kwcVno0U4iKM64LA5yqQ+iTHyQyi2 BcRk0fulr+sADCyXtgCObRMvwL1UIjKBNiyg6QUHdnODygszwmkuqeLtcnaK52El/Vjl GJNBpnC1fO+OjthPBA0Wd9AUfPvgW/1OYlhnQPQqgcKWNTr79zEHjKpYMJ+30IAyTmkt Qxwg==
X-Received: by 10.14.181.194 with SMTP id l42mr1581440eem.63.1380010180595; Tue, 24 Sep 2013 01:09:40 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id k7sm50556284eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 01:09:40 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <524148C3.7090709@gnutls.org>
Date: Tue, 24 Sep 2013 10:09:39 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz>
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 08:09:42 -0000

On 09/24/2013 07:17 AM, Peter Gutmann wrote:
> Just a small amount of Schadenfreude here when I point out that as I was
> reading through the long list of GnuTLS security advisories at
> http://www.gnutls.org/security.html it seems that a number of them would have
> been avoided through the use of the EtM that Nikos has been so strongly
> opposed to :-).

I don't understand what does this prove. I was one of the first to ask
for a solution to the issue. Pointing an issue in your draft doesn't
mean I'm against solving the problem.

regards,
Nikos


From benl@google.com  Tue Sep 24 03:24:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9D621E805F for ; Tue, 24 Sep 2013 03:24:20 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwXRsPJZKE4P for ; Tue, 24 Sep 2013 03:24:19 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4420521E8056 for ; Tue, 24 Sep 2013 03:24:19 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so8866416iec.30 for ; Tue, 24 Sep 2013 03:24:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XJBDM/Cb9nTev8e2yI9ZsXgNt864FvgFF25k7Ax6GWc=; b=Ai5EjoAoK4Ckw8DM3ea1RpiJLZrhulROqg4TOzSRnucNOr3Tj+D2Yf1YoVz3hUuDQz toKIf6yZcXvjMS8SNtq6b1RKDbfxkLtyZ8uHACgPpfj1fO+z1nQNl0Zki1wAQEkZgfJr U8rfOf9V2Q5K2hvwWfreVO1bQmalRj0+GDP4eDHHf2yP2r9/+hn+fN+d2mgK8NoKuq8S UjwuqFXF2ggPnCbG7u4ujt0sAiksVtSOBN1ArredvrL48AZesiY1qv5vHRqNML5ncPWc nshLHkyhuM+WvN1WDXPPKf7DtdeWBNLS2R8Hz57L3Jkzr/6o7htgmRmPdhi9JmD/O+8T utXA==
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=XJBDM/Cb9nTev8e2yI9ZsXgNt864FvgFF25k7Ax6GWc=; b=EGq/6gHkFsZ4K1WpeuW8121MkedgCxE9QZr/xWn85PMzH2n3HFE7hKN6O1yx7BMdCg NLih8pPgfC/TXAzSCY461k8AVMxfRKvFeG+bP/ZOesa0TwOiZ6GoQO7Lm0502cpHl9up 99RaWo1XeC7BXP//N31QPLQ+ptzGN6VCk2zJ4a8vXdoJOLnRBNsbkOJ1S2TvrgS/v4c1 DXR7kGdrb0mq6oe4tl9Nkb/Y2YUJZhGDEEsN5nQsWmsl4UBMEL/zugBBAX+MbfIMOsCP jk1SiqpGGpoxsPi4oGxHzdYrXXlJjHY3diCDFmsH23+pqO2uALW/EV26iV6X7E47b9nA 7sVw==
X-Gm-Message-State: ALoCoQmgih+J4zKRGEFFtZ3TWfiSh+dZyGwPPO3FoIgfaxeRwCABp8TKyIiOPB481+bt+VYygJtyAjT796Udk7lhOKNO5ucpAjdOuwJANX4Xr3zH0xmLEF8StcZPO3bDp+ScQAt/JoWHxzaXAmvGG1zmF6qGqmPbYTZPPL8zojOFoPUlGK4QZUpWeoK+8rhuu8IMpCZRZNXq
MIME-Version: 1.0
X-Received: by 10.42.92.84 with SMTP id s20mr8133166icm.63.1380018258674; Tue, 24 Sep 2013 03:24:18 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 03:24:18 -0700 (PDT)
In-Reply-To: <524148C3.7090709@gnutls.org>
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org>
Date: Tue, 24 Sep 2013 11:24:18 +0100
Message-ID: 
From: Ben Laurie 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 10:24:20 -0000

On 24 September 2013 09:09, Nikos Mavrogiannopoulos  wrote:
> On 09/24/2013 07:17 AM, Peter Gutmann wrote:
>> Just a small amount of Schadenfreude here when I point out that as I was
>> reading through the long list of GnuTLS security advisories at
>> http://www.gnutls.org/security.html it seems that a number of them would have
>> been avoided through the use of the EtM that Nikos has been so strongly
>> opposed to :-).
>
> I don't understand what does this prove. I was one of the first to ask
> for a solution to the issue. Pointing an issue in your draft doesn't
> mean I'm against solving the problem.

The issue you claim is that it does not defend against key recovery
attacks. I am not aware of any key recovery attacks against HMAC, and
MAC truncation was not proposed as a countermeasure for a key recovery
attack against any MAC.

Can you provide a reference for your claim?

From simon@josefsson.org  Tue Sep 24 03:39:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D62511E810D for ; Tue, 24 Sep 2013 03:39:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO5lYyCcIOmz for ; Tue, 24 Sep 2013 03:39:08 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF1821F9D19 for ; Tue, 24 Sep 2013 03:39:07 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OAd1Qw004985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 12:39:03 +0200
From: Simon Josefsson 
To: Trevor Perrin 
References:  <0f476a6eb1e64519bb37001b02fddd4c@BLUPR03MB166.namprd03.prod.outlook.com>  <072c2f95d4fe4031bdc1a114a9b810ce@BLUPR03MB166.namprd03.prod.outlook.com>  <159a1a51405047e185633d089b110bfa@BLUPR03MB166.namprd03.prod.outlook.com> 
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:130924:trevp@trevp.net::roqGURU20XGOp8xf:7fv
X-Hashcash: 1:22:130924:maray@microsoft.com::CSdeChXwdOErfd83:6pNq
X-Hashcash: 1:22:130924:tls@ietf.org::p9uBAQh93xGHBB6W:f8iN
Date: Tue, 24 Sep 2013 12:39:01 +0200
In-Reply-To:  (Trevor Perrin's message of "Tue, 17 Sep 2013 17:37:23 -0700")
Message-ID: <87ob7ipkqi.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: "tls@ietf.org" 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 10:39:10 -0000

Trevor Perrin  writes:

> So I'm asking:  Is there a legitimate reason for the community to
> spend time fixing this RFC, implementing it in TLS libraries (it's not
> currently present in any libraries, I believe), and adapting new
> standards to use it?

No.

> If not, can we mark it as "obsoleted" or similar?

+1

/Simon

From n.mavrogiannopoulos@gmail.com  Tue Sep 24 04:26:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB6A411E810B for ; Tue, 24 Sep 2013 04:26:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level: 
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-ibziSdc1B9 for ; Tue, 24 Sep 2013 04:26:27 -0700 (PDT)
Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A6B5611E8104 for ; Tue, 24 Sep 2013 04:26:26 -0700 (PDT)
Received: by mail-ea0-f182.google.com with SMTP id o10so2369146eaj.41 for ; Tue, 24 Sep 2013 04:26:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=C7wYRjehCtr8HVro3v9OrlABrDh7A8qqOg//7pDwi/I=; b=rpVWTV0pXYgeV/9wfvyVJBQ0FkJPPeQso+qeweYdW4KQNwOYen0x/ij2jjFt8CFBMb 4vtRyb0v5EPYAjdydD0Gz5Gle3lWy0AgIVruR1vj/WATs4GPgmFi2MCI5pp266u1Q5CI +YESTIXN/MAPzcUml3M++c6bM5Tz2llIrXPaKCV4MBdCAxb3BmhVHUWj/bCE4kbcnE4n V8iSzsvs4NBEFjnAK8p0OH4Zb34N8SpHb4Uszb9XsjYaMzz42DrdhwO+7dfJIfC13nuQ SQrLFG5h5LzKTRYM5/J75DRcaqOy1O7mVwrjVLEqPk6lN5gQwzPpmMppzHPwmlh6/0NF guqQ==
X-Received: by 10.15.76.68 with SMTP id m44mr2039123eey.78.1380021985712; Tue, 24 Sep 2013 04:26:25 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id d8sm52223106eeh.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 04:26:25 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <524176EA.3090401@gnutls.org>
Date: Tue, 24 Sep 2013 13:26:34 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Ben Laurie 
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 11:26:28 -0000

On 09/24/2013 12:24 PM, Ben Laurie wrote:

>>> Just a small amount of Schadenfreude here when I point out that 
>>> as I was reading through the long list of GnuTLS security 
>>> advisories at http://www.gnutls.org/security.html it seems that a
>>> number of them would have been avoided through the use of the EtM
>>> that Nikos has been so strongly opposed to :-).
>> 
>> I don't understand what does this prove. I was one of the first to
>>  ask for a solution to the issue. Pointing an issue in your draft 
>> doesn't mean I'm against solving the problem.
> 
> The issue you claim is that it does not defend against key recovery 
> attacks. I am not aware of any key recovery attacks against HMAC,
> and MAC truncation was not proposed as a countermeasure for a key 
> recovery attack against any MAC.

Hello Ben,
 I believe it would be better to consult the opinion of an expert on
hash functions and MAC designs. The fact that you (or me for that
matter) don't know something doesn't mean much.

> Can you provide a reference for your claim?

I believe we make circles. I previously referenced IPSec (RFC2104) at:
http://www.ietf.org/mail-archive/web/tls/current/msg09832.html
The same RFC references the Preneel-van-Oorschot paper.

I take your question that you actually read RFC2104 and the
Preneel-van-Oorschot paper and you disagree with their points?

PS. I attach the comment of Bart Preneel on the topic (a cryptographer
with significant expertise on hash functions).

regards,
Nikos

-------- Original Message --------
Subject: Re: truncation of MACs
Date: Tue, 24 Sep 2013 10:51:37 +0200 (CEST)
From: Bart Preneel 
To: Nikos Mavrogiannopoulos 

> As I am not familiar with new trends in MACs may I ask you whether 
> this practice of truncation is still believed to provide benefits?

Nikos,
I hope all is well.

There is a tradeoff: if you output more bits, it becomes
harder to predict the whole string (that is, to forge the MAC)
On the other hand, you release more information about the
internal state, hence attacks based on internal collisions
as discussed in the Crypto '95 paper with Paul van Oorschot
becomes more efficient - in some sense you expose more information
about the secret key.

If we look at the attacks during the last 18 years, it is
clear that no (forgery) attack has found that exploits the
fact that a subset of bits of say HMAC-MD5 is easier to predict
than any other subset or that exploits truncation (except for
a reduced guessing cost). On the other hand, several (key recovery)
attacks on MAC algorithms (including HMAC-MD4 and HMAC-MD5)
have been found based on internal collisions. These attacks
would become more difficult if fewer output bits are available.

I am in general more concerned about key recovery attacks (allowing
an unlimited number of forgeries) than about forgery attacks.

My conclusion is that my intuition as cryptanalyst was correct
and that it would be best to shorten the output of a MAC
algorithm to half the internal state.

Note that many strong designs in the SHA-3 competition are
wide-pipe, which means that the internal state is larger than
the output; this is to preclude multi-collision attacks,
long message second preimage attacks, and herding attacks on
hash functions (these are attacks on hash functions discovered
between 1999 and 2005 that exploit the fact that the output size
is equal to the internal state). There is some solid theory
underpinning these design choices.
Part of the current controversy on the NIST planned draft
for SHA-3 (FIPS 202) is that the Keccak design was wide-pipe
while the planned draft will reduce the internal state to increase
performance.

While hash functions are not exactly the same as MAC algorithms, I
believe that these developments in hash functions go along the
same lines as our recommendations from 1995:
  - new attacks are discovered that exploit the fact that the
    size of the output is equal to the size of the internal state
  - the response is to make designs with internal state equal to
    twice the output state.


I hope that this helps.

Regards,
Bart


From benl@google.com  Tue Sep 24 04:40:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5880F21F963F for ; Tue, 24 Sep 2013 04:40:42 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PG2voQUAXfl for ; Tue, 24 Sep 2013 04:40:41 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 782B921F9642 for ; Tue, 24 Sep 2013 04:40:40 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id ar20so8797813iec.18 for ; Tue, 24 Sep 2013 04:40:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vXLrtIzy3ku9fbMIFsuL+iCBRwk6BmU0pmcl/72TQbc=; b=owj1JES9YABSANFcvDaGfVHpa0zI/6cixp/d5DoTFwytPTbyIL/Mp5VfYqyG3ShJOk Mm4UfghPnt7zxxTxA1od+e5+VmZ08han8Q3ZLeCeltG07iP+nMCf6GwrIC7AI/I4y24b QhvPMKK4E1l4uOHtReq5LA41qTsQwg536B8+OjlgrRVjmCQ+1b8takaj8pn7NdMiKz+v EbtryMTrc3beC0v28eAelZr9j22lL5lx/KY2aiKwyi7Bw/a60ZlMnMuNDcz7AZGctBRx QZVkAXtHcNiqfTSR4NjABUoWmh2/2coOizN/5hTAHXDE+8/mP2IOskZBFrLREcgV6PAA jlSg==
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=vXLrtIzy3ku9fbMIFsuL+iCBRwk6BmU0pmcl/72TQbc=; b=EYIlxzKtFuDJ4zS/XYO2h4OHi+4bKE+IxbRQYoyB4dr9pA+PE0UpMBRbdxz6ybjLpD 3YnZkrqANjHtzgI390LSViwJBFt9lXLeJb9osVlMkL/PaKQOPtl1BZr55HRf2b6AgjB7 UZ991yOTLah3FhO1BFppXAtRB/JusOQ6NTqDHUY+YiU8ORKOfEamksq2QjAOsoSnDt02 KB1oSx3ous2MekkRHBWMDkkWc7sD3TAZkJsbJfEn3G2JFbrOpuUSYWAyTPU6dx1ILx0Z uhQUjCyPbWZJ7I21xRTy/2PP5QkElxmmedASeZB20acCbgG+QRyYGBunIrFuAm7Ox7dg 1AAg==
X-Gm-Message-State: ALoCoQkW8A0zHlmik2sfZ61xikF8m3yv6fRNY9wq1SNAcRUAhvdyQatTj5O0vwZ4vOpGEh7TkjDt4/tHXvdWNOdHXR/oKUiEO0gciyel2viajmyQ/7VDsXrKzoIFiB1wF44TPX85xhwJfixDn1vMdm517dmOGKOHv3EeyliPf2GeUgkQaaxW2gf6+etto4wchertl/CHTz18
MIME-Version: 1.0
X-Received: by 10.42.211.74 with SMTP id gn10mr2452701icb.17.1380022839554; Tue, 24 Sep 2013 04:40:39 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 04:40:39 -0700 (PDT)
In-Reply-To: <524176EA.3090401@gnutls.org>
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org>  <524176EA.3090401@gnutls.org>
Date: Tue, 24 Sep 2013 12:40:39 +0100
Message-ID: 
From: Ben Laurie 
To: Nikos Mavrogiannopoulos 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 11:40:45 -0000

On 24 September 2013 12:26, Nikos Mavrogiannopoulos  wrote:
> On 09/24/2013 12:24 PM, Ben Laurie wrote:
>
>>>> Just a small amount of Schadenfreude here when I point out that
>>>> as I was reading through the long list of GnuTLS security
>>>> advisories at http://www.gnutls.org/security.html it seems that a
>>>> number of them would have been avoided through the use of the EtM
>>>> that Nikos has been so strongly opposed to :-).
>>>
>>> I don't understand what does this prove. I was one of the first to
>>>  ask for a solution to the issue. Pointing an issue in your draft
>>> doesn't mean I'm against solving the problem.
>>
>> The issue you claim is that it does not defend against key recovery
>> attacks. I am not aware of any key recovery attacks against HMAC,
>> and MAC truncation was not proposed as a countermeasure for a key
>> recovery attack against any MAC.
>
> Hello Ben,
>  I believe it would be better to consult the opinion of an expert on
> hash functions and MAC designs. The fact that you (or me for that
> matter) don't know something doesn't mean much.

I have consulted experts. This is why I am puzzled by the objection.

>> Can you provide a reference for your claim?
>
> I believe we make circles. I previously referenced IPSec (RFC2104) at:
> http://www.ietf.org/mail-archive/web/tls/current/msg09832.html
> The same RFC references the Preneel-van-Oorschot paper.
>
> I take your question that you actually read RFC2104 and the
> Preneel-van-Oorschot paper and you disagree with their points?

Actually, I did, and I don't disagree with their points, but I
disagree with _your_ points.

a) The paper describes a collision attack, not a key recovery attack.

b) Step one of the attack is "find a collision". Since that is
impractical, even for (untruncated) HMAC-MD5, hash truncation provides
no useful defence against the attack.

c) In any case, the whole point of the truncation defence is to make
it harder to go from _observing_ a colliding MAC to the ability to
construct more collisions. But it mostly does this by making it easier
to observe MAC collisions.

d) If you _really_ want to defend against this attack, the right
answer is to design hash functions with bigger internal state.


> PS. I attach the comment of Bart Preneel on the topic (a cryptographer
> with significant expertise on hash functions).

In which he says he was right for the wrong reasons. So, you need to
reference the right papers (i.e. the ones that describe key recovery
attacks) so we can evaluate the severity of these attacks. I am not
aware of any even vaguely practical attacks against even HMAC-MD5, let
alone any HMAC we're actually contemplating.

Please present your evidence.

(Incidentally, he also agrees that the right answer is to have larger
internal state, not to truncate. SHA-3 gives us this, right?).

From n.mavrogiannopoulos@gmail.com  Tue Sep 24 05:17:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B23511E811E for ; Tue, 24 Sep 2013 05:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level: 
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-lUnx0ZCDbR for ; Tue, 24 Sep 2013 05:17:34 -0700 (PDT)
Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id B309F11E8110 for ; Tue, 24 Sep 2013 05:17:33 -0700 (PDT)
Received: by mail-ea0-f179.google.com with SMTP id b10so2395005eae.24 for ; Tue, 24 Sep 2013 05:17:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:openpgp:content-type :content-transfer-encoding; bh=qCsuUgsQqbiMeAEUhysvRmjwi1gFC6Ero1awl4iEf0Y=; b=QVpOBTH49rYDwNKWRGGBPf6ELKa/6CntUUvUxmRdkoFZWDzUWzp+LVGKGFQh0Mmef0 YYMSxhRaezGAMRBM5ZTv7/Ll23U0bk1bApNJNT42a2cAbYrsQkbfkwdP3XSJu53tE+UL B6Vfpzq4nV6/67HdTALp5ysp5/Uiy+MjSs1ttpMuJ6tRlef2A6GioIQDsR62F/y5kRPh ZmUNgR02Y3PteBYVMcIGc9HE1SN6Bv4JrVccNTVylv4mXL42F/igcHWbcCzjBnqD2cLV qrkHdv9vPMv6RDKTOd03Ea5s2beBX1ogfNurp3apf1LBF85yHgGsNrzuAFsQwvVgS8vj s+xQ==
X-Received: by 10.14.37.4 with SMTP id x4mr46284784eea.16.1380025052830; Tue, 24 Sep 2013 05:17:32 -0700 (PDT)
Received: from [10.100.2.17] (94-224-103-174.access.telenet.be. [94.224.103.174]) by mx.google.com with ESMTPSA id v8sm2564787eeo.12.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 05:17:32 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos 
Message-ID: <524182EC.80505@gnutls.org>
Date: Tue, 24 Sep 2013 14:17:48 +0200
From: Nikos Mavrogiannopoulos 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Ben Laurie 
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org>  <524176EA.3090401@gnutls.org> 
In-Reply-To: 
X-Enigmail-Version: 1.5.1
OpenPGP: id=96865171
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:17:34 -0000

On 09/24/2013 01:40 PM, Ben Laurie wrote:

>>> Can you provide a reference for your claim?
>> I believe we make circles. I previously referenced IPSec (RFC2104) at:
>> http://www.ietf.org/mail-archive/web/tls/current/msg09832.html
>> The same RFC references the Preneel-van-Oorschot paper.
>>
>> I take your question that you actually read RFC2104 and the
>> Preneel-van-Oorschot paper and you disagree with their points?
> 
> Actually, I did, and I don't disagree with their points, but I
> disagree with _your_ points.

I am confused now. My point was to truncate the MAC and this is what
RFC2104 and the paper argues for. What do you actually disagree with?

>> PS. I attach the comment of Bart Preneel on the topic (a cryptographer
>> with significant expertise on hash functions).
> In which he says he was right for the wrong reasons. So, you need to
> reference the right papers (i.e. the ones that describe key recovery
> attacks) so we can evaluate the severity of these attacks. I am not
> aware of any even vaguely practical attacks against even HMAC-MD5, let
> alone any HMAC we're actually contemplating.
> Please present your evidence.

Since you are the one claiming that MAC truncation isn't necessary when
all existing protocols do it (even TLS does it on the Finished message
MAC), it may be better for you to present evidence that this isn't
necessary. Just add a paragraph in the Security considerations of the
existing draft. That would be sufficient for me.

> (Incidentally, he also agrees that the right answer is to have larger
> internal state, not to truncate. SHA-3 gives us this, right?).

I agree, but the discussion was about converting the old ciphersuites
that use HMAC-MD5 and HMAC-SHA1. There is no HMAC-SHA3 (in TLS or
anywhere else).

regards,
Nikos


From pgut001@cs.auckland.ac.nz  Tue Sep 24 05:31:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01E6821F99F8 for ; Tue, 24 Sep 2013 05:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level: 
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1B4UNSntf+X for ; Tue, 24 Sep 2013 05:31:18 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 91BE421F87B7 for ; Tue, 24 Sep 2013 05:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380025877; x=1411561877; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=st+YVwwTvHOGT6K97+vYpXkvG2QudVo7VgTDlJiw6ec=; b=NT/POIMEZG8AsC29rLPtxi52obWyHLazKEsgguTQGS8q0hlXHofkvmLt oiWc/D0o3NDzIPhK6OCOa6apTAovxlBoPQ7fra8tRF5yLSLQMDy+zUrrV ibRm8zKxNLpn4uZdh2XObgW1eznQ0OUCbIlbm3Sp3LZDvFF76slOw34Lp E=;
X-IronPort-AV: E=Sophos;i="4.90,970,1371038400"; d="scan'208";a="213887794"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Sep 2013 00:31:13 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 00:31:12 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac65IfHcVqqY2KB5QIOIiN5kL9FEAA==
Date: Tue, 24 Sep 2013 12:31:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567C914@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:31:24 -0000

Nikos Mavrogiannopoulos  writes:=0A=
=0A=
>Since you are the one claiming that MAC truncation isn't necessary when al=
l=0A=
>existing protocols do it (even TLS does it on the Finished message MAC), i=
t=0A=
>may be better for you to present evidence that this isn't necessary.=0A=
=0A=
Before that, you'd have to present evidence that "all existing protocols do=
=0A=
it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS doesn't=
,=0A=
SSH doesn't, ... .  In fact of the major IETF application-level security=0A=
protocols that I can think of, only IPsec does, and AFAIK (meaning based on=
=0A=
long-ago discussions with one of the IPsec folks) that was done in order to=
=0A=
fit the MAC into the fixed-size AH header (although there seems to be some=
=0A=
disagreement on the details).=0A=
=0A=
As I've also already pointed out, TLS has for some years now provided for M=
AC=0A=
truncation to a range of sizes.  If anyone's really worried about this, the=
y=0A=
can request truncation to whatever size they prefer.=0A=
=0A=
Peter.=

From prvs=29794e2de3=uri@ll.mit.edu  Tue Sep 24 05:48:52 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A5111E811F for ; Tue, 24 Sep 2013 05:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.528
X-Spam-Level: 
X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=0.319,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7TJuww1xMSW for ; Tue, 24 Sep 2013 05:48:48 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 450EC11E8121 for ; Tue, 24 Sep 2013 05:48:47 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8OCm6wZ025441; Tue, 24 Sep 2013 08:48:40 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "'pgut001@cs.auckland.ac.nz'" , "'tls@ietf.org'" 
Date: Tue, 24 Sep 2013 08:48:32 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac65IfHcVqqY2KB5QIOIiN5kL9FEAAAAmv0e
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567C914@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-24_05:2013-09-23, 2013-09-24, 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-1305240000 definitions=main-1309240052
Message-Id: <20130924124848.450EC11E8121@ietfa.amsl.com>
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:48:52 -0000

Guys,

Isn't it enough already? Sufficient evidence, including publications by res=
pected cryptographers, has been presented to adequately demonstrate that tr=
uncating MAC has security advantages over including the entire output of th=
e hash function. That was the primary reason/justification for truncating M=
AC in IPsec.=20

FWIW, the reasoning of that paper applies to SHA3 as well, though arguably =
that extra security measure is unnecessary there.

P.S. Peter, I admire your ability to keep arguing well past the logical def=
eat. 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street                        Email: 
Lexington, MA  02420-9185      =20

Web:  http://www.ll.mit.edu/CST/

=20

MIT LL Root CA:=20

 


DSN:   478-5980 ask Lincoln ext.1638

----- Original Message -----
From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
Sent: Tuesday, September 24, 2013 08:31 AM=0A=
To:  
Subject: Re: [TLS] padding bug

Nikos Mavrogiannopoulos  writes:

>Since you are the one claiming that MAC truncation isn't necessary when al=
l
>existing protocols do it (even TLS does it on the Finished message MAC), i=
t
>may be better for you to present evidence that this isn't necessary.

Before that, you'd have to present evidence that "all existing protocols do
it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS doesn't=
,
SSH doesn't, ... .  In fact of the major IETF application-level security
protocols that I can think of, only IPsec does, and AFAIK (meaning based on
long-ago discussions with one of the IPsec folks) that was done in order to
fit the MAC into the fixed-size AH header (although there seems to be some
disagreement on the details).

As I've also already pointed out, TLS has for some years now provided for M=
AC
truncation to a range of sizes.  If anyone's really worried about this, the=
y
can request truncation to whatever size they prefer.

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

From Kenny.Paterson@rhul.ac.uk  Tue Sep 24 05:59:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E6421F9228 for ; Tue, 24 Sep 2013 05:59:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level: 
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Usq0XdB+vjQf for ; Tue, 24 Sep 2013 05:59:46 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id D2D4421E8063 for ; Tue, 24 Sep 2013 05:59:42 -0700 (PDT)
Received: from mail74-am1-R.bigfish.com (10.3.201.240) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 12:59:41 +0000
Received: from mail74-am1 (localhost [127.0.0.1])	by mail74-am1-R.bigfish.com (Postfix) with ESMTP id B2B571000CD; Tue, 24 Sep 2013 12:59:41 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT003.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -31
X-BigFish: PS-31(zzbb2dI98dI9371I1431J542I1432I12d5I14ffIzz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz31iz1de098h1033IL17326ah1de097h186068h5eeeK8275dhz2dh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(13464003)(377454003)(479174003)(24454002)(189002)(51704005)(53754006)(243025003)(199002)(48214007)(51694002)(81816001)(15202345003)(76176001)(81686001)(80976001)(74662001)(83072001)(76786001)(74482001)(56776001)(54316002)(76482001)(74366001)(74876001)(47446002)(76796001)(74502001)(51856001)(47736001)(47976001)(50986001)(49866001)(4396001)(46102001)(19580405001)(19580395003)(31966008)(83322001)(36756003)(56816003)(15975445006)(83506001)(79102001)(69226001)(80022001)(66066001)(81542001)(65816001)(53806001)(74706001)(63696002)(81342001)(54356001)(77982001)(59766001)(491001); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB280; H:AMXPR03MB277.eurprd03.prod.outlook.com; CLIP:134.219.227.30; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail74-am1 (localhost.localdomain [127.0.0.1]) by mail74-am1 (MessageSwitch) id 1380027579745469_13599; Tue, 24 Sep 2013 12:59:39 +0000 (UTC)
Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.242])	by mail74-am1.bigfish.com (Postfix) with ESMTP id A1B084A0246; Tue, 24 Sep 2013 12:59:39 +0000 (UTC)
Received: from AM2PRD0311HT003.eurprd03.prod.outlook.com (157.56.249.149) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 12:59:39 +0000
Received: from AMXPR03MB280.eurprd03.prod.outlook.com (10.242.69.154) by AM2PRD0311HT003.eurprd03.prod.outlook.com (10.255.162.38) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 12:59:39 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AMXPR03MB280.eurprd03.prod.outlook.com (10.242.69.154) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 12:59:38 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com ([10.242.69.140]) by AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.89]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 12:59:38 +0000
From: "Paterson, Kenny" 
To: "Blumenthal, Uri - 0558 - MITLL" , "'pgut001@cs.auckland.ac.nz'" , "'tls@ietf.org'" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac65IfHcka+JHcxaQ6OFXY9dkTUeRAAAm4UAAASTYYA=
Date: Tue, 24 Sep 2013 12:59:37 +0000
Message-ID: 
In-Reply-To: <20130924124848.450EC11E8121@ietfa.amsl.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [134.219.227.30]
x-forefront-prvs: 09796A1B83
Content-Type: text/plain; charset="us-ascii"
Content-ID: <002B9E346CEB0F428DD843EC10A96850@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 12:59:51 -0000

Hi all,

I was not going to join this debate, which seems to be essentially
political rather than technical, but I guess I should. I already (in a
previous post) pointed to the state of the art on attacks against HMAC:

http://www.ietf.org/mail-archive/web/tls/current/msg09824.html


My conclusion there was that HMAC with all current TLS hash functions is
fine without any truncation in an encrypt-then-MAC construction (wherein
the MAC output is exposed as part of the ciphertext), but we should avoid
HMAC-MD5 just to be conservative.

Now I just wanted to remind everybody that truncating MAC outputs is not
ALWAYS a good idea. Specifically, in the context of TLS's
MAC-then-PAD-then-Encrypt construction, it has been known for some time
that short MACs coupled with TLS's support for variable length padding
allows an attack. See Section 5 of this paper:

http://www.isg.rhul.ac.uk/~kp/mee-comp.pdf


(published at Asiacrypt 2011).

This is not to say that truncating TLS MACs in an encrypt-then-MAC
construction is inherently dangerous in the same way. It's not. But I just
wanted to make sure it was properly understood that truncation can also
have negative security consequences, depending on how the MAC is used as
part of a protocol.

Cheers

Kenny



On 24/09/2013 13:48, "Blumenthal, Uri - 0558 - MITLL" 
wrote:

>Guys,
>
>Isn't it enough already? Sufficient evidence, including publications by
>respected cryptographers, has been presented to adequately demonstrate
>that truncating MAC has security advantages over including the entire
>output of the hash function. That was the primary reason/justification
>for truncating MAC in IPsec.
>
>FWIW, the reasoning of that paper applies to SHA3 as well, though
>arguably that extra security measure is unnecessary there.
>
>P.S. Peter, I admire your ability to keep arguing well past the logical
>defeat. 
>
>--
>Regards,
>Uri Blumenthal                            Voice: (781) 981-1638
>Cyber Systems and Technology   Fax:   (781) 981-0186
>MIT Lincoln Laboratory                Cell:  (339) 223-5363
>244 Wood Street                        Email: 
>Lexington, MA  02420-9185
>
>Web:  http://www.ll.mit.edu/CST/
>
>=20
>
>MIT LL Root CA:=20
>
> 
>
>
>DSN:   478-5980 ask Lincoln ext.1638
>
>----- Original Message -----
>From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
>Sent: Tuesday, September 24, 2013 08:31 AM
>To:  
>Subject: Re: [TLS] padding bug
>
>Nikos Mavrogiannopoulos  writes:
>
>>Since you are the one claiming that MAC truncation isn't necessary when
>>all
>>existing protocols do it (even TLS does it on the Finished message MAC),
>>it
>>may be better for you to present evidence that this isn't necessary.
>
>Before that, you'd have to present evidence that "all existing protocols
>do
>it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS
>doesn't,
>SSH doesn't, ... .  In fact of the major IETF application-level security
>protocols that I can think of, only IPsec does, and AFAIK (meaning based
>on
>long-ago discussions with one of the IPsec folks) that was done in order
>to
>fit the MAC into the fixed-size AH header (although there seems to be some
>disagreement on the details).
>
>As I've also already pointed out, TLS has for some years now provided for
>MAC
>truncation to a range of sizes.  If anyone's really worried about this,
>they
>can request truncation to whatever size they prefer.
>
>Peter.
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls
>



From ietf-ietf-tls@m.gmane.org  Tue Sep 24 06:37:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A25811E8120 for ; Tue, 24 Sep 2013 06:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2Y2DAJEWReI for ; Tue, 24 Sep 2013 06:37:46 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id A419221F8EB5 for ; Tue, 24 Sep 2013 06:37:45 -0700 (PDT)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1VOSo6-0003xv-Qc for tls@ietf.org; Tue, 24 Sep 2013 15:37:38 +0200
Received: from c-50-132-41-203.hsd1.wa.comcast.net ([50.132.41.203]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Sep 2013 15:37:38 +0200
Received: from eternaleye by c-50-132-41-203.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 24 Sep 2013 15:37:38 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed 
Date: Tue, 24 Sep 2013 06:37:25 -0700
Lines: 25
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C7355676085@uxcn10-6.UoA.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-50-132-41-203.hsd1.wa.comcast.net
User-Agent: KNode/4.11.1
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 13:37:51 -0000

Peter Gutmann wrote:


> If you do want to generate your own ECDH parameters (i.e. curves), that's
> another huge mess to deal with.  For DH you just use Lim-Lee and you're
> done (although the fact that TLS doesn't communicate the 'q' value is
> something I'd really like to see corrected), while for ECC you need to get
> an awful lot of special-case checks and conditions just right.

Bernstein and Lange have some interesting stuff regarding that in-progress; 
this presentation[1] points out that those very same special-case checks and 
conditions are made necessary by the types of curves chosen, and that by 
choosing complete, twist-secure Edwards curves those can largely be avoided.

However, neither of the NIST curves nor the Brainpool curves are Edwards 
curves at all due to not having an order 4 point.

> Then, once you've done that, you get to find out how many implementations
> support the arbitrary_explicit_prime_curves format, which I suspect is
> pretty close to zero.

Of course, this remains an issue.


[1] http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf


From housley@vigilsec.com  Tue Sep 24 07:05:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 977AA11E8120 for ; Tue, 24 Sep 2013 07:05:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlTGJSubROB9 for ; Tue, 24 Sep 2013 07:04:54 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 14D3A21F915C for ; Tue, 24 Sep 2013 07:04:54 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9062AF241AC; Tue, 24 Sep 2013 10:05:37 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id YhViJA9QV5Hk; Tue, 24 Sep 2013 10:04:02 -0400 (EDT)
Received: from [192.168.2.100] (pool-96-255-145-152.washdc.fios.verizon.net [96.255.145.152]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CF126F241AE; Tue, 24 Sep 2013 10:05:34 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley 
In-Reply-To: 
Date: Tue, 24 Sep 2013 10:04:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Trevor Perrin 
X-Mailer: Apple Mail (2.1085)
Cc: IETF TLS 
Subject: Re: [TLS] RFC 5878 - why?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 14:05:00 -0000

> Hi,
>=20
> Does anyone know of a reason to use RFC 5878?  Extension data can
> already be sent in TLS handshakes:
>=20
> Client -> Server : ClientHello Extension
> Client <- Server : ServerHello Extension
> Client -> Server : SupplementalData (RFC 4680)
>=20
>=20
> 5878 just adds another extension structure inside existing ones:
>=20
> Client -> Server : ClientHello Extension signalling AuthorizationData
> Client <- Server : ServerHello Extension signalling AuthorizationData,
>                            SupplementalData containing =
AuthorizationData
> Client -> Server : SupplementalData containing AuthorizationData
>=20
>=20
> Seems like a bunch of added parsing for nothing?  What is this for?
>=20
>=20
> Trevor

As far as I know, my co-author is the only one that implemented the =
specification.  It worked.  However, he has changed jobs, and I do not =
think he is working on it any more.

Over the years, we have answered several queries from other people that =
were looking for an authorization mechanism.  I do not know if they used =
this approach or not.

As to the complexity, you should take a look at the TLS mail list =
discussion about TLS User Mapping Extension, which became RFC 4681.  =
Both user mapping and authorization were forced into the =
SupplementalData structure.  Both had more straightforward approaches in =
the beginning.

Russ


From SRS0=2RbL=TE=acm.org=bmoeller@srs.kundenserver.de  Tue Sep 24 07:29:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FCB11E8139 for ; Tue, 24 Sep 2013 07:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.086
X-Spam-Level: 
X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=0.540,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eCvxCw6tIT0j for ; Tue, 24 Sep 2013 07:29:01 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.8]) by ietfa.amsl.com (Postfix) with ESMTP id B873121F96B1 for ; Tue, 24 Sep 2013 07:28:44 -0700 (PDT)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MMrlb-1VWTws2gxz-008GSv; Tue, 24 Sep 2013 16:28:42 +0200
Received: by mail-oa0-f42.google.com with SMTP id g12so2232550oah.15 for ; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kqaP3G5bmFuOPU/bWwydal6ob86LQMCXfYu6vgp7pOg=; b=jxMLINAlC0uMlKxoBz2todBLzTaue/BWiP0V6fK3hhkjnUkeklGSaWwkIYbZcAYJfb TX1ZXsGuGrFFHem9cb4K4IiKfyJ7NrvydCjgx1ucL5ZVMvF/LsUcDTnZpNmcJFsXTN57 EslVcjitlklsON9mKsaPYSLoXxy2eTXVskuildSVDjSPzIbzHrNLGHT/NdOTkV5y0k6g r8IG03PTQEsfYAryQ9tJx8qum8pTwpsxS6MykLTIs56klCFWux6XkFRNrKP6QZkgs6L/ ax0k6CtNi9XBiY4KiDof526C4ucPfhKgoA1HSoHbIMyA7WRXvDt115q1UuPWxLJDFvnJ /jLA==
MIME-Version: 1.0
X-Received: by 10.60.39.169 with SMTP id q9mr511438oek.79.1380032920418; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Tue, 24 Sep 2013 07:28:40 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org>  <524176EA.3090401@gnutls.org> 
Date: Tue, 24 Sep 2013 16:28:40 +0200
Message-ID: 
From: Bodo Moeller 
To: Ben Laurie 
Content-Type: multipart/alternative; boundary=089e013cc3a600026c04e721f496
X-Provags-ID: V02:K0:nBPEKNv35XjfEWX3utt+/Hd6hPj0kC/iJtqrquspmZn VG9T7QXIADdFP5W9tJH96KefSVMdESGkGTmT+mGSSDFj8pnw/s PVpAu2oUBwlcPQGS2+zkSqC9V3JWy15ubFUkyY4nmlMJKG7qq8 Izpz/1bCkPRrxnwP6QFEXBEi9d2iev+n+0MCE6W7Nk/1BMqXLK NuQ5EcmXWr4xq1DennH3XGvle1fMsxON8Q387v8RPbwJQXVP/s /wnFou8fZOQDmEnyKHCzUX8G+poB1GnSPZjhvzjbBoAps2mUWy gEes9ob5hU8OSxj5mL6XtUeSJFscgy6axXF6yg/G4egnftm/gf 9f1kDP5d4saNXRxqO5CSFA3TE5IRBoTu16gLWZBSZ/X0VeMI3V j9Aej+DQZ7jvAhEWNJVwbbvGg5nM/q4dXc55jGPdDXrNzdBXDy pQs3Z
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 14:30:33 -0000

--089e013cc3a600026c04e721f496
Content-Type: text/plain; charset=ISO-8859-1

> > I take your question that you actually read RFC2104 and the
> > Preneel-van-Oorschot paper and you disagree with their points?
>


> c) In any case, the whole point of the truncation defence is to make
> it harder to go from _observing_ a colliding MAC to the ability to
> construct more collisions. But it mostly does this by making it easier
> to observe MAC collisions.
>

I think this reasoning is not quite right because that attack requires
*internal* collisions (and the internal state wouldn't be truncated).  Of
course, it's not an attack on HMAC.



> d) If you _really_ want to defend against this attack, the right
> answer is to design hash functions with bigger internal state.
>

Exactly. Given a particular l-bit MAC with an l-bit internal state,
truncating its outputs (such as to l/2 bits) isn't demonstrably an
improvement.  Rather, if we want an l-bit MAC, it makes sense to have an
internal state larger than l bits.

Nikos, you pointed to RFC 2104. The following is a literal quote from that
RFC: "The results in this area are not absolute as for the overall security
advantages of truncation."  In particular, encrypt-then-MAC with
untruncated MACs isn't a broken design.  (Assuming hypothetically there's a
key recovery attack on the MAC alone, the encryption step means that the
attacker can't pick MAC inputs after all.)

Bodo

--089e013cc3a600026c04e721f496
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=




> I take your question that you actually read RFC2104 and the

> Preneel-van-Oorschot paper and you disagree with their points?
=A0



c) In any case, the whole point of the truncation defence is to make

it harder to go from _observing_ a colliding MAC to the ability to

construct more collisions. But it mostly does this by making it easier

to observe MAC collisions.

I think this=
 reasoning is not quite right because that attack requires *internal* colli=
sions (and the internal state wouldn't be truncated). =A0Of course, it&=
#39;s not an attack on HMAC.







d) If you _really_ want to defend against this attack, the right

answer is to design hash functions with bigger internal state.

Exactly. Given a particular l-bit MAC with an l-bit=
 internal state, truncating its outputs (such as to l/2 bits) isn't dem=
onstrably an improvement. =A0Rather, if we want an l-bit MAC, it makes sens=
e to have an internal state larger than l bits.



Nikos, you pointed to RFC 2104. The following is a lite=
ral quote from that RFC: "The results in this area are not absolute as=
 for the overall security advantages of truncation." =A0In particular,=
 encrypt-then-MAC with untruncated MACs isn't a broken design. =A0(Assu=
ming hypothetically there's a key recovery attack on the MAC alone, the=
 encryption step means that the attacker can't pick MAC inputs after al=
l.)



Bodo



--089e013cc3a600026c04e721f496--

From SRS0=2RbL=TE=acm.org=bmoeller@srs.kundenserver.de  Tue Sep 24 07:30:21 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1BF11E813A for ; Tue, 24 Sep 2013 07:30:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.266
X-Spam-Level: 
X-Spam-Status: No, score=-1.266 tagged_above=-999 required=5 tests=[AWL=0.360,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVT3qKQNMen2 for ; Tue, 24 Sep 2013 07:30:16 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 71A1911E811E for ; Tue, 24 Sep 2013 07:30:16 -0700 (PDT)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MfjDI-1VCT350fVk-00NPzB; Tue, 24 Sep 2013 16:30:15 +0200
Received: by mail-ob0-f181.google.com with SMTP id gq1so4888629obb.26 for ; Tue, 24 Sep 2013 07:30:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=k6nr7MacHSef9MzLzfiXlC2gzYzxtqJTnCK9K3+3V3w=; b=XDuNJfw1KR5Ce9R9CEmJbModcP6cEbbrXKvAPE6EX5ft/HpwYnElSFhCH1w4f8S0Co 8ZgU3Q//W5xZD8LUAVFXSPjE0UTm1e/xyRjqklqYWEn9/dcMyPr7T/wImRnPpLm/PVd1 Xldo2N3qovz+lsyfKRwuiwTy1/C88Jx0byDeCH+eXfzygzPHrhojrNvvlUJrW8shVQ3R r+2Akwt96IPG9spAnEUt2duRVMeyodGg4qTPd0i1jewK75TLACbthiknbyzUIuGo2PTi XzzP9d9nRaZfiWJQWTjjJRzardjQ+lAC3WEPjeV/rYxe3fFEjLeEVuYQmJfiAWnSw1gb YWhQ==
MIME-Version: 1.0
X-Received: by 10.182.49.166 with SMTP id v6mr25459783obn.13.1380033013752; Tue, 24 Sep 2013 07:30:13 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Tue, 24 Sep 2013 07:30:13 -0700 (PDT)
In-Reply-To: 
References:  
Date: Tue, 24 Sep 2013 16:30:13 +0200
Message-ID: 
From: Bodo Moeller 
To: "Paterson, Kenny" 
Content-Type: multipart/alternative; boundary=047d7b5d2ea4902fbf04e721f9c7
X-Provags-ID: V02:K0:eFhKJaAWwb+/QzvjhibW3fiI6RtTbupubC5g0LwapxK FXIO7WXhBRZXSMzTcuIZfvJowIs7LI4LFDNQg4APZdbNvhnPpb ECOUSNW39ny4V6WQvnXOpSF+WdCZUGt5GxXkhNpg7hwFcAo3IY IpOnwo+niY/WfUyvaxFLJYdrxtR6DgcL6ScKj/yujwJQgBwfUx 0yeJMYBnR9flboQ3GQJjcDr/7mwk/Uon/xxdOFqbjMPJTosPBY dof5mIENZE4qYIY/WE8f9lGR7KTOC3Uh02Mvsg0bSBNgUqFELb FkQYI78yS2kh0Jb/llvD0xG3bb59Z2a0khs3vs8tU13K6/S1JA W9J+ImUVYyR5z2muwNfmpLc/heAOMhjn1IxsisuCjkbk6mEQ/u TkIb4qUHX4+O0NIc+8KkIpWI4DpwCpSco/6rB0EIpaxNBHeFrK bMqSu
Cc: Alfredo Pironti , "tls@ietf.org" 
Subject: Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 14:33:30 -0000

--047d7b5d2ea4902fbf04e721f9c7
Content-Type: text/plain; charset=ISO-8859-1

>
>
>
> 1. There is some formal support for the "Pad-then-encrypt-then-MAC"
> approach being used in the above Approach #1 in the following paper:
>

I think here you meant "Pad-then-MAC-then-encrypt".


>
> Kenneth G. Paterson and Gaven J. Watson
>
> Authenticated-Encryption with Padding: A Formal Security Treatment
> Cryptography and Security: From Theory to Applications
>
> Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107.
>
> http://link.springer.com/book/10.1007/978-3-642-28368-0
>
>
>
> See in particular, Theorem 8 in the paper.
>
> Unfortunately, this paper is behind Springer's paywall. For those on the
> list without access, you can access the same content in Chapter 5 (Theorem
> 5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here:
>
> http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf

--047d7b5d2ea4902fbf04e721f9c7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable






1. There is some formal support for the "Pad-then-encrypt-then-MAC&quo=
t;

approach being used in the above Approach #1 in the following paper:

I think here you meant "Pad-then-MAC-the=
n-encrypt".
=A0




Kenneth G. Paterson and Gaven J. Watson



Authenticated-Encryption with Padding: A Formal Security Treatment

Cryptography and Security: From Theory to Applications



Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107.



http://link.springer.com/book/10.1007/978-3-642-28368-0







See in particular, Theorem 8 in the paper.



Unfortunately, this paper is behind Springer's paywall. For those on th=
e

list without access, you can access the same content in Chapter 5 (Theorem<=
br>
5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here:



http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf




--047d7b5d2ea4902fbf04e721f9c7--

From Kenny.Paterson@rhul.ac.uk  Tue Sep 24 07:43:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FA221F9A16 for ; Tue, 24 Sep 2013 07:43:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8y7uRworXoA for ; Tue, 24 Sep 2013 07:43:13 -0700 (PDT)
Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0249.outbound.messaging.microsoft.com [213.199.154.249]) by ietfa.amsl.com (Postfix) with ESMTP id 0336311E8139 for ; Tue, 24 Sep 2013 07:43:07 -0700 (PDT)
Received: from mail41-db9-R.bigfish.com (10.174.16.251) by DB9EHSOBE018.bigfish.com (10.174.14.81) with Microsoft SMTP Server id 14.1.225.22; Tue, 24 Sep 2013 14:43:06 +0000
Received: from mail41-db9 (localhost [127.0.0.1])	by mail41-db9-R.bigfish.com (Postfix) with ESMTP id 4946AC001DC; Tue, 24 Sep 2013 14:43:06 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT001.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: PS-7(zzbb2dI98dI1432I1447Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah1de097h186068h5eeeK8275bh8275dhz2dh2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh1155h)
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(189002)(51704005)(199002)(243025003)(51914003)(479174003)(24454002)(66066001)(80022001)(81542001)(83506001)(79102001)(69226001)(63696002)(59766001)(81342001)(77982001)(54356001)(53806001)(65816001)(74706001)(56776001)(54316002)(76482001)(74366001)(76786001)(74482001)(74876001)(51856001)(76796001)(47446002)(74502001)(80976001)(81816001)(76176001)(81686001)(83072001)(74662001)(83322001)(36756003)(56816003)(4396001)(47976001)(47736001)(49866001)(50986001)(31966008)(46102001)(19580405001)(19580395003); DIR:OUT; SFP:; SCL:1; SRVR:AMXPR03MB280; H:AMXPR03MB277.eurprd03.prod.outlook.com; CLIP:134.219.227.30; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Received: from mail41-db9 (localhost.localdomain [127.0.0.1]) by mail41-db9 (MessageSwitch) id 1380033784201212_6641; Tue, 24 Sep 2013 14:43:04 +0000 (UTC)
Received: from DB9EHSMHS029.bigfish.com (unknown [10.174.16.250])	by mail41-db9.bigfish.com (Postfix) with ESMTP id 226BAC40046; Tue, 24 Sep 2013 14:43:04 +0000 (UTC)
Received: from AM2PRD0311HT001.eurprd03.prod.outlook.com (157.56.249.149) by DB9EHSMHS029.bigfish.com (10.174.14.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 24 Sep 2013 14:43:03 +0000
Received: from AMXPR03MB280.eurprd03.prod.outlook.com (10.242.69.154) by AM2PRD0311HT001.eurprd03.prod.outlook.com (10.255.162.36) with Microsoft SMTP Server (TLS) id 14.16.359.1; Tue, 24 Sep 2013 14:43:02 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com (10.242.69.140) by AMXPR03MB280.eurprd03.prod.outlook.com (10.242.69.154) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 14:43:02 +0000
Received: from AMXPR03MB277.eurprd03.prod.outlook.com ([10.242.69.140]) by AMXPR03MB277.eurprd03.prod.outlook.com ([169.254.16.89]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 14:43:02 +0000
From: "Paterson, Kenny" 
To: Bodo Moeller 
Thread-Topic: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)
Thread-Index: AQHOrV7JqCYZI8YfRkeamC+FHpvRkpm9gp+AgBeHzICAACUTgA==
Date: Tue, 24 Sep 2013 14:43:01 +0000
Message-ID: 
In-Reply-To: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.6.130613
x-originating-ip: [134.219.227.30]
x-forefront-prvs: 09796A1B83
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: Alfredo Pironti , "tls@ietf.org" 
Subject: Re: [TLS] padding bug (was: Re: Requesting feedback on TACK draft)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 14:43:18 -0000

On 24/09/2013 15:30, "Bodo Moeller"  wrote:

>
>
>1. There is some formal support for the "Pad-then-encrypt-then-MAC"
>approach being used in the above Approach #1 in the following paper:
>
>
>I think here you meant "Pad-then-MAC-then-encrypt".
>=20
>

Yes, thanks for the correction.


>
>Kenneth G. Paterson and Gaven J. Watson
>
>Authenticated-Encryption with Padding: A Formal Security Treatment
>Cryptography and Security: From Theory to Applications
>
>Lecture Notes in Computer Science Volume 6805, 2012, pp 83-107.
>
>http://link.springer.com/book/10.1007/978-3-642-28368-0
>
>
>
>See in particular, Theorem 8 in the paper.
>
>Unfortunately, this paper is behind Springer's paywall. For those on the
>list without access, you can access the same content in Chapter 5 (Theorem
>5.6, page 96) of Gaven Watson's Ph.D. Thesis, available here:
>
>http://www.isg.rhul.ac.uk/~kp/theses/GWthesis.pdf
>
>
>
>
>
>
>
>



From simon@josefsson.org  Tue Sep 24 08:28:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E7A11E812E for ; Tue, 24 Sep 2013 08:28:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6lsgKymDPDX for ; Tue, 24 Sep 2013 08:28:36 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAEC21F93F3 for ; Tue, 24 Sep 2013 08:28:35 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OFSB0a026130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 17:28:13 +0200
From: Simon Josefsson 
To: Rob Stradling 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:130924:code@funwithsoftware.org::B7MIB7LJrhcW5IRY:5iNk
X-Hashcash: 1:22:130924:tls@ietf.org::PW70yfsL2fRVlCt3:PS2a
X-Hashcash: 1:22:130924:rob.stradling@comodo.com::VpTqEcCEz8dCczPl:RTsC
Date: Tue, 24 Sep 2013 17:28:11 +0200
In-Reply-To: <522ED9A7.7080802@comodo.com> (Rob Stradling's message of "Tue, 10 Sep 2013 09:34:47 +0100")
Message-ID: <877ge6tf1w.fsf_-_@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: [TLS] Ed25519 for PKIX
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 15:28:37 -0000

Rob Stradling  writes:

> Your draft defines a NamedCurve ID for Curve25519, thereby enabling it
> to be used for key exchange.  But what about "(client or server)
> authentication through reference in X.509 certificates..."?
>
> I'm not aware of an equivalent of RFC5639 for Curve25519.  Should we
> create one?  Or could we simply define some new ASN.1 Object
> Identifiers in your draft?

Curve25519 is not directly usable with ECDSA, I believe, so OIDs aren't
sufficient.  Ed25519 is more relevant, however it uses the EdDSA
signature system instead of ECDSA so possibly more of RFC 5480 has to be
duplicated/modified in order for Ed25519 to work.

Given the performance improvements with Ed25519, I think this is a
interesting topic to pursue.  Perhaps a small team of people can get
together and work out what is required.  It doesn't belong in the TLS WG
though.

/Simon

From simon@josefsson.org  Tue Sep 24 08:32:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0476711E815B for ; Tue, 24 Sep 2013 08:32:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CZBdY7taagu for ; Tue, 24 Sep 2013 08:32:40 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 0166B11E8139 for ; Tue, 24 Sep 2013 08:32:33 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OFWUlh027048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 24 Sep 2013 17:32:31 +0200
From: Simon Josefsson 
To: tls@ietf.org
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org>
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:130924:stebila@qut.edu.au::1WbmBYmibPsDkqwr:ofA
X-Hashcash: 1:22:130924:tls@ietf.org::2nxQfvjk4x/PCfv2:6gf8
X-Hashcash: 1:22:130924:code@funwithsoftware.org::q1eyW1dE8zuOJG+e:5LVl
Date: Tue, 24 Sep 2013 17:32:30 +0200
In-Reply-To: <87zjrl21wp.fsf_-_@latte.josefsson.org> (Simon Josefsson's message of "Mon, 09 Sep 2013 22:08:54 +0200")
Message-ID: <8738outeup.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Subject: [TLS] Curve25519 in TLS
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 15:32:41 -0000

All,

I have updated my Curve25519 draft, primarily to clarify that Curve25519
isn't directly applicable to X.509 signatures.

http://tools.ietf.org/html/draft-josefsson-tls-curve25519-01

/Simon

From agl@google.com  Tue Sep 24 08:34:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EE4421F99FB for ; Tue, 24 Sep 2013 08:34:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.806
X-Spam-Level: 
X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.172,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yw18H+HiBzi6 for ; Tue, 24 Sep 2013 08:34:33 -0700 (PDT)
Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9A20121F9A37 for ; Tue, 24 Sep 2013 08:34:33 -0700 (PDT)
Received: by mail-oa0-f48.google.com with SMTP id m6so2312329oag.21 for ; Tue, 24 Sep 2013 08:34:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=mIuWvLsUkCYPk2mmxj7McuFqCVNhh2u6nFwAYGEjWoQ=; b=gMfxzN8SYVGJhEk1D2MApRxf/A4ddvWMtxkd1+RZKZdzxQUegF+L3IcWGk82qAQdI4 E6dQOQ7ZTPbhojMmh8ytKDeBLmYNViDWQ8l3224wl6FQ76KuOXuAgRpJWzR5oTtgp6c0 cG7Un9lMg/xcKHIJ6zWreLDS0Xq/lRcXdG6SjLmAMrWIr4Ne6SzIYxkd+x9GrTHZivoi S0qhBsZc02ECp233zhcuFHz+TwijPy3dP1zM8lb3Y9wP9Q/tIrEdOrNbg/mB/kigYxhQ SjLykXB5mWSlD4B30ss8n8b7xl2KHoaj+4bKG/XmG6JoSuOb2BLJ2NrdjfBd81EcCo8u atRg==
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=mIuWvLsUkCYPk2mmxj7McuFqCVNhh2u6nFwAYGEjWoQ=; b=K+TqFH0tbVObnllDIIfQqraASzD9tDRO02xyj415Y6H0AtgtjJNiRD1dlqr3+R8cs6 S+RA+lq550oMWc4LGMk0ciWA24tFzTOhkHOPGMp9m4+Cc6KqzrGEmOydf3NI8fF+CwbS koak6V5wyHPhQsVws98ShP+uzXnFRMjOfDJ5H8LoLUoNuqoG1CBz5HarfcoDdRz60crt MmlWI+cMd+62pApQI8UsWgUKDeNrfst8ZRFK0lrGKAxRw+9zpwc1vmS+waHp/zivnS+g 31rQIzMjMTwkze0ElsJZGEk1Xs6d16HoavFgtZu764BGMieppYgwFk8fRABbGgRsaflL IBWw==
X-Gm-Message-State: ALoCoQm9YHMbp0c9c06umPuelY3Qmlx5/zqq9V3ARyrocf6upVeFkbvt6xHT+n4TI96q5OU6rOpXLdabvmS/X1VTYjDPTieWglzIL1XecWPA5mGf2tAZerSMvrGwcx9VH66Jz1/ApGoKnft9Wgjz5KZqJ+j9fOyMkJ25HBWUhnkWTg4BRWSiHrixBYk5c/Mn+4UH/a8Ncgai
X-Received: by 10.60.45.102 with SMTP id l6mr8190821oem.36.1380036873010; Tue, 24 Sep 2013 08:34:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.79.105 with HTTP; Tue, 24 Sep 2013 08:34:12 -0700 (PDT)
In-Reply-To: <877ge6tf1w.fsf_-_@latte.josefsson.org>
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <877ge6tf1w.fsf_-_@latte.josefsson.org>
From: Adam Langley 
Date: Tue, 24 Sep 2013 11:34:12 -0400
Message-ID: 
To: Simon Josefsson 
Content-Type: text/plain; charset=UTF-8
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Ed25519 for PKIX
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 15:34:34 -0000

On Tue, Sep 24, 2013 at 11:28 AM, Simon Josefsson  wrote:
> Curve25519 is not directly usable with ECDSA, I believe, so OIDs aren't
> sufficient.  Ed25519 is more relevant, however it uses the EdDSA
> signature system instead of ECDSA so possibly more of RFC 5480 has to be
> duplicated/modified in order for Ed25519 to work.

Curve25519 and Ed25519 are the same curve - Ed25519 just uses the
twisted Edward's isomorphism of curve25519 to make some calculations
simpler and then builds a Schnorr-like signature scheme with it.
(Curve25519 implementations typically use a Montgomery ladder which
isn't suitable for some of the operations that the signature scheme
needs.)

(Indeed, one can use the Ed25519 code to perform fixed-base,
curve25519 operations faster than the curve25519 code.)


Cheers

AGL

From mike-list@pobox.com  Tue Sep 24 09:01:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EDD11E8177 for ; Tue, 24 Sep 2013 09:01:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfsHvkYr33-G for ; Tue, 24 Sep 2013 09:01:24 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id DA6DC11E817D for ; Tue, 24 Sep 2013 09:01:01 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 16CBFD837; Tue, 24 Sep 2013 12:00:56 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=we6ZQQQAKXO/ xHq67FxLoWuBPTw=; b=Scqm8ydmFIUtMMBChJ4AFp9/sSgIUKAh4q901Or7pr12 t6ntu7mIXmjxAMpRlP9nlI3HtDHih0+3on/O+pJ8cULR2Fd+r2YfHc6lq9rhX2sI tO3vmFUZUfgAtUJuUuwzOAziC/1ghB+qPrbCSWGmcddgkbYjLnDrcwMhSyJU4Tg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=i2sGRk RC7G+Myp2pkjZfuMJkiKhgShCkSitr6VrLSx5Pib5QMNK2gmIqcfcMHm6WqcIrD0 LXQwPGMYVwZfejVSDBlvJYmugE0NaLRgsuarSEYL0eV4STbjb5b45uajKVjE2DLF /mQOxvNkpSzxOQOaUbm0xEPTqe3chbsFScv5k=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 0C709D836; Tue, 24 Sep 2013 12:00:56 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 53992D835; Tue, 24 Sep 2013 12:00:55 -0400 (EDT)
Message-ID: <5241B736.60708@pobox.com>
Date: Tue, 24 Sep 2013 09:00:54 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C735567C914@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567C914@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 7EAFE7DA-2532-11E3-9ED8-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 16:01:40 -0000

Peter Gutmann wrote:
> 
> TLS has for some years now provided for MAC truncation to a
> range of sizes.

I believe you are confusing the max_fragment_length extension
with truncated_hmac.  Truncated HMAC provides only one size,
80 bits, with the motivation being bandwidth constraints.

Mike

From mike-list@pobox.com  Tue Sep 24 09:03:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCBE11E816F for ; Tue, 24 Sep 2013 09:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level: 
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y64hYSUITKq5 for ; Tue, 24 Sep 2013 09:03:29 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8A59B21E808F for ; Tue, 24 Sep 2013 09:02:32 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DE460D84B; Tue, 24 Sep 2013 12:02:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=iL0gRErVIaEI 3kPjYzp3EIBg6qM=; b=D7KTJsDttZeaCWPaRapunonTKCcsjNQYZpUyYZ6BJr1l zAI6RhNUSsv8f1pEUwu5mqPoRWRZ2Pj6o1hHFevAEHRf83hqw0JFayHY3iyDJzXc FZfuZ+MqkKAZYnfM480mVESfcXv90vOUlVUaWhVtIH1oJHsBFoBQpR0+wafGb+8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=Arwzbe KU18fhcb2bNnguBzTpgWRjIktkySKJBf1yMRDE380fLkB1VsTySoDUWHZtt8Ymk7 3Qr2l4TWniCujhHeeSYJPUhitntbweKKE+WDUcMsF0sLGVlZI/n8KL0fdAJCwRj9 WjysA0h8vxsiWYJSutuqvmGZNZQ9D7Fal1j00=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D3F8FD84A; Tue, 24 Sep 2013 12:02:31 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 2D779D849; Tue, 24 Sep 2013 12:02:31 -0400 (EDT)
Message-ID: <5241B796.3000704@pobox.com>
Date: Tue, 24 Sep 2013 09:02:30 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Gutmann 
References: <9A043F3CF02CD34C8E74AC1594475C7355676085@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7355676085@uxcn10-6.UoA.auckland.ac.nz>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: B7D00432-2532-11E3-B17A-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 16:03:34 -0000

Peter Gutmann wrote:
> 
> For DH you just use Lim-Lee and you're done

Can you please provide a pointer to the Lim-Lee algorithm?

Thanks,

Mike

From benl@google.com  Tue Sep 24 09:04:20 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882E021F8F97 for ; Tue, 24 Sep 2013 09:04:20 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MP2vsmVa8q4U for ; Tue, 24 Sep 2013 09:04:20 -0700 (PDT)
Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F2B4F21F963F for ; Tue, 24 Sep 2013 09:03:56 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id ar20so9346176iec.32 for ; Tue, 24 Sep 2013 09:03:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=63VjmJ4eo5PIWGo99bLmWepzTQ/h1Ntne2CzcHtdE+s=; b=nIqpV2FcoAqc49rl30DGHdPAnECddDj9/ZO3RVTTLsLff29nGYvjZliH3muY0V0/QC 0RxeZKoehuVDf4wBeuJGE6EAKKZyRXg+vAM4DIU0OuKMdDm7pDQ+MqXvbu79BsLUiO/A jiRYxSHJlWxie70/lfJWdJwRs90BTmULdf8NhP/bDhYl3DYLdl9KL7L6XHvMR27j0XmV 4uL/BwL12MxkIciUJYlb6GEIuhXVSAbuBJRCIHblKci0p9PakjDcdszP+kD69kOkZfPO JrjxyporXUEB1fEKhUlQEWjJ3VbCNkDlkFIIkWL24mj0APdc3Y14luDxPmUkVTQ4c1cw TsiQ==
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=63VjmJ4eo5PIWGo99bLmWepzTQ/h1Ntne2CzcHtdE+s=; b=ORZvHlPaVrK/3vtppsDQg+f2MDpAeloSAn5Vvft0WsHdDLzwkdHHPTy2H1jhBFv/G3 JPur/byfN1j9HUJZges9u5HcXXpw3mMM5mfQlYXpf2tzgykQlyaR0a7SKZirVIZqk3YR mWQwM2TwQNZzS4wcoYtnUoJK5ekRpxdG2hhQRr9eZgXCe7xxXjTjurRzCtiAQ+XSrOka JBqKO3EpkZ7bfxCoxlW5ldez7ssrDdVNM94mpiJKI5kZlYcCq1rIa1wqrYuSLQJJSEiS rfEhfdCTiKp7zJM2SAxppwTj6eKmbaANOVrAyaibKCr0r3j7ieoOz2bUdfnGN+V7Eb7A jCeQ==
X-Gm-Message-State: ALoCoQm24W0Bh1s1viUbF5KUjORG0r1DPFGbBxibwvDDwb1sNCFrChpAxJVNamRqxotqRKW7Dstrj7UQl+I6KxAO0vBz9c6AWaqAQsQaUDARHVi+JpfdbLLlduEximKEY0ZiRoc7u5fz6rvHhftc+Tf9uxpA7P2wsJpjbfZk8UdzPII5IvPb+7xGuDBv56w5EeNZb/75lTZy
MIME-Version: 1.0
X-Received: by 10.42.211.74 with SMTP id gn10mr3840933icb.17.1380038635705; Tue, 24 Sep 2013 09:03:55 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 09:03:55 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C73556760EA@uxcn10-6.UoA.auckland.ac.nz> <524148C3.7090709@gnutls.org>  <524176EA.3090401@gnutls.org>  
Date: Tue, 24 Sep 2013 17:03:55 +0100
Message-ID: 
From: Ben Laurie 
To: Bodo Moeller 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 16:04:20 -0000

On 24 September 2013 15:28, Bodo Moeller  wrote:
>
>> > I take your question that you actually read RFC2104 and the
>> > Preneel-van-Oorschot paper and you disagree with their points?
>
>
>>
>> c) In any case, the whole point of the truncation defence is to make
>>
>> it harder to go from _observing_ a colliding MAC to the ability to
>> construct more collisions. But it mostly does this by making it easier
>> to observe MAC collisions.
>
>
> I think this reasoning is not quite right because that attack requires
> *internal* collisions (and the internal state wouldn't be truncated).

That's what makes it harder :-)

>  Of
> course, it's not an attack on HMAC.
>
>
>>
>> d) If you _really_ want to defend against this attack, the right
>> answer is to design hash functions with bigger internal state.
>
>
> Exactly. Given a particular l-bit MAC with an l-bit internal state,
> truncating its outputs (such as to l/2 bits) isn't demonstrably an
> improvement.  Rather, if we want an l-bit MAC, it makes sense to have an
> internal state larger than l bits.
>
> Nikos, you pointed to RFC 2104. The following is a literal quote from that
> RFC: "The results in this area are not absolute as for the overall security
> advantages of truncation."  In particular, encrypt-then-MAC with untruncated
> MACs isn't a broken design.  (Assuming hypothetically there's a key recovery
> attack on the MAC alone, the encryption step means that the attacker can't
> pick MAC inputs after all.)
>
> Bodo
>

From christian.kahlo@ageto.net  Mon Sep 23 09:11:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A92F921F9E9C for ; Mon, 23 Sep 2013 09:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.066
X-Spam-Level: 
X-Spam-Status: No, score=-3.066 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_URI_OEM=0.533]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seM+sWO8c+Sk for ; Mon, 23 Sep 2013 09:11:22 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB921F9E76 for ; Mon, 23 Sep 2013 09:11:21 -0700 (PDT)
Received: by mail-bk0-f44.google.com with SMTP id mz10so1253876bkb.31 for ; Mon, 23 Sep 2013 09:11: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:reply-to:from:to:cc:references:in-reply-to :subject:date:organization:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=LDgGOHXqZ7yTcHZZ9vv347eaKf8XpS2laClD14QrZ08=; b=HwVYh/8Ksoop7QYd3XvIF2intovdoMnSaFkir91QhQxZ48xicN6zg9vsMPsZzJoNd8 9ov2YCVSiJivbucwPd8068FNcgYSAFQCwnC7JKw6gwn1x5HKzPiEF3/zOopZajNQjXpV +GSRVoghgH4RYNoJoiStAfUT78j0HxpDro3YGXxcuDJu6mO7x/BebUW5Gjsk+2yUZcCK u/aYnRNOgpCWNXJBT8g4NnVkmAH5RlUuQ0GawXqX+3fbHjLqsTCxCuOuT/DABFiQ1Cw/ ReEFiF1Bj+yxE5R5gMUw574uHpKMGkZU5Fh7Qrlz0xbMx4LvRX4UUI4VWtdfp2YSjyQm jXnQ==
X-Gm-Message-State: ALoCoQmMK8WEf6DGAQduaC6aw/fla96EYuXep3YPv0PucMETnqN7morRdUv+yts3DGdu+5F3ODLs
X-Received: by 10.204.168.197 with SMTP id v5mr18450459bky.24.1379952680244; Mon, 23 Sep 2013 09:11:20 -0700 (PDT)
Received: from THINK2 (cable-82-119-12-81.cust.telecolumbus.net. [82.119.12.81]) by mx.google.com with ESMTPSA id z6sm9012704bkn.8.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Sep 2013 09:11:19 -0700 (PDT)
From: "Christian Kahlo" 
To: "'Nikos Mavrogiannopoulos'" 
References:  <523c738f.0733cc0a.41a0.3096@mx.google.com> <523F383A.20803@drh-consultancy.co.uk> <523FE7B6.10501@gnutls.org> <524038fa.c402cd0a.127a.ffffc841@mx.google.com> <524047D1.7040601@gnutls.org>
In-Reply-To: <524047D1.7040601@gnutls.org>
Date: Mon, 23 Sep 2013 18:11:25 +0200
Organization: AGETO Innovation GmbH
Message-ID: <52406827.c664cc0a.2ad0.ffffd7f7@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac64ZW2U50kRXnQxSaSq9J2JttsfIgAD1x0Q
Content-Language: de
X-Mailman-Approved-At: Tue, 24 Sep 2013 09:33:53 -0700
Cc: 'Team Neuer Personalausweis' , tls@ietf.org
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 16:11:26 -0000

Hi Nikos,

> > maybe you want to read http://cseweb.ucsd.edu/~mihir/papers/oem.pdf
> > and http://www.iacr.org/archive/crypto2001/21390309.pdf.
> > Both mentioned within this thread:
> > http://crypto.stackexchange.com/questions/202/should-we-mac-then-
> > encrypt-or-encrypt-then-mac
> Have you actually read the papers you mention? For example have you

Phew, years ago probably. I just looked them up.

> seen theorem 2 of the second paper? The issue is with the

Yes.

> unauthenticated padding used in TLS not AtE. There are only

And that's why it shouldn't be used this way. :-)

> philosophical advantages of EtA over AtE when the latter is implemented
> properly (i.e., as not in TLS). Today we have more clues on the issues
> of AtE than it was at the time TLS was designed.

That's absolutely right of course. MtE is in SSL/TLS at least since
1996-03-04.

> > Please tell us which protocols are still using Mac-then-Encrypt today
> > without running into any security trouble (esp. chosen ciphertext
> > attacks). MtE is considered as a design fail by many researchers.
> 
> TLS with stream ciphers. It is authenticate-pad-then-Encrypt that has
> issues, please check the literature more carefully.

I've read it. Actually, what we're doing with EtM is Pad-then-Encrypt-
then-Mac.
Regarding stream ciphers: yes, but keep in mind people like to mix it
up with RC4 and you've to say you mean i.e. AES in CTR mode or similar.

> > As we discussed earlier AEAD might be a solution, but AEAD is not the
> > only one. I would encourage everbody to also have a look into
> > ISO7816-4 secure messaging. That's the way most electronic ID cards,
> > electronic purse cards, credit cards, small HSMs, etc. do
> communicate.
> > And now think about that there's a reason for that it's an EtM-
> > scheme.
> > Sorry, your attitude "there isn't a need to innovate" sounds somewhat
> > unfamiliar with cryptographic primitives to me.
> 
> Please read my mail again. The innovate refers to how the current EtA

Done that.

> proposal by Peter ignores all best practices in implementing EtA in

OK, got it. To me it read like "no need to innovate" as in "no need to
change".

> protocols. Existing EtA protocols like IPSec truncate the HMAC to avoid

You've got RFC 6066 truncated_hmac if you want it to do this way.
Peters approach to keep things as much as simple as possible seems
OK to me.

> revealing the whole internal state of the hash algorithm. The Preneel-
> van-Oorschot paper referenced previously in the thread gives a detailed
> treatment of the issues (admittedly HMAC was designed to discourage
> these attacks, but being conservative is a good design practice).

We've had a lot of discussions about this. Strictly speaking if a non-
truncated HMac reveals (too much) information of the internal state of
the hash algorithm something totally went wrong with the hash function.

As a result of this BSI TR-03116-4 chapter 2.3, 1st bullet states
"do not use truncated_hmac". I'm sorry again for the lack of an english
translation at the moment. The Federal Office for Information Security
will probably provide one later.

In THEORY a truncated_hmac offers an option for attacks as only a
fraction of the original HMac has to match.

Best regards,
Christian



From christian.kahlo@ageto.net  Mon Sep 23 09:12:32 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C9021F9E76 for ; Mon, 23 Sep 2013 09:12:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.333
X-Spam-Level: 
X-Spam-Status: No, score=-3.333 tagged_above=-999 required=5 tests=[AWL=0.267,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScFJZyzuI9vQ for ; Mon, 23 Sep 2013 09:12:27 -0700 (PDT)
Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id E39D921F9E9C for ; Mon, 23 Sep 2013 09:12:26 -0700 (PDT)
Received: by mail-bk0-f47.google.com with SMTP id mx12so1226059bkb.20 for ; Mon, 23 Sep 2013 09:12: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:reply-to:from:to:references:in-reply-to:subject :date:organization:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=TAKMQs8kH9oT6ppXyRoiIZ9CcFePn42Pa8sqPXAqpuM=; b=VEbtY7CGFEFmiFEF8BrzaAas9LHNtlwptBtWnm5cIYWpCxN4bFckV7AwmKmFjSMaC3 KGqmfH5qSAdvsrjYjx9kr6V1IOF99W7fnlXvLC7Zgk2XGDmyDwtpGwCv3TR0gKIc5YtB LNarBORBF+HnZc1ZeU9CKV+z4Qh4eEbaD+bcvtxeNHUPQMptXVY7jR4TMPpXfJZ6fina YZQTNb/QEjDxNUGouAW6RaA567HtGxV3uY/xNRseY/bjV4jlEbyl7RXitNvhV1MgRmkB xNH/rWK9JTLg/YFTv+WSH37TojIXyJDBz0lu7qKMetzoank/baPg0en5m35xJmL9UjYs azvg==
X-Gm-Message-State: ALoCoQnn1W3vIbpmBZePwdeAQhxDHFr9mLdt4JA+Q3a9WkTAZzgO7kK7KFtftByYXFMj6b6C9pcU
X-Received: by 10.204.78.8 with SMTP id i8mr18719422bkk.3.1379952745851; Mon, 23 Sep 2013 09:12:25 -0700 (PDT)
Received: from THINK2 (cable-82-119-12-81.cust.telecolumbus.net. [82.119.12.81]) by mx.google.com with ESMTPSA id l5sm9015087bko.7.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Sep 2013 09:12:25 -0700 (PDT)
From: "Christian Kahlo" 
To: "'Yaron Sheffer'" , 
References: <20130920142728.15100.58320.idtracker@ietfa.amsl.com> <523C5CF6.2040401@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711D4F64D84@USMBX1.msg.corp.akamai.com>
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711D4F64D84@USMBX1.msg.corp.akamai.com>
Date: Mon, 23 Sep 2013 18:12:30 +0200
Organization: AGETO Innovation GmbH
Message-ID: <52406869.c567cc0a.503b.ffffd63a@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac62DoYzoQJGm6p4Q2Sy8rs0AqgiOgCW9rcwAANNjhA=
Content-Language: de
X-Mailman-Approved-At: Tue, 24 Sep 2013 09:33:53 -0700
Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-bcp-01.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 23 Sep 2013 16:12:32 -0000

> > In addition, we request that the TLS working group adopt this
> document.
> +1  This is an important document.

Read. +1.

--=20
Christian Kahlo, Research Manager IT-Security, http://www.ageto.de
c.kahlo@ageto.de, Tel. +49-3641-3678-305, Fax +49-3641-3678-101
AGETO Innovation GmbH, Winzerlaer Stra=DFe 2, D-07745 Jena
Gesch=E4ftsf=FChrung: P. Israel, S. Sauer, S. Scheppe HR: Amtsgericht =
Jena, HRB
210399



From christian.kahlo@ageto.net  Mon Sep 23 22:08:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A09521F98EE for ; Mon, 23 Sep 2013 22:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.919
X-Spam-Level: 
X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.680,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzZuZc9PXnK9 for ; Mon, 23 Sep 2013 22:08:29 -0700 (PDT)
Received: from mail-bk0-f42.google.com (mail-bk0-f42.google.com [209.85.214.42]) by ietfa.amsl.com (Postfix) with ESMTP id 59C1921F9C7B for ; Mon, 23 Sep 2013 22:08:28 -0700 (PDT)
Received: by mail-bk0-f42.google.com with SMTP id my10so1509019bkb.15 for ; Mon, 23 Sep 2013 22:08: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:reply-to:from:to:references:in-reply-to:subject :date:organization:message-id:mime-version:content-type :content-transfer-encoding:thread-index:content-language; bh=Ip6PwwwrHGfBdkYcPKWlMVUCi77e2MXZMSmOQiWfXFU=; b=h1neT24TDqzX59cLY/rxSR7d5cHZC67cNGjFbTycbimDLieQZhSkKJAeaYtxfVXZ+h eTgGniyswj/8g4a5bq2IOfmcj+KZIy5CI2ov627xKDnpTqurCIXKxPfvUBlvDbb28Fo0 fBJwHkBF0QCIeN5v28ivKXBspQWznIfsjeVkhfYwkk2InGCOZ8KuSCIVTQ+yQsYjO7Jy CA61G86NaA/qcnK4G4xU0a7B3Ry3yU4FdXMkdG5sKRB8stgzA09in0bCfDIy2jC6OSwr 6hriGODlDb666sX9q2BhlySAMI1Y097SRXU8EecwVfbZ8fbWtpFEfbHOHAXK6YnWjBae 4L1g==
X-Gm-Message-State: ALoCoQl7Aj+YXJvOd4OG8gafsA6ze6i/mvC+mSeXgnHQtTcVu45MhJVFXgh2n90fNrUAUtnVMXJS
X-Received: by 10.204.233.129 with SMTP id jy1mr101670bkb.27.1379999308084; Mon, 23 Sep 2013 22:08:28 -0700 (PDT)
Received: from THINK2 ([62.117.13.26]) by mx.google.com with ESMTPSA id qg7sm10242291bkb.6.1969.12.31.16.00.00 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 23 Sep 2013 22:08:27 -0700 (PDT)
From: "Christian Kahlo" 
To: "'Peter Gutmann'" , 
References: <9A043F3CF02CD34C8E74AC1594475C73556760B8@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73556760B8@uxcn10-6.UoA.auckland.ac.nz>
Date: Tue, 24 Sep 2013 07:08:31 +0200
Organization: AGETO Innovation GmbH
Message-ID: <52411e4b.8712cd0a.074a.fffff2c8@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac644yexka+JHcxaQ6OFXY9dkTUeRAAAMNVg
Content-Language: de
X-Mailman-Approved-At: Tue, 24 Sep 2013 09:33:53 -0700
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: c.kahlo@ageto.net
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 05:08:37 -0000

> Could people please indicate on the list whether they'd prefer option
> (A), fix the problem with EtM, or option (B), which appears to be "do
> nothing", or at least "delay indefinitely", which amounts to the same
> thing.

[X] A

-Christian

--=20
Christian Kahlo, Research Manager IT-Security, http://www.ageto.de
c.kahlo@ageto.de, Tel. +49-3641-3678-305, Fax +49-3641-3678-101
AGETO Innovation GmbH, Winzerlaer Stra=DFe 2, D-07745 Jena
Gesch=E4ftsf=FChrung: P. Israel, S. Sauer, S. Scheppe HR: Amtsgericht =
Jena, HRB
210399




From benl@google.com  Tue Sep 24 04:54:57 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D571321F9D0E for ; Tue, 24 Sep 2013 04:54:57 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VdQPVjXSjzMI for ; Tue, 24 Sep 2013 04:54:57 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id CFD0E21F9D05 for ; Tue, 24 Sep 2013 04:54:56 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id e14so8497918iej.24 for ; Tue, 24 Sep 2013 04:54:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zGRmPXaZI9adT0qULhEDWOCmco8imVLLO4t1HCIkYD4=; b=QEnjYGB32ZxVHLctVQkZ5aMZ48m+XcpfNSSxyGNBi9bIepJE1XvXC1DilEiK2Yhfo3 +38kGbnuUjlVTUVGlHgpM20GXAGa+0InpDkfZTBfXz8nfTs6FWJruJ1XL5WbgIfq2GdD Du0rB3Ob573gyDH4pn6/0oVchQv9Qzm05cM4INbS4c4SE3kLZ3iSocUhlZT10bO9LhvN kKnDGdDOAp/5C4DKLH2lzHBEEy7T7hjfZ3YSEIAZ9IxoeYLc/vs9YjMVyeiShtVmzVcZ QwYytB6jkK2nSGGcu94T60ZNZ5NTdo+FsR6mtsIMYFhudPsUMyylLchzWXrx0q2kxLrx tgOw==
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=zGRmPXaZI9adT0qULhEDWOCmco8imVLLO4t1HCIkYD4=; b=irneXgPQRiaepspvuLRdkrJl2s+GUlxSKFmZxXQDYAYFEd1ybwQwGHVDQXgoBYFtpN wDdMAbOhuOVr1lZKq7crV6gI2uvax+sg21VmKTtif5vdUZRC5HHKGUrFA52tL9Yl//WS wmugMDjrWP9zh11O7HYXPZXozKRx8fKSrAvxrHTGpMdAeFppFy0HTkP31QhzbkNvbfqc uY0oxVBJirDKQWDvUoHqfA0LHVdGr1qByBTf5K2J3YJi7uXaY0slRksuykrhfWmBfaA/ 1f2beG4wJ3izGiIcBSlXd2a8xvZmBZsVtAuOI7mwXcRFa5Ewc+acHOUHUkxGh/x7FjVH e/qQ==
X-Gm-Message-State: ALoCoQnu0w3NYihN+Q1krt9fHOuZWREndwcaHYZP7I21C5XB39kY6gEVmSl98DfiNmAShUF3yHG+T6C/ALsWtPGxRMrSFJfi8wY4VEP7p/aveU0OewZUWKHtXRzAAwb9m1uThAG3MINrQQzmgs2bxLTIxVnnyZkRPJ1QpWorUcpWs41c9qdyf5CjxUgl/jTOKQeAhfwACbt/
MIME-Version: 1.0
X-Received: by 10.42.42.132 with SMTP id t4mr8207203ice.90.1380023692880; Tue, 24 Sep 2013 04:54:52 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 04:54:52 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 24 Sep 2013 12:54:52 +0100
Message-ID: 
From: Ben Laurie 
To: "therightkey@ietf.org" , "tls@ietf.org" 
Content-Type: multipart/mixed; boundary=bcaec51820f2ff3a5c04e71fcd45
X-Mailman-Approved-At: Tue, 24 Sep 2013 09:33:53 -0700
Subject: [TLS] Fwd: Improving EV Certificate Security
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 11:54:58 -0000

--bcaec51820f2ff3a5c04e71fcd45
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: Ben Laurie 
Date: 24 September 2013 11:02
Subject: Improving EV Certificate Security
To: Ben Laurie 


We invite comments on the enclosed proposal.

--bcaec51820f2ff3a5c04e71fcd45
Content-Type: application/pdf; name="EVCTPlan (2).pdf"
Content-Disposition: attachment; filename="EVCTPlan (2).pdf"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_hlyyfab80

JVBERi0xLjQKJeHp69MKOSAwIG9iago8PC9UeXBlIC9DYXRhbG9nCi9QYWdlcyAxIDAgUgo+Pgpl
bmRvYmoKMTAgMCBvYmoKPDwvVHlwZSAvUGFnZQovUGFyZW50IDEgMCBSCi9SZXNvdXJjZXMgPDwv
UHJvY1NldHMgWy9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUldCi9FeHRHU3RhdGUg
PDwvRzAgMTEgMCBSCj4+Ci9Gb250IDw8L0YwIDEyIDAgUgovRjEgMTMgMCBSCi9GMiAxNCAwIFIK
Pj4KPj4KL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0NvbnRlbnRzIDE1IDAgUgo+PgplbmRvYmoK
MTUgMCBvYmoKPDwvRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDEzMjk3Cj4+IHN0cmVhbQp4
nK1966ptuY7e/3qK/QKZPXy3IQS6knP6d4cDeYCQNAQ60N3vD9EnjzmHJU1p7QNhQe2qtVWS7CHL
ujv9uujnPyX6x6zp1//81z/w321V/s9//19//I9f//ePfzt+eb3m6P34m9eoMzGW418JT/qFn//+
T7/2v/z7v/zxD/90/fqX/2Bcg3CllCvw/G/CsXLqv+Qf9H9+/T0hemPIuc4PhlLKL/nHxmB//xWD
ZdfC/DP9+Hvx+X1ZrzKv+v9pj/K9Qv5/sCT+IdA///bHP/z1+pXnr7+B/fs7plp+pav8+tu//vGf
ryv/1//y62//5/jbRgysE6JdCmLU11VaPkGKApnr1QttygHSJEi+rldLo58gWYGk9mqC2bYURF6v
3No6QKpaTy7jlesluE0KpOVXKyudWP5RgfT+aqucC7rUmvNoryvLnRsKZPZXKpdg908JUq70qnmN
E2QqkNRf40o54KXkRoT6iaV0BVLmq9NnjAi1QuIrIDSSPl6jTLFmjWQWkpaRAlEoq7xWWtFXrLQt
66rR5tZEhC4hC01jyf01U23BztXSSKICoax0PuhT15NZJZW1X6+ev1D5y9/ooOeexy/5B6uhL793
j3Dt63X16ySR1b7XSae0zfN8lfXh4jdVRcMhlXuqN6xd87VqOvcjKylpJI19rkjUGmnK1cXJ0FLS
WnrNKo6gFoHWM/HSSiBIbeCSkOdLfb42E33hFWIh/ZZ7GcHRoLP1SllAVAWRxmuWsYIF9UybW8Kd
67W+cpI719/fmb8qdLr4qlC67Xp/LMUVqShsyQFR/6og6PIqowYQK796XycOLTWrY+knDq3a01UN
GcUqXX2vPvAtXU4S6coLN+RBSG0g2Riv0qAUHiwapBCh1eeJRX3uRAKcJIhec6IvVTp02ENIX751
GELqskqNVsSXlU+I9E+++rmi8hcNQrzIzdW3fJ90+aYW0RmZLqIVfSE6SrSCc8n6WCcIXO012v5F
zM45IlYWcUvH/1yyvnwvuqvSPPc2a5uETuTIRRwPjSUbQimJ45a/Hbf1wae++CSx6bhjl/fBJxG8
1jwgzGHCMRj5xJH1YaLvkJYgo7/DhZNST17r0IcJJ6WvE8QcJpyUlSNCGTKOY+AuKBVS9T2da9aa
kayb29ryF43zNlKPCNV5W37LPZK4diQWYxDjMHVYWw+Id1T8bRkke1dN0YI+R+UB0VqTTKkmQfQn
yiQLk0+Tuy0ZssBC7u4/XTmvzEflIfSnBqHN7S0Sl0wG2bpmjnghWbhGE5vbNQgRkiCGUCVCQqD0
fZ1bfVUpchoHWReDrvXgI2bYw63VQJ7yoPXMsaK9HbBBBRZtyeaZNSGzcSQtixykQKDyIkK9CfHX
HtZar1pydIgKWTqd1OCp5YzLAhChfrTfk9MrSYihIYjZkVvwlcl1f3W6QwNtWio5ElJUNB0Y+Eto
FusYke9UU6QrSR+8Fvn50b6RJJB2Ob9hUbtfJkC64KVqEPpAa4ptUUZQoQtilhRpuUIGWeolWlEl
g2z7Ai4vlQyyieCF/xUrXbEXLSngpebrVRQW7YTRLdzJHww+dCW//yo5UnOVZCFfl9A+f2oQ2pfV
SiDblQwyhUV/xtoBIs7ZpRc9LC+aXVIL5HAL2VVKrJJamApEs7uIkNjbpgEMs8bPIrewjBx9xEZK
YVyhamlkkM0fsKSkedFLbnTLaEJKLBtZHCTONVpRwa7UGWwc2Qlk+Q2xL5oXMt8vCXKpswgvNuca
6dPW6Dsv8Y2yCke1DkKrB0eELsRXJZsvApn0jaowOXTcq5HquKa0J/SK6BKhizO65uELj54i4e4k
DCsLq0SHETq+tMSiTY5OXzpxUMsV706+HJnT0dZ18uVqldaaMvl6y+SY92jNHVGEGZm5vdPO1TaD
A9DJCxsSi1Z0dNxfiSy2QLo7IhpTaFTDLkdsQ43aF32ikaO7c5DhWFJdwRkZZApMCaL3ZdAdsWaO
zusgP4OQfJHuyA0jo9WRCnLD1mrpgNAb9I56HDiUmqHt4WjEAaG9I9jVOZ9UtLdxrR2M8FllL4yU
dMDr9sLo7D8gxvNBKBS5iAdEn7dUhsZiCFUEI2qO2CWFx47aAaJ9OVJ4HDsJ9oUsriax6Osk9TtI
E2DpXfOir5M0iiH0JajBHmGwonkHaYKt46BGKtE3QlCjznNF34MaqQYfICe4nr0FK8pkfF+SkMmR
ZBLMlc4VWTeMREqBaJ+kkg1fSo14aWU7c8GKIAzjmsHuIl+zUknRit5eli8MHy/rwKIdsXVpLMYR
oy9d4YgdINpVhpeVZnAYC/xtMr8DWSgJSMSatZVZMrECf9vntuSp91+ftEJX6CCn8NwWdYXCzbpm
i+SyQHfMq0e8wBWrM5AWeGJtXeK4au+HLuIlt9+CGFEwrPSlP6JxcgdAxrlz1p+7vemA0Lq9aV8s
kQxLCkRb+XSP1Jqj/a90j5CTJK4a46xNdtt9jVpJcyyJxGTD6KZJPyBZmhOzZNItmo52PqFbxprR
eip2ZZRo4xop1CluV63nKqRFghhXDdIiz5Dx9/KPdMgoyT+BWG6Nv4ecc4qUZSPPntwjIU/aP4Jn
n3p0Qlq6Ix7+J0IikKQ/B9LSIAv0pYOv2BDl6SkS/1bJyL9KJP4NEUHETYIVkelCJsN5nv+iIWhB
pbRo5zpxO1qkxBrJwkVWRbTmQV9xthateVayXMaMFjQRNmmn/OtLpJEVO9sQek57UPDbexa3lXY4
kiGk80s9Z43lNxIp+UnvqBuHTkJHIiW7mbOFzCb0Q/O0DLmOO9eS/VxUIuOv5XSAGLONc45LsKLc
6m19Cyw25wijuJaIEMqIkCY5sCjDAglFzipkP0fX7qxC9nOx/c4qBOyOO6sQsDvurMKBRe8LyXBZ
s0bsLhgf10nImPn40qPkQBYyVF5qLVgR281tiN01ycD3RewuOiNq3YXkGkLQZxf5sge72j6sICRB
jGmNKycUqYy7bVXxpU0C430tubsL05oczJDQoN3tkpD+AIhUXr0HpxGmdVEgmtBCIH6u4AOU631z
uaeRsxMSi4mP8+WWBBaTn6BvpLCYJAcut5QjdiEMTZwjY2dW3H9FKENtZzaAzBYRaqg+aSv4ADCL
iwIxNi9ut5kDkSqDvtEoJdo6CEO9ZvQBUDonsRi3BPLyAxYY1wrLN+NagWhLk4zrhhyGvyIUo/VZ
okNC3sSL7lYhUpoXkpcmQWy9GhFaeQXiXWvVWKzVe+cNAkJt7KrPgFAfGos1e+80xwHyVw1C7CJx
E4GAUIvOETIhl8SiNWaFvEiLwdjO8zXSELKgzcjrjsT73DZy3Tme729LI3EZyAr4skCqfScOfPUC
27n1HmlD2M6j1OiCZdt59EgWYDvnKqwKvbnkTb/alCaDSYUM5ORXxAsSZz1FN3kjceE61oDdgSB6
Co5rmwjnC31pkiXIm02hXQwdZEKqUIZaXDgTsi5ByIAQt7NFVzDtyCulGW1LzxddwZfY/3/UIJOu
4Bx9aCRL1hDH1WRl6DZSWLRPwcmS3iJTtpMspJJn8I2QUCnXVYJvRLJPF3nuEaGB9MMVGcSdhCG1
XALRpav1VWddFiR0XoZ36Uyyr8+/VnpoofIVDA1PaN71lAeEDkmjBAyFnQcZk3y4Sy4PEFOViWq0
GAs8JIVF+1lpGULazM/vbIq/IlSJ1ZGDjeOqTFQeH1hM4ebYxckPyG/4oeVxoNWpokslNboDi+uo
I6p//LVxk668PdniBgywxezKFje8wU4oPpTPBxe+Yv8CXhAMRlFgcUNQXIinQL4V4qFu8OBF1+m+
v8IB8qUQD8mzA0KzwkmiHOHo8N7rScZIVe+ajEFy5+gOJLpId9x1vAcW4+reKaJg99ddx3tgMfV+
u47X/8qZxGmQAx+BQJzQKlDcKFZGboFE7gTRriOdWM4K+HKLDBFnBfxvmOk6aQpEBd1ySxqL8bob
Avp5BUKZEdNYLQdfEaV6HHQOCI0d3PblKSOKi7K1Y0Hau0dYDmVrwSciBY+yNZ8TNA7RiY6EpVy0
KysHm8KeMPmXwUllT7hL0dYg+a6gCwjlu4LuANFeeVk7Ku2fxFLvIIL/DUu7vXL/JJKHu73yYHP7
7ZUfhEw1H0LOKdqWcQeL/QOCZikOFgcLWnew+AH56b5K14VU2htaXyZ0pRdYFwfITwghzo9FqDUb
nfJ9gbmGWqrtvsB8kFZIy+Z0gBgVStqcK8mLa6iljqY8XD1B5JII9XUSspHLQS4p5MyPOdIxnxKL
uSnpmP9EaGVDSOvQCz2lcwWLRnAzoyiguE5GvtZ9tQTxz7GrDwJectsZ/wNEq79Sd8b/4EUHFGsi
n1SAGDVL8rL4+vFX1Ghf1rlzpn6bznlGs+IBojV+pzUjJx2A0CnmdLIvC3msnU4OsEwitGAmutKN
4uxV1gq2hdwhun1GDT5RodNd6xoRFrRRJdiBrjcPjb7aasGiUVrAl4srlgUmPd9Q7qEn7XhfLn6s
ECZ9EYfeLAj2JunIU0fp0CZKjiQWU07RsaAe7n+fO84dLJpsiCGxmEWjB6jIrdNXFKmOOsWJ/i2l
/7g0ptvnrfR/2+thpf+B1klBpKu2vzG8c57otm4SxPbj0NUxcj0JmWKxobEYjU5Knx3D4nugUPoS
5KvSZ8fG38VJhNixeUCMRq+vhIaoA8Ro9Lw77Q4QbRUnUm6zzIBdNMtzq92xdVqj5L474I5vpK1i
fMaeIggy0OtVTjpGc5HNNWo7d85cUXT+rjFT8BVhoFe6yqI1s7oeQug0L2NqLEZdT2KXnQWfXfrQ
2+UIQCaXcAXc4nJXSLTOudCdjGvB3ZaCm/sEMLqa7u2exNH+ZqCvWiNBQKqKLqkUnOdCdt6QIFYT
494QZ8jq87bTiQe7Om1GpuBWs278C3VglS8of+PIsZ+X+EI2m0W81EjiUONVkjirVlfT/rcS0sHV
vsJjVjkWN2tACN02fV4j2BZ022x/wg20oTxr+xOuRNWC/kZ5hkyfDIpMcw+OWeVa4RZp5YraTwWi
2UUEZ4zoJHJ9VgoBUFcrrjMzKQK1ChLEZpguRUbnANG5y/Eof08Q2Z3yIOryuYVZMTUSJ+SgRpZn
VaepUMyQBS82wYSOTsmuJoRwYK/RrjTUhpa0AnFqqA0dNUfsQlb6KsEBadyvmXrwATAOYrQieNEr
Qjfm6pFQInvUJMi39NHAOAj/SzeE+xQWk2FCQeYUYqmzOgjmIQnlf4B+ddLt8yRkG2mGxmJSNmjM
rSVShb2kV0oCi0mTkOKoEovttck72+XruY4QTpa3vF4RGjIliG22IUJL3L7aVkBuSGExDUZkK3BC
zP/SyA2VS1zRZjYIGjIViCI0EM4LT9q4iI40yvWCRuoKiWZ2IK47Rgs+IlptOGNmQAJXoaIaw1Hh
mKaxfQ+3qQ+VbfMHkDoMFu0HNMydgfXh9+WTk7fjQ/6kAbotuBCvuA1L6O7nQrxg0XRbcCFecRvp
UPx2cfAnABl3CMnnha6UprDoraMrRRMyWQMixFEmv9edrhROPQQzAvrt2Pjd8CR/UyAxDeiZduUH
JHkoTkxWgRSRIqOdMHJrMqdJ/OVA4tgJ87eNJG7kfn4f0yVDbk2WIN/cmoLuwmDJ4/qREN1b+QeQ
adk1iQfa/j5rsGhU2NV0CXZNa8p1u1h+N3yq5PpcgpA28nPZc7EOdo1PQoQkiK2wI0IFKtztNIVP
orDoMUkIIA3Udfq7i6RBliA2gDToym8pEEz4JGOMSBUia5B/AFmXwWKckkX3+Yq0ZSWtQAZ4pC3J
JKM7dEXyUunMr5FGIC/o7y+pBjtX6RLZETFXXCqmL+YSiQv5wK8iQWzdW76zQ/7Yg06EOLHjTyPo
tLnsiPm8jH77aj4vSDLUIpSUKquvq9x+o98OT6bF9hsfkP+mQRo5heVctLFWE/IzTSzaOB20u+2K
DgC5R6/G3qf7GVtBZkUoBkOoIA4nedHsVsThhvgAutcdMalyleBIw6NoEsT4SOPaUw0CdulIc51k
sC/0pbez7I6maNOya7r32+6xONjVBi1yRZfUQNqgvZD9GpFF0RF8VCCmNZ/kZazoCkD3fqvhNd3x
peeKdhfd+9un9pvd66KrcUR3cEf6cdVTpHTzD2rW0M7g3yPo3ldIzLbQqR+lz2hBiE8WqXW1F0Xq
fbvUrmIYiDKzS+1uy6BberFLrcdXhJZ+fdqAdMSf1DhPN6tuOhvJYm65qW4FBYq4eL5ZdcsjEn1Q
brk5sJg+9LrrlAJe6HRznVJAiE43zzcL2B1ka2IaWHXLCdJYu23+2DpNaK5dHnQQ0r09q+/hZdUt
SkAmeKLJvLpVCfkiM5H8rROLmcPb98w7f3fRCdOaJGRmfZGpD6s2wAIzHU1E/tZl8gwvxYv2GKph
19rpRAh9RgEvzbJrTPnbTq9uhcrHTg92F8LQJS9fssVsYQe8kJ2+JIjNP6ydc3lAtErDKK+MzM0h
mKZEKO2cy7HoS4O03TZ/8GKqiNbOovvsIqF8obX7YNfMMAZIE19am881797iA0SXRSHpeLUICYnL
Qt+wLy4oIlpVaEOTIYc/MOqKtgX+gMTybWoYd4sdn8h0mcPYzy3iZVauWwsWRAqIe9v8U1SW4dY0
f1+GW5vpoJ1DoY+v6ZDGqBLEmMakgDq8F/8roptmwXvxD1otdGFfQjEb1wTSUnuLeEEpSjq3RTer
1n57L77qruP2Xvz9r6Q50J/sf0QMgU5olQ52BVlJtEr75xkt5B3TK48lm3FftP2Cld+pT6jlA206
ce/6hAPkN+oTHmi3KO0BcYvSApB3UdoD4halHSBeUdoB4hWlPSBuUdqBxStKO1akbR5Mskat2AFi
aoz7njHjE0JR2lXLuSITPXsXpfmLRkSxNYj8g0Vfc5kISRDbcUuECFXwGXOBLVxaxC6S20V8aNOT
23aXcbAgJK7RZXzQ+TLLZl/t/oLgdPK97S+Ip5pfNSKEujXJi6nbIG2R0fF8gOgwKWYN863gShTX
MPCt4IpLgSzwTeh+aJgZQ4KYW5lkIaFuzf+KXJQ264h4QVWawvKtKg3FBcGi3yVnwYowSFiC2J5c
lL+tcEX92i87BOyiKm2siM7I9x32bItpyaWvSLZ4IN2FR6IlIQtmmM3Y/ba+Mqzcl9RWsCBYCDwQ
9ADRwTNyUaYE+WYh8OTR45IwU2aSxqITo5gZeqUrUkAYRJPQEx0sGnOnJRb7zgRGRJTguKLOgWeT
+jKHKTNdgtipon3HiPwjgrCjJqQNJ9Q6IAAUEMLgBkSa/DXDiuBBnb4aa9ddmOGLbsOAPASAfNFF
2JErJgJCaGdBOYS/IgwN5WCUf1wbOl7aCBcN1bFWjQhBXLo0GLQBBu0isegIUMOYckSj/POKSTQc
jQr2BXPKEY0KVoRaB0SjfJuiYU65BLFDQxNdWEJJfat1uGYkLh2tTWNF+9+RAs/SMNFYIAtdGiaa
24JGoB6cRTTK9isSlo5hLaPU4Jx10goptRHtG31mDBUNOEFf0w8QS+H4LXP+KU42zadvc/7v6jF5
oLUD9Zjzbon9Y8777RYVWRnc/Q8h/VAGLP4KC8JtcWCLfwoInfwn84znTla3rB1RQ56BeWAxIcH7
mapgQbPvWY/VLWtPnBMQWMwzGFfjbPkB8SWzr+hopxGWukTybTQOZ/arW6aPcmSJxFrhdeftj63V
y6lvF8ctwcdknO15PCB6PfiGaIfxPxAy7jwjM1gzviFaLQ9Cpu+jaCzG3YJHhscXqt93AI+Mg6AB
SNnPqvjsFqR+FBYdJ0rtDqX6Q2JghWNkU/UbHOCRzRKsmY1w9l/cEw8jfPsvQWsIysGbEBdjhPed
2fclCiMluT7Al6gyrh1geyB0lA49wgLCBumu3X/q6x7Y4Dz0MMACly0J3Wust+su0/Y/EGxw7obx
9xYzb7hM2z/PNVeNxRjYpexK7oAQBhPL3dd0uKhcQHwZBZmXYNZExkgpdHa1fCyoRuZ4oT9DBoJQ
haq0Vvq43TF/yZg5LFSYNdKboaM/M2mWOqUKM9XGKF6X6tQY6W0PTvTPByberBWq05YtL7pOAeZ1
EYrQmteGF2MYl7eX6q+ovr1Uf8oMhuSx8+hPf4FnjpFPAbuwwFEQ4d9njT22vKLdhbiInftqgKM0
wBfLxoMDcnTkudgYbyL43LJ5ze6NP3CF7geeW+RvCyxwHpAUEIIFXmp0y8AC57lFAS/12nOLDvWj
sWC4gMSis9odwwUklt+yjp/uLjMW/m0d/13NeA+024z3gLjNeNUtMP404z0g1jpG5ROuH7cIPzWy
sWdOJ4g2j9HGletJyJrHac+iP7AY8/i6k+r+ihDgJOfkXJExj8t+pM/f3Xy9Y/NukyK5k5qQsY/T
1FisgXx3g/tbl8vdDV7d+m3uwGbzNwBB4U2JhIGbtCUWXbLAbX9sij+7q1PzMJw4Nh/09LW7BsAt
n8/jbbj6zYO7ZuaUKP0V4SpxZt4VOgyg3CUAfu/gqrvI9gAxL2jNu0rAxYLZHYoXU8AJ+0uB6Hg4
Gva5kMBvtsvYljaDnUMF7a4ScLstCsRFglg7+24BPbCYsRtZYzH7gng4R1X8FXXDrmkf7HcLaMDu
yHdRg9uHBWP8kiB2egcRQmWxf9LIsbs9B3/R5KDvoga/s4w00C5q8DvLLhLvEWxcTW/nwm+CS1OT
sUH1vJ2YoHnwumsnXJEjzbMHnfunFTMsdyIn6C98J3L8psr2TuT4W9vfiRxX/DHDckqQb0917UTO
Q+hLap47SYN9geeGTlL/E+ElrqRAjL1OX3FJRaetW2RPitAcJqiOF8VRNOwvGuMnd5rGtRcwfpIn
pwaEatoDyP1z1vAsxCXOmbG0W91vpfm7y92BkQ7D8EluNfWthcZtooGtwJZ4FWaWthXaMmTMrHTO
i4TGWsdspySMNRPURQ+oBLFmNux5ccxMuJwfghEQxhCHrb7EideNgdwCmiK7ETW6NdXoA6FGt015
hHTknh//KNGF1wdeW+8hIcyzLvIK1ytCWkRiMTuHEcaXPGXa5UILaBOnTIOgjnesSJ2SmfYiD6AE
m/tp+/PXPDKGYkdXzECPqETSfnRbKsbuen7AuzHwAfn27O8uF/Yb4D7lwn4bHd0ml8RiewfzXenj
s9uvu9LH7Rf49A4GK3r3DgYrIi3Db1JVtxYdzg8PHKxujfhTUex2qaQ19ptU/r4gN7BDzw+I9myu
tadC+SuCf8QTBw9ezGypvCcOHiBmcP61Jw7634jLhTFzwxeGjApRsf/GyEc7GN5eOkBMzfHi94UP
ZjWSNn4i0y9Nxs6nouWsLLCYgSd3S1mw+xNFmblFmzLRJCew2MeD764znxf4Nbso0++AgzxhiMgB
ou13NA/OnINzVshSzRLEJiH6nj4VgKAzsPfoKGIoIc+NOrCYd63oA4zeI0Jkh04M4vE/AOqJ+XFg
/wNwsTBHWd0GIMze5wd3jhWZJAM501mc+d+JZrWn0PPLiGDW4u33a0FJFptbLPvJ9Ta3bveT621u
Ue4n13sQ8nK9za3+fed6m1tP+8n1Htx6ud7mlvZ+cr3Bgt653mNBXq73AfFyvQeEl+ttboHwO9fr
M/vJ9R50nFzvQcbL9Ta34PmT6z1AvFzvAeLlev0P9Mn1Bmt+53oPQl6u9yDk5XoPEC/XG4HcITOf
3U+u98Bi1GzThExqlAt0Uwm2DrNfOSDmHyIeLYU4lX+IeLQU5pAFhCAMCEIFi+YK3ZIiXhCzRDdL
gKXfMyH9L13Q5yexmDgVGjoxE9IXhk+EKdgX1PMrLOZxwGtPlvTlpXKFrlDLNsK089cHKzpQQuKS
JIQJQi1NxkaYEOsSzJqwTknbQDiY1XlNJAoxBjMgVO9y4oOQxvIOMfnS8gkxBXuLOaQrR1uLp2xh
q/gXEdLKbKsECxr3jMtD52pJQNK4CF7M2/Vrz0QL6Kx7JpqvOFC1ORWIDsdAWBDJ8nULJlTxLGdf
oBpm2uO1J39zUdjZJRbzCCEyzz9gwfNsCot5DT4bQl8iWQvDBYIVYVJpm9F5xhOD7UrBSeQxV1d0
WaEnPeHFqIBZvFKBomVftBHu4gEFwUfEyDPEGv31dAQ15xVZWXgkpUmNawJICGrikaCDF53JhbRI
ENuTPvdrRL4oYBCWJqRDb/xSXwxSLbsmN91e+RrRKer8Up8whM2+IHyNbHuwaH6pb0WWC4JZCovZ
FzxfgMy/L9yIdxWFxQzCyjvz7+v/ke6cvb91HPBK31RHGKtqbvPJJ1bV3FpdDkRh/FRzC5gRiOJ3
IJtbzgunhENIzS3sRj8ZP57R3ApmuBxXSSMiNPc8pwPCuBPXTvBGIGsHdnw6GC3FgR0fC2bZcmDH
3zkMjuLU4AOiu4PRcM4Vgw+I8TkqIkjzRGKGPhk69rGJulOQBxbzZMW8LVG/hY7MzCax2H7zpQnZ
oU/dYDGp8XvQUvCJ1j1oyf9EHNq5WrAtHNlh286VSsx8Snj44uDWtGel/TZGQCi32/xzvzP8CYXF
DHRCtQtiVf7mog08SRDrT8w9NvfAYpyFvick+cqFjuGekHRgMa8qrtv+81vF0PxbhOaw/gQGOgks
dnJU1YRsxnru9z78RSMdze99+IvGe+T8frS/IrgLHBTzeUFCuiospskbndX9lBdT7YowH1tDQZdX
2Y9jBrxApCQWwwtmDrFN5RNCJBDtZL54wxlQWExZLXrFUeN4sKvbvBEJxPuZAS94tuCaAovxF9Ie
Y+XL7qef/AD5UmTKA6j8W68lw4vNSBtebJHptccfHyDaqC1lV21GIH0/9xnwgrFEEotOeTSEKFH7
6StvvJnIE5KDFaGAasiLXLPbESULJBdVqDwh2f/OSH1LPWcm3tYfiECYJBFTmIAA5hQXtK1SrXuW
k7/1cBa48c3fERSyDonFJr6vPZM44CXPPZPYv0M6tzEIkN8Ktz+lpnrewCfc/ne1Vj3Qfrj959aq
5pbaPuH2n1urHhA33P5za1Vzy4ufcPvPrVXBgj7h9p9bqx4QN9z+c2vVwa0Xbv+5teqg44Xbf26t
am4p+hNu/7m16gBxw+0/t1YFa/6E239urToIueH2n1urIpB3uP3n1qoDixtuD1qrsKJZgxNSEB1F
99WxL8Y8XrtBKyBUBzdoBQtC+S/S1/5J3PWcM5AWfnSnXyEdLucc4Xr4jSYBYoPtCHBHnLzbpnxx
4jJMPKPhM8tBcoXly8TUMYQyNa8rIPCJNzL874OJqdx8FfBSaEVFbL+JByNkiZanQ8lp+67l25L3
CWF0wbWiY4aRqUlisSNT523Ju9cDzy7I8oB8m13Q5BWirWd+sCO8ZWCxcvzUb+1BzJJt/aBx6h76
4OtTDFVtGIbhb25Ld7PSwa02zTLGWFzROYPZy81KAS/lHmMR8IKwZm3R5uIlh6lAjE2L0tIZsdIt
t15rlS8KrY/bSPd3DrHRH7AgUK6w6DXPbAhpI33hMdtWoxUh8cLegN/ydN3vpfiqkDu0JMjXDi28
3eKfRQxvbShA9SWKo+BTGHwm2svDMGp0K3KHFqZu+B8AcxSaxGKnJCDEHdJBPx/KGwNuSegyBl34
ehnzXXmKhflEcVTZ7YlIGIBZYJ67JbqJlp84ZukWZqJxq12jnIRMVxaKJCUWE3jGTFW4RG7RKw9M
rQiI+bxwbDqfWEyR5Ci7QyxgdwxNyNrnibSrZNe8wbDodC/xAUwF5NyNW82tnc1X381SPi94ro2b
pXxCiF/zILPm1gvzswZizXZIWdpzzAJWSIujEeqBsDHwrpGYIPj7WYOAzntc6sGtrsWk05K5qMMt
HX/C137H2yd87bezzblff/bFMuOVDNSFHiCmb6vtNwsiLHd1qX+KYOZva9UVKB6XOoK95WGp6MPx
dwU1NTwH4AAxRn677UwfBI9gSBBjFjfM95eH1YxC7XeVhL9kuq13lYTfBgVpWTk4Qiip4ceqDyTm
LTYE0nukN3jOaa3BKSvwGrl4wW8sQjaEixf8liB4/qiz9AnxJFT0xPvaHy1Z3M3uSxwedNsGos8L
IuBsILqiwJNQJYjtyXpHwIOerHcE3F80txBLLHpFnwi4zwsJVJKLti7HuG1r9xShYobnvwVbhzZA
dDAdWExnF549GOGKEGVAB5OvxOBQXFx4EHZ2SbVgHgBAfdUlQFRw8KKbSBgoo6PF530RqA1aGARH
99oDoTV44kGwrR0g5hrGu4WL/K0DRBsWJOZcXXCAmNnymBV+nbxoDY4cfafjcLL7pQ1+rRXRqZMO
JRlTBxIzN/7CsyiCFW3YcQFOPkG+zXMtdC8dIPnL80+rCyymy2PhkeuQF/RncGL2wNJjqxVCQVtw
c6W+J1rcMEnggdBLg9hgkMADoT84xsFJHGZhV9qP+h5I9CYnuIl0q/icJMwGxIj/A4v+4HCwJRZj
sXIzZEwIbXKSkLaHEsbY4C2BA8S8a9B3HPdgV2NBpyNepfI3F08mc91GsOiedgj2ANGniZ/V/AHL
3E/GHyBmsHHfzUEHiDb2Z9tPxge7S5c215AEvGDcpMRiVkRaeEksxqxF5yV66n1CGGyseLGzj+fu
zPdFCmF/RcgG9a9tPz8genoJHAKFpZiQfdKL1momo78W5TcHLwak7rHFAbttblv+WLSZ9dC3Le+f
AIwt5lKU4wOYSQ6FS1H8A4BZD2xAB18RxWqCinlgAcMZg/WiIkYTMc8rrN1Q758PDHFgK/3YElMS
07aVHvBC2qei6d7XGxjiMNB0fxAy89T6KyFg7J9VlMTUUVPEC97mRKj3kEn9YMRIe6hxwC4mUg5x
yExEH+2okUrAI2hsyB9IdA3EhZc5ew8kEvF6rvwNsHDvbHSWySXcBdH+pqAevUhWjBlZ564wPljR
xmjTrNgxwiS3U+r1LzPMyMOMTntFizSmDBxqxbyH3DQWaxeXXRnin2VMKINhGsgKikc4LO2fIbyH
PCXIt0A7l6AcIHpYV87EyyzBV2yl7ucVAhA6ZjzEzN86lH3wKLSDFxPdzjsXEqwI6hYNg8HWkbpl
n86XKDxNViQvJqJPHhC7oAEveAIX/qWvLVEGXiSIfQ957ki7bzfisWOOtB8gpmxj7JETAaHS98gJ
f0UIXfPICd8OoIO44/UBuy3v6p2AEAkDT4PwPyN5YGQUCmPZrGiU18jChq0/VETDC1geSYwzQRnK
AaFuUBT+/wCxDA7jXo5dU/2AmCd9YUnhdY0DRFuYyKeipjogxHX/Xaz4yywCnr31gNgqGJjVvZ5Y
dGV2XbtU4GBXm7LIp0oQQwj2O0oFHhAd54ULqrCY3MLklMfJiuYWtjkiwQeI8UDLbew+IGZCAIzd
0oL9x4SAesHY/YD8VNZE4gmd8331aFdAYuWB0ItHug0ZkQfCLJ5zvGudIMZLRY435xNEV+tjxgqy
MwcrRvjWTnc8IOaD8ySdkU5C2h3GYHmJxQY3xs7OHCDGeUz73bwIBIRGjtiFM6CwmHEaePCgn7tr
Hq4et/cegGBQqgLRu8tRrCW+kWZ3zf1y9QFifDo8Z7CCNUPK5+gtWDMaHTJy3wEWDMecPQf7j1EZ
Q2KxL97AMRTfWUeFClzqcorlnyZTlHdX7kFHg7TbRw0WBJdBEjJuLEINEotxY8ftLx9H/ssMC/ZR
D16+ZIrYRw3YRRwBrRu+tMDz49FwB4hJA63duHt8ANMMMXZYzv/QaIZAQ61/oDFqmz1M/4SgHmxJ
EDvloms6pluibgfzWLL2HsmSYQfzwGLSQGk7mAErEAX0FhyiYLxH2jiMcg5A4N1LXox3Qh+Ra6x8
XpDCUVi0zVqTXbTJz5hFm8F7ZHz0eF9QzDXkvpiER+ma0B0BC0uNx8ceTFpDv0uND5DfKDV+oE3B
bMHzdLkfILbc4Z5TO1xvg4fQ8vXjxwu5zaIKQuYSm/cl5oeg0bmDsO+BxcT52+6zC3hBJwZfP/6i
uTI+CUL6W3BlfJknu1oXcxGqALFX1NjPtg7XT8g837/0YF/4xTVW134EFOWJrPR9XvAEwLhOLCbS
h5kPmNbgCwNXJGPOQgCCimRMSAgWjYEOGDoQsMsD/keNPgBP+BcgpsZ63nMJgt3FiFkhLma2xIVp
97UFCyo8m79HsoD7h9Pp/lfE/cOTL31uMT4W6fSATrkHX/q7gkdbOZ3uy3/hzvl+ioKZ2NruwZe+
KKAXj5vRA3bH/T5ZwMu4B18eIPrSnff7ZMHmrvt9soBdOMgIVBwg5hobO7PsrwgBTH5+/sBiJr+2
He7wJapySaBQ79+CnCMF57lyQWDOwd7Wej9aFSy53Y9WBZw0ZHqEbJu+tX6PpAx46fdIymDj8IAW
HbTgO6NoeSksusoDXjZeYfg7Llrc3I+rbDzX9839294039wfaP/m9oMJn5vbD7J8bm4/sPG5uR8s
7s3txyQ+N/eDxb25fV4+N/fyvv9uJBJYTPJ4XT8SWlUTMrGItXYI6wD50mjPIawD5NvljhCWzwu/
uIoQ1nBDWLjcOYQ13BAWdxtJEDth/m6rOQhpd7nO3e0SrAiv96CVJSDUMTlq5kAw0Wmf0csSEMLz
uxjFeIBoowdD6NHM4stL5plPP2BZuyUm2F2UE0kQm528dkuM/xl5xPwIdoUthCS0iPVQMe27zmDJ
/BoUFFtACIU7aLQ/lmwebb92L36ABW894b3vA8SkL/t+vyfYOEjLkCfauLH3FCVfAZVR9oPfAaFx
zyUKvhCsRYwLChaNiSqltIgQgltXOpHo4r9rt7v4JxHN+gWDfo4lfxsNP1uLsCAqlccMloxO/DIk
L+YxVUTiciQKtd0DtP1dQSc+D9D2P2Ltd+fBQchYEferoQGhcb8aemDRUQQYlDMUbjQt8TOcAci6
n+H0v1FD7Qre2PSPa4NBKXbu2/T4ayVxoHUdYr4HaPvb0hDzIKskOGcNMY8+I6MD0+NTumawLeiy
r62kiBckzfMVGR14EGpJLKY8k0NXrUb7QmqhlxHdVnjtaRLu4KLH1K1UR4s+NAaLoyUmIERqobcR
3b94b3UtYUbZt5zoA/SIDtqNyAdsweb2NNGCHnxEpGyva5WIWTI5CslmYIp10hxTgXx5k/VKkeJA
s1Ga4gzpTncM7ipCEJJuaiLV0lcvEQi5FlcR0p9MThdZ6p4iLLOiRE+YCnpvF0ncbGL7VTwVQ7lI
xiI1N0hWyHYcwQEZdIk0sWatTskfIy13RbcZaVv0eq3gGw4IS5cHUU8ZI2Ehq/GLyIWdXJiV/p0m
8scJUxQeEOMroHvnRKEThbXQaWvpRPFtSj2Gdj0gv+Mozk9AOGnn5O0oHiC/4Sg+0K6j+IC4juJ0
Y+YfR3G6AfGPozjd9MnHUXxAXEfxwOI5igEvb0cxWPQ7xDvdHMsnxHuw64V4fV4+IV6f0CfEO91k
zifEGxB6h3inm4aBi8dvxQYgGAoieTETMvr95lbAS58aiwmrjnvE8NTZkcPzukcMB4TgvyFoHWzd
ukcM+7zw+18IWvuEEOPlEcMHFp3kwnNNaUZ08u0nHiDaxSiGFetXXXtOccAtRof0JtZs5jdjlHGo
GPgl3iEVgxnO3PbQXn//2fVq4kh/db3yuSB9gxe48sgxHnpR7xzKClDEeoCYEO/kIlafE9Sf8lOw
/q7ww13oEvO/M+akcYneAWKykPcYAV8UeF4Emrd8/cMzkyWImSqGAC4qCv+OGwVXVPM28bmi2m8j
xBX1gfavqObt+XNFNe9UPFdU8z7uc0U9WNwrqnkf97miHizuFeXz8rmiHiymlKbv/pSAl3XPGTpA
tPr7XFEPIa1nP1eUS+i5oponrjwVCSHGA0RfLsXwYm5UXFESxAYq2x5xf2D5MjWU63qCFSELiUvM
p8OPZU4huqYKJisk2dxhac8zOkBMZ0Pek4gCVt5TkY4zpwNymNjX23lEtO/BSUgEXgMs+R4idICY
G+raIVP3/H/raUTU7N5Dp6fxgXB7Gh8Qt6fxAPF6Gg8Qr6fxAPF6Gg92nZ7GgM67p/FA4vU0Hli8
nsYHxO1pfEBMWSqGMqxLbItJZCQEG+fJrpmrtnZz7wFiBquhhj4H25JzeU3SV8H288SFmVuEhV9H
vU5uTS9RRR/nLIFAYZ4CZD9aUMfmCtn+yWcFcOvvL+H0cT4QXh/nA2EquMd+MvqAMIep70vwATG5
LcyswXjBA0Tf2XgtAOMFD0Kmj3Pup+IOEH2YEKL+AUvumhdzT6IUV4Fo9cCPWuLs+ytCqyfdp9HW
8aOWaQZfiOtsMQ4xWFFH+l9gsc/WrR8JkVWtCNmTbdj99to2v/wdEIJI4eXvg119ViBSePn7APlS
Tl5Qi+t/o08V7QFiCm37vvn93cXQcTYxfKmDFdJ+wILWAoXFFDrdlfgHiBnbclfi+7sLK4S94ICX
fveUBit61+sGhPpdXuyfADzrvRXnQ8iUS6VdABbsC0o94cAGvCAYDl/aF0wMcOT5MId461RnSjuj
emDRVT8Zpba5B7zAJU/ItfmLRsFUrVKpmnJclJ3Wkxdbjov61hGIC56cq3i02FcMqJdaEsRwiw4y
lHcF3KJht0np1v72Svs1GP9DoxiKy7v8zcWAxt5LD6S7ckqjR5qZGz4lFltS1bbDHRDinIbAYrxp
yMIPhMqlCdkHt+/mO/+CxeQW9uz93UVRFY8UD9gleWkSxGDp6KwrgViiGopuvUgvYORK6TmSBYxc
GYQ7kG7uG60j0guN7Ey6KCJliIRpk1hsOjTv/G5ACD2JbaRgc5ExbRLEji5H5mPVYOtaQeajr2hF
aFtUWMwMx6EJmcGJEJcfCCEJprB8echo1BQJHSY0ZgliM6bI5Ugl9eUpo9GEkjJbh1kreDEmIESO
8zW7WJFOE6+2353xF40hjqOniF283J3I+Q/2paf16gpEpzLJvRkj0pfIqq4i9IId89hfeYpL2nSW
1voiWtGSSVpWF4f+W5Mr+bozYoWsjjrkof+N/gbS9u+wgdffcID8RmTxgTYTzvPaScADxAQfMdAL
9/8HxAYf++1UfUCMx4SpbJKQcR7Iod+OTAAy95vXB4jOSSLgxF7K8r4cJrxgZvvBrXmJuu2Z7cGC
UCTJjoFPh4sk4Rg8WL70mcasIK74AytcAClZMTYnCiBRsOBzy90N7KM8ovClvY6H0D8gJlSH7NhI
PRCo3A0h25dw3f6Sz+6oew7msWht9GMkexfsmq3DiyK9lugDkKHH4+79r1guw4vNjhle7JTFvmdy
HiCmMhGlrmUFi+biRYXFgGAq21yBvPDzpjnlYOtKTXtmU4ClXfutrQOLMfrnnk10gJjixXw7if7u
9jtVemAxLRBtP011gGh2SRgqhv0cK9JYIAxIxB0g2utCxmG1HH3GdQ+I978R0mxNYjE9eOn6iVBF
PFsSsl0SGO5+4jAvDaGOVdw51uave96Pvyu13JW5/kGrFQ+T1h7x0tBp1FegOtAlMSSIYRe9U13o
S30vYp4MdyYG7I65Bwv5RwTvFW1/1ecFo91LjwSqrut2aX1e3g+c+luHKsnt0rpb93ng1GcX4xr5
LXb/uDY8h4vsr28v8Oul7CO6Bw1GP4/LDAjx9IArZLfO/QKTv3Uok+SB6v4RQZkkzzk/2DVGP7Ir
OVKpbd5zzgN25z3n/OBFf0aUzEos1lxHJHFE1li/ULMsCBksaPZmV9Nlt6PZbsozbUoc7xc2fa3b
C0bPiQNrvAvMH7rECTAFmTwRTpoDurAQwcYhjAqtdWHTD4nFvMiKSOIPhN5D132R6txi1aMD27nF
Sp6j623r/zP9/D9yy3PYCmVuZHN0cmVhbQplbmRvYmoKMTEgMCBvYmoKPDwvVHlwZSAvRXh0R1N0
YXRlCi9DQSAxCi9jYSAxCi9MQyAwCi9MSiAwCi9MVyAwCi9NTCA0Ci9TQSB0cnVlCi9CTSAvTm9y
bWFsCj4+CmVuZG9iagoxMiAwIG9iago8PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFz
ZUZvbnQgL1RyZWJ1Y2hldE1TCi9FbmNvZGluZyAvSWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRz
IFsxNiAwIFJdCi9Ub1VuaWNvZGUgMTcgMCBSCj4+CmVuZG9iagoxMyAwIG9iago8PC9UeXBlIC9G
b250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL0FyaWFsLUl0YWxpY01UCi9FbmNvZGluZyAv
SWRlbnRpdHktSAovRGVzY2VuZGFudEZvbnRzIFsxOCAwIFJdCi9Ub1VuaWNvZGUgMTkgMCBSCj4+
CmVuZG9iagoxNCAwIG9iago8PC9UeXBlIC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQg
L0FyaWFsTVQKL0VuY29kaW5nIC9JZGVudGl0eS1ICi9EZXNjZW5kYW50Rm9udHMgWzIwIDAgUl0K
L1RvVW5pY29kZSAyMSAwIFIKPj4KZW5kb2JqCjE2IDAgb2JqCjw8L1R5cGUgL0ZvbnQKL0ZvbnRE
ZXNjcmlwdG9yIDIyIDAgUgovQmFzZUZvbnQgL1RyZWJ1Y2hldE1TCi9TdWJ0eXBlIC9DSURGb250
VHlwZTIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovQ0lEU3lzdGVtSW5mbyA8PC9SZWdpc3RyeSAo
QWRvYmUpCi9PcmRlcmluZyAoSWRlbnRpdHkpCi9TdXBwbGVtZW50IDAKPj4KL1cgWzAgWzUwMCAw
IDAgMzAxLjI2OTVdIDM4IFs1OTguMTQ0NSAwIDUzNS42NDQ1IDAgMCAwIDI3OC4zMjAzIDAgMCA1
MDYuMzQ3N10gNTIgWzY3NS43ODEzIDAgNDgwLjk1NyA1ODAuNTY2NCAwIDU4Ny40MDIzXSA2OCBb
NTI1LjM5MDYgMCA0OTUuMTE3MiAwIDU0NS40MTAyIDM2OS42Mjg5IDUwMS45NTMxIDU0Ni4zODY3
IDI4NS4xNTYzIDAgMCAyOTQuOTIxOSA4MzAuMDc4MSA1NDYuMzg2NyA1MzYuNjIxMSA1NTcuMTI4
OSAwIDM4OC42NzE5IDQwNC43ODUyIDM5Ni40ODQ0IDU0Ni4zODY3IDQ4OS43NDYxIDAgMCA0OTMu
MTY0MV1dCj4+CmVuZG9iagoyMiAwIG9iago8PC9UeXBlIC9Gb250RGVzY3JpcHRvcgovRm9udEZp
bGUyIDIzIDAgUgovRm9udE5hbWUgL1RyZWJ1Y2hldE1TCi9GbGFncyA0Ci9Bc2NlbnQgOTM4Ljk2
NDgKL0Rlc2NlbnQgLTIyMi4xNjgKL1N0ZW1WIDk3LjY1NjMKL0NhcEhlaWdodCAwCi9JdGFsaWNB
bmdsZSAwCi9Gb250QkJveCBbLTg1LjkzNzUgLTI2Mi4yMDcgMTA4Mi4wMzEzIDk0Mi44NzExXQo+
PgplbmRvYmoKMjMgMCBvYmoKPDwvTGVuZ3RoMSAxNzA3MgovRmlsdGVyIC9GbGF0ZURlY29kZQov
TGVuZ3RoIDEwMzM1Cj4+IHN0cmVhbQp4nO17eVxUR9boqborTUMvNDSIwG06LAaURREwLq3SgBIQ
0WijIiC0gCuyiFsSk5jRYKJmGTWTTGLMopO17TiKmcTsakzMMjGJk8XoxFGzkDiZzEyi0v1OVTeI
TvK998173x/v95u+nD6nqs6tc+psVdWJQAAgFFaDAJnNLe7mQYO7owAiDwGITy2qXej+Q83CswD5
6QAhtyysXdYsPSq/BECi8S1tweK62j+E760EGIg84s2NC9uWvTnpaAKO5yE/NDa6aw03qJ8g7w8I
V2Gz/s0brxeQfh5heMOC5XN/q3gzAWwLAKz75zY3LPx9kkkDMLwLIP2jbmmbdr0ybifAgGUAtLlu
YW2znP1xM4AO55c2A9Mdocmz9WC1YeTfIVYF9nmqdm8Mw3v+uXK5v7znjLpTWY9NHeeHwDvKLb58
APVLf7l/mbqzbyT4oQ7Wg9+loEAJSEDBCBlwHfadk/6BtiIioM0Y5zmEJo6/ovdCsZgNSQjrxCMw
SnoMNpAiKMaxl4OQiWMrED+F8CDCW9h+AcGBcAjhGoSFCDEINyNMDUIlwkTGz95FejObh2Fsp8pX
Q73YBaK4FvvfgHLxLOIJCENhs9QE5dJI5BsB+4R3IUu8D/vDsP8psEixiOuRfyniRsQ7YZvwJ8SP
glnKRL5nIUx+D8LENoRNCA1Qj/IO02P+HsTTUf6vxWz/j2I2KRWH4XvtsFb4B4xFXCJWwVj6d6RF
7K+GtbQYyul3YBZDkJ4Fm+VHYC3rF0s4/1r2jjAQNgujYKyQDpNw7Hrha9BLP4BBpKAXvkd4C1JR
bjLKezuA4QG+bgZs3bjm3jVx/ZlOPwNcx6rLgetXDKNpsf85hNf6dLsSUK/+IDzJfEVSUZeXEdYI
D8F1iHsQlrI5pN3QxMECLyLfiqC/V8jfgUkaC+ORHhb0ZQA2QQqX7YZc9J9LXACJ4rswC+38FbM5
wjhpBpTIF3EtVTCK+Z/FXvB9oxDrL+d2eZrH0E0Iv5NOoN8wRnttxeyjfA/jFTd/vwrHq5BvB8Ij
2P4M4SCbT/gBMpjdue+vwXezIQHHnkB4X3wYcsS30Ve4fmwfCb7ziFIKo7gcFn+9eEIg/ugIvwfh
JNIN3Ecs9jCPev3VC8wXTG8Elh/PILyDttsesDMpwfYbQfw7Mczvo3Mgi8Utxs4wFqMsTnD8GOaB
Ae04iuvfgnosRLuydd0PFxC2o6/2yWvAjTAZ4XruL7Qtsx1fdzas5HmKcUvPEYL+MLB8YjGNa3gs
KHMsiz0eU72YxT/mBb77E7MNtwOLvV58FrZI65CH6cfsw2KwF2Nusvy4DD8ciGuuXy9mtmPxyHIW
8yaI6/p0whzmecTwjzCJ5wPGay/us1OfvSCP15Yssl7MgluZrvR7eEdK82+X4/zb6Y/+7dKbCHsQ
zmE739/eV3MsCBMR5kK9dA3quhbtkw9d4v3Y5wFVejJQa8SDMJf7mvF3IEyDQeJjWBM2QpIcAxPR
bno5Azpw7pdZH66pXHge699c2IjzbRUb0X/YJ94CG0UXxKE/J7JxYT2+izziDHBxvllwpzgKYoWL
YBGehjJsTxTvhJswVifivBOF23DuRrgN6/O1ohl1exVulS1MZ/82LoPx4zjrQzmbpQ8gXxyE+j6N
+pyEqWxtyPuF8DIMVl6HBKUMec4hz1+Q5wEI5+t7GVTxDsTrEQZxm8SxuZQkzOmhkCPVYB8Cewdx
gvQ9ZHHb9bfPHpT/A87L5jyDOt2CuuZwO3YoKTgXxof0DeTL47CP2doLOYqZ7wHXiLFQiGsoE21Y
kztwTdvQ1jVYO/4CFcJ2GCrejX0McFy8CQZJ7ZjPy5G+FsaJs3k9XiuchwJhG4xCbJRzA7bi9hkD
C2UjrJUHI/055EsrEes5/xjpINJZuA+iLHGO/yKTzecphkI6Dm03zv85XeJ/Q94Kg+Ry5EUeruN5
zDcmF23F9e3NlStz68p8CeLevPwXPDKYL62oO8rC+vM51vfTiJ9E/CziPyL+BPN5Jas70nuwT3wP
ZeFeyfcrtl+G8Ji4szcn+3LQgv7Ivzwfr8jLW4L5mBzMx6wr8/BKzPZbvudhzWI1iD6G8Ry0Bdsz
WN3n+wbW/l7eK3Hvu4G67v8RzyB5dA/kiSfYPuE/L9jgbrZXqV/CelkHteivdqUc5WOtDNbDOQhL
ER4RP4C76IdwCwOkdyFuZnsEO/oET00Wdh7CQ9UABBkuHbIEznP5BwcFUZIVNUQXqg8LNxhN5ghL
ZJQ1OmZA7MC4+ATNlmi/Kik5JXXQ1Wnpg4dkZGZlDx2WMzw3L3/ENSNHjR7jGDtufIGzsKh4wsSS
a0vLJpVPrpgy9bpp012VM2bOqppdXVMLc+rq3XMbGpvmzV+wcNHi5iUtrW3tSzuWLV+xctX1N9y4
+qabb1lz66/Wrrutc/3td2zYuOnOu+6+59ebt2y99zf33f/bBx7c9tD2hx959LEdO3/3+BNPPvX0
M55d3md3/37P3q59z/3h+Rf2v/jSy6+8+trrBw4eeuPwm28defudd9+D949+8OFHx/708Seffnb8
8xMn0VercKUrwIHnxhFwA7mR3EX89CB9g34m3CB0CrcLDwlvi3pxkjhLrBbvjL81/m+aUYvU4rVE
LVnL1IZqI7SR2mitQLtRe0TboT1pk2wRtihboi3ZNsQ2O5EmyomGRHNiZOKAxPjEtMTixJpEd9JD
SU8kHU56J+n0OXpOuUD9fnZCh20o+zw9gLKPoew1KHuD8LBIxHBxsjhb3BS/Ov57lB2hWTWNy87W
8vtkP/wvsmcGZZtQdkyf7HqU/XhQNpyTLhC/3/8FgN8CNgCfCaBnb4+3Zxdzf8/ynmU9HT1Lewq/
eOiLnBPBoDhx64nNJ386cevJv548d2LZSQ/Ayc4TppODT2on4z+f9/m7J5UTnxzffPyvx/EUf3wH
QtvxJcerj2ccz/z03k/v/Pi7Txd96mLzSC/y4FvGz+XZAeD0cMzaKz50O32M7v6X3p1X9vSN3BWA
nxlZTddw4kl4GNbArWQYbIaz8CvYAOvht/A7eATOQydR4Ra4G87BX+EO+DusIzo4Dt/BA/A4/A2+
x/vRdngK3oCD8DTMgTrYBPXwJrjhEByGd+AtOAJvw5cwF96Hd+E9eAYa4Ce4Ez6Eo/ABNMLX8A3c
BvOgCebDQlgAi2AbLIYl0Awt0Art0AZLoQO+QsusgOWwEq6HVdAFD8GNcAPeYm6CH6EbniPHyJ9I
KNGTMBJOBCKSj8kn5FPyGZGITAzESExEIcfJ5+QEOUn+TL4gZhJBLCSSnCJ/AR/4yWlyhpwlX5Kv
yNfkG9JNviXfkXPkr+R78jfyA/k7uuYj8g/yT/Ij+YmcJxfIRRJFrKSH+Eg0iSEDSCz8Gb4gA0kc
ZguQeJJACaVUoCKVqEwVohEbeGAXSSR2qtIQchVJIskkhepoKCGEwin4C0klg8jVJI3qaRgNpwZq
pCZqphEknQwmQ0gGtdBIGkWtNJrGwB9IJski2WQonIYzdAAcg5PwCXyKte0E/Ak+J6PJGOIgY8k4
Mh52kgLiJIWkiBSTCWQiKSHXklJSRiaRcjKZVJApZCq5jkyDB8l04iKVZAaZSWaRKjKbVJMaUkvm
kDpST9xkLmkgjbCFNJF5ZD7cRxaQhWQRWUyayRLSQlpJG2knS0kHWUaWgxeepYPo1bAH9sJrdAzs
ht/D63AzvAJroYdmwr3wLbwKj8If4SV4mYTABbgI4Bg+tcQ2cUJxUaGzYPy4sY4xo0eNvGZEfl7u
8JyMIYPTU5OTrrInJkRbTEZDWKguRFVkSRQogXSnvbBG8yTXeMRke3HxYNa212JHbb+OGo+GXYWX
83i0Gs6mXc7pQM65V3A6ApyOPk5i1EbCyMHpmtOueY4U2LUuMmOyC+k7CuyVmqeb06WcFpN5Iwwb
Nhu+oTmjGws0D6nRnJ7CpY2dzpoCnG9XqG68fbxbNzgddulCkQxFypNqb95FUkcTTtBU54hdFNQw
JtYjJDlr6z3lk13OglibrZL3wXg+l0ce71H4XFoT0xnWa7vSX+q8vcsIc2rS9PX2+tpZLo9Qiy91
Cs7OzrUeU5pnkL3AM2jFqWhcstuTbi9wetLsOFlJRZ8A4pGSjHat8++Aytu7v7m8pzbYIycZ/w6M
ZEvsMxOO99KAuqGGuD6bjemyvssBc7DhWT3ZFWhrMCfWC46MtEoPrWEjL/WORF7HRlb3jvS9XmO3
MVc5a4J/SxujPavnaIPT0fr8Lwn/cFzzCMk1c+oaGa51d9oLCgJ2m+ryOAqQcNQG1+rclZmB/LU1
uIgmZobJLk+GvdljsY8LMGCHxnzQNMXFXwm+5rGM90BNXfAtT4azgOmlOTtrCgIKsrnsk137YKj/
xK5hWuyzQ2EYVDI9PFHj0SnJzk5X/VxPQk1sPcbnXM0Va/M4KtF8lXaXu5J5yW70DDqB4mxcIn8L
13YFdy8zW7mSpGouGitUMm9hh1aIX/ZxI3HAiO7iTebRcSM1F9ayXjaUEuRg1GXzYENIGl/MhgT2
6vjiWFulLfD5L1SKDeokJXnUfnMZsaNPp4CcX1QtwM0UGqQ53QX9FLxsUimoYHC2n9eTMlsEBeMb
KnNnce+QkISZi30Up+FdzIvRmgfKNZfdba+0Yww5yl1sbczW3L8lU+wlk2e4uLeDOdmp2kumdLJe
e16gC7TOCR7AcHJg4uSZhwV6C7HydHYW2rXCzprO2i7/6jl2zWjv3FVS0tnsrGFiXWjCLv9z62M9
hbdXeow1jWQEm98+ob7TPsU1MpYHZXlfsnro+KmuoEJ5wQDlA1hBxu2yk3WTdznIuikzXPuMeNxa
N9XlxU1rfM24yl1X4Zhrn4YVmffSvl7W0lgLSgiWBS/uZWwodp8DYDUfFXkHb9d1EeB9am8fgbou
Gugz8j78DEYpuqkvPkocj5oiCx/pInpvdsJDXSTS4U1IWHwwy7YIYSHCAoT5CPMQmhAaERoQ5iK4
EeoR6hDmINQi1CBUI8xGqEKYhTATYQZCJYILYTrCNITrEKYiTEGoQJiMUI4wCaEMoRThWoQShIkI
ExCKEYoQChGcCAUIXSTXu1hFNNy7iKEc70KGhnkXMDTUO5+hbO88hrK8TQxlehsZyvA2MDTEO5eh
wV43Q+neeobSvHUMXe2dw9Agby1Dqd4ahlK81Qwle2czlOStYugq7yyG7N6ZDCV6ZzBk81YypHld
DCV4pzMU753GUJz3OoYGeqcyFOudwtAAbwVDMd7JDEV7yxmyeicxFOUtYyjSW8qQxXstQxHeEobM
3okMmbwTGDJ6ixkyeIsYCvcWMhTmdTKkd/gLVFvT9KwEF8I0hMkVWQmFBVkJToRJZVkJpQjalswt
ji3lW8TMdcRwO9m45sE1z6x5cc07a6SNjQ82PtMo1DQ1N9GNM8nGGaR5OtlY/mD5M+Uvlr9TLm2c
/ODkZyYLGyserHimQhizatIqWr6yZmXzSqG5jDRvJJkbazY2bxRgA8E/x4bmDRQ2ZG5wbCjfUIMN
2djsaKY1baSmlTQXEEhNxYOy2aQ6cg1j3o4ihu0J22k0Ot2CEI4QhqBHCEXQIYQgqAgKgowgIYgI
AgJFIAiOVYDfJ6JV26cW1fZhuGr7IEy1HdWrtvdDVdsfdartvRDV9q6q2t5RVNvbsmo7Iqm2t0TV
9qag2g5T1fYGUW2HQLXZw52JeqdN59RUZ4LsjBedcdQ5EJwD1Gg1SrWoZtWohqt6VaeqqqyKKlVB
LelS/BUlHrV8pmsXIRsqPeYSKJk6bh8Q4r/1jrR/89M6jsSVeGKnuDyb4ypLPNlIQNyuKBhXWaJh
y+7ZjAXJkxlXmUZw7xxHsGTtUnF0/KwAjjI2j96Vm+ts0gK7ck1lwa5MaH42GzIhpjm6uZV/2tpa
r/z8uwr/Nz5taeyudhphH8QgWMQMsOB98QzCNwx8eFuTXsW741QAgf2XnvfxljUF8SHQ/dL97N/+
HMK71RG8se2G3tvgfuw7BLfjHeo+7L/UA3hXe5y36/EGdTNybEaeXvo+PIf366eZZDjeax4hH0Ih
jcb7xysASH8NX5P3yI14W4jA+0QjSYc7aA6pFMZIEtK7YRG+NZu8Rd4Sj+EtbhG+8UeoxttTOiyj
75JNwo2wmq7GEabro77tkA37UN7/9Uf93/qj98P8wT7MH/8jn/8hfyBX6v/D5zV4De/KgaeIPx29
D95YBXovPUwPC4N/9vlJ+EmcL86XCqRfy43yC0oIfyYpX6hD1V0h6fgs1YXomnSvhhbz5/P/PP95
/vP8//6wogmryWxhtTgbBFAg2REl3S/8VrxfASvkYhco9xNsAmT09HSTjOoqRFmZESabKclmsq0W
oGc1BR/gFNCD+wD7Nb3cf0ZcLv0RIuG0Y8OZSAKKSoTpCqE3GMmKUBIpE2EdbIWd0IUF8xicRbGK
3qpP0efqRdBrer1corfKTlM0o0zmsDD8jsqFM0DpBpxpmYF0WAh1hxCdMEOYJwhXG0YYqBCq30J2
kL3kIPmInCEykDN6QlSIhnUgsOnX6nExXf53HVaTSS4Bi97BsD5cmGAJmRAeYhFgzJhuY7fxSBr+
VVdVVVdlV1eZhiJVxVvVVcT4YVpaN35VVx2oCvRnZfIBJdmeSE0W89DsXKts08BkBFu2OGp8zdsv
f/ndC28vXvS071vfSd8eUkOs30m3PFHo2+07f973xl33PkUeIFNIMfGi3XAfEQnudaEwy5EUjXe2
Ip1OUaxKipKriEoYFEgFipqi5qoCqCHMNmqX/4LDwuyj6kmxKEpQHCIVq2oIDazFlJ/RzZWurupG
vatGGk+hxsRki7QFAff1U76BdOvFbcJ8SfI1Pd5zbre0bzfz4j78ugm1EaDakaVIJFUiQkE0bjN5
UAwuaAS5EZYBc6SooCeZ55lOMJDpg4Y+sZvbucv/tiM0JASpIhFUwjQjxn+wI1d11ZKW7ipUaKhp
qGnfIWnf+SIIWEH4AeVKMM4xUBWjRXpIPCaeFX8URRAKQCxSQOCCuvw/OMK4sCJZKA7Ojes9nZZm
PG3sxukDU9siNx+im3H6C7tZtJf73pPO4enNDHHwqCP+ulgiNA4g062E5hjbjVRoCCfUKKgEigY6
w1HGbiaMEY5sJiw8IcqZmpCX4EoQ1qpbVJqHnKqR+yAeZ59AjEJozAQpYkKoFBLKYgpDqtucn3+0
Gy/tDvOAiKsjRkSsiBAjY5JicmLaY8SqqkrCY6qqqtt4HAPsdDayV/OIy8qsguoqSdEE2R6IKvYt
RdlIMNzM2DoX3/PDwwlzfV/7DpLRxEiyiNP3x4WE9Ex87pWDv3/7wwWvEnsY8ZAKMoo85Vvq2+ZT
nt8mrfe96zt/0fc0ySeRdHgga4V1mLXJ0OX4lXoVUYwEkjSn5tbaNfHqUCIUp+5MpY0RJEJxKom5
iQ2JQuIAGODMCydrwwmEp3SIaMJ4d3x7vJCT4ExwJ7QniDr9CP1E/Tz9Cr00NJEIyKsLTYgXk4ot
LkujZZlFtJhy8ZwynTTgKYVlrwIkyTrBJE5ICjH1ZWR1lfFIldmaz5MukIhIdb9mPIpfLIKAZ2hV
bm5U1NDs4TnDklNSkpNzhg0fmm1VkjE35UhLVJTVGhUVaRHtiVMn5O0Y175h0oNLN3ec3fO36mtS
Hymc2351Sduyzct9/zz+6viuQbmr6ybeWJJb+NLaR45NejpueNvMvFmj8/KLXt/66Gm0lRkz9W6M
UQVGOVJSFJIqEuVuIt5NClIoAcoTgSayoKBKsVgsUVWiPBSwgvJsPG08XcVT0W6y5dgi6ZOHfEPE
myTp/AVJ2r0bJYT5vxEfQwkyPOjIE2uMRrlEdOgN+G3U6eSSIoy6XBHrG14CU1WXKkqFslBI5aVA
lxJMlPYiQojY5X9pd2IKvtPl9+weEMeJlxzJliikrgoNlUuKRYKzWMUUMVecLjaIHaIM4gYSIlPK
9B2DSdSyhOUqyajqzo/JiGbBzJ6q6hYWnYBDkp0MJWQovcfdc/w4WU7mf2SRjlx4Q8xlueb/Rjgl
jodYSCLJ+yDJ/61jFLOKEmGNoKRB69AoTTUUGyjsNRw0fGQ4YxAx6CINUm50UfT06Ibojui10Vui
leikUl3pukgS2eU/50g2oBki9WyeyBRbWZ5EQNIzi0u8T0oeIRAhCdhSJ4cha6BaLQMRaHTMwAqd
Gl6hGqINqYY8lOwybDXsNHQZDhmOGc4a9GAwT4yfEU+F+IqdapdKXWjneeoKlQpF6nSVgspmjYiI
wGxX9fYKqq8wx4TSULPCrGUMlNy0QO5WofGMn6GvjR9gCBs/q0o7EtxCWB+iJd3dB6qMr5nMfcmO
YZyWJNsTMXSvwtA12hOVlOEYxFGRJos1MjFZCIQy7jL0VMvXN+wjcZ+NvPast6Z8+IvTv3x/altr
2oyrNu15fdPilRv3rnv45AAi1jyYPuboGd/qOzKqx5HPLfe4d9zGauxY9Mvv0S9WuNPR5JTIQ4QI
qTF5MRTWhm0J2xEmUFDCGCmEKWV55mIzXWveYd5rPmg+Y5bAbGbWNvOiZ45O0uXonDrhanGEOFEU
BH2FEmYNo2EGUsE2X9wWxIpIXYUhNFIJpDM3yWfMOr3WqOo5WjUyaDTMib6M5bupPRFy2G4aJTwz
O+7uovv2PPfo6ptL7v3zJ74/k0GETnlFOParuGF/euH51+u21ZHkCwTI8EJW53GN4kBcYwwkkrGO
JpeVCF0K6VR+ozyuPKccVj5WZDpdIo3qMnWdulXdqUqpap5ajMl0qatLPaQeU/UwHQORqka+5wZq
fUJZUTyh1mgWqA08SHdE740+GB0S3eU/xbcMRjhKGXM0iS8jZWuNJM9YbHQZG42ikcerkcer0b5W
2aLsUARIkXKlImm6JFKl4mp1hDpRFYTpaoPaoQqKalUpBt9RR15gu48vD1RNVjMlIA6WE4RIrgFk
QIVFz1qWBjwkTbTMsFCpQh9q4dZHCxvTuqsCQYqBmVa1pJp5onoJd0UVOyZ8hhg7X+NoSeDsg16x
WawBhyjokpTkHGMuq65YUEmiIiu2YSnJYtjFiw0zNz68sDx9Zsvth+/47UObXv/LzTf4rrpxWkUo
nVw8iUrPu13Vt6VrV9+2xU9Ctm28adWRMaSpoqyttXQqi0p0mx/v/JEw2xHXbiZCZF5IcYgrRAgJ
DdcroVKpUhpaWqwnoO/y/9UxgJ8T+elHH1KBSW2gFRF6nUGOgN5kHNlbbnFZI40HjAeqDvAkI4EA
sw6NtGMBtucM5TsFPTwie/oS6eOP999//+HHplRLIy1r3LFx2y4uETZuO/JVPD87zBIOiW2QCSPh
giO9OMYV0xizLEaElLTcNErdpJ1QQTMONMtlqWl5acVprrTGtGVp69KUNFa55jJl02JGlA0cDfay
sGFl5lFWQtbFbI3ZGdMVI66L3hq9M7orWkzV5+kpsC2R0nlZK7KoO7c9lwpGLTd1gDUhOjK3IsER
grtAwhZ1h7pXFbaE7gjdi4eN1Clq0pRQwsq+yYLxwIqViZmJCBVDsioih4SHypG9parnAJ6Tuo/2
oIOP4qn2AB46TPzgEUhEnp3dR7sP4PeBo2lV3aZ+p5KI3MA+i2a0J+I+m5ts4ibMtSoYEbKiyLxM
8dLFdtxkEkxotjfXNDx2+02/fl7bmXFq/qQ/f/XkA5XVq1omHH7ktwNnz0nbk/7ALt8/32w8TUrr
rl/e4G5Z6ftk6+LKcTdrT+ZMi5hH5J0nxra0T6u+d/unRqOQFD8oYcuv7tkzURJvr2++e2Nb/e0Y
R2vxBPknjKMIaNyjGK1G3JK7/D86wvipsTQinGVHBOuJYP6IUENL1VIlxBqSEiJASJf/vCOKcYRY
5okrRCpWGCJ0ITqDouNhhZarChzXMKaO4mktjUeUzTSMxZSC4TTUFCzZQuzS+c71Sfv3J/9uxuMv
04eWdU4efvGUdLrn/WsmnXilp5rFExbjl6XX8MRvApc3ZKXQ5f/JYWF6CqZwfWmHiYCJq2ti6sb1
uw+p7HBtigibbIRVslGvM8rsfPEhBj3PZBb1PQdQQbyrEeaEwK4yXMBot5lISZbTmZXpLMi9m0yW
XnNmsmZWwfmRGOgX3mNncP83VEELquB2lCk6qy5Fl6sr0k3XNeg6dKoiW+UUWZBpqUKsJAXvWyKQ
aF6BIni0RTEVSche6aBEiU4doLJqJsoVSiiBYBkKaMmUZDU/Aq2G4RGpbd5fV+7bSDLEvReaptU9
DgFvynFYxxPgoENTBuKZx9Zooym2XNt02xbbQZsEpbkJJIGbKaHL3x2I+AS1NFchisp6FezlJRkJ
n4PbTzGWKiarKcV0xiSCiR3ur+Fm5iXepFkHpgzMHSiQ6HTG3HsUESE6ymCJEipi9RVRCTpVZ9LF
KlGKWeaBESg5xs+OsPNqWt9W34NBgtlzlH0Fj6oYLMFYuRQ0VpY+wcCRqj9xLova3zEn/6bY/avG
LHr09Czt6VmP7aGP9Vw3/OJZ+tOkma6ci1+JGas2bRxV8bq3Z1jQTsIxtJMJah1mxWA1UNIRQaD0
UgBxG/BIMgZi6PKoN/GoN4sV4SYMeJ0crgQDPhDvfCHdVf8S7qi5ZjIJAxqWj92QvP/mkbM/IDV0
8RO3leVfPCVmdD7gm9rT1Lsf61C/UKzvOx0ReyVC8qzEVGaVc+UiuUEWZXZnZCrKbOeczlSU9WVr
YQvsgL1wEO//cu/VUwTgngK+g0LUPIG4Qwi7uuH9hDrDrwt3hwsTI2ZEzIsQwitCIiqEEB6feCPr
8p/9PSMFXF3amDR+mA1scv2OI9xZvNANA37JAjyGRBhtWL+MtkR5LAn9+LTPd/HEX/xwiMTdusV3
6ub76IAfSZbvE99FX4/vAzKEgG/hsT+QDUfZ2tf6ZonpuHYDnoTvdRjPxJGosiLdP3V4w9+io7ou
/2m+cCS+csSzJelMJiKWklIrJQq10hS6lp6h/6QyUBbCWWwBlPJbBuW3jIGusMYwOl1pUCh1WsjE
GGKpCIupUEi4IIeFKr2eDK61N/mW8H2RrXYJc2wSc2fkcLZgCy44WTDhdUoLuJo49+9fcO8pnx++
L7gvytyWS+bs3Jfado3PJr3vWuA75fv2B9+bmUJ6z6bYLLLpzefzgjd5dgILh2pHtGqMNqYaDxnF
g+EfhdNwOaRULm3EDO3yf7s7mKQXHQk8Sw39640Mko5W6FVZ0emDW9eR7GB2sRrM60dgQ+9V30qP
jB7j3rJ/f+ORoTXCsrTnbun5jZjxxIvmwMmXXkSdbPCqo01NiE6gSrg1nKbai+3r7AKM0JOcOCIc
MhGTVNYQ1xFH46xgLcNDxxb9Dv1e/Rn2C1Xi2RiSEktIqkJSDCRVI9Q9oH0AFZSYAYJFKDa7zI3m
ZeZDZslsuHS5ZT9M4eUW4++Ew2LCC4RQoVmiGWGpMGihBoXfDzEe017HQ9rrVSa871YHf2XqvfAe
CFx4g0cy4Bfeodk5w1KGCL2X3cDBht90seSPHf9grefxW2aOt710X7t3+JKWgqr2dde3HH72d47d
jffMu3bk6EmVQ9fcM9Ezw5HVkDM6/65Fmx5mtWQSs5Lkwkxd7pisRkRH0FQrwQOscYtK1BACMp7J
+CU3pDSQkD/ylGR+hGSemKk8MdMjRkZQQxiVlLAKM14IKhRzqCIHbsIYjQfwUFbFjmhsO00bibHI
7knco1AVgeeynFz+O1XfVSA5581Vq/aTZN/HM90TygYuvePGZ4R7N5+Y4Ptoc883a1uSdsS/sInp
fz3eb74QM/Ce3uqI7bAQHR4dFZVY1SI8TO9QxbV4ajqjCnigPrc7+EPaD47B/GQNpWfNP5qpYraa
U8wCmEV+1xH5XSdCqAgP0YWHqnKw5hu7L6sZS1q6u/mtnp19cnFPs+fIXGsTueaj2ffH7N+vvTzL
8wcxo+e6HxcU0XMX3rtnTNPh5+iLTGc96vy5mI03/i92UfZ/eDhMIiWhkkxlGa8EgiiqCp7BMnCD
+ewIk27Oz8qM3SX/H7M6GnPRe+wvFa857IrDrjeKgOfySSm8CE+XO2QplebRYuqiy6gkXw/0ev5z
Qh7pIjSF5BJKxMxIq1wiaqFol67eHw/YTwcSiEtIqIxKBH86WMJ/N1jSnT+K/3DQw37g6sYrRVZm
ZWXvrwYh2b6cd0kssR20iIU9ZvotswSesk+j9wzwXdASkWGhYoUQHi6HykKYITwsFOu+ydi3RONr
XGJ/g/w33nC4rlVJnoGkYHamiASKCKG5eCFWTakmCnlhxWGsyOqdWKwUMXySwaSf5Awlghhq3Bq2
M4ySBhlNE1YUNj2sIawjTIIwA5NsQMlchil4asZIOcBv/uw3AryCjcoI9AcvvgGrYLjkBH7ACphH
S+q+q+Px0Vm+46+Qa0jsK3vmrnt8cbnriRvolxdfE0YG/ltkGr30rwhHQ+//7I52xFaAxus8TAzS
Ap6LJwdpsR+PhHR9kJZxl27m/6JQwHf1sJLTgX9xuJ7TMu+/j9MK79/BaZXTezkdgjOtwo07QBOI
JuODNIVwMjNIC5BMmoK02I9HQnpjkJYhiuwI0irEkxeCdAjE05AgrRO/IZ8E6VDIlHvl6qE4SOv6
rSWU6akYOK3v1x/OaCWB00amp5LB6QikzcooTlv68Ufy9QboqH79MfzdSZyO5bICc8b140noR1/F
+as4PZjT8xmt9tNZ7Te/vl+/Pqj/+MXNy1uaGhrbtNS6QVpWfv5wrbSprmVx6+K5bdr4xS3Ni1tq
25oWLxqijV2wQOOcrVqLu9XdstRdP2Rqi3tOe12ju00rnVLhbmhfUNty6e2+wWnullacQssakp3d
11k6BcpgMbTAQqjl/6P3cmzNgeUkDNwwD9tfIlwanwJtiBdhsNViX73wG2GX8ILwIsI+4TnhSRiP
vM04Rws0QQPuLW2gQSrUwSDEWZCPz3CkSnG0DnkWQyvCXM41nktp5t+12NOE1CIYgiNjUe4CxJfm
bOUtN2I34qX4XY+cU3nfHGjHuRuRauOSpkAF0g3Yu4Dr/HOy//XNaXzm1qAWTPchkI3Pv3IyCf/V
en5Or3Qcr+f6sxUt4vprzOr4PQ37FiGnG79751mETy2fReOjl2yZznuYPWoRGlHGQu4f1sfebuWt
Vk65uQXn/qzsuVxbDVu1OLKc89dxiW4ur4WPMK/PwfcWILQh15CftZ3GY2Q+l6Fxztag3q1oj6bL
/MskM7st5G818hX+nM6stZjr3svFLDAUMvlIB/Y1cfnMBrV8RQFvN3DeZbzffVn8BKJY49Lbg/Rc
vso2bLf0ac+84ObjAUu1Ib/G/yEE03oxH/0l+2jBNfbaujVoscAKGEczUnPxrTrew7y8MOhlJj3g
gXo+W3/ptVyDdliBzwLO38jlt3Ce2mDkXxmT6UFLuYOR1GvJJTiTm8dLr086eBRo/Hs+l8zeTcT5
FvM8YlKWc1rjnm8K9tX+Qjyk8pG5wTrS68mFwbW5MYNreYbXcd1r+doWIDWob8XMm+08Lxr71h/I
0F+KIpYHgVyp41Zlc7b2zdfLVcffb+V54+YZ0J87vV+cNCJnB4xBK1zy4M+tdS6fsTfGLuXsz0XR
nMv8wOpYII4X9PXXBuds6ovIgN1bgvZr5dnSEByr7fN4a795JwSlt/Bsb+MxmAjXXmbRX5qVxUIT
n+mXvdsc5E3EmVl2tWHPCMjAp4M/Q3DOK2NxCLf8QuQJZMFinKGFe74R2xn99qRank297ZN8j3Jf
tme5L9uVeBaI8WKWWCIWiaPwOx+5a3mM1fO9bCxytPC1s7f+F/2ftTEKZW5kc3RyZWFtCmVuZG9i
agoxNyAwIG9iago8PC9GaWx0ZXIgL0ZsYXRlRGVjb2RlCi9MZW5ndGggMzExCj4+IHN0cmVhbQp4
nF2S226DMAyG7/MUvuwuKk6BthJCmpgqcbGDxvYANDFtpBGiEC54+4W4ZdIigfTF/u0fm6huXhqt
HEQfdhQtOuiVlhancbYC4YJXpVmSglTC3Sm8xdAZFnlxu0wOh0b3IytLgOjTRydnF9g9y/GCTyx6
txKt0lfYfdet53Y25gcH1A5iVlUgsfeVXjvz1g0IUZDtG+njyi17r/nL+FoMQho4ITdilDiZTqDt
9BVZGftTQXn2p2Ko5b94EpPs0otbZ0N65tPjOI2rldIiEM+IjkQ5UU10IjoT1YEyHihPiE5ERSBO
sYJinDoU1CGnmodTMHt3xR8et2/KSJQdqC5p+fHhIBQkk/z8SAmX5C7P6ZJsHdJ7Myq/Dmld5rYB
MVvrhx82Hqa+zltp3H4KM5pVtT6/W1mhqwplbmRzdHJlYW0KZW5kb2JqCjE4IDAgb2JqCjw8L1R5
cGUgL0ZvbnQKL0ZvbnREZXNjcmlwdG9yIDI0IDAgUgovQmFzZUZvbnQgL0FyaWFsLUl0YWxpY01U
Ci9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0NJRFRvR0lETWFwIC9JZGVudGl0eQovQ0lEU3lzdGVt
SW5mbyA8PC9SZWdpc3RyeSAoQWRvYmUpCi9PcmRlcmluZyAoSWRlbnRpdHkpCi9TdXBwbGVtZW50
IDAKPj4KL1cgWzAgWzc1MF0gMSAzNSAyNzcuODMyIDM2IDM3IDY2Ni45OTIyIDM5IFs3MjIuMTY4
XSA1NSBbNjEwLjgzOThdIDYyIDY0IDI3Ny44MzIgNjggNzIgNTU2LjE1MjMgNzYgNzkgMjIyLjE2
OCA4MSBbNTU2LjE1MjMgMCAwIDAgMzMzLjAwNzggNTAwIDAgNTU2LjE1MjMgNTAwXV0KPj4KZW5k
b2JqCjI0IDAgb2JqCjw8L1R5cGUgL0ZvbnREZXNjcmlwdG9yCi9Gb250RmlsZTIgMjUgMCBSCi9G
b250TmFtZSAvQXJpYWwtSXRhbGljTVQKL0ZsYWdzIDY4Ci9Bc2NlbnQgOTA1LjI3MzQKL0Rlc2Nl
bnQgLTIxMS45MTQxCi9TdGVtViAyMzcuNzkzCi9DYXBIZWlnaHQgNzE1LjgyMDMKL0l0YWxpY0Fu
Z2xlIC0xMgovRm9udEJCb3ggWy01MTcuMDg5OCAtMzI0LjcwNyAxMDgxLjU0MyAxMDI0LjkwMjNd
Cj4+CmVuZG9iagoyNSAwIG9iago8PC9MZW5ndGgxIDI4NDg0Ci9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
Ci9MZW5ndGggMTM1NDkKPj4gc3RyZWFtCnic7b15fJRF8j9e3f3MlXNykAMI80wmCSE3SUgIRjJA
EoFwXyZAJJNkkowkmZCZJATl8gKDB8rHW1cUREWU4Q7oCu6ieOG1q6sLIq54i6KLui4k863u55lJ
Arq7n+93X78/fi8yVnd1d3V39burqrsngEAAIBBWAYOsllZ7y4P32e8FSJoCoL2m2dZkf3L88CSA
ma8DxLU12Za2aFfo9QAkBnvJjc4aG4zJaAHIxnLI2YYm99KgIu1obEcKOdPQYLcFherzUPYsUgIW
aw/X3ikj/xxSXn1jZ93smY/cBzAuCMB4qK6lvmlI9xVOADOWNWNr2t3yZT+YXwNIexnL02qabC2f
xCx6AGWTkf4GXHf69jd/e+ThvYtCC3/Ux6Jq+LOp9Q8Heb7n8p3Hz33YU69/XJ8DFAwoT4QAprqx
vdNggv4QtpfpHwcz6KDfD3uOy7DnMCmC+aDB3kbIhHE43QjtNYgV1apD0QI/uehfSKDkgkVIDl0c
HNHMg0fIGiLRrfA03erdwOLgG2kbdKPsSKxbhHk7LfDei/J3SC6SiflSpBakSqTbkJ5C+gfSfUhd
KN/G+/Ix/OQikt4ETs08719wvgrNETiAtAD5hdInUKktQD2OwDzeVwIoxvoFONYs7VaYj/W12P4s
1pVj/nssVyG/Hvt5kX8J+V7drQRw7IPIf4f12ThOMNIzqPda9gLKurwr6FaSgmPORyrGOVyYNyJd
jXJ8HaN4PTkCl5MjXj22lyKfh/NPEPIuqMUxvuaYISa8/zSOJZZXIf8o6vGwBN4e5AEpmW6DxTQS
nqPbvHNw/ZuVdSMdgef4mv1rQv1VnS4mRcer+xPOubw/9el2Ea26gA6wHBKG+f1IVqSx9Cg0SVNw
/z6ByZpPYTYnPfoM4jQf13haqoVr9eB9GvV8RrMb+2HZTy4okx6EIHYWRmPbMu3d8D3WAx2J9BM8
Tr+B27WJ8Cza15U4/n1I23DMdmELtTAH+2eIcT6Fwcg/gsTnTvLhxLFBL9msuxVWI+7nucdg//eR
3iNHiB4JsP8qnH8px5zvO5nX8wWOMxNlbEhmrHcKckEgYrUf9/V7tO/3cay1qh0u7MthoWq3fuI6
+EjYmUoC+61wFOkQ0itIxxCz25AmIj8VyYOEMkSPc8egHSUJe0WbQRyShH2gbXD753slbFZZQ7mw
MeEzRIP9o3Gce5Ge1G6Da5CeQnoSZb7g/sJtluvpG5v7FLcZXy7sezHsoVtpBF8ntyl/zn0PoMXv
g2hbvpz7Hbd9nlMrjMZ8HsuBAm6z3N58OcdF6I/+yH3Cn/et1Yv62UT+LjSptr7Kl3M/5Vj48/Vw
pcB7J+xGvk5qhWp2A5RIf4Ja2gsezWjcy8XeFXxt9Gvo0B8CHkmnY/m+C/J7OeneJVdrDsG3As93
4SHMl0jv0njpXaLRPOX9UgPkFc1TdIXgL8ovJHJIaeM5p/5t/9v6/xui72megjrkv9K86/Xieu7k
PqH7mmQhyb4c63cirUJK0aeSe/WLSbduLhi1eLZpuS9YYYzGCvnSISiSBmEcAEjE+rmaE9DGboXL
pK/BTlbhWfAuCdQNwjPgbojlc9H34HpOfHzMW/rZ0QCbu9CWfLnPXi/MecxXbUrkqu8t/5W8AG2S
8LOBx2dxPmCMFiTs1dvst89XoBrzST77HGin3iP97PMbHDfmQru8MBdnC8Z3n59y3/Ctn8dHHuN4
jORxjhaQZJ/8hXlff5KDfnKfiMNHYb7q2/+DtAGpBtuSUM+T6P/X8FiGc/1ZOx1qtC9CAxsK1dr5
ON83UKXNgSG47m/9Z+pV3m/U8zTbd5ZynLD9G985qskCvYhnr8OVIt68DuniHEXd+PmpfQx6tFGg
U/t+x/1Q+OASKOFno1QHd0t3er/EdfyO7UG8sV66Eq4TbQCF7Iz3qFTt/YKfiWyDiEG10l3eU+wU
2h7ve5W3SfMOPKi9DGr943EZzHkd11/7PHwu4Ro1T4ozf70vHvO916/xfqU7jut/AT6V9qFMHHyu
eZWvBTEYJdZUIfo+6l3Jx9LN8+6TvoQazX6sQxJ9rvV+reIxrz8WwoY5FjimdqE4sw9q3sa2Gjim
q4QrddU47xL4XBeNdXyuW3H/MzB3e18V5/UqPN/SoZb9gLbVKGzxas1q74usG0y+c5gdQb+73vu+
5lrM65H42kWOcR/9R9w30Ea02/F+xu8TG/CMT4B7tJuhU/smdEr/gE7NJyg/CorYd+hHEvKl3i/U
uF3CtFj/M8ZctG/lLqPcZ3QTve9rHxbzlQgd+D3FBcvZGbiS7oMijCUz9VvRVhaKc3od2t9HSN8q
BH9AKlJpkkI0CNveRhtdhuWHmZFcjvzdNAfeoFulKKwL5WeutBoc0jzIZiMxjoThneJteJT8Ag+w
UPBKr8IDUjf8hfyC52QE/Mg8MJvthvOi/k1wolwxfQcKpXsxfhcihmvhC2kRrGQ74Bz7M66hDmM9
9tPcBt9qEiAdcX+A/UD0nMgn8BWbB19pb4IH+HxcDuk5HL+akzQR0kW/fiR09dEFOtMyWMomw42o
72fI3zdAX9TVr+da+Ezo+Cv6CT34uNiPy0gPwPUA3uNIiUreO7NfHvUf0PF+ucxz3NPN/FzQrsCY
9x7Gvgq8s4Tjuwl68W3Tgy+Dnn0oV475N1h3GfIZSPgO6jVgXTvmuzAPQarDepTxHsa6YmkI+ooS
p67BuquxvRvrX8Uc3zzedMyPAJw/jRSiUE8k5ncgXYt0J1IpEij5uQ8VfbwzMF+BdTje+buwz89Y
zkEe31rnf0H6DulhpHXY5wS2pyGVYXkpUgO37YvuNf/1/NfPs/8053GL64n5aPTDLy48k/7j3Lef
/ya/8Ozy7f+/y/vdQS/IFRx86+h3lv7LM9OX4xBZ/Qlj81iMUYU8LvPYyOOxiEdqLu4BSlz8ip8h
mK/BOHiWx2IeDzEWv4TxcDXmbZjzO+gLKNPu04s/ilUaqjx9deexhJyBgqQ7Ccrjmr+iV5CV5HZy
J3mEeMhx4qUV9Ah9hX7ICGPMwCxsBetit7BH2BtSkDRdWigtkjZI90gPSZukXdKz0gfSl5r9mj9q
vtKcHXbjsF/kUHmQPEyOl5PkDDlLzpHHyIXyWLlYdsor5c3y4/I2s8YcYY4yx5uTzBnmOearzHeZ
n4in8dr40Pjw+EHxg+NN8SPiU+Mnxtvi7RZqMVrMiZBIE4MSjYmRiTGJQxMTEtMScxMLExsTVyXe
kLg28ZbEDYmPJG5L3Jl4IPG5xMOJryW+mfhB4mdJhUnWpPFJVUk1SXVJi7/QnKFnRp6j5+RzeecK
z409N+5c8bnp3vNeL/9mBDYKBDaS7eQo+Sci8BIi8D4DPwI3IAK3sU0SkUKkmdJV0nrpbul+6VHp
Galbel/6QuPRPKt5S3Nm2KphG+UgOUKOlmVEIAURyJYLVASuRgQ2IQJbByAw27zAvN6PQBgiEBs/
TEWgKr5WICD/BgIz/AisT9yYuNWPwKuIwPuIwBg/Avakq78gZ8gZ6RxBBFLOjUYErOcmnCvlCHg/
4d+TeCPJVWQm+aP3OKnC6BOKuCRBIOKjPb8Ryw5uQ72pvSm9I3qTMWIZvSHeAC/0nu892fvO+Q/P
Hz//1vnXPqkE+Ntx5TuZkzci3fXxgpM3nPzl4ydOdmAJI+7J9UhdJ5d/3PbR1R91njzw8aGTt330
xEd3n7j7xKMnMLqd2ML7fhR9YsmJRVjKOmE9kXMi4Xjp8ZLjhccLjucdzzmedXzE8fjjQ45HHifH
vj329bEvjn167G+817GXjh089vwxnOXYi8ceO7b9WMmx8cfGHUs4Fn/MfGzY4EPG59GPn9dt0T2k
e1D3gO5+3X26e5nyHVMvDPihzyg0oNxNT/i/b0qD3/hhg5FeZW8wRIGdGNDyV6S/KfSbvV/nxN5Q
S6/+tuRFPR9lm/38xt+U6vr1atgEN8CN9DzcDZ/BTXAbrIOH4EnYDEboQniuhw1wBr6HW+EeWAt/
gOPwHfwOtsLf4Qc4C4/CNngZXoKnoRpqYD3GnlfBDkfgFXgDXoPX4Sh8DnXwNrwJb8EzUA/fwh3w
Z3gH/gQN8CV8DTfD1eCAxdAEjdAMG8EJS6AFWsEFbeCGduiAL2ApLINOPHGXw7WwDx6BlbACY+pq
+Aq+gf3kbnIPoYQRiWjgHJwn95L7yP3kAeiBXqIlOoKPE/IgeYj8jjyMPv4IMZAAEkiCyKNkE/wE
P5PN5DGyhTxOniBPkq3kKbKNPE2ewVjgITvITrIL/gHvki6yjuwme8heso90k2ASQvaTAySUGEkY
CYeT8DGJIJHkWfIcGUSiyC3k9+R5cpAcIi+QP5BoEgPbwUNiyWDyR3KYDCFDSRwZRl4kL8Ev8E/4
G3xCTEQmZhKPb6KXySvkVfIaeR1j0RvEQhJIIkkib5K3yNvkHfIn8mc4QIaTZDKCpMAp+JS8C+/B
R/AB/BWOwQn4C3xIvkNX/x5j+Q/k7+Qs+Yn8TP6Bd8t/klRyjpwnPaSXpGGcB0oopYxKVEO1VEf1
1EADSDoNxBttMA2hodRIw2g4jaCRJIMOolEkk2TRaBpDY+lgOoQOpXF0GDVRmd5CzTSejCTZ1IIv
ugSaSJPocJpMR9AUmkrX0pvZZvYYG80K2Bh2GStkl7OxrIhZ2Tg2nk1gxayElbIr2EQ2iU1mZWwK
m8qmselsBpvJZrHZbA6by+axK1k5q2Dz2QK2kFWyq9giVsVsrJrVsFpmZ3WsnjUwB7uaLWaNrIk1
MydrYUtYK3MxN2tj7ayDLWWdbBm7hl3LlmNEX8lWsdXsOnY9xvYb2U1sDVvLbiafkFN42q3DaH8r
xvvbYQe+8rtILuyBvfBH8insgt1wGK6DF2AN/Yaepmfot/Q7+nd6lv5If6Lf0x/gR/I5PcTC4Tm4
D06jrzwGd5IiuJ2MI+3kDjxjNpAO6CbXktPkW6ZhWjaI6ejP9B/0F/pPeo7F4HkTyGJZABvMgtkQ
NpTFsWHMxGQWxJKZmcXjaZTAElkKy2CZLIuNZNkslaWxdBbGclguG8XyWD6e7VpQv+/GnGJCL/B4
/m25pNHq9IaAwKDgkFBjWHhE5KCo6JjYwUOGxg0zyeZ4S0Ji0vDkESmpaekZmVkjs3NyR+Xljy4Y
c1nh5WOLrOPGTyguKb1i4qTJZVOmTps+Y+as2XPmzruyvGL+goWVVy2qskF1Ta29rr7BcfXixqZm
Z8uSVpe7rb1jaeeya65dvmLlqtXXXX/DjTetWXtz17pbbr3t9vV33Lnhf+66+55777v/gQcf+t3D
Gx95dNPmx7Y8/sSTW59i255+Zrtnx85du/fs3de9/8Czz/3++YOHXvjDHw+/+NKRl1959bXXj77x
5lvw9jt/+vO77/3l/Q/+euz4hyc+unTLuXTLuXTLuXTL6au+dMu5dMu5dMv5/88tx2q1Fo29vPCy
MQWj80fl5mSPzMrMSE9LTRmRPDwpMcESb5ZNw+KGDhkcGxMdNSgyIjzMGBoSHBQYYNDrtBqJUQJp
JZbSKtmTVOWRkiwTJ6bzssWGFbZ+FVUeGatKB8p45CohJg+UtKJk3QWSVkXS6pckRrkQCtPT5BKL
7DlabJG7yfyZ5cjfWmypkD2nBT9V8FKSKARjwWzGHnJJTEOx7CFVcomntL2hq6SqGMfbERgwwTLB
HpCeBjsCApENRM4TbWnZQaLHEsHQ6JIxOyjog1Erz2BLcYkn1lLMVfCwxBJbrWfGzPKS4iFmc0V6
modMqLFUe8Ay3hOaKkRggpjGo53g0YlpZAdfDqyTd6Qd6rql2wjVValBtZZa28JyD7NV8DnCUnHe
Yk/0slMxfUUcPHxC+Zr+rUNYV0mMQ+bFrq41smfjzPL+rWaeVlTgGNiXJpZWdZXi1LdwFGMyURGu
Pl+Ksii7pYTXVF0tewyW8ZaGrqurcEMGd3lgVqd55+DB1v3ekzC4RO6aU24xe4qGWCpsxUN3RELX
rM5dsVY5dmBLetoOY5iC5o6QUJUJCu7P2P1tghPinCub5YeTcI0sk9AMPHKNjJqUW3Aho3liHw1d
NaNRDH8qCPby1OI2ODyGCVVdxjG8nvf3aBLxctT1I4bWKsvpbwbW2NQabaLxR+AsNw6/gWG7j/ek
pnpSUrhd6CbgRqKOY0V5VHpaezfNs7QYZcwQPphRjt0qxmQi5mYz39V13VaoxoJn1cxypSxD9ZCd
YM1MrfDQKt5yyNcyaC5vWeVr8XevsqD57ha3kEEefZL/v1BjVERJwxgPifoXzXalvWy2pWzm/HK5
pKtKxbZszoCS0j7a36ZynogJ5WwIVTk6hIlWtMSFfmFeKA/ySIn4n1ZYcm23To+mKGqIXOoxVk1U
0ooAs/k/7NTtPcN7iayvm6qmZ0zqwPJlA8oD1AvqYqiwlETL5szv6goY0FaKcaerq9Qil3ZVddm6
vauqLbLR0rWfPkYf62opqfLtaLf3wLohntJbKnARDWRMOsC4cFhJt8B2pINI3yFJkIXpdKRFSAys
dMvO23Os3ZgtEtmuaTOzV/F8ytRsUbZOVPKAYCU3jFHyrBwut3lXyVJe3rwre4xSThmplBMSs1eO
M9LNuOffiTQU00ykIqSVSBJOvnnXoDilmyGSd9u0a/CQ7NCDdBNKbMJ+m4SKm6wB2Bw+XTtdR78b
l0++xtEeFulKkS4SaZFIM0UaqrZ+xWcX6UGRbhdppkiLRDpdpE6RCnk80k6Tb/DzNX6+Il9ZwyGN
gIkYMaybiDWNWE14ZzKQwJ25pju6SaA1P9eUIU8wZSPlyFeY0jA3IV2TMtGUjmROKTbl4/WcgAFf
6nqIjkYfCA/TW7vJtn29a4J71gSDoZsU7UyZYhpnIGPggMSny0O6H0namdJqeh57y6KIrzz61E7T
ufRuMm+n6Z+mbj3ZafrF1E2JNcL0D9Mp08+mZ00/miabXkl5yrQfpe7faeo2dUsotTGlmz5lDTWt
M81C5U6ZlpoaTc2yaGo0Y2YNNNVgp/kp803lGCpwlmmymOUKEw6z11SCjcUp3YTsNVlNN5ty0kXX
bN51r2mkqdWUYRLTpSnTjVB0S+bZXtNwnCxezFJimhtsCDbkrz+uW/+Ebv0W3foVuvXjdOsv063P
060fpVufpVufqVufqlufqFsfp4vUh+uN+hB9kD5Ar9dr9ZKe6kEf2e09aU3lr/9IrZFnWomnkuCN
lKf8GxGEixI9hcngiWBltGz2eFLmOVQDZdWy56fZlm4SgH6osYwnnvAyKJszPsYzOrWsW+ed5clP
LfPoZiwo30HIbRVY66FruwnMKe8msbzqxiH8nNuPuxp7461DeO698daKCohqL4opCh8bVlBa/CtJ
lZqm9v3EpA74KZvRuR93uXyXznS5DouzsbieF9fzYkyc5+6y2eWerXEVnmzOeOMqyjwbZssLy/fj
TX9bSfF+vPJjVlG+n6WRZ0pm8XqWVlxRUYZbI+TQ7J/hcs/wDOX070ERl4Mi/XtCTiKKnEXIodkp
clEyWIScJUoeIDeMPM3lUniGctEnYZiQGxZ9sp/cjgOWkuIdFotvrANC5oAylqdQiJhMKGI2CRF0
FZMQMREqREr7RNJVkQy/SIaYiZE+GZMiEyz7ZIL5TKn/0Y99fGpqiYPbyozyHXoYX4GngMijjC1j
xb4Hx459bMgBeId9DYF4EAbgTSrQMh6KimJSjYUkUxvk0WKVDolLX2aOWTHkgATkCSEdhNXBalP6
uPRxvAmtlzeF8CuZ2hSz4jLzkAPkCbXJiNVhOEc/Pd3uNvyBmBJHsf8/l/rTpuZuKPOkzC7zFOEB
tEOnK8FbSnEF1mX56gIDS7q9h5TKDKws5JWM+QX9dQaDKoho7J2eRqabSD6qUJHqQlVwov4Iul2g
OQCxgrbAYCkJYgC8nyN9wfNeh/db3tbr9P6N8u8R9qik/DwHB+EWfKNswc8OMBIJ3+Kd+JZfh++V
r6ALX+p3kN34rl6GL/tH4Vnye9oC8/EdHY3v7T9CFmHet/Atv5wEgxbC8f1+FObBHd7bSQQEQixM
wDf5fvYy+4v3W1JKmjFODIFimAV72bfwPpHo5ZoYjcubDhowwEtwlE5BvcNgEOTDJJgGC1Gnx1HX
F+EYSdZM8H4EZrDCbJy5E26DTfAquZ3aaRvdzF7WzPXe78VZcCQ9JEEpOFDKBR1wP67jO3y7R+Cr
+lMWIz3Y+0PvL17+vcdwyIVxUAJtuJrD8Bq+hj+Ff5C5pA7fn3NYi6SR6r1R3t2ocxxkY1SbDFNh
LlTBtbASEXsIdtBN7Jbew70/Y+Rj+ElHrfNhDK5/PmJ1FP6Kr/xYfIcPJxPJbOIgG8k5fDEX0NV0
M/0Z33HJ+Mljm9ge9iH7iH0vTZSWSp9pA73J3jJvg3ep92HvQe/HiKkJkmEKjrkQrgIbrqoDVsP1
sBZ360H8PAQP43txL3QDejj8CV/1H8MP8DMJIdnkMlJI6kgjWYoBaA/ZR94k79BKaqOP0qP4JpyP
c29GbyiWZkgu6Z1e6B3de0vvjt43vCHend4j3m+8PYimCTFPRETToRzsOPONcAe+Uh+Dp/i3E/g5
AMfgOHyJyBnwYySRJJokkBEkHV/+eWQGmUnmk3riJp3kOnIbWU/uIw8SD9mF2jxPXiR/Jfwrxh8Q
GYSZBtJQaqLxNI2m0ww6jdbTNXQ93Ub30Ofw8xb9M32fHqOf4pv5F3y7RuInniWxiWwyvu+d4q2+
gj2FeL7GTkoS7l+olCylSTdIj0nbpTelr6VfNIGa2zQbNPdqPtV8qgWtUXu5doa2QXuXtlv7gY7p
ZurqdCt0K3XX6fbisWfRb4Od6B07cKX9fuhCeAT+RJ6HE2QLi6RPkRn0cXI3CWExsJg9QN7WlMHN
tJB6yFQaxf6OL/h2GMSeJGfhLOylEn2fpEqPk43wHHrSLXQxXSqFkiulJ6Ue4pbewWf0KdhCv+Xz
aCOlx3G2djxYm8hY5OqhCX5HI+E1vM7dCEvgD/A7rYGux32/HZLoRBhFJvG9od/B1+gdYaQIrkY/
6SGbNG76CFnGvqBBMI/00I/IZRo31OFRvprsotPYa+QUet5zaC9lpIEWkGrogc/Io+QzOhem0uth
k1Sv+TP5kKSSaZoGtD+QTrJJrI5G0Gcv+lZwO+xGTzgKU9jLsJDcid5/lKbCJOqEh9jvyZewm1wr
1bMG1HIplcj16AvbYBebKAXCeNjNdsPz5An2HkmF7dJS0kw2eEt6KuFH7RbpGbZDkycN9b7ae5w8
Rt7yHqDfQ773VTa3t548KMWiX16L3tuKCAXCU9j/QYwYW0CPXCL6421or4MwthnQy0sxck2Bq8gP
6DHXI0p5JBmm0XhYTMfpZG0kgG64fzXu/wJt+e8RWYtWcEIh8V3x/wNJW36bNMkqbRtIOuNA0lsH
kuHBPgrYq1Dg2YEUnAAQ8qBCoWf433u5RJfoEl2iS3SJLtElukSX6BJdokv0/zFR/vtCDX7wBa+D
yTsoeZZkgBZ0NH8naKRukrGbQYCOM3sIxOq1Gt5OgZEJuwwLno9JNf5U2FM4zXi2cGpPIRQhbzyP
ycgsc5g5LBETAhKcl9mh81b+R25k6RD/nUE7Js1wFOeM3UtKIICWkG5ydpc05jMc8OxpKDo9Misn
P0fXnno07ehRfPx6/4Kv1O80B1DHENhoLdVrtVSr1+s0hoAgSasPCQrSafWhGoMx6J4gQmVc1DBd
UKROF0SDJGkYo5GMUaILlRhlxqBzlFCD3qzRdpNnrSE6nSQxBvqgJ0Ovvy4mNdZ4FmKKCo38cxZX
UlR4moRFF4QVFKzJSF2z/PCajJjU5cbDqWHhBQX43xpjyGHN4cNrRKozFq4xHh6ZZSE5ERZmZsTM
koZrdSNY0ec/PH9Fz/avSRH5tMCsz67SHPhnKdnSO59eTlqO3bniaUSiAvfhclxhOAyFZHjXekWS
bAzLHcSTgnjHoCNDj8RJEclxQ5OTBkUEahJGBEYkD42LGwYkEsGMjDAnJw8fDtKQoWZSlSzRYXHm
5HDQR6fou+nd1uCQFEiYnlCVsCpBSkjoJu9ah8UZ+O/Lhg41xMVdYwiFTP7bnNIRBmKE6NKZ/Hcm
hSR12TTjGRKTWZm6bOr3mGNVpvj2PXWZ8Qde38O3qjC1BwqLUs9iiphkFhp7CtdoMjhGgGUSFh5d
oCtEgyCVqak5xJwdPYwOitTqoqIw1VqwIm9UblKSxczM2fljKfIWcwXJIS9dW1i9ZvKNN3e0r/v0
1t5nyIh3nx1ju6n35dNk2o0Zle7xq/f03qI5EBA2d0NFZ3fW8IccnSc62cS1142dP+LcBoNx6oqS
+sW4pgWI6k5ENRRkuNM6OVoODMsdyhOIlCOzIj2RUigJlamBBA41kSFDTXImyZR1V2iIbDSq2Jpk
MyHJlEYUGM3JoaAfnKKfGW/sJjprmIJbqbmFEASO44YgVRJ0h8qpp6cZf5qq4nOqKBVxgULNGgHM
yCyoJJWVS/oBQrVandaSmJOdn8c/HJPhiMQCkk0OPDxn6dZ5i5/+/erq23v/8sVDy6bkXTFmyoJr
q664u7dHcyDa9PC3/7Oj98MPlw+L3hIXbkmfXH1u486Dpmj0My+ufrPwmoeteUMokUHW5aErMIOe
aBlN1up06iI11IzOoUsG9CyDTncNGIgJF2WAbu+hXeb4XJ5bg4YOy82ELPDwvxTVTV7cqxf2cjv/
XZLPZBTL4IVKYSg+wwGEQMQH1TiEAxGecNOoNBNzvlmHQL9NQntNFuk6S6+l93tNxOOP//M0jxjB
vU5mFispt8ZIGo2qNpPMxKjVmHUQTrezA0QDEvlol0a3HX0b9x3DCg3bhWGrfj/Rooq4MVNP9Zw9
ZTx79pRQpsivz8isCGLWoefqgslqsiHuWO/uD+N6nbqydb+8tg5n8q7tddJHhQYLrXETYRKihVGG
SRhaEDkzCddIZq3OqN2uwal3SWQ7xXwv05VIsB/D50d72FT9l108YJ46bTxt5EpcrAOpRBxyiCXf
TGJ6W+I+JFOOx5ENvc512lHr0NLme7+Q8qSxMBxGwQvWmQvSSWJAYqAlKDFtDJlMtJn6Av2V5nqz
lJuWEihlJicFs1BIHGZJTmURwQHZg5NTU9MCgiMDAoKjEkzRJHpWhGmwLikg28QCo8tDo0hUN/mj
dVimrE3KC5WHQbnR0mKhFu8wa1h4LgwzDnMOY8Oeo0shH5Iw5XB+Vpk69adKXA9Htgc5DN1FRad7
Kk+tCclIDVGDQIFvr3kwwP/4OqGyMhH9Pz5pVG4eGnxCPpo8Wny8Vjc8Ly8nm/9xMx3TDoqMtiRF
oG+EoI9E5WTn5THjVc/UbNg98ybb5WTu5EEZRZ2td5j3jf77/hdd5bGXDY3aF3p50pV1v7tuvMM2
f0vVDTPLnl5TcfPs8KCQuMkjixKy7ZXG3z1xVWnL3Jbef6yYnn1VLvks1GgISb2qYEr1oq38T/lf
jRiPQ4xjIR4O7Qez96TVgDHYxANxFP+leHlIWK5Bmxy/LmZdrBQTe8VgNIQ9sS/GsiSWFtgxeM1g
CbgsDBkMLJyEhcZBgpFUoYsQI5mBjERmS0MGp4WtD98YTsPDJdkUpIs2SYHh3fRO65BIWZ9kiZND
rdFyLoQaQ1tCPwqVQscmJI3leP+EeCtYn+JIn8aAW8nP3J7KJaeEMyG6r6RyfFuXcCck0VoJMUaQ
wxNysjmmZq0CJDHzGIN4sxmepN7vft/+Yv0jBO56/pOQ8z9IN9dU7u5NoHPI2sXug8QRfv03TW/d
+Ay54uFvXp82yxR710PLyLKhQWvv2Ih4XY6gJaBf4P2BZFoDHmcvsc/Zj0wy8IgxJXN07nTDKsNb
BmYyZBoeNmw3HDR4DVq8WkiEaXUICkumOp1FIpG8poYmE9BqtLpkKYBSDETNksFIeCAKlyQ+YAwO
uEp6S6KSNTA0V2rjEUiKnje234mVuiQVY86EheV7JOvUjCLRzVCUVCRZxyaK0q6yJKU2ZJwZayOT
MQm3KE1xWUo+NFPJo1VRQyQXjRsuSjtjzUUDfp9dwSMcPyYvDHc8Pd0v4uk0hYV4SxDH4ZLUJQTv
OCQih5GS1N2pvcUn9pyQTh89ei5CSjr3Vx718hDbOIFtr3VulYZM16zSvKVhemLSZGoe1mzXHNR4
NTrKmEUJhxw9lgwcOsaawRCuQAcH4U2gq+At3C5rIPpygyQC97xF/qiNqLUqoIE1JrwIfKABB02U
QobmYwnBAg6Wci7kKzmCBD6QgIMkahEkUNHm+b5xvNESPhA5P3QXIJfaPyYuac3BG0Eeyd7T+wa/
OSEyxXgfLEAvjYbvrDMSdKN01EIT9Hm0VD+PXhlURzv1S8O2hh3UPxv2uv6VsBAWFU0lPPGiozlS
xGoswCMbATMEBVmCjZFGrGg1kuBgY4RJq2PdpNcaRinRJgdFBwdDAAFjsNHQTfbtDCrHg3+fNbgo
mBiDpwcvCnYGS8HP0uUYLSg5sDO6HO+xB6wRuAiYDovw6jsvBqKDVfsU14JTPRj40Vt7TqXyOybw
q2ZhalEhxBpPxRRxW0G/5YETuRhk1RCKF8zDStjMicjR8QgpAqQlQvViHSs+sXn44gO21RsGr9lz
66BJJes+yKmXkvY31d7SdtnKnuX0kerMUeNf/ntvuIIeW4DohcJZ6zUGdpNhg/4Og6QNjgreoj8i
fSn9k2mTaLI0muTRiaST3Ex0IaGUBdLQUNXQDOV6bSBChQanDVUMLjS0HKwhxly8OaDJGfG+lcWv
CUagVdCCpncG0VBwYTDPKOzvtf2ksN/FoZLfHJa0TuB/5gXQcCLNqlmFRKPlBEcp5pQeLfKdw1RL
EgaE3VOFAS07hKnPhESI9F1GBYbirrHEB2G0TgRAhG5j+qyHZuVNn5w5etHLBfOlpA+uaR/+RPyf
e0/3zuN+OA3PBIZ4pcEPewJTQvE06Pa+twtzxg+EWGTuCn7Q/GA8a2fLYu8OvCtICpTxlJCxdRfm
Zi5VjMyNbF3M5sAtwVIp6wxcG8hSghLM8ZbRQZIcFMji4vXxmEskOiFqVgQkEDJisClCpzGNCIyT
rUZidJM0fkQYSLkM6CcEummk1ZjOT/IzehkSjYk08UwURywsYUQuRBmj6Ek81F/ImPeCcnYsSZ16
trLnVCWyrafRDJec9h0ip4w9p/CVQ8KU4xmWVIrTQ6QR+ZFR/MTg53PCcH6WcOtD7Dh4eEBH8Y+4
zMcPT5q7J2v1vKVLExJ7P06eUPzy7pfflnZIq9quakgftvytvHm2I2u6V68miwOnNZdWjctMSbkm
doRz4ord++8JqmqZl52dNDhvfu7sjun3LliwABe4CnFvl5LQu3qtbbH6WMNdgXt1ewM+H/RpjM6g
NxhuCLop5i7dXQFPsSe1+uEB+THtuvYAd1BbjDaNZBoLwiaFSYNiY9Dpo2Ijo9DHVyIcUbHc6TX6
SH0WOr2eaDR60MdGGfTR2uRQEw2MjQnQDE6OitVrjNHlUdydQ2PKi2KJMXZ67KJYZ6wU202X7xqC
HsAjwdAgOUtD3tKc1JzRsExNkYZqYqM10ZrBAaMRdHRxdHtu1FNPnz3N/R4z4fep+PbG4+E0en5h
oeLg3PE13PGREW/MEP9LAa9K4qaUj2eFen7zZwKWLCz24MvX3BO/as9t4ZOumHKHwxwVV7XnxOOH
3r+1bsImau+pmJtZOGHyinn5XeQ1PFQIPIqRsxMxDYCHrGXhw5kcVBpgDZoRdLNurWFV0GNkS8A+
EqjVaAKipOEBo0ETYDDk6DWRer0G16anOQQi+ctRr+cBMgACDOWgN+opojEIg2a5TLLIGcKc5HZC
iTfwAJkqrorc5Hp+5PfDQuVxzd1Sr4Y5Nc4vqUTX360PCI/OJakVZpYTERWdl4+Rn8x4xrMgNCp3
Jqk52LNRSurZV/XBkjvpSn5IwiJpGSj/SoPvb2dxnmDUHqvyFII034LvX3No1BxSeQnQTlReAzGa
8yqvhaHaYpXXwWFtlcrrIUnnUXkDdAW/r/IB0h/EzJwPhOqQapUPgrqQwyofrN2tS1D5EFgYmuL/
y6UrQ2/y/xuNGmOi7x9ZBG34cpVnkBdep/ISBIU/qPIa5G9QeS2EhD+h8jqoDt+r8nqIiLhK5Q1Q
EtWq8gHUZtSofCCMjNqn8kGQE/WFygez+RExKh8CGdFD+L9+ITHULSR6rspLMDh6kuA1ot6p8ry+
RvBajn/0zSqPmEcvF7xO1D+i8rz+LsHrRf0LKs/r9wjeoO6vwiv7q/DK/iq8sr8Kr+yvwiv7q/DK
/iq8sr8Kr+yvwiv7q/DK/iq8sr8Kr+yvwiv7q/DK/nI+oB9WAf2wCsT6SHXtgVgvq2sP4v/qZvQH
Ki/B0Oijgg/Ben30jyovYd8vBW/k48cYVJ6P3yP4CFFvUXmsj4kWfGQ/zCP7YT5IyF+u8lx+pOCj
RP2VKs/rywQfy8eJWaLyOE6MXfBDhPzNKs/llb2O6zdvXL95TWKcTSrPx7lH8AlinGdVno+zXfAp
ov5dlef1rwg+XYzzncrzcT7hvL4f/vp++Ov7rUvfb11B/eSD+skH9duXIN++zIFOvNfYoQ5sUIO5
DE8izYEGwU8FJzQjuVUpGSZgqRV5ntqw3iEkZKxpxP4ZyBWLetv/40iZfs1kmI0tjeJvRyoyLqyb
hLky30gowE8WpKtctqgdhz0aMZ+FfepRB7foNQvHcyG1QjumtUKHZmyzQ5Nfk1acV0YpmzqTIu9A
hGTswfvzEZvxFsVn4S02MVONOpYNa5SeTWJEvoIG1L5JjOjAFreQbhBzcdTd6gwuscIa0dct2pvF
KDznOjmFDg51LS1ibK5RjdDKJWbjLVy+VuSK/m1iNlnM0F8rhxjfje3Notwhxm5QZ7ersk4xljK3
r75RjO1WEanBkoLMhXJuHNMuUHFgroxdo9a0CaT5XvVZiVPsS6tAtFH055py62hSe/lmqBH929VZ
HepKeZuCZh8KdSjJR1Nq+3B1qOg61ZU4hHybKPXtqktYbKPQ7tdtwuc5Lv9a7OJP8/Hx+sZoxXkW
q9raVPxrhE3Lqt37MKsVc9eLWqV/B7Y41D3kMo3izwfzHk5M67GtXUVbGaHPl21irxTrkAWGNer6
HWLXGoVMi/AzxRqbRU9lJf2t2+G3LBnbl6o70yS04bap7JtL9eRGvx5NotRnve4L4o3rgvXVqHNU
ixHaBNK1A2zTDkuw3ocst+0a/wrrhG3LwgaWCmxdwu7cYjfq/bvOdVf8nftSmt+bXKqV9cUjpbVJ
7IgNlon+itZ83BrR2mdpyuy1Aq0W4SWd/lX45ub9O0S7TSDRqs7BfUhB0S36+zT2jd4ibKhJxFCf
bhkXxdUxA3aNx7t6Yf82odkksbZGgTb/097K7L7IyyPnaExlSMZxuUyr8A7Fq0YMGLn/SH316QPq
p6Iv9LU9I3yjVY0VTUKjxX67+L89J5S9rFejp12NiX2xTRl1Lp4hMswQ/WVIEvNNxXQ6zl0nrN2H
Mrdnl9ihBnW0DJiGcnNwZaVIE3BFnJ+Otbx/KaZTRH0J1szGlPvNFYh8CX6mito5EIzvFE5zhKW7
fsUPZH+9orGy2y2qPfT5z8X4KOekEzFoFRbVIKR96/GdFj4brBatnSjf5p+zxh93FezaRN++eGlX
PYpHtb4Yr8QWhxrPXWq8qRej2P3xmmNboc7GI0+7Guer/SelMqf7XyDjs8AOf+S0q9HA7ve3VhHb
3GqsqVN95dfw8kUIjpi93yh9Eebi+WpV++K2XC2itqJ1tbozzerIv7ZDw8WqBiKlnBYXW8XFM/vi
Lo+wNnELsuGsjSraLjW+/dbcGcL2m/udAZ0X7YVdvQH19xzlZLEJjVoEsvyscwh/+/d7Lqu22Nwv
7vrm5d5fK5B29DvhWvvd0tL80q397LbvXvGvkeLaNYnxfXblHDBeh9j/xWI3+0cTX+zuk3SirBJn
2gTifPwG/3oUvfpbd5Ma7RX8Fa9qUe2j71QYaEP/akV99jFJrP3infPdC/l5aFdvj8pqlLtojdjV
5gv2oPUCvPtG5utzitOiVo2r7eLe1gH9b37/fvd94yk+aVfvJwNPcd94F++jglbfbbpGjHmxH/t2
zHYB1nX/K237UL54hoF3kYEa2dUbthvPUd8I/JQZh7XpwE/Q0ZAL+XhqypiOxFI6vlFykbKAv8vn
QpkqmYWtI7ElV+XzIQeJ98qDUfie4cRHbxD3mBacLxM/HeKTIe4DAz2+RkS+3zonOFcsvLPDbxfK
KehQoy3XaZaI0MoZOk29mznVWz/3T+UkbRUtDrEDszHtOze4VfHXGL9N/O/0zhTy/N/GycTULSIE
36tMcfYsElai3Ccy/JL/3Rk6xB1AkbX/V2bxtWVeYI/+sed0ttjrbDV2+Ul5ToNdnupsdrqxSp7g
bG1xttrcDmez3NJYkyEX29y2fyOUyQeTZzsb23iNS57UjP1GFhRkpWOSnSGPa2yUZznqG9wueZbd
ZW9tt9dOcDa77U18kNZO2WXDTljvqJNr7S5HfXOaPK7VYWuUa1DK5sDGJmerXW5oa7I1O1xuuabB
1mqrcWMHl9tR45LdDbZmGds6ZWed7MBZWlrttfYau8vlbHXJtuZa2Ybjt9U0yA51KEez7G5rtssd
DncDdrdjrbOW9+Z8ow3nwP42VMZX5+6wN7sddpSuQaattTNDFpA42+2tNlyeu9VuczdhE+9Q04ZL
dPHJXM46VFOoUNfW2Iis0BWnb3LiJI7m2jaXWyzV5e5stPdHgm+Oi89ib21yNAuJVudiHNaG+te0
4UTNQrNah63eyds7Ghy4wgZ7Ywsi4pTrHe12ISB22SY3Ihxykx2xa3bUoLitpcWOMDbX2HESBW4H
B0u2L8XFNNkbO2Vcmws3uZGP0eRoFPC6VbtxqfPVYI9qu9zmstcqaNqXtHFl22o4/nKdE5eMI+Ki
3G5Hcz1feqsd993tSuPb5ELIhB1hsclWb1vmaMah7e6aNAU07F7rcLU02jr5FLx3s73D1WJrQdVQ
pBZVdDtcfGAu3tLqbHKK0TJ8tjpGWdose31bo61VnuS2NTpqxszD7tx4szNGZ8vJUx01rU6+VSMU
YUVI8OkKP3WOKD0hz2lFq2iytS7mWPwrn8BV1qN52tEShbWh6NzZ8gybW06S50yVp9fVZQiV7Y0u
e0cDimVMmz5nUumkCePmTJo+TZ5eKk+ZNKFk2uwSedwVs0pKppZMmxMcEBwwpwE3ybcHfMP4wLhs
xMMt9sevD/qks77V1tLQKebhbsERrO6UO51tvGcNt13Urq25VtglWguamrB4tBYH2jmK2+pb7XZu
1xlyBXZrsKFROau5U2JP9wBlOIAd3DjtaAZ2vm+t9ho3Wk0d7kqfXtwgnPV2ISIMxt8PNxp9obrN
jUOjmk70z34LGu7yKYVu4YfC35nbrtxua2yzVaO92lxob/17Z8hzm4UHdPpWgWtSNwedxSa7Wuw1
jjpHzcUrlxHFZmG7vK+tttbB9xjNpFWEtDRe3SqwFbHiAqUaHU0OviCcRMh1OFsXuxSTF9YtKp0d
aDNt1Y0OVwOfB8dS4G5Cs0f9cataOmXFFVSEBk4k8JhU17c4HguXtNldYhqMojX21mZ1Ba2q3kLY
1eBsa6xFW2132DuU4HfR8rkc7qQd40ltX8D0rxHVEmG6xt23x3xhNlXrul8fVqjs76BGEXUgnMfm
HsMF5s4eJ6fLyaNz80fI+SNHp2flZmUZDHPLsDJr5MjcXEzzc/Ll/LxRBaMKggMa3O6WMZmZHR0d
GU2+ja9xNvX3Cbtc3Grr4FigC6JSONIsZzV66DSMZk4M/WncSVsdNQ6bPNsmfMOFZ9no7N8YO7PB
3dSY2eTm//+zzCbXIhuPExm88j/s0GFvxFr7v+/CS5kqjkJ6wJcjE8Q12yUuvrYBLYtFyzI4/Rst
Sp/+9WX96p3i+tzWv51tZM+ybWwX2892/MYXNMrzoH9bMZmJufsCnZ395vn11fBH+a/p1imu7xfO
/rF63RkwmjRYmiBZpXHSaCn7V8b6FWRIln8liwf0mAFOYhOPlOYLNG4WjxsHfCW4/i0lONYyca23
AcD/AZsl9E0KZW5kc3RyZWFtCmVuZG9iagoxOSAwIG9iago8PC9GaWx0ZXIgL0ZsYXRlRGVjb2Rl
Ci9MZW5ndGggMzA5Cj4+IHN0cmVhbQp4nF3SzW6DMAwA4HueIsfuUAEpaVcJIXW0lTjsR2N7AJqY
LtIIUUgPvP2CzTppkQB9SewYQ1LVx9qawJM3P6gGAu+M1R7G4eYV8AtcjWWZ4NqosAjvqm8dS2Jw
M40B+tp2AysKzpP3uDoGP/HVQQ8XeGDJq9fgjb3y1WfVRDc3576hBxt4ysqSa+hipufWvbQ98ATD
1rWO6yZM6xjzt+NjcsAFOqNq1KBhdK0C39orsCKNo+TFOY6SgdX/1rMl7NKpr9bj9k3cnqaHtJyV
ZShxQokdKs9RG5JcdCI9ofKUdCTlqG1GeiRJUkXak86kCiXp9O0JS19q3PxWfH9DQemFpOroFEmS
W3zsBE3S0XJPk3LJS5nm7sxf8d56dfM+dh0/NbZ7brSxcP8b3ODmqPn6AS9joFoKZW5kc3RyZWFt
CmVuZG9iagoyMCAwIG9iago8PC9UeXBlIC9Gb250Ci9Gb250RGVzY3JpcHRvciAyNiAwIFIKL0Jh
c2VGb250IC9BcmlhbE1UCi9TdWJ0eXBlIC9DSURGb250VHlwZTIKL0NJRFRvR0lETWFwIC9JZGVu
dGl0eQovQ0lEU3lzdGVtSW5mbyA8PC9SZWdpc3RyeSAoQWRvYmUpCi9PcmRlcmluZyAoSWRlbnRp
dHkpCi9TdXBwbGVtZW50IDAKPj4KL1cgWzAgWzc1MCAwIDAgMjc3LjgzMl0gOCBbODg5LjE2MDIg
MCAxOTAuOTE4IDMzMy4wMDc4IDMzMy4wMDc4XSAxMyAxOCAyNzcuODMyIDE5IDM0IDU1Ni4xNTIz
IDM2IDM3IDY2Ni45OTIyIDM4IDM5IDcyMi4xNjggNDAgWzY2Ni45OTIyIDYxMC44Mzk4IDc3Ny44
MzIgMCAyNzcuODMyIDAgMCA1NTYuMTUyMyA4MzMuMDA3OCAwIDc3Ny44MzIgNjY2Ljk5MjIgMCA3
MjIuMTY4IDY2Ni45OTIyIDYxMC44Mzk4IDcyMi4xNjggNjY2Ljk5MjIgOTQzLjg0NzddIDU5IDY3
IDI3Ny44MzIgNjggNjkgNTU2LjE1MjMgNzAgWzUwMCA1NTYuMTUyMyA1NTYuMTUyMyAyNzcuODMy
IDU1Ni4xNTIzIDU1Ni4xNTIzIDIyMi4xNjggMjIyLjE2OCA1MDAgMjIyLjE2OCA4MzMuMDA3OF0g
ODEgODQgNTU2LjE1MjMgODUgWzMzMy4wMDc4IDUwMCAyNzcuODMyIDU1Ni4xNTIzIDUwMCA3MjIu
MTY4XSA5MSAxODEgNTAwIDE4MiBbMjIyLjE2OF1dCj4+CmVuZG9iagoyNiAwIG9iago8PC9UeXBl
IC9Gb250RGVzY3JpcHRvcgovRm9udEZpbGUyIDI3IDAgUgovRm9udE5hbWUgL0FyaWFsTVQKL0Zs
YWdzIDQKL0FzY2VudCA5MDUuMjczNAovRGVzY2VudCAtMjExLjkxNDEKL1N0ZW1WIDg3Ljg5MDYK
L0NhcEhlaWdodCA3MTUuODIwMwovSXRhbGljQW5nbGUgMAovRm9udEJCb3ggWy02NjQuNTUwOCAt
MzI0LjcwNyAyMDI4LjMyMDMgMTAzNy4xMDk0XQo+PgplbmRvYmoKMjcgMCBvYmoKPDwvTGVuZ3Ro
MSA0NjE4NAovRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDI1MzU0Cj4+IHN0cmVhbQp4nOy8
B3hUVdc/uvY++0zvmZbJZEomM4GEEkgogUgGSLDQe4JEQm8iJYCAlCA9VAsIqDQbVYYQMAQUVERB
EWyogIAKivoiqIhKkpm79plJBD6/9/3u/97//3nufcjkd9bue5+1V9vnTAIEANRQAgKkj5swdNxP
O8Z/A9DYDqCqeWTgmKFvkuHZAGvyARK0YwZOGaf8UPMUAMF68Dw8dvBA0h0qAIL3AZhfHDFm4pRj
m4qDWN8S8xtGjBg60DTGuBXbXkckY3bIsawbKzB9ANF8+MNTh32V2Px7gF7/AsgdNWzc8DGPpmz5
HaD+CAAxNHjyRM+qcR9PBmiF88nSB48ZOG54eeflAJYvAOKWAV87/ehfj82/uGaAPvt3RYIC+M+m
b1NSOd1zT9l7N3fWDDe0UnTCrBLbE6kBXuVtwl2gvQFu7gxnGFrFyut+xHq8RKyHlxwYDCJQMEBj
aAfANKoa5BWVxbrQrDqE6OfwECsGC+J+eSI8KvaBfLIA+tGtMJ1DSIQg2w4TsO1WzLdFWsn7Yvve
iPOIbEQfhCNW1hkxENGT57HtPt4XxxjHx5FoMfRTuGGs2CdSg/OtEt+FYYh1mN7EvoXNsiwYg/kX
sd9BBtCCt8E+q2RbYTWWP4f1g7FsHdJ8zG/EdH/slx5LK+VLIZ5ThAzL6+M4i2P3myK8Cc1ZceRr
vJcCHPMBxHycoxvSDoiO2CYOaTvEAvIuLCTvRjZhPVKYg/Mv4OWI3Bi9D8eZh/U52C8Z83Mw7cB1
yJDqEV5EPbodsqgZDiBtjPffN3rfiHdhBL/nunvC9cfW9F8RXWPHW4Fzvo7w0azIJaTKW9Z2J+bc
gfuFDChBOhqRgOhOj8MY1gkI8muNeAkEDpRMzqdziHvYEOiCeYLr7CmWw1qeR3SWUBypYc/BBuE6
tMS6abJVeB9DkN9NEDegMf0XNJT5YRbKVy6OPxuxDse8LMnDEOiF8zdCmsEuSTI0H7EE57payyfO
G8zPxn3tgXNVc43B/j0R9+K+lCAe5uvB+RtznvN9J33CWdj2Irbpz4HlNgl471wmeR/eH8fyx+Rw
098UNmGbpcjXC0gZwsLXUAtJzmLAuiM4TjxChkhENEJcQmxCjEa0QryGqIdzA84rSPKKMsNlU5IP
lA3xXeQhrk2S2eg9rJP2M6ozG2Nj8Xm8su0wOgYvH5PrC5dZXMuu2rG5TnGZqaWSfI/mck9+4ffJ
ZaqOou6xn+BevgZJB1G2ainXO1wz14dVtDcsRLoW5XgOl1m+vlrK+cJlTeIJ6kSMZt9yr+mSjiAV
AHwxWZ9TS2t5UUdHwIs4ZpFsENqUDXAfmwj3CU/AIHYNcoX60EhMxzK8H2wboj9BD8UhyMC97Ir5
NXfQ1Rzyz8go8RDe5zbk52fwPPJ0PPuMJrHPiChui/wgAjkqbqMzpfR/oXeCHIrWccpxa93/3fL/
FdBT4ja0mdsiP4qfRSJ4P09ynZD/RNIRnlqK5WWIEkSqIo2sVowmFfLeYJChb0OMZUFoJQahBTuE
+2NBO4+6gOW9xa/hoLAUFrHPIl+SEiihn8F8uQUG0lVo03AuegrmcPDxkY67RY5uk7k7ZamW1srr
nZTb/JhMuZHKUP8+jOFiDDcQv6McvUCic7Tg9lnyD2ijEfOj8hq5WSefR+ElpItr5fMOOR19h3xq
7pTLO6nkW9C+1+oprmNR7f1z+8htHLeR3M5xO1Pb/k56S/9SuhXlmNvh49AvptdJMTyAa/wmpvto
h3G/+0Yisg6RV2Tlkc2CKbJZ1hTTXyDEyCt431PqfGp+JBzzp/VrfWm0HNS1flTMgDExe/aiZG9+
haclP9pHWp9SthNmiVW472gDpfVuiOkg8hPXPZoVIc/XwhK8j3hhAeojliP6c55IewFg536B+0Rh
JfKZ+6KlMEc4g/EC75sBRslf5EBfXPtRqQx9Kqe8TOwLm2Q/QVPWG23tIRjC94rfB18P33vFJNAq
LGgnPoMmbAu2sYAK222QeBCEVyS54H1HY1yEvJAPBjnKbBdsw8fbKPUJginGjxclXkj9MRbh8sV5
gWPKLNBDiid+gvVib+iLOrRRXgIbZb1R5yywGcd4Cfv15mvBfg7JX6+EB1G/FqJtWog2ByT57xep
Erbh/UxBu44QSpBH28AuliAPR0v3nsuiNnYB1x9hKwS4jMhWoh3m8cRKKGVpkCcbDUuxbKmIdhLn
XYxlc1F/01F3F2F/d8xuA869CMt53xwey/AYgeuLPAhxshIpDgBpDTxOwfmFH2Cj8AAsRDluq1iJ
fJgHDdFfEJQ9F6JJFFJ+ZgxLopDKDFFKvIIBZkjlGfAx3SqoUW65D93HZsNI1geaCk0gnhmhIfsI
dfUveFbQwwB2DJ5lFbCE51kc1BNCeP/lGFvy8hPQjZfTjzG/GvqxbOy/EB5hA6BY2IWy9ymo2DDc
a+wnLkM5Scb+v+K4MZBvoZ/QB3VrPqb/imzn7aQ5yiN9Odh90FDqdwuktdbijjXTjsi3B3BPcb08
fdt6ca1166xd4z+sT7pPPi72423Ys4BnlshZhD9Kw93pUtiG2EBPQ3uhM0wlm9HAPAcdyCXEczHs
gPskugvRHX18MzId0Yg1g9cQszHdAOkbiJ3RPMZuzeAMYh6O/SbS3fxcwEHbQXNOsWwdYjXi/dq6
W8Hn+qfyWyEmwO35PVDCQa5HajjubI98bo7zNWf3ID8RKIsrOGSzoJ98Mu5fCpa7cMw78jhPU7YH
Rv2n9fwnkBOQLvEwiuCt91i7H0it/wOcvYV6OI35hv9H6/tfAe7vLEShxN+fwRKTIR05BUlI+yDt
I0yCKRyYb4j5glp+Ejz9StgMT0nldfsXLUdZwSMl3HNn+Z35O/f1P+XpbnjpVtTKQZ08PAlzOVgO
tkfcmVcchbkcsnew7p3/mmev/Af0g1RhrbQmkGTsjrysK/pMBE3GtTqkPks46vInUJcRvK3UXwtL
OSTdRdByGMlRV98M7TfiFr4253zFOaX62v2p3Zc79wfXF2QfIvqhr/gQ0pH2RNq2ltbJd8xe3Cbz
3aPyXpfntuTSHW3+1om/deME9zX/POb/n4C6cwzxLuLI/+65uJXhNsLA7cRZjENyMI78DOOTB2EO
QA3akurGiJfRDvVC+jmWofcO10doMW3EsuFInweo+h3TE7D8sygilCXAhlhcGY9le2N9FbHxekb7
V70HcBMl6ubOaP+qrYhRmP4FMQPTXyF9E+lqbP8j9puL9K1ofc0AzE9GHMD8T5h/GJGP6RVILUgb
IOIQJuy/ioPHI//lHPr/Ov3n88f/lGLMMhjX6ebPvJBOv/MM8T+mtfv5H+idZ43a/f9P9JZnBnfQ
KB/wzPQNxn2hW88+/+6MU0txP8O3gvWO1GBMqeFxNI9lefwsxY8xKp3fpDgW5wUw11IeO/P4lcfO
PH5FuhHpQpkorac3P+fzdYHkUiQ4JYUAZQ/MYUqVD0zZnD+j5Y9BoSXMJLPIcvIk2UhC5CyJ0AL6
Lj1KvxKIIAhKwSfMFEqFJcJG4UOmYV1ZfzaAPcWeYc+zF9hutp99yX4Q94lviz+K12UaWYLMLWsl
6yEbLRsjGy+bKZsvWy17UbZFtlP2gewz2V+uea6/PHqPxePyJHkCnkaedE+Gp5Un29PGk+sZ65nl
edHzime7V/TGea3eJG/A28jby/uQd6V3cxJNkiXpk0xJliRHkjupflJa0n1JA5OG+qjP4PP6wU/9
Gr/Bb/bb/U5/sr+BP9Of7X/YX+Kf61/oX+J/yr/Rv91f5q/0H/Af9r/vP+H/0v9dIDsQDLQLFAUG
B4YFRl8WL9svt7pGrzWpolWequZV2VVtqtpW5VZ1rSqomlG1uGplVaR6UE1Oza/h6kh1JMKfgMMG
iXMbyE5ynNxEzh1Bzn0hQB3n5iLnlgkvMMJ0rDt7iK1gq9hatom9yirYF+yyGBL3iyfFazHOeWVB
WdE/cu6aq8S1waPxxHlsHg9yLhU519STFePcKOTcC8i5rbdxrqf3Qe+KOs4ZkXPxSa4Y54qShkic
8/w3nOtWx7kV/g3+rXWcO4ac+wI516qOc0MDoy4TiXPkGqsiyLnUqpbIuWBV+6oOVX2qplWVVi2r
qq5+qKYNcq6Ecy7yLQrmyoiZHqOvC40jZ+kHqBF6lMgnyaNkNJlQvQHzI7nMhtPCqeH64XqYnA7T
YDI8DCOgE7Sp/qr6bPXJ6verL1R/XH2Ct6xeU726env1Rvw8VT2rem7149UjqzMAvi0E+OZs9Kn+
hXmIlV8/eGHuhb++3nzhUcy9hkC7eqH0woyvJ50fdX7qhcpvG1xYdn7z+VXnVp3bdG4xwLmXed/z
tnPjz6FlPpd+Lngu41zy2Q5n885mn8062/xsxtn0s/XPJp1NOGs+S878fOanM5fPXDrzDe915siZ
g2feOIOznHnnzEtndp7JO9PuTNszyWeSznjPuByHHDcdXxvewEjvDfnL8uflz8mfla+Vr5Gvlh+V
75BvlK9H//WDrI2Ip1NhMNdd0vz29xT0uyhuy18TrLV5YQj8mx+hC1qaf65ZhliHEVEX1oMVIR10
ay17CDEsiv/uh3XjYD1iuS7/bh139AywenXp5H/bUvXf1nS6LSvACzAX5gkPwSr4DubDMlgMz8MW
eBFDhFJk6xx4Cq7BL7AUnoGF8BachauwDrbCb/ArXIdNsB3egyOwAwbBYFgBQ+AYDIV34Sh8CO/D
B3Acvodh8BGcgJPwKgyHn+EJ+BQ+hk9QVn+An2ARjIKRMBrGoPQ+AhtgLIyHcTABimESTESZfhQu
wxSU7qnwGMxAOX8NNsIsmAklMBt+hH/BPrKKPEMoEQgjIlRBNVlN1pC15FmogTCRETlRQIQ8R54n
68h6tEUbiZKoiJpoyCbyAtyAP8iL5CXyMnmFbCZbyFayjWwnO8iraLNCZBcpI7vhT/iMlJLFpJzs
IXvJa6SCaImO7COVRE8MxEhMcAG+JnHETPaTA8RCrGQJeZ28QQ6SQ+RN8haxETvshBCJJw7yNjlM
EoiTJBIXeYccgb/gJnwD3xI38RAvSSLvkvfIUXKMvE8+QJv5IfGRZOInAXKCnCQfkY/JJ+RTjBBS
SD1Sn6TCRbhEPoNTcB6+hNNwBs7B5/AVuUqukV/QV/1KfiPXyQ3yB/mT/EVukjRSRapJDQmTBujH
gBJKqUAZFamMyqmCKqmKNKRqqqFaqqN6aqBGaqJx1EwaUQu1ksYkndqoncZTB02gTppIXdRNPXQJ
9dIk0oQ0pT6SQZOpnwZoCq1H69NUmkYX0kWiQTTSq8JsYY4wT1ggLBKWCsuFp4SVwhrhefScLwlb
hG3CDmGnsEvYI+wTXhfeFN4RjgrHUVc/Ej4TvhS+Er4WLgk/CFeEq8Iv9Bf6K/2NXqe/0xv0D/on
/YvepFW0WlAJakGD3oXgTb3IXmIvs1fYZraFbWXb2Ha2A73KThZiu1gZeuZytoftZa+hn9nHKtFP
H2CvszfYQXaIvcneYm+zw+wddoS9y95jR9kx9j77gB1nH7IT7CT7iH3MPmGfss/YKfY5eqkv2Wl2
hp1lX7Fz7Dy7wL5m37Bv2UV2iX3HvmeX2Q/sR/YT+xe7wn5mV9k19gv7lf3GrrPfybfkIrvB/mB/
sr/YTVYFu6CMlpJM2AN74W08He2GcjgMj8ObsABtUVehh9BN6C70FvoIfYV8oafQC34n39NDbCYc
gDVwBTXzJXiS5MBy0pZMJk+gv3iKPAoVZDq5Qn5m49kENpsVCwVCP+FBob9QyOaySexRNo9NZvPZ
VLaALWSLWClbzJawKexptpQtY8vRIz8h+eRn2XMY06zDyGY1W8NmsPVsA9uInvoFoZnQXPhN4GdE
GUDti2JC8ULvMDtYKTBRJlcoVWqNVqc3GE1xZovVZo93JDgTXW6PN8mX7A+k1KufmtagYaPG6U2a
ZmQ2a96iZVar1tn3tMkJtm3XPjevw7333f9Ax06du3Tt1r1Hz169+/TNL+j3YP/ChwYUDYRBg4cM
HTZ8xMhRox8e88jYceMnFE+cNPnRKVOnPTZ9xsxZJbMfnzN33vwFCxeVLl6ydNnyFU88+dTTK1c9
s3rN2mefe37d+g0bN73w4ksvv7J5y9ZtwvYdr+4M7SrbXb5n72sV+yr3H3j9jYOH3nzr7cPvHHn3
vaPH3v/g+IcnTsJHH3/y6WenPv/iy9Nnzn517vzd2PFu7Hg3drwbO96NHe/Gjndjx7ux493Y8X8W
Owbbtg3mtLknu3WrrJYtmmVmNG2S3rhRwwZpqfXrpQT8yb4kr8ftSnQmOOLtNqvFHGcyGvQ6rUat
UirkMpEJlECDPF+HIk8oUBRiAd999zXked9ALBh4S0FRyINFHW5vE/IUSc08t7cMYsthd7QMRlsG
61oSgycbshs28OT5PKHjuT5PBenXPR/TS3N9BZ7QFSndWUqvkNJaTHu92MGTZx+R6wmRIk9eqMPk
EaV5Rbk43C61qr2v/VBVwwawS6XGpBpTIZtv3C5ia0OkBLXltdpFQaHFRYUcvty8ULwvl68gJPjz
Bg4Jdeuen5eb4PUWNGwQIu0H+waFwNcupE+TmkB7aZqQrH1ILk3jGcnvBhZ7djU4VLqkwgCDitI0
Q3xDBvbPDwkDC/gcxjScNzdkm3bR/ncWBze1z19wa22CUJpnH+nh2dLSBZ7Qhu75t9Z6+bWgAMfA
vtTfoai0A069BJnYsacHZ6PzCvJDZB5O6eF3wu8qen9DfXm8pGiUJ6T0tfONKB1VhFvjKA1Bj6ne
MocjuC9yARx5ntJe+T5vKCfBVzAw17nLDKU9pu6OD3rib69p2GCXwRhl7C6dPpbQaG9NDK2rk1JS
c57q2KOOs4SvyHc/CkTIM9iDK8n34T215JehLaF0cEtshj8FBHuFhuCOjAwp2xeVGlrxct4/JPox
Riz9HW17ke/Kv24vGRgrkfkNvwNPcjmpEzWsr02H0tJCqalcROTtcU9xjW2kfLOGDSZXUJ9vnMGD
BNkH3ZC3AwtaNUb2e718gxdXBGEQZkIl3fOjeQ8MSiiDYOO0ghAt4jWHamssvXlNSW1NXfciH0py
uXTqs4QUgbpfvcEalzeiVYhY/0310Gh9x56+jt375XvySotivO3Y67ZctL5lXV0sFYprny8k0FiK
JghSLQpl/7rGPJOvCTE//sokoR5SIVegVEolxNMhZCi6L3otUHm9/8NOFZFrvJdE/u4WW2aoVdrt
+da35W9bnqZUwAWzAO3Yq19pqeq2OhS16IT3xwhKPPTK93rah6A3aqYffysih1pyFCSEgsiy9rwB
yl+0KJa9rWFCLF2AP1w6GzbogIautLSDz9OhtKh0YEWkZJDPY/CV7qNv0bdKx+UV1QpORaRycUKo
w5IC5NUI0qphWx/oBRtcRUQQArjx2hjRFTEAsRyxHiGT2vGSsYhZiIOIa1JNULCVPZkRrECyWCK7
Rz3cVMoOjGb7F0rZ3X0LorRz9yjNvT/arFW0WZPMaHGjdlGa0iBKTf6mJZyqtE0PtbVi6H4SQWEc
Xgk9DHpCwA0bBAuEEFSQxUqCgml3cqDp+oMCAwwHBIJhqTtySCBlWmPTtioaoVfBBG76M70SraFX
duuMTde3fYB+AzsRBxEC/QY/X9OvYRa9gBqgx2sOYj3iIOIE4ipCRi/g5zx+ztFz2OoraIzIQQxA
rEccRFxFyOlXeDXQs1yfpCtP5yAoPYtXAz2Dt3UGr3p6GlOn6Wlc2idlLbKa7pMSaY1jCbc/lrAl
xBIma9MK+nHZX/XdFfTb3Z4094a26fRTCCEoTvYpDv4peBDdEEWIcQgZpk5h6hSUIFYgNiBCCBn2
OYV9TmGfY4gPEKcgHRFEdEMo6MkynKaCnigLtHO3tdIP6btgQ6Yep+9J9AN6RKLv03ckehSpC+kx
eqTM5Ya2aqwH7GNAakDaGOtF+ubuZJM70tZIDyJ73HhtjMhBdEUMQCxHyOhBmlQ2xG3CQfbDMQVg
yzL4QaIvwyYFBEe5g4H2KGMefgm0ugdTeFnvWR+gwcCqNZjll8CyJzHFL4G5SzDFL4FpszHFL4GH
J2OKXwJDRmGKXwL9BmCKXwJde2EKLxV03WvJKe4WXUcTT1s9fRS59Chy6VHk0qPA6KP8A38xvrZn
y1JTkWNrg2n1U90llaTkACnpQUo2kZKhpGQmKZlNSrJJyUOkJI2UOEmJi5QEScl+0hJZUUKC5bdl
s4J2UnKMlOwgJcWkJEBK/KQkmZR4SItgBfWW3Z8hkTyJ7G7L9QrpPW2a6nGNXuSoF8Xai2p/EK8n
EBEpF8RGnqRo43gXp0m7U3Oi+Uatmo5tex99Gzu+jdvwNpxHMNygt1GM3sZB3sYB9HjNQQxAHEJc
RUQQMmydhAtfLl31eG2MyEEMQMxCXEXIpOVcRVAYG1viTmlhjWOL7spz9G38JOHHS73BRIPTkGa4
T1juJHoX6eqKuGgLsPJTvsmoMOJpbe8f2j//0IKyrZIuo8shETdiRYwuL/sr0V1BVpcF9rvbWsgz
4GIodSQLAsSPtCUUS/lm4FRwmglOug1p0zJnH+ymLws0cFcSHe+11/2X86L7B2cFxeRl5373554K
Rsrcn2HJtr3uT52L3EcbVyiw5ECggiCp9EhN9zlbuncck5rOxoq1Ze6ZnOx1z3De6x7tlCqGRise
KsZcUO/uEejnvg/Hy3UOcgeLccy97hznQ+7saKtmvM9edzouIS2aTMXF1ndKk/pc0oC9W1SQEcEG
8lXyfHlXeXN5U3kDuVfulifKE+RmhUlhUOgUGoVKoVDIFExBFaAwV0QuBNP4A2CzzMAJ/84AASal
DZRf+bNibteIgsIDEIoTOtKOPduRjqFDg6HjIE/oRk9fBVGhAxV97UjI1BE69moXapnWsUIe6RFq
kdYxJO/2YP4uQpYVYGmILqwg6P0qSIQXzUvgoeo+IMQ4b2kCp/XmLS0oALt1co49x9TGmNUh9x8u
RbFr2t8/9tvSiaFVHXvmh7YmFoSa8kQksaBj6Ckey+7D8/O1vNx9eJRGUpC/T2hDfs3rwcuFNrkF
BR0rSB+pHXjIL9gOJeYXqZ3CBR7eDjwKV7Td2mg7P/bHdsmcYDulEvxSO79SKbVjhLfbVZycl7sr
OVlqY/NAsdSm2Oa5tc0xP7bx+6U21hI4JrU5Zi3hbUJtpCZOJzZxOaUmxAFOqYmTOKQmff5u0jjW
ZFFdk0XSTAL5u40z2kZ7obaN9gK2Sfuf/gxtl5ZGdrcuGNyfnwOKfHlDEUWhxZNH2EMlgzyeXYML
YgeEQNGgwSM4HTg0VOAbmhsa7Mv17Grd/x+q+/Pq1r7cXdA/r1f+rv7BobllrYOt83wDcwt239st
s8Vtcy2qmyuz2z8M1o0PlsnnurfFP1S34NX38rla8Lla8LnuDd4rzQWSjHfL36WAdgUYdkp0N1Wr
UF6LErwF7ayGcW0k4W3ttc9MqGT8i31qjMI1eKLTInhVw7YN2/Iq1ClepeOHvViVfWZrb0Il2Ryr
MmCx0dcO0iZOKp4E9ryRudHfYvzBoomTOMOj17Ti/+4H6/Lw3JZbPBGgYyi1Z8dQDsa5u+RyLC3i
txRqVVumVudhuBktbISFrXihINQ15GXZvEypjDX8r/s/KUbbcy0ooft3k6CLTITiAiHk6tiLoino
FYuqKzFc4u6huABvsJikkeLaMaRlQzQN/H5rMXFSLBXjw8QYjfbCLsW17Kj7wT5oqsRKiEc4xFcg
ngXADhD5HnGZ0/DIyGVezyn9ERtXxACwGXaQkbADDsJb5BrwJ3v7oBx4xJMLz8F0eBoWoBfrhyWL
oAd+RCx/msRHyqExbEQ/thGOY9u+MBMqwUrskR9gFswTPsFe80ALSdAWusFYWEo6RSZBfzjP5kAL
6ASPwDhSEsmPLIs8GXkRXoJ9wnuRGlCDAwbj53jkZ/GLyFloiD1Wwho4T55U7oEgzlKCLZ+HCbBW
KGQkMjxyE1fghUdxDQw6w3FyiKbh6EPhe2In04X2OMoLkVDkMLZyQiGMgLVQSZqRe6lX7B/pHDkO
VpxjCo66BspgL34q4HU4TTTitciLkWsQDw3gfryfcviQHBLCNbPDOZzRyKX6kIU1Y+ENeBdOEh95
k44VNWJTMShOi3wKZmgCvXG1r2DP78gfdCZ+ZglHWIdIO9AhX57g3IZ34GviII1JV9KH1qdj6Tph
Aihwxib4GQIjkd+rcfRzKDV7qYaeEF5g21iVLDF8IaLDHQnAs/A8vEm0eKceUkweJ6fIt7Q9HUCf
pd8IT7Mt7GP5QLzrh2AMLIVt8AcxkZakO3mQjCDTyQLyBFlDjpOT5DJtS3vR0fSqMEIYL7zO2uGn
Jytmc8T54mLZ5XB++HD4o/AfkaaR+dAd5WE2rn4lrMM72wcn4Ev8nIdviEjURIcf/tS3N3kMPzPJ
UrJJegZdjrOcJN+QH9AD/U6qKDpWKqMJ/Ckrfnx0AgaUT9Pn6An8nKT/on8JNiFJSBOaCdlCgTAW
V7VAWIGfPcLXzMFOsAjyuam4Slwvbha3iW/x92nyx9Glf1D9Qk1qzbkwhBeGV4XLwuWRr8GCe4jO
Ao9Q2bj6gfgZhfu9CiVuJ3xCNMg7B0klbUgn5MwAMoqMJ1OQk3PJWvKStPZXyQHk0ufkKq5ZS53S
mhvRZrQd7Yqfh+hQOh5jrydpOT1FbwpyQS3oBYuQKtwrFApDhYnCVGGVEBI+EL4SvhFuCNX4iTAV
c7MkFmBp7F42gE1i69j37Huxv/i+eEmmko2RzZdVyH7BIKaNvJu8u7xQvly+V/6poog/RYU98Nqt
rzrIBWG2kCfsgWU0g8XjieVDlOcBMEToTFFS6WaykM4g5TRZnCJrTVuTLnANj/ZP0yN0Pb1BWwud
SUfSE0bxv1TlPzIz43/5nc3ehivsAN7bhzjyFJmGzKRXZRooI9LfTZN3hHSWJrwPp4XzRM42whmm
IjZyhb4idEMpeJ21EfPBKzwHrwrjyQzYQ/MAVFWKJSjHXchWtAu9SFPypxDBqLcLSlEL4VuYA6Pp
F3AF9XghPEOGsOGwDDLIdPgeXkatqC8+IkuVWchROpKV0jhSDpRt4X/PTJKJIJphLikU1squ0i9h
EpxgKjgnbMfVn6CvCp3ZNbEHGYEaMAPmw/jIbJgq5rOPyXAQSB/wswto3aYLTZkX6Sy0Kv3Rpu1F
7a5EO9BW6IwldpScTigXvdFCrMXParQTDCVoJOp4X7RiH0K5rBetgOGijqDVAWDvh3tAv8jLsCYy
HB6JPAkN0R4siEzHETfDJVgOm8m88GMwDk+OX6JudxI70BNih0hDWkq/pD3pqtv3F7ntJ3b4ET+v
QgdoI+6HUvY59IScyJLIZyjd9dDCroFBGJ9exLv8GWe4TzgEGeEudFekgzAO7/c8dI+8EnETFYyI
PAxd4QC8JBdhoDwtNsHD/x7UHEM/xGkAIf8WnIyCaRDT0TCuRhlqCSB/HEBxCned+/geAJolANqW
Ueim/zP0j0Rh+BDA+CkedX4FiMP5zEMQXwBYG8Vw+m/YUgHs30URj+twTIvC2Rwg8T0AVzbiTwBP
EkCS6Q48EsOR25G8EMB/ACDwDUA9PHPVLwJIxXtPOwbQ4A2AhoMAGrUBSA8iLgI0xbEyAgCZWNYM
x2uO99qiE0DWXoBWyIfWywDu8QAEXQBtzwG0P3IX/yeQO+ou7uIu7uIu7uIu7uIu7uIu7uIu7uIu
7uIu/j8ASqQXLiL/Vr8c2pVTclEmr6BrgnEgsosCqOTsIoF4hUy8SIUDtAkoyRrSCOxphhvZNdld
DNezO9dkQw6mDdV4aZLuNXqNfrwQYFDtEQ5VB/mX7D3sEJ/m0cgx2XrxE1CDDRIgBTKIPKhaEb/C
QUcoHAkJ/Isuenu82W6PtydY9PGOJmmmA3Q9zjkUNHR9UC044uMFkmC3++vxcjeWN6Lry/xq5wG6
FtLwXprQtbuTtjeT8bwF83ocUukBApMy+/bjqy68cv2K4QZeIOdKzRVDtiE7B2HANDGasrI4FjRK
m2E43CTd3n5qsAfJqO9Kc0OGp4mbNAxgqnEyprRU7wYbs7iJUYWpOAWmUhPruUlTL14apDRyQ7oP
LzqicROriBeD2uQGsxwvUPtakdQmZpPCuMzmGU2tFrPMlxQgSTKL2ZrRtHmzzIBAMgj5b+oeXbeq
dM9r8+ftIlntC/q1y0UISU9Wf00urXsGKxZgRStemFfQj/V7/uw7ByuPHiHvTHx2afHEtcuKbxbL
lH/9QZatO8Mr3iWHJz67ZCKvQGb1E3aTFLESdywQtIAoEPFnCsJsD1lBKBklG/9KlJPIQolpTdLj
hGYZFmFho+Pp2NP0++/hn3GU6eHutAh32wD3BFUpegIGk1xhMFSQjN2wXqdAGjTK1+seAsEgeARB
2G58fok0cM0NvkUoVTkoUKSQBKgxs0XzFhkyOX4sBkLOr/ywc78Ds6em3ONDLoa7HyB/Et3Pp2uq
ThaUrtr/etgd9twxv6YerWegSpWBgEnJV6BaLxC+Aj2sFx7S69w6qttu+uf543xgzEwJ4CfDarNa
DLRmNm5d0j0p02Yf6Nf5RLg7uUC+PrBvVWm/j6tqTv8c/jWswNm3hs+ROXAcVNBljwqVa5usgnQL
BoiQTSlRkWxQUQEzIGspb9UVBsBYmAUbkOMb1BtX4yquF16/aLiCoolMlgTUEJXQJukZyGqzTJ7S
vHmLvce79W2a1Vw4fnz84kDn+IEP4ryVAGQBziuAP2infJrs6OA7gW3A+g1MGv9GobR/0eEqjx8/
Ln0XJ/I9zUKOCdBzHwiRc2XmLFoRORf0mLOeEQgV1gs7BSpMBmLmf+5JsJ1KuAz0MnJyyx4Atnsa
jpxtQA2Lcm+B2CitUNIlUpiWZuGyvGVFOD9e/NdN/soDeke+Z0bxEO5QIuwpl3niDc6KyLUy6lG/
EbkAVoQJoY9cCA5isgV0oXqh/qhOVMrVdpoX18nyQHz7hF5x/S3943skjJaPVg+Oe9gyOr4oYSp9
VDZZPU2/QLZavspw1H6anpKdUp/ROxwuJppdWq2tWBn0+jLTlQSUBiVVrnAbi6Eiciiow1IPBHFp
K1zvLpbYlIayUDg+jTOLs4sUjodCaMl/CCLOYOLKaTWhWKB+pgTiDFw7jYaAL0ku6z36kw2Tyya2
G/XJxk+nPrFvy/TpW7bMnP5AIf2EMHLP9gG7w5HT4XD47R2rXyPPh5+5eo2MIKN+Hjmf78V5ZFAV
8kYFxUGPENQaM0ezWXQ5XaNg2xlRgkykglIkGkqOqaS1m/gdAeGS79CIQa0+U6y9pXSReMSgSMV4
dSXJJvPQfncxXMS7SpPuLWrDc2xZxJjF7xAK07w+o0wmb4YylkGrytt+0uuZbxpPZI+1me5+9d5j
A/j6snG/5bg+F3wfbN5abC3bLx6U7Ze/qzjqlN+vKdD00o3WDNFNM02LW2Q6YLrkuJRwzaE5qH4t
jiYYnIZEg8sgeyNyDeS4wQqkysi1oMOlMihksmNOh9npdCicDpQ5hcMpaF2GCvri7q5GYqwg9j1a
l1kEVwXdH9QTqlEV2z7B9fD9JPvpbPCAgbQMaox7cugAOpbOooxW0mT0Fct3RTeU2/80LqSS20Iv
UHjRaOL3jpcFukZpOhTYqKZB7S63hEJSOMFv8QZaIEeac+PrS5JUMGqY0SzJ5Exe3YLa/C+svbp5
zWOPP0f2xf350Sc37nvlrU39XTt2tM0efGjm4UvDRj/1XGnciS9/3JG/9cCLCwc2QU72iXzHrMjJ
NPgkWE/UWrV52vlalmfsa5ycIPSwPmwYZR5inaSdap6vLTUvSnhJqxI9Av96nZr/STWTE59WQziD
gjjYfsK/PKElzco1GguzV9IXIZ6OCCZbXE6RueprTcUDPGM91FMiLw5IOhAgEDAEaGBFQ3sFaVkW
/wmp5P+rHCVH/bcyNKggT+6q1YfrMY24XhhVihrkX1ZjNFCckVE+ohQh51CQyPi4FtaYv0KNaFGX
rOUeZ5+cXwG9W59y98rRs3ZumpHRyWxSF1fMHzVyibnc++OrU46NHjbk8RXhy6fejJA59jULQo9P
32heR6fMGPz43LmePe8OLxsy4LlGrteXHQr//h2umP+vNAN6MBVo4XqwuSlfM0KzVrNFc1QjdhI6
aZ9mggllCzQyQS6q1IIcNBqt9pjAzILABC1QjZbJhf10PygwRNoQVPF/CarRwDEVq6DDXhNFVTDR
namqIC2CWnkwyZcpL/E2k6/QU65xWq05E6iBeqhA9+gqyBKJc/8qRO6lpV1H0fvOIOkbBk83so1Z
WSQWdDAUPL1ej7yTvvikRftrytJWRD4NqjOyhKSGWQJLTMzmAUMBchbbBM2aoDpLU9ItSxMMZGmS
nEgbZkkhRQGGYM1IhjHD4jMKRkJX1cylzz915Eh5uBkZ8JKwt/qBl8IbUTVW1oxGoeF22Cu+jLr8
YzCxo2NqYmniqrhX4t7WnNKcSVAo4+y6VIegTBfT1ZWorgKKniFOZTHFxR3T6c26OLNOr0X5C8bp
VC5LULcBfalOH7QQi8VpQjV9Tc/IJ1w2UXmDPuZyao0DDGMNswzLDcyAcmiX5NBOwG6wU/sKj+kA
aQZ6shKluGWZbs8/yaP7dnn8WyK5u0Q5zLmCElloRKDjvLhA0ShNROaCpNWSQpPxhbcKJkpjnNfi
FVAiwWKW80ir9+uWNQ8/Xr5jSd8l9bYso1/WvNZ17hOHiGLi0uvv1ZASQ+niw5vWlnXNsdJftocn
9w/f+OjdJ8oucK/WGblpQX1OhFQoC6aMjie58qAlNz7X08/UyzNaGCIfohhlGuKZqJjknKeY7zyl
+NRqlKNCl6d4fB4v12xjPVdQ201LUZQSyCcDOO9QiZWiK0FMcpm16G9bYmC2x19skHiHUY3BYKCG
FQ1UnFkukhVU5dgG2MbaZtmYrYIm706LebMrtZyKqa6kso0Lr9SyhausHEMd7r1kcq6hJm7ffElg
NLTg+krMt3BNqNptb3D/6D5tew+ibQ8ML6959OTcr8MXn190ecdXNS26Lusy4cVNj03bynrqRqV3
Tm/z89nBReE/Pi69MpN0JNPJljc3v1X9VeHWgop1q3fu5D5lIGqtVXwFdXZcUHdYSxj+UgVTokZy
c59OCVNqtMWCQPltd5UMvEAdekWx8ifoSgaQAVTIQTKWzEIHG6+LSQkeUwrHZ3e+fqWL4Qb3djw6
4bY/y5gVNfRcGpp5LTIQZHJfc5OpxUBhz5LwlY7N9fuEx39bxG7uWLIybApXVZzZQX4k7z5XG7vE
S/4vFd4IZrZydLIGfQ9a+/qGCQ9bxziG+6Y5ZriWOBa71lq3OA44frR+57nhibvHus66wyq0qj9E
RlO4Mvlwt+1ej8xTz9VVN4BrjhN3WCSfdItuejnXF3clyQI17rnxDl1pwCWhnAuCsS58MQaN1Lgi
7d07zfWVW1WjdsOhcDyJaUIb2iwzhW81UsCdNhmlkCZApK2OnjrG7bBOH9hzRrfmpPn+MXurifzI
8iuPTftl0/bT9P2XJk4p2zJ9xkbS0zDtkU6zvhinsfcZTRRfnCeGteFvMSr+Prz71YNC5rN7Dz+3
hO83hX78uy0Yb7ogCeYGGyO3Euh0x/QEOsgxNIGO1gzU0X4YSNDmulwdTYhXyBkYUoxG0NY3Exdy
Z2fQ503yZrtV7uykJE+21+uCh1yPqB6yjUo2POTBcGGUr/bUJ535eBydbaiRQuob2RInLholb1WI
P1CIR41m/KTBWfG3j2LcRemonJ9xyBfEZW2SvL/li48Wr7Xvi//j/c/xuDQnv7mDVhwnI5NNozq3
ap320qBWI9evWGM9fvrHl4s2TezyQNHD4WcwxKaRGjwGF6BfkuPR0BUc3NiQbhiuGKEsMiwUVhiO
ikdkhwzXDGqFWED60G6GEeqQ4TfNb9rfdEqmYVqmE9QqpcgYun2FTC7XYFoh08gxcPfINWYsoILg
YRoztlC6RFHhkgmyCjouqASF5ocg/wPuSqIGQtRBk8YDQ+VCj27sBDvPhBWMsApCgupumkPy8xph
hYZoeN6gl5+Q01nyEjmVP6U/9bl0MBkfj8BfO4b5jngDCpY9J9txJeeixN0rPOhHY7ugkT0tFkmh
nmUtMBw+rDt8eIEYpcjyjiF1z44hV/d++eVMLyjklRgFQuRPLpUFZML4Qh8eF3yCV4jzCoEUmVyg
GR/R/K+21Ty78Uvyy5oOSc4MsfJmB3IgnEv7kVX7Hl26GM8jq1CifkD+GiXrOzvYjbEOvj6+Yb5i
5VylbKRjkjhOWayeI85Ry1KsSsGekuqyJiqVcSZXamr9+uBMdCGX3C6XERT2gKyXP6BxNEh0eaSo
ujCtdX9JmKQnHzc6X6kNIREoSShY2VmNjfwRAomGQChRGUbvLTGOjvqIt2k0gAz40EU3jYoaplfR
wOb3i4cNn7e8b8mbS8JPkXtmt3ygY4fH14XPkDEPBdr3a9Vr5ZLwDrGyYN/Qh17OSDlQMnxXUROh
h9E6rPP9Y+tXbZBrWo7u0GNqE25Hh0W+FyejXiVCRbBoMB2VSD3QVDsYxsHExBKYm7gC1orbhJe0
+4Ry7bvak3Ax8bdEo86UaExMFFJl9YypTo/7Xm0fc19Ln/gR4ujEx0yLTWuFNbq1zs3kRbrZ+Jku
DszgMJgNDsYPiGX1sgi3Pyn1sgx6ICwhzqURElxMaQjoH4CAhxDicNsCHgVRxLsG949a5M7cHBd2
rnVFUT1MSyvkBywygdhkzJeUjNwxJaMK2uQBrpDUYjZxO8TK37on/PalK+HPn91J2r91ljRofTDj
rae2fNt/zHfzX/iG0iZXq94kj3x8ifTedeH9hhue3BS++sT+8A+lB9DqrEMd7Icyokf+zA0GPG7S
XhHdeKPBpQcFLlRJlA53oiG2766/9z362CO26U3S208NNhcS5AqZQlQwBZPF2x12KlOrNCqtSpBZ
rGZrnFWQJQg2LzHp8GJXOL3EqjJ6QXr8k4o/s4kkJDarDQ+RZooi4vc2jR0y0A9715G/tvWbWTCx
uMu0J47PC+8iWU+81CSv8zMPd9kR/kCstCR2GhQ+cfiVcHjLwKY7mjfJ++Hl7/5IdXEp2IS6wL+V
roYHgxaZ6FIo5HIQGL9RldKlBoWc75nTYMqU9xIe8Kg8WqpyaJkydtea1g9GN4ofD6Wtun4x7U6B
b5KOi7d4Y9jEkqvXCWnVnwlzxcod4ZztYe0OvpLNuJJ5uBIldAymSitZLid1i8GFPIcnEjWlDnXd
7KrW/e+Y/WLUaXPvdefMm4Wvqi/RUE03PmurHTXDcIQxqAP7UAf88EUwL8GcYKFFKeQhRRwxCcnJ
4DXZqB9wdiKzuXSC1yVTEhJI8Sd70IJST0oRxhUTSlJISmLAoyKq+MDgB2ultrOhEEWhMy6Bh06S
7HJmSNno+SeLxxQoGrnMl+B0OOOdgkwTMPgtAXdA4WcBn9+uTfSCVR/nxcbmOI8cc0mi30ucapQR
sxEvLqXXC8kCXiD2qJA/qqz7iwQuNaglzfzG27TEapM3oqgm/DGZ2cRQUVoYhU50zPLwyQ1fhNeX
7ybdzqwn5MnATu+gvWPnvfWot+UCQp+Yea0NzdlOai5MKN5HHvriFCkuH17xdPq4ks7d53ZduP5w
+M+SgS2Ike/kQbzMxp0U4Ok9fOcof8awu+U90rOG3RmZUdowPUrr1Y9Snz9KE11RandEn0001hoy
PeIKcaeIXEcvthw2QAhYYwzyu8F5uAaiyYOFK3C6TexUgaSEeO4pK0EfVlgwfkJ2TWEtR/iBiotE
hvHgW9wv4Fq5L0iVnmJmBDWEMsElgsLDPR19JaiTUyEmarJb1Pu7wqiER4fyWla9RT/G4X7bgQ35
t2/1OJ6BTArOAqpXmGmCgk3WzNe8pxGUmvs19+uF+syvbaDLFx5kk7VTdAu0CjUVFVna5rqutKOA
xwBFZ207nWo1XSOskq9SbBZekctMVK/TpYvULIpUgafQdFGBSYWmh74HCaLLVvD/nabWanU6AyiU
tMhUYqKmSroZj0dNykSPooI0Cao0SpUnqJmlJupK2gdjCzXW0Ap09Eo9AY9+nIEYKmif1zxikVgi
CmIF3bzb2BoZGs8fNBZm2/HWJV+OaUdd5mIhevacbP74se7jQH/PPfyCGZKHR9IkHf525a+DJlIF
isgpjHVOSZ68Y0iDdfWwjh9p/9ylU/HS2An3073eLF0Dr3TK3dsiS9e0hZTc0xBLYyfZtAKMBWB8
oWQmidXWvAXxGn1G4iPG1SSZPJhujccjLRH3h/vsDOeLlVW/PnFft2eF6psd2PtVzdiFKg+PNAej
NfhK/BR0kACzgkUOPTEbzOYEW0ICYwZmVtvUCWyLba/uiE6w2ewJ1JMYNHaN62oLOvLFfGVfQ2/j
gLh+tgH2Po6+CYtta6gh3iUIJpdaaQl40JQ5ShJJoj7AxSneeauDK+Qe7tZHh+je4gzgbcq4sZd0
t4UBo20wZlJ0cDCYLCTN3ycdtpWH9x48Ea7c/B5J/PwMSZj6wxMfhj+nx8gY8vxb4ZfOng9v2PMe
6fdG+I/wCZJJEnYT9VPhSxD1bqwGpVQLdugbbDbUONpMOxo6mh80PGhmao0LhQ1s9qjdNQUUDo+D
4K/Dro1pQ/ytQc74whudr9TZXcnl1UY1Nhc6Y+r1GjFd56to/Sc7P/xkwc/ho+GF5LED6wo7NZkb
XiRW6kxD947ZH66p2S6QJbP6z7FocaUb0Q9jQIPrTCKdgnqTWkdMzZ393MMUY9zMVBH5ZrfJkYn0
2u6klEwjzyemZBpiVB+jWP/F7sRAtB7bG2KU1weLMeHXPeB8wNNT3d85xjlBOUU3VT9PtVD/jHaL
vkJ/Wfe93qDTaDxGvdlo1Bv1GqUpgXodVpUMTz9ajWhXKq02R7zLZgNvksQzu12v1ylcAd1zskJP
8rjkkmQhOcke452v9ea/nRbuffxFO48Wom+ZJBZiMQaJ0uPG6NNGse7xeOwn+mRHpQjqs/SGVkZT
K64CZLykMLrIuaAjPsuYFJ9lQuiCzixDkhnhRlhi+pJWcEvQiWFFnE9oRHF3fNJOSSd370ZaeviD
acc+6Vyvd6fI9bd6P9K3obfj12TjvFVdnnkhnC5Wdn1v6nOnEv3JXSaFx5Mmc5e0VMtrJgkZLabe
O0J6Ot0fT78/oXdNh3DwucHCYFYsTGTMn9JMyHK2F+6Xd0rMc+cmd0jpKRTI+yf2rbcoTldPG0im
yUKKv7k+05frz2vcz9PH19v/sHqUdrRumHmofap6mnaafoZhUnKxf75Qql6kLdUvNcxLnuN/UrtK
v8ri8ifrtGrRi7FagkIuYwKVEX9yEpZhSJHQcDlK8RUrNDQQD+lGisg4soLI8HwcCvobulxWQXQ1
VCYEHA8oA1Cf1Hc09QZMJGDqJelskzr3fhEPNbfFpfyxJuI6f6yJe8aPM9HwXjo6j49r4aIZTWPR
WnJKAA+Q0eeasYjVYrZZmU3aDTxMJwf6v6Yd8N6MsVt7duvfOvxw95HDZ/769At/zRcr9Tu2hDZm
tSRf5pdMm1/1/Lvh39aQzw2PLO3brjg3b7jPNjCtxQtDx745ZOQHs3WLl81+sGtGxuh6rfdMnnSi
eOIPeA/pqPeV0smya1ArUheyB6R/lKSsoMW7PdED3msyD6GNBSJgeg+RhJbXKvauieo8F11DzcXC
7wzSm6ec2le6zXiURePCiaw0nCBqd+y4+RuXgo1oVZNwTjOMD6oC+nyWrziqYFbu2q1xlsxM1lrR
gT2gmKx/Wbysl2uAGvljHKdMaQ7QQo+VeKzdrLTIOs5aYhWsWinS4n2V2FdVaOH+CfckrZCHXIXj
b0QNqWSCUEtIhjFmQJuhp44+lTKyoreGhKs+/TB8c9xb9+6YcWqvWFm966tw9QvLiPYHoWt12cE9
g96S3l5hLApiB+kJ8e/B+xqLJBXqCX5VY026pkizSLFIuUJzSHNNo/Zoumkoo2oFxsxKj0I0KxQi
Rh8eKpopFZWEij94VOiXhyrIUKrgq1fXy+qmICWKFQrM4xlaS4P1sgZQspyup5TyEqNH7CbSdPTF
K8RD4jVRRH+8cLe6aHPUH4/nb2Y47IboizRH/BV79GXaLefqqM81o18tAz2y7ZcypYlwgmFJReRn
6Q2V5H7rYbPmkvsF/n9gJD+ENtyLx2vJm2YQ2rbmvY/JjEbupIZkyZEajJ+qPi8ZN2UKqy/FUfEA
8sncTpMlwdz6EDDWNwXsWdDcmGVqbr8f7jXeb7rXng99jfmmvnbDasVqPRUYBjMyOfJKpdZolFqd
Xq8xx5lM/D+/2i0VkezdItg9nGpMRk6D/SwKpQdESjEONBMCdlGhcFnsZovFbtIolS6LCZMmo0av
9xiMZoPBaFJqFHaLqDcaUK5Ei0YU7Aa9XqlUKCjaabvJZMQzvMNmcxjaKkl38IAGrxZEEETSfa+H
H0rj4yvI4l0xm+2I71yDsU+NI77G3iVvaO53dZa7NvbhZjv2HYHapxqdb42EbidoiRfoDIcP4yX7
cG3q1gvujR73xsi30KSyV0RuRDfMj4Wpf29YLLrSYcluTVAMtpT2cALfwLjoBsaZkMRlYEjEH5QQ
si782Lvnkx0tVcT248ddfc6G370dfmR/+P0Uuc0cPooqkfPMyp+ShXM1jvC/fltcLryKsVLhEs/Q
e6te4JqxODyS2iVL0jLoZkIaoQZRlgZyk0CpXPYqE/2S4diueH5EbaRwPVuyF3Xn4jgMnX3GDMti
svTLL8Mj5d1X/vXlSj52SngkKZfGzgw6mZgmlxkEmgbEJBNFQl9lgl8O25XP8od21/9hXOJtlmH0
NfOS8nDxl1+SpeGRK2UpKzGWeCBymTlZG6gHLUhicJlSq0yN1zpS62tTUzH6trRIaJV6f2qhtjB1
lHZkalF6qXZ+/bXWZx1btJaX47fW2xu/v97h+BP1PrZ8VU+RayVum9ue1iA1M4tlNbif3degj6Ig
bZhiZNpkzQLNUc1f2r/SjC0ydYQZGidn2pp6zfYB9cfWp/WdjXU5uuW69bqITlyv26m7qhN0Oqdg
q6Bbg1b7SrPTKYe8FFVTp6CuP9AwEPze5Ar6YNCQEuSv4DyB9MDOgBhoksWtiNvly0zPOpRFN2SR
LJvfntQ4+aDshIy6ZTkyKmvSkj/T5U800Uzw77Rk11y6xK3jxdrXcVg7PnogrX0jx1/GYSDt535I
8lItpE+zzJToo842VHJbVovFbLX5AgJ/5hl96ouNhOwh+0btPHBv8X3NRp8eTjLyFs6amhiyP3Jy
0cKt3QxKW9IBp23Q4bH9m44ZOWJTIHFO7w7b5nWZ3cWs0zqS/apHGt5TMN4+fnHH4MAHGk25VjXv
npbkq3pOQ73Oje8rerDrPY/iDs7HHXTz0xUkwqngdiJq9MliMzFPFHPcITd1u5OcGc52znHuFW5Z
q7hsa7ajk7WTo1BRqM3XF1ofcoxSPKwdoX/E+ojjkPtLzWnb6fhv4v5l+1f8t4kX3BF3vEdsrG9s
Thdz9EGxk76bOEw8nfg7u2nQGCw6JqOQ4ETNUVmcOrU9+aSaGNRBdZG6RM3UE4kxAzIEP6WHCEYU
G0iIXCPMTXJIVyKQeNe9LWIvGCbwZwLXeawwXnJU+Cs9DJQ4j9Uw3osqYcTgACNnA/iSUgSMDere
pZCGr5RP2DVo5/hg+NfXD4ymmb2fmLz9pUmTt4uVNb8v77r8WHH4avjU82TVwd6Lj79/8shx1KZu
kcvCFZR6BxwP3qvUELezfVx7W8+4nraiuCLbs/RZYa32RcOLDo1CG68aRUcKo8RJmnHaEu3Lmj3K
vao9Go0VT6/fUkGXNEA/Vj9LL+gJF9b706UTeBGMw7P3BriAJ3El6PVqDDFMTrXc7mRqp57ok3VJ
CbiKZHWaGy022tP7nZbkE3LilufIqbxJQuZhyT6M5y8gJsT+Odo+INyoXZlw/cqE2mcnxqzGBgyy
Ci/WBlXEFn3llCl9uaIukuLMErJ3JV599XT4jwk/LNpx1r0zfla/hVtfnDtqGZlne+0ESSSq7YTO
3rkxYfTDb39y6q3HUbI6IJfOx54JnwpuU1Gm9WsztblasZm5mbMv7aXqYe7pHE6HiEOVg81FzkPu
T8XP4r6KvxR3yXzV9lP8JUmCrG53moOLXUcHl0F5I5qsbWRtRZtpO9I8bQfz/c6+qj7a4dpLsu+t
N8l1nYFYBJ3aoEfJUsuNgKIlqO0ZBPxGvd9gOGkkBmPQWGQsMTLjRFPyQfkJ+Xl5RM4477rKBXm8
K7NbTLA6X0GRkr4BlH1RioA4/hYtrtTeZlypUaujDEMxI+ZbXtO1HHp41meTRn06p2hV4901nu2T
Jr+0+bEpG+evW1L1wnoilHZvS3U3O1DTB8fePHL6g8PIs46ojS6ULAvy7FxwiBucFtpbKBQLlb3V
Q4XR4ljlULXCAAZioCmmL8Wb5hsOeRNTq/gmzramzo62zu6m/vE9nANNYxwDnVNkUyw36A27AaxE
r7XZull5yCdYnfoVhg0GajCwBKdKDlzwlGRlHAqXLaiV4sCU1MyQlmgdbv7QyB/I5DSYyC2jm7it
GYZkeTA5NfMWlsV0Ma1zzUU8vKal3RifJkWNNbHXXtk147OlNxKm2PN5Mn5CrbBFj+FmuVcKJYlX
egsqEx6qbPDzvh/CV4n57GdER6ovq8rmDV5Sc5p217Tss2j6FtLH9kI5caMt0JB64XPhvwyenZUj
yMr57Ue8zD1eHB7KS/CkZIPdQZdZSfTxjePT44Px4+Kf1Tyn3aJVOLT1tKH4Q/Esnt9dPYc7M1Gh
FTR6p4pYaJo5jgkyUK03E3MkLshsfgYCfRLVjbOkSctM6as/Kqc7cwXO9YI9/gCpBC/cICqw4+3j
sRJjevShGEheKeQBfbb0nZcsY/QJpdlglCnlMgW6FAMefcEo0yeQNJKWOns2SUPBmsC9bQZ/J4Zy
hXrI1dDCv1NQtn59nGPO5E79E1o27ZF74oSwdsn40Zkd+pqeV3UoGrSkehjKULtwd+FHlCH+hvRa
sEitFs0N1H5zJ3WeWaZMjE9soA6YG/iy1M3ND6g7mPvI89Uj1DdVv1t0jXwNUtr42qR0SlnRYEMD
eXNv8/o5DTqoO3jz6vfy9qo/Uj7YO7h+UYOSBqdTLnt/9l1NMdqsMksF3VVezxknlyyYwYMHIm6/
SuAQnAQuXTOCbUWnU6/KS3JqVFZLhj9D5bfbT9qIwRa0FdlKbMw2UU/8kOROPqg/oT+vj+iZW5+j
74pWMT6twUQvV8i0LpJCXufHwvH8qHSDf+PgYuzN6sXo6WQ8WjEbf6Av+c6U6CtVrpk2jF6kc2Ag
7hb1HLZT3bT9xBkL7ToyOXTm2iMfLT0w7eWhZza88eOal2dM37xj2pTN+Y7u/qZD+rUILSbZX60m
ZMnqkupRf56Ysk1I/ejQwQ/ePvI27v4CAOGydBrbtQ+s/IsoFlumnzUT8oRKLZO+MZRsi8+0KYwa
o1kQCeidotysVmn8ymBG88yIkhxSEmUX6fhmy2yeGbJes9Jx1g3WkDViZVZq9ktSF7Rg42v824Ie
5OwFYNDFcm83e+yrZPy5x/i069FvzGVHfSCPmiVx08l0cr9OpkkgWgUKGvDn2rMhrZCkZUQ9I56T
jT6jxBWZxbigfOahya92LJ80utvSbHSDvz5Z+OJzNQPoxgWP9Vw2o2Y/ythCVLFs6Xm0HGYEC7sq
Vyg3KEPKQ8rzymtKOSjdynHKEuX6WNEFZUSpcivRV8kZFZQyYSYBmShjKpncL4L0T4pD7BC7wGSH
2DVGgXnYScwx1kVRe4cTsqXv7mTn/P19Yb7lE8bH8W/A4l0sLC8vZz+dOFFlYYGq06j8kU3h7qSV
tEYTrAl2xvhZbM0yxPmiaFOIopwxysQ4IFo1FcwaZhTVcr4utUzuNOpXoN7jGUaj0fr/r9aeBDyK
67w3x861s7uzs6vVrs5BN0hIQgjEythaDFhgDLKRIBZGNqvdkTSwh9hDQjaxce2YHK5DnKbgtKnP
+miSmkNgsOOYJLab+GhwYyex8zm2P5PETkLqtpTWpZL6vzezB+AkvRA788+b9/73v/96/z/vza4k
7bNT1fYee5+dsQc83m/O680pJFmN2KDgpGUn6lmPYw+yCpEn0b148V5FMBesnILiahAUqZwSnXw5
MoVADWH6KXN/Fs6n8R6Yu6Znx2qWVnctnV68Yv9a9sPXXvv4lvuca+9lt55/4Pn1UezdgP/Mv+M1
JuqVUBnPbea2iIzL8S+2cxyziZmUaJXTPPM6BfwQT23sFOE8DWfVRgrmkYLQnVDCsayN5brEXuAO
t1C6XppkstJbzPsc/yhH1XINfL0Q5JaJPY4+xyA7yF3PD4qfZqds94kvcv/A/pg7zX3I/xv3sVCi
SpKNYVia43hIBeEC8sF6nvPyPMewbL1N8tpskgSSZwUK5It/mUSw25HE4i/ns9VAwu4K1Wokfinb
B1OPvR7R9RD3IaoH9YG+BWTHe/N6Rwp8J4+LduaeF1kJI0zPpUGcr+MtXXD2k02FPEhAWM6Qo7nJ
KySJLZVBUaisXM7hZdTKIJxeP6yR06F51lYu8vR7J7K+D4ubO3l4XhCs+eRhHz79/LAS5MwTuZLJ
6ZA99/ScMr9IK6S+zVKC1we9eb3LyQFanTvsx41/e6jcrE4NDZJgFZsj3q1bS/Gg0NTffDi7nXru
57MP3gbJ47eog7MTM1G6+uZZvN/4DlCDLqLdd59ANpiUupaZizydS8xz+yLzXGMuAoXqwSu5bNW2
+23v2Ng+OHxkY6pt47Y9tjkbi3+Nj2ZMR4MxEYdTBjPQ/Yg6CWEoXeR12LxNNjebVkmcb4qMBI/g
jmlrJQg8I9cAM1EtevEEEud+Glphd4BnPM2eFt8r/YVme8N2TqNLBa1W9JdrIsPUVlVwJRV2MEGK
qy0LKNKpegr/cgddD7borN9HNqIOHfXX7yunygEKBRC9uLaeOoUoHC/T1QhrC4MCdfXHqV1HCoYK
OcLMaQhQzpwdmiHPGCAtwHMyOBSiSu7S4vVDp+z1NHhldzmlOkpy7pJsz8Ub+8hjxlKyA5X4TDI5
F3vPBzse3T6xv/rWl/7qb47Ubr1i/M+mr49ec3s32/CVDTcNX//0k8dmGumvxW7q/sojM/vpw7t2
XfvVL828ac0jvwRu+dArIY+N4Tz048px5X3mV56PmHMejsU2uwgYOKVQB5RT/nf9c35WE7xOr0+F
CYXifA7J4ZSddXYyq9gp+G/f4CeCxLOK/yM/Pe5/wH/Qf9LP+hl6cYnPmljUSyaW0tykcna5menC
tGI+EcAuLj+v+Di3KAkSLzGc0uDmnOWUS1IthuGlUjAeotMlS60Ut4hhex/Kvr3twWsVaXrBjjXp
x9iG/U+uHl/f8emZNH1XIr7i3ldm8J6BVRAPNwJPHCiAvhMaUnkpIPdya4TN3KAwyhmC0Kl0q92+
Jf7Vyjp1nW+1f6ttq7hRGVKHfBv9cVtcjCpxNe6L+iepEpGzOW5gBmwD0g1yjNFtuhSTpdIKlneD
ynnryKq8p66+s52nEK/wGoS2i97BigblARz8AuysQyGoghWNRovKcOBr7lXf2Tx0bmiosF0dZwfY
/MV+W784bBsWWbBxD9nLh6ydfcWxyKpHPvfCzyjfLb/5wjuzZ04c3nvX4SOf2XuY9lCN90zMvjfz
6m/+hKqiHK+8/MprL7z8EnS9d9Zg5wFfVIjyfhj6a1lZqFyurFPYHu2gRldr8+Xayo6SjsorK8e1
fZrQXdpdfnXp1eWDwg3y1tKt5duFHbKhxEt3lJ/UfuR92/922Y+qTntPV72rzWm+WrZZaS5ZwnYr
V7FXK1uUX9h/Uzmr2N1OyBxwss75IFlHzkDdKYlSpJC0TdojsVKG8iymF6v1CH1iul4N6Tr1Sfk6
SdjdweJ03ZMzMl+Jl+yEa3QzRaza+0j3vWOfPbU9+84tW77Y6n50YtfXH8ukD80atmc/f911d88d
eHj2/Beu6Z45zzzy6vMvv/HySz8Bfq2ZNZh3gV8KqkDfDh2w0830Av9l9Dp6SuZ6SnoC6wL7qh6o
snV6Ost7qlZ5VpVDMl8e8UTKt1XtqXqde0P9Jfeh/Gu/Mp+ukZtLgvQSeS19lbyFNug35Z/53/d9
GPhl+X/SLop1eMsg73RyXkinkLPUuRjhrNNFKa6Qa5trj4t1ZdyfkHVWVl0Q55pB7tnll/IH7aTc
VpK+1IpsL0g5Wxbs3/Ts7D8mf3TrCzsfmpn3jV3pR5+cyD48a9DCZRuoVop/YPaOR+/5j5XMN199
9Xt/9/qP/w5HE5+BcOlF4I4b3RG6rM1DKSxVy3ayK9l+doTNsJzoFkRBdHjcogMxAmUnaoAksWmf
QAk1mofy0DXu3xulqr3P56PU08rQ2RTeUYIHFcxtwkbKD/Y6yYr2UAqvN5vyN/MeHnzFZx66wui5
4cYrrrzyshu9VWzDgzvXdD/W2NuzLTXzOqa/Z+4D5hDQ3069GbqFrfHWdItXi6vqNtfoNbvFe8Q7
6x71fL3lu4xDLC3zl7ava/lxqa2c3kTTSgcl+bcKW8Wt0lb7VnmrY7uwXdwubbdvl7c7phumG114
balu/tK6LdKgPdoQbcrUZur21H1Z+kv53qb9LV9pf0R6Qn648ZGmIw0vNPgq8Ts7alVwi9BYL0ts
mdZQwtpbK8twYlRRHegJ9AVuCjwZ+GGAcwWqA8nAOwG2OvDFAB14ht4EGT/C+ZOC9x4o1CmIkiiF
ovH2riNeXyfZ5lXldHdSVOvWylglXVlRwrMVrfbqMqqsLhDy+DsDx+kbDvN1C6DmUxXBUwuoBWUd
uFUDZPPbOk520D0dezroDoWiqDqk1blq3skHV4tyCfzO9fgdotQG4vRxDn+22XpctBPS+Gbw5ili
uKnT+U03peZUEGpcWFULiWaDW1EVj8JwNQ6tHIlNfDllWwiHKi9cznPWlqOaWocszIcwuKlRlLhm
thxVK5V40jC32pADeUVvQfPtt+MsZScO8wvbxhsbGlshr1vadcl6H/zhxXGS6PUcdn3ult27ltR/
+cX7+lYsW/Cl/k8/u8V9UE4bu7f7fG3ldz63f7Px4qd/+CZ1ecWOlL7q8lp/fcfa2zf0TjVVN6+5
ZdS/cevGrtqKSo9Ut3jF7q1b7v/UN7Cm1c39M73Adh8qRXtOIAlvsWnAwfTJ0AoA9gQgw5EdEsUg
nyI2uyRwlYzdpdSgGsqh1svUHC+sFldv48f5Pfw+nkUwxzzAH+RP8qd4jn+a3o781NJDI6axkNfQ
IKs7jb3AGfwYHnsBSCiUH5jr1vWl5rMn/KTA3UXeOCCrcbRSds3y4VjLnXceOXrU09xU9eD9yhX6
Q3TkboqPzf7p3TNfXt9ShsdyB1jNu+QbVZ89gcrwcx+IEGnN48OL+B+F5qvezmYPVSd4fDLl8dnB
4N0wHLTYV+8vJSFGKXWylCrdUEbMHocYZR+V0eNlD5QdLJsrY8sgv807BPzGlyaegkyQFTcE8mnr
mVx0AZ6BPLtdHrS2hoNKlbGK0+Fy4PUsvM8PYgxWLkcOwW0mTwsW3A4eEfTEegjX2EASqFKiJiSZ
Ynp2v3Hjw32KfdruTlx33T2XTf/l9Jp435I0fe/MkT9d1Htd/xc/SwchWaTweyvMB8ALibrxqSWQ
ote4gxK2Zoc7KEJ41SngA3187tdH4ExZZ6jx05BYNa8TNcEBrj4IiRBtIx8c4Oqt0NGm1k6kwcEl
z0dNYoMUREukNahX2kxtpgeF68URaoQ2BEPchSapSXpK2CVOSnupvfRdzOf4zwqfF7+GDohfkr6B
HpKeRU/xh6QfoBekt9Ab0m/R+9J5dFZqkZBN8iOf1IQapC6pD0FmYwupvk5bCAJFCZKselHyiqKE
GBryKbLCB3kYuG6yXMfxksggytYmU3KNEAqFIGenxeNU+dEQpAW0DaCQqNEhqsb+63/AIjtTFpgZ
mhkq8585PWQ+zgvmky938JL9SZDY7CzssCCbLHKrZx7Icv52Nvbt0/XV/ubfnphNsA0zd44mBybo
z+LsncI/bGB7CiSi0odCistLLWDnS/TV7hvc97gZN9ZPsXpep1JRaWa3oW9W13WynCx6uHIxoNpY
xHJ20e4UVAV5GC9fIZTbKyF4q+cXCM3OTrSE7xYuc65ierkQv15YZ1/p6nVfrd7g2qju4KPCqDrF
3cxnhBPc065j6r9y58Umu7sJNTkanU2uRrXNuwx1qZPCXcIBZr/8GPU4/bj9UfkoOsY97fw+ZMVv
ih+wH7h+pZ7l/kOsUBmyJMvbREkS7LIsKW432Ne6Izakasfn1oZGJJdT+56bFzTerarNNh5SZd4p
yXK9w+l1OJyC2+VqlgQvNMfrtJYUEU3xKiu43LLTIbklllEdsox3mmKxqi6820jynlMc1DYHXnhg
HMepx0KS1idRSek2iZaO05tCYp+bSrpvc+PtAZtCdsVGbSP5IAOCf+wodc5zboRMC4H1Z4eG/OD2
4T9WgCH/J6/RWhrhJsf/xhIt71SW4w+G8Wfdwer+66cdmqzR35p7F1Hwcc6dmkbtLk09Pvcutcz6
N7juYGc/pOTC3KlDPH6fAgrm9a87uJiscwhz7x7iNbNUtbbH4S08p465NIxbOD536jDfjjEeRsvo
p82e8sjz7UpJO/fcu0ckjdXwO4mDuVfEnHOvH1ODqAU++IGBJ0geF5AMmOyYw0pOdNxTStaHmUaG
Wjf7zNNP9LCLnzhx/5LLjz05O/3ME/N/Akr/F6fdL9GJmQMvv0qPnH+L3n30P3+If3cB/NE/gfYr
1ORTLpVy1QTIw4bQsUBwi+vP2T8X7nN+1XXSdpI7yb/sEl0hX7CM8YgljjJlCdVtv526xy60qZ9i
B/lB+/XO/dQB6YD9Kfq4/H37S85XlLeYN8TXHD9TfiGpKscxvCCKFMeJNpaB2coFTtdBuVwOxQ4+
m3bYGVmROBftkpQX0YsirdQj0YuQyNCOFx2Uo15mvLLMSCKk7zSnOEALkdSnUupax61yjeQKc+Kt
IQkcyVMh7lpuD3kxYmXIqTG30jV9MNC17t3PW6+HEt8CrkX5hXL2DNkQWlAx8kazpUBD1itlQZdr
r0AUxzzCCWtT/inPtNNfGbRjrtkrg3JNaZCBD74+PC+okMf3JUGqZl5QDFXktnBhKULEgR/IgH9a
XIo9VRd+HsM0Ui7qztn73nu4taKl/shPZr9EfeHtt7pnP6SbqNmPe9uvXHx+Vp75e+rqwdkh7L3m
zV7H/A7kV0btPeKqoFyYikcqgk3eza4nJSbkCAFDtab2TgUfeFlUfQ6/2mhvlBsdS+WljiXO+9z2
JrXJs8Y3qA56BksM1fAYJVPchGPKfbP35pLPOD7vvlu92/M57wHpcfu3lGfcT3t/Lf3K+6+OGeVj
71xFFbgAWQF/Ap4/4PV46lXJCxcuGRxGvV3y2u2SR1Vl2c4xFQEXqlAq6LaK5yroiuN0z1GXJ6SG
vMfpgZC9Rw2p9E3qcyqtHqeuPOaiatDqcgnfUl2aPRTS5Ha5T2auledkWoYaR9pcMFi6Z7pc2w3O
oyygzOBXVkCqeGOrXzl7OoBfgD5T5lfOEAj5cXCTE7FQ/NwOy3gvESh4BidYpB8s8hkkz32A7HMf
UEX26J37+bGuoFTTFXTCJHy0JOi2duUN4netwSRBnp5Gc1mgi+zcsKYg/AJxbc1t3stalq8pdTfY
7LPx777dXFPd/P70bGxFXfvuzZ2zo08oTXXlO1yVbNPMfdnbd0/QO85//8krB/uxnGPMh9Tlth8g
O8qEGn7Ev8/Th/jv8fQ/C9SXhQcFOi38iUBvEnSYbCFTsjNI+DqPv46gimI+BkdtR8spRDPLEb9M
aISMCW+Nkb82ldvLqOAsGaK/meIvIkAQ/qHUTvhH7SQPv728+aUEu79T3XxDy9IlDPvvr/31XZdd
N7/Xd1O/+V3IVzEbyO+H4n+z1m+JYuol6goLppHT9nMLZtCNtpMWzBbVsSG/7XcWzCEnV2XBPHqe
a7FgATXwuy1YRJ93PGLBEvtd0jOG7WjY2WrBMhpx7rNgBzfNfWTBTrTVeS7/E9e3uTZaMIQvrn+y
YBrx6goLZlCb2mHBbFEdG5LVtRbMQf2wBfNoWB2zYAF5PIoFi2i1r86CJTrses2C7WiRz7BgGULg
r1qwg9mivmTBTtTqw9//QLEM0Cb7zhPYBrBSaicwh8tLywnMk/JGAgsE7iKwaMnIhE0ZmbApIxM2
ZWTCbFEdU0YmbMrIhE0ZmbApIxM2ZWTCpoxM2JSRCZsyMmFTRiZsygjDUtF47WQsvQSWi8qdZOyf
IrCCx1I6SmAPwGpplsDeovolGI8F+4rKA6TtXgKXk75MnJVFdaqL4DpS/ysEXkDghwm8kMCHMCwU
0S8U9SUXlcu5sQygKTSOdDSCwigCZw09AZ8BNEbg9SiJEvDJWLU0tBKuUgDjYxjKDVJDg5IYtG8F
aBUpD/8fMbXlKdNQP9yJkd/lNeukoWwtnM3+FqEg/LWjhRbUQUpXQIsYnDdCm1GgIUNabQR8afik
0AQco4SGBNzTUTxPSQr61aBW2OrJrG8AhzRogdtjjAnUQnrBd8Kkp4iFKwwlZss4wYhHMAbUxwlG
A+5kSO0x0hfmesbqIU1GGCFtM+R+gmDBZ0xTktBgWGMZJ7gxRRFCVZr0hu/g+lFyNunPkt400kMx
VQbBn4H7CXI9SXCPWb3rVt0kwWX2nSuPEdwZiyMRuDI5c3G9DODUCVcMOJu4I1ZJlnAay6qgJUki
lxThaIy0x5Ri7YhbrXI9REj7CatXwxopvmdys8CFEaiJsZmlBb4aFneT1kgMUj9LrgpSTRONjRHq
PlkncpaTzo8F34sTfAUcKehnh0Vt2OJ/hOi0Zul9jmdR0vcoKTXbT8Idw5IhrhMD2Zs6koTjKNyb
sLhtYijYcpjIytQOjfAwYo3fIFKLkTrjxM5MbUyQluZIirXbyGuWBvd3WZKJE2qwbppyS1uWHMvT
ESdXBe3NXORv0heNL2L1MUwwZAmnoxfopo52QnmOs1nySzS5EY4Q3daIDuwivE0TvcsQaYzmpY5p
N+0d21JL3prSlpYV/JF5N04kEkY3k/Ym1RhvhNwtaJrZe5Rwa5xYyVR+FLm+cftJcj9MOJGy+sA2
ZHIxQ9rnKM5hHyc6FCc+NEdb6yV+tfsCqWF/N0r0H0u3G222+sv5Wuwrl8FRQ02ACcsgRezBtKP5
RbjWg14Xrv6W6HnKsvs4wb4jL+P/rc835TJqeULd8m8FP2Vi3QTzgYauJe011ED6Ww/HPuh7hGhu
jmNYN9OE22MWtla0AeoNwOxxFXxWwogw3AeluP1VcLyGlK+Gkn44YhvoBS6uhr/1pHQAOci3wUhk
lIZlhxfPoblyk2JTcuOWbAu2cCl/zDkvCTxIEe0YI7Vz48l5/pw+DZO7U1A/m+8zkvehJu+ypG3B
9+mWdWAPVfDXpp8wLN+ctnzHKMGi530v5u2g1Rv2IhOWzx7Oz3pmn5k/wJmcbk3mvaBuWbaet50U
8VMZy2+MWHr/SfzKWTvmmF6EpeAtLu0vaukX1uVh4oFNqoctySQszJ8koUYyqgs5ZXr+S7Xi0p5z
PhR7yzCJaMLQa8zidtryVb+v71ai+4kifz51iSx0K5opthxzlggTisYJZ/G8ZRB7++My1yxdTBT5
0Fy/2PqjhNNG0WyVKoq4WvK1U0V6W4gR/jCnMHVxgj+nV8kL8E0S+e8g0iz2Jjk/XKiZhLqmn8kS
jmP8Y/nxmHQVa3fc8twm/02rGrf0o+DhL9ShPzSign6sJWO/VHK5GA/PbboVCZqjMePKCJFq4iIZ
pC7idwEzHl+SeP6o5VcnSAw2iYqjuD8u/Rw+0yZ1K9a4cEbO4btUjia3CpFxhOC81I5zEgtfxOuR
/xG1BS5f2sOFccWFFOlWtJyBGTKHAc8yK6B0IcJz4zLUibpgPtTguAiuFkK+0QmfdoRzzk1onVWz
nfwqXCf8mXAXWgwf3GopWgK5Cf5g7GMkJhmH/trgb5L8tZK5/UKLjxDP9/vmCQytItY5mdcLcxY0
LG+LadpIPLQ5h26w4qykFcFj+zRn0hS5YxAJ9MOxMG9grcKZFY4T/md0t5H6ceirDY4Z4iGwrNrI
3HMT0RIznmjN1/z/7WGSxABmXf3/pZfcvbaL9DGPe2BqXB8JR3TtCW1gTNfWJxPJDBRpK5Op8WQq
nDGSCW08FmnVVoUz4T9SqQ0j0/qTsSwuSWtrE9BuUTDYvhAOHa3ailhM22iMjmXS2kY9racm9OjK
ZCKjxzGS1JSWDkMjKDdGtKieNkYTLdqKlBGOaRGoFTbgZjyZ0rWxbDycMNIZLTIWToUjGWiQzhiR
tJYZCyc0uDelJUc0A3oZT+lRPaKn08lUWgsnoloY8GcjY5phoTISWiab0LVJIzMGzXUoTUZxawzH
wtAHtA8DMbmyzKSeyBg61I4AkE1NtWqEJckJPRWG4WVSejgTh1u4QSQLQ0zjztLJESCTkDCSjcUA
JLRC9/EkdGIkotl0hgw1nZmK6cWcwMJJ4170VNxIkBqp5A5AGwb6I1noKEEoixrh0SS+PzlmwAjH
9Ng4cCSpjRoTOqlApBzWYsAOLa4D7xJGBKqHx8d1YGMiokMnJrsNzCxN3wWDieuxKQ3GlgYhxzCO
uBEj7M1YepO2+otAi2Fdy6b1qMlNfWcWE5uNYP5rI0kYMmCEQWUyRmIUDz2lg9wz6RYspjSwjOgR
XMbDo+GbjQSg1jORFpNp0DxqpMdj4SncBW6d0CfT4+FxIA2qRIHEjJHGiHH18VQyniTYWnO62m0O
baM+mo2FU92boR3W2o7WZR1a03ojkkpiGc0ntdYPkNPj2kAKZB8Pp3bgEf8hzYexjIIS6qBvRKeg
6qZ+7dpwRmvQBtZrfSMjrYQwPZbWJ8egWuuGvoG1V61duWJgbd8Gre8q7Zq1K1dv6F+trejduHr1
+tUbBhySQxoYA1HkOI3FghHD4GDUGSKFPD1gecnRVHh8bIr0g5Uf82l4SptKZnHLCNZQoC6biBLt
A50AhSJ6DTphgDZD9fBoStex9rZqg9BsLAyqkxzGpgctMxcQg7k1iVVQB2HrWDopPZIB3RgB3hfo
wmJPjuqkClGLfDsQJ2j8cDYDqIHMJFhh0YAa0zmiQPnzrMg3xhqqTYRj2fAwaGU4DVpV3LpV25Qg
ej6VGwWMyRIOmERYS4/rEWPEiFw6cg24mCAaituGo1EDyxg0J0UcVwsuThHeEo9wEVExI27gAUEn
pN5kMrUjbSo20WFSmJwEnckOx4z0GO4HcJnsjoNyA/0gqvEpzVR4i0MXdkT4sXakMDjs8XZm9TTp
BnxlRE8lrBGkLLpJ5fRYMhuLgq5OGPqk6eIuGT6uB5LUwWtEC24xP0YgizjjSKYgYzywsEX1yCej
JSTnG1i+wkIE/YQz3bjCpv4V2kKtaVln13yta9Gyhe2d7e2iuGkdFLYvWtTZCceuxV1a19IlwSVB
hzSWyYx3t7VNTk62xnOCjyTjxTaha6tS4UnMCzBBIAowbUwOg4VuAJ+VBAffgo00ZUSMsNYfJraR
hhlrWcfvwd02lonH2uKZRDiut8XTN4Wxn2jFhf/NBpN6DEr1P94EX7VZfCS1IRhKkjQYByAJEuhC
Ckg5YDLfDtcfklAgd7+fBIs4JMJBS5T5KnOIeZZ5Dj4nmKeZbxThCpPAIHf9HsGtX9CXfgE2go+t
Yhex69he9nI4BqF2mKSIUSscGaMOUg8yiIR4+CFMioRnGAdC/wVnD6RdCmVuZHN0cmVhbQplbmRv
YmoKMjEgMCBvYmoKPDwvRmlsdGVyIC9GbGF0ZURlY29kZQovTGVuZ3RoIDMzMgo+PiBzdHJlYW0K
eJxdks9ugzAMxu88RY7doSIJ0K4SQmppK3HYH43tAWhiukgjRIEeePsFm7XSIgXpZ+ezv+DEZXWs
rBlZ/O57VcPIWmO1h6G/eQXsAldjIyGZNmpcCL+qa1wUB3E9DSN0lW37KM8Ziz9Cdhj9xFZ73V/g
KYrfvAZv7JWtvso6cH1z7gc6sCPjUVEwDW2o9NK416YDFqNsXemQN+O0DprHic/JAZPIgtyoXsPg
GgW+sVeIch5WwfJzWEUEVv/L70h1adV34/F0Ek5zvucF0jOSzIjORCWSKJGSHZKURGciyqWUS05I
2QEp5URHpMMmkORih+4WH9s/V49L7FHEqa7ckgOBJCgnT9Q6JaJgKihIzhNqndIFksUy3Tgl50lG
QZJnkixTzYy6b8TildzNP3Ue/n1i6uZ9GBa+EJzSPB9j4f6IXO9m1bx/AQndq3kKZW5kc3RyZWFt
CmVuZG9iagoyIDAgb2JqCjw8L1R5cGUgL1BhZ2UKL1BhcmVudCAxIDAgUgovUmVzb3VyY2VzIDw8
L1Byb2NTZXRzIFsvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJXQovRXh0R1N0YXRl
IDw8L0cwIDExIDAgUgo+PgovRm9udCA8PC9GMCAxNCAwIFIKL0YxIDEyIDAgUgovRjIgMyAwIFIK
Pj4KPj4KL01lZGlhQm94IFswIDAgNTk1IDg0MV0KL0NvbnRlbnRzIDQgMCBSCj4+CmVuZG9iagox
IDAgb2JqCjw8L1R5cGUgL1BhZ2VzCi9Db3VudCAyCi9LaWRzIFsxMCAwIFIgMiAwIFJdCj4+CmVu
ZG9iago0IDAgb2JqCjw8L0ZpbHRlciAvRmxhdGVEZWNvZGUKL0xlbmd0aCA3NDMyCj4+IHN0cmVh
bQp4nK1d3c4kuW2936eYF3BZEvULBAFsw+trBwvkAYLEgAEHiPP+QHhUXV2lwxZ7LoLB7s5+wyEp
iaL4X/FH0F+/i/qvnuOP//jHL/j/MvL833/+5y///uO/f/mfxw/D0Vutjz85Wu5xYnn/9ndvMMUX
f+DXv/3lx/mbf/7tl9//Jfz42/8qzhhT/tEU7fyNovwvRTdSrD/W/+hf/vhzxQW6wJBS7m8MIvJj
/c+Jwf78IwbLsYX5q/7ab8v75zIO6SH//29Xei12YsLq5i+FbvVHCl1+xJF+xBPoj7/98vtf9a+X
H79hca8DB7KY8MN//PIvIcif//XHb39//nE/Ym3lCVMSwUg9Shh9gRGCyfnoJcUnTO4EU+SII8uC
pzCM8tPHwk/OBFOVH4ltwdMIpoWjDmyOw08bR8hxpcV4etOjlWXtgdc+4lFKXNaVeV1jHH1IXXj+
0wqTgtIiGKaVotKq0WM5xXGMICs7TCrJkaSsR1oJRlR0GYZpSf5OS7qlFQkm65G2vq6L+Sn5CARj
+FHxSbn4W1jTkaO4oppUfFop2eUZ4jOaK4ap6z7XEt396br2b3iG8vMNz8iGH16XBF27jOGduwSV
H4LJYcL8+beNlpEUjhha9vZdUj5Sy8O72iLpqLElT0WINIVJ4q4zl2OU7MqBFOU5+SpLxfbINa9y
EAhGZWUUUlnMs8qKhNhdWqpqiBRfbRm6rF7Fg8khH6Iy5ZHKUbe5heHiSfEIUZK3hTkV1daheWKZ
9YUphIevUtYXppdSXFpZ+UlpeNck67HHEdY9/CPB6CtUJLnXJNeoL7XPjj5CQdfvaazclBTDMKmu
pHrunsRn1RC9DX/p+gjpGWb3KFRDCOHJg2H0uL7gKSEafnjtajBYWnTbS2xHSyl561KbQvdnuOJc
9KVKEhdaMZLGGqvCilih3oAXdPb1Wwz6I33ELnB+3UM/JE+VJFsGjGFWnuDWMBuXYXbDsGEGg1IW
EL5ZMSuaNhWq7LYvlqY3dCx4vil8Ze2ovT3/ijGLmp5cySt7vIKuOnjUvsDw5nZc6nm6e1pdpQ2m
+BMP6ekUvvOT4nd+VMYMP8Z+SFAyOXk8p6TSH+Kyh2JsMMDUhefEMFlvrIy44DF2kaVl7L1ajkQw
1nbSfa4rLb7VqSmtGLO7hz2ZdZk9nBqtd5cffRDVRRQPjwQ9izIfxK1sSFRtXmRZu3nD1X6RUV1S
ar406Ss7/IbjHeuh+jDjyOdbt6eFIz1Nwj0efaReZtl2C2G+vMyyG8+fGEaOSnhY04g+ZCMPV3xE
H7IYSRuxCaiPVC6rNjJ49JGqyZXmHJQUgfCTqZddjebscZOjUpK64jFWUD1GWzfwVzZwwiExuvKe
1U+qRbp3oFn9pDFq9DYnl6gvhywCxi9HVh+oK0OeXoH1UhkPw3TA9PWVYn6GwjQRl+fRjp6Dq3dL
AM/FvRRF3ePYevIko+BIGYb4KaqbQwruW1GkqC5M3bsUJYvqufWSGn70vBLBmHWVcVll2z0sVWnF
3D1xLi2pnms+P+qrFIIxtPTcW8rVxaP6OzEM4xlKq1b3TFXxHCOMVWkQrapvcmaYPzFMP1pe3ze2
fmtKlhbj0eueGA/zLPkoPXtXuWYllap7LWpWMRykEpgddWMz4WExrOrGtro+gYaWqoRBt51uoN5i
gybxDnagiemDZtnZ4rECOr1t8fLNcMa+lredTQyoq3nZ4jcM7RkM59qnaO7x6BusnI8FxkQr22UO
3TDf7P7pSrQ3OEnyw5VoP41yuhJvcMeVuGG2rkTbCdHDlWg7uX+4EjfMT7sSbSebD1fiZm/vStww
e1diT+t2JW48e1diy8/Dldjy83Altlv6cCW2PD9cifuE965Eo4v5yZW48exdiXtde1diz/PtStxr
37sS+z28XYn9Ht6uxJ6f25XYrgvh00Ywxi5XEySc7sb2KklU+z6E5dzZOhWce+3Z41lw7mdo/cZD
ekzUTEkEY+x7NT2ZlrHLYXrGUF1+1JR5hej36yrlCtHftChGJ2rKlN7ceyGqE4YeiMtPq1dI/JZn
duvUJ2E8/Kip26d4UvfuDhyOkYp4/GTIBuHhdydDNqQse8jvV8a5tyYuHoGvNZZ95vcrZ/W1qq8P
c4avtepD1gkZOmGsW8geEFxRyQvLxptogBnukWZV8xJq9URDb/pRc1+vF4eB9Ugjw3DsMcBrq9mj
VQK8tvX5Ml5AVDMuRE+zlKQG4wpioq566F3EfXQKDr2RQjA+iZKK6yX9Ei09LbT6ttDYnqMXvenp
yDsSm0iR6H2D4f0EYRYRp86wNGSbnoiqiutMFMs2Rq/aSp/pupAyyeT5BI+FlkkmRzxVCAI4tN7P
9IPWrwyj/BAeY0FBXQef5SyvfPODZTYjoYkZhpcFTRzxKjrLKihtqOv2sOVVEcbvxTvRCE3cQneX
3vMrMevwo1e7zOjZDcNqJCKF0ZG8fQghWyhBtWxc2DGGTrSkrOGVUN6xrGowCN7NUrwdTDj00hY8
xs5RCz2VNFx2oM9TyN6pTxtvvq0Pnkk5pnK9ifvTmjZeS+4FhI13ppsfePgkWn2lmx1aarernZfc
/RmIYzZX4pEi1zdvPS+TRr/e1v2ZSkCs08cjoRh+eO3qJ1tabHel+HrH9+uShP1p0dtDEXm94/vz
Qmq9jVVhGnsyK63hK1UpSkuGqwwFMtZic/ew4rHP7kMgFY99LS4/kLG+ajqzh133uVRx91B9wzxI
0/GZDoRou3svckCItnosZ1VQZVZ47ZVqVruil1VD2TS+WgTDVxszOl1JbfyBzcBo8Bies/IsJXnb
A1MxEIzNrSMimqonGrnm77QQ7fwK84FnY0/qPreWPdGAPZniaN5ZlKA8V3fpMCdbWs0aTkRNc7Kt
jxfXkk17kmAMraS0ZLjap6hGCD260lxUNBIZdIwGkjHIHDEx7oZqTfdWFPUi1GodnmJRg++ooWdP
ehAHH5nMrMEw7YiEx2yzmixfaan0MC1jk0N6uqyKjm6gXlBV4MU9igrxoROl7an65sTk2yM1BfUL
V3vEsKPS02NY3hxyI2BDWcdADbPPBpeadmcw7AbhvdT3O/Zpl7xBODYX1ceucUr+jYYtTTXWQ50W
4o3HVL2qEyKI8T1gGI++hT30ZVXWys5wfBd+ys84UKNvbFdUA8k0vN4gbMANdWpOu/QNYmKh6tzG
Ou2uG4b3IKB2a9pdNwzvN+rEwrRhbnbMfqsXkceyKmPZq32imi0utP7A+50NHhaRmBFOTgse44jB
O4q5+jBvJ3TPc8H+rHjMPiOWNaunnf2Z8W3imdc+49t52Wcjj/COpPrrGkprxl0fMBx3VdlIM+66
X1eCfTvjrntaKVzx5AcetrdRekEw1s0KhpaJOacrvu3QEsuzLUVG0V5fz8uUIl/x5P0VTPCcR4zu
HqoR8/Kut3dQfazLu97z3OPlXW/vRYJ3PUu1nT1U2RgEY8tpwit+uz8vtdkvT37LjwQ9L8JjbHLV
5YPwGHsb8VKCsXFyuVz5razK9NO/8Cx27YYf+Yl1Zbsuw3OurzqhvWzoi/KqE3rwzP4adJQeqkur
qoyd8YeblvGh1AGYUcy9/kGZc84pe7oFZc6t5+aexYivOiHnLKYvP5q7dtQJER7WCbNQ6AstOGNM
65MzNmPgexU+fTHJ7lFMX2xWiu+3J8OVJzwsGvDXRqOngPkpiG+vauyTv9YJ5pO/dpal759u+GKM
x2wz4v+Fnh32Z7vl2ZR4I/5fo3u98lB+Zpn8w9AinuGv5Vlttd9nNY/UGuvZhUEIZ5bJ78+iqIlU
+CqzZyPpVSa/V89l+unrVQ5MS82oUKP7nKIqqRCMcfxKgbPqolHrh1fFHKti0X9W6WGXVyVDfb91
l9lf61jVCmNo6ann0JtLazQ8lO6tgC82CCZy0Y0qjUDrMv5aRB+Wf7tUgSk/6+1KpiYJeyiuMlTf
EfVPrkFbE3rHaH+4cEnQh7UaLXwDUdyUY3clFYVLra63wvCjD9xIPXm3AsVNifDwo1NrVT/dtX1q
Uz+NQNp3Nw1JhM8Iu9ocy5/T+mGHz0KfG4TtzDFetUB7kJnjYhh2C5DjmuVOe27Vy3uVRDkw+jYx
Hpay6TZPV2a/8qjSUacr88DDbgrMn1l+dcNY9+tyiRye9f1iWmwCxFosHpPAkpdr5ZwFzHCG+SPD
oC+mL+syLuPs08kLCHsF70qUPcvpXYnyYMd4X/nlpey3MKEFh2CMxzhbcGTl+UOz6Fn14vAD65nx
8NohGmquumuHZQwrai896BU904QPNPRSzgTWiuZjjdLULc4OIn9FMIYd5BZSW1fFbQrIO83ndL87
gqr22RewFzCJlh/j5yXU/Kfi8Tzrj5p35iKo0mnFuxKCzGYb7i7LrEIhtcJVVcgozQ5Kh2M1VdXx
WmhxvaQgsznGsjvReEO6OzkudyuabgeYxeKqsNkRMU3evRDOjBLhMemHUA71YJMLE69i/QcMrR1d
n5FgjEuQusVDkprlKtbfrz0jtxDWu25TSrquvN5168bounr3LgX6HYLQBfxUoTQtZ4flhkxZSZ7I
55ZfDaZ7kc89nQ2mzmmhfD42V2fkobszm0f3j9Jsm2AYdixCNbRs0ydaEOiWmvYLdRaHf0sLyucl
uy8FGjpziK70FJTY1/WW8s0puRg8Zl0ZWbCVH7M/JcG1GD6MnsUYrvaZbRyEh7XPbOPg/TEtGvH7
Hja7duOYoo0j5/W8TIuGrr1Xf11IXxXSUMZlUloMw26DOtNh+Fps5qaEtA/TSkgl+pquSrF42K0S
lY3mijNaNGKU9epwqkxFI5dSvS2sKhp1NeM571NV+TAazqHVpmhiX3eQdHPFqfcv7CBpWcS1+SpO
fZABRdvTkLSU1UbIP+NWye5+IA0ymxluED5+DFJgEHa+UIQ4lZnslhfD25OR3UVEsrETjE1+vb0U
2W13RG9pjQs/JpGIQQppLHg+jerpLVaXFhpQZ8LFWde7EeCxLvZk1NzqPfr8wJRKsvBjknooDZxl
EQ7PeuqMJ/E+owBsJkoewsPFeOHtpmxppfB2U2SnGDCqpxEe63693RQh0X+4VpebsicFG7sEV+DP
+kGCYT8Fea1Ze74XsZTfvsyen3LVsO+PHbmvs4bd2Z561dntxTC1q4buwQ/34sycQ174+dYwNTVM
ewvSH3bqo+0WeKuPLchDfbxhTE43vgMhNwwHQuI7ENL2Kia/emluGKtirtzwg2fmR4bBY/Pr6dX/
4/AMD30WQ3swV1G1w3O5iqofeLi7rUZLi/cHvUatFhdm9hr19UyNGqoInLss31qo7a7iLFCe6doH
Kb4e4UpH7mnNAM9MEe5pYRrYmSJ80DItZtcogQeMCd7AkU8rLU5552uUwP5aoPz4TMk9YDgtDodu
Tnjai+EsUT6v/Z5nOPuMh/cHEZ45KcrBA2c/JfdazDJmxsOvD1LwBGNb1dKrBNc59/EOdGyv10zT
Ex6bgr9Kgh88m/S67iHDmDR9MbRMoANySDyb0BU6XMKqokxKF3LYsnsvBF0wZ3DmpmUCSnoWZ1Bl
ey9UfR/9DKps5WcGlCrddz6L+mrucY6iXs09ztJRzrqi4Ug2EvDfKCH0QJRMJA3599lGtH+7BK37
s41ofxAZAtaLuzlZTalAeEz4JpZXgfKen5wwamFVUCZyJVdhscMzxjo02kMTlcKohZS9PcyIGZS8
vpMcKkJ9+3CfwFnnXPN6XCYqhakF61NqtrC/inSd3ekYkDC8m46s+YjrQ/pplscsiX2s28SkXuMR
9m8J8urneIT9MSCvnuY8gv0xIK9eY3BFGUXOL2d3q5dVbV/O7nYDi75bjWBsCEhp1eTusjpDR5Tg
6sqCYEBLruyUps53Du67XlpXndvcdx0VzGquDfcsRjlUOpJLS1VGLb68I0zUU4ueysBEkEh47LSP
YPkxU0P0LL7wjIkgTMtmzeshxLMpqRY9izpclVFVrajv4tNCvGnWGTk8q4smedUHJtSGeFN3vYpa
u1rWUVx2VPWoObuqHhNLCkdZX2x+aauqnt5lve08fUT1SkqlepLR1OoppbsPYIOEDbKaf6IgO38v
yH6A0PUYAJkp3btexDiM8dUY+0DDmWFY/KfjuS9KRrZ/zul44OEsPRxGWfHYWFJ6FVLnba1MxCxW
omWz/eo0zZkgDxguIn8XUjvrqh/4YTzNrt14XyjMIH6Mk4sjLSstW0j9robY4xlXUfuDZ+PpIYY4
FtngFwrDRM6BGvv9man803nfF2THa3jHnmek+18OtVNs3S/HfFsnlCQZWiYw0/mapXADr0M5UQS0
QPe5L7LZDnTmoA3kAcLBcjVmStEn9AFiGinG0TqB8BmH1zDdB4yJpwbMzllh7L1NlpaJNw80wq4w
LN/6GpW4wphqFkHiZ4WxDRntEAy58fjRF6szzIdgENP6NBp+tC/ruroCn+syzRblHA3v8aPPWo5j
PS8+U7WcBsHYoUTd0LJDicrRavTPAjb1+MKzWldz4q7DM0qCpPk8o2nD0DIRI5RsEs8fGjJy+QaD
RpxYvXWhbKjU0d11oUyAYGzje7C0GA8C4ITHNOvDuiI8tm4ooMdukXlOUs3yI92RZV0fZtUHvA2O
+plN9nmFsU0k6oijHtO5X4hO9fAFBvWzUld+ONg+Z5Q3X8ZQuFBon00jvt7BPly9imInac3Vq2gi
6QzzoYnkKy28nYyHgyL6LqrnscCYhn58TiN84Ufi0eJwdS+GNgn6Kp3z0uf3rND2eM76fg2CMQOZ
5GwM8vanwPv9huf13QkPDxpNxpd1qWcbEtHifUY9OMHY0iq1z4T4+dCMIpVgTEO/vnEEY9aOmvFW
1ntqSrTyOQvU4QcDooYQDAfMVFa7Glc+zGtwmqNXM77HQDB2wH8ztMx0eoGHnMRd+/xCDsFwwEzt
hBn19/gpyK5kf3/wmRnCY+vBwllZ/cTDAcXaVK8SHjM9ALXwK8xP2LjY9RfwOuzys40bx2Y7bhv3
DcKdAepYz8T5A4SFF4Xo6E12CCG4k5s8QUxrdleNtWKxVnD+Sgktx0zKpOHUw51e5xOGLa85yZVg
TM07xvB9gVFNzHiMB4AyobGuy3wAaNazE4yxlDtyfsthWUsZuY0V5tPQpvn1GufQ0ZYs9cseqiYu
Y4WxVnCe86qeLBuHO2IK0AJiKudRsOWDoN+PQNiCUYuhIqjlyA5akvsgGDP5SV9Wfca9daO6Q2Ws
egvH6E4pqbh40iuX58hgUm8tE4wtnK+G1sfW5r7CmEiDatgeCYatdsS5w7o/djwUvr32ZQ+R28gr
LTO2tKk3EmVZuxnm1dUDD3E5CzPNawRDy1quWV+yLN49nlZpJxjTIo0cN8GYvGrRV4pgzOgnjDLO
6x01Zfqw/rOrw5APDQRjrUk5Ry05+3OOAK3eUcBQZDQcC0U6dJzG0p7lFi+Das9OK6hMdbUGavAL
wxgjEJNMVhibEcXnflYY+1WCcY6CdK4Xuo177+7VgYGnr/oCY79dgAK04IozavlfRs52XfPrTC25
4oyMaA9pFTEzHur15SWPn9wNHjMCtMCQlujJGAr1e43iXXcYZoZnk+/U/SEYO24UgaAcPflBUjT6
GhxfVSIFbic/JXWbiyuFqMHPvXTvtIo+TC1+gdGHaWSCMTX4rxoAD48aPjl8waOSUaW4DwHGQ6Xc
3Me0qGbJrbkP3KydDyuM4Qefa5Pm3hwkTpUn1wgtKj2tEQy3EqO7B7lwbw/VvRTprvggcdrFx4Ok
aKiEhxOMqlnS6OJplpkUjcG9FbPdmC6XyZsWeN+raHAOEqP6q7giVgWTw1YYzvqcn0BIrnJGJ3GQ
vCpe8ymFerbXeVtYYSOk7tJCaWvNqz3C+eCGyFVdxNAU/KtVnBgPw+CTgFJWG4r4mUX4oa7q51ff
8ZyX8f7oBJ0cPmspTwBTIIsBYgsAPRiQ6Dy92/13ySDRbYXhkroY5fxwqIcnBUzpWvGwezbFdbo6
+4+MpbM+5knKeIIR7Q4LGtshXWYljkdJ9WqvoS8cswOHFvszZbI9JtTYtjNlsv0kTJyzXlcY6yzC
eJ7v157neTHqIhVmaHOL57wjR3KQVqlxhbGTgtUiyYTH+Iswnqt/org8Zd1mk52VA1XBDsdIzubo
HhZysyGN7jGD3OxsKXUOFP0Cs7/DOVDkXWNYYYwXjHjcGV/ew+CbvHWFMV7erHgiPKbQP17xXOe7
cmgTEvHuFhoGSvpCSx9u9Rp8Wipgr5jvfu0qYPrqrDDmwxMDr0V2z2K0Kza6/XbRrMIlGBNfDvMl
SN7+oPH7Ky01DpnWp8bv3leYT43feeTo8gwDMrjijO9OiJThsqP2Y6nF1Zdyfppm1YVm3jB6OIur
vjFPaxRaFvfg13K0Lv5RYCZxi9ndnpbOkZ/eutTDxYx75x2VORr7CzuYrEnsfBq5pa9r9WHgNjRX
iyETUgiPcTqRCelE68MnimfVkAsDt4FgPsw/zm24GgEzt8KI7g3EzK0WZBUNM3MLrsUKY51guBZk
RXBGpcC1yO61yGWc1WIeLVRMxeqaCLnCECMYM5cLn7Ukfsx8r4E4ZndpoY50EIxpe8dIuxXGZJzU
m56txA+Yn8m6qEX6Al7L/T5nXUrcbOuddXmD7CuL3iD7yqIbZF9Z9IZxKou2DD8qi25aps2sWFof
cyoEY1rIoNaGu4FnTmXFY/hBToXw2Fa0eOWBbn5MZaEeRZhm6R7PbN2fVUw3HjPGF/dtxfOxQhHN
197+zCaOL/wgeEX8mP1Bu9q3M+3BnKntrM1XRdn+3PVteFWU3TCmiqlfVV5bfmZ+Rkh+TBVTR+27
yzP63gwt82m1flWU3TCm761eFWV7Wkn1YyTZMNa0Oqqne7TdQ3yaQ63T7N3lWVn0FaYZPNZSRo/8
ui6zP2pNyyAYPi98GriH7u5ha1eubL+H+LRCIlofxtMGwmOqs1B9lL6c13iNxvD2EJ/4IBibw8lX
Xu7GY3JBan+clWA3DDdtqV5tBPPJ4g5JfFqpXfm97doxntbw/GE8bSYYrkSfn6g+K8q2ekwQcyM8
hp+SDZ5P/XMSiBbvT52ty8tb8Mmcjmdl2vYOojvuVeW1fS8E/bskhuYL1bqF0jxu8IGPOSDakXg0
x40VDbtr+EI1UbIVQ7Nb3bvGOaEpoiQfRo6cSQRNwZCaeARjTWkxtGzBUMNEIvGuxMwnxRXmU4fd
Kz26x1Pe6dGtKGcVr1GTe20ypukQjB0ONa40620YmpzTnA69iLLJbyFocAZDtgZmCcXQsh+6jmbt
PKS0zNGQrkbF97LbWG8NVxmVhLmqw9XeGPz0igPtaaFbj5bON7TkYI7CJIvwEYBBR8pLn7NFCYaT
M/Vd27anVd+1bdvrhe+N6Gvqrx3OPuMx3y3BQKIVj1nX/MBecK3Z0sdVa7e9Ohjq1PMKw1e54kNG
Z2Rh+wIiMVUJxmR5IubpRve8ZieeRPHWdc64leTtIT5cUhmP6dYrV4p5zw+69UZ0PYKK3oczarDn
5/o2jnOVkZn6SgtVX0TLnFdFFiy5KrNiuFhdYbh7vqoczu5K5+5U9D6k5J8FJnXH4Fo+Ff0RMlwL
qp0fM1llrDFMOwe0PffwZ7Jg+rp+vvlXFuwNYCIFuEEzUnDj4DBAPr/l9AThykpUiC0A7FMGfBZn
dn5s6aBz8NX1csOYOcGoUlhhbKJMT6MNb9WzAWmEdU3mU5jjyCsam0tLV4XizQ1793oH46ji4pkf
Upge3I3HJNNUHxKeT8No5Ewj3nj4JBAB+MYPepSIn489Sqf3uodBMq2u2/ypOnMwHvNR9HR5wXvJ
wHBaWWFsMk0uL/jeH5NNC5f3uqWF2VolEAx7cMinMYzx7t+e4M3Pp4/GfIORbPDY4Vrx8oa2Nyfl
tyd4w5ipNunyKN8wd2Tzr/rr/wDYn9KnCmVuZHN0cmVhbQplbmRvYmoKMyAwIG9iago8PC9UeXBl
IC9Gb250Ci9TdWJ0eXBlIC9UeXBlMAovQmFzZUZvbnQgL0FyaWFsTVQKL0VuY29kaW5nIC9JZGVu
dGl0eS1ICi9EZXNjZW5kYW50Rm9udHMgWzUgMCBSXQovVG9Vbmljb2RlIDYgMCBSCj4+CmVuZG9i
ago1IDAgb2JqCjw8L1R5cGUgL0ZvbnQKL0ZvbnREZXNjcmlwdG9yIDcgMCBSCi9CYXNlRm9udCAv
QXJpYWxNVAovU3VidHlwZSAvQ0lERm9udFR5cGUyCi9DSURUb0dJRE1hcCAvSWRlbnRpdHkKL0NJ
RFN5c3RlbUluZm8gPDwvUmVnaXN0cnkgKEFkb2JlKQovT3JkZXJpbmcgKElkZW50aXR5KQovU3Vw
cGxlbWVudCAwCj4+Ci9XIFswIFs3NTBdIDEgMzUgMjc3LjgzMiAzNiBbNjY2Ljk5MjIgMCA3MjIu
MTY4XSA0NCBbMjc3LjgzMl0gNTAgWzc3Ny44MzIgNjY2Ljk5MjIgMCAwIDY2Ni45OTIyIDYxMC44
Mzk4XSA2MiA2NCAyNzcuODMyIDY4IDY5IDU1Ni4xNTIzIDcwIFs1MDAgNTU2LjE1MjMgNTU2LjE1
MjMgMjc3LjgzMiA1NTYuMTUyMyA1NTYuMTUyMyAyMjIuMTY4IDAgMCAyMjIuMTY4IDgzMy4wMDc4
XSA4MSA4NCA1NTYuMTUyMyA4NSBbMzMzLjAwNzggNTAwIDI3Ny44MzIgNTU2LjE1MjMgNTAwIDcy
Mi4xNjggMCA1MDBdXQo+PgplbmRvYmoKNyAwIG9iago8PC9UeXBlIC9Gb250RGVzY3JpcHRvcgov
Rm9udEZpbGUyIDggMCBSCi9Gb250TmFtZSAvQXJpYWxNVAovRmxhZ3MgNAovQXNjZW50IDkwNS4y
NzM0Ci9EZXNjZW50IC0yMTEuOTE0MQovU3RlbVYgODcuODkwNgovQ2FwSGVpZ2h0IDcxNS44MjAz
Ci9JdGFsaWNBbmdsZSAwCi9Gb250QkJveCBbLTY2NC41NTA4IC0zMjQuNzA3IDIwMjguMzIwMyAx
MDM3LjEwOTRdCj4+CmVuZG9iago4IDAgb2JqCjw8L0xlbmd0aDEgMzgyNDgKL0ZpbHRlciAvRmxh
dGVEZWNvZGUKL0xlbmd0aCAxOTM2Nwo+PiBzdHJlYW0KeJzsvXlc1NX6OP6c8z7v2XeGGZaBebPM
gAwKAi4oyaigFrlvYJIgouAGAm6lidfccMnqamqLS1aalqOioVnaXpZpi3VNUysrW0zrmvcWwnyf
854B0br3frbfP7+XDM/7ec45z9me7TxnhlEgAKCFWhAgtbKqtPKH56Z9CZASBqBpmlo8pfQVMiEL
4J58gEj9lOJZler3dQ8DEGwHaXJFSTHsm/8TgLcfgHVL2ZSaWUc2V3uxvSuWN5aVlRZbppifRd4r
CPFYHHck8+oqpA8idJ4wefb4kpo+swGG/Qjgmji+csKUmQnbfgVoVwYg+kpm1EhrKj+cAdAN51Ok
lkwprpxQ3/8BgNC/AYSsBL52+sGP9y46v26MMetXVaQK+M/mrxKSON572+63f9/ZNMHUTXUnFtXI
T2QGfCp7NA+A3ib4fWdzuqlbsL71R0zkNWIiPrKhBESgYIIU6AXAdJomlBVVBLvQzFbw0U/hblYN
oQi3K6NgpjgC8sliGEWfhTkchCjwsh1QhbzPYrkn4gO8L/IPRziLkIUwAiEiWNcfoRhhKC8j737e
F8eo5OPIuBpGqZxQIY7wN+F8a8S3YDzCE0hvZl/BVkUmTMHyFux3iAF04TzYZ43iWViL9Y9hewnW
PYE4H8ubkB6N/VKDtFq5AsI5RlBgfTscZ1lwvwnCK9CZVfu/wL0U4Jh3ICzCOQYh7oOQhzwhiHsh
LCZvwRLyln8ztiOGBTj/Yl6PkBPE/XCchdiejf3isbwA6QhchwKxESEGIZHugExqhYOIU3D/IwP7
RngLyvieW/eE6w+u6Y8QWGNeW8A5X0KIo5n+rxGr26ztZlhwE9wupEMt4kkIkQiD6VGYwu4EgvJa
J34NAge0TC6nMwi3sXEwAMsE1zlUrIf1vIzQX4ZqfxN7DDYKV6Artt2jWIP7GIfy7ohwFVLoj9Be
4YJ5aF85OP58hCdwzAuyPYyDYTh/B8Tp7GvZhhYhLMe5LrXIicsGy/NRr0NwrmvcY7D/UIS+qJda
hMl8PTh/Cpc51zsZ0ZyJvOeRZzQHrLfLgHvnNsn78P44litoh5uvY9iMPCtQrucQM4RQvoYWkO0s
CNj2Jo4TjqBAiELogPA1wmaESQjdEF5ASMS5AecVZHtFm+G2KdsH2ob4FsoQ1ybbbGAPT8j6DPjM
puBYfJ4YxQ6YFIQYPib3F26zuJZdLWNzn+I204Jl+57E7Z78zPfJbaoVo++xH6AvX4Psg2hbLZj7
Ha6Z+8MaOhyWIF6PdryA2yxfXwvmcuG2JssEfSKIs9rsNVX2EcQCQFzQ1he04BZZtOIy2IJjFinG
YkzZCP1YDfQTHoSx7DLkCO2gg5iKdbgf5PXRH2CI6jCkoy4HYnndTXgtB+UJMlE8jPvcjvI8AY+j
TKexEzSWnSCiuN3/nQjkHXE7vU+m/4BvBnI40MYxh7Zt/936/wnQT8TtGDO3+78XT/j9uJ+HuE8o
fyCpCFILxvrdCLUISSoPWauaRBqUw8GkwLMNoYJ5oZvohS7sMOonFOM8+gLWDxe/gEPCCljKTvhP
klqopSdgkTIUiukajGk4F/0EFnDg4yOubGNHN9jczbbUglvs9WbMY37QppyIFeh/7wfhfBCuIvyK
dvQkCczRhcdn+XzAGI2wKGCv/t9b7fMdeArxshb7vMlOJ91kn7qb7fJmLJ8tGN9b/BTXsbRl/zw+
8hjHYySPczzOtPDfjNv0r6PPoh3zOHwURgX9OjYId+Aavwz6PsZh1PdIv1/Rx/+Mot6/VbD4tyrS
kP4bguh/Bvc9q/VMzfc3B8/Tdi1naaAetC3nqJgOU4LxbIscb36Bv8rn6Ah5fWrFTpgnNqLeMQbK
690Y9EGUJ657EitCma+H5biPcGEx+iPWI4zmMpF1ARDGzwV+JgqrUc78LFoBC4RTmC/wvulgls+L
bBiJa39HrsMzlWNeJ46EzYofII0Nx1h7GMZxXfF98PVw3aumg14VinHiBHRk25AnFDTIt1GWgRee
ke2C952EeRHKQlkCSrTZAcjDx9sk9/GCJSiPLbIs5P6Yi3D74rLAMRWhMETOJ36ADeJwGIk+tElZ
C5sUw9HnQmErjvEU9hvO14L9IuTzejXchf61BGPTEow5INv/KH+jsB33MwvjOoJQizLaDmFiLcpw
krz3HBaIsYu5/wjPgpvbiGI1xmGeT6yGOuaBXMUkWIF1K0SMkzjvMqy7H/03FX13KfZ3BuM24NxL
sZ73zea5DM8RuL8ovRCiqJXzAJDXwPMUnF/4DjYJd8AStOOeqtUoh4XQHs8LgrYXjdAxAHL5viAs
D4BcZwpgEiOYYK5cnw4f0mcFLdotP0P3s/lQzkZAmtARwpkZ2rMP0Fd/g0cFI4xhR+BR1gDLeZmF
QKLgw/3XY27J64/BIF5PP8TyWhjFsrD/EpjKxkC1sAtt72PQsPGoa+wnrkQ7icf+v+C4QSBfwShh
BPrWIqR/8+/gfPIc9f6RHFg/aC/3awPyWlvgpjXTPJTbHahTXC+nb1gvrrV1nS1r/JP1yfvk42I/
zsMeBbyz+E8juAK4eTBdAdsRNtLPoLfQH2aTrRhgHoM+5GuEx4LwHPST8S6EwXjGdyJzEDqwTvAC
wnykkxG/jLAzUMbcrROcQliIY7+CeA+/F3CgvaAzx1j3BMJahHdb2toCn+vP6tuCGAk3lvdCLQdy
xd/E4WZ+lHNnnK8zuw3liYC2uIqDYh6MUs5A/SVgfTSOeVMZ50lje2Hif1rPfwJyDFJlGQbA23aP
LfpAbPsvwOk2WOI4eDb8r9b3PwHU7zyEQlm+P0Fo0IYM5BOIRTwC8QhhOszigOX2WC5okSfB268M
W+Fhub5Vf4F6tBW8UsJtN9ffXL5Zr/+pTPfAU22hxQ5a7eEhuJ8Dy0Z+hJvLqnfgfg6KN7DtjT+W
2TP/AUZBkrBeXhPINnZTWTEQz0wEGo9rjZD7LOfQWj6GvozAeeX+eljBQfZdBFoP5Rxa2zth/EZo
I9fOXK44p9zeop8WvdysH1yfl72PMArPivchFfFQxD1bcKt9B+PFDTY/OGDvrWUeS76+iee6T1z3
jWP8rPnzMf//BOg7RxDeQnjz/+u5eJThMcLE48RpzEOyMY88gfnJXbAAoAljybUUhKcxDg1D/CnW
4end3A5Bj7QZ6yYgfhyg8Vekq7D+RAD8lEXCxmBeGY51+4J9VcHxhgb6N74N8Dta1O87A/0bn0WY
iPTPCHOR/hzxK4jXIv/32O9+xK8G2pvGYHkGwkEs/4DlyQj5SK9CHIo4GSEEwYL913Dg+cgf7qH/
5/jP7x//VYw5Swmu08nf80I85+Y7xH8Zt+jzP+Cb7xot+v9PuM17BjfhgBzwzvQl5n2+tneff3fH
acGoz+a2wIb7mzCn1PE8mueyPH+W88cglu9vch6L8wJYWzDPnXn+ynNnnr8i3oR4iUKU1zOc3/P5
ukA+UmRwyA4B6iFYQkqTD0zdmb9Hy98Gha5wH5lHHiAPkU3ER04TPy2gb9F36OcCEQRBLcQJ9wl1
wnJhk/A+07GBbDQbwx5mj7DH2ZNsD3uRnWTfifvF18TvxSsKnSJS4VR0UwxRTFJMUUxT3KdYpFir
2KLYptipeE9xQvFb9MLo3ySjFCpFS7GSW+ogpUrpUjcpS+oh5UgV0jxpi/SMtCNGjAmJscXExrhj
OsQMi7k7ZnXM1lgaq4g1xlpiQ2MjYp2x7WI9sf1ii2NL42icKS7GBS7q0rlMLqsrzOVwxbuSXRmu
LNdkV63rftcS13LXw65Nrh2u3a4DroOu113vuo65Trq+cWe5ve5e7iJ3iXu8e9IF8ULYhW6X6eWO
jbRRauzcmNXYo7FnY07jwMaCxrmNyxpXN/qvjW3Kbvql+Zr/mt/P3wGHjbLkNpKd5Cj5HSX3Jkru
bwK0Su5+lNxK4UlGmIENZnezVWwNW882s+dZA/sbuyD6xBfF4+LloORiFF5F0Z9K7nJ0bfRGSSeF
SHZJQskloeTSpMyg5Cai5J5EyT17g+SGxtwVs6pVcmaUXHhsdFByRbHjZMlJ/0Jyg1olt8q10fVs
q+SOoOT+hpLr1iq5UvfEC0SWHLnMGglKLqmxK0rO29i7sU/jiMZ7GusaVzZeu3Z3Uw+UXC2XnP8r
NMzVfis9Ql8SUvyn6XvoEUa0yIfITDKJVF3biOVybrPNnuak5nbNiUjOgXtgBkyGMrgTelz7/Nrp
a8evvXvt3LUPrx3jnNfWXVt7bce1Tfh6+Nq8a/df+8u18mvpAF8VAnx5OvCu/rmFCKu/uOvc/ed+
+2LruZlYegEB4+q5unNzv5h+duLZ2ecOfJV8buXZrWfXnFlzZvOZZQBnnuZ9z9rPTDuDkflM6hnv
mfQz8af7nM49nXU683Tn0+mnU0+3Ox17OvK09TQ59dOpH05dOPX1qS95r1Nvnjp06uVTOMupN049
dWrnqdxTvU71PBV/KvZUzKnoiMMRv0d8YXoZM72XlU8rH1c+pnxUuV65TrlW+Y7yOeUm5QY8v75T
9BDxdiqUcN8lnW/8nIJ+E4AbypcFW0tZGAf/5kcYgJHmz1tWIjyBGdEANoQVIR7btpXdjTA+AP/q
hw3iwIYESwP+3Tpu6ulmia10/L/l1PzLljtvKArwJNwPC4W7YQ18A4tgJSyDx2EbbMEUoQ7FugAe
hsvwM6yAR2AJvAqn4RI8Ac/C3+EXuAKbYQe8DW/CczAWSmAVjIMjUApvwTvwPrwL78FR+BbGwwdw
DI7D8zABfoIH4WP4ED5CW/0OfoClMBHKYRJMQeudChuhAqZBJVRBNUyHGrTpmXABZqF1z4Z7YS7a
+QuwCebBfVAL8+F7+BH2kzXkEUKJQBgRoRGukbVkHVlPHoUmaCYKoiQq8JPHyOPkCbIBY9EmoiYa
oiU6spk8CVfhH2QLeYo8TZ4hW8k28izZTnaQ58jzGLN8ZBfZTfbAP+EEqSPLSD3ZS/aRF0gD0RMD
2U8OECMxETOxwDn4goQQK3mRHCShxEaWk5fIy+QQOUxeIa8SOwmDneAj4SSCvEZeJ5HEQaJINHmD
vAm/we/wJXxFnEQiMSSWvEXeJu+QI+Rd8h7GzPdJHIknLuImx8hx8gH5kHxEPsYMIYEkknYkCc7D
1+QEfAJn4SR8BqfgDHwKn5NL5DL5Gc+qX8jfyRVylfyD/JP8Rn4nHtJIrpEm0kyS8RwDSiilAmVU
pAqqpCqqphrSnmqpjuqpgRqpiZqphYZQK+lAQ6mNpJBUaqdhNJxG0EjqoFE0mjqpRJfTGBpLOpI0
GkfSaTx1UTdNoIm0HU2iHrqELhVNopleEuYLC4SFwmJhqbBCeEB4WFgtrBMex5PzKWGbsF14Ttgp
7BL2CvuFl4RXhDeEd4Sj6KsfCCeEk8LnwhfC18J3wkXhkvAz/Zn+Qv9Or9Bf6VX6D/pP+hv9nTbS
a4JG0Ao6PF0IbmoLe4o9zZ5hW9k29izbznaw5/BU2cl8bBfbjSdzPdvL9rEX8JzZzw7gOX2QvcRe
ZofYYfYKe5W9xl5nb7A32VvsbfYOO8LeZe+xo+x9dowdZx+wD9lH7GN2gn3CPsVT6iT7jJ1ip9nn
7Aw7y86xL9iX7Ct2nn3NvmHfsgvsO/Y9+4H9yC6yn9gldpn9zH5hf2dX2K/kK3KeXWX/YP9kv7Hf
WSPsgt20jmTAXtgHr+HtaA/Uw+vwF3gFFmMsGigMEQYJg4XhwghhpJAvDBWGwa/kW3qY3QcHYR1c
RM98Ch4i2fAA6UlmkAfxvHiYzIQGModcJD+xaayKzWfVQoEwSrhLGC0UsvvZdDaTLWQz2CI2my1m
S9hSVseWseVsFvsrW8FWsgfwRH5QPpMfZY9hTvMEZjZr2To2l21gG9kmPKmfFDoJnYW/C/yOqABo
+aCYUHzQm8IONgpMVChVao1WpzcYTWZLiDXUZg8Lj4h0REU7pZjYuHiXOyGxXZInuX2HlNSOaekZ
nTp36ZrZrXvWbT2yvT179c7J7dO33+135N3Zf8DAQYOHDB02fMTI/IJRd40uvHtMUTGMLRlXOn5C
WfnESZOnTK2onFZVXTN9xsxZs++5d87c++bVzv/LgvsXLlq8ZGndsuUrVj6w6sGHHv7r6jWPrF23
/tHHHn9iw8ZNm5/c8tTTz2zd9ux2Ycdzz+/07dq9p37vvhca9h948eBLLx86/Mqrr73+xptvvf3O
kXffO/r+sePwwYcffXzik0//dvKzU6c/P3P2Vu54K3e8lTveyh1v5Y63csdbueOt3PFW7vhfyx29
PXt6s3vcltW9W2bXLp0y0tM6pqZ0aJ/sSWqXmOB2xcfFxkjO6ChHZER4mN0Wag2xmE1Gg16n1ahV
SoXIBEogOTeuT5Hkcxf5mDuuX7/2vBxXjBXFbSqKfBJW9bmRxycVyWzSjZxe5Bx/E6c3wOlt5SQm
KQuy2idLuXGS72hOnNRARg3OR3pFTlyB5Lso0/1lepVM65GOicEOUm5YWY7kI0VSrq/PjLK63KIc
HG6XVtM7rneppn0y7NJokdQi5bPHVe4i9h5EJqg9t9suCio9LsoXEZeT6wuPy+Er8Amu3OJxvkGD
83NzImNiCton+0jvkrixPojr5TN6ZBboLU/jU/T2KeVppHK+G1gm7Uo+XLe8wQRjizy6cXHjikfn
+4TiAj6H2YPz5vjs95wPu17EwS298xe3bY0U6nLDyiVerKtbLPk2Ds5v2xrDnwUFOAb2pa4+RXV9
cOrlKMS8oRLORhcW5PvIQpxS4jvhuwrsrzQul9cUTZR86rhecWV1E4tQNRF1PhgyO2Z3RIR3v/8c
RORKdcPy42J82ZFxBcU5jl1WqBsye0+4Vwq/saV98i6TOSDYXQZjkNDp2xKlrW0yJbNzKm9Iq2QJ
X1Hc7WgQPqlEwpXkx+GeuvJHaVeoK+mKbPhTQLCXbxxqpNyn7l1UZ+rG63l/n+jCHLHuV4ztRXEX
f7yxpjhYo3CZfgVOcjtpNTVsb6F9Ho8vKYmbiLI36hTX2EMud2qfPKOBxsVVmiREKD4YhLItLuiW
guKPieEKXtbghbFY8NUOzg+UJRgbuRu8KZ4CHy3iLYdbWkKH85balpbW7kVxaMn18q0v1Kdyt/4a
TbaQ3LJuPmL7N82lgfa8oXF5g0flS7l1RUHZ5g27oRRo79raFqR8Ib3zhUgapGikILeiUY5uZeaF
fJ2PufBXIRv1uAalCq1SriFSH5+pqF/gWaCJifkvdmrwX+a9ZHS9W3CZvm6eG8vdbyjfsDxdnYAL
Zm6aN2xUXZ3mhjY0tcCEtwcRWjwMy4+RevtgOHqmC38b/Ie7ciiI9HlRZL05A9pfoCpYvIExMkgX
4A+3zvbJfTDQ1dX1iZP61BXVFTf4a8fGSaa4uv30VfpqXWVuUYvhNPgPLIv09VlegLIqI93a94wD
o2CHSwh+BAGc+ExBGIgwBuEBhA0ICpmP11QgzEM4hHBZbvEK9t0PpXsbEC2T0Z6Jk9PkYnGgOLpQ
Lu4ZWRDA/QcHcM7tAbZuAbaOGYHqDr0COCE5gC2utFqONfq0wz1tmLofR6BQiU9CXwcjIeCEjUIo
+BCooAjWeAXLnnh32oZDAgNMBwSCaanTf1ggu/XmtJ4a6qeXwAJO+hO9GGihF/cYzGkbet5Bv4Sd
CIcQBPolvr6gX8A8eg49wIjPbIQNCIcQjiFcQlDQc/g6i68z9AxyfQ4pCNkIYxA2IBxCuISgpJ/j
00RPc3+Sn5zORqD0ND5N9BRu6xQ+jfQzpD6jn+HSPtrdJTNtv0x4UoKE0xUk7JFBwmJLa6Af7v6t
nbOBfrVH8jg39kylH4MPgeJkH+PgH4OEMAihCKESQYHUJ0h9ArUIqxA2IvgQFNjnE+zzCfY5gvAe
wieQiuBFGISgosd34zQN9Nhudy9nTxt9n74FdhTqUfq2jN+jb8r4XfqGjN9BHI34CH1zd7QTemqx
HbCPCbEJcQq2i/SVPfEWp7+nmR5C8TjxmYKQjTAQYQzCAwgKeojG7h7ntOAgL8IRFSDnbvhOxk/D
ZhV4Jzq97t5oYxJ/uLvdhhQ+Nkgb3NTrXrMOi/zhXvkQUvzhvn85Uvzhvmc+UvzhnjwDKf5wj5uI
FH+4R41Bij/cA4chhY8G+sQL8QnOLgMnEamnkc5EKc1EKc1EKc0ERmfyF/zG+Noe3Z2UhBJb7/W0
S3LWHiC1B0ntEFK7mdSWktr7SO18UptFau8mtR5S6yC10aTWS2pfJF1RFLXEW39DMdMbRmqPkNrn
SG01qXWTWhepjSe1EunibaAxu29Pl1GujPb05H6F+LYeaUZcYwxKNAbNOgbd/hA+jyH45ZIXmaTY
AHN4NMexe5KyA+UO3dIqevajr2HH11ANr8FZBIYKeg3N6DUc5DUcwIjPbIQxCIcRLiH4ERTIHYsL
f0B+GvGZgpCNMAZhHsIlBIW8nEsIFCqCS9wpLywluOiBvERfw1csvmJojDfK5DB5TP2EBxzEGE0G
RvujaRew8Vu+xawy421t3z/0//yHHtQ91XQlfQCiUBGrgviB3b9FORvI2t3uF509Q8kjEM3Q6kgm
uIkLcVeolsudwKHiOAMcdDvitN2OEdjNuNud7DxADLzXPudvjvPO7xwNFMkLjhedn0oNjOx2nsCa
7fucHzuWOt9JaVBhzUF3A0F0QJJZ9zu6Op87IrPOx4b1u533cbTPOdfR1znJITeUBhrursaS1+gc
4h7l7Ifj5TjGOr3VOOY+Z7bjbmdWgKsT77PPmYpL8ATIJFxsO4c8aVy0PODwLg2kzJusXKPMVw5U
dlamKZOVMUqnMkoZqbSqLCqTyqDSqTQqlUqhYiqqApW1wX/O6+FvAFsVJo743wwQYDJtovzJ3yvm
cY2oKNwBvhAhj+YN7UXyfIdLIG+s5Ls6NK6BaPAAFeN6EZ8lD/KG9fJ19eQ1KP1DfF08eT7loLvy
dxGysgBrfXRJA8HTr4H4edXCSJ6q7gdCzAtXRHKcuHBFQQGE2WZkh2Vbepgz++T8yaMo+PRc/wm7
gY7yrckbmu97NqrAl8YJf1RBnu9hnsvux/vz5dyc/XiVRlSQv1/oQX7JHcLrhR45BQV5DWSEzAcS
+Rn50GJ+lvlU0SBxPpBU0QG+9QE+F/ZHvniOkE+tBpfM51KrZT5GON+u6vjcnF3x8TKPXYJqmafa
LrXlOeJCHpdL5rHVwhGZ54itlvP4esgsDgeyRDtkFhIBDpnFQSJklhHXWVKCLEtbWZbKMwnkOo8j
wKM/18KjP4c8nv/qT2kvj4fs6V5QMprfA4ricksRinzLZpSF+WrHStKukoLgBcFdNLakjOPiUl9B
XGmOryQuR9rVffSfNI/mzd3jcnbB6Nxh+btGe0tzdnf3ds+NK84p2NN3UEaXG+Za2jpXxqA/GWwQ
HyyDz9W3y580d+HNfflcXfhcXfhcfb195blAtvFB+btU0KsA004Z76FaDdprUWRMQS+bqbKHbLzd
Y8LuizzA+B/2aTEL1+GNTo/Am9r3bN+TN6FP8SYDv+wFm8Lu6x4TeYBsDTaZsNoc1ws8NdOrp0NY
bnlO4Lcaf7CqZjoXeODpqf5XP9iWi/e2nOoagDxf0tA8XzbmubuUSqwt4lvydWup02pzMd0MVHbA
ym68UhBaGXldFq9Tq4OMf9T/9CDuzb2glr64h3ijSQ1UFwi+6LxhFEPBsGBWfQDTJX48VBfgBquJ
h1S3jCEvGwI08P22QM30IBWUQ00QB3phl+oWcbT+YB8MVeIBCEeIEJ+BcOaGMAD/twgXOG4u91/g
7RzT75G5IQgAW+E5Ug7PwSF4lVwG/s7efqgHnvHkwGMwB/4Ki/EUG4U1S2EIvkSs/ysJ99dDCmzC
c2wTHEXekXAfHAAbCfN/B/NgofAR9loIeoiFnjAIKmAFudM/HUbDWbYAusCdMBUqSa0/37/S/5B/
CzwF+4W3/U2ghQgowddR/0/i3/ynoT32WA3r4Cx5SL0XvDhLLXI+DlWwXihkxD/B/zuuIAZm4hoY
9Iej5DD14Oil8C0JI3OE3jjKk36f/3XkckAhlMF6OEA6kb40Rhzt7+8/CjacYxaOug52wz58NcBL
8BnRiZf9W/yXIRyS4XbcTz28Tw4LzU3zm7O5oFFK7SATWyrgZXgLjpM48gqtEHVimugV7/F/DFbo
CMNxtc9gz2/IP+h9+JonvMn6+HuBAeXyIJc2vAFfkAiSQgaSEbQdraBPCFWgwhk74msclKO81+Lo
Z9Bq9lEdPSY8ybazRkVU8zm/ATXihkfhcXiF6HGnEqkmfyGfkK9obzqGPkq/FP7KtrEPlcW467th
CqyA7fAPYiFdyWByFykjc8hi8iBZR46S4+QC7UmH0Un0klAmTBNeYr3wNZRVswXiInGZ4kJzfvPr
zR80/8Of5l8Eg9Ee5uPqV8MTuLP9cAxO4ussfElEoiUGfPF3fYeTe/F1H1lBNsvvQdfjLMfJl+Q7
PIF+JY0UD1aqoJH8XVZ8xdEqTCj/Sh+jx/B1nP5IfxPsQqzgEToJWUKBUIGrWiyswtde4QsWwY4x
P8o5TVwjbhC3itvFV/nnacq/4JH+3rUnm5KazjRD85LmNc27m+v9X0Ao6hAPC7xCZeHqi/E1EfW9
Bi1uJ3xEdCi7CJJEepA7UTJjyEQyjcxCSd5P1pOn5LU/Tw6ilD4ll3DNeuqQ19yBdqK96EB83U1L
6TTMvR6i9fQT+rugFLSCUQgVkoS+QqFQKtQIs4U1gk94T/hc+FK4KlzDl59pmJPFMjfzsL5sDJvO
nmDfsm/F0eK74tcKjWKKYpGiQfEzJjE9lIOUg5WFygeU+5Qfq4r4u6iwF15o+1EHOSfMF3KFvbCS
prNwvLG8j/Y8BsYJ/SlaKt1KltC5pJ7Gi7MU3Wl3MgAu49X+r/RNuoFepd2F/iSPDIWJ/Juq/Edh
Zfyb31nsNbjIDuLe3seRZyl05D56SaGD3UT+3jR5Q0hlHuFd+Ew4S5RsE5xiGmInF+kzwiC0gpdY
DzEfYoTH4HlhGpkLe2kugKZRtRzteAB5FuPCMJJG/in4MesdgFbURfgKFsAk+je4iH68BB4h49gE
WAnpZA58C0+jV7QTpyqSFKHkHVrO6mgIqQfKtvHvM5N4IohWuJ8UCusVl+hJmA7HmAbOCDtw9cfo
80J/dlkcQsrQA+bCIpjmnw+zxXz2IZkAAhkBLnYOo9scIY3FIJ6HUWU0xrR96N0HMA70FPpjTRha
zp1oF8MxQqzH11qMEwwtqBx9fCRGsfehXjGMNsAE0UAw6gCwd5uHwCj/07DOPwGm+h+C9hgPFvvn
4Ihb4Wt4ALaShc33QiXeHE+ib98p9qHHxD7+9rSOnqRD6Zob9YvSdpEw+B5fz0Mf6CG+CHXsUxgK
2f7l/hNo3YkYYdfBWMxPz+Muf8IZ+gmHIb15AN3l7yNU4n7PwmD/M34n0UCZfzIMhIPwlFKEYqUn
OMHk/wWcDwCREFb93wC9HABm+Bdw4M9B3IL2O+A6KM8BqIb9G/AFQK26ETRHMC9pBtDHAxjyAYyb
AUyP4dVLBxCC2w3Zch2s/QBCZwDY6gDsyBf2IUA4rj0Cx42KQPgGIPoXAOl+gLi/BMA18Rbcgltw
C27BLbgFt+AW3IJbcAtuwS24BbfgFtyCWxAESuQPXET+V/1K6FVPyXmFsoGu84aAyM4LoFGy8wTC
VQrxPBUO0o6gJutIBwjzmK5mNWUNMF3J6t+UBdlIm67ho2NqjDnG7MIHAQbXJOHwNS//I3uJHeaf
9T/bfIYsgKOggQF7NTjhdkUDGeR1EyGLUqIhWaChAhZA0VXZbSCMgQqYBxtxcRu1m9bilFcKr5w3
Xcwy4YT8abpoarpIzJbMjqnpndJDrQplQufOXfYdHTQyLbOzcPTotGXu/uHFd+G8B3DyxTivAC5v
GOXTZAUG3wlsI7ZvZPL4VwsLL+LQgeEOHD16VP77BP+3NFP8CPsO3Q+C/8xuayZt8J/xStbMRwRC
hQ3CToEKM4BY+VfgCPJphAtAL5AGsm0vANtzD46cZbpy0YRjZ2VnLRY7eArnml7vmEoKPZ5Qkk7I
tlXN+eHij7/jCNTfhPooEA+gNgwk2luSYko1TVCVqYtMS4RVpnfENxWHTZdNWpVYQEbQQaYyrc/0
d93f9X83qJmO6ZlB0GrUImM6vUGlUCp1SKsUOiVuQ1LqrFhBBUFiOityqKNFURWtEBQNtNKrBpXu
Oy//E/8DRAuEaL0WnQSlSmHIIHaMnWXCKkZYAyFe7SDdYeVZnbBKR3S8bDIqjynpPGWtkiofNn7y
qaymaeEI+BuGm44IN128CGHZWREXs89ncfVd5CJACSzuEMYR12CmOTNzsen11w2vv75YDGCUT55P
OzTPFz14VH49Mwoq5QH/ZVTHP7viTwGpmlYYh8KLE2KEkBjBnaBQCjT9A5r/+famRzedJD+v6xPr
SBcP/N6HHGzOoaPImv0zVyxDfY73fyvOQH1GQYO3qIROjKISpOlLoBJqomrh/qhVsF7cLjyl3y/U
69/SH4fzUX+PMhssUeaoKCFJkWhOckjOvvoR1pGhI8LLxElR91qWWdYL6wzrHVvJFrrVfMIQAlaI
MFlNEYwbyu7ETNLgP+xNSMw0GYGwyJBonRAZzdQmt/EOcEuEkAin3S2piCo8umR0mAedqrD/xQFo
jf0vXuH2mH3RbEcbJx5PYeE0KCRVxK5gcbHxtFOGJT49jdmVbndcrIKGWi229LTOrP7V25pf+/pi
86eP7iS9Xz1NkrsfSn/14W1fjZ7yzaInv6S046XGV8jUD78mw3ede7f9xoc2N1968MXm7+oOonQO
oRHPR+sT4K97CQUVFXHte7reliHj9IwAbp8awIntAjjOFcBR0QEcFiFjb4relCGJq8SdIlod2uAD
6M0+YCnghUFwFi6DaJGwchVOt5l9UiC7YO/R+btr0QILC6ZVZTUVtnwGjz6fjY5pTjcfepVrFSiU
oCY/Fz8GA0TCPG9RhJFYTVZrpD0ykjETs2rt2ki2zb7P8KZBsNvDIqkU5TUPDBlo90bki/nqkabh
5jEho+xjwkZEjIxcZl9HTeHRgmCJ1qpD3ZKSKCNqo0iU0S2hVMIdbRVTyDUj64X7MGoE1RJigpg0
Zgm1UlkzXUyQngbmDIqKgRKyhHR+l/TZXt+879Cx5gNb3yZRn54ikbO/e/D95k/pETKFPP5q81On
zzZv3Ps2GfVy8z+aj5EMErmHaB9u/pp/p5Z/d6wJtaKHMBjp7VRqnmSleaY8612mu6xMq4s2Ggxg
D4umXGMWtypCiiD4GxGmlwhffmF499GybOWQPa3wKl8+j9mWzBQ5aJNCKEw3x6TZo9GIaEyMGenO
nTLcCe64mCdou4f6T36o4Kfmd5qXkHsPPlF4Z8f7m5eKBwyW0n1TXmxuatohkOXzRi8I1eNUo/3f
sh/Qu1Kh2ftYiVDCqoUaxlwJnYRMR2/hduWdUbnOnPg+CUOFAuXoqJGJS0MMiXp3PI0XElydjRlx
Oa7clFHSiLjhrsnaifpJhvHW0rDZ2nv09xjnmqbHV7sWCXXapfo64wrTwvgFrof0a4xrQqNd8Qa9
VoxxREVHqpQKJlAFccXHYp1CjI5s/wBK4qIN2puIRAaRIlJJVhEFRmef19U+OtomiNHt1ZHuiDvU
bmhH2kWkxbgtxG0ZJuu9Y8ldQb2fx1B2g0+amgrPI1wxW+yZ6J88iBEL91MonIZWEdIlmqIzBqQY
n+B2d8ro3Dk9zWYLemuo1W5jdpsNjy0FWox79Av6MW/PrXh26KDR3ZsnDy6fcN8vf33yt0XiAeNz
23ybMruSk/m19yxqfPyt5r+vI5+apq4Y2as6J3dCnL3Y0+XJ0opXxpW/N9+wbOX8uwamp09K7L53
xvRj1TXf4R5S+ed38nky0KsXaTSKB+Qv0KgbaPUeKRDWX1BIhKbg2Yv0XiIbDW9V7VsXsBuUQJap
6XzhNyb59M1uOeo7xYTGmGlIcxSra44U9c899/vf+Zm5rLmchslzdvU6meAh1CQqPKC0CJQqFc8z
0SVPsUP1eFmLXV7JkkdGKjB4iDkmNM6cHrqMrDh5srlcOXj1bydX87ETmstJvTx2htfBRI9SYRKo
B4hFIYqEPs8ElxJ2qB8dxQ+iPxmXxHRKN8d1iiH1zdUnT5IVzeWrFQmr0cfu8F9gDtYDEqELifKu
VOvVSeH6iKR2+qSkTH3n0C6R3ZJuTyrUFyZN1JcnFaXW6Re1W297NGKbPvTp8GcT94W/mPh6+LHE
D0M/T1Tl2IjT7gzzJCdlZLLM5NtZv+QRqgLPeFW5Z4Zuse4d3W/63zzmLhkGwkwp8Rn2tBhr2Jh2
Fe1oO0eKIdvwgGGDwW8QNxh2Gi4ZBIPBIdgb6LNeW9hqq8OhhNwETZpD0LYrNhWDKya+gd7lNSV4
wW1yS+5U90636O6YyYOvMzouIzXzcCbdmEky7a6w2JT4Q4pjCupUZCuoomNXlPs0NGZT4TTP1cKL
KKuvv+aGfT77YtN5tOYUbJ2GWDZsc9CyybRCmObiFivbcxf51SkjgVu0MqEHlQ3cFhpqtdnj3IJC
acB4ws8kZBKyxu2fuPNg3+p+nSZ9NoGk5y6ZNzvKFzb1+NIlzw4yqe2xBx32sa9XjE6bUl622R21
YHif7QsHzB9gNegj4l2aqe1vK5gWNm1Znrf4jg6zLjcuvK0r+TzRYUrsn9Kv6K6Bt81EDS5CDTrR
Mkx4tn/i3UFEnTFe7CTmimK20+ekTicmBI5ejkrnKqeiW0iWLSviTtudEYWqQn2+sdB2d8RE1WR9
mXGqbWrEYedJ3Wf2z8K/DPnR/mP4V1HnnH5nuCSmGFOsqWK20SveaRwkjhc/i/qV/W7SmUINTEEh
0qFQEk2ow6ANiz+uJSatV1ukrdUybQ0xp0O64KL0MMHYs5H4yGXCnCSbDCQCCY/u2yUQY/C8629q
usKjyjQ5xuCvOVPOb1Hy2AzTYtAlzBhGME6bIC42QcAoki6HalQAaf9MfdWusTuneZt/eengJJox
/MEZO56aPmOHeKDp1wcGPnCkuvlS8yePkzWHhi87+u7xN4+iNw3yXxAuotVHwFFvX7WOOB29Q3rb
h4YMtReFFNkfpY8K6/VbTFsidCp9uGYiLRcmitN1lfpa/dO6vep9mr06nU23SPcVFQyxY4wVxnlG
wUi4sd6eKp/xRZhWrcJD/xye9WowGrUYjCwOrTLMwbQOIzHGG2IjcRXxWo+TEDz0ye2O0PhjSuJU
ZmM+2TEy43U5Pky7iI+q4Ndr9gPh32e5WHXlYpUcidFWzZkpJgzHhedbwi+mSGikeAJbeNBtjblc
WELWrqhLz3/W/I+q75Y+d9q5M3zeqCXPbrl/4kqy0P7CMRJFNDsInb9zU+Skya999Mmrf0HL6oNS
OouWZZYta7uGMr1Ln6HP0YudrJ0cI+kwzRDrUMcEOk4sVZdYixyHnR+LJ0I+D/865GvrJfsP4V/L
FmRzOj0R3OzyIrgNKjvQeH0HWzfaSZ9Hc/V9rLc7RmpG6Cfov1Z8a/udXDGYSKhg0GLSGIkSMwOa
lqANSyfgMhtdJtNxMzGZveYic62ZmWss8YcwDz+r9CsZl91ApaAMj84YFDSs/hfRpOT7UtZ5LrIs
DtdNizt1TCfu1OjVAYGhmRHrddMSupa+Pu/E9IkfLyhak7KnSdoxfcZTW++dtWnRE8sbn9xAhLrB
Panh9z7U8t6RV9787L3XUWZ56I3RaFmhKLMz3nFOcITS4UKhWKgeri0VJokV6lKtygQmYqIJlpPi
79arEcqOlm7hHR09Lf0jejoGW0aHD3EUW6ZEFDtmKWaFXqVXw0xgI0a93T7IVmSrtAk2h3GVaaOJ
mkws0qFRAjc8NVkdgsZl9+p5DFQnJGX49EQf4eRpqcudwbE3ikdGJ3Ha0k3xSm98UkYbkQV90dO/
6TymSh7P1WkeOdlrOi8bGh5V07LkGwuXHc+byLSqFmMLJH1WZYyNS47EuOW4KNx9IPmn/d81XyLW
0yeIgVy7oNm9sGR502d0sK7riKVztpER9ifriRNjgY4kNp9p/s0k7TxQRlYv6l32ND/xQjAFrMWc
yg57vNFWNTGGp4SnhnvDK8Mf1T2m36ZXRegT9b7ww+EsnO8uMcKZEaXSCzqjQ0NCqccawgQFaDZY
idUf4mV2FwOBPoTuxkXSsWsGx16Nw5mxCud6Miz8IDkAMXCVaPCWjycDpt54kJqyMP+5WMiP/ix+
ll7EG1vH1N6zvVaTWaFWKlR4pJjUlkgwK4yRxEM8SfPnEw8aVhU/bdM7ZXTh2Q/6IXfD0HQ82ndv
2BASsWDGnaMju6YNyTl2TFi/fNqkjD4jLY9r+hSNXX5tPNpQr+bBwvdoQ9GQBJe9RVqtaE3Wuqx3
anOtCnVUeFSy1m1NjsvUdrbeoe1jHaHM15Zpf9f8GmroEJec0COuR8KdCauSNyYrO8d0bped3Efb
Jya33bCYYe3KlSUxJe2KkmuTP0u4EPNT3KUEs92mCG2gu+oTHSFKOYKZJEydePyqhcNwHLh1zfX2
FB0OoyY31qHT2ELTXekaV1jYcTsx2b32InutndlrjMQFsc74Q8ZjxrNGv5E5jdnGgRgVwz3JNTHc
IT0DZIe8whPIaTypusrfzuCnbuF5jrOCl4ppdrvNHjg7E9C6aMAz7Zi9yBmjO6SNe47fqU3rXTN3
SZiBzPCdujz1gxUH73m69NTGl79f9/TcOVufu2fW1vyIwa60caO6+JaRrM/XErJ8be21if88Nmu7
kPTB4UPvvfbma6j9xQAC/ztmK+zaDzY0C32oPcPFOgm5wgE9E/hXOuLt4Rl2lVlntgoiAaNDVFq1
Gp1L7U3vnOFXk8Nqoh5g4xZlz+ic4bNdttFK20abz+a3MRu1umSr84Yi82X+3oqEkj0HDAaE9h0U
iPQe/lYSIhSSR37DRD4DMbUOmJtBYVC6DApdJNGr0NAALc0zHzyFxJMeOBkxozbHmWWpKELNi+vv
Ozzj+bz66ZMGrcjCY/CXhwq3PNY0hm5afO/QlXObXkQbW4IuliXfeJUw11s4UL1KvVHtUx9Wn1Vf
VitB7VRXqmvVG4JV59R+tcapxrNKyaigVgj3EVCICqZRKF0iyF9z97HD7BxTHGaXGQUmseNYYmyA
qmWHeKuVU+jsi4F3PhC4yqumhXRKDxVwF0vq6+vZD8eONYYyd+NnPAIswEcXeY3L94OIbtula+Ci
ndEpgFM7BnBs4CLudaHejKJT3CCeFdlAfFwWBadYKdaKfpHxf/GSCgFV8JFklUSgj24AchgPatpG
L6x11R5PYN2yeVbJd3Iu8gX18m1cth2FG301Dt7cD2r/37w9tXq0nfPsvPoL+9eSeEK8KlG7SopT
h0VKakGIi3YoQh1aLSZNiriIcJPmuIvwfx2Huuz2CINrlZmYG0jh3jDXqkgSiZQ3HGh6nIsc53/G
uBGoE7JhIEokPN7VQGbtienb4luYRTWdxxB+8Uph04Dc0pxvMHHiUQtF3h+PQP5mChd8i0HprCFu
q84cSSz60BaD4nGd7y5UvrLZ+SNgVXL4amtfm9KenjjjEed9R554dk/c6B6Vf63PH3fn/G7MvXrA
mLH5B3bua0qgj08e0231lqZH6O5Zswatf7DpZNDTvkFp2eA9b4goKELoVlOD6Svh25DLwtUQBWvw
X/Z2RAHONpG1puNh58L8YUxSWQ1WmwVdjihseo3eoDPEa2W/0xL81Q4IkxXJ/S7schitDNsY5gs7
HMbCBJoeagu6nuUPrmdvcbsrWYG7ADpe4M6ECeh1z7MpzGqNSqPUCAqT26wwRBKjxhIUWNJ8HrI8
hdNkmQUvAW0Etnjz9M+LNg0yaeqTJvWrfoa5H9mZW9k/bW5TNV00dUrPh95rOohWl4MZQwLKRA/h
8Iq30KLUhOv6KvqpRigKVBMU5SpVhqmbpZutU1iuKc+SZ8sNGy2OVg8xFVoKbUPCpohT1ONMUyxT
bOPCZpJQtULU3yUME4dp7tJNFkrFUs1kncbuYEozmpw1XslFERLvykhVElCalBIe/h3PckPD+nCe
HiBtiAcvsnBDo9AxgqcGKCrPRUwLCq8WFnpa3wPi+VPv0fle9VBxqHqsOFbNSGFBiKkLSgIC93to
G61ztix94xSx3fvDsrPNF/fvXrxo956Fi3fTEJKwckbzF01Hf/gLiSb6995974M33j2CUy9uLmcx
KBcLnoPHvE/pTO1Nt5nyTCxb8knUKbXTxUWlhaZF9YqqlFZJqm72bpF32O+ILFDdpRttHx05UTVJ
V26aYp8UeVj6yPp52OcRH0Wft56PPif5JVsc85g8oZ1YN1MfdodplOlr7Q9RzSat2YC5Fb/OKGx4
nQFDePxxDTFpvJoiTa2GaWpISDpNt7gA/vRC48QLDfmzG418pTFntr3QhLQ4mS3USvmxlmAW2ohq
8ZZuD5UtOT5x+tl7Rz3Qwfz0jFnbn6mp3tVcLr5UN3jwcv/aJ5sbl93ZralR2HL09XdPvHvkU5RX
v+Zy4RzKywQOeNm7Vks9NCmsO82js3WK7NDs8LzwVdEbo8WMkIzI7OickJxIvO5EloSURBZF10Z/
rDhh+Ubxne77MFM7GqvzhGbSTrrbaR/dKFpOT+pOhX1l+y78m8hr1EiY3hqBmblBYcWEEwx2Qzrw
vNxITEavschYa2TGGvOf5OVR0TdkAoE04ErWH+UD04g5eI3pHDz7b0jKk5MeGf5S86WKj+57Y9rm
ppgds6qf3jlj+pPN5VTVfQDpQJQbmxc8vfL33sJzR4++9tbHn7zFz5KFmE2+idIxwwJv95QQYmIk
jmWw3mwoG89qmEJtVqlVan2IWa0HQUW0shmARp24SkVUsVIICaGx5n95jlv6vt56juN97EoV3jfk
TfF3+OXzDkzvLDbMfZ1vsYoUtgTZQGaoxFixcHOP8uy77u7Rq1f3u63RzL1pWr9uzyT0zS6qavqY
rz8b72K7cP2p5KT3XhZrje2mvkOdEz8itjR2jnql+v74p0O2J78q6NX2iDB7al7yJ3Yxkg6n1JRG
NGGjVaPVozWjtaN1o/UTVRPVEzUTtRN1E/X17voEI3+fLr5d5/hRmgLtOPe4xJq4mvja+Ic1j+ke
SnwkeXXqFs023ZMJWxL3uN9w26L4Z0CW6MxRqgSXTsMiJHco03aIiuCpo8MZnh0+MHxM+M7wY+EK
Y7gzvCL8bDhzhj8QTsNfpMPxTgQ8wzQRL6EmcpxQICZC+ccEe6y2DPnjgmiDOYOQDqOjJkfRKEeo
kjk6aJ0RJCI+3BsSlhHeQO/arYxPQs4XHJnHk0hSRBrv5cb7TlHa4TSanVabRtNMeKOOByneGHsW
CD8uKYR3bLniTOvPP5OqGiAHfX7LueIJXqin4UXHg9G8SnbcqvOBd4GCbwLhUeBNaB8dh6m422yy
mEJMgiJWL0WCOlEZScT2+Ii2YjHGEBcJsXF6naqdJpIkJqg1Cg+LBKcpih8a/COxrMCD8FQiyTN/
Ps/jpvFEqDCkiy1g5gnuhA6Y+Xbu8of3TvHF36yWU+Hs3cal986Z1cn18JvrBvbsmvTg0LkvjTL7
dNXlcybabCmR9x96ZET5m3OPnSS3OSZVlebcFhfmSrt9/oC+sxOdnn73TggbMnpIlzhHVIgmPr3n
nNGjNozcwS0t3v8LTRLX4b2rdj9o+Mcc7gw1l3JPJGrDMQfU6TVEAJtJ7TFqMFQKWqMpFmKJ3uLS
Eb9SlavOLVJWKmuVq5QM8IzZqPQpDyuPKxXKA3QihJHOu8YHnEX+WBPz3vM8Clzkb1TyKGBOTze9
E/iY0GUP3M75XcrcxczvT1YuImqKuDNr7OTk++/fs3dviCcxetMGU4/SzbRkOVFObl6xvOnh/skR
cgaJXnNO/tbiS/shgt+MMUOkUogtw8hTjXYWa4YnhMSrQmw6EmLTosObcTuQbnOF2eUUw04O24l9
QITs9jzFiLgcQSsjNkb4IvwRLAJvAK0BAbNjtaQ+jrkyUw8Ib03sL7ZkFxgZ5He3sgIRQTapCGYy
6I16qlCqFCpRhTkG00WCXmWOBJ5hJCXNx4iIdhJ8myIBRYEXIbtsJp05LWTPOXH3kwNN2nqteerg
wSu71z9W32/KwE7V9KGmPSs69h089IElNBPTaQIR/JaDstCQu1/ohJeYWHOmhnuz3pypxvQqQ8Uf
tMH//R7EJIiR429edXRMBiTiA0sXvGrMtsGGDyx95t2b2CEDJHwYde0gUe3WZEInTT/oqxlBRtAC
Vb56PBlPy1Xl6lkwk8yks1Wz1DM1i8liukhYqlyiqlM/DmvVD2p2wGbNS/CCcpfmHXhD8xmc0PwI
X2ka4YomWQOiJgxsmkRwa7poBoJXoxa9FluG6MVEUaNUqVxqjVWt1uD1nmKAtuIVX9RoMHSrVJQS
hVKjFoCIKTqii1V5vV681VB1A4nc68VrARWR8qol6iWx2u8/5Cq7GBHeVNhUGBF28Xxh4A2PTMwJ
ucvy9474Z7iL58qf4S6Wo7nHg3lQ22/NQmEMSQ/B7LlLSDohzzdPfvm8yxnm+XF/81Tmbrp/QsWw
GXRJ4H6jABBfQI1Y6C6vyWglSaydht5hvsu80iyYuX2qnTEZJkdUAve/y97nnPEZTKFThygi1eEW
kQFTaNVag8pighDBqnSoIrVRmLy5lEkqjyEDOim7qbobcoS+Cq+yvypP29vY13yH5S7jEMsk5TjV
BMtsxT3KGtV+xQHjPsuvikZ1otacCIn6BEOiMcGSYu0KXSwzVYtUa4VHdM+QrXSr9mndXtinOGB4
m32iOKm+wC4Yv7VcUfyudlgEUUQTVopqjUal1ek0JrMZ/StvjwgWqcF/u3e8xmiQXjMrVZLSbLF4
8PIsikqDRqdz6Q1Wvd6gMhuNHo3Kit1BbNUiUKK0MJXRrDPoNWYNEyx6nU6lUiq5Wi1G/umfxnrV
pCdFev7WrKBvIM94NdJADanQzNNQTQMd7lUPNJMK8zwzNfOS1iSSIvk+KKDin9lLroZcHS8fC+H9
rxQWhmHYx19uAIVh37Rq3RR8WQI3qMzA5/b4XNy/rTHciNASFhtMrysNpiwOnOaQ53MOza/XSzqJ
HvSfA4Jg8B+vh1SjZGnwnyNdgz8Feb6Mofn7QeU/vkuZSuSKmKF5vnT5nWCV/9wupRSotQT/VmA/
H2ifUeJjqxr8x3crU/mIu6ErPRCYqXXw1n52uZ/Zf26PRmIS8AYMvPL3zw3+j/dZMiEZocH/8a6Q
TNxQQeAGDNMwS+NGLtt4iJ0bepyQIJC85hcPbMtm6dv2b+h0276dzfUvbmv3KRr9o+fNR+jUprXv
HqXjGz+jc/ZeO4bWH9M8WPgJrT+CLN5jdBAjj0VbHJmJ1hHGnRrBq/caqVFKTM0w8YdSp7bY9GGW
BG2CLkHfWddZ38mwzqxNtCSG9LMVWApCCkLLLeUh5aGzFTP0s833WO8JXaivMy+3LA9Zal2r2ao9
aHrRfMD6veZb66/6JtNvVr8jGk1IZ0J7xMgRbg0JcVk0ViwYdWhwLq3GqtVqQiwWnU6rEBzhRnCY
HDTFcchBHQ00e68xxGvxWhvoMK822+K10DGWQxZqaSC99hlJLORGaniTxShpvV5Jl6obqBMG6fw6
qkOOPSlG3CzNro+U5qDxRYSbmvgfjWDA4X8zEma6cj7cdB4vDhFhposyBWH8cOQWyKOPiv8JiYhG
ZkAC0B7RrLKyVGhZBtRoGGr0RdD5L4DWf4G00afVf2Zfl0xNbJdMAwbxvaGZ5thQrlOuVFmlHlIY
khB44w1f10MYZqd49syzdk/O6mc3u0Vt85RXP/fEOj1f1TdP7hmfOmdERvOEbabE+MhJxiiW2LRu
+vw5M+ikxrd39ioYGvguaB9hAAT+BxKA5uC/pcrjn4b0CNIUDOIZaPmfSu4WDwdp1oZHhDDxpyCt
AIMiOkgr4XVFcpBWgVs5J0iroU6/JUhr2KvyzJzWwlhDhyCtg/GGVUFar6hXXA7SBhhtuNr6T3zP
Mw6Blv8vWjT+HKQpKC09g7QAKZa0IM3a8Iigs9wepBXIXxyklTDWUhakVRASYgrSasi1xQdpDS02
fhCktdDRVh6kdZierA/SemGU5UiQNkAHG/9bL8IEXJvO1ijT8v9YbdfKtILX2yNlWinXJ8i0Sqa7
yLQ6qKMAHdBRgA7oKEAHdBSgWRuegI4CdEBHATqgowAd0FGADugoQAd0FKADOgrQAR0F6ICOAnRA
R5zWtNmvVt5LX5nWtak3yHsfKdMmvhf7BJkOQdpiny7T1jb8oXycIG1rUx8u910s05HyXIExo9rw
ONvQ8TL/aplOkuknZbq9TO/itKrN+lVt5tK1qde17GUYzIZKKIXxUAwliCXYhjAMymS6P1TAVISa
IJcEvbFUhTR/FmN9ucwhYc1k7N8BqRy5vvh/OVJK68okGIotk+V/lzjAU411tyMOzNcRMvGVCu2D
VJpc2xN7TEY8BPtMwDXUyL2G4HjVCFUwA5/j5DVMxbZSmNK6kiqcV0Ku4uBMAf5ylJCEPXh/PuJU
SJZn4S3F8kwlwbGKsSbQc4o8It9BGa5+ijxiObbUyNxl8lxc6jXBGarlHZbIfWvk9qnyKBzzNVXI
aygP7qVSHpuvqEReVbU8G2/h/ONkHFj/dHk2SZ6h7arK5fFrsH2qXJ4pj10WnL00yFshjxWYu6V+
sjx2TVAiJVgKSOZmvhocs1SWSjniwNglwZrpsqS5rq5bSYWslypZopPl/nyl3DqmBHu1zFAi958R
nLU8uFPeFpDmdSmMR04+WqD2ulzLg9KtCO6kXOafLpeua7VattjJ8ur+3CZaPKe6dS+8bYo83vUx
qnCeScHVFgflXyLbtBS0+xaZjZPnniDXBvrPxJbyoA45z2TUfcBGKvA5AdtmBKUdGOG6LxfLugpY
hyTLsCS4/3JZa5NlnkrZzwLWOFXuGdhJW+sub7UsCdtnBTUzRV4Nt82A3qqDnjy5dR1T5NJ16625
Kd5U37S/kuAcY+URpsuSHneDbZbCNKxvkex0+V/iadnheNm2JdkGZsmyrZbtrkbWxoRWrfO1B/yd
+1JyqzdVB63sejwKtE6RNVIM98j9A6vm45bIrdctLTD7OFlalbKXzG7dRcvcvP9Mub1YlkRVcA7u
QwEp1sj9W1bcMnqlbENT5BjasrYOf4ir3W7QGo93E2T759rtBiOC87XEWh4ru+JTgkQcieugSvaH
gB+1azNWf7Tr66XnZTuvCvr9FHn0Sa06/p/G/IBeJgQjYWkwvl2PU4FRh+N5IMEgub8Ebnm+/vgc
iHOPly23RWLcNqtlaZcFR+sAA5BvGJ4efRB64444PRBref8++LxTrs/FmqH45D7QF6WYi6/+cu0w
0INGhmGy1Vb/iU1LrfWBFQc0VxnU7XVf+KN8AmdeBcqgSraOMpm7ZT8tkb/FnsbKrbORf3rrnCWt
MTQgu+ly3+uxrzToHTxCXY/XgThRHozN1cHYMUEepbQ19nLZFgRn41FkRjBmj2099QJz1vwbybTY
1szWKFga9OzSVt+pkuNUTTBujA/a/Z/Jq8XbucRK24xyPVr8cb5xQfvitjxWjsCBVY8NamZqcOQ/
01CCvKsbJRWI/H+0ij/O3BJDebQsljOaYpx1clDa1cFY9a/m7iDb/tQ28Xz2H3RRGsxm2npO4JQo
lldUKUuWn1vlsr/9Z51LQVuc2iaGtszLvX+cLOnyNqdVVZuMK7mVu6qN3V7PEf69pPjqpsjjt9hV
xQ3jzZT1P0nWZtto0hKHr3NWIG8gzkyXJc7HL2vdT2Bdba17SjByB+Qf8KrKoH1cj/A32tC/29F1
+7hd3vsfNdeS4/GzrTSYCQZ2E8grS2StTr1JB1U3yfv6yHx/FXLkHxeMqzPkHGwmtM3i/rP2W8YL
+GRpMNe48URuGe+PegxI63pmXCKP+Uc/btFY8U2yHv/fWu11Kf9xhhvzihtXVBrMlmvwhGwZgZ8y
PbG2PfCzsStkQBc8DyV8dsRSe7xvZCCkAr9zDoe8IGeq/K/iZeArQHeBdATeqzN0wrsJBz56mZyT
VOJ8KfiaKb86yGf7jR5fIke+f3VOcCpH9s6ZrXYROAXLg9GWr2mIHKEDZ+iAYJ5VEczguX8GTtIq
uaVc1sBQfF4/N7hV8ZsVzxP+e+tOkfn5/zCTgs8aOUJwXaXIZ88Y2UoC+USHVs7/2xlmyjlAgLf0
/2SWlraUm+yxdexhsytLxxeXlErbpGFlpVL/iqkVNVgl9a6oqqyoKq4pr5gqVU4u6SDlFNcU/wem
FD6YNLRi8nReUy3dPhX7dczMTG2Pj7QOUs/Jk6Uh5RPKaqqlIaXVpVUzSsf1rphaUzqFD1I1W6ou
xk5YXz5eGldaXT5harLUs6q8eLJUglzF5dg4paKqVCqbPqV4anl1jVRSVlxVXFKDHaprykuqpZqy
4qkSts2WKsZL5ThLZVXpuNKS0urqiqpqqXjqOKkYx59eUiaVB4cqnyrVTJ9aKs0srynD7qVYWzGO
9+b05GKcA/sX42Ja6mpmlk6tKS9F7hIkplfN7iDJIqmYUVpVjNurqSot/n+NXU1v20YQtSFdYsB/
odhTmwCOZLtOZBvowUiVQEgtF5YcoKdgRQ7JrUkus7s0w/yU3HLrIYf02AJFf0uP/Rd5M6JkOUk/
DpZFcr7em7ejkS8OBR6xQ1QDoudk3iYoU0pI6jzHW6kV6QuLJKaMax8Eqg9tTptMcHM8ZyFXmFIs
nL1GWI36oxqJSqksNjq1/LzJDBBmlFdgxKrU3JAYSJe1ykGHKgjclSaCua4qAo1lREiypNswWYpe
A0xBeauAzaPJOccoTC70hk43vssXwWNBqvYUL9mkVzUXW0fMv0osICMiQIVgypShO0Lfg9/jNnlQ
JjrCZaFT/caUCE0h2luSBvfY+CrXLadg75IaX+kKpcEkRonBeA7M5pWzhZVog5VWT5fQLimtc+1O
X8CPVXs4OD5U989N5Cz36IFYnc/l1y9q7tD7QrtrRvxvygeWFCIk6E00BdOrmfpRB/W1mp+riyQZ
SGGUe2oymA2mF/PJ08mTs/nkYqounqofJk/G09lYnT27HI/Px9P57s7uzjxDK1ZMc1s4MMABdZAu
rOvBybOp01XWSh4WP/O0aFVra/aMWKGori5jUR80AUGJrqEJAzXDXKeOiNU7UD/BLdOQjl3w0YNn
uFMMs9WwBAnNJu6OoyhAGwm4v62L225TEhORxdoP7YTiF3VAaJRpcQo3AH3jV0VB/Gsq1s6sUHWj
81ovoErtoapN74G6KkXn7QoFMHXNwZHQylcUmcREnyNXYLEUhbKvjmPDPYZynAyuPb7thFuZCJ8U
lZvCMCAkEbvGumu/FLZoWG7aBpqpF7nxGedBrCXdBcSN+tGqqlVLwXcM3U0kfEySW3A88V7V5CUN
ZmVEruwQuK5uMfaZrfMYWr0x1CxH3Gfw2Q6dJEyN+HYsrjGiLBnGUbjtMQPTXdXJl8NKyWuHblZ0
gZBHh1M2uJqdqYfq/vHR6IEaHRw/3D/a37937+o5bu4fHBwd4XX07UiNHj86eXSyu5OFUJ0Oh03T
DIpV4yNbbJ4JUt873TAXOIIoCpEu7QIndIqZZTHg9/iQOhMZrWZazobHJ9bx4T/EHmahyIdFKHVB
w8K/1DwnBnzzfzo0lOMu/bcLXw07HsUay5CVr8Fa/gVeK2tSu72LD/Ofcf23rAKr5zNZFnkl4qUl
7r3t/dr7o/cnfn7r/d57vxFLy2Kwuv5LYtOdXHQnmsTrf9U/6D/vP+t/h9cTWGv5ihh360i2/WH7
XW9LVjz+I4yT9YxjbG19BGe+sKYKZW5kc3RyZWFtCmVuZG9iago2IDAgb2JqCjw8L0ZpbHRlciAv
RmxhdGVEZWNvZGUKL0xlbmd0aCAzMTAKPj4gc3RyZWFtCnicXZLNboMwDIDveYocu0PFf7tKCKmj
ReKwH43tASAxXaQRohAOvP2CzTppkUD6Yjv+cAjK+lJr5XjwZkfRgOO90tLCNM5WAO/gpjSLYi6V
cBvhWwytYYEvbpbJwVDrfmR5znnw7qOTswvfneXYwQMLXq0Eq/SN7z7LxnMzG/MNA2jHQ1YUXELv
T3puzUs7AA+wbF9LH1du2fuav4yPxQCPkSOyEaOEybQCbKtvwPLQr4LnlV8FAy3/xR+pquvFV2sx
O/HZYXgOC6QKKS6R4hQpjYgORAlRSXRCSq5I2RNSGhJdkDLKPJ7QZ+uc/XrctaMI06KYDK50LlFC
kmlFmySSHKkL+aSbKzU7kHJKn5OdabPcDKjnOpz1Eu+TF7O1fuh40zjtdc5Kw/1nMKNZq9bnB3UA
oG4KZW5kc3RyZWFtCmVuZG9iagp4cmVmCjAgMjgKMDAwMDAwMDAwMCA2NTUzNSBmIAowMDAwMDY3
MjU5IDAwMDAwIG4gCjAwMDAwNjcwNDAgMDAwMDAgbiAKMDAwMDA3NDgyNiAwMDAwMCBuIAowMDAw
MDY3MzIyIDAwMDAwIG4gCjAwMDAwNzQ5NTcgMDAwMDAgbiAKMDAwMDA5NTExNCAwMDAwMCBuIAow
MDAwMDc1NDM1IDAwMDAwIG4gCjAwMDAwNzU2NTkgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBu
IAowMDAwMDAwMDYzIDAwMDAwIG4gCjAwMDAwMTM2NTYgMDAwMDAgbiAKMDAwMDAxMzc1MSAwMDAw
MCBuIAowMDAwMDEzODg5IDAwMDAwIG4gCjAwMDAwMTQwMzAgMDAwMDAgbiAKMDAwMDAwMDI4NSAw
MDAwMCBuIAowMDAwMDE0MTY0IDAwMDAwIG4gCjAwMDAwMjUzMTAgMDAwMDAgbiAKMDAwMDAyNTY5
MyAwMDAwMCBuIAowMDAwMDM5OTI2IDAwMDAwIG4gCjAwMDAwNDAzMDcgMDAwMDAgbiAKMDAwMDA2
NjYzNiAwMDAwMCBuIAowMDAwMDE0NjY2IDAwMDAwIG4gCjAwMDAwMTQ4ODYgMDAwMDAgbiAKMDAw
MDAyNjA1MyAwMDAwMCBuIAowMDAwMDI2Mjg4IDAwMDAwIG4gCjAwMDAwNDA5NjcgMDAwMDAgbiAK
MDAwMDA0MTE5MyAwMDAwMCBuIAp0cmFpbGVyCjw8L1NpemUgMjgKL1Jvb3QgOSAwIFIKPj4Kc3Rh
cnR4cmVmCjk1NDk1CiUlRU9G
--bcaec51820f2ff3a5c04e71fcd45--

From hovav@eng.ucsd.edu  Tue Sep 24 09:31:59 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92EC221F9F0A for ; Tue, 24 Sep 2013 09:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEQBl1F2Lqoh for ; Tue, 24 Sep 2013 09:31:55 -0700 (PDT)
Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 671FA21F9D96 for ; Tue, 24 Sep 2013 09:31:53 -0700 (PDT)
Received: by mail-qc0-f177.google.com with SMTP id x12so3202151qcv.8 for ; Tue, 24 Sep 2013 09:31:52 -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:sender:from:date:message-id:subject :to:content-type; bh=WVwbReWEcQ0LNO39kz1TGukm08uoAmlNDtd7F2Vketc=; b=biRtCOSpjxLhWzZ35qRVbK21eHFnAqGDhFk3+FcUV7yFZIWZNEHmCJdfWd2NjUh0Qr FcFZoc5BsaMyLcMV1dfFvgBpsn6ewAb9dyj69ACdbHh9U0aFwrN31XS1IUtegMBhVYs6 021hf8RFADs6mCIeHeoGaCLVlCYDwqWlvrABoAqlAcdwJus3ewoZtj1g3FxCF8z+5+Ad XIXE/zvwZLy3SbpH2EtpJiFUqKtPEDQ4qXWcG8qWBtZaY0J0HVVSEmcY0zYn/t8b4NXb Vj5geDxYX93xSsrXyZKdhoR1c/QpYUgLhcUmQey06pu5UNwTIW7QamyazDknlIHLcqwr Co9A==
X-Gm-Message-State: ALoCoQkg1iPMZtD5NUt0J+2pc6aGLJ2HYLfwEygwZW7YyLUJS1lo/CxxpI9f21TOEd4Okdm9CNFT
X-Received: by 10.49.39.39 with SMTP id m7mr27400914qek.60.1380040307733; Tue, 24 Sep 2013 09:31:47 -0700 (PDT)
MIME-Version: 1.0
Sender: hovav@eng.ucsd.edu
Received: by 10.49.117.135 with HTTP; Tue, 24 Sep 2013 09:31:26 -0700 (PDT)
From: Hovav Shacham 
Date: Tue, 24 Sep 2013 09:31:26 -0700
X-Google-Sender-Auth: Z7Nvj8VyAhVU1mdiJdqXvpDA2hE
Message-ID: 
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=047d7bdc1564518d2604e723ac69
X-Mailman-Approved-At: Tue, 24 Sep 2013 09:35:01 -0700
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 16:31:59 -0000

--047d7bdc1564518d2604e723ac69
Content-Type: text/plain; charset=ISO-8859-1

Peter Gutmann  writes:

It seems to be accepted by everyone except the WG chairs


I'm not thrilled with making changes to a fundamental part of the TLS
design through an extension.  TLS is too complicated to analyze already;
this doesn't help.

I would prefer an approach that deprecates existing suites in favor of
non-CBC authenticated encryption modes.

-hs.

--047d7bdc1564518d2604e723ac69
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Peter Gutmann <pgut001 at cs.auckland.ac.nz> writes:
<=
div>




It seems to be accepted by everyone except the WG chairs
<=
br>
I'm not thrilled with making changes to a fundamental par=
t of the TLS design through an extension. =A0TLS is too complicated to anal=
yze already; this doesn't help.




I would prefer an approach that deprecates existing sui=
tes in favor of non-CBC authenticated encryption modes.

-hs.


--047d7bdc1564518d2604e723ac69--

From prvs=29794e2de3=uri@ll.mit.edu  Tue Sep 24 09:40:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA7021F9195 for ; Tue, 24 Sep 2013 09:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.932
X-Spam-Level: 
X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.665,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FjabkbFsbLAh for ; Tue, 24 Sep 2013 09:40:50 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7968C11E8146 for ; Tue, 24 Sep 2013 09:40:39 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8OGbePh009525; Tue, 24 Sep 2013 12:40:36 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: Hovav Shacham 
Date: Tue, 24 Sep 2013 12:40:30 -0400
Thread-Topic: [TLS] padding bug
Thread-Index: Ac65RMfgXOgTqwa/Sxq3LMbsNe18vw==
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail=_CF8FA036-2603-4DAB-9C16-4C00947EB1B1"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-24_07:2013-09-23, 2013-09-24, 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-1305240000 definitions=main-1309240088
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 16:40:55 -0000

--Apple-Mail=_CF8FA036-2603-4DAB-9C16-4C00947EB1B1
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_1A9DC0A2-6E5F-447B-A0C1-87EFF200B808"


--Apple-Mail=_1A9DC0A2-6E5F-447B-A0C1-87EFF200B808
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

On Sep 24, 2013, at 12:31 , Hovav Shacham  wrote:

> Peter Gutmann  writes:
> It seems to be accepted by everyone except the WG chairs
>=20
> I'm not thrilled with making changes to a fundamental part of the TLS =
design through an extension.  TLS is too complicated to analyze already; =
this doesn't help.
>=20
> I would prefer an approach that deprecates existing suites in favor of =
non-CBC authenticated encryption modes.

I concur. Deprecate old, and require authenticated encryption.

--Apple-Mail=_1A9DC0A2-6E5F-447B-A0C1-87EFF200B808
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=iso-8859-1


On Sep 24, 2013, at 12:31 , Hovav Shacham <hovav@cs.ucsd.edu> wrote:

Peter Gutmann <pgut001 at cs.auckland.ac.nz> writes:
It seems to be accepted by everyone except the WG chairs

I'm not thrilled with making changes to a fundamental part of the TLS design through an extension.  TLS is too complicated to analyze already; this doesn't help.




I would prefer an approach that deprecates existing suites in favor of non-CBC authenticated encryption modes.

I concur. Deprecate old, and require authenticated encryption.

--Apple-Mail=_1A9DC0A2-6E5F-447B-A0C1-87EFF200B808--

--Apple-Mail=_CF8FA036-2603-4DAB-9C16-4C00947EB1B1
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 - http://gpgtools.org

iQEcBAEBAgAGBQJSQcB+AAoJEAUj5dJ7jKh7nDoH/2qU092mYoibwqkYVOkSwJ43
qUybp1kB3KidftWcLh9EvaqyzefEYts0pgovjs4C19DMTgbqS+XxJPAQpuyzobeY
ByZxopf/fgyn5nJKZVek6obSJ4x2OUSN2YkGpXnakX1kB3WUrzyX1nK1iKIoqLZG
yJtOgzsNFLuanQ6rF8kFQah18rRTxKpAtsSeZpzZDzPJxW8YY7cJpe0z6+uL2z/j
mjWsjRLCkdSNzl3mPFULDKrFyJKJiSlgthCmdAAuYdoUlCb5KqN7FFDo4hVLz3rf
sD5Sv4s3pGsCmek6rZYFIMQm5ygEexYn/hHMcCYhn7wcdE1Z3ICjzrpNhrNfXJU=
=mVIo
-----END PGP SIGNATURE-----

--Apple-Mail=_CF8FA036-2603-4DAB-9C16-4C00947EB1B1--

From prvs=29794e2de3=uri@ll.mit.edu  Tue Sep 24 09:48:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A924721F9926 for ; Tue, 24 Sep 2013 09:48:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.688
X-Spam-Level: 
X-Spam-Status: No, score=-5.688 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfWJSgf6SGuR for ; Tue, 24 Sep 2013 09:48:36 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4388821F8EA8 for ; Tue, 24 Sep 2013 09:48:35 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8OGfQtV015279; Tue, 24 Sep 2013 12:48:32 -0400
From: "Blumenthal, Uri - 0558 - MITLL" 
To: "c.kahlo@ageto.net" 
Date: Tue, 24 Sep 2013 12:47:19 -0400
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac65RbwNsJb/zWgpRD+74ryZpM1bpQ==
Message-ID: <7966A10B-9B28-4CF3-AB1C-74CCE617ED90@ll.mit.edu>
References:  <523c738f.0733cc0a.41a0.3096@mx.google.com> <523F383A.20803@drh-consultancy.co.uk> <523FE7B6.10501@gnutls.org> <524038fa.c402cd0a.127a.ffffc841@mx.google.com> <524047D1.7040601@gnutls.org> <52406827.c664cc0a.2ad0.ffffd7f7@mx.google.com>
In-Reply-To: <52406827.c664cc0a.2ad0.ffffd7f7@mx.google.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/signed; boundary="Apple-Mail=_CB6D0B73-9B00-4505-8F99-10A544240BFA"; protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-24_07:2013-09-23, 2013-09-24, 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-1305240000 definitions=main-1309240089
Cc: Team Neuer Personalausweis , "tls@ietf.org" 
Subject: Re: [TLS] Comments/Questions on	draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 16:48:41 -0000

--Apple-Mail=_CB6D0B73-9B00-4505-8F99-10A544240BFA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> We've had a lot of discussions about this. Strictly speaking if a non-
> truncated HMac reveals (too much) information of the internal state of
> the hash algorithm something totally went wrong with the hash =
function.

There are two issues. One is how much info the non-truncated MAC =
reveals. Another one is that it enables key guessing with just one valid =
message+MAC pair.

> As a result of this BSI TR-03116-4 chapter 2.3, 1st bullet states
> "do not use truncated_hmac". I'm sorry again for the lack of an =
english
> translation at the moment. The Federal Office for Information Security
> will probably provide one later.

I wonder what their reasoning is.

> In THEORY a truncated_hmac offers an option for attacks as only a =
fraction of the original HMac has to match.

Certainly.  It reduces the collision-creating space from square root of =
full MAC size to square root of truncated MAC size. For the benefit of =
requiring 2^(# of truncated bits) valid MACs to successfully forge a =
MAC.=20

With modern MACs and keys either attack should not be practical. Still, =
I personally prefer to truncate, though not necessarily all the way down =
to 96 bits.

--Apple-Mail=_CB6D0B73-9B00-4505-8F99-10A544240BFA
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 - http://gpgtools.org

iQEcBAEBAgAGBQJSQcIXAAoJEAUj5dJ7jKh7wAkH/3duSmexFVoDuOFlNyW2Gn8K
p//VlKTifLd6KFvSswV+p6mCkTkvVIYm7cO9vb3UAYx077Uc+4Jhm/GvG36FtK7d
Re0DlGmuMKn8bGgV0B0UhZi2o8uLY7RHFR/6FNmALSQU9xbnsuNYvNWVYnsduJc7
WgpoMwiP90KkN3mLBnNUQ9PbhrsPVwpdKRXjCTDZkWqqbXbfFZoatZDPeYPvp+k5
bZslt0XS1lMiEM9RKN3XV61zC3IUu523M7IRaTORR4FzJ0Ti+ZVVJeNyQR/Te3h8
Hf+uZWtBeOguZ5qKZQxJwyYWITNuBzVyTEd+Jn07YrprB2LAXt5capb5KD3ehro=
=3gaG
-----END PGP SIGNATURE-----

--Apple-Mail=_CB6D0B73-9B00-4505-8F99-10A544240BFA--

From mrex@sap.com  Tue Sep 24 10:16:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD10921F9193 for ; Tue, 24 Sep 2013 10:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.818
X-Spam-Level: 
X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_BIZOP=0.7]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3A2hFQ4oZaA for ; Tue, 24 Sep 2013 10:16:01 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DF3B521F991F for ; Tue, 24 Sep 2013 10:15:59 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8OHFsAB022665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Sep 2013 19:15:54 +0200 (MEST)
In-Reply-To: 
To: Hovav Shacham 
Date: Tue, 24 Sep 2013 19:15:54 +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: <20130924171554.6F0931A9A0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Sep 2013 17:16:05 -0000

Hovav Shacham wrote:
> Peter Gutmann  writes:
> >
> > It seems to be accepted by everyone except the WG chairs
> 
> I'm not thrilled with making changes to a fundamental part of the TLS
> design through an extension.  TLS is too complicated to analyze already;
> this doesn't help.

Where I agree is that it would be preferable to limit any fix
to the exact problem that has been identified (already by Vaudenay),
which is in how SSLv3&TLS use a Blockcipher in CBC mode
with "authenticate-pad-encrypt" rather than "pad-authenticate-encrypt".

"Making changes to a fundamental part of the TLS design through an
 extension" is a lame argument.  If this was really an issue, then we
would have to recomment against the existing rfc4492 approach to
the use of lliptic curve crypto in TLS in its entirety.

When we're concerned about the reconnect-fallbacks in Browsers
to an extension-less SSLv3 Clienthello--which btw. will currently
also prohibit the client to offer any AES-GCM cipher suites,
then we could define a signaling cipher suite for the
CBC-fix that can be safely included even in SSLv2 CLIENT-HELLO.


> 
> I would prefer an approach that deprecates existing suites in favor of
> non-CBC authenticated encryption modes.

This sounds like a marketeers approach to the problem, appreciating
the "new business opportunities".  But it is very ignorant about
software maintenance (for those vendors, which actually provide
maintenance), where the amount of code changes to the installed
base decides whether there is going to be an update produced
for the installed base.

There is nothing wrong with CBC, and it is a real pity that TLSv1.1
addressed&fixed only the running-IV problem, but entirely ignored
the authenticate-pad-encrypt that Vaudenay had explicitly described
as another problem.


What is available in Browsers is really just a small part of the problem.
For many communication scenarios, the end-to-end principle no longer applies,
and the distance between an end-users browser and the regional perimeter
gateway of the service provider is small in comparison to the distance
from the regional perimeter gateway (a reverse proxy for HTTP-over-TLS)
to the central/backend servers.  The end user has no knowledge and no
control what gets used behind the reverse proxy, and why should NSA try
to listen to the regional and short connection between a browser and
a regional gateway when it can instead pick up the contents on the regional
gateway, on the backend, or from the transnational connection in between,
an independent of whether that access is voluntary, compulsory or
surreptitious.


-Martin

From Andrei.Popov@microsoft.com  Tue Sep 24 10:41:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AB821F90CC for ; Tue, 24 Sep 2013 10:41:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0qjLLWL3R3W for ; Tue, 24 Sep 2013 10:41:08 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id D626121F88B4 for ; Tue, 24 Sep 2013 10:41:07 -0700 (PDT)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) with Microsoft SMTP Server (TLS) id 15.0.775.9; Tue, 24 Sep 2013 17:40:59 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.130]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.130]) with mapi id 15.00.0775.005; Tue, 24 Sep 2013 17:40:59 +0000
From: Andrei Popov 
To: "Blumenthal, Uri - 0558 - MITLL" , Hovav Shacham 
Thread-Topic: [TLS] padding bug
Thread-Index: AQHOuUODka+JHcxaQ6OFXY9dkTUeRJnVFwgAgAANcOA=
Date: Tue, 24 Sep 2013 17:40:59 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
x-forefront-prvs: 09796A1B83
x-forefront-antispam-report: SFV:NSPM; SFS:(189002)(199002)(24454002)(377454003)(19300405004)(53806001)(76482001)(83072001)(76786001)(19580405001)(65816001)(19580395003)(83322001)(80976001)(74502001)(47446002)(76796001)(54356001)(77096001)(79102001)(56776001)(76576001)(74662001)(16236675002)(15202345003)(51856001)(59766001)(77982001)(31966008)(63696002)(56816003)(54316002)(15975445006)(19609705001)(50986001)(81686001)(47976001)(74706001)(46102001)(74876001)(74316001)(33646001)(80022001)(69226001)(49866001)(81816001)(74366001)(81542001)(47736001)(81342001)(4396001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB194; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_abf83d95c8b544418115a5830a0127c9BL2PR03MB194namprd03pro_"
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 17:41:12 -0000

--_000_abf83d95c8b544418115a5830a0127c9BL2PR03MB194namprd03pro_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I agree that an approach that deprecates known weak ciphers in favor of (cu=
rrently deemed to be) strong ciphers is preferable. This is how the TLS pro=
tocol was designed to remain secure over time, and it does not rely on new,=
 optional extensions.

Besides, has someone completed a thorough analysis of all existing TLS ciph=
ers when used within the proposed "Encrypt-then-MAC" construction?

Cheers,

Andrei

From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Blume=
nthal, Uri - 0558 - MITLL
Sent: Tuesday, September 24, 2013 9:41 AM
To: Hovav Shacham
Cc: tls@ietf.org
Subject: Re: [TLS] padding bug

On Sep 24, 2013, at 12:31 , Hovav Shacham > wrote:


Peter Gutmann > wri=
tes:
It seems to be accepted by everyone except the WG chairs

I'm not thrilled with making changes to a fundamental part of the TLS desig=
n through an extension.  TLS is too complicated to analyze already; this do=
esn't help.

I would prefer an approach that deprecates existing suites in favor of non-=
CBC authenticated encryption modes.

I concur. Deprecate old, and require authenticated encryption.

--_000_abf83d95c8b544418115a5830a0127c9BL2PR03MB194namprd03pro_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I agree that an approach =
that deprecates known weak ciphers in favor of (currently deemed to be) str=
ong ciphers is preferable. This is how the TLS protocol
 was designed to remain secure over time, and it does not rely on new, opti=
onal extensions.


 <=
/p>

Besides, has someone comp=
leted a thorough analysis of all existing TLS ciphers when used within the =
proposed “Encrypt-then-MAC” construction?


 <=
/p>

Cheers,=



 <=
/p>

Andrei<=
/p>

 <=
/p>





From: tls-boun=
ces@ietf.org [mailto:tls-bounces@ietf.org]
On Behalf Of Blumenthal, Uri - 0558 - MITLL

Sent: Tuesday, September 24, 2013 9:41 AM

To: Hovav Shacham

Cc: tls@ietf.org

Subject: Re: [TLS] padding bug






 






On Sep 24, 2013, at 12:31 , Hovav Shacham <hovav@cs.ucsd.edu> wrote:<=
/p>














Peter Gutmann <pgut001 at 
cs.auckland.ac.nz> writes:






It seems to be accepted by everyone except the WG ch=
airs






 






I'm not thrilled with making changes to a fundamenta=
l part of the TLS design through an extension.  TLS is too complicated=
 to analyze already; this doesn't help.






 






I would prefer an approach that deprecates existing =
suites in favor of non-CBC authenticated encryption modes.








 




I concur. Deprecate old, and require authenticated e=
ncryption.








--_000_abf83d95c8b544418115a5830a0127c9BL2PR03MB194namprd03pro_--

From benl@google.com  Tue Sep 24 10:46:34 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D3C21F8CB4 for ; Tue, 24 Sep 2013 10:46:34 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vbrUM6CjfO8 for ; Tue, 24 Sep 2013 10:46:33 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id EA20F21F9CA4 for ; Tue, 24 Sep 2013 10:46:32 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so9474030ief.1 for ; Tue, 24 Sep 2013 10:46:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y1S2u2biWnHDsZgOSkBZchqwUJ0OW4ewj96I4KI82O4=; b=AcFyX/ApC2hE5lDt3aF3+OWierLefxbJVdUV5LvKNP6Klre1OgHM/fjtAvtoNd8Eld NXUBaWlzutplPsU/sWwHoZmIVgH3WoCF3GyzVKUn/TdYLQXvH6HtN3+r6uRgBH+UcUJg dcersnse7i5znEW0fDmy3eSNqugbMK3m0TBwFaroVCrQsYXqSO+teXgQpR0127oY6luR G3GaNYyJsvii+5vN04n6hJ+UGy6x3ass7XTIcyw0lDQPN6vZRGdiE3GfD2V9/AHcCxU+ i/4IHERSt70uxlYL/XZRka6L/AMrXWsFYD9+qLpMNS53pkvncDfS35ytZNk2inQxILok C1UA==
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=Y1S2u2biWnHDsZgOSkBZchqwUJ0OW4ewj96I4KI82O4=; b=mrI3+5+zvZGUg1Kr/LGGmlwNRNFcS0IS/6n9ue07+vzJIN+2TTaNO93FKsHR4r8GTQ p1lmrtaIn14eNuXl3mx23GQshjTIOqbR3x7N8RiqjGB9TEJjEh94guIUJWKrIbheL/Hp D367vBjly2UwpMsBrsZEIiw5TtmwjFmZPSYJGtOe8XZDz4a0tLrcepQe55dUJylWqqK6 rZ/fuiuJp9wVrQZ9lUEDJxOzWmjuoIacCrUmZ1XG2WYfHink+Kn+ok9r5fQegd0UWYGf Hag1X49loGEaSZAhtdUYwbvMiwvr1eQ1uJYQlYtfx45WfLOqFiG5caH4Ygmof3uIkPbn /WQA==
X-Gm-Message-State: ALoCoQnHQ8ubveU7tM3eYVIvOWaYAXw6jQu2V8W6WuweDe38sjNvCziCwY5TM98gbSTnTq+TvB6/1kxEVQ76yhai6ENgDf9dBdkZNW7ssvDgLcX7KRLHmPIztWoxxdIlhZEd+OJQJlxGHdnPKRgLrWdiOvbImdpw9qJWe7UQ7oKokb4g+oaD0DL1cEhwOQvwOsWOGczhix5l
MIME-Version: 1.0
X-Received: by 10.42.50.5 with SMTP id y5mr9621887icf.96.1380044791138; Tue, 24 Sep 2013 10:46:31 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Tue, 24 Sep 2013 10:46:30 -0700 (PDT)
In-Reply-To: 
References: 
Date: Tue, 24 Sep 2013 18:46:30 +0100
Message-ID: 
From: Ben Laurie 
To: Hovav Shacham 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 17:46:34 -0000

On 24 September 2013 17:31, Hovav Shacham  wrote:
> Peter Gutmann  writes:
>
>> It seems to be accepted by everyone except the WG chairs
>
>
> I'm not thrilled with making changes to a fundamental part of the TLS design
> through an extension.  TLS is too complicated to analyze already; this
> doesn't help.
>
> I would prefer an approach that deprecates existing suites in favor of
> non-CBC authenticated encryption modes.

That means requiring TLS 1.2, which is a far more complex update to
existing s/w than this change.

From hugokraw@gmail.com  Tue Sep 24 11:18:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1978921F9F5B for ; Tue, 24 Sep 2013 11:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.226
X-Spam-Level: 
X-Spam-Status: No, score=-1.226 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_OBFU_ALL=0.751]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbKbyK-UtcO1 for ; Tue, 24 Sep 2013 11:18:12 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E802A21F9F31 for ; Tue, 24 Sep 2013 11:18:11 -0700 (PDT)
Received: by mail-ob0-f174.google.com with SMTP id uz6so5406019obc.33 for ; Tue, 24 Sep 2013 11:18:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=LNj2qj5bOn6/crmVt5nluZJNkp5+g8UnTgszUvVlkps=; b=lidL9UQ8mimVKyQsW8B8qetXKiw94FRNaQ932UdXiMY1CFyHlll2CCdOBG4KKio8Nz F4Tedv2UmoRRLwk62Jmqawg+6eRp41gUUjNKD3WA5iEsqXhg/AWgG8CjHvNWwgu9kgkU 9y2wp0sBp94RKZ4/xsAkLKxLZauyOuXzZc2NjQcU8JCCj0IPnGxYwZNnaLGk6I0ElFY3 mwkQyB4oI6IwgBlNM4aJlGX+GvyK+H3LL7umClAzDPAsaZGWzVGi8daOYGs8HiIEfwAT 6y8cPEECyF+1O9J206+2y7rfuBUsHliagtSQt0NF/GKJHk2ViV4VG22aNVvBfK28BqIV 3tnA==
X-Received: by 10.60.134.14 with SMTP id pg14mr2452360oeb.66.1380046691148; Tue, 24 Sep 2013 11:18:11 -0700 (PDT)
MIME-Version: 1.0
Sender: hugokraw@gmail.com
Received: by 10.182.204.34 with HTTP; Tue, 24 Sep 2013 11:17:41 -0700 (PDT)
In-Reply-To: <20130924124848.450EC11E8121@ietfa.amsl.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567C914@uxcn10-6.UoA.auckland.ac.nz> <20130924124848.450EC11E8121@ietfa.amsl.com>
From: Hugo Krawczyk 
Date: Tue, 24 Sep 2013 14:17:41 -0400
X-Google-Sender-Auth: efqdwPo8UzkVo1cctztMWcVzFEY
Message-ID: 
To: "Blumenthal, Uri - 0558 - MITLL" 
Content-Type: multipart/alternative; boundary=047d7b472868ccaa6c04e725282b
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 18:18:13 -0000

--047d7b472868ccaa6c04e725282b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8BUri says:

> Isn't it enough already? Sufficient evidence, including publications by
> respected cryptographers, has been presented to adequately demonstrate
that
> truncating MAC has security advantages over including the entire output
of the
> hash function. That was the primary reason/justification for truncating
MAC in
> IPsec.

=E2=80=8BJust to set the historical record straight:

=E2=80=8BThe motivation for HMAC truncation in IPsec was saving some dummy =
padding
to obtain 32- and 64-bit alignments (in IPsec headers).=E2=80=8B

Once the benefit of such truncation for alignment purposes was identified,
a long debate took place regarding the security risks or benefits of HMAC
truncation. We eventually converged to the consensus that truncation posed
no known risks to HMAC and, moreover, the work of Preneel and van Oorschott
showed that in some cases it may even add to security. This led to IPsec
adopting truncated HMAC and also motivated the paragraph on truncated HMAC
in RFC 2104.

Since then there has been no significant new evidence supporting truncation
or non-truncation. In particular, the prevalent use of HMAC as a PRF (not
just MAC), also in TLS, assumes security for both truncated and
non-truncated HMAC.

One thing is for sure: The decision to truncate a MAC must be done on a
per-algorithm basis. For some MAC algorithms it may be fine to do so, for
others it may not.

Hugo

=E2=80=8BPS: Historians may want to consult OLD IPsec archives, for example
www.vpnc.org/ietf-ipsec/96.ipsec/msg00001.html =E2=80=8B

On Tue, Sep 24, 2013 at 8:48 AM, Blumenthal, Uri - 0558 - MITLL <
uri@ll.mit.edu> wrote:

> Guys,
>
> =E2=80=8B=E2=80=8B
> =E2=80=8B=E2=80=8B
> Isn't it enough already? Sufficient evidence, including publications by
> respected cryptographers, has been presented to adequately demonstrate th=
at
> truncating MAC has security advantages over including the entire output o=
f
> the hash function. That was the primary reason/justification for truncati=
ng
> MAC in IPsec.
>



>
> FWIW, the reasoning of that paper applies to SHA3 as well, though arguabl=
y
> that extra security measure is unnecessary there.
>
> P.S. Peter, I admire your ability to keep arguing well past the logical
> defeat. 
>
> --
> Regards,
> Uri Blumenthal                            Voice: (781) 981-1638
> Cyber Systems and Technology   Fax:   (781) 981-0186
> MIT Lincoln Laboratory                Cell:  (339) 223-5363
> 244 Wood Street                        Email: 
> Lexington, MA  02420-9185
>
> Web:  http://www.ll.mit.edu/CST/
>
>
>
> MIT LL Root CA:
>
>  
>
>
> DSN:   478-5980 ask Lincoln ext.1638
>
> ----- Original Message -----
> From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]
> Sent: Tuesday, September 24, 2013 08:31 AM
> To:  
> Subject: Re: [TLS] padding bug
>
> Nikos Mavrogiannopoulos  writes:
>
> >Since you are the one claiming that MAC truncation isn't necessary when
> all
> >existing protocols do it (even TLS does it on the Finished message MAC),
> it
> >may be better for you to present evidence that this isn't necessary.
>
> Before that, you'd have to present evidence that "all existing protocols =
do
> it".  As I've already pointed out, S/MIME doesn't, PGP doesn't, TLS
> doesn't,
> SSH doesn't, ... .  In fact of the major IETF application-level security
> protocols that I can think of, only IPsec does, and AFAIK (meaning based =
on
> long-ago discussions with one of the IPsec folks) that was done in order =
to
> fit the MAC into the fixed-size AH header (although there seems to be som=
e
> disagreement on the details).
>
> As I've also already pointed out, TLS has for some years now provided for
> MAC
> truncation to a range of sizes.  If anyone's really worried about this,
> they
> can request truncation to whatever size they prefer.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


=E2=80=8BUri says:

> Isn't it eno=
ugh already? Sufficient evidence, including publications by
> respect=
ed cryptographers, has been presented to adequately demonstrate that



> truncating MAC has security advantages over including the entire outpu=
t of the
> hash function. That was the primary reason/justification f=
or truncating MAC in
> IPsec.





=E2=80=8BJust to set the historical record straight:

=E2=80=8BThe motivation for HMAC truncation in IPsec was saving so=
me dummy padding to obtain 32- and 64-bit alignments (in IPsec headers).=E2=
=80=8B




Once the benefit of such truncation for alignment purposes w=
as identified, a long debate took place regarding the security risks or ben=
efits of HMAC truncation. We eventually converged to the consensus that tru=
ncation posed no known risks to HMAC and, moreover, the work of Preneel and=
 van Oorschott showed that in some cases it may even add to security. This =
led to IPsec adopting truncated HMAC and also motivated the paragraph on tr=
uncated HMAC in RFC 2104.




Since then there has been no significant new evidence =
supporting truncation or non-truncation. In particular, the prevalent use o=
f HMAC as a PRF (not just MAC), also in TLS, assumes security for both trun=
cated and non-truncated HMAC.




One thing is for sure: The decision to truncate a MAC =
must be done on a per-algorithm basis. For some MAC algorithms it may be fi=
ne to do so, for others it may not.




Hugo




=E2=80=8BPS: Historians may want to consult OLD IPsec archives, for example=
 
www.vpnc.org/ietf-ipsec/96.ipsec/msg00001.html =E2=80=8B<=
/div>



On Tue, Sep 24, 2013 at 8:48 AM, Blumenthal, Uri - 0558 - MITLL <uri@ll.mit=
.edu> wrote:



Guys,




=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
Isn't it enough already? Sufficient evidence, =
including publications by respected cryptographers, has been presented to a=
dequately demonstrate that truncating MAC has security advantages over incl=
uding the entire output of the hash function. That was the primary reason/j=
ustification for truncating MAC in IPsec.





=C2=A0



FWIW, the reasoning of that paper applies to SHA3 as well, though arguably =
that extra security measure is unnecessary there.



P.S. Peter, I admire your ability to keep arguing well past the logical def=
eat. <half-smile>



--

Regards,

Uri Blumenthal =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=A0Voice: (781) 981-1638

Cyber Systems and Technology =C2=A0 Fax: =C2=A0 (781) 981-0186

MIT Lincoln Laboratory =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Cell: =C2=A0(339) 223-5363

244 Wood Street =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0Email: <uri@ll.mit.edu>

Lexington, MA =C2=A002420-9185



Web: =C2=A0http://=
www.ll.mit.edu/CST/







MIT LL Root CA:



=C2=A0<https://www.ll.mit.edu/labcertificateauthority.html>=
;





DSN: =C2=A0 478-5980 ask Lincoln ext.1638




----- Original Message -----

From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]

Sent: Tuesday, September 24, 2013 08:31 AM

To: <tls@ietf.org&=
gt; <tls@ietf.org&=
gt;

Subject: Re: [TLS] padding bug



Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:



>Since you are the one claiming that MAC truncation isn't necessary =
when all

>existing protocols do it (even TLS does it on the Finished message MAC)=
, it

>may be better for you to present evidence that this isn't necessary=
.



Before that, you'd have to present evidence that "all existing pro=
tocols do

it". =C2=A0As I've already pointed out, S/MIME doesn't, PGP do=
esn't, TLS doesn't,

SSH doesn't, ... . =C2=A0In fact of the major IETF application-level se=
curity

protocols that I can think of, only IPsec does, and AFAIK (meaning based on=


long-ago discussions with one of the IPsec folks) that was done in order to=


fit the MAC into the fixed-size AH header (although there seems to be some<=
br>
disagreement on the details).



As I've also already pointed out, TLS has for some years now provided f=
or MAC

truncation to a range of sizes. =C2=A0If anyone's really worried about =
this, they

can request truncation to whatever size they prefer.



Peter.

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls


--047d7b472868ccaa6c04e725282b--

From msj@nthpermutation.com  Tue Sep 24 11:52:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2FCF11E8160 for ; Tue, 24 Sep 2013 11:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.424
X-Spam-Level: 
X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z6u1Ud8cRrw for ; Tue, 24 Sep 2013 11:52:51 -0700 (PDT)
Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by ietfa.amsl.com (Postfix) with ESMTP id CD27B11E8158 for ; Tue, 24 Sep 2013 11:52:50 -0700 (PDT)
Received: by mail-qc0-f174.google.com with SMTP id n9so3359508qcw.5 for ; Tue, 24 Sep 2013 11:52:50 -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=hb92/HngNotZSgZFnFIYbCMvYyGAwAfz80/TrNh8NtA=; b=AMTEl6EDKZyOXkO6fPPfnELYjtzWEagJ8SGRTuP7BNYUt0iMRd2qN2eW+Rrh7xzTEA cjVnIIM1vbvbZf/fgNJ2O4rQU09LxnSaS1MuihXV60yOfNwACtzYo8juAQKv0YXdLocH viR/JnkclCg4K8aYaPDwf0fwGDSJRyhZJG1dQkca200JAMr7vOgaAnhYb/3c0+HMZtU7 jqQ3lYV0168y7D7GIxndJmV4kY/lCS7wvDijLCSf71m3TUiDErsCnx74xY+PFL5nqdsc feKuVxEEj5hXW1Wh0AZPAZu9V1tTxwGcefrOP6TWcjO4xzt9W9V6HhIl6A24kn1H2/kx w0mA==
X-Gm-Message-State: ALoCoQnxsMWfYoB7RMJ2FOleQui0xkzWu41jLN7d8vF3Te9IS4FnzMHIHKb8fIr3GTNuAccq6HLz
X-Received: by 10.224.50.208 with SMTP id a16mr8268600qag.89.1380048770069; Tue, 24 Sep 2013 11:52:50 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id x8sm2745317qam.2.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 11:52:49 -0700 (PDT)
Message-ID: <5241DF82.1020601@nthpermutation.com>
Date: Tue, 24 Sep 2013 14:52:50 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Nico Williams 
References: <20130917124948.8DEFB1A974@ld9781.wdf.sap.corp> <52387927.4030007@nthpermutation.com>  <5240A8F0.2020001@nthpermutation.com> <20130923230057.GB15037@gmail.com>
In-Reply-To: <20130923230057.GB15037@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 18:52:57 -0000

On 9/23/2013 7:00 PM, Nico Williams wrote:
> On Mon, Sep 23, 2013 at 04:47:44PM -0400, Michael StJohns wrote:
>> On 9/23/2013 4:00 PM, Nico Williams wrote:
>>> On Tue, Sep 17, 2013 at 10:45 AM, Michael StJohns
>>>  wrote:
>>>
>>> But evidently you must care about the application plaintext.  Why not
>>> move the application into the HSM as well then?
>>>
>>> That deserves a tongue-in-cheek smiley, of course :^)
>> There are SSL/TLS accelerators that move a whole bunch more of the
>> crypto stuff inside the HSM, but PKCS11 is designed to be useful for
>> more than just TLS.
> That's not responsive though.  The fundamental question is: why should
> anyone treat session keys as more valuable than the plaintext they are
> used to protect?

1) Smuggling out the keys is easier than smuggling out the whole plaintext.
    a) Consider a web site running TLS, it extracts the session keys and 
posts them as a stego picture on the self same website (e.g. the photo 
of the company headquarters?).
2) We generally assume (for design purposes) that ciphertext may be 
captured without detection.
3) Attacker gathers picture and ciphertext together, extracts the keys 
and then extracts the plain text.

I generally assume that targets of value (e.g. banks, etc) have decent 
self-monitoring capabilities both at the network and system level.  That 
tends to suggest that less is more when it comes to exporting data from 
an attack.

>
> I think there is an acceptable answer, namely: where the TLS (or
> whatever) channel carries some data that is not trusted and where you
> want privilege separation, and where you really just don't trust the
> hardware furnishing the plaintext.  But you kinda have to say that
> that's what you're after, and then consider other issues that come up as
> a result.  For example, you might actually need a significant part of
> your application to live in the HSM.

Its not that I don't trust the "hardware" furnishing the plaintext, I 
don't trust any general purpose computer system to be immune from 
hacking attacks (and I'm of the firm belief that any one that does is 
delusional).  I would like to use HSM policy and security guarantees to 
reduce the impact of those attacks.  For TLS, this may ultimately come 
down to doing everything inside a HSM purpose built for TLS, but that's 
not the problem I'm trying to solve.

  I'm trying to get the policy controls of PKCS11 to do the correct 
things with derived keys (general problem, not just TLS).  The current 
TLS KDF math has holes in it that are inconsistent with this goal (e.g. 
any policy control absent doing all of the TLS negotiations inside the 
secure perimeter of an HSM [NOT a PKCS11 possibility] may be trivially 
defeated due to the way the key expansion step is defined).  I'd like to 
revise that math in a fairly straightforward way to close those holes 
and make it possible to apply appropriate policy controls.

Mike


>
>> Consider a specific field of use - 10s of Millions of smart grid
>> capable electric power meters.  Consider that I have a back office
>> system that talks to each and every one of them securely.  Consider
>> that I'm worried about insider threats with respect to reading and
>> controlling (e.g. remote disconnection of the meters) these devices.
>> Consider that I never ever ever want a control key to be present
>> outside of an HSM in plaintext form.  Consider that some smart grid
>> technologies are using TLS as the sole credential layer for
>> controlling substantial amounts of power.
> I've considered these things.  See above.
>
>> TLS should be designed so this is possible.  I believe it currently
>> has a limitation that makes this goal difficult or impossible to
>> achieve.
> Or you could design a better HSM.  Why isn't that an answer?  PKCS#11
> may not be the hammer that you're looking for.
>
> Nico


From simon@josefsson.org  Tue Sep 24 13:07:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAE121F9C37 for ; Tue, 24 Sep 2013 13:07:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvOwoDZ52ujM for ; Tue, 24 Sep 2013 13:07:09 -0700 (PDT)
Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id EBCE221F9AF0 for ; Tue, 24 Sep 2013 13:07:05 -0700 (PDT)
Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r8OK6t7Q010006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 24 Sep 2013 22:06:57 +0200
From: Simon Josefsson 
To: Adam Langley 
References:  <522D25B9.7010506@funwithsoftware.org> <56C25B1D-C80F-495A-806C-5DD268731CD4@qut.edu.au> <87zjrl21wp.fsf_-_@latte.josefsson.org> <522ED9A7.7080802@comodo.com> <877ge6tf1w.fsf_-_@latte.josefsson.org> 
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
X-Hashcash: 1:22:130924:tls@ietf.org::bicOeTJ6SV97VBBk:AXvc
X-Hashcash: 1:22:130924:code@funwithsoftware.org::CsKNXMQnmcflcYq4:A6Cd
X-Hashcash: 1:22:130924:agl@google.com::Qnxae1OP2Cx2BYWK:CFjc
Date: Tue, 24 Sep 2013 22:06:54 +0200
In-Reply-To:  (Adam Langley's message of "Tue, 24 Sep 2013 11:34:12 -0400")
Message-ID: <87y56mrnkx.fsf@latte.josefsson.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se
X-Virus-Status: Clean
Cc: Patrick Pelletier , "tls@ietf.org" 
Subject: Re: [TLS] Ed25519 for PKIX
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 20:07:10 -0000

Adam Langley  writes:

> On Tue, Sep 24, 2013 at 11:28 AM, Simon Josefsson  wrote:
>> Curve25519 is not directly usable with ECDSA, I believe, so OIDs aren't
>> sufficient.  Ed25519 is more relevant, however it uses the EdDSA
>> signature system instead of ECDSA so possibly more of RFC 5480 has to be
>> duplicated/modified in order for Ed25519 to work.
>
> Curve25519 and Ed25519 are the same curve - Ed25519 just uses the
> twisted Edward's isomorphism of curve25519 to make some calculations
> simpler and then builds a Schnorr-like signature scheme with it.
> (Curve25519 implementations typically use a Montgomery ladder which
> isn't suitable for some of the operations that the signature scheme
> needs.)
>
> (Indeed, one can use the Ed25519 code to perform fixed-base,
> curve25519 operations faster than the curve25519 code.)

Sure, I know, but I don't see how to get to signing PKIX certs anyway.
Ed25519 is used with EdDSA, not ECDSA.  RFC 5480 is about ECDSA, ECDH,
and ECMQV.  5480 does not specify how EdDSA is used with PKIX.

Are you saying that you would use the ECDSA vehicle of RFC 5480 for
EdDSA as well?  It seems like mild abuse of the acronyms, but I may be
mistaken.

Or perhaps my question really is: how do you think we'll get to signing
PKIX certs using EdDSA with the Ed25519 curve?

My (not published) Ed25519 PKIX draft define OIDs for Ed25519 but I'm
not convinced that is sufficient.

/Simon

From iam@kjro.se  Tue Sep 24 13:09:33 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4309B21F9C99 for ; Tue, 24 Sep 2013 13:09:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FH4pFH+cjSvE for ; Tue, 24 Sep 2013 13:09:26 -0700 (PDT)
Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB8B21F9CC5 for ; Tue, 24 Sep 2013 13:09:17 -0700 (PDT)
Received: by mail-pb0-f42.google.com with SMTP id un15so5048391pbc.15 for ; Tue, 24 Sep 2013 13:09:17 -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:openpgp:content-type :content-transfer-encoding; bh=pgMODjZ74qoathmf/e+V/vbNH5Z2giADwPQSR0bsRqs=; b=Xd5eLmc4FMao9Ai6Hv+SC0gap11jLiNLw7U3+FDukbrQgKAjIplHOkeeUmiF+QbM5I 5RU5adfVdTDz/xlul4tE2qcdcNxkEjRYMHtmErqqEr4v5HhUxIGqXwdq67hCe99qWyDT gKtdDzMPF/BI4OdyMqS6vlPF35Gqr/K7GAILbtHKO3m7HC3vNdxiwbFnxESi3QExixEr 7IbdkNq8riFuPPgR4ZVwQEIVGlc12ikI3mjx8BCHtkDVZkeE1rqkGFSb3EaW2+wrKKUA Ye/f5w9iboQJ2WlKdxoXuqxVjXrwo3Z3EjhpFaBnFqoU3CDZMEs3FQnMYEKDiw30O4X/ ucpg==
X-Gm-Message-State: ALoCoQk6bCRKDlwyt/766ZdMRFJBpOh8CDQ85eXk2c8ThH24+tix5//Z+tQswuwLw34j+VkYAwHC
X-Received: by 10.66.163.199 with SMTP id yk7mr12960707pab.136.1380053357266;  Tue, 24 Sep 2013 13:09:17 -0700 (PDT)
Received: from [192.168.10.105] ([66.18.212.57]) by mx.google.com with ESMTPSA id fl3sm47801012pad.10.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 13:09:16 -0700 (PDT)
Message-ID: <5241F16B.5060200@kjro.se>
Date: Tue, 24 Sep 2013 16:09:15 -0400
From: Kelly John Rose 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C73556760B8@uxcn10-6.UoA.auckland.ac.nz> <52411e4b.8712cd0a.074a.fffff2c8@mx.google.com>
In-Reply-To: <52411e4b.8712cd0a.074a.fffff2c8@mx.google.com>
X-Enigmail-Version: 1.5.2
OpenPGP: id=00468DE1; url=https://kjro.se/iamkjrose.gpg
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 20:09:33 -0000

If I may be permitted to vote, I would say A.

On 24/09/2013 1:08 AM, Christian Kahlo wrote:
>> Could people please indicate on the list whether they'd prefer option
>> (A), fix the problem with EtM, or option (B), which appears to be "do
>> nothing", or at least "delay indefinitely", which amounts to the same
>> thing.
> [X] A
>
> -Christian
>

-- 
Kelly John Rose
Mississauga, ON
Phone: +1 647 638-4104
Twitter: @kjrose

Document contents are confidential between original recipients and sender.


From ekr@rtfm.com  Tue Sep 24 13:11:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58BE021F9CE3 for ; Tue, 24 Sep 2013 13:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Oj9AX4V4QjI for ; Tue, 24 Sep 2013 13:11:41 -0700 (PDT)
Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2B221F9928 for ; Tue, 24 Sep 2013 13:11:41 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id p19so3463991qcv.11 for ; Tue, 24 Sep 2013 13:11:41 -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:content-type; bh=VgJb/zJcyk0wDsJwETNjoJ3DdiQv0mwK3n0cvaI0YhQ=; b=Cnwv9AfY8Qe/4BCmqBMIqNTXhCMM3VnHFtM3wwNrm7LMWzUXzF26etBtDzsyOteAqY frZ90ghRs2nT4MpysEDEo0/8Do7UjJfmyFH7YUEpsXzbM7i96yPKD0VTNF9iMLHFQ0T2 OlVHxm1frld1e38u10T7EuniL5piqgu3h2m8f8lMAWwU+ABSSpDfHMmyKb4f0vVbPb3v M+b85tlx4MG5Ie/ZF8YYEaY9oCBk7Uqr5KPY3+yF7mfqbtuIzd9Y7cOBPKVn5890pqjw 42VItzFZzstQCMvnPlUS29xIMBYvpr0IdHrDvnHpuWmBXVrEoMr/snOexLqlgp7mNcWc NSNg==
X-Gm-Message-State: ALoCoQm47Q3YZiMU8EYWnLBISvVmzu9Lkt9OpPvYNpI8uOJu4hi63lcwjmJnpeFpkReBiEBicJsw
X-Received: by 10.229.219.199 with SMTP id hv7mr18657776qcb.15.1380053500934;  Tue, 24 Sep 2013 13:11:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.42.68 with HTTP; Tue, 24 Sep 2013 13:11:00 -0700 (PDT)
X-Originating-IP: [141.212.109.200]
In-Reply-To: 
References: 
From: Eric Rescorla 
Date: Tue, 24 Sep 2013 13:11:00 -0700
Message-ID: 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11344874b1dae104e726bee9
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 20:11:46 -0000

--001a11344874b1dae104e726bee9
Content-Type: text/plain; charset=ISO-8859-1

Peter,

Do you think you could address the questions I asked below?

Thanks,
-Ekr



On Fri, Sep 20, 2013 at 8:52 AM, Eric Rescorla  wrote:

> Peter,
>
> After reviewing this document I have a few comments/questions:
>
> - Because this draft relies on extensions, it seems not to resist
>   active attack when clients do insecure version fallback
>   (see for instance:
> http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
>   The existing attacks appear to principally be active attacks on the
> browser
>   environment, which is where fallback tends to happen.
>
> - Maybe I am misreading the draft, but I'm unclear on how you get
>    the TLSCompressed.length for the MAC computation in Section 3.
>    Does this have the same issue as was raised for McGrew's CBC AEAD
>    draft?
>
> Am I missing something here?
>
> Thanks,
> -Ekr
>
>

--001a11344874b1dae104e726bee9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Peter,

Do you think you could address t=
he questions I asked below?

Thanks,
-Ekr=







On Fri, Sep 20, 2013 at 8:52 AM, Eric Rescorla <ekr@rtfm.com> wro=
te:




Peter,

After reviewing this document I =
have a few comments/questions:

- Because this draf=
t relies on extensions, it seems not to resist
=A0 active attack =
when clients do insecure version fallback





=A0 The existing attacks=
 appear to principally be active attacks on the browser





=A0 environment, which is where fallback tends to happen.
- Maybe I am misreading the draft, but I'm unclear on how =
you get
=A0 =A0the TLSCompressed.length for the MAC computation i=
n Section 3.





=A0 =A0Does this have the same issue as was raised for McGrew's CB=
C AEAD
=A0 =A0draft?

Am I missing someth=
ing here?

Thanks,
-Ekr










--001a11344874b1dae104e726bee9--

From juraj.somorovsky@rub.de  Tue Sep 24 14:22:07 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E343811E8165 for ; Tue, 24 Sep 2013 14:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wujWRJvCMs8l for ; Tue, 24 Sep 2013 14:22:01 -0700 (PDT)
Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id 00DE421F9CC5 for ; Tue, 24 Sep 2013 14:21:53 -0700 (PDT)
X-Queued: (qmail 12462 invoked by alias); 24 Sep 2013 21:21:50 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 12399 invoked by uid 109); 24 Sep 2013 21:21:49 -0000
X-Qmailscanner: from 134.147.42.227 by mx4.rz.ruhr-uni-bochum.de (envelope-from , uid 103) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88.   Clear:RC:1(134.147.42.227):.  Processed in 0.055776 secs); 24 Sep 2013 21:21:49 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx4.rz.ruhr-uni-bochum.de with SMTP; 24 Sep 2013 21:21:49 -0000
X-Queued: (qmail 8398 invoked by uid 992); 24 Sep 2013 21:21:49 -0000
X-Qmailscanner: from 178.201.6.234 (7Cil8M2CiUy55WCzq+DQ4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de (envelope-from , uid 0) with qmail-scanner-2.01  (sophie: 3.06/3.45.0/4.91.  Clear:RC:1(178.201.6.234):.  Processed in 0.023142 secs); 24 Sep 2013 21:21:49 -0000
Received: from ip-178-201-6-234.unitymediagroup.de (HELO ?192.168.0.103?) (7Cil8M2CiUy55WCzq+DQ4w==@178.201.6.234) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 24 Sep 2013 21:21:49 -0000
Date: 24 Sep 2013 23:21:47 +0200
Message-ID: <5242026B.1000303@rub.de>
From: "Juraj Somorovsky" 
To: "Michael StJohns" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References:  <5240A4F9.2020308@nthpermutation.com>
In-Reply-To: <5240A4F9.2020308@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 24 Sep 2013 21:22:08 -0000

On 09/23/2013 10:30 PM, Michael StJohns wrote:
>> TL;DR: you can recover low entropy GCM plaintexts if the same key is used
>> in a mode like CBC.
> 
> Right.  But you can't recover the key.
> 
> Let me reiterate the threat model:
> 
> 1) All keys are kept in an HSM (not supposed to be extracted - but TLS
> KDF trivially allows this)
> 2) Attacker has access to use the keys (e.g. either has HSM credentials,
> or has hacked the program using the HSM that has HSM credentials - the
> TLS stack for example).
You are right, the attacks do not apply to your scenario since they do
not recover the key.

...Sorry, my last one attack scenario :) ...assuming you are going to
use your KDF taking as input the key length. This would mean you would
generate the same key for AES-128 and RC4? (both have the key lengths of
16 bytes)

If the user would use AES-128, the attacker could force the HSM to
regenerate a new key for RC4 (in this case the same key as for AES-128
would be generated) and generate the RC4 keystream. Afterwards, he could
run one of the attacks against RC4 to learn the original RC4 key (and
thus also the AES key).

Does it make sense?
Thanks
Juraj

From wtc@google.com  Tue Sep 24 18:50:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 295A911E80FD for ; Tue, 24 Sep 2013 18:50:03 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1AB3U5Lyamt for ; Tue, 24 Sep 2013 18:50:02 -0700 (PDT)
Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4C35E11E8100 for ; Tue, 24 Sep 2013 18:50:01 -0700 (PDT)
Received: by mail-qc0-f179.google.com with SMTP id l4so3718010qcv.10 for ; Tue, 24 Sep 2013 18:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ujKTGjiLnMBNTCQBuUEbhG18Gdg7yyW/ts8XyNsVUQ8=; b=VNwkKkRiqCH348y3GDnxcgaJDPZ4vf0u8AcDGobFWINSW0L8lPvLFOfQ0uMCuhIpzm qjrHMzfGcOOZAI4ZkJJAfIvCcbvSyEGCwYARL3xxu5buKcUAz2cCxV3TzAcsvhsoBIFv 5tUbi0b293EJLrV5325GVw0qRE4IDDdfY2f9BobQTGnNGFevJNHtsg2m9GdVUGi27ZOf pg3V7sFtWW1fFXgNRsbm4mC6IIMgZ4gRQ4rM0OpfrCmKy+Q42gxzOyYp6bZeQIgx5gkB X2E/mPMfXA1sv30UBbtS0INkFBnOd4Sa49I9LdUqKdQ3jiU9hQ/FeKavk6Gokdy6Vgie nXqw==
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=ujKTGjiLnMBNTCQBuUEbhG18Gdg7yyW/ts8XyNsVUQ8=; b=KEZLlK9qGrW6GJY+VQfKHA6LhzHobptsmJdRhgm9pBL8CFJfGSIR1CAHLgi5mEodcn 8EhIIzh4OqixuFujmsWLyxYTRpPrO+4JRwAHSWuwBcfRuIs0xHRNj7yfi91EMbNmYZ8x He1bfd8TAk7SCQ3n5xXMcQE8E1zDFbRiGghbGgRZ3PnQiYpPDQdQ5vWJzxNuqZAAWASL DUxc+86V2tN0gMu+zpt6A8MEd02uAUgfZ9UU6iElbh/3ad3jOoJ+H77FVa8v235GRAwo iBPX2G4BBYRd+pHwXQlYlPZiIAzYfAghqx4JAIQK4iMs7e1j3Y8UERbeJO3epP89L1Q2 E9fA==
X-Gm-Message-State: ALoCoQnMiLZ12vNJ0kyXX9ZgPd2srohZc7izkkKUC83icDSwiZUKl7FjnnZ0uW5cHaJ2xRKDFQev6Tb/CjqGLgCddyg0w8dSmPxEGBHM/Dd02lylCPMYKr9YvH/sQWUSHzIzAffd/HJB9jl5S1ImrXqqxS14x3eFYqFo7GZczLX4mfX0ihkYkIIh1wl0yUgs3NwQY347NbYQ
MIME-Version: 1.0
X-Received: by 10.224.166.2 with SMTP id k2mr13161529qay.88.1380073798634; Tue, 24 Sep 2013 18:49:58 -0700 (PDT)
Received: by 10.229.176.133 with HTTP; Tue, 24 Sep 2013 18:49:58 -0700 (PDT)
In-Reply-To: <523DF3AF.6060208@nthpermutation.com>
References: <523DF3AF.6060208@nthpermutation.com>
Date: Tue, 24 Sep 2013 18:49:58 -0700
Message-ID: 
From: Wan-Teh Chang 
To: Michael StJohns 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 01:50:03 -0000

On Sat, Sep 21, 2013 at 12:29 PM, Michael StJohns
 wrote:
> Following up on the previous discussion, I propose the following changes to
> the key derivation steps for TLS.  This adds a length field for each key
> being derived to the PRF seed value.  For the pre-master to master secret
> derivation, this is a single 32 bit length field of value 48.  For the
> master to key expansion derivation, these are 6 32 bit fields each
> representing the length of one of the keys (or IVs to be derived).
>
> By doing this, varying the length of any one of the sub keys completely
> changes the key stream.  That prevents the type of attack described by
> Juraj.

I like this proposal!

> I spec'd 6 fields for the key expansion derivation instead of three to make
> this completely general - and to allow it to be used with the key material
> export RFCs.

Could you elaborate on how your proposed change affects the TLS keying
material exporter RFCs?

Thanks,
Wan-Teh Chang

From msj@nthpermutation.com  Tue Sep 24 20:09:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD3311E81A4 for ; Tue, 24 Sep 2013 20:09:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level: 
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[AWL=0.032,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9YR+PlwAmdR for ; Tue, 24 Sep 2013 20:09:04 -0700 (PDT)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) by ietfa.amsl.com (Postfix) with ESMTP id CFA2411E8106 for ; Tue, 24 Sep 2013 20:08:51 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id c9so3812272qcz.28 for ; Tue, 24 Sep 2013 20:08:50 -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=jgvjnjenvmN0YGb7CRUquCzfj4qQ6LFHD+qWVJZL8mE=; b=mq2tCJqLpTYm8wJDlllMGAYqDYELUa0YU2LqA0TpIC8riDwTyMfA4Wc0ozk9gDrxM6 foXSL5iTtgEl4SjX9GBi1uOW+i3epPFFcOrVIRCxpPul3xDoDIVVvDd4PhNPxyGjb7un niKn+/8km+hT6WcsLZjAU0HHv8q+Bdlcgs/UCoE1eAf3FvQdwpk/5lBN0L9eBzh43q2H VYkTIeRlUo+KXz1KxyZgpHPYzBLxMevNxal/QfFXAV8M+qGTQFiWEYCDThUMvuLOYUNu nLx1uNqtx1rjMduVS47U7TJI/keoc4ucFjUs5d0AzzzylQQtHESJ100nmcsXgNz7GICo LP1Q==
X-Gm-Message-State: ALoCoQkYcRljY94FMUx1U4dRFxLJHFxJFf5jnBo5+uP5X3B1iVwZX50mFRv/Gl62rb1uVutXKcfj
X-Received: by 10.229.30.7 with SMTP id s7mr41645527qcc.7.1380078529241; Tue, 24 Sep 2013 20:08:49 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id u8sm58483279qef.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 20:08:48 -0700 (PDT)
Message-ID: <524253C1.7090509@nthpermutation.com>
Date: Tue, 24 Sep 2013 23:08:49 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Juraj Somorovsky 
References:  <5240A4F9.2020308@nthpermutation.com> <5242026B.1000303@rub.de>
In-Reply-To: <5242026B.1000303@rub.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 03:09:10 -0000

On 9/24/2013 5:21 PM, Juraj Somorovsky wrote:
> On 09/23/2013 10:30 PM, Michael StJohns wrote:
>>> TL;DR: you can recover low entropy GCM plaintexts if the same key is used
>>> in a mode like CBC.
>> Right.  But you can't recover the key.
>>
>> Let me reiterate the threat model:
>>
>> 1) All keys are kept in an HSM (not supposed to be extracted - but TLS
>> KDF trivially allows this)
>> 2) Attacker has access to use the keys (e.g. either has HSM credentials,
>> or has hacked the program using the HSM that has HSM credentials - the
>> TLS stack for example).
> You are right, the attacks do not apply to your scenario since they do
> not recover the key.
>
> ...Sorry, my last one attack scenario :) ...assuming you are going to
> use your KDF taking as input the key length. This would mean you would
> generate the same key for AES-128 and RC4? (both have the key lengths of
> 16 bytes)
>
> If the user would use AES-128, the attacker could force the HSM to
> regenerate a new key for RC4 (in this case the same key as for AES-128
> would be generated) and generate the RC4 keystream. Afterwards, he could
> run one of the attacks against RC4 to learn the original RC4 key (and
> thus also the AES key).
>
> Does it make sense?

Yes.  But preventing that requires a different/additional set of policy 
protections to be built into PKCS11.  I'm working on them in the PKCS11 
group.  The general idea is provide a way to specify mandatory policies 
(e.g. key types) for keys derived from other keys.  That problem is 
broader than just the KDFs used for TLS.

In some ways, the right answer to the above threat is to prevent the 
module from actually providing RC4 based keys and mechanisms.  Ah well....

Mike



> Thanks
> Juraj
>
>


From msj@nthpermutation.com  Tue Sep 24 20:36:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF35D21F9339 for ; Tue, 24 Sep 2013 20:36:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.57
X-Spam-Level: 
X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pm5zmREYOpdJ for ; Tue, 24 Sep 2013 20:36:13 -0700 (PDT)
Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7DA21F9323 for ; Tue, 24 Sep 2013 20:36:11 -0700 (PDT)
Received: by mail-qe0-f48.google.com with SMTP id nd7so3768910qeb.21 for ; Tue, 24 Sep 2013 20:36:10 -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=Gi0kx4NLnBTDcFiHt97LStjSHXt/fiBwplV28eZe3p4=; b=C1m+6bN5OBbYcgA93CgvPWgaC/2t9yFcDJj5RvzS3WRD6NXtLsU648BXNiIc7oBMbK NyTt6CDhAChJN23qXk7XOfanNNZLTJ90RQ/bjBDdB3qQojq/KJVlyK87vBAxCYDLpPt9 XdFpSzQXCLhx99+9W5O9fZz2f4Un5rFL/GQflEpPI768tnP4hxDC/yobkOcMmhL7rgqF ugB7KG2ozP1w4JPslHwIkm4z5b/pd9fDg1ciFZTO2v3hV54OADIsNBBVNawz5QFKLsVF n3XbDUbVOb5aRZysv7RTj2plwxPDZDHa598In281VnW7l8bNveWCKnzJYhS0RsUOC0Vi 5//A==
X-Gm-Message-State: ALoCoQn2ZU4AKAwvyX9vsc02wL/99Jn2FAzs+vcfpP92C10KhrZar91kHk2tiW4MjEVCiXL11Doa
X-Received: by 10.229.127.74 with SMTP id f10mr41867342qcs.16.1380080170806; Tue, 24 Sep 2013 20:36:10 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id u4sm61448928qat.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 24 Sep 2013 20:36:10 -0700 (PDT)
Message-ID: <52425A2A.3060401@nthpermutation.com>
Date: Tue, 24 Sep 2013 23:36:10 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Wan-Teh Chang 
References: <523DF3AF.6060208@nthpermutation.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 03:36:18 -0000

On 9/24/2013 9:49 PM, Wan-Teh Chang wrote:
>> >By doing this, varying the length of any one of the sub keys completely
>> >changes the key stream.  That prevents the type of attack described by
>> >Juraj.
> I like this proposal!
>
>> >I spec'd 6 fields for the key expansion derivation instead of three to make
>> >this completely general - and to allow it to be used with the key material
>> >export RFCs.
> Could you elaborate on how your proposed change affects the TLS keying
> material exporter RFCs?
>
> Thanks,
> Wan-Teh Chang
>
>

Simply by adding the length fields to the KDF inputs used with the key 
material exporters.  So if an exporter needs 4 keys, there are 4 length 
values, 2 keys, 2 length values etc.   That makes what gets passed into 
the KDF the secret, the public values including the label,  and the 
length of each key and that construct can be used for the pre-master to 
master, master to key expansion and for any key exporters.  This is just 
an off-the-cuff suggestion at this point.

One other alternative is to only provide lengths for keys - anything 
after the end of the keys is public data.   That allows the 
private/public division  of data consistent with the current model 
without having to build a special function just for the key-expansion 
step.  And -  if you run this without providing any key lengths, you end 
up with the same key stream as the old function -and that simplifies the 
PKCS11 implementation.

Mike








From juraj.somorovsky@rub.de  Wed Sep 25 00:33:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B275C21F9F34 for ; Wed, 25 Sep 2013 00:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level: 
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VHp5-00C0VK for ; Wed, 25 Sep 2013 00:33:40 -0700 (PDT)
Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id 130AC21F9F26 for ; Wed, 25 Sep 2013 00:33:39 -0700 (PDT)
X-Queued: (qmail 1864 invoked by alias); 25 Sep 2013 07:33:38 -0000
X-RUB-Notes: Internal
X-Queued: (qmail 1611 invoked by uid 109); 25 Sep 2013 07:33:37 -0000
X-Qmailscanner: from 134.147.42.227 by mx4.rz.ruhr-uni-bochum.de (envelope-from , uid 103) with qmail-scanner-2.01 (sophie: 3.05/3.42/4.88.   Clear:RC:1(134.147.42.227):.  Processed in 0.055952 secs); 25 Sep 2013 07:33:37 -0000
Received: from mail1.mail.ruhr-uni-bochum.de (134.147.42.227) by mx4.rz.ruhr-uni-bochum.de with SMTP; 25 Sep 2013 07:33:36 -0000
X-Queued: (qmail 21827 invoked by uid 992); 25 Sep 2013 07:33:36 -0000
X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUxgePeMW6VfJQ==@134.147.40.78) by mail1.mail.ruhr-uni-bochum.de (envelope-from , uid 0) with qmail-scanner-2.01  (sophie: 3.06/3.45.0/4.91.  Clear:RC:1(134.147.40.78):.  Processed in 0.025836 secs); 25 Sep 2013 07:33:36 -0000
Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUxgePeMW6VfJQ==@134.147.40.78) by mail1.mail.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 25 Sep 2013 07:33:35 -0000
Date: 25 Sep 2013 09:33:35 +0200
Message-ID: <524291CF.5060902@rub.de>
From: "Juraj Somorovsky" 
To: "Michael StJohns" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
References:  <5240A4F9.2020308@nthpermutation.com> <5242026B.1000303@rub.de> <524253C1.7090509@nthpermutation.com>
In-Reply-To: <524253C1.7090509@nthpermutation.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] TLS and hardware security modules - some issues related to PKCS11
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 07:33:46 -0000

On 09/25/2013 05:08 AM, Michael StJohns wrote:
>> ...Sorry, my last one attack scenario :) ...assuming you are going to
>> use your KDF taking as input the key length. This would mean you would
>> generate the same key for AES-128 and RC4? (both have the key lengths of
>> 16 bytes)
>>
>> If the user would use AES-128, the attacker could force the HSM to
>> regenerate a new key for RC4 (in this case the same key as for AES-128
>> would be generated) and generate the RC4 keystream. Afterwards, he could
>> run one of the attacks against RC4 to learn the original RC4 key (and
>> thus also the AES key).
>>
>> Does it make sense?
> 
> Yes.  But preventing that requires a different/additional set of policy
> protections to be built into PKCS11.  I'm working on them in the PKCS11
> group.  The general idea is provide a way to specify mandatory policies
> (e.g. key types) for keys derived from other keys.  That problem is
> broader than just the KDFs used for TLS.
I understand that it is not that easy...

Are these policies going to restrict the key usage based on the KDF input?
If yes, what speaks against to use a derivation concept that takes as
input algorithm name the key is used for?

The key derivation based on the algorithm name (+ its key length) brings
the same security as yours. In addition, once your PKCS11 policy concept
is ready and implemented in HSMs, one could define new policies based on
the input of the KDF and restrict the usage of the derived keys.
> 
> In some ways, the right answer to the above threat is to prevent the
> module from actually providing RC4 based keys and mechanisms.  Ah well....
Yes, it would be possible to define only a set of secure ciphers (and
thus remove RC4)...however, what happens if one of these secure ciphers
is broken and thus affects security of a different one, which
accidentally uses the same key length?

Best
Juraj

From nick.lewis@usa.g4s.com  Wed Sep 25 01:33:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FE321F9F34 for ; Wed, 25 Sep 2013 01:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.997
X-Spam-Level: 
X-Spam-Status: No, score=-0.997 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXVUdDcWgohC for ; Wed, 25 Sep 2013 01:33:07 -0700 (PDT)
Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.166]) by ietfa.amsl.com (Postfix) with ESMTP id E9A9E21F9FAE for ; Wed, 25 Sep 2013 01:33:01 -0700 (PDT)
Received: from [85.158.137.3:43828] by server-6.bemta-3.messagelabs.com id 4B/B5-04812-BBF92425; Wed, 25 Sep 2013 08:32:59 +0000
X-Env-Sender: nick.lewis@usa.g4s.com
X-Msg-Ref: server-5.tower-38.messagelabs.com!1380097978!14566862!1
X-Originating-IP: [89.206.228.155]
X-StarScan-Received: 
X-StarScan-Version: 6.9.12; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 29244 invoked from network); 25 Sep 2013 08:32:58 -0000
Received: from unallocated.star.net.uk (HELO gbtwk10s037.Technology.local) (89.206.228.155) by server-5.tower-38.messagelabs.com with RC4-SHA encrypted SMTP; 25 Sep 2013 08:32:58 -0000
Received: from GBTWK10E001.Technology.local ([10.234.1.29]) by gbtwk10s037.Technology.local ([10.234.1.39]) with mapi; Wed, 25 Sep 2013 09:32:57 +0100
From: "Lewis, Nick" 
To: "'tls@ietf.org'" 
Date: Wed, 25 Sep 2013 09:32:57 +0100
Thread-Topic: Re: padding bug
Thread-Index: Ac65ydZhkjFJWjbPSvuJeogMKfJ34Q==
Message-ID: 
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_AAE0766F5AF36B46BAB7E0EFB927320630E4A54283GBTWK10E001Te_"
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 08:33:12 -0000

--_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54283GBTWK10E001Te_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Martin Rex wrote:
> Where I agree is that it would be preferable to limit any fix to the exac=
t
> problem that has been identified (already by Vaudenay), which is in how
> SSLv3&TLS use a Blockcipher in CBC mode with "authenticate-pad-encrypt"
> rather than "pad-authenticate-encrypt".

I agree that the fix should be limited to the exact problem. The fix could =
be a change from AtPtE to PtAtE
using a greatly simplified version of http://tools.ietf.org/html/draft-piro=
nti-tls-length-hiding-00  without
the length hiding features

--


________________________________
The details of this company are as follows:
G4S Technology Limited, Registered Office: Challenge House, International D=
rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823=
38.

This communication may contain information which is confidential, personal =
and/or privileged.

It is for the exclusive use of the intended recipient(s).
If you are not the intended recipient(s), please note that any distribution=
, forwarding, copying or use of this communication or the information in it=
 is strictly prohibited.

Any personal views expressed in this e-mail are those of the individual sen=
der and the company does not endorse or accept responsibility for them.

Prior to taking any action based upon this e-mail message, you should seek =
appropriate confirmation of its authenticity.

This e-mail has been scanned for all viruses by MessageLabs.

--_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54283GBTWK10E001Te_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Martin Rex wrote:


> Where I agree is that it would be preferable to=
 limit any fix to the exact


> problem that has been identified (already by Vaudenay), which is in ho=
w 

> SSLv3&TLS use a Blockcipher in CBC mode with "authenticate-pa=
d-encrypt" 

> rather than "pad-authenticate-encrypt".


 


I agree that the fix should be limited to the exact =
problem. The fix could be a change from AtPtE to PtAtE


using a greatly simplified version of 
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00  wit=
hout 

the length hiding features 


 


-- 


 







The details of this company =
are as follows:

G4S Technology Limited, Registered Office: Challenge House, International D=
rive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No. 23823=
38.



This communication may contain information which is confidential, personal =
and/or privileged.



It is for the exclusive use of the intended recipient(s).

If you are not the intended recipient(s), please note that any distribution=
, forwarding, copying or use of this communication or the information in it=
 is strictly prohibited.



Any personal views expressed in this e-mail are those of the individual sen=
der and the company does not endorse or accept responsibility for them.



Prior to taking any action based upon this e-mail message, you should seek =
appropriate confirmation of its authenticity.



This e-mail has been scanned for all viruses by MessageLabs.





--_000_AAE0766F5AF36B46BAB7E0EFB927320630E4A54283GBTWK10E001Te_--

From p.j.bakker@offspark.com  Wed Sep 25 02:08:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2C21E8055 for ; Wed, 25 Sep 2013 02:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DurU9Yx8RzNs for ; Wed, 25 Sep 2013 02:08:33 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 9F9B221F9E12 for ; Wed, 25 Sep 2013 02:08:32 -0700 (PDT)
Received: from [188.200.77.25] (helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VOkz5-0000PL-Ob; Wed, 25 Sep 2013 11:02:12 +0200
From: "Paul Bakker" 
To: "'Michael StJohns'" , "'Wan-Teh Chang'" 
References: <523DF3AF.6060208@nthpermutation.com>	 <52425A2A.3060401@nthpermutation.com>
In-Reply-To: <52425A2A.3060401@nthpermutation.com>
Date: Wed, 25 Sep 2013 11:08:28 +0200
Message-ID: <016201ceb9ce$ccc77bb0$66567310$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFh5jpWJf69Lt53SBS6zYpd99BHlgMIBHvXAZaFk+uaitxjQA==
Content-Language: nl
X-SA-Exim-Connect-IP: 188.200.77.25
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Cc: tls@ietf.org
Subject: Re: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 09:08:38 -0000

> Simply by adding the length fields to the KDF inputs used with the key
> material exporters.  So if an exporter needs 4 keys, there are 4 length
> values, 2 keys, 2 length values etc.   That makes what gets passed into
> the KDF the secret, the public values including the label,  and the length
of
> each key and that construct can be used for the pre-master to master,
> master to key expansion and for any key exporters.  This is just an
off-the-
> cuff suggestion at this point.
> 
> One other alternative is to only provide lengths for keys - anything
> after the end of the keys is public data.   That allows the
> private/public division  of data consistent with the current model without
> having to build a special function just for the key-expansion step.  And -
if
> you run this without providing any key lengths, you end up with the same
> key stream as the old function -and that simplifies the
> PKCS11 implementation.

Wouldn't using the 'ciphersuite id' in the KDF provide the same (as the
ciphersuite determines all those values) and is simpler in the process?


From pgut001@cs.auckland.ac.nz  Wed Sep 25 03:30:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0589711E80D2 for ; Wed, 25 Sep 2013 03:30:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level: 
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9SFnKxuDy9qr for ; Wed, 25 Sep 2013 03:30:17 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 2425F21F9D9C for ; Wed, 25 Sep 2013 03:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380105017; x=1411641017; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CPBKfnqRrN/Fnb5BMmjPLk+3DDv/2Pk2AThyGo1csKI=; b=HImZqnhHrI815WF6XBIrNHGoV1jq/wpR3TrbgRD/V2u886TFIuS/unSb R12gYlHrL+wCnjmrO5ounCxrlm5eK80prcmsHAABY1R9vBxghIvCpKJ7e o2124sNvuRBT+BW3LiGPFsGTlrvlZ6YYv0ON8xGn4ud1Cpyt//ZGLLxz9 w=;
X-IronPort-AV: E=Sophos;i="4.90,977,1371038400"; d="scan'208";a="214108723"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Sep 2013 22:30:14 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 22:30:13 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac652jeTx133SxOpTE2eA3YPrgA5JA==
Date: Wed, 25 Sep 2013 10:30:12 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 10:30:22 -0000

Eric Rescorla  writes:=0A=
=0A=
>Do you think you could address the questions I asked below?=0A=
=0A=
Sorry, given the email avalanche recently and the fact that I wasn't sure w=
hat=0A=
the questions were getting at, I'd put them in the TODO list.=0A=
=0A=
> - Because this draft relies on extensions, it seems not to resist=0A=
>   active attack when clients do insecure version fallback=0A=
>   (see for instance:=0A=
> http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)=0A=
=0A=
Right, but given that the problem is broken clients I'm not sure what the=
=0A=
issue is.  Anything that falls back to older, less secure versions of=0A=
protocols is going to be vulnerable to things that the newer protocols fix.=
=0A=
=0A=
> - Maybe I am misreading the draft, but I'm unclear on how you get=0A=
>    the TLSCompressed.length for the MAC computation in Section 3.=0A=
>    Does this have the same issue as was raised for McGrew's CBC AEAD=0A=
>    draft?=0A=
=0A=
What was the issue raised for the AEAD draft?  Since I'm not sure what the=
=0A=
question is asking, the only real response I can give is that there's a num=
ber=0A=
of implementations out there that interoperated without problems, so whatev=
er=0A=
the perceived problem is, it doesn't seem to be much of an issue.=0A=
=0A=
Peter.=

From alfredo@pironti.eu  Wed Sep 25 03:49:00 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4E21F9CED for ; Wed, 25 Sep 2013 03:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.426
X-Spam-Level: 
X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wE1AAdM1xb7X for ; Wed, 25 Sep 2013 03:48:57 -0700 (PDT)
Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id CDEA221F9CE9 for ; Wed, 25 Sep 2013 03:48:55 -0700 (PDT)
Received: by mail-qc0-f180.google.com with SMTP id p19so3952516qcv.11 for ; Wed, 25 Sep 2013 03:48:55 -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=BaJv0HR75qiVoTeRPUY191hUM0Dsn3JScWLetEUFdi0=; b=MlXJpB3NwfA7/m25X5vhUVvCElks0rWV3Lo5MPHSvkXdF1xMnSoRnaoN8UeOxYzecl ObMTSdRAsrIMapw8Kp0klVaQ22ob0NvWeGaaOiUHeUmOQ+5etCp4GYW5/vT41DxSD0Ew zFe/2idMG5rWwGxx1UmTv40vWMg86tULBLf9Q=
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=BaJv0HR75qiVoTeRPUY191hUM0Dsn3JScWLetEUFdi0=; b=bY2vhBNn4Jgs+L2t47nkvad8D2w7ZZJGe4TI28ZK+Edlnp+FEXqu/Ndz2bVIONr3Co aa7CtqLU5O0S/HVf8m7SNEpFstoEg1awt5+F9h2jpiVaC/UaSTTZTpvyLIUB5A6d3L9h /J6ls8bmUQnvIjgBteRi7yAVUzYl/X/LzJT+U3a7FxcCyJ9WgxzdkoTesf2WMxb5dL5y D74dbwc2+dzDR9YlXCEoKXr42sVaVoX2XvhelyOFPBLBMwvE1FuYp8I0gA2LMALM6mBB uRFKQtyP+cnI6X4n4SZFWtmFgE6bjbAEtshOnBMkQYrno+Vo2/wjIpvr1qlBIbZTMRDL QDBQ==
X-Gm-Message-State: ALoCoQmDMRhVzbnnJKLlwUXVVarhDgn6wXVWEkwrMXQqTKksLLcCA2EulR4gb+MjcHfQJUCwgsd9
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr15413502qam.92.1380106135368; Wed, 25 Sep 2013 03:48:55 -0700 (PDT)
Received: by 10.49.108.103 with HTTP; Wed, 25 Sep 2013 03:48:55 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: 
References: 
Date: Wed, 25 Sep 2013 12:48:55 +0200
Message-ID: 
From: Alfredo Pironti 
To: "Lewis, Nick" 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 10:49:00 -0000

On Wed, Sep 25, 2013 at 10:32 AM, Lewis, Nick  wrote:
> Martin Rex wrote:
>
>> Where I agree is that it would be preferable to limit any fix to the exact
>> problem that has been identified (already by Vaudenay), which is in how
>> SSLv3&TLS use a Blockcipher in CBC mode with "authenticate-pad-encrypt"
>> rather than "pad-authenticate-encrypt".
>
>
>
> I agree that the fix should be limited to the exact problem. The fix could
> be a change from AtPtE to PtAtE
> using a greatly simplified version of
> http://tools.ietf.org/html/draft-pironti-tls-length-hiding-00  without
> the length hiding features

Indeed, I confirm a strict subset of
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02
(pointing to the latest version)
fixes the padding bug.

Once the padding bug is fixed according to this draft, my experience
implementing it in GnuTLS and miTLS is that it costs almost nothing to
implement the length-hiding features for the remaining stream and AEAD
ciphers.

Best,
Alfredo

>
>
>
> --
>
>
>
>
> ________________________________
> The details of this company are as follows:
> G4S Technology Limited, Registered Office: Challenge House, International
> Drive, Tewkesbury, Gloucestershire GL20 8UQ, Registered in England No.
> 2382338.
>
> This communication may contain information which is confidential, personal
> and/or privileged.
>
> It is for the exclusive use of the intended recipient(s).
> If you are not the intended recipient(s), please note that any distribution,
> forwarding, copying or use of this communication or the information in it is
> strictly prohibited.
>
> Any personal views expressed in this e-mail are those of the individual
> sender and the company does not endorse or accept responsibility for them.
>
> Prior to taking any action based upon this e-mail message, you should seek
> appropriate confirmation of its authenticity.
>
> This e-mail has been scanned for all viruses by MessageLabs.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From alfredo@pironti.eu  Wed Sep 25 04:01:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3121F21F9AF8 for ; Wed, 25 Sep 2013 04:01:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.426
X-Spam-Level: 
X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBf8m1oUwTEF for ; Wed, 25 Sep 2013 04:01:40 -0700 (PDT)
Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0B121F9F86 for ; Wed, 25 Sep 2013 04:01:37 -0700 (PDT)
Received: by mail-qc0-f175.google.com with SMTP id v2so3927684qcr.6 for ; Wed, 25 Sep 2013 04:01:37 -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=mon7lICynwSiJ/oYYGZ5LbzbnULwRw0huxbfnDkjHxE=; b=AezHAeH6ZxHvqiLa4KWPALMMMHw6VlCGwG8PPEMC36Xaz8mF1VkfEmKhZMlKl/Oed9 HGS3hNE3yb7Y/QsY/D+UQWbDXcKi3rcpVfahEJtGwTD22PvbKfW4dz/z8Ts5/yGAmrcS ykvsxc5VrUnUkfbpT5A2Rl9bxbu/2eT4+gIlA=
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=mon7lICynwSiJ/oYYGZ5LbzbnULwRw0huxbfnDkjHxE=; b=BkqXGuW9jYzH8Zpm8nDznZorSxI+9g+TRs2le7nJfMsm7rHfr2KV4NRsfMsNXBCkZJ Ay7EWmPPMA7YDi8EMSCMFdMCQn+0KtcBwbpoC/MG0dzOPr3om2jfNArw6JggCYoPMUtm wUtL8BExyvpjoMzj4elFQdcmTnRIoySDCIZVhZnl//KQIbRB4PzmmU77qdyk6Z1bnzJZ i2d6SutWOLLpbcKZyRscq/J4PVXjyqN/z+pC8+IsSd1BBT4Se0kC7fLl9DRsL3H1bcX/ hNzYWlY7SaBOGkqMcEXOaa3AgC3/VwOWnAzP+LPM722ssxyvazoiHP9yLzNzY/mzSq1s qs3Q==
X-Gm-Message-State: ALoCoQlyiXV8/run7gB+AX3WlrVegLaZc5jDromp6GvspvwX/5oisjFbtl3KmXy2aWZnMDLpwN+0
MIME-Version: 1.0
X-Received: by 10.224.92.81 with SMTP id q17mr15474735qam.92.1380106897090; Wed, 25 Sep 2013 04:01:37 -0700 (PDT)
Received: by 10.49.108.103 with HTTP; Wed, 25 Sep 2013 04:01:36 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
Date: Wed, 25 Sep 2013 13:01:36 +0200
Message-ID: 
From: Alfredo Pironti 
To: Peter Gutmann 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 11:01:44 -0000

On Wed, Sep 25, 2013 at 12:30 PM, Peter Gutmann
 wrote:
> Eric Rescorla  writes:
>
>>Do you think you could address the questions I asked below?
>
> Sorry, given the email avalanche recently and the fact that I wasn't sure what
> the questions were getting at, I'd put them in the TODO list.
>
>> - Because this draft relies on extensions, it seems not to resist
>>   active attack when clients do insecure version fallback
>>   (see for instance:
>> http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
>
> Right, but given that the problem is broken clients I'm not sure what the
> issue is.  Anything that falls back to older, less secure versions of
> protocols is going to be vulnerable to things that the newer protocols fix.
>
>> - Maybe I am misreading the draft, but I'm unclear on how you get
>>    the TLSCompressed.length for the MAC computation in Section 3.
>>    Does this have the same issue as was raised for McGrew's CBC AEAD
>>    draft?
>
> What was the issue raised for the AEAD draft?  Since I'm not sure what the
> question is asking, the only real response I can give is that there's a number
> of implementations out there that interoperated without problems, so whatever
> the perceived problem is, it doesn't seem to be much of an issue.

The issue is on the receiving side, about computing the
"TLSCompressed.length" field that you need to put in your local
computation of the MAC. I believe
http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
as currently defined suffers the same issue.

On receiving side, currently you can't just take the ciphertext and
additional data and locally derive a MAC from it, because the MAC
contains the TLSCompressed.length field, which is the lenght of the
plaintext *before* padding. So, currently, you need to:
1) decrypt
2) split plaintext from pad to recover the TLSCompressed.length value !!!
3) check the MAC

note that step 2 is performing an operation on sensitive data *before*
the MAC has been checked, which actually exposes a very similar
padding oracle to the one that affects current MtPtE.

Fix is however not too difficult: in the MAC, include the whole
"plaintext+padding" length, so that it can be computed directly form
the ciphertext length, without need to decrypt it first.

As a note, this details are already sorted out in
http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02
where the whole padded length is included in the MAC, and an
"implementation note" paragraph forces the implementer to perform
decryption steps in the right way, avoiding "smart" developers to take
insecure shortcuts.

Best,
Alfredo

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

From SRS0=M8uh=TF=acm.org=bmoeller@srs.kundenserver.de  Wed Sep 25 04:03:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A9E21F9FBF for ; Wed, 25 Sep 2013 04:03:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.391
X-Spam-Level: 
X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=0.235,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9TdqhVyPUTV for ; Wed, 25 Sep 2013 04:03:23 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id B3C5721F9BAB for ; Wed, 25 Sep 2013 04:03:22 -0700 (PDT)
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0Ljxmg-1VzVGk0R0U-00c9fA; Wed, 25 Sep 2013 13:03:20 +0200
Received: by mail-ob0-f177.google.com with SMTP id wp18so6431450obc.22 for ; Wed, 25 Sep 2013 04:03:18 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qTMMQAo0PYjl3FgLDpSNXNdkjcvO3tEGF6hQInlsUtU=; b=iVtxW5A4Dn297gfR1mAG4bNAVYMVRU60nf/iwXlgkiJH3DvQQDStvKyMkdwJzlY5Wg B6Ocd+MNJK670/8ntkK0qzaAK8UzdCqTKdYYzrQ+7cMVY3rb9SfT99pzQcBKj6lLGF9P ZWuYBZJoVtHSzpHSUaAm/40C6z0S6BFdIzfCt40pC8aCRPCLYmXpc8qgq/nqzh11TvrT CCpYmdVYjSs3oXAb5GGyMZO2YwFevL4IdnsmmMS1IqfyJHJEUFf75t3VcBKlcm0/KSK8 66VjWKK4+CUBp8UNpn8bndvineK704OQLP5HpS293MxGYLOi5/udJOoPPqR4bW9BBI/W VHgQ==
MIME-Version: 1.0
X-Received: by 10.60.63.68 with SMTP id e4mr29810787oes.23.1380106998896; Wed, 25 Sep 2013 04:03:18 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Wed, 25 Sep 2013 04:03:18 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>
Date: Wed, 25 Sep 2013 13:03:18 +0200
Message-ID: 
From: Bodo Moeller 
To: Peter Gutmann 
Content-Type: multipart/alternative; boundary=001a11c257d46be24904e733330f
X-Provags-ID: V02:K0:vKbBx7MAXyqsX3BHLeJhNlUBmetwUc0f1BDa4AiiWpf u6JsEIKaQcBgdWhUMEgVm7jl6klknbNsKZnJqHpP+6fa80VDet Kgq9hAuG9OoY299byBzwpLqw5Iq+CubXpa/YTFHxwXwtzCqKCo v54uhwEGihk0ryEu4sXYQpnXJQD87YYHCqi8HHU2W4IW6ldNlw FKjfJ6fA7Vv6hayx5cVFefka4u4oAaAA1IHkS6XpS6+77ZTg3q 1URTEHcbqFUL28XfAuQEtnyPwmuSCXs7nRj4pG6ZVQx3aP2i3X 4vgO6O7uX1JA85F6UVAqsTgLJM+i9yOvzI1R1P3QzLT4gjDhso h2PMskAYTl0IBCgZO0yO2lBPGGaqp9bvPbiGeu2h0vkx3NVBen nanU/+cmAZL2GITiT3nC3jc+novusz529jQlaJhLDwZwkyLD3J P0aEP
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 11:05:38 -0000

--001a11c257d46be24904e733330f
Content-Type: text/plain; charset=ISO-8859-1

> > - Because this draft relies on extensions, it seems not to resist
> >   active attack when clients do insecure version fallback
> >   (see for instance:
> > http://www.ietf.org/mail-archive/web/tls/current/msg09468.html)
>
> Right, but given that the problem is broken clients I'm not sure what the
> issue is.  Anything that falls back to older, less secure versions of
> protocols is going to be vulnerable to things that the newer protocols fix.
>

Consider a client and server that both support a secure protocol version,
but where the client will reconnect using an older protocol version if it
suspects that that's necessary for interoperability.  Since in this
scenario, the client won't reliably know if handshake failures indicate
interoperability problems with the actual server or with an active
attacker, having a security fix that can be applied to the older protocol
version as well has a clear benefit.

(Also, offering this Encrypt-then-MAC option rather than just switching to
AEAD ciphersuites completely could make it easier to fix older
implementations before they can migrate to newer protocol versions; but I'm
very skeptical about this rationale in the case of falling back to SSL 3.0
[and no TLS extensions] -- if an implementation really is stuck at SSL 3.0,
that looks hopeless to me.)

While removing SSL 3.0 support entirely would avoid this kind of problem,
SSL 3.0 is still sometimes required for interoperability. (Cf. the history
of RFC 6187: http://tools.ietf.org/html/rfc6176)


So maybe the right fix to this kind of problem is to adapt an idea from
draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
that would *only* be used in SSL 3.0 connections by clients that have
downgraded, and tells the server "If you can read this, tear down the
connection because we shouldn't actually be using SSL 3.0 for this
connection"?

Bodo

--001a11c257d46be24904e733330f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=




> - Because this draft relies on extensions, it seems not to resist

> =A0 active attack when clients do insecure version fallback

> =A0 (see for instance:

> http://www.ietf.org/mail-archive/web/tls/current/msg=
09468.html)




Right, but given that the problem is broken clients I'm not sure =
what the

issue is. =A0Anything that falls back to older, less secure versions of

protocols is going to be vulnerable to things that the newer protocols fix.=


Consider a client and server that both=
 support a secure protocol version, but where the client will reconnect usi=
ng an older protocol version if it suspects that that's necessary for i=
nteroperability. =A0Since in this scenario, the client won't reliably k=
now if handshake failures indicate interoperability problems with the actua=
l server or with an active attacker, having a security fix that can be appl=
ied to the older protocol version as well has a clear benefit.



(Also, offering this Encrypt-then-MAC option rather tha=
n just switching to AEAD ciphersuites completely could make it easier to fi=
x older implementations before they can migrate to newer protocol versions;=
 but I'm very skeptical about this rationale in the case of falling bac=
k to SSL 3.0 [and no TLS extensions] -- if an implementation really is stuc=
k at SSL 3.0, that looks hopeless to me.)



While removing SSL 3.0 support entirely would avoid thi=
s kind of problem, SSL 3.0 is still sometimes required for interoperability=
. (Cf. the history of RFC 6187: http://tools.ietf.org/html/rfc6176)




So maybe the right fix to this kind of p=
roblem is to adapt an idea from draft-rescorla-tls-version-cs-00 and create=
 a signalling ciphersuite value that would *only* be used in SSL 3.0 connec=
tions by clients that have downgraded, and tells the server "If you ca=
n read this, tear down the connection because we shouldn't actually be =
using SSL 3.0 for this connection"?



Bodo




--001a11c257d46be24904e733330f--

From pgut001@cs.auckland.ac.nz  Wed Sep 25 04:21:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3449921F84F8 for ; Wed, 25 Sep 2013 04:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQv1ReZ5j8MX for ; Wed, 25 Sep 2013 04:20:58 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id F1ACA21F8BCE for ; Wed, 25 Sep 2013 04:20:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380108057; x=1411644057; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=DqmYudVDLFKDr2xPSHNFP5vyi8sJh8l7FSBsudRiZKk=; b=Ma9iw7N1wSH6jk1Fql4pel1AYbPzSeSGdQ4JvriTFBjGXTNGGAEaYKpB NmL8Fz+xHWoeh4VI7sTZWImLul+jziCn8GXh5KMt+pqxxWUBzLJf9bDnz G1U04GFfduks2zSNQUgsnZ2cY+ZzWAHSLtlb1OYF88NpiJUftQwl/YW0K w=;
X-IronPort-AV: E=Sophos;i="4.90,978,1371038400"; d="scan'208";a="214112329"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Sep 2013 23:20:55 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 23:20:55 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac654U0ImtPifUbbQCiU46qwJr4uLg==
Date: Wed, 25 Sep 2013 11:20:55 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567D411@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 11:21:07 -0000

Michael D'Errico  writes:=0A=
>Peter Gutmann wrote:=0A=
>> TLS has for some years now provided for MAC truncation to a=0A=
>> range of sizes.=0A=
>=0A=
>I believe you are confusing the max_fragment_length extension with=0A=
>truncated_hmac. =0A=
=0A=
Yep.  I'd have private email about this but I'm still working my way throug=
h=0A=
to it, see my earlier comments about the email backlog.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Wed Sep 25 04:25:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7526621F9FB5 for ; Wed, 25 Sep 2013 04:25:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.583
X-Spam-Level: 
X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guqU8CCERHgV for ; Wed, 25 Sep 2013 04:25:49 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 098FD21F9C55 for ; Wed, 25 Sep 2013 04:25:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380108349; x=1411644349; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=/plTKBPYqIH8cE6y03nZL/KsxDyH8yvmhzFdkb7gYX4=; b=f5s5AHkw77ix8W/kHqm6okPU+hk3UFRcdKbqQ53S4MZD6StZ8F8BaN8h He8bG7l/7EUCLGl8NOzt+xdowqFy2rwcYyWUi3O5cjTC3KVoMp1dig2V/ CSENy6HhIU26J8ZSX7sVvdSLTPghh1OW6KpiPBZZS/mV8HXItpMCuVLSb c=;
X-IronPort-AV: E=Sophos;i="4.90,978,1371038400"; d="scan'208";a="214112584"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 25 Sep 2013 23:25:47 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Wed, 25 Sep 2013 23:25:47 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac654fqouzzgSjFPR0aNmxr0+W1ZJg==
Date: Wed, 25 Sep 2013 11:25:46 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567D41E@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 11:25:54 -0000

Ben Laurie  writes:=0A=
>On 24 September 2013 17:31, Hovav Shacham  wrote:=0A=
>> I would prefer an approach that deprecates existing suites in favor of=
=0A=
>> non-CBC authenticated encryption modes.=0A=
>=0A=
>That means requiring TLS 1.2, which is a far more complex update to existi=
ng=0A=
>s/w than this change.=0A=
=0A=
You beat me to it (see: email backlog).  In fact this issue has been covere=
d=0A=
in the draft since -01.=0A=
=0A=
Peter.=

From holz@net.in.tum.de  Wed Sep 25 04:29:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9A721F9F7F for ; Wed, 25 Sep 2013 04:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.984
X-Spam-Level: 
X-Spam-Status: No, score=-1.984 tagged_above=-999 required=5 tests=[AWL=0.265,  BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OqgrL2SoFkwS for ; Wed, 25 Sep 2013 04:29:43 -0700 (PDT)
Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) by ietfa.amsl.com (Postfix) with ESMTP id 13E4221F9702 for ; Wed, 25 Sep 2013 04:29:42 -0700 (PDT)
Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 8E61A8099A; Wed, 25 Sep 2013 13:29:41 +0200 (CEST)
Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 4DB9F80989 for ; Wed, 25 Sep 2013 13:29:39 +0200 (CEST)
Message-ID: <5242C95A.6080306@net.in.tum.de>
Date: Wed, 25 Sep 2013 13:30:34 +0200
From: Ralph Holz 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz> 
In-Reply-To: 
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.97.8 at ex6
X-Virus-Status: Clean
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 11:29:47 -0000

Hi,

> While removing SSL 3.0 support entirely would avoid this kind of
> problem, SSL 3.0 is still sometimes required for interoperability. (Cf.
> the history of RFC 6187: http://tools.ietf.org/html/rfc6176)

We have some empirical data, albeit only for servers. In our most recent
IPv4-wide scan, only 3% of servers required us to downgrade to SSL 3 in
order to complete the handshake. All others were OK with TLS1.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

From pgut001@cs.auckland.ac.nz  Wed Sep 25 05:05:37 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE85D21F9F40 for ; Wed, 25 Sep 2013 05:05:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.584
X-Spam-Level: 
X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJMkBHuc+PfO for ; Wed, 25 Sep 2013 05:05:32 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4E88511E80D7 for ; Wed, 25 Sep 2013 05:05:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380110729; x=1411646729; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=CJFKB3jkJrxTmnj1v41EpTvPC51YlFoNwD3tFAHNmhQ=; b=CqsjsiLxHkJCkyawBSvd6ZFp18/bx/w1wBii3keX4o10hN0NDp634ksH BLZSvhfWKUd6PcNGHqct+SBI5kZIrtTAFBz0EmsDc1hgsfAdgLFupmu7A FwTlkSlp/J38+tOaehE5VxRaX6iT1q8uUSMLAXU9v45HssVMTm3SXBF1A w=;
X-IronPort-AV: E=Sophos;i="4.90,978,1371038400"; d="scan'208";a="214115694"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Sep 2013 00:05:26 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 00:05:25 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac6554R+5ig9zF5BTM2JQBRKtTumNg==
Date: Wed, 25 Sep 2013 12:05:25 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567D446@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 12:05:38 -0000

Michael D'Errico  writes:=0A=
>Peter Gutmann wrote:=0A=
>> For DH you just use Lim-Lee and you're done=0A=
>=0A=
>Can you please provide a pointer to the Lim-Lee algorithm?=0A=
=0A=
It was presented in "A key recovery attack on discrete log-based schemes us=
ing=0A=
a prime order subgroup" at Crypto'97, see the link (unfortunately only to a=
 PS=0A=
file) at http://dasan.sejong.ac.kr/~chlim/english_pub.html.  There's a PDF-=
ised=0A=
version available via Citeseer at =0A=
http://citeseerx.ist.psu.edu/viewdoc/download?doi=3D10.1.1.44.5296&rep=3Dre=
p1&type=3Dpdf.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Wed Sep 25 05:08:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B256711E80D7 for ; Wed, 25 Sep 2013 05:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAfrbf6nfUaY for ; Wed, 25 Sep 2013 05:08:44 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 52BA521F9FF9 for ; Wed, 25 Sep 2013 05:08:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380110925; x=1411646925; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=rmOcQ0V+BJPrQ0T0jRvkrhNEhQhN26vyM5+UNK+5l90=; b=njUFaAgTXCtvFLDK90qin29NLpiYjr/9M5davrvUB+d+DqNRWdQGLRCw C6um0ywCib5GJTopRrJZq/34C5EH0atTotwYxi8oMCdyLVzwIIqRhcY7Y gcFjLUgYul9kCk9Uk9GoJdAaZjMzoHdBj1QWfn/BrBZcBNRldJeoDYvW5 g=;
X-IronPort-AV: E=Sophos;i="4.90,978,1371038400"; d="scan'208";a="214115885"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Sep 2013 00:08:44 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 00:08:43 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac655/otklypa49jScqhl6dblNTQPA==
Date: Wed, 25 Sep 2013 12:08:42 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567D458@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 12:08:49 -0000

Alfredo Pironti  writes:=0A=
=0A=
>Fix is however not too difficult: in the MAC, include the whole=0A=
>"plaintext+padding" length, so that it can be computed directly form the=
=0A=
>ciphertext length, without need to decrypt it first.=0A=
=0A=
Oh, I see.  It already is, in fact I'd never even considered that you could=
 do=0A=
it any other way, and given the results of the interop tests so far I guess=
=0A=
no-one else has either.  I'll add a clarification to the draft about this.=
=0A=
=0A=
Peter.=0A=

From alangley@gmail.com  Wed Sep 25 06:11:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C6121F9E0B for ; Wed, 25 Sep 2013 06:11:44 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ci60J4QBnVPn for ; Wed, 25 Sep 2013 06:11:44 -0700 (PDT)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB2821F9DD0 for ; Wed, 25 Sep 2013 06:11:39 -0700 (PDT)
Received: by mail-lb0-f172.google.com with SMTP id x18so5008541lbi.17 for ; Wed, 25 Sep 2013 06:11:38 -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=OnpjsbpyRUzPQ6l6/mF9kURlQkHzUWGO0z+ij3fxMaQ=; b=HqLl+LCNXd/1153BkAIP6niPT/A92vaNcjj0t2rP1f+Li5beTYZxQn62xjMqZne0xh Iv6DHvgY5nzMBzxoobXyBfyIFFz6+7OcSBRGPZLTa2TDuUKLENIg4QgjM52uf+lUNXHT jFEW9Nw1Gqskt0iZWmv8DNVK6TIomFR+p1Bd9PQa5aK85c2JXVpmSJp0+KRwx/tUrT86 xNIJkgP7P3f9Irg5UGuhi/0nipox+Jo50w9K/JBo+sGN3qnx2nay445vW/lR4URz14YJ LfQu8r4CB1P/EZPwyd+BrDVTB5BTHg9r+cQik55J+H+kk8XCQPYYk2AGiGbcW9SEErSu hJvw==
MIME-Version: 1.0
X-Received: by 10.152.8.115 with SMTP id q19mr30282961laa.16.1380114698172; Wed, 25 Sep 2013 06:11:38 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.6.170 with HTTP; Wed, 25 Sep 2013 06:11:38 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz> 
Date: Wed, 25 Sep 2013 09:11:38 -0400
X-Google-Sender-Auth: inYuk__6gIoVp-iyjmajrdGKJ1E
Message-ID: 
From: Adam Langley 
To: Bodo Moeller 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 13:11:44 -0000

On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller  wrote:
> So maybe the right fix to this kind of problem is to adapt an idea from
> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
> that would *only* be used in SSL 3.0 connections by clients that have
> downgraded, and tells the server "If you can read this, tear down the
> connection because we shouldn't actually be using SSL 3.0 for this
> connection"?

(I think I would want such an SCSV to indicate TLS 1.2 support rather
than TLS 1.0 support, but that's just a detail.)

A possible problem with this approach is that there are both broken
servers and broken networks and I don't have good information about
the latter. (It's obviously much more difficult to detect.)

Broken networks can stop the transit of TLS based on version and that
has been observed, very rarely, in the wild. However, just because we
haven't observed it much doesn't mean that it's not happening, it just
means that we rarely get to observe it.

If it turns out that broken networks are insignificant then we can use
an SCSV to prevent version downgrade. (Using the renegotiation
extension for this would have been nice, but I think we've already
lost that battle.)

However, if they are not then we may need to run modern ciphersuites
in older versions.

The first step to figuring this out is that Chrome will stop
downgrading to SSLv3 when talking to Google servers soon. If that
works, and we're able to get to the point where we can remove fallback
completely without breaking networks, then that will answer the
question.



Cheers

AGL

-- 
Adam Langley agl@imperialviolet.org http://www.imperialviolet.org

From SRS0=M8uh=TF=acm.org=bmoeller@srs.kundenserver.de  Wed Sep 25 06:21:40 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A324C21F9FB6 for ; Wed, 25 Sep 2013 06:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=0.203,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pB0vemPmklDH for ; Wed, 25 Sep 2013 06:21:34 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id A919621F9CDF for ; Wed, 25 Sep 2013 06:21:31 -0700 (PDT)
Received: from mail-oa0-f43.google.com (mail-oa0-f43.google.com [209.85.219.43]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MdH7v-1V6sNA0EXD-00IF2C; Wed, 25 Sep 2013 15:21:27 +0200
Received: by mail-oa0-f43.google.com with SMTP id f4so1001220oah.2 for ; Wed, 25 Sep 2013 06:21:25 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yXmCiFzN5eynEr5k8F3iE4BHfJVR3yiqkoqYazuon5w=; b=XQgRQUs/GBtG2bvS3XrX11/1BYeYfjlJkfvOpyTN0erNHRnKbnVYIkheedlxxzxY8e xEpOpLl8tjO0x1rKUX0yBh0DqexlRCzk+exqI/yE4c0PfY8ZHzIv7H2Qo0hvCFBMxig9 s05TdWjkHI5pIyDGojOoQRWy46rH6GjNyZSSiVG+3lDkNnAODYDvrRGq/8Z9CPFuiHA9 jPlj12WfmBzzWl3BcY0dzzWonPQXP9zDPWiwxnvcg5YX2qglfmi5ZqfHdMuLBNykqsdx YKcryaktA8hFaQ9lkdUxYTgxT6i2wSEJjg2KDQzzZwgpqgU2fptuORwOfn1Dn7KIr1h+ cTTw==
MIME-Version: 1.0
X-Received: by 10.60.173.205 with SMTP id bm13mr16973449oec.25.1380115285827;  Wed, 25 Sep 2013 06:21:25 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Wed, 25 Sep 2013 06:21:25 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>  
Date: Wed, 25 Sep 2013 15:21:25 +0200
Message-ID: 
From: Bodo Moeller 
To: Adam Langley 
Content-Type: multipart/alternative; boundary=089e011607065c728f04e73521e3
X-Provags-ID: V02:K0:lwz/vhk3sUZr+NRMWozsxSkWq3l3rOGRzwqWCCUyrAP Vqy7b8ydmcGXuOl4MNDKLDhhw8UgZRxGtzS6jrwRIfz1yP8qYJ +vmPKY76SDL1UdDx666/XFgY8CNGYlfQRaisAokipEu+Nv6q21 G1at4inQ4ttV8U1T5G9yJ2tnuKQUNxhMdlhrt9MU1OXPI8bEXF 7BkNmfiYLuj0qsjhP0Y8hMcBwM90x8YVKEcDlZgisOb1I4OVbK VfVCu7KXZYGso5rAB2lwc9FpUy3bDO7VqZw6Hy2MhKgosWilOX r2Pu45HB66g+PXBIbpD3DCPT/ymFWqgoutRquenglV1oOx1TU/ nAOYg8jO4K4BI57Ntct9UXQqDBLah1U0neh4dvr2+ihMFsLbUY t1JX971FCj6XBN2h+gh8aO+EeT5Qi2jsZ1X1dMt/BmmjFxkDVW 83Wcy
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 13:21:40 -0000

--089e011607065c728f04e73521e3
Content-Type: text/plain; charset=ISO-8859-1

> A possible problem with this approach is that there are both broken
> servers and broken networks and I don't have good information about
> the latter. (It's obviously much more difficult to detect.)
>
> Broken networks can stop the transit of TLS based on version and that
> has been observed, very rarely, in the wild. However, just because we
> haven't observed it much doesn't mean that it's not happening, it just
> means that we rarely get to observe it.


I know -- and the boundaries between "broken network" and "attacker" may
not always be clear: if the broken network effectively *is* an attacker
(even unintentionally so) and weakens the cryptography of the connection,
it may make a lot of sense to avoid that network entirely.

--089e011607065c728f04e73521e3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=


A possible problem with this approach is that there are both broken

servers and broken networks and I don't have good information about

the latter. (It's obviously much more difficult to detect.)



Broken networks can stop the transit of TLS based on version and that

has been observed, very rarely, in the wild. However, just because we

haven't observed it much doesn't mean that it's not happening, =
it just

means that we rarely get to observe it.

I k=
now -- and the boundaries between "broken network" and "atta=
cker" may not always be clear: if the broken network effectively *is* =
an attacker (even unintentionally so) and weakens the cryptography of the c=
onnection, it may make a lot of sense to avoid that network entirely.






--089e011607065c728f04e73521e3--

From msj@nthpermutation.com  Wed Sep 25 08:22:56 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2521321F9C4D for ; Wed, 25 Sep 2013 08:22:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.573
X-Spam-Level: 
X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5zgAIDVoUu4 for ; Wed, 25 Sep 2013 08:22:49 -0700 (PDT)
Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id C12BE21F96E4 for ; Wed, 25 Sep 2013 08:22:47 -0700 (PDT)
Received: by mail-qa0-f54.google.com with SMTP id bv4so3540596qab.20 for ; Wed, 25 Sep 2013 08:22:46 -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=cSWNdnzJVN+rYfMTC6mGeTdwiav9brPaNgdkADcfg6Y=; b=hIxwE4JAlC8GdBQnBxRjBIO0CxS0mukCNRrEvVKqg1WwP0r9WcNPHUQE+7DjP+GWWh HI/A/iB8CxsFbIMW4D5sHwk1e7918UzvLJbAbzzaP60N1fWQhOIiW36xLrVB2eoa/jnp fGIy7h2U1OKRRsUZohfgqRvKtE0E4IZzVy/pLfGKDfu8/tXG1fp070zY1p1ryWQpfNgn Dk21FM6hMnvY1wOjZAveT3j6/UX7fEBPNfvRDrGtUsd4CaOkrhNvY3tW2WvNQJBZmam4 HY0M2m4hvhnrO94UzQUQystOPetND2ueMpbvtsQBngWmRLdCfDjKrmrMFGLJ0gavESOs H4sg==
X-Gm-Message-State: ALoCoQnAlpltvVaZWxky6PsWuMqOTzmKpOggGDioihCaymUGKoWkeO9eMiwSPxAI2u35cYuFvNzC
X-Received: by 10.229.30.7 with SMTP id s7mr45622781qcc.7.1380122565057; Wed, 25 Sep 2013 08:22:45 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id u3sm66442432qae.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 08:22:44 -0700 (PDT)
Message-ID: <5242FFC7.7020302@nthpermutation.com>
Date: Wed, 25 Sep 2013 11:22:47 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Paul Bakker 
References: <523DF3AF.6060208@nthpermutation.com>	 <52425A2A.3060401@nthpermutation.com> <016201ceb9ce$ccc77bb0$66567310$@offspark.com>
In-Reply-To: <016201ceb9ce$ccc77bb0$66567310$@offspark.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] New Key derivations for TLS1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 15:22:56 -0000

On 9/25/2013 5:08 AM, Paul Bakker wrote:
>> Simply by adding the length fields to the KDF inputs used with the key
>> material exporters.  So if an exporter needs 4 keys, there are 4 length
>> values, 2 keys, 2 length values etc.   That makes what gets passed into
>> the KDF the secret, the public values including the label,  and the length
> of
>> each key and that construct can be used for the pre-master to master,
>> master to key expansion and for any key exporters.  This is just an
> off-the-
>> cuff suggestion at this point.
>>
>> One other alternative is to only provide lengths for keys - anything
>> after the end of the keys is public data.   That allows the
>> private/public division  of data consistent with the current model without
>> having to build a special function just for the key-expansion step.  And -
> if
>> you run this without providing any key lengths, you end up with the same
>> key stream as the old function -and that simplifies the
>> PKCS11 implementation.
> Wouldn't using the 'ciphersuite id' in the KDF provide the same (as the
> ciphersuite determines all those values) and is simpler in the process?
>

Considered that, but that would mean that a PKCS11 implementation would 
need to have the mapping between each and every TLS ciphersuite and the 
composition of its keys.  That would mean that each time a new cipher 
suite ID was issued, PKCS11 implementations would have to change.  Not 
the most general solution.

There's also this problem that the pre-master mechanism can be used for 
many different ciphersuites - and figuring out how to make sure policy 
controls apply to the downstream (master, key expansions, etc) keys is a 
pain.

Mike




From brian@briansmith.org  Wed Sep 25 08:29:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF411E8119 for ; Wed, 25 Sep 2013 08:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HveteCaUtOpu for ; Wed, 25 Sep 2013 08:29:18 -0700 (PDT)
Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF2A721F9D94 for ; Wed, 25 Sep 2013 08:29:05 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id jt11so6143325pbb.24 for ; Wed, 25 Sep 2013 08:29:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=19nJyesbwYa9ZF7Bi7PjX+243k9U0hxOXpsCmNik2nI=; b=f+zuIWntJZ8CrMJldyidMH2+uNJt2ViHUNNzCATfZJiy6cjSGsGBHH2I3FSvJCrj17 UNqlvP3faYbSfHHPM2eM0H35AANzsw6Cq57gYTlxYn6gsCcdmRs018l9du2F4uZeei+w kMJdrVhXhgWih5WbfGeyaUs3ykuIzx4KhhGexBfuwqiWpXFXsVVTLFjGTtKw/w/3n6rQ E99pxFk9HDmustOjdQOoshiwhhZWLH7FQyhyF0TbP/zrhjq9zzYIkn+daGRVdvD9piDr KG90q/D3Mdnnu91GgkkazbNgWSGjA06pIwNIflY24obxJJAQlGmDHfHC7k35Tcnc9x5t 6iHw==
X-Gm-Message-State: ALoCoQkbTzAJctrmfhaWcx7d7H08IYhFB3KknaDjldmeajQDn2f9I3UcvedJ/EYVCggVdr6aqDLl
X-Received: by 10.67.24.7 with SMTP id ie7mr34419095pad.112.1380122944162; Wed, 25 Sep 2013 08:29:04 -0700 (PDT)
Received: from l7 (v-1045.fw1.sfo1.mozilla.net. [63.245.219.50]) by mx.google.com with ESMTPSA id qw8sm33629508pbb.27.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 25 Sep 2013 08:29:03 -0700 (PDT)
From: "Brian Smith" 
To: "'Adam Langley'" , "'Ben Laurie'" 
References: 	<522BE808.4090405@stpeter.im> <522C6892.4020206@drh-consultancy.co.uk>	<522C7FD8.1000301@drh-consultancy.co.uk>			 
In-Reply-To: 
Date: Wed, 25 Sep 2013 08:28:59 -0700
Message-ID: <424e01ceba03$f7d7b420$e7871c60$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQCsycyqT0jdzFuUDdBKrUAKAOZvRQHLhofAAO/2YMYA5kMVQAJ0iIFoAgJcbdwCQv2oRgIN6y9nm7cYb2A=
Content-Language: en-us
Cc: tls@ietf.org
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 15:29:31 -0000

Adam Langley wrote:
> The cost of making any change to TLS is mostly equal to any other,
> since the bulk of the cost is in deployment. Using an extension to
> negotiate encrypt-then-MAC is a simple change, but it still leaves us
> with CBC mode. On the other hand, AES-GCM left the station some years
> ago and has a clear head start.
> 
> AES-GCM does, currently, depend on TLS 1.2, which is proving to be a
> pain to deploy on the public Internet as a client, but we'll get there
> soon.
> 
> I don't believe that this change solves the problem for SSLv3 as SSLv3
> doesn't have extensions and so cannot negotiate it. Once AES-GCM is
> running I'm hoping to simply define those ciphersuites all the way
> down the versions in order to solve version downgrade issues.
> 
> Having an alternative to AES-GCM is certainly valuable, but I don't
> want it to be AES-CBC. I think the prior discussion around
> Salsa20/Chacha20 and a polynomial MAC is the most promising direction
> for that.

All of the above matches my position as well. I don't see a lot of long-term
future in CBC-based cipher suites within browsers except as a legacy
mechanism. For example, we (Mozilla) have already decided not to offer any
SHA2- or SHA3- HMAC CBC cipher suites in Firefox, even when we enable TLS
1.2 and even though our TLS implementation already implements SHA256-HMAC
cipher suites. Adam's recent changes to NSS and OpenSSL have demonstrated
how to implement the existing encrypt-then-MAC construction in a way that
addresses the most acute known issues with the current CBC construct in TLS.
AES-GCM and soon new side-channel-free AEAD cipher suites (probably based on
Salsa/ChaCha) provide alternatives for implementations to avoid the CBC
construct altogether.

The downgrade issue only affects incorrect implementations of TLS like ours
(Firefox and other browsers); I think that the implementers of these
problematic products are best off working on a more general solution to the
downgrade issue, instead of encouraging more one-off workarounds for it. We
should focus our effort in this area to standardizing the side-channel-free
AEAD cipher suites and on verifying interoperability of AEAD cipher suites
(AES-GCM and new constant-time ones) even when the protocol version
negotiated on the wire is less than TLS 1.2. If we can't make that work then
we can re-consider our options.

> I've no objection to this ID, but nor am I esp excited by it.

Though I don't have any intentions to deploy it in Firefox at the current
time, I also have no objections to this ID, and in particular I encourage
the assignment of an extension ID for it if work is going to continue on it.
More generally, I think we should lower the bar for getting an extension ID
to "somebody has written a document describing what it means that isn't
completely crazy." I am not even sure that the "that isn't completely crazy"
qualifier is necessary. WHATWG asks that people register link relations
(e.g. "foo" in "") by simply editing a wiki, and that hasn't
caused any problems in practice.

I know there exist TLS implementations that aren't browsers and I am biased
towards considering browsers' needs over others. But, I think it is worth
considering how likely it is that this will be adopted by browsers when
considering if/how to move forward with it.

Regarding the particulars of the ID:

Section 3.1. (Rehandshake Issues) seems overly complex. I think this
extension should be connection-level, not session-level. Imagine a browser
that contains a preference that controls whether we support the extension.
It would be best if we could create a session with that preference set to
one value and then resume that session with the preference set to the
opposite value. Also, the Chromium team experienced interop issues due to
the negotiated compression algorithm being part of the session state. Based
on that experience, I would expect interop similar issues if this were made
part of the session state.

Section 4 (Security Considerations) would be better if it listed specific
ways that the encrypt-then-MAC construct is currently known to be better
than state-of-the-art (i.e. Adam's constant time) implementations of the
MAC-then-encrypt construct, in the context of TLS's CBC cipher suites. The
draft cites Krawczyk's paper for motivation but Krawczyk's paper says that
there is nothing to worry about as long as the encryption mode is CBC,
right?

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)



From mike-list@pobox.com  Wed Sep 25 09:39:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9C321F9BC2 for ; Wed, 25 Sep 2013 09:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level: 
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwFzLQn58mrn for ; Wed, 25 Sep 2013 09:38:59 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9411E812C for ; Wed, 25 Sep 2013 09:38:59 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 82F0FD336; Wed, 25 Sep 2013 12:38:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=k/LYnYoMA6LJ ivFHr4uqdQrFH/w=; b=OQtoU+hXrPXl/jicVHjRWy9OD06IPrlilf0KeUqA1Vkw uQk2LtmqdQ5WKIiY4K+GfL/iFKVZc4X+5AhaJrVRRLSZLmk/0SlLyxID8OOON34q oCPV0XZ4QU31RTus2VTQHIIiZWTiXbcN4vr2d7u4olEl9bt9C9Xv3eRbYnPbMI0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ETZlpg C+iJhGiHO4PklDOG09LPa/r7cuUN0DTYih2QS9WUtgfStFLnxfh5tyMhUO6kbhYZ sJYsJQeKaJ2HrYhry/Un0oIgDLjE/LzEC0MsUKR4goSgpKQbK3MPi1PF+RwVnWoV HK/VLkkdZanEOjD6R/F7PYmGif8Oa3dw/eCAM=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 6FE84D335; Wed, 25 Sep 2013 12:38:58 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 894FED334; Wed, 25 Sep 2013 12:38:57 -0400 (EDT)
Message-ID: <5243119D.4070001@pobox.com>
Date: Wed, 25 Sep 2013 09:38:53 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Adam Langley 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: F972F088-2600-11E3-B10F-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: "" 
Subject: Re: [TLS] Comments/Questions on	draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 16:39:04 -0000

Adam Langley wrote:
> On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller  wrote:
>> So maybe the right fix to this kind of problem is to adapt an idea from
>> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite value
>> that would *only* be used in SSL 3.0 connections by clients that have
>> downgraded, and tells the server "If you can read this, tear down the
>> connection because we shouldn't actually be using SSL 3.0 for this
>> connection"?
> 
> (I think I would want such an SCSV to indicate TLS 1.2 support rather
> than TLS 1.0 support, but that's just a detail.)

Instead of particular versions, it seems to me that an indicator of "I
tried to connect using a higher version than I'm using now but had to
fall back to this verion" would cover any case now or later.

The server would respond with an extension value indicating whether it
intends to communicate over the channel using the negotiated version or
not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
or SSLv3, for example.)  Both sides would continue the handshake through
completion to ensure that everything is legitimate.

Mike

From yaronf.ietf@gmail.com  Wed Sep 25 10:47:51 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEDEF21F99DC for ; Wed, 25 Sep 2013 10:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.486
X-Spam-Level: 
X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZLOcT6XZ0lq for ; Wed, 25 Sep 2013 10:47:51 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CA29F21F96B1 for ; Wed, 25 Sep 2013 10:47:48 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id q16so3369306ead.35 for ; Wed, 25 Sep 2013 10:47:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=MLRo5GU0pVyyahRC/umr9flwKyoie1fvttF9Sey6G54=; b=IFP8z7eNdmP/jUF0HkCW7EMM6PPM9ovNGEoneMTAEg9/49ojlqi1fqxRg3gFUWqUjA Fu5QhHgqiTlBp7K04PFsWsA73YXN3PMVBZ1J7sEbM1iVyoUJTA5mLgAKbSt7XO9zgkw0 rjrDrXuRQpCp+XrPdXjtL9X2NQhe0uBUEZWRk5holvQjbZC4wWE29nLSsZ9XH8t7lbOg +PffJLelIGq0WMZxonSPkB244PG1kFkHhnOR7GGOm0J4jrNW5k7TLu2ltqCs6Bt0UUGh +ws7a36Ag5H7CeaL9HYTwa5oMNZgMxKi4nuMpSLxvrqUBrcpwrwFMZB6WYUayDEFeRZY kclg==
X-Received: by 10.14.224.198 with SMTP id x46mr5903567eep.53.1380131267749; Wed, 25 Sep 2013 10:47:47 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id x47sm68035400eea.16.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 10:47:47 -0700 (PDT)
Message-ID: <524321C1.5080001@gmail.com>
Date: Wed, 25 Sep 2013 20:47:45 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Michael D'Errico ,  Adam Langley 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>		 <5243119D.4070001@pobox.com>
In-Reply-To: <5243119D.4070001@pobox.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 17:47:51 -0000

This discussion seems to really be about enforcing the following policy:

If the client can speak TLS 1.X but the "network" (middlebox) only 
allows TLS 1.Y, then, even though the server will happily negotiate TLS 
1.Y with other clients, it will reject this client and will not allow it 
to connect from inside this network.

Organizations often enforce weird and misguided policies on their users, 
e.g. forcing them all to use IE6 so that "legacy applications" do not 
need to be upgraded. Mind you, those older browsers only speak older 
SSL/TLS versions and *their* connections will still go through! 
Employing such middleboxes is just another policy of this type. Is it 
really our business to counteract the organization's policy?

Thanks,
	Yaron

On 09/25/2013 07:38 PM, Michael D'Errico wrote:
> Adam Langley wrote:
>> On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller  wrote:
>>> So maybe the right fix to this kind of problem is to adapt an idea from
>>> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite
>>> value
>>> that would *only* be used in SSL 3.0 connections by clients that have
>>> downgraded, and tells the server "If you can read this, tear down the
>>> connection because we shouldn't actually be using SSL 3.0 for this
>>> connection"?
>>
>> (I think I would want such an SCSV to indicate TLS 1.2 support rather
>> than TLS 1.0 support, but that's just a detail.)
>
> Instead of particular versions, it seems to me that an indicator of "I
> tried to connect using a higher version than I'm using now but had to
> fall back to this verion" would cover any case now or later.
>
> The server would respond with an extension value indicating whether it
> intends to communicate over the channel using the negotiated version or
> not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
> or SSLv3, for example.)  Both sides would continue the handshake through
> completion to ensure that everything is legitimate.
>
> Mike
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From mike-list@pobox.com  Wed Sep 25 11:57:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8D21F9CC6 for ; Wed, 25 Sep 2013 11:57:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.568
X-Spam-Level: 
X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PfnkBPRiSEZb for ; Wed, 25 Sep 2013 11:57:06 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 95B2921F9D38 for ; Wed, 25 Sep 2013 11:56:53 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5C370DE94; Wed, 25 Sep 2013 14:56:50 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=LVAd3de9wbbV OiLN5vip5PzBI04=; b=lBkmobkKrOATJYwej3baheQIMyk4A49wIv+Uh6VjDxbs 4aQqisMseyKoQj3C0NEQbtjRrzWq8kOmPTD0f6txpULiAnSyQPrjrgSK9lZcGeoo N1gz6qHhuyDrw68wFhWJUdY7F7tAMTYbCmX27ZycanA0Fm+pyot7zm1Tqp62Tjk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=T0dLBK SHvCWoNaLursNeyyFosf46DT/+rugDh4DhTwXg6N9sHj9uFwrLcO9UMtQmBmNhlN WPjZmYTaNA61ebaHdymg+KtLQkAbCZ1W7+KbuJP6x6FX892yqioH5HZOruZUqSP+ acdCh+YrPeYznSE3lkj/oul2F30Cwl91UfTH8=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 52AB6DE93; Wed, 25 Sep 2013 14:56:50 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 6CE8CDE92; Wed, 25 Sep 2013 14:56:49 -0400 (EDT)
Message-ID: <524331F0.1090905@pobox.com>
Date: Wed, 25 Sep 2013 11:56:48 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yaron Sheffer 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>		 <5243119D.4070001@pobox.com> <524321C1.5080001@gmail.com>
In-Reply-To: <524321C1.5080001@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 3BD9C9FC-2614-11E3-B651-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 18:57:11 -0000

Yaron Sheffer wrote:
> This discussion seems to really be about enforcing the following policy:
> 
> If the client can speak TLS 1.X but the "network" (middlebox) only 
> allows TLS 1.Y, then, even though the server will happily negotiate TLS 
> 1.Y with other clients, it will reject this client and will not allow it 
> to connect from inside this network.

No.  A server that is happy to use TLS 1.Y wouldn't reject the clients
who first tried 1.X.  The discussion is about adding a mechanism for a
client to inform the server that it couldn't connect using a higher
version, and then also for the server to acknowledge that back to the
client.

Such a mechanism would provide a way to detect problematic paths/routes,
i.e. middleboxes, and also any active downgrade attacks.

Mike



> Organizations often enforce weird and misguided policies on their users, 
> e.g. forcing them all to use IE6 so that "legacy applications" do not 
> need to be upgraded. Mind you, those older browsers only speak older 
> SSL/TLS versions and *their* connections will still go through! 
> Employing such middleboxes is just another policy of this type. Is it 
> really our business to counteract the organization's policy?
> 
> Thanks,
>     Yaron
> 
> On 09/25/2013 07:38 PM, Michael D'Errico wrote:
>> Adam Langley wrote:
>>> On Wed, Sep 25, 2013 at 7:03 AM, Bodo Moeller  wrote:
>>>> So maybe the right fix to this kind of problem is to adapt an idea from
>>>> draft-rescorla-tls-version-cs-00 and create a signalling ciphersuite
>>>> value
>>>> that would *only* be used in SSL 3.0 connections by clients that have
>>>> downgraded, and tells the server "If you can read this, tear down the
>>>> connection because we shouldn't actually be using SSL 3.0 for this
>>>> connection"?
>>>
>>> (I think I would want such an SCSV to indicate TLS 1.2 support rather
>>> than TLS 1.0 support, but that's just a detail.)
>>
>> Instead of particular versions, it seems to me that an indicator of "I
>> tried to connect using a higher version than I'm using now but had to
>> fall back to this verion" would cover any case now or later.
>>
>> The server would respond with an extension value indicating whether it
>> intends to communicate over the channel using the negotiated version or
>> not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
>> or SSLv3, for example.)  Both sides would continue the handshake through
>> completion to ensure that everything is legitimate.
>>
>> Mike

From SRS0=M8uh=TF=acm.org=bmoeller@srs.kundenserver.de  Wed Sep 25 11:57:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD9011E8111 for ; Wed, 25 Sep 2013 11:57:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.445
X-Spam-Level: 
X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02F0wLhZWv07 for ; Wed, 25 Sep 2013 11:57:35 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8121B21F9CC6 for ; Wed, 25 Sep 2013 11:57:13 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LeM6H-1WEQeo3V1R-00q7NH; Wed, 25 Sep 2013 20:57:12 +0200
Received: by mail-ob0-f172.google.com with SMTP id gq1so183965obb.31 for ; Wed, 25 Sep 2013 11:57:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/gwvXbO9OlaphgW+TUItjXJoON0Dfj8q8vcVOCeDekA=; b=B9/mXkxJJRBcjW7oUycjm08iCx68zZW29Czya1gqzzAhJJ/YR6a2VtD9MJfQwdrOnR D5qCCOluPUbmz65zkLRhQlQkkQDru6bZSnDvS2nM8DEpwsxOJISjkHIZLX1FAxupsEPf BTLeytmdNQQa+5YEJJcpycxrQ4UbTa28RriEwB8lzJWwbVf1MaNHVy5DAzeeeBvXXK20 reZ0YlqlHUQ2pBj0Z3JmKSN8X+WU8tYLJ40kbAn/So9AYi7oWXR2aJGSvvt2kECTR1c1 nNiFSzw72olwpAedfSKdjJuvKeEuXAq59lu6SnYXOUYITE+WXMPuonIKy7sHFdVJ7LCz oQ2Q==
MIME-Version: 1.0
X-Received: by 10.60.136.226 with SMTP id qd2mr1954220oeb.20.1380135430626; Wed, 25 Sep 2013 11:57:10 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Wed, 25 Sep 2013 11:57:10 -0700 (PDT)
In-Reply-To: <5243119D.4070001@pobox.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>   <5243119D.4070001@pobox.com>
Date: Wed, 25 Sep 2013 20:57:10 +0200
Message-ID: 
From: Bodo Moeller 
To: "Michael D'Errico" 
Content-Type: multipart/alternative; boundary=047d7b47247015a6ee04e739d2b0
X-Provags-ID: V02:K0:yTAC2/QZQTxEgGZAbeBX971QATapNRBCh5sG5TTyAMh n9wU2zBTG7EvwedIrM6gzW0illDXnm4t6Yb3pBsViEUA0QZKpE pkFp6otibeefuhWmm3gKOO+jD4i7lUScSOZSW2yguP8f27dZJg m5MWUfH5RWjoghZq30cIHP0AsqdJd/Ost6JK/wT4v7XNJUSRk5 i3gjmaNtE4LZfjDUp7ezyCc50eNXKrp1NrRzPONtFony83J/DC XVhA5iQmk4iB5riNS5R6OjDPMN0m8cQ6t15bDmnjLAacKLlIr8 0+rYkf/WAu6QbQ9cwS4tVpXjFg93zPe/mn2HVVbcJO8lZEUOju uZ3xg10q2timiwIRdXwgwOsBKCU9BGdqfuJr1XzvP7FpCt34UP tOMzINSOJINHcnLaDAFVdy7uEFRqN1PAAGQQW6fgts9atFBjYp 2CP9A
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 18:57:43 -0000

--047d7b47247015a6ee04e739d2b0
Content-Type: text/plain; charset=ISO-8859-1

> Instead of particular versions, it seems to me that an indicator of "I
> tried to connect using a higher version than I'm using now but had to
> fall back to this verion" would cover any case now or later.
>

Indeed that's what I ended up writing down for an Internet Draft.

The server would respond with an extension value indicating whether it
> intends to communicate over the channel using the negotiated version or
> not.  (It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.0
> or SSLv3, for example.)  Both sides would continue the handshake through
> completion to ensure that everything is legitimate.
>

If everything *is* legitimate (and the implementations are correct), the
initial handshake with no downgrade should have gone through (and
negotiated the highest common version).  So I think all that's called for
if there's a problem with a downgraded connection is a fatal alert.

Bodo

--047d7b47247015a6ee04e739d2b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=


Instead of particular versions, it seems to me that an indicator of "I=


tried to connect using a higher version than I'm using now but had to
fall back to this verion" would cover any case now or later.

Indeed that's what I ended up writing down f=
or an Internet Draft.



The server would respond with an extension value indicating whether it

intends to communicate over the channel using the negotiated version or

not. =A0(It may be OK with a TLS 1.2 -> TLS 1.1 downgrade, but not to 1.=
0

or SSLv3, for example.) =A0Both sides would continue the handshake through<=
br>
completion to ensure that everything is legitimate.
If everything *is* legitimate (and the implementations are cor=
rect), the initial handshake with no downgrade should have gone through (an=
d negotiated the highest common version).=A0 So I think all that's call=
ed for if there's a problem with a downgraded connection is a fatal ale=
rt.


Bodo



--047d7b47247015a6ee04e739d2b0--

From SRS0=M8uh=TF=acm.org=bmoeller@srs.kundenserver.de  Wed Sep 25 12:01:05 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D6721E8094 for ; Wed, 25 Sep 2013 12:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.463
X-Spam-Level: 
X-Spam-Status: No, score=-1.463 tagged_above=-999 required=5 tests=[AWL=0.163,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bi+ZSmEsCM38 for ; Wed, 25 Sep 2013 12:00:57 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E76A21E8091 for ; Wed, 25 Sep 2013 12:00:44 -0700 (PDT)
Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mrelayeu.kundenserver.de (node=mreu2) with ESMTP (Nemesis) id 0MGVFc-1Vc3Tu2G8G-00DWsc; Wed, 25 Sep 2013 21:00:42 +0200
Received: by mail-ob0-f181.google.com with SMTP id gq1so191385obb.26 for ; Wed, 25 Sep 2013 12:00:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DuxGoQisaYbAzAkl0i8JynSZ6bifu+g1Fx0vsYEaP7Q=; b=HJO6BgEUjqV9DtLU+hPwz3aFIUnSWXnrBTd2eEmakJGFkbf9nBtdLho9QspO6bszpW SqvZQ4IPw55ndXMcsRq1CFr8tm2QpbaSb9bDWQ48tfqzB1N9Z4nIXT/y1SU5DJx0KR2m b3inz0fhAVFJP0OtxUfV4AX2OYSijhDO71f80Z4U4FOgc8cyhfXJtIvWZQmzwwLMvfjp ay/6wTX27R9K9QGyOoR27vE1noHjszJ9t5CHwlJBJI4KAk4DwUwTqs41WgHnv4MWAzEX NAlhk7wOe3JAGx8IuJxdvbzJPjK1Abox9+n+OTbvFYiFf1CBtp4lhHwvUstZj7WZm7nO zKmQ==
MIME-Version: 1.0
X-Received: by 10.60.65.227 with SMTP id a3mr31476183oet.13.1380135641349; Wed, 25 Sep 2013 12:00:41 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Wed, 25 Sep 2013 12:00:41 -0700 (PDT)
In-Reply-To: <524321C1.5080001@gmail.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>   <5243119D.4070001@pobox.com> <524321C1.5080001@gmail.com>
Date: Wed, 25 Sep 2013 21:00:41 +0200
Message-ID: 
From: Bodo Moeller 
To: Yaron Sheffer 
Content-Type: multipart/alternative; boundary=001a11c25700a50c8504e739de53
X-Provags-ID: V02:K0:Rv2yAuB1C7DreZPiXtG10LCbgYs5EpyjiQHaaZ5jeeN FDBF24s86wO/Q94VYlHAin1XAWZjj3TAWO7prCzq3C2Ew0GBW+ a1JGJ4IBK+xTeUaXWhf+L2blS2KEmCck2eqQ3ul/+diU3kCGpS 6RQ/khMqGeR2paqLrQjTgtLUmcddiiDrMPhlDwO7HWfqAKYFYE vWXBt5pjebGpwrq61GgX65pDoEy+dhycWLED5/vlalRRD+eTfi gO7zMPY/KZpBLWDk1+elmfXCGJbrl9BDvfg1K/BUuK/E4AFu+n XJtq2ntzKT7WNUMezAnud5mnskw9lfX7uKyFm/2nBAF/8egXYL sjW91ZxW30f0/XNmfFENZvNx5QMTkgmpbC6hCHddSYtgk11Bf1 ahyBRaAsoOe2eQZ7Nouv6duFyZfVW4YG1eNUC+D681p5U3+nDo QKwXk
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 19:01:05 -0000

--001a11c25700a50c8504e739de53
Content-Type: text/plain; charset=ISO-8859-1

> Organizations often enforce weird and misguided policies on their users,
> e.g. forcing them all to use IE6 so that "legacy applications" do not need
> to be upgraded. Mind you, those older browsers only speak older SSL/TLS
> versions and *their* connections will still go through! Employing such
> middleboxes is just another policy of this type. Is it really our business
> to counteract the organization's policy?
>

Certainly, because we don't know if "the organization" that's trying to
downgrade your connection are your local network admins, or a foreign
government agency.  This doesn't mean there couldn't be a knob allowing you
(or your admins) to disable the security check, but the protocol should
have means to detect this kind of problem.

--001a11c25700a50c8504e739de53
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=


Organizations often enforce weird and misguided policies on their users, e.=
g. forcing them all to use IE6 so that "legacy applications" do n=
ot need to be upgraded. Mind you, those older browsers only speak older SSL=
/TLS versions and *their* connections will still go through! Employing such=
 middleboxes is just another policy of this type. Is it really our business=
 to counteract the organization's policy?



Certainly, because we don't know if &q=
uot;the organization" that's trying to downgrade your connection a=
re your local network admins, or a foreign government agency.=A0 This doesn=
't mean there couldn't be a knob allowing you (or your admins) to d=
isable the security check, but the protocol should have means to detect thi=
s kind of problem.




--001a11c25700a50c8504e739de53--

From yaronf.ietf@gmail.com  Wed Sep 25 12:26:43 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D635521F9E50 for ; Wed, 25 Sep 2013 12:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.494
X-Spam-Level: 
X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttSKzydjLbWf for ; Wed, 25 Sep 2013 12:26:43 -0700 (PDT)
Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83A21F9E46 for ; Wed, 25 Sep 2013 12:26:36 -0700 (PDT)
Received: by mail-ea0-f174.google.com with SMTP id z15so57455ead.5 for ; Wed, 25 Sep 2013 12:26:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DFTgUCqkc1MEkikD629OlNB7yO7GzW9oxTKB9kaD22c=; b=v4/rYgh53XXDZGe00jF6zOL4CN+n/0sCOn7+jh2l5xo07h2avPUmCxTHBNr/6Xc4el dm74jk0XkfTFzHTd8wlA8Rl2Ng6r6+g3CuUIv1xh2cLIvYa50lg7kNi4a8yx76qe+TJm EHEwnBX/OaN8uSNovD0QBClGeGCOlzDsxV9TeNGQe6NKU3hoHgO/WcIX0cKQiXu6lUY3 ZX8BrH5fGOmA/Or4LMC27O+7dTmh+J5aIq1RkC/84iJrc9ouOCww59xzWjiLAyH5UH7o PMZNxVUfavXyfpRU7M8HuatDArSBgU5207gpzXIkUIbIfVDJTjNAutmUOYhiKpV8XQy+ xiQg==
X-Received: by 10.15.45.8 with SMTP id a8mr57778076eew.1.1380137194712; Wed, 25 Sep 2013 12:26:34 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id f49sm68919421eec.7.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 25 Sep 2013 12:26:34 -0700 (PDT)
Message-ID: <524338E8.6010300@gmail.com>
Date: Wed, 25 Sep 2013 22:26:32 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Bodo Moeller 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>			<5243119D.4070001@pobox.com>	<524321C1.5080001@gmail.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 19:26:44 -0000

It's one thing to "detect" these cases. Such detection is probably more 
effective on the server side, where there are admins that look at log 
files. I agree we should be providing both sides with the information.

It's another thing to recommend that servers always drop such 
connections. I don't think we should do that.

Thanks,
	Yaron

On 09/25/2013 10:00 PM, Bodo Moeller wrote:
>
>     Organizations often enforce weird and misguided policies on their
>     users, e.g. forcing them all to use IE6 so that "legacy
>     applications" do not need to be upgraded. Mind you, those older
>     browsers only speak older SSL/TLS versions and *their* connections
>     will still go through! Employing such middleboxes is just another
>     policy of this type. Is it really our business to counteract the
>     organization's policy?
>
>
> Certainly, because we don't know if "the organization" that's trying to
> downgrade your connection are your local network admins, or a foreign
> government agency.  This doesn't mean there couldn't be a knob allowing
> you (or your admins) to disable the security check, but the protocol
> should have means to detect this kind of problem.
>

From SRS0=M8uh=TF=acm.org=bmoeller@srs.kundenserver.de  Wed Sep 25 13:27:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E279321F93BA for ; Wed, 25 Sep 2013 13:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.478
X-Spam-Level: 
X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=0.148,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avyhpdZ5jfox for ; Wed, 25 Sep 2013 13:27:22 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by ietfa.amsl.com (Postfix) with ESMTP id A6B1E21F940D for ; Wed, 25 Sep 2013 13:27:19 -0700 (PDT)
Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0LrDs8-1Vsjf62osW-0139s0; Wed, 25 Sep 2013 22:27:17 +0200
Received: by mail-ob0-f176.google.com with SMTP id uy5so415779obc.35 for ; Wed, 25 Sep 2013 13:27:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=p+/qjRrhyk+mE15dyFZYgEKKH8HpzJ3eNoWiOP+jJXo=; b=R1gWCOsBFv3f3bA8wAou5qtxZQLsy5tKOfjeEtC4yjqPcgxjN/3c3u+fUkCAysFoCO 3gAcItkoMljFZFtGaRpUHoc1DkHs2xzkCHnempge9QJ82mQWzsHf/ru+BChD8pI3Lc+/ ZWj0HjCZUmWn+JunjXyobNzL/77oxgKPRSESATgibfRPhpicEEOQrw80mDIBUUpXL2O7 xkWPee5UQzGCqTBXuMioAjloUkNLTmuAV7vKFelN5fLdEW3mYufiz5SFOka2qwfTRVkJ HrMogL5usk4jWAvO1Bfu2Z4h6nt51cfpap4E1JyDDEMHEdJPgrBGX7yqkbopFE+RYBvu 44Sw==
MIME-Version: 1.0
X-Received: by 10.60.43.131 with SMTP id w3mr32108057oel.10.1380140835424; Wed, 25 Sep 2013 13:27:15 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Wed, 25 Sep 2013 13:27:15 -0700 (PDT)
In-Reply-To: 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>   <5243119D.4070001@pobox.com> 
Date: Wed, 25 Sep 2013 22:27:15 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113346ce3c9ebf04e73b1462
X-Provags-ID: V02:K0:TLlWzHeS+Kx15F5aG3JFAY/tSoHhk/huBhXvnkukbUS U73PhbovKciWcDfXo9zbQi+Nh1QHnSGCxg0YO9xe+J25Qvp4zz fVXfnhOuKuMBR4qvXw+VOYbOY0vCqdbhPmyRnMH4DXZPDmuyAS W7evmDDHu+by90YCMB7RGhjuIUR8aqHLTMntpdDxjQvu4IbfUB 5dhHXlXd2dXEOkv99bQ4VoY8CqlizeuGDykSYOVXlYahE3J1m7 l55+Gep0IEooMuE3GfMkn1qo6gtJFxJfiY5tKx1wSCcKVyzUvP 73+9UZKI+Afwq3djNzqhbCSeCwyhYqLSsBApnndsfNWSEIm3Fu SETcvX19iKerz39ntU5RRlH3DCm7+Qf3g6o5T0BnAcHgp7dOM9 E2ckl88GoZ9BGthWDzv+MMW2MliLfs+1eF4uhTF3bKnRoB6J/A a83PX
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 20:27:27 -0000

--001a113346ce3c9ebf04e73b1462
Content-Type: text/plain; charset=ISO-8859-1

> Instead of particular versions, it seems to me that an indicator of "I
>> tried to connect using a higher version than I'm using now but had to
>> fall back to this verion" would cover any case now or later.
>>
>
> Indeed that's what I ended up writing down for an Internet Draft.
>

Now here:

http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

Bodo

--001a113346ce3c9ebf04e73b1462
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




--001a113346ce3c9ebf04e73b1462--

From SRS0=M8uh=TF=acm.org=bmoeller@srs.kundenserver.de  Wed Sep 25 13:35:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F38421F967F for ; Wed, 25 Sep 2013 13:35:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Level: 
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=0.136,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snlrK-Hy9-hF for ; Wed, 25 Sep 2013 13:35:15 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 23C6D21E805F for ; Wed, 25 Sep 2013 13:35:14 -0700 (PDT)
Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LnBmv-1W5hgD30qT-00hMLo; Wed, 25 Sep 2013 22:35:13 +0200
Received: by mail-ob0-f177.google.com with SMTP id wp18so442170obc.8 for ; Wed, 25 Sep 2013 13:35:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eKzh6jNcP0y+cE+2mQDeEJ6lgjKJWAZYuRvAGH26jrU=; b=B0HFp0bWDgldKz3fXidX3wT3Clw8i1C3MUT8to17q9SLdLQSOyi914tz9p6xKHVFOE x+XPWbbqE3EPde6B7bHh3EiytLQU/rsvwN8jNdmOT97kyqgVtcv/f8K1JS4u15F9FwPq ozebYm1f1GG4Qc5TUYj4ecacRo6QG/7teqN5BiTPZFt/yGJGG8N1GtQ1liC1pK9+GKNl u93lgLBLGQPFh5omC0ZGN8NYcrF87HyZTlz45tKUvDZ6ilYTezMEcbzCsg+GcgSD5yB+ NUBRD08OmYZDMMPQoE74Gd5WqNFs7Xwop1FHYoNgZMYsO/SaFI0k9kT6jCFcHm3WgDpy vyzQ==
MIME-Version: 1.0
X-Received: by 10.60.160.164 with SMTP id xl4mr2053113oeb.69.1380141311421; Wed, 25 Sep 2013 13:35:11 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Wed, 25 Sep 2013 13:35:11 -0700 (PDT)
In-Reply-To: <20130925202312.29986.21441.idtracker@ietfa.amsl.com>
References: <20130925202312.29986.21441.idtracker@ietfa.amsl.com>
Date: Wed, 25 Sep 2013 22:35:11 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e01176ac79bc58704e73b30fc
X-Provags-ID: V02:K0:9vExbt9v5im/CaeexI6ruKoBazeMPzTW6hWOHi+6PiX sY4lQ2MS940k+UwfY5tptvmHxQjt8vrfhGuSeYe0iaf16mqxNf oXo2kf5IMueyolPIuD4AqdNikqTZZoeOI2I5uDXOmQuIt65Z29 jvFKsNrl6PfOgp3K1b2nmhcy3VjfEh7KkN7qkLiym7H8fLXMrl lGO3z+XUHWEoRLk7K7h/icuamlbQgzQj2kLK+qLbJ3b4QbuCaq qp+Qf6nuaUojLEy8oUl00nAjRD8TlfkA7Ph467XlDwRKoXe7CO sTxMIpWmoFTI1xRE155Uy5JxykbleIkDKvL5TJEpfzsm2JtKaj iMpLhtPbKS0z2181Yvkp6lNZ+4Qghyn9zNyk4aCqS9jg0lGbNX f58J5mME1celRiBXgYc5OXbyE09MMNbh7pP8N/QV2Px7Md2iKv w732w
Subject: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 20:35:22 -0000

--089e01176ac79bc58704e73b30fc
Content-Type: text/plain; charset=ISO-8859-1

---------- Forwarded message ----------
From: 
Date: 2013/9/25
Subject: New Version Notification for
draft-bmoeller-tls-downgrade-scsv-00.txt
To: Bodo Moeller , Bodo Moeller 



A new version of I-D, draft-bmoeller-tls-downgrade-scsv-00.txt
has been successfully submitted by Bodo Moeller and posted to the
IETF repository.

Filename:        draft-bmoeller-tls-downgrade-scsv
Revision:        00
Title:           TLS Signaling Cipher Suite Value (SCSV) for Preventing
Protocol Downgrade Attacks
Creation date:   2013-09-25
Group:           Individual Submission
Number of pages: 10
URL:
http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
Status:
http://datatracker.ietf.org/doc/draft-bmoeller-tls-downgrade-scsv
Htmlized:
http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00


Abstract:
   This document defines a Signaling Cipher Suite Value (SCSV) that can
   be used to prevent protocol downgrades for Transport Layer Security
   (TLS).




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

--089e01176ac79bc58704e73b30fc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable




---------- Forwarded me=
ssage ----------
From:  <internet-drafts@ietf.or=
g>

Date: 2013/9/25
Subject: New Version Notification for draft-bmoeller-tls=
-downgrade-scsv-00.txt
To: Bodo Moeller <bmoeller@google.com>, Bodo Moeller <bmoeller@acm.org>





A new version of I-D, draft-bmoeller-tls-downgrade-scsv-00.txt

has been successfully submitted by Bodo Moeller and posted to the

IETF repository.



Filename: =A0 =A0 =A0 =A0draft-bmoeller-tls-downgrade-scsv

Revision: =A0 =A0 =A0 =A000

Title: =A0 =A0 =A0 =A0 =A0 TLS Signaling Cipher Suite Value (SCSV) for Prev=
enting Protocol Downgrade Attacks

Creation date: =A0 2013-09-25

Group: =A0 =A0 =A0 =A0 =A0 Individual Submission

Number of pages: 10

URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.iet=
f.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org=
/doc/draft-bmoeller-tls-downgrade-scsv

Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draf=
t-bmoeller-tls-downgrade-scsv-00





Abstract:

=A0 =A0This document defines a Signaling Cipher Suite Value (SCSV) that can=


=A0 =A0be used to prevent protocol downgrades for Transport Layer Security<=
br>
=A0 =A0(TLS).









Please note that it may take a couple of minutes from the time of submissio=
n

until the htmlized version and diff are available at tools.ietf.org.



The IETF Secretariat







--089e01176ac79bc58704e73b30fc--

From mrex@sap.com  Wed Sep 25 13:55:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E272E21F9E40 for ; Wed, 25 Sep 2013 13:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.156
X-Spam-Level: 
X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmHlnA2dBgVe for ; Wed, 25 Sep 2013 13:54:44 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8F43B21F9D95 for ; Wed, 25 Sep 2013 13:54:31 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8PKsO2s013741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 22:54:24 +0200 (MEST)
In-Reply-To: 
To: Bodo Moeller 
Date: Wed, 25 Sep 2013 22:54:24 +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: <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 20:55:01 -0000

Bodo Moeller wrote:
> > Instead of particular versions, it seems to me that an indicator of "I
> >> tried to connect using a higher version than I'm using now but had to
> >> fall back to this verion" would cover any case now or later.
> >>
> >
> > Indeed that's what I ended up writing down for an Internet Draft.
> >
> 
> Now here:
> 
> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

OH NO, not again!!

Any kind of specification for TLS, that suggests to the server
to apply heuristics and make (often flawed or unjustified) assumptions
about what the client may want or may not want and have the _server_
abort the handshake rather than the client, are a REALLY BAD IDEA and
squarely against the IETF spirit to promote interop.

Fatal SSL alerts in particular, are worst of all, because they do often
do not give any clue, are not ever sent by a number of TLS implementations
(you just see the connection close/reset), and are hardly/poorly visualized
or not even accessible on many TLS clients.

If anything, then such a "downgrade protection discovery" signaling
cihper suites should cause the server to respond with a ServerHelloExtension
listing the features that the server supports and would be capable
of processing properly when present in ClientHello, and leave the
decision, whether to abort the handshake and whether to tell or ask
the user about any perceived problems first, entirely up to the client.


-Martin

From mbadra@gmail.com  Wed Sep 25 14:08:24 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F3C21F8411 for ; Wed, 25 Sep 2013 14:08:24 -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=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ntT-NYbqGGrp for ; Wed, 25 Sep 2013 14:08:24 -0700 (PDT)
Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B441621F9C05 for ; Wed, 25 Sep 2013 14:08:04 -0700 (PDT)
Received: by mail-ve0-f171.google.com with SMTP id pa12so227097veb.30 for ; Wed, 25 Sep 2013 14:08:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UW6hIPTuZ0LTtgbyWArxybw3Vo49cZOTL1fZOLOzZwA=; b=iPrUeCDoVjVx1sXRkyWMtnKFsX4dcCbrqXZxzYub60TpNfjsFYiZK8zC5tk1pQFKpu C69J4kZbY2mnDcmy2DaskUHczKk+24wqyblqhQ3GTwJHaXXPT8mRR/ozMp5TdCjOSBII RHaXjjIo5Hwq4lmtCzcYPxsoTKVYnVGtWFXPdMwS85ULRMPLc8HGESmb+hJXGPBRE57I Fwsh+Cgudhe4tSW022xBxNS/RA9g4LX62Gm8ntXZV/BOedqoyZvoUPK+ovG5EwVL2GS8 JZopWIQrL4xSOqQxLEVZySz/iS6zf8P+8lQLtejdkUe8oJ1DOseedLa+LtcNTwZa5e4G nkNw==
MIME-Version: 1.0
X-Received: by 10.220.237.208 with SMTP id kp16mr34844599vcb.4.1380143283879;  Wed, 25 Sep 2013 14:08:03 -0700 (PDT)
Received: by 10.221.43.138 with HTTP; Wed, 25 Sep 2013 14:08:03 -0700 (PDT)
In-Reply-To: <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
References:  <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
Date: Thu, 26 Sep 2013 01:08:03 +0400
Message-ID: 
From: Mohamad Badra 
To: mrex@sap.com
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 21:08:25 -0000

On Thu, Sep 26, 2013 at 12:54 AM, Martin Rex  wrote:
> Bodo Moeller wrote:
>> > Instead of particular versions, it seems to me that an indicator of "I
>> >> tried to connect using a higher version than I'm using now but had to
>> >> fall back to this verion" would cover any case now or later.
>> >>
>> >
>> > Indeed that's what I ended up writing down for an Internet Draft.
>> >
>>
>> Now here:
>>
>> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
>
> OH NO, not again!!
>
> Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.
>
> Fatal SSL alerts in particular, are worst of all, because they do often
> do not give any clue, are not ever sent by a number of TLS implementations
> (you just see the connection close/reset), and are hardly/poorly visualized
> or not even accessible on many TLS clients.
>
> If anything, then such a "downgrade protection discovery" signaling
> cihper suites should cause the server to respond with a ServerHelloExtension
> listing the features that the server supports and would be capable
> of processing properly when present in ClientHello, and leave the
> decision, whether to abort the handshake and whether to tell or ask
> the user about any perceived problems first, entirely up to the client.
>
>
> -Martin

[reference] http://www.ietf.org/mail-archive/web/tls/current/msg08892.html

From mrex@sap.com  Wed Sep 25 14:10:12 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3479021F84EA for ; Wed, 25 Sep 2013 14:10:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.16
X-Spam-Level: 
X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.089,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBNx2i80cBHP for ; Wed, 25 Sep 2013 14:10:08 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9D121F9C0D for ; Wed, 25 Sep 2013 14:10:06 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8PL9s7m013138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 23:09:54 +0200 (MEST)
In-Reply-To: 
To: Alfredo Pironti 
Date: Wed, 25 Sep 2013 23:09:54 +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: <20130925210954.825521A9A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 21:10:12 -0000

Alfredo Pironti wrote:
> Peter Gutmann  wrote:
> > Eric Rescorla  writes:
> >
> >> - Maybe I am misreading the draft, but I'm unclear on how you get
> >>    the TLSCompressed.length for the MAC computation in Section 3.
> >>    Does this have the same issue as was raised for McGrew's CBC AEAD
> >>    draft?

Eric is correct, the definition of the MAC in Peter's draft is
obviously incorrect (and likely does not match Peter's implementation):

TLSv1.0:  https://tools.ietf.org/html/rfc2246#section-6.2.3.1

   The MAC is generated as:

       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
                     TLSCompressed.version + TLSCompressed.length +
                     TLSCompressed.fragment));

When changing from mac-pad-encrypt to encrypt-mac, as suggested
by Peter's draft, the MAC no longer operates on the TLSComressed PDU,
but on the TLSCiphertext PDU -- which results in:

       HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
                     TLSCiphertext.version + TLSCiphertext.length +
                     TLSCiphertext.fragment));

    The computation of TLSCompressed.length on receive changes slightly,
    because there no longer is a MAC trailing the data after decrypt.


-Martin

From mike-list@pobox.com  Wed Sep 25 14:17:16 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB09E21F8267 for ; Wed, 25 Sep 2013 14:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.57
X-Spam-Level: 
X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM-eXMEZ+nUo for ; Wed, 25 Sep 2013 14:17:12 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7211E80ED for ; Wed, 25 Sep 2013 14:17:09 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BC538D70F; Wed, 25 Sep 2013 17:17:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Npdk85IXYQ2u 8BJc2Z614A+CqxY=; b=Zj4jIw8VTtzq5ePE3QxHF9v5JC83OfhPMyzTQC8igx2O 5A7RKn10qQzRJlL0n5/JLiyYArF3WPgyDKiT6iY8LIjXfso0uTems0ySNGvTucSO U6aIcuvWWl51mj85VK2bWj2RH4sduj7t4mFm3ioF5tElggPyYxaqCIzYbi44kg8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=lgCGxl +fYisTCsWroblv7xzvw0iKxgSOzCoT575wAcmLPDC5rOLJNaiF8pU4gptAuThnZZ 6dzmjBVnX+PEJXPrnpI8RsXZYY+7v4+Ho1dgYh6uaO2e3Jb3VDvOf38UWJDSbxDY PBS21k1JeiWIqsHJuJzyg89upK91C68QWYKbY=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B1AA5D70E; Wed, 25 Sep 2013 17:17:08 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 0B7C1D70D; Wed, 25 Sep 2013 17:17:07 -0400 (EDT)
Message-ID: <524352D3.4020601@pobox.com>
Date: Wed, 25 Sep 2013 14:17:07 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Bodo Moeller 
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>			<5243119D.4070001@pobox.com>	 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: D5B3DBAE-2627-11E3-913F-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: TLS Mailing List 
Subject: Re: [TLS] Comments/Questions on	draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 21:17:17 -0000

> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt

I think that the server MUST send a FATAL alert only if it would
not have been willing to negotiate the lower TLS version in the
absence of the SCSV.

A WARNING alert from the server (or some extension_data with more
information) lets the client decide whether to continue.  Both
sides can keep track of these occurrences for further investigation
by interested admins at their leisure (not via calls to the help
desk).

Also RFC 3546 and 4366 have been obsoleted by RFC 6066.

Mike

From mrex@sap.com  Wed Sep 25 14:25:45 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485DF11E810F for ; Wed, 25 Sep 2013 14:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.163
X-Spam-Level: 
X-Spam-Status: No, score=-10.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tx4fu5E74NnQ for ; Wed, 25 Sep 2013 14:25:40 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 967C011E80DF for ; Wed, 25 Sep 2013 14:25:33 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8PLPWCX017452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 23:25:32 +0200 (MEST)
In-Reply-To: <20130925210954.825521A9A7@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Wed, 25 Sep 2013 23:25:32 +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: <20130925212532.B3FB01A9A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "" , Alfredo Pironti 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 21:25:45 -0000

Martin Rex wrote:
> Alfredo Pironti wrote:
> > Peter Gutmann  wrote:
> > > Eric Rescorla  writes:
> > >
> > >> - Maybe I am misreading the draft, but I'm unclear on how you get
> > >>    the TLSCompressed.length for the MAC computation in Section 3.
> > >>    Does this have the same issue as was raised for McGrew's CBC AEAD
> > >>    draft?
> 
> Eric is correct, the definition of the MAC in Peter's draft is
> obviously incorrect (and likely does not match Peter's implementation):
> 
> TLSv1.0:  https://tools.ietf.org/html/rfc2246#section-6.2.3.1
> 
>    The MAC is generated as:
> 
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
>                      TLSCompressed.fragment));
> 
> When changing from mac-pad-encrypt to encrypt-mac, as suggested
> by Peter's draft, the MAC no longer operates on the TLSComressed PDU,
> but on the TLSCiphertext PDU -- which results in:
> 
>        HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
>                      TLSCiphertext.version + TLSCiphertext.length +
>                      TLSCiphertext.fragment));
> 
>     The computation of TLSCompressed.length on receive changes slightly,
>     because there no longer is a MAC trailing the data after decrypt.

I forgot:
Peter's proposal includes the CBC-IV in the MAC computation for TLSv1.0,
but this isn't technically necessary.  In TLSv1.1, the MAC _must_
include the IV, but the IV is already part of TLSCiphertext.

Curiously, for decrypt, the way the TLSv1.1 GenericBlockCipher PDU 
is specified, it uses a fixed zero IV and a block-sized "random confounder"
that is covered by the MAC, but ignored after decrypt (reminds me of Kerberos)

-Martin

From mrex@sap.com  Wed Sep 25 14:32:28 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFEB21F8FB6 for ; Wed, 25 Sep 2013 14:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.167
X-Spam-Level: 
X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbcTID37SB3y for ; Wed, 25 Sep 2013 14:32:24 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2CD21F958A for ; Wed, 25 Sep 2013 14:32:21 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8PLWHeI026523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Sep 2013 23:32:17 +0200 (MEST)
In-Reply-To: <524352D3.4020601@pobox.com>
To: "Michael D'Errico" 
Date: Wed, 25 Sep 2013 23:32:17 +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: <20130925213217.5C39E1A9A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: TLS Mailing List 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 21:32:28 -0000

Michael D'Errico wrote:
> > http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
> 
> I think that the server MUST send a FATAL alert only if it would
> not have been willing to negotiate the lower TLS version in the
> absence of the SCSV.
> 
> A WARNING alert from the server (or some extension_data with more
> information) lets the client decide whether to continue.  Both
> sides can keep track of these occurrences for further investigation
> by interested admins at their leisure (not via calls to the help
> desk).
> 
> Also RFC 3546 and 4366 have been obsoleted by RFC 6066.

"Warning level alerts"?  Please don't!  As rfc6066 summarizes,
the last experiment of using warning level alerts failed badly
  -> "unpredictable client behaviour" and it is NOT RECOMMENDED.


Speaking of rfc 3546/4366/6066 "TLS Extensions":

  https://tools.ietf.org/html/rfc6066#section-3

                  If the server understood the ClientHello extension but
   does not recognize the server name, the server SHOULD take one of two
   actions: either abort the handshake by sending a fatal-level
   unrecognized_name(112) alert or continue the handshake.  It is NOT
   RECOMMENDED to send a warning-level unrecognized_name(112) alert,
   because the client's behavior in response to warning-level alerts is
   unpredictable. 

-Martin

From mrex@sap.com  Wed Sep 25 15:18:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A30821F9D0D for ; Wed, 25 Sep 2013 15:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.17
X-Spam-Level: 
X-Spam-Status: No, score=-10.17 tagged_above=-999 required=5 tests=[AWL=0.079,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iY4h-yIAcmE for ; Wed, 25 Sep 2013 15:17:56 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 43D9C21F9E02 for ; Wed, 25 Sep 2013 15:17:52 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8PMHmpl009838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Sep 2013 00:17:48 +0200 (MEST)
In-Reply-To: <424e01ceba03$f7d7b420$e7871c60$@briansmith.org>
To: Brian Smith 
Date: Thu, 26 Sep 2013 00:17:48 +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: <20130925221748.54BC01A9A7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 25 Sep 2013 22:18:01 -0000

Brian Smith wrote:
>
> Regarding the particulars of the ID:
> 
> Section 3.1. (Rehandshake Issues) seems overly complex. I think this
> extension should be connection-level, not session-level.

The reason why this draft needs to be complex, is that the TLS
protocol is signficantly underspecified for rehandshakes (aka renegotiation).
rfc5746 fixes only the renegotiation security vulnerability,
it does not remove all of the underspecifed areas.

When a paricular PDU content change is part of a TLS cipher suite
and negotiated through the cipher suite ID, then the PDU change
from current to new will happen with "ChangeCipherSpec" (seperate
for each direction of the communication).

PDU changes based on TLS protocol version and based on TLS extensions,
however, usually apply to ServerHello already.  There currently
is also no distinction between changes to Handshake message PDUs
(or addition, insertion or reording of Handshake message PDUs),
and changes to the Record Layer PDU -- the latter being subject of
Peter's proposal to fix the mac-pad-encrypt for Blockciphers with CBC.

Personally, I since believe it would be sensible to specify/define at
the TLS protocol level that any changes to the record layer PDU,
_independent_ of how they're negotiated (cipher suite, compression algs,
TLS extension) ought to universally apply to the first message following
ChangeCipherSpec.

Currently, this is undefined/unspecified in TLS.

Question to implementors:  The GenericBlockCipher PDU for TLSv1.0
and TLSv1.1 differs.  Do you know what your implementation currently
does should the TLS protocol version changes on a rehandshake/renegotiation
between TLSv1.0 and TLSv1.1 (up or down), why it behaves like it does,
and where this is specified?  ;-)


-Martin

From pgut001@cs.auckland.ac.nz  Wed Sep 25 16:26:47 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D8711E8111 for ; Wed, 25 Sep 2013 16:26:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level: 
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRFdIufqtppG for ; Wed, 25 Sep 2013 16:26:40 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 8AB5811E8113 for ; Wed, 25 Sep 2013 16:26:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380151586; x=1411687586; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=7vfF+yWJt4Cl+C0QzXGaPtK95UtgGKg55QknmsD5/+I=; b=VuEBDkNBnatcSvtddQxlJSFg6xyV+nylq/NeAA3fyMyfKFTApzYO7hio cSDBwe94mVsNRVxj9bcK7YbLvJT0uBVDDfej6JKsmS7csgCkXUNLlRclu wijwmldB1U4bDiEY7e2iSAdJ5IjH0T3H8BjN4sjTktSBREC5Wq6ny0JaG c=;
X-IronPort-AV: E=Sophos;i="4.90,981,1371038400"; d="scan'208";a="214200240"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Sep 2013 11:26:11 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 11:26:10 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac66RpxbzOshTMvxQ0G4GqgD9kBmog==
Date: Wed, 25 Sep 2013 23:26:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567D91D@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 25 Sep 2013 23:26:47 -0000

Bodo Moeller  writes:=0A=
=0A=
>Consider a client and server that both support a secure protocol version, =
but=0A=
>where the client will reconnect using an older protocol version if it=0A=
>suspects that that's necessary for interoperability.  Since in this scenar=
io,=0A=
>the client won't reliably know if handshake failures indicate interoperabi=
lity=0A=
>problems with the actual server or with an active attacker, having a secur=
ity=0A=
>fix that can be applied to the older protocol version as well has a clear=
=0A=
>benefit.=0A=
=0A=
Sure, but that's not specific to EtM, it affects any security mechanism=0A=
introduced in newer protocol versions.  I think draft-bmoeller-tls-downgrad=
e-=0A=
scsv-00 nicely deals with this in a general-purpose manner (i.e. not someth=
ing=0A=
specific to EtM).=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Wed Sep 25 21:27:26 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9263F21F9AA3 for ; Wed, 25 Sep 2013 21:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mbpVZhRtOjb for ; Wed, 25 Sep 2013 21:27:21 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id C593221F99C3 for ; Wed, 25 Sep 2013 21:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380169640; x=1411705640; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=1ol/5EzjjXCnB02f1fNVBHSh89XAjj3EOhXRBbcyhxc=; b=eIDcBCyPOO5qTuKpVWzkRK5uQhCzYICzxLhNZI2FWks7heM/GZtfFO86 xDLCbPyLXQP4GIYtaJkKrNXpKIjE8hzFS3YXWJItHYrsE4x+AQ5OywmTk 3azqol9y0ioiyZUsU8a4r7D85GFIM6dBHgTAg6tU0aIDWyW1csGbIwGam k=;
X-IronPort-AV: E=Sophos;i="4.90,982,1371038400"; d="scan'208";a="214283124"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Sep 2013 16:27:17 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 16:27:16 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac66cK4NqVuVho6TShis7a3twaoyzg==
Date: Thu, 26 Sep 2013 04:27:15 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567DB9B@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 04:27:26 -0000

Michael D'Errico  writes:=0A=
=0A=
>Instead of particular versions, it seems to me that an indicator of "I=0A=
>tried to connect using a higher version than I'm using now but had to=0A=
>fall back to this verion" would cover any case now or later.=0A=
=0A=
That seems more intuitively useful from the server admin's point of view,=
=0A=
you could use it to gather traffic stats on forced fallbacks, detect=0A=
middleboxes, and so on.  It'd also allow you to make informed decisions=0A=
on how far you want to fall back, for example you could use it to =0A=
determine that only 0.5% of users are having to fall back to SSLv3 and =0A=
therefore refuse to connect below TLS 1.0.=0A=
=0A=
Peter.=

From pgut001@cs.auckland.ac.nz  Wed Sep 25 21:54:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5C711E8146 for ; Wed, 25 Sep 2013 21:54:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wonMzXmy3V7u for ; Wed, 25 Sep 2013 21:54:43 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4559811E8155 for ; Wed, 25 Sep 2013 21:54:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380171279; x=1411707279; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=l8WMdIsNfMoH2LOtDEzryfuoFYP/YLd7GsAZCHNmKUo=; b=rugnTFzxH4k+6m7wgqDBeLTb6pgZybaLGbWwkLdL+uV8lGEJ3KM4DOdV lhYa/aGd8Wve40ayD6Y3s56+ikriKpI3LRWlmiTgE1B+ybKj4UfYxfOFc cjfKk3n6YztTKHq/Gpgb8cg9oHJrc3Xr46hNfsYUgXXrz0mtkmIqO5eE0 s=;
X-IronPort-AV: E=Sophos;i="4.90,982,1371038400"; d="scan'208";a="214289956"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing
Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Sep 2013 16:54:38 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 16:54:37 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac66dIBW3ZwfNpTEQoqPAuo5RGJ4tw==
Date: Thu, 26 Sep 2013 04:54:37 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567DBC6@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 04:54:49 -0000

Martin Rex  writes:=0A=
					 =0A=
>When changing from mac-pad-encrypt to encrypt-mac, as suggested=0A=
>by Peter's draft, the MAC no longer operates on the TLSComressed =0A=
>PDU, but on the TLSCiphertext PDU -- which results in:=0A=
>=0A=
>       HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +=0A=
>                     TLSCiphertext.version + TLSCiphertext.length +=0A=
>                     TLSCiphertext.fragment));=0A=
=0A=
So all that's necessary is to change the text to reflect this, and=0A=
perhaps a note to point it out?  That's fairly simple to do.=0A=
=0A=
Peter.=0A=

From pgut001@cs.auckland.ac.nz  Wed Sep 25 22:10:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD8311E8135 for ; Wed, 25 Sep 2013 22:10:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.586
X-Spam-Level: 
X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiCheDOQCr37 for ; Wed, 25 Sep 2013 22:09:57 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9443421F9E95 for ; Wed, 25 Sep 2013 22:09:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380172196; x=1411708196; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=gzYD1rOt1OqJYiOTcxTJEqCKbEzR8jzqIt1XPnLvE08=; b=Yvl7/mBDqfn8A3n0Uz8tgTn5579yFRE8yN+Ev8BaHbCMOnikJe+cgEbw 4sLfU9DIq7ue327E+ZzXC24JxjX4L1IzBeI8nnTMaUk8HlVApqxyUBAvM tnQCUKG5GyKyW/JzWA+wvFVEnqn4Y4hWYBHiHlNDJ+rZi1bSq7t6WNt63 I=;
X-IronPort-AV: E=Sophos;i="4.90,982,1371038400"; d="scan'208";a="214292756"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 26 Sep 2013 17:09:54 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 17:09:53 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] padding bug
Thread-Index: Ac66dmh5e0o65odvRG+KdOIeZQAqbQ==
Date: Thu, 26 Sep 2013 05:09:52 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567DBE8@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] padding bug
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 05:10:03 -0000

Brian Smith  writes:=0A=
=0A=
>Section 3.1. (Rehandshake Issues) seems overly complex. I think this=0A=
>extension should be connection-level, not session-level. Imagine a browser=
=0A=
>that contains a preference that controls whether we support the extension.=
=0A=
>It would be best if we could create a session with that preference set to=
=0A=
>one value and then resume that session with the preference set to the=0A=
>opposite value. =0A=
=0A=
Uhh, isn't that a security problem if you can rehandshake and turn EtM=0A=
off?=0A=
=0A=
(I don't have much of an opinion in this area since my code doesn't do=0A=
rehandshakes because I consider them too problem-prone, but if people =0A=
have concerns over this it'd be good to discuss them on the list.  My =0A=
solution is just "don't do that, then").=0A=
=0A=
>Section 4 (Security Considerations) would be better if it listed specific=
=0A=
>ways that the encrypt-then-MAC construct is currently known to be better=
=0A=
>than state-of-the-art (i.e. Adam's constant time) implementations of the=
=0A=
>MAC-then-encrypt construct, in the context of TLS's CBC cipher suites. =0A=
=0A=
I didn't do that both because it'd involve tracking down a decade's worth =
=0A=
of attacks on TLS to document them, and would be out of date as soon as=0A=
the next attack on MAC-then-encrypt is published.=0A=
=0A=
Peter.=

From yngve@spec-work.net  Wed Sep 25 22:50:30 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C477711E8159 for ; Wed, 25 Sep 2013 22:50:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38Jj6X7Upmop for ; Wed, 25 Sep 2013 22:50:26 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id D762D11E8153 for ; Wed, 25 Sep 2013 22:50:24 -0700 (PDT)
Received: from 228.72.202.84.customer.cdi.no ([84.202.72.228]:52846 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VP4T0-0002DS-Nu for tls@ietf.org; Thu, 26 Sep 2013 07:50:22 +0200
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References: <20130925202312.29986.21441.idtracker@ietfa.amsl.com> 
Date: Thu, 26 Sep 2013 07:50:12 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 05:50:30 -0000

Hi,

Please note that I have previously posted a draft describing an  
alternative approach which is client-side-only.

Document:  

Tracker:  


This approach uses the Renego Indication extension as a proxy indication  
of whether or not the server is version and extension tolerant (according  
to my most recent numbers, this is 99.74% accurate among current renego  
patched servers), and if the client finds, after a version rollback, that  
it has connected to a renego patched server, it then reconnects using its  
highest supported version, and if that fails, reports a connection failure.

According to my most recent numbers (collected during a full scale beta  
test of the new TLS Prober a month ago, so I am not 100% sure the numbers  
are fully correct, as I am not sure the current version is stable) 80% of  
servers in my sample now support the Renego patch. Among these 0.261% of  
the servers are version and/or extension intolerant when sent TLS 1.x  
version range Client Hellos

Among the 20% of servers that were not patched 4.22% were version and/or  
extension intolerant (essentially all were extension intolerant, only .5%  
of these intolerant servers were only version intolerant; among the  
intolerant renego patched servers the corresponding number was 13% only  
version intolerant).

In total 1.05% of servers are version and/or extension intolerant in the  
TLS 1.0-TLS 1.2 range.


The benefit of my proposal is that:

  - it only needs to be deployed client-side.
  - it does not require changes to the protocol, only to how the client  
handle a specific situation.
  - once clients only accept renego patched server this method, *and* the  
version rollback functionality can be removed.

There will initially be the downside of handling the .26% servers that are  
version/extension intolerant, but those can be quickly patched. There is  
also the problem of version/extension intolerant intermediates in the  
network that have been observed by the Google Chrome team.

In relation to Bodo's proposal, I think my proposal have the added  
benefits that:

  - It does not require any server-side updates
  - All servers that would implement Bodo's proposal would already have  
implemented the renego patch, and _should_ already be version tolerant (as  
seen above, not all are, but 99.74% are). This also applies in relation to  
any server that implements whatever the solution for the  
padding/encrypt-mac issue will be. As such Bodo's proposal will only be  
relevant for version rollback attack scenarios, or buggy intermediates,  
both of which my proposal handle client-side as a fatal error.

Bodo's solution do have the benefit that the server will learn about the  
version rollback, although in a version rollback attack scenario involving  
a sufficiently compromised protocol version I am not sure that the server  
will receive the signal (if so, this would also affect the renego based  
variation, but a client can take additional steps if it does not receive  
the renego extension, e.g. remove secure indications/padlock for the page).



I'll also note that two other approaches (proposed by EKR and Adam  
Langley) for this have been discussed the past two years, using SCSVs, and  
these and mine were discussed at the IETF-84 TLS WG meeting.




On Wed, 25 Sep 2013 22:35:11 +0200, Bodo Moeller  wrote:

> ---------- Forwarded message ----------
> From: 
> Date: 2013/9/25
> Subject: New Version Notification for
> draft-bmoeller-tls-downgrade-scsv-00.txt
> To: Bodo Moeller , Bodo Moeller 
>
>
>
> A new version of I-D, draft-bmoeller-tls-downgrade-scsv-00.txt
> has been successfully submitted by Bodo Moeller and posted to the
> IETF repository.
>
> Filename:        draft-bmoeller-tls-downgrade-scsv
> Revision:        00
> Title:           TLS Signaling Cipher Suite Value (SCSV) for Preventing
> Protocol Downgrade Attacks
> Creation date:   2013-09-25
> Group:           Individual Submission
> Number of pages: 10
> URL:
> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-bmoeller-tls-downgrade-scsv
> Htmlized:
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00
>
>
> Abstract:
>    This document defines a Signaling Cipher Suite Value (SCSV) that can
>    be used to prevent protocol downgrades for Transport Layer Security
>    (TLS).
>
>
>
>
> 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


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From p.j.bakker@offspark.com  Wed Sep 25 23:41:29 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B948811E815F for ; Wed, 25 Sep 2013 23:41:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZSAxsnpRlMM for ; Wed, 25 Sep 2013 23:41:23 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id E7EE911E8164 for ; Wed, 25 Sep 2013 23:41:21 -0700 (PDT)
Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VP5A0-0003wk-Sf; Thu, 26 Sep 2013 08:34:52 +0200
From: "Paul Bakker" 
To: "'Peter Gutmann'" , 
References: <9A043F3CF02CD34C8E74AC1594475C735567DBC6@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567DBC6@uxcn10-6.UoA.auckland.ac.nz>
Date: Thu, 26 Sep 2013 08:41:02 +0200
Message-ID: <007201ceba83$6164a130$242de390$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFhE9Rc+YY/ht8jD1tO4dwRZdRURpqy3GUQ
Content-Language: nl
X-SA-Exim-Connect-IP: 82.161.132.220
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 06:41:29 -0000

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
Peter
> Gutmann
> Sent: donderdag 26 september 2013 6:55
> To: 
> Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-
> mac-00.txt
> 
> Martin Rex  writes:
> 
> >When changing from mac-pad-encrypt to encrypt-mac, as suggested by
> >Peter's draft, the MAC no longer operates on the TLSComressed PDU, but
> >on the TLSCiphertext PDU -- which results in:
> >
> >       HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
> >                     TLSCiphertext.version + TLSCiphertext.length +
> >                     TLSCiphertext.fragment));
> 
> So all that's necessary is to change the text to reflect this, and perhaps
a note
> to point it out?  That's fairly simple to do.

I'm rather new to the list and late for this party..

But 'skipping' a layer (the TLSCompressed one in this case) is a bad idea
for a number of reasons.

Code path verification.
In case this comes to fruition, instead of the clean:
  "Assemble Data -> Compress -> Cipher -> Send",
 we get
  "Assemble Data -> Maybe hash in some specific cases -> Compress -> Encrypt
and sometimes hash in some specific cases -> Send"

This makes checking code correctness a step harder, aside from the fact that
suddenly cryptographic information (which used to be only required in the
Cipher layer) suddenly needs to be available on other points as well..
Meaning more coupling between layers and functions. This is bad in my
opinion!

Aside from the fact it's not pretty, there is a reason for having nice
separate layers, the fact that you can re-use / re-write the 'old buffer'
and do need to use unnecessary extra space. Violating that contract by
letting layers access the full data of another layer it should not see,
requires extra storage space, which on most embedded systems is very scarce.

I understand the issue, but in my opinion this is not the way to solve it.
So please reconsider solving the issue this way.

Paul


From p.j.bakker@offspark.com  Wed Sep 25 23:58:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F72A21F98AC for ; Wed, 25 Sep 2013 23:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Enkq06XJ0U3a for ; Wed, 25 Sep 2013 23:58:07 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3E72321F9767 for ; Wed, 25 Sep 2013 23:58:06 -0700 (PDT)
Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VP5Py-00040v-RF; Thu, 26 Sep 2013 08:51:24 +0200
From: "Paul Bakker" 
To: , "'Alfredo Pironti'" 
References:  <20130925210954.825521A9A7@ld9781.wdf.sap.corp>
In-Reply-To: <20130925210954.825521A9A7@ld9781.wdf.sap.corp>
Date: Thu, 26 Sep 2013 08:57:32 +0200
Message-ID: <00b601ceba85$af76ac90$0e6405b0$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQIbqhsvkLjOsXMYuVkR6j4EVe9YzZk9tuyQ
Content-Language: nl
X-SA-Exim-Connect-IP: 82.161.132.220
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Cc: tls@ietf.org
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 06:58:11 -0000

> Alfredo Pironti wrote:
> > Peter Gutmann  wrote:
> > > Eric Rescorla  writes:
> > >
> > >> - Maybe I am misreading the draft, but I'm unclear on how you get
> > >>    the TLSCompressed.length for the MAC computation in Section 3.
> > >>    Does this have the same issue as was raised for McGrew's CBC AEAD
> > >>    draft?
> 
> Eric is correct, the definition of the MAC in Peter's draft is obviously
incorrect
> (and likely does not match Peter's implementation):
> 
> TLSv1.0:  https://tools.ietf.org/html/rfc2246#section-6.2.3.1
> 
>    The MAC is generated as:
> 
>        HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
>                      TLSCompressed.version + TLSCompressed.length +
>                      TLSCompressed.fragment));
> 
> When changing from mac-pad-encrypt to encrypt-mac, as suggested by
> Peter's draft, the MAC no longer operates on the TLSComressed PDU, but on
> the TLSCiphertext PDU -- which results in:
> 
>        HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
>                      TLSCiphertext.version + TLSCiphertext.length +
>                      TLSCiphertext.fragment));
> 
>     The computation of TLSCompressed.length on receive changes slightly,
>     because there no longer is a MAC trailing the data after decrypt.

Please read my other reply on 'skipping' a layer somewhere in this thread.


From alfredo@pironti.eu  Thu Sep 26 02:32:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4122D21F9AA4 for ; Thu, 26 Sep 2013 02:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.426
X-Spam-Level: 
X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa9cg+dDzg4C for ; Thu, 26 Sep 2013 02:32:07 -0700 (PDT)
Received: from mail-qe0-x22c.google.com (mail-qe0-x22c.google.com [IPv6:2607:f8b0:400d:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id A69FB11E8172 for ; Thu, 26 Sep 2013 02:32:06 -0700 (PDT)
Received: by mail-qe0-f44.google.com with SMTP id 3so597365qeb.3 for ; Thu, 26 Sep 2013 02:32:05 -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=AwOWZiEZJu0eP979ASjTTpTK5h4NemI0DAydbp8I2PY=; b=Ss9ebPVr4ssBfQBqnIY/RNj6dBoaD6RvJV4lh2WRcyZnrq2yJy86XCTIpKQnHV3cX6 oXnvZE1Gnb75GWGxe6QaC1Yps4fKbUKhI0xXqnop2WS9I+cdRa9t5rjcOQqYbxNAJz8A /G38sYPMc2K/5bhz2LYKGi3wmf0p806pO8ohs=
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=AwOWZiEZJu0eP979ASjTTpTK5h4NemI0DAydbp8I2PY=; b=YZTYaCHb4wsikSKoCPoGPIzQ9U4jp763jEDZbCAo+6VWivsc4+KoNC+k+8ZHcMcjGz CcpeImVBJhg/qZIrpwrzoEpLliqd9TZgaPT9Wt2dsKUJYh7jFkPmMMbbCYrfByX5l5q8 7WYXkoGIv7IwnnJO7fYtbIQcN4hWy1nMcg1sOvaGnZUVSTiaZJNKgSlqqnsxIWEQjaUt 8VEINf3NQyaMLHqhkHsCoX61b16MVX8W4onLBCB8G1c56QgiFThj9/sa6cxkJu1Ye3+a T/9ophmdyJF0AshYkhr02ZLndfdjpAyg1EsFSajVFcczf4jHlpJnKMMYhlkRItQgQS3n VUJQ==
X-Gm-Message-State: ALoCoQkoN/eelYNEmnCbQXXn8NmCtig5o/MGmGmPbhC89cDrMg80Qd+GzYUUca75ObOEXAgLPEg2
MIME-Version: 1.0
X-Received: by 10.49.48.168 with SMTP id m8mr8392543qen.25.1380187925718; Thu, 26 Sep 2013 02:32:05 -0700 (PDT)
Received: by 10.49.108.103 with HTTP; Thu, 26 Sep 2013 02:32:05 -0700 (PDT)
X-Originating-IP: [128.93.188.195]
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567D458@uxcn10-6.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C735567D458@uxcn10-6.UoA.auckland.ac.nz>
Date: Thu, 26 Sep 2013 11:32:05 +0200
Message-ID: 
From: Alfredo Pironti 
To: Peter Gutmann 
Content-Type: text/plain; charset=UTF-8
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 09:32:11 -0000

At this point, it seems to me that both [1] and [2] solve the padding
bug, and both are straightforward to implement.

On the plus side, [2] also offers length-hiding, which is going to be
useful in TLS 1.3, when more parts of the handshake are moved to the
encrypted stage. (E.g., the size of an encrypted certificate is
usually enough to reveal the identity; or look at the NPN ad-hoc
padding strategy to protect the next protocol name).

Actually, the padding bug could also be solved by using salsa/chacha
(which I support); additionally implementing also [1] may be less
useful (redundant) in this case; implementing [2] would still inject
padding features into salsa/chacha (and AEAD), for those who need
length-hiding.

Again, if you don't care about length hiding, you don't *have to*
implement the length-hiding interface to be compliant with [2]; just
follow the data format and you're padding-bug free and interoperable
-- and you can implement length-hiding logic at a later time when your
users ask for it.

[1] http://tools.ietf.org/html/draft-gutmann-tls-encrypt-then-mac-03
[2] http://tools.ietf.org/html/draft-pironti-tls-length-hiding-02

Best,
Alfredo

On Wed, Sep 25, 2013 at 2:08 PM, Peter Gutmann
 wrote:
> Alfredo Pironti  writes:
>
>>Fix is however not too difficult: in the MAC, include the whole
>>"plaintext+padding" length, so that it can be computed directly form the
>>ciphertext length, without need to decrypt it first.
>
> Oh, I see.  It already is, in fact I'd never even considered that you could do
> it any other way, and given the results of the interop tests so far I guess
> no-one else has either.  I'll add a clarification to the draft about this.
>
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

From p.j.bakker@offspark.com  Thu Sep 26 02:43:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4E021F9A19 for ; Thu, 26 Sep 2013 02:43:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.504
X-Spam-Level: 
X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoH5bpBnZkae for ; Thu, 26 Sep 2013 02:43:04 -0700 (PDT)
Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) by ietfa.amsl.com (Postfix) with ESMTP id 3C08E11E817B for ; Thu, 26 Sep 2013 02:43:02 -0700 (PDT)
Received: from a82-161-132-220.adsl.xs4all.nl ([82.161.132.220] helo=Slimpy) by vps2.brainspark.nl with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1VP7zx-0004We-1u; Thu, 26 Sep 2013 11:36:37 +0200
From: "Paul Bakker" 
To: "'Peter Gutmann'" , 
References: <9A043F3CF02CD34C8E74AC1594475C735567DBC6@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: 
Date: Thu, 26 Sep 2013 11:42:50 +0200
Message-ID: <01ef01ceba9c$c749f360$55ddda20$@offspark.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQFhE9Rc+YY/ht8jD1tO4dwRZdRURgKXZ0P9mp5WjrA=
Content-Language: nl
X-SA-Exim-Connect-IP: 82.161.132.220
X-SA-Exim-Mail-From: p.j.bakker@offspark.com
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)
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 09:43:10 -0000

Please disregard my previous reply. Let's blame it on my lack of sleep ;)
(I read TLSPlaintext instead of TLSCiphertext)

Paul Bakker wrote on 2013-09-26:
> 
> tls-bounces@ietf.org wrote on ent: donderdag 26 september 2013 6:55:
>> Martin Rex  writes:
>> 
>>> When changing from mac-pad-encrypt to encrypt-mac, as suggested by
>>> Peter's draft, the MAC no longer operates on the TLSComressed PDU,
>>> but on the TLSCiphertext PDU -- which results in:
>>> 
>>>       HMAC_hash(MAC_write_secret, seq_num + TLSCiphertext.type +
>>>                     TLSCiphertext.version + TLSCiphertext.length +
>>>                     TLSCiphertext.fragment));
>> 
>> So all that's necessary is to change the text to reflect this, and
>> perhaps a note to point it out?  That's fairly simple to do.
> 
> I'm rather new to the list and late for this party..
> 
> But 'skipping' a layer (the TLSCompressed one in this case) is a bad idea
for a
> number of reasons.
> 
> Code path verification.
> In case this comes to fruition, instead of the clean:
>   "Assemble Data -> Compress -> Cipher -> Send",  we get
>   "Assemble Data -> Maybe hash in some specific cases -> Compress ->
> Encrypt and sometimes hash in some specific cases -> Send"
> 
> This makes checking code correctness a step harder, aside from the fact
> that suddenly cryptographic information (which used to be only required
> in the Cipher layer) suddenly needs to be available on other points as
> well.. Meaning more coupling between layers and functions. This is bad
> in my opinion!
> 
> Aside from the fact it's not pretty, there is a reason for having nice
separate
> layers, the fact that you can re-use / re-write the 'old buffer' and do
need to
> use unnecessary extra space. Violating that contract by letting layers
access
> the full data of another layer it should not see, requires extra storage
space,
> which on most embedded systems is very scarce.
> 
> I understand the issue, but in my opinion this is not the way to solve it.
So
> please reconsider solving the issue this way.
> 
> Paul


From SRS0=fyqm=TG=acm.org=bmoeller@srs.kundenserver.de  Thu Sep 26 02:59:10 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9654011E8181 for ; Thu, 26 Sep 2013 02:59:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.518
X-Spam-Level: 
X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sbhwifu8nlwD for ; Thu, 26 Sep 2013 02:58:45 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2903A21F99DD for ; Thu, 26 Sep 2013 02:58:19 -0700 (PDT)
Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LaD6c-1W8xXG1Q9W-00m0ps; Thu, 26 Sep 2013 11:58:12 +0200
Received: by mail-ob0-f182.google.com with SMTP id wo20so1573848obc.27 for ; Thu, 26 Sep 2013 02:58:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/GZDfKIyYiUM5PwB8q+8v36F1hcmhNashXZoS+ZKP5s=; b=YERUWr/eWEBnxZbSNZL8MlMlsVQhCrZ0CjV/DaFqCp+DeQHW+AFQafbMZs7vKUnhZ4 AG/yvi6k1F/88V9AfUFHzvZXeMSMeGd/3lQA/Z4zd7HjzR0yLi78wannJBCljthXzAWf HZLC13AwxF8e8ZxQHiV/9/2SFp71AIDUpXNKEIZ7GeZVYnxttVy6gJ5ssnZG/s6t0w8n t+1OlbT42hyT67iaAEtyuzWJ8eQrLw58+fZUJf1XuGlzYdY9k47NzESwIqVtPS/6T4bI EO752ce3SMMl+X5Gig17tTwQIaaf7dL0UmFQvhI2i5vYojYEM4vWTfHPQugrNDPNfUum ajXA==
MIME-Version: 1.0
X-Received: by 10.60.62.4 with SMTP id u4mr7364oer.35.1380189490976; Thu, 26 Sep 2013 02:58:10 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 26 Sep 2013 02:58:10 -0700 (PDT)
In-Reply-To: <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
References:  <20130925205424.8DCFA1A9A7@ld9781.wdf.sap.corp>
Date: Thu, 26 Sep 2013 11:58:10 +0200
Message-ID: 
From: Bodo Moeller 
To: Martin Rex 
Content-Type: multipart/alternative; boundary=089e012953ba5524b604e7466874
X-Provags-ID: V02:K0:B7t+Y2twH8BRkt5Zabvb+lD+aKuYmRWt5O4c+URzvAd t5FQVEhmaFt++TVAnG26KU5EJpqbw3OKIt5gtdglKtqMdRHcPy 4EI2SMzjAQIVS9eX2Y4tXIwUu8b6KEdlubTNv7NIu82sB3UPqZ mnALLGN00rtc1p97bIBuyW+THGPkoGgWJFk7kBfvtgFMQ9Resc jlaAuotdirf0Lmwr5MNxcqV2Y/uNapbip6rGiv3YlCLxtQ75aG iXdQLbJcjbWVB6G+HrUfLk/Hx32TfYY6g0OfWGg4fShGqsEGM2 48N/OsRmK9M9r/ZOA02mN0sHAWAUtUynMZIMS/kL8M5SC4xEDK TJsqeLFwRE3gWTW7tW11gcmcuaaKlh+1iHjjYKD0Doa6WbSDSj XF94L8t+G3QskA9DOTPCERo541KVVxVxS0qUTUJDzqoiHVAccJ HVU3X
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 10:00:10 -0000

--089e012953ba5524b604e7466874
Content-Type: text/plain; charset=ISO-8859-1

> >
> http://www.ietf.org/internet-drafts/draft-bmoeller-tls-downgrade-scsv-00.txt
>
>
Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.
>

(For my response, see thread "New Version Notification for
draft-bmoeller-tls-downgrade-scsv-00.txt"; I want to avoid hijacking this
one.)

--089e012953ba5524b604e7466874
Content-Type: text/html; charset=ISO-8859-1







Any kind of specification for TLS, that suggests to the server

to apply heuristics and make (often flawed or unjustified) assumptions

about what the client may want or may not want and have the _server_

abort the handshake rather than the client, are a REALLY BAD IDEA and

squarely against the IETF spirit to promote interop.

(For my response, see thread "New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt"; I want to avoid hijacking this one.)





--089e012953ba5524b604e7466874--

From SRS0=fyqm=TG=acm.org=bmoeller@srs.kundenserver.de  Thu Sep 26 02:56:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210E811E8183 for ; Thu, 26 Sep 2013 02:56:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.51
X-Spam-Level: 
X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[AWL=0.116,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2cOesGUPklL for ; Thu, 26 Sep 2013 02:56:35 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id A405C21F9AEF for ; Thu, 26 Sep 2013 02:56:31 -0700 (PDT)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M7Ual-1Vl4uX1EF5-00x1uf; Thu, 26 Sep 2013 11:56:30 +0200
Received: by mail-oa0-f49.google.com with SMTP id i4so405113oah.36 for ; Thu, 26 Sep 2013 02:56:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gAUXJnPG7ftWUms9lP0k8yS4VxZwVpeRQq9xWh+Qb/4=; b=VvZWJRAl48ciufXOwbq+rmcw56IvSZP6YVcL7JEQOek3oAs4nBfL9h5BgxVCQfuz7r V/R/KfPctsqcZfqd1f2gYmcKYnZ4bdyGoLD6j4UTkpWqLAcRdHQ2nbosFYOzBUJYYl4J vMHUAkzS/5W2TYSKSAqhEOv6StlLB677znzg7EPY0O0VMaMNcxVYO3MHjkQI2AakQi79 pmsT2JkiacDe0+pHmqWt2cuq+SGJ09IDRgBkL5HwakrczIszXZqENRGQocaLVzdEyr7Q ZxCl7P2U/LK7JLMg1k8YRF35vo00IvEvjbSTHMXnHH07sc7Dp26AGwozsjYg8rebd5z4 racg==
MIME-Version: 1.0
X-Received: by 10.60.58.10 with SMTP id m10mr239663oeq.61.1380189389000; Thu, 26 Sep 2013 02:56:29 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 26 Sep 2013 02:56:28 -0700 (PDT)
In-Reply-To: <524352D3.4020601@pobox.com>
References: <9A043F3CF02CD34C8E74AC1594475C735567D321@uxcn10-6.UoA.auckland.ac.nz>   <5243119D.4070001@pobox.com>   <524352D3.4020601@pobox.com>
Date: Thu, 26 Sep 2013 11:56:28 +0200
Message-ID: 
From: Bodo Moeller 
To: "Michael D'Errico" 
Content-Type: multipart/alternative; boundary=089e01538bc441173d04e74662fe
X-Provags-ID: V02:K0:lowpqWuX1r2lLiRxGYtmfKLa+i2gJreI0utC5yhpWmV d/qgwdb5RFzDyuirH2ep5W9mJSYdKv6FzjLncrdTcH4F5CIata G4R1aAPyjDyTi8gH0g4F2vn5Eslu32D5zCNu75IQYTLhDnDpHj ruKU0toJhoE2wucVf5QEC/chE5DZ7iMTXY1gHxLNWkshNaHbHo j6nIFZvskw1aFSCFh889ou3Zj3L5QCDQruyvYrpHlcuBQkjEDu Lm16n1IZzcKzLXDkgBniDfJL2HTYMy3NgJXMNrCdlJo7I2mPL8 s81gSjXJceFj/J5MTPXymXvpcjuuOtWL5oWbi7DK1+o30x2/mG QykCWIzeBnCWtbQ1gHlPmk5G76Fmfdpj+7yRfREeCx25PNmmRI pa/bsKgfaFuyHhglV1rsK6W3envO6pN0P8EWZB4C7qAC2G/ZFy nKF+t
Cc: TLS Mailing List 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 10:00:48 -0000

--089e01538bc441173d04e74662fe
Content-Type: text/plain; charset=ISO-8859-1

2013/9/25 Michael D'Errico 

> http://www.ietf.org/internet-**drafts/draft-bmoeller-tls-**
>> downgrade-scsv-00.txt
>>
>
> I think that the server MUST send a FATAL alert only if it would
> not have been willing to negotiate the lower TLS version in the
> absence of the SCSV.


> A WARNING alert from the server (or some extension_data with more
> information) lets the client decide whether to continue.  Both
> sides can keep track of these occurrences for further investigation
> by interested admins at their leisure (not via calls to the help
> desk).


I guess this would work, but I also want to keep the protocol simple.  (If
the client wants to continue with the downgraded protocol, it can send a
downgraded ClientHello without the SCSV.  Sending the SCSV is RECOMMENDED,
not REQUIRED.)



> Also RFC 3546 and 4366 have been obsoleted by RFC 6066.


I know -- so have RFC 2246 and RFC 4346 (by RFC 4346 and by RFC 5246,
respectively), but all of these are still relevant for implementations of
older TLS versions.  (RFC 6066 alone doesn't tell you how extensions work
in TLS 1.0 or TLS 1.1.)

Bodo

--089e01538bc441173d04e74662fe
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


2013/9/25 Michael D'Errico <mike-list@pobox.com=
>



http://www.ietf.org/internet-drafts/=
draft-bmoeller-tls-downgrade-scsv-00.txt





I think that the server MUST send a FATAL alert only if it would

not have been willing to negotiate the lower TLS version in the

absence of the SCSV.



A WARNING alert from the server (or some extension_data with more

information) lets the client decide whether to continue. =A0Both

sides can keep track of these occurrences for further investigation

by interested admins at their leisure (not via calls to the help

desk).

I guess this would work, but I also =
want to keep the protocol simple. =A0(If the client wants to continue with =
the downgraded protocol, it can send a downgraded ClientHello without the S=
CSV. =A0Sending the SCSV is RECOMMENDED, not REQUIRED.)







Also RFC 3546 and 4366 have been obsoleted by RFC 6066.
I know -- so have RFC 2246 and RFC 4346 (by RFC 4346 and by RF=
C=A05246, respectively), but all of these are still relevant for implementa=
tions of older TLS versions. =A0(RFC 6066 alone doesn't tell you how ex=
tensions work in TLS 1.0 or TLS 1.1.)



Bodo



--089e01538bc441173d04e74662fe--

From SRS0=fyqm=TG=acm.org=bmoeller@srs.kundenserver.de  Thu Sep 26 02:47:35 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA6721F99CD for ; Thu, 26 Sep 2013 02:47:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.501
X-Spam-Level: 
X-Spam-Status: No, score=-1.501 tagged_above=-999 required=5 tests=[AWL=0.125,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6oiM3N0lesC for ; Thu, 26 Sep 2013 02:47:30 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id EBB3311E8187 for ; Thu, 26 Sep 2013 02:47:25 -0700 (PDT)
Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Ls7Op-1VrhpL2Bqx-013MQU; Thu, 26 Sep 2013 11:47:25 +0200
Received: by mail-ob0-f179.google.com with SMTP id wn1so1572565obc.10 for ; Thu, 26 Sep 2013 02:47:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=h5aFs8nLoChfCJsSKCOJfWLd2hFsXwcl5tcBwLPeQ2U=; b=R30NXJjrZlLJyAOfSsxZ2VitBsIt7dcNQCkSwM501Te0y7phi5sryZCOiA/chzcFxx REDHvMkpC4xdNckO1zRvSMAFekTM6yyPxOuR0Z/RSzB+0s+8uvzm0p8hhqxU46wtMna/ jiMg/Uskztrls1QRRBm0oJNA5MwlLwwWhLa/Hu3MrKfqld8/ymkfM6ULL4xlvTr6shYA qyghZYl1897yt/6Un+t0a19oyUnmB59q8yCqSQvXPQG9/V78wzOcQWgSs05Djmluo9Xd s9lBjJ5eVHqjn1iP9l959Dk8dq+bYTsK/WfGl2YZtlqg+GPB+MsZvuoAqWSK9Glpw/4k TbIw==
MIME-Version: 1.0
X-Received: by 10.182.84.132 with SMTP id z4mr874569oby.49.1380188843116; Thu, 26 Sep 2013 02:47:23 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 26 Sep 2013 02:47:23 -0700 (PDT)
In-Reply-To: 
References: <20130925202312.29986.21441.idtracker@ietfa.amsl.com>  
Date: Thu, 26 Sep 2013 11:47:23 +0200
Message-ID: 
From: Bodo Moeller 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0111c09ab7904e04e74641fd
X-Provags-ID: V02:K0:3nBqp4Tt2/WmqDQ4B14EGMSqjnl+dcnVFDXoFb1Styr 1hQabxifflLTSii1ZMVE4Eh0viOorYYKMOIneh/dYYcn37wHW9 2EY/piCqON6ruCt9hQY/qJ2i65CvvS0NKhTYUGctJUF4cGjrFb 8Jl+VJkjL5K+AOUHasthlvzvoe27/LkiIV7KrFnXuyDLLtEgDm iRUwpKXLM3wzUUbbFm2eIoGtQ7fEex52smIMH2broJmnQoCiHA WbOroUmVpsSFhTAR0FaBkQdGtRcBiMojZ18oxbFjPjfJ4s867G 2Hc4PTcx5V6n3kOxqR3MkLCsCsQN+k3GCpz0kdpxbJ8daAugpG qUMwY2qGDoMXON5kHQ797nBDTLEg1h+H5FaTHTaVJ6rZqDCsK/ iOmsFa0WJBDVd7RWrAOmifXDHpkJLXiD6L655vb+I38OZnjJQW 71UxR
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 10:01:11 -0000

--089e0111c09ab7904e04e74641fd
Content-Type: text/plain; charset=ISO-8859-1

> Document:  rollback-removal-02.txt
> >
> Tracker:  version-rollback-removal/
> >
>


> The benefit of my proposal is that:
>
>  - it only needs to be deployed client-side.
>  - it does not require changes to the protocol, only to how the client
> handle a specific situation.
>  - once clients only accept renego patched server this method, *and* the
> version rollback functionality can be removed.
>
> There will initially be the downside of handling the .26% servers that are
> version/extension intolerant, but those can be quickly patched. There is
> also the problem of version/extension intolerant intermediates in the
> network that have been observed by the Google Chrome team.
>



> I'll also note that two other approaches (proposed by EKR and Adam
> Langley) for this have been discussed the past two years, using SCSVs, and
> these and mine were discussed at the IETF-84 TLS WG meeting.


Thanks for your comments!

Obviously all of the above proposals are somehow related.  Actually, I
think that your ID and mine in fact complement each other in
that draft-pettersen-tls-version-rollback-removal-02 provides heuristics
for how to handle (and avoid) protocol rollbacks in the *current*
implementation landscape, whereas draft-bmoeller-tls-downgrade-scsv-00
specifies a simple mechanism that can be used to avoid security problems
from protocol rollbacks in a very *general* way.




Martin Rex noted (in neighbor thread "[TLS] Comments/Questions on
draft-gutmann-tls-encrypt-then-mac-00.txt" where this came up, but which I
don't want to hijack entirely):

OH NO, not again!!
>
> Any kind of specification for TLS, that suggests to the server
> to apply heuristics and make (often flawed or unjustified) assumptions
> about what the client may want or may not want and have the _server_
> abort the handshake rather than the client, are a REALLY BAD IDEA and
> squarely against the IETF spirit to promote interop.


I'm not sure to what extent I agree to this claim (for example, we do allow
servers to abort with an insufficient_security alert if they don't agree
with any of the ciphersuites listed in ClientHello.cipher_suites), but in
any case please note that this is not actually what
draft-bmoeller-tls-downgrade-scsv-00 specifies.

Rather, the specification has very specific instructions for servers when
to abort the connection (certainly I'm all for encouraging
interoperability, but for a security protocol there clearly are limits to
this -- I'd rather not interoperate with man-in-the-middle-type attackers,
for example), and specifically leaves it to clients to request that
server-side behavior for a given handshake attempt or not.  The
specification includes recommendations that will ensure full security based
on the capabilities of the given client and server, but client
implementations are allowed to ignore these if there are appropriate
reasons.

(I think an essential difference to Eric's and Adam's earlier proposals is
that in my proposal, the client wouldn't enumerate its capabilities for the
purpose of server-side heuristics.  Instead, use is entirely directed by
the client, as needed by its protocol downgrade sequence.  In the ideal
case, with no client-side protocol downgrade taking place at all, nothing
happens.)

Bodo

--089e0111c09ab7904e04e74641fd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=



Document: <http://www.ietf.org/id/draft-pettersen-tls-version-rollback-removal-02.txt>

Tracker: <http://datatracker.ietf.org/<=
u>doc/draft-pettersen-tls-version-rollback-removal/>


=A0

The benefit of my proposal is that:



=A0- it only needs to be deployed client-side.

=A0- it does not require changes to the protocol, only to how the client ha=
ndle a specific situation.

=A0- once clients only accept renego patched server this method, *and* the =
version rollback functionality can be removed.



There will initially be the downside of handling the .26% servers that are =
version/extension intolerant, but those can be quickly patched. There is al=
so the problem of version/extension intolerant intermediates in the network=
 that have been observed by the Google Chrome team.



=A0

I'll also note that two other approaches (proposed by EKR and Adam Lang=
ley) for this have been discussed the past two years, using SCSVs, and thes=
e and mine were discussed at the IETF-84 TLS WG meeting.


Thanks for your comments!

Obviously=
 all of the above proposals are somehow related. =A0Actually, I think that =
your ID and mine in fact complement each other in that=A0draft-pettersen-tl=
s-version-rollback-removal-02 provides heuristics for how to handle (and av=
oid) protocol rollbacks in the *current* implementation landscape, whereas=
=A0draft-bmoeller-tls-downgrade-scsv-00 specifies a simple mechanism that c=
an be used to avoid security problems from protocol rollbacks in a very *ge=
neral* way.






Mar=
tin Rex noted (in neighbor thread "[TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt&=
quot; where this came up, but which I don't want to hijack entirely):




OH NO, not again!!

Any kind of specification for TLS, that sugge=
sts to the server

to apply=
 heuristics and make (often flawed or unjustified) assumptions
about what the cl=
ient may want or may not want and have the _server_

abort th=
e handshake rather than the client, are a REALLY BAD IDEA and
squarely against t=
he IETF spirit to promote interop.



I'm not sure to what extent I agree to this claim (=
for example, we do allow servers to abort with an=A0insufficient_security=A0alert if they=
 don't agree with any of the ciphersuites listed in ClientHello.cipher_=
suites), but in any case please note that this is not actually what draft-b=
moeller-tls-downgrade-scsv-00 specifies.



Rather, the specification has very specific instruction=
s for servers when to abort the connection (certainly I'm all for encou=
raging interoperability, but for a security protocol there clearly are limi=
ts to this -- I'd rather not interoperate with man-in-the-middle-type a=
ttackers, for example), and specifically leaves it to clients to request th=
at server-side behavior for a given handshake attempt or not. =A0The specif=
ication includes recommendations that will ensure full security based on th=
e capabilities of the given client and server, but client implementations a=
re allowed to ignore these if there are appropriate reasons.



(I think an essential difference to Eric's and Adam=
's earlier proposals is that in my proposal, the client wouldn't en=
umerate its capabilities for the purpose of server-side heuristics. =A0Inst=
ead, use is entirely directed by the client, as needed by its protocol down=
grade sequence. =A0In the ideal case, with no client-side protocol downgrad=
e taking place at all, nothing happens.)



Bodo



--089e0111c09ab7904e04e74641fd--

From benl@google.com  Thu Sep 26 03:56:06 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0468111E8184 for ; Thu, 26 Sep 2013 03:56:04 -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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecRcebJXCN5S for ; Thu, 26 Sep 2013 03:56:03 -0700 (PDT)
Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id F241B11E818A for ; Thu, 26 Sep 2013 03:56:02 -0700 (PDT)
Received: by mail-ie0-f170.google.com with SMTP id x13so1136268ief.1 for ; Thu, 26 Sep 2013 03:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DU03Vd+OZu0tZEQ9Zxkd4vuySKW67LQpsdHcXuzG4V8=; b=KqJP/hU5INRC9WBt8AW7yGRbmPYOTHlcgwSSA1rYJVL5gRfuc50+evJRGKTSPHFXwp nekVKbsu4TNBbVnLo9y9NJ6GUgkySDidqSsce7sAzndBzjVVsVrKXCIzYr4DcmIBt8Yb fgvx2u1cFxV4CsjIge+mG25M1jlOgQ1jtMEqxg252SB5BDXPhkB+USuyvc3dhDJfvGVD aNViyKKrNz8gQgQc2ej5e+q3so56jTJDveJ/i+Pw4YeRuHW8rA852Q+5+ngbUOSJxUIu qDDpqNTDw3N5/J0OQyYGiKg5+H8RmWYsLo6olhr7/I8n9HMUNstO3qMBke0eW9LFDBpD Y70A==
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=DU03Vd+OZu0tZEQ9Zxkd4vuySKW67LQpsdHcXuzG4V8=; b=EWeiMh92IljOomeul8Ph2mFfCfanuoVkXr+ISCYn+fAea07ScxgVOGw/hIrSEUUKg0 mANpzoa1NWc8wYkK0O/SQVjfh8Ooeo1RfdIA4n9I2Uv+nAJcMI+UyDIhpu5EIEBYihW7 s3lkuEmVwZKPPHJpqVO53TvZEFrLJqojGlcNLwnf8eIN8QEmNCkJks3frJry3UAwqVyy r8NtOB9IMtWKred7s6bJhKmub7o4d//XqLwMqN+K1kXudTSY/KM+bDqDfllAfdelqBgr psJjFPZ+Yie9DiLyrLxznAGnw6bgFcWngPklOWvriGS8qXmb0MEwiO15QtfQewVwUOQM UhVQ==
X-Gm-Message-State: ALoCoQlrLvV3xPehmrKgZzlYDg/i3B/fK7WOppxQ+UAla3gXYjbKUJeqi9GBI5PaweFt8EdDMueaQcDU9rF4Lqnba6qicNtanspri8KACwpuLW7B44ndA4hECkwD8pz8oq4Ee78vfcHvjPCmI02ubltBDHf3xfizOxU16NN+bbrttLPJvRCE2y5CYrTdqTWSGNb2C35stkkA
MIME-Version: 1.0
X-Received: by 10.42.190.17 with SMTP id dg17mr351314icb.44.1380192944873; Thu, 26 Sep 2013 03:55:44 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Thu, 26 Sep 2013 03:55:44 -0700 (PDT)
In-Reply-To: 
References:   
Date: Thu, 26 Sep 2013 11:55:44 +0100
Message-ID: 
From: Ben Laurie 
To: Joseph Bonneau 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "therightkey@ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 10:56:06 -0000

On 26 September 2013 06:15, Joseph Bonneau  wrote:
> I'd like some elaboration on the plan for step 6, creating a whitelist of
> valid EV certificates without an SCT. How is this going to be achieved?

Not sure what the question is - as the doc says, the list will be
constructed from the logs...

From mrex@sap.com  Thu Sep 26 04:35:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538AF21F9B90 for ; Thu, 26 Sep 2013 04:35:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.173
X-Spam-Level: 
X-Spam-Status: No, score=-10.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fhXSdY5iGuW2 for ; Thu, 26 Sep 2013 04:34:58 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2C55C21F9B6A for ; Thu, 26 Sep 2013 04:34:54 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8QBYoej021761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Sep 2013 13:34:50 +0200 (MEST)
In-Reply-To: 
To: Bodo Moeller 
Date: Thu, 26 Sep 2013 13:34:50 +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: <20130926113450.387DE1A9AA@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 26 Sep 2013 11:35:03 -0000

Bodo Moeller wrote:
> 
> Martin Rex noted (in neighbor thread "[TLS] Comments/Questions on
> draft-gutmann-tls-encrypt-then-mac-00.txt" where this came up, but which I
> don't want to hijack entirely):
> 
> OH NO, not again!!
> >
> > Any kind of specification for TLS, that suggests to the server
> > to apply heuristics and make (often flawed or unjustified) assumptions
> > about what the client may want or may not want and have the _server_
> > abort the handshake rather than the client, are a REALLY BAD IDEA and
> > squarely against the IETF spirit to promote interop.
> 
> 
> I'm not sure to what extent I agree to this claim (for example, we do allow
> servers to abort with an insufficient_security alert if they don't agree
> with any of the ciphersuites listed in ClientHello.cipher_suites), but in
> any case please note that this is not actually what
> draft-bmoeller-tls-downgrade-scsv-00 specifies.

https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3

   This section specifies server behavior when receiving the
   TLS_DOWNGRADE_SCSV cipher suite from a client in
   ClientHello.cipher_suites.

   o  If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the
      highest protocol version supported by the server is higher than
      the version indicated in ClientHello.client_version, the server
      MUST respond with a (fatal) protocol_version alert.

   o  If TLS_DOWNGRADE_SCSV appears in ClientHello.cipher_suites and the
      ClientHello message does not include field
      client_hello_extension_list at all ([RFC3546], [RFC4366],
      [RFC5246]), the server MUST respond with a (fatal)
      protocol_version alert.

To me, this part of your document places two requirements on the _server_
to abort the handshake.  And the justification given for aborting the
handshake is *NOT* that the TLS connection characteristics proposed
in ClientHello is inacceptable to the servers' policy (which would be OK),
but that the TLS connection characteristics appear to be inconsistent
with the TLS connection charateristics alleged/assumed to be desired
by the client.

In a security protocol, it is a design failure to rely on a connection
peer to enforce one's own policy (the connection peer may be an adversary),
and it is necessary that each peer checks and enforces his own policy
himself.  But once it does that, there is no need (and less confusion)
if each peer takes care only of his own policy.


-Martin

From hallam@gmail.com  Thu Sep 26 07:15:13 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9065B21F9346 for ; Thu, 26 Sep 2013 07:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHIVQDK9e54V for ; Thu, 26 Sep 2013 07:15:08 -0700 (PDT)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) by ietfa.amsl.com (Postfix) with ESMTP id ECA1C11E80D2 for ; Thu, 26 Sep 2013 07:15:07 -0700 (PDT)
Received: by mail-lb0-f179.google.com with SMTP id x18so1114604lbi.38 for ; Thu, 26 Sep 2013 07:15:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TELM+kWDtXgi5SjcqiiwmFDEeXcKNjtr3RDFNu8+bBE=; b=AHZzZTN/BOmFX7wWSc5jZs3n6BhWurGd4yfkpMHUrxd4XVPzwwtSZ20xcVA9WgUuWE oFWa3pFMcuuRhfnmas4IQlb4gqyqClkaPZJ39ArB93H1FhXL9b0Tk+Jh8v5e+Z8Fn8K7 o56qmdU/GIVnbeRuffDAOsK/b1yi0ygsGwovZsATwQwK19KlIgHdQttLd92D84FPeTcj kHM55vc/zchFN465c2Y49rUtzVME/E7midgz4EpWOgevKNv0Lu5DGJdceSqbTdihFaVn x9P7CpzHXMXjEyX9obdGBuIk/HJe0/Z4HGGoBXrFLusMgYBc5/tWc8x5j+hFYp0xs1TO zq3g==
MIME-Version: 1.0
X-Received: by 10.112.155.39 with SMTP id vt7mr4057771lbb.29.1380204902221; Thu, 26 Sep 2013 07:15:02 -0700 (PDT)
Received: by 10.112.148.165 with HTTP; Thu, 26 Sep 2013 07:15:02 -0700 (PDT)
Date: Thu, 26 Sep 2013 10:15:02 -0400
Message-ID: 
From: Phillip Hallam-Baker 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=089e0112c136ea0cb704e749fe09
Subject: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 14:15:14 -0000

--089e0112c136ea0cb704e749fe09
Content-Type: text/plain; charset=ISO-8859-1

My understanding of the 1024 bit Ephemeral DH key issue is that it is not
currently possible to use longer keys because a certain number of deployed
Web servers will abort the connection if a client presents a longer key.

Hmmm, wonder who made that decision...


Regardless, this is not a problem that will solve itself. Even if
presenting a longer key will cause a connection to abort in 0.1% of cases,
browsers are not going to make the attempt. So if nothing is done the
legacy servers will prevent use of longer DH keys for the next 20+ years.

I don't think a TLS version number upgrade is the solution either. It is
just a bad idea for an algorithm suite identifier to mean one thing in TLS
1.2 and another in TLS 1.3.


The simple solution to this problem in my view is to specify a new
algorithm suite identifier for DH larger than 1024 and use that in
parallel. That might get us to a point where 25% of Web Servers are using
very strong EDH within 12-24 months.


-- 
Website: http://hallambaker.com/

--089e0112c136ea0cb704e749fe09
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


My understanding of the 1024 bit Ephemeral DH key issue is=
 that it is not currently possible to use longer keys because a certain num=
ber of deployed Web servers will abort the connection if a client presents =
a longer key.


Hmmm, wonder who made that decision...

<=
div>
Regardless, this is not a problem that will solve itself=
. Even if presenting a longer key will cause a connection to abort in 0.1% =
of cases, browsers are not going to make the attempt. So if nothing is done=
 the legacy servers will prevent use of longer DH keys for the next 20+ yea=
rs.



I don't think a TLS version number upgrade is the s=
olution either. It is just a bad idea for an algorithm suite identifier to =
mean one thing in TLS 1.2 and another in TLS 1.3.=A0




The simple solution to this problem in my view is to sp=
ecify a new algorithm suite identifier for DH larger than 1024 and use that=
 in parallel. That might get us to a point where 25% of Web Servers are usi=
ng very strong EDH within 12-24 months.




--089e0112c136ea0cb704e749fe09--

From SRS0=fyqm=TG=acm.org=bmoeller@srs.kundenserver.de  Thu Sep 26 07:29:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B99421F92E7 for ; Thu, 26 Sep 2013 07:29:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.491
X-Spam-Level: 
X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[AWL=0.135,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWH0Uj6-CukI for ; Thu, 26 Sep 2013 07:29:14 -0700 (PDT)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by ietfa.amsl.com (Postfix) with ESMTP id D458F21F9991 for ; Thu, 26 Sep 2013 07:29:12 -0700 (PDT)
Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by mrelayeu.kundenserver.de (node=mreu4) with ESMTP (Nemesis) id 0LhHE4-1WBmqc33BI-00ma5y; Thu, 26 Sep 2013 16:29:11 +0200
Received: by mail-oa0-f42.google.com with SMTP id g12so757560oah.29 for ; Thu, 26 Sep 2013 07:29:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3vOZu9omEFRglh2LlZc8nwr3YjivfPUwjF5VV3s8zP4=; b=kKGpoXYwOAXZm3BoFVRelS8JjXKcge9yqX6WXs53KnsOOZ5R1JBP8qCbfjHyed2y4n 2djLf0Xi+XlxqfvuchEtoTIzxeWnxTclFBxgZnk4guPf/+yuubZSdZxE2jmLWajnbFJd DX75d9meFjEZ5zorbNzMy+CkhvH5maJY4ts7PMLIlaPzKEDCXmlXUoW09v204ssHblaR 8mDKNTLrWwDpN2xz9mYXh6U7+u5OdXstzPzJFC8RrWRZG/lhXUlZfQwahagHHqk1auNc 3oYpnwt02CBndPZK7ThSdywxAkAQEGvM9ek/i5DLrWzKDR+VRyipGg0XuVGW4by+SYlM VcsA==
MIME-Version: 1.0
X-Received: by 10.60.43.131 with SMTP id w3mr1047544oel.10.1380205749483; Thu, 26 Sep 2013 07:29:09 -0700 (PDT)
Received: by 10.60.115.72 with HTTP; Thu, 26 Sep 2013 07:29:09 -0700 (PDT)
In-Reply-To: <20130926113450.387DE1A9AA@ld9781.wdf.sap.corp>
References:  <20130926113450.387DE1A9AA@ld9781.wdf.sap.corp>
Date: Thu, 26 Sep 2013 16:29:09 +0200
Message-ID: 
From: Bodo Moeller 
To: Martin Rex 
Content-Type: multipart/alternative; boundary=001a113346ce6a47b804e74a31e1
X-Provags-ID: V02:K0:3+oln3oDwzYA8tko+CYI9E7CC0KjzkUAqOnK8g4A5S9 ZBxm/XiaeWT3odemAGy5A+L71lbd0UWyrrtAmoNSzBKjzL79i6 CIDPGUfcaih1pCiHG90DCobhcK+w8s7vO92WB6wC5Ca7G/TPHJ k4ZvkWz0MVm2gXRYr/3fU2J0LP/wu2WpGgG5ZFPjiNPZMjAU5j rp08kL6o3VgibmlQ26YjEmCXD41SHLtWjBsn6LFVAbZlidsUMZ 8UbRAUOcpaS0tlD6H4Vnu/8HcD1QXwYrjq0TLHVhWXXQxm3u46 bL/vZ0s3RzUHe6v8Ge+6J2JMoNUsNWPgB7ji+8aknI4wSAgBY9 nz1sC5Q7jh5YCRx8i9Pc2j6T2+Pso9T1llXTt1mSl3hyontqeS xvXKDXTX4C3cVr4HkJxGCjNgH4lkrZkGQGLrjJfmRUyZII87yy vfo98
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 14:29:18 -0000

--001a113346ce6a47b804e74a31e1
Content-Type: text/plain; charset=ISO-8859-1

>
> https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3
>
>    This section specifies server behavior when receiving the
>    TLS_DOWNGRADE_SCSV cipher suite from a client in
>    ClientHello.cipher_suites.
> [...]
>
> To me, this part of your document places two requirements on the _server_
> to abort the handshake.


Yes. My point is that there's no server-side guesswork involved -- no
"flawed or unjustified" assumptions. This is entirely client-directed
behavior!


In a security protocol, it is a design failure to rely on a connection
> peer to enforce one's own policy (the connection peer may be an adversary),


If the authenticated handshake for a client-side protocol downgrade goes
through and you're actually talking to an adversarial server, the same
adversary could have negotiated the downgraded protocol version immediately
via proper TLS version negotiation.  This entire specification is only
about scenarios in which the client *is* willing to use the downgraded
protocol if necessary and *is*, in particular, willing to rely on it at
least for authentication and integrity-check purposes.  In other words, you
are not relying on an arbitrary connection peer, but on an authenticated
server.

Bodo

--001a113346ce6a47b804e74a31e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



=







https://tools.ietf.org/html/draft-bmoel=
ler-tls-downgrade-scsv-00#section-3



=A0 =A0This section specifies server behavior when receiving the

=A0 =A0TLS_DOWNGRADE_SCSV cipher suite from a client in

=A0 =A0ClientHello.cipher_suites.
[...]



To me, this part of your document places two requirements on the _server_
to abort the handshake.

Yes. My point is th=
at there's no server-side guesswork involved -- no "flawed or unju=
stified" assumptions. This is entirely client-directed behavior!





In a security protocol, it is a design failure to rely on a connection

peer to enforce one's own policy (the connection peer may be an adversa=
ry),

If the authenticated handshake for a c=
lient-side protocol downgrade goes through and you're actually talking =
to an adversarial server, the same adversary could have negotiated the down=
graded protocol version immediately via proper TLS version negotiation. =A0=
This entire specification is only about scenarios in which the client *is* =
willing to use the downgraded protocol if necessary and *is*, in particular=
, willing to rely on it at least for authentication and integrity-check pur=
poses. =A0In other words, you are not relying on an arbitrary connection pe=
er, but on an authenticated server.



Bodo



--001a113346ce6a47b804e74a31e1--

From benl@google.com  Thu Sep 26 07:37:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7941321F9EA2 for ; Thu, 26 Sep 2013 07:37:01 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwB2EXealke8 for ; Thu, 26 Sep 2013 07:37:01 -0700 (PDT)
Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9408211E80D7 for ; Thu, 26 Sep 2013 07:36:32 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so1459348iec.16 for ; Thu, 26 Sep 2013 07:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Kh2MZUB6SW2fD/Dl0KQogAuh3+KNf6XtMhEJnVJwxtU=; b=SN07Ar3nPojF2AwJ3FGGmBpQz9kyFNzxC6u3HOmU4IXPNwJvwMqvmF/otWZ/suRoWO 2DRZd7zY0sMkM2OArrd2lg8WE8hk/v1G4Ja/ps0GFiE9/ZfcWWf0znFMvqncRctI+h4a jcmtPkJ66fqf6fyINGes/YMJSV28kbtFZdmDcnTh3P5VBSbhtvbaRa92nRdoOxD8ZiQR MIKZMgjxBHUFqWPdYZZV3TizyH56UK7o8+dMG813mt9ax0nJTobHJTaAHk9PG3qhY6p5 ZWpQrgx/EZLQHCyae4f1GnQ6GQ579Vo9p4FAwoodQdcTHqqKzFoyocf/Y6cOGYwTAYMW 8/RQ==
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=Kh2MZUB6SW2fD/Dl0KQogAuh3+KNf6XtMhEJnVJwxtU=; b=b4UgBatxIiVXbe+X5ynKDIVTH2Ttao90HJBWmczOxZ+Jmwm3VRaYoHkiEicybK6ARf GlYH39euh31OViC9emxQO8yMScWDKpdvkuKGe9MTjQZvJ2jPW7dwB3IMre7cX9Faa0MM PeMZfnpVyij3JMcQ0cyHSdRq+hSKJP4W0ciLt1uC0pOiliVZhkTZgzNGnL+5Ili06GME DuD1EhEhEMaupOUb1n35wVbOOe0wNws8GNLA5yA5jD6K90CqYmfeDoctPvIqOfE3O6pF SPZwjOGwFJ/TsuoY89L4GU8nef9Rz7KARSqQTPkyrpq87i/Gfvg+YZDIFccp0y7bz2Tb fMfQ==
X-Gm-Message-State: ALoCoQmutgLDQJxJOhifNItVaXbPOf4FpLACAtWqOYYBoisLf4MsVF56AKuUHCbLv4skUx41y8f3/bBF2rhlHo1iT5Abb9eVeqezvgBJbWqETOIaq6dym5d+begb15oihtaxVqkgVlOIVQAMiQZ2dkeGZE9J7q82lt6dDBIByZO9yIZj8h55P3pkkBvXr3llkv/DSgDdHRux
MIME-Version: 1.0
X-Received: by 10.43.130.2 with SMTP id hk2mr1398117icc.11.1380206190873; Thu, 26 Sep 2013 07:36:30 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Thu, 26 Sep 2013 07:36:30 -0700 (PDT)
In-Reply-To: 
References:     
Date: Thu, 26 Sep 2013 15:36:30 +0100
Message-ID: 
From: Ben Laurie 
To: Joseph Bonneau 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "therightkey@ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 14:37:01 -0000

On 26 September 2013 15:29, Joseph Bonneau  wrote:
>> I'd like some elaboration on the plan for step 6, creating a whitelist of
>>
>> > valid EV certificates without an SCT. How is this going to be achieved?
>>
>> Not sure what the question is - as the doc says, the list will be
>> constructed from the logs...
>
>
> I think I read it incorrectly as "without an embedded CT from *any* qualify
> logs" instead of "from all qualifying logs." Now I can see how the whitelist
> is created, but I'm less clear on what the intention of it is. Is the
> assumption that some certs will be issued with more than zero but fewer than
> three SCTs (proposed to the minimum acceptable in the "Qualifying
> Certificates" section) and you'd like to whitelist such certs during the
> rollout period?

Ah. So, all existing certs do not have embedded SCTs. So, we either
wait until all existing certs expire before we can enforce CT, or we
whitelist the unexpired certs.

> Also, why isn't there be a step 8 in the plan, where the whitelist is
> deprecated and every EV cert requires SCTs and Chrome is rejecting the EV
> certs without them?

The whitelist is fixed, so at some point all certs in the whitelist
expire, and the whitelist thus becomes empty.

From wtc@google.com  Thu Sep 26 07:51:55 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4063311E810A for ; Thu, 26 Sep 2013 07:51:55 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ED4jjz-0i-7d for ; Thu, 26 Sep 2013 07:51:45 -0700 (PDT)
Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0EFAC11E814F for ; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id i1so800835oag.34 for ; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bqm/sIB0/m0gj488Nv3VBSYqU3R8a3R9iZIQ+oAMGb4=; b=oh5XNC+zok0y7qaDGl1bcuOAgej69IO2DqfJV/v3RabrYYdL9cmT1HAimMMTc1RgFv NlSc0J6VlrmxU7ZianKWt6P0OKIX2NeYdH+JNRVogox5g7RzPrdOHJSjN3FksEuxn8iD Qe8H+kjI8UL9kGiwcVqmx6Cc0UNUPPMEtzECgYAqWS2UGnjWQrdzzjV6cl0gjvBvhYLq qUDDDk18hJRT7pbw9YE9Cfol0turOSGaswwQuN0u2kWHlKuG8bvqq0BIbjsKPN5MbVHa zEbVEDRUN3DjjAcrDi/Wlq/xVdlE0/RMxrspnA2QvBiJror7YHBiAP4VGiGRQcX6ToZG P6MQ==
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=bqm/sIB0/m0gj488Nv3VBSYqU3R8a3R9iZIQ+oAMGb4=; b=jrZnrmHPEUKD9PP5Ne3fyctOgTyotf5QwGhgccGmrjERWm090GBIw1Z6suJBbr0/+G Ho57xX9+xnvSx4qiDlmFfa4LZYZxlpnz4lxsPXysB5JW+21BtQYx+AE/YYsB0w8YjObz BzzvbGiN2aoxLm+HwN10z1jQLGo4C8jtjpCNX50nCCMTnW/OTvniThLyKUeShP5qG/SN aUobvtdGJIz2k7amx5756qwPgZkaW2tu8g1wmVrKJrS73IaR0i9tDt/W/eFmuAkWeDPA Fi8Dnb3jHKY2AHxIKP2i8D0kcyfOwEkiDaBVP0VMl07pGTi5IKr7OWQ2kcLbdFyrJRnw WE3A==
X-Gm-Message-State: ALoCoQnQ2EUqzqvl4WQ7BQNRyOcnsaPNy7SRoH+uoZ4EhpeA9bKz9OMSrvbMYRg4sSEyyZAE6ouEe3yIqJRgFVNLS7To7v04hmnSK6UAZwocXan5Ld7TYMG7tZW0La6k2GqGezl0TNQCgBT+37ylpOFOd2ERE+FDvpFiRMXyn4pjZ8cZKBe3hR4+0NvrsGB/nVkyaPE6oZ4f
MIME-Version: 1.0
X-Received: by 10.182.246.7 with SMTP id xs7mr642660obc.81.1380207103509; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
Received: by 10.182.79.105 with HTTP; Thu, 26 Sep 2013 07:51:43 -0700 (PDT)
In-Reply-To: 
References: 
Date: Thu, 26 Sep 2013 07:51:43 -0700
Message-ID: 
From: Wan-Teh Chang 
To: Phillip Hallam-Baker 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "tls@ietf.org" 
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 14:51:55 -0000

On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker  wrote:
> My understanding of the 1024 bit Ephemeral DH key issue is that it is not
> currently possible to use longer keys because a certain number of deployed
> Web servers will abort the connection if a client presents a longer key.

The size of ephemeral DH keys is specified by the server, and the
client must present a key of that size. (This doesn't change the
problem though.)

The client needs a way to negotiate the ephemeral DH key size (or the
DH domain parameters) with the server. This can be done by either an
extension (similar to the elliptic_curves extension of RFC 4492 for
ephemeral ECDH keys) or new cipher suites.

Wan-Teh Chang


>
> Hmmm, wonder who made that decision...
>
>
> Regardless, this is not a problem that will solve itself. Even if presenting
> a longer key will cause a connection to abort in 0.1% of cases, browsers are
> not going to make the attempt. So if nothing is done the legacy servers will
> prevent use of longer DH keys for the next 20+ years.
>
> I don't think a TLS version number upgrade is the solution either. It is
> just a bad idea for an algorithm suite identifier to mean one thing in TLS
> 1.2 and another in TLS 1.3.
>
>
> The simple solution to this problem in my view is to specify a new algorithm
> suite identifier for DH larger than 1024 and use that in parallel. That
> might get us to a point where 25% of Web Servers are using very strong EDH
> within 12-24 months.
>
>
> --
> Website: http://hallambaker.com/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From yngve@spec-work.net  Thu Sep 26 08:01:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E488D21F9ACA for ; Thu, 26 Sep 2013 08:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJD+8xtVDUeD for ; Thu, 26 Sep 2013 08:01:29 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1968021F8F4A for ; Thu, 26 Sep 2013 08:00:52 -0700 (PDT)
Received: from 228.72.202.84.customer.cdi.no ([84.202.72.228]:54511 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1VPD3j-0005cc-5m for tls@ietf.org; Thu, 26 Sep 2013 17:00:51 +0200
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: tls@ietf.org
References:  
Date: Thu, 26 Sep 2013 17:00:40 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" 
Message-ID: 
In-Reply-To: 
User-Agent: Opera Mail/12.15 (Win32)
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 15:01:44 -0000

Hi,


On Thu, 26 Sep 2013 16:51:43 +0200, Wan-Teh Chang  wrote:

> On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker   
> wrote:
>> My understanding of the 1024 bit Ephemeral DH key issue is that it is  
>> not
>> currently possible to use longer keys because a certain number of  
>> deployed
>> Web servers will abort the connection if a client presents a longer key.
>
> The size of ephemeral DH keys is specified by the server, and the
> client must present a key of that size. (This doesn't change the
> problem though.)
>
> The client needs a way to negotiate the ephemeral DH key size (or the
> DH domain parameters) with the server. This can be done by either an
> extension (similar to the elliptic_curves extension of RFC 4492 for
> ephemeral ECDH keys) or new cipher suites.

In my opinion the length of the DHE key should have at least the same  
length (number of bits) as the signing RSA key. And similar for ECDHE, if  
necessary.

Thus, no need to negotiate a length, or incur any delays caused by having  
to generate a new key to match the length requested by the client, or any  
performance problems caused by a client asking for a very long DHE key.

Unfortunately, based on what I have seen, it seems like the DHE keysizes  
are hardcoded in many cases.

> Wan-Teh Chang
>
>
>>
>> Hmmm, wonder who made that decision...
>>
>>
>> Regardless, this is not a problem that will solve itself. Even if  
>> presenting
>> a longer key will cause a connection to abort in 0.1% of cases,  
>> browsers are
>> not going to make the attempt. So if nothing is done the legacy servers  
>> will
>> prevent use of longer DH keys for the next 20+ years.
>>
>> I don't think a TLS version number upgrade is the solution either. It is
>> just a bad idea for an algorithm suite identifier to mean one thing in  
>> TLS
>> 1.2 and another in TLS 1.3.
>>
>>
>> The simple solution to this problem in my view is to specify a new  
>> algorithm
>> suite identifier for DH larger than 1024 and use that in parallel. That
>> might get us to a point where 25% of Web Servers are using very strong  
>> EDH
>> within 12-24 months.
>>
>>
>> --
>> Website: http://hallambaker.com/
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls


-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

From 57756671618275-ietf-tls@sublist.cr.yp.to  Thu Sep 26 08:28:59 2013
Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 450DE21F9FB0 for ; Thu, 26 Sep 2013 08:28:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.339
X-Spam-Level: 
X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=0.277,  BAYES_20=-0.74, SARE_BAYES_5x8=0.8, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf1OScwge+e8 for ; Thu, 26 Sep 2013 08:28:28 -0700 (PDT)
Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id D27CB21F9D18 for ; Thu, 26 Sep 2013 08:28:18 -0700 (PDT)
Received: (qmail 27820 invoked by uid 1011); 26 Sep 2013 15:28:06 -0000
Received: from unknown (unknown) by unknown with QMTP; 26 Sep 2013 15:28:06 -0000
Received: (qmail 15843 invoked by uid 1001); 26 Sep 2013 15:27:57 -0000
Date: 26 Sep 2013 15:27:57 -0000
Message-ID: <20130926152757.15842.qmail@cr.yp.to>
From: "D. J. Bernstein" 
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz>
Subject: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 15:28:59 -0000

Modern elliptic-curve cryptography solidly takes care of all of the
"brittleness" mentioned in this thread, and is much easier than RSA to
implement securely. Compare https://twitter.com/tweetnacl to the amount
of code required to implement similar functionality in OpenSSL.

Peter Gutmann writes:
> potentially NSA-influenced values like P256

There is indisputably an unexplained seed c49d3608 86e70493 6a6678e1
139d26b7 819f7e90 for the NIST P-256 curve mod 2^256-2^224+2^192+2^96-1,
and similarly for the other NIST curves. This was identified by the 2005
Brainpool standard as a major issue for the NIST curves; it has also
been highlighted recently by Bruce Schneier.

Fortunately, one can design high-security elliptic curves that don't
have any unexplained constants. That's what I did with Curve25519.
Curve25519 is the curve y^2=x^3+486662x^2+x mod 2^255-19; every number
here is completely explained in the Curve25519 paper.

> even without NSA skullduggery make a nice single target for attack.

There have already been several detailed studies of the cost of finding
multiple discrete logs on the same curve (authors: Escott, Sager,
Selkirk, Tsapakidis, Kuhn, Struik, Hitchcock, Montague, Carter, Dawson,
Lee, Cheon, Hong, Bernstein, Lange). Basically, if finding one ECC key
costs 2^128, then finding 1000000 keys costs 1000*2^128, and the first
key found will still cost 2^128. For comparison, finding 1000000 AES
keys costs the same 2^128 as finding a single key, and the first AES key
will be found with cost only 2^128/1000000.

Yaron Sheffer writes:
> The recipient needs to test that the received point is actually on
> the relevant curve.

This is certainly an issue for the NIST curves. Fortunately, this test
is completely unnecessary for x-coordinate ECC using twist-secure curves
such as Curve25519. I introduced this approach at ECC 2001, using the
smaller curve y^2=x^3+7530x^2+x mod 2^226-5 as an illustration.

Peter Gutmann writes:
> For example if you used the recommended (until not too long ago) way
> to generate your k for (EC)DSA then you'd leak a tiny bit of your
> private key on each signature (again, that nasty propensity of DLP
> algorithms to leak the private key).

Ed25519 has three levels of defense against this type of problem.

First, k is chosen as a random 512-bit string, many bits larger than the
group order l (around 2^252). This is overkill (compare to the 64 bits
in Algorithm 2 in Section 4.1.1 of BSI Technical Guideline TR-03111) but
also an inexpensive and comprehensive defense.

Second, the group order l is very close to a power of 2, specifically
within 2^125 of 2^252, so the bias would be unnoticeable even if k were
as small as 256 bits.

Third, k is actually produced in a deterministic way as a secret hash,
so the k-generation mechanism is fully testable---there's no need to
worry about the implementor accidentally choosing a biased RNG.

---D. J. Bernstein
   Research Professor, Computer Science, University of Illinois at Chicago

From benl@google.com  Thu Sep 26 08:36:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2444C21E8094 for ; Thu, 26 Sep 2013 08:36:23 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZkCphA26qa2 for ; Thu, 26 Sep 2013 08:36:22 -0700 (PDT)
Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8D47111E8104 for ; Thu, 26 Sep 2013 08:35:54 -0700 (PDT)
Received: by mail-ie0-f179.google.com with SMTP id e14so1554453iej.38 for ; Thu, 26 Sep 2013 08:35:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CH+IlXpXbdzcRGeylx02D3eZ78SUty4/XWv5VloKij0=; b=gO/XWJOgrsTSpW3eDKOOZsmStum1uosgH8hhYsC5Hh6YyQlWwsrh7vcKhd1sY7aT2X umo7oTcCKrn6qOrDHXfRHetIrDu5eZ246SP/A4+KCURzDn8ms+ZOEi6mJQQQmTFbWzR3 8XgUbySM8ExgiFsuWh6s2kqB7FESEJIXl3FmBGNvhJKZqTP3/+yy55ZlBTsh3hhOcmfW reSpPGuPG8hXji+8wYfZJA+trOUGo3VORq5pse93+qMpW4NErfOto3xQ57icohlC72TW jU/97vDqCmavI/tzq5W2lW58Edt4zoyVagSEBenr1eqfkgwWfhesgPvGZjnD7vgOKhFB qHOw==
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=CH+IlXpXbdzcRGeylx02D3eZ78SUty4/XWv5VloKij0=; b=ec64ekbQyDZ5es7UdaempEuCoL5lsiDkwbmr0BtsEjIbhmzaBjV6CjXCgETuIpiJR0 ksgkfMcyXdnGRf+7ZCqZWI5wazmZFcMxG4+FJBj9yE6hR6z+EJZi3t49gs37yDgw/IHk v2CppSNOoTHcmXsLDRT6yAeJ4PUAOZegopClXC+TjHBhzHO7kDSpbDV8TrLO2859qkbb 8F9vinsE5+sQZjWA8DAOnirxA6dA84Q18oTeXqZGtOLniooHuy4RgnEZfNQh2iGZOWUY S1ZtF2HoWzKvlJH6Ba8CVtTifBOX5ef2aayPhBR2sEOTNVAhpzoqOwBZQGGn04nmzQYx DRFg==
X-Gm-Message-State: ALoCoQl/064DN9n+QO/7FZYibtrqmzJwatnYrBBzZUR3c/ZKQFJoJyF3GLqzI5Y7U6eD7FyAtJ2ezH1F7mCZz7xXuez7a856/iRpDUo+KpavWqGIhAwZ636SMnfhbsMMpoMwDeUDrNo8vukdDOIHHLIsP9ObBbZEHC30JKtm62N0XDCUKqBLrA4eu7EFdX5m9FUVp1R2jfCG
MIME-Version: 1.0
X-Received: by 10.42.178.9 with SMTP id bk9mr815094icb.88.1380209752803; Thu, 26 Sep 2013 08:35:52 -0700 (PDT)
Received: by 10.64.230.140 with HTTP; Thu, 26 Sep 2013 08:35:52 -0700 (PDT)
In-Reply-To: 
References:       
Date: Thu, 26 Sep 2013 16:35:52 +0100
Message-ID: 
From: Ben Laurie 
To: Joseph Bonneau 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "therightkey@ietf.org" , "tls@ietf.org" 
Subject: Re: [TLS] [therightkey] Fwd: Improving EV Certificate Security
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 15:36:23 -0000

On 26 September 2013 15:44, Joseph Bonneau  wrote:
>
>> >> Not sure what the question is - as the doc says, the list will be
>> >> constructed from the logs...
>> >
>> >
>> > I think I read it incorrectly as "without an embedded CT from *any*
>> > qualify
>> > logs" instead of "from all qualifying logs." Now I can see how the
>> > whitelist
>> > is created, but I'm less clear on what the intention of it is. Is the
>> > assumption that some certs will be issued with more than zero but fewer
>> > than
>> > three SCTs (proposed to the minimum acceptable in the "Qualifying
>> > Certificates" section) and you'd like to whitelist such certs during the
>> > rollout period?
>>
>> Ah. So, all existing certs do not have embedded SCTs. So, we either
>> wait until all existing certs expire before we can enforce CT, or we
>> whitelist the unexpired certs.
>
>
> I think I'm back to my original question now :-) How do all the existing
> certs get into the CT log? (at which point building the whitelist is easy)
> Is the onus on EV users then to log their old certs or face failing in
> Chrome? Or do EV-issuing CAs have sufficient records of what they've issued?

My assumption is that this is true. If it's not, then CAs need to tell us :-)

> Or is this something that we're hoping can be (at least mostly) achieved by
> network observation?

This is also likely.

From dbrown@certicom.com  Thu Sep 26 09:47:27 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF89821F9F80 for ; Thu, 26 Sep 2013 09:47:27 -0700 (PDT)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level: 
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=-1.488, BAYES_20=-0.74]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8WRnrltVyRE for ; Thu, 26 Sep 2013 09:47:22 -0700 (PDT)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1B721F9F01 for ; Thu, 26 Sep 2013 09:47:04 -0700 (PDT)
Content-Type: multipart/mixed; boundary="===============0395656752=="
MIME-Version: 1.0
Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/AES128-SHA; 26 Sep 2013 12:46:41 -0400
Received: from XCT110CNC.rim.net (10.65.161.210) by XCT107CNC.rim.net (10.65.161.207) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 26 Sep 2013 12:46:41 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT110CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Thu, 26 Sep 2013 12:46:40 -0400
From: Dan Brown 
To: "'djb@cr.yp.to'" , "'tls@ietf.org'" 
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOus0hxn3XJXmgAkKRAg2ZE6kwf5nYKGnA
Date: Thu, 26 Sep 2013 16:46:39 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net>
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to>
In-Reply-To: <20130926152757.15842.qmail@cr.yp.to>
Accept-Language: en-CA, en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.65.160.251]
MIME-Version: 1.0
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 16:47:28 -0000

--===============0395656752==
Content-Language: en-US
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
	micalg=SHA1; boundary="----=_NextPart_000_0000_01CEBAB6.714ABA20"

------=_NextPart_000_0000_01CEBAB6.714ABA20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit



> D. J. Bernstein writes
> 
> 
> Peter Gutmann writes:
> > potentially NSA-influenced values like P256
> 
> There is indisputably an unexplained seed c49d3608 86e70493 6a6678e1
> 139d26b7 819f7e90 for the NIST P-256 curve mod 2^256-2^224+2^192+2^96-
> 1, and similarly for the other NIST curves. This was identified by the

[DB] Five NIST curves are Koblitz curves, which do not have seeds at all.
They also use small curve coefficients, which is similar to Curve25519.

> 2005 Brainpool standard as a major issue for the NIST curves; it has
> also been highlighted recently by Bruce Schneier.

[DB] I must have forgotten that aspect of the Brainpool standard.  If
possible, please remind me of the issue, if only by link to the relevant
document (and section thereof).  In particular, I already tried to summarize
on this list (in response to a message from Douglas Stebila) an argument
that a consistent treatment of ECC must mildly reduce, or at least revise,
the claimed security of any EC curve if the treatment also posits that NIST
curves have an undisclosed strong weakness.  I may have missed an something
important.  To further elaborate my argument: it is possible to formulate
one's suspicion in such that way that one needs only to boost one's curve
size accordingly.  For example, if one suspects an undisclosed class of
curves whose density is say n^(1/8) where n is the curve size, then, to
resist falling into this class, one can choose n large enough, so that the
risk is small enough.  Such risk should be somehow calibrated with claimed
security levels: e.g. if we want the adversary to incur computational cost
of 2^128 at success rate near 1, we may be satisfied with success rate
2^(-48) at cost near 1.  With these settings might choose a 384-bit curve
instead of 256-bit curve.  This doesn't protect against constant density
classes, but is at least worth something.  Of course, I made up the n^(1/8).
One might look at the densities of the current weak classes: one has n^(1/2)
and the other (MOV) has, hmm, I have to study it some more, I just remember
a result that says it's low.  

If I recall correctly, the Brainpool documents recommended against, or at
least avoided, special classes of curves.  I have argued on this list that
Curve25519 is special in its use of small coefficients.  What's your thought
on the risk of this?  So far, the main two weak classes of prime-field
curves are negligible density.  If the future reveals such classes, then it
seems that attempting to select curves verifiably at random is a more solid
way to avoid falling into such a class than choosing a special curve.  If I
recall correctly, the MNT curves were special curves chosen for desirable
characteristics, that later fell into one of these classes.  

> 
> Fortunately, one can design high-security elliptic curves that don't
> have any unexplained constants. That's what I did with Curve25519.

[DB] Wasn't this well-known already for Koblitz curves, or are they broken?
I may have lost track, since there has been recent improvements in (EC)DLP
over extension fields.  I had thought that maybe Koblitz curves remained
unaffected.  (Also, some standards, e.g. ANSI X9.63 have long prohibited
such extension-field curves, which might be a good case of anticipation, or
perhaps just promotion of interoperability).

> Curve25519 is the curve y^2=x^3+486662x^2+x mod 2^255-19; every number
> here is completely explained in the Curve25519 paper.

[DB] Does Curve25519 ignore Cheon-type "attacks" (which are rather weak)?
If so, that's probably fine for TLS, because the attacks do not affect TLS,
unless the TLS-PRF is much weaker than we think, and DH private keys are
very heavily re-used.  So, I mainly ask for completeness.  Also, the NIST
curves and the Brainpool curves do not incorporate any countermeasures to
these attacks (the Brainpool deliberately so).

> 
> > even without NSA skullduggery make a nice single target for attack.
> 
> There have already been several detailed studies of the cost of finding
> multiple discrete logs on the same curve (authors: Escott, Sager,
> Selkirk, Tsapakidis, Kuhn, Struik, Hitchcock, Montague, Carter, Dawson,
> Lee, Cheon, Hong, Bernstein, Lange). Basically, if finding one ECC key
> costs 2^128, then finding 1000000 keys costs 1000*2^128, and the first
> key found will still cost 2^128. For comparison, finding 1000000 AES
> keys costs the same 2^128 as finding a single key, and the first AES
> key will be found with cost only 2^128/1000000.
> 

[DB] Good point. 

I had interpreted the comment differently to refer to attacking the curve
itsel (which would support using a random curve for each TLS handshake, for
example).  A typical response to the comment (under my interpretation) is
that AES and SHA2 are also nice single targets, and well maybe, that's a
good thing, with incentives, publicity, and so on.

------=_NextPart_000_0000_01CEBAB6.714ABA20
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUgTCCBnAw
ggVYoAMCAQICChfYCekAAwAXxTIwDQYJKoZIhvcNAQEFBQAwUDETMBEGCgmSJomT8ixkARkWA25l
dDETMBEGCgmSJomT8ixkARkWA3JpbTEkMCIGA1UEAxMbUklNIFN1Ym9yZGluYXRlIENBIE1DQTAz
WUtGMB4XDTEzMDUyODE1NDQwOVoXDTE0MDUxNzAwMjMzM1owgYUxEzARBgoJkiaJk/IsZAEZFgNu
ZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xETAPBgNVBAsTCENlcnRpY29tMQ4wDAYDVQQLEwVVc2Vy
czESMBAGA1UEAxMJRGFuIEJyb3duMSIwIAYJKoZIhvcNAQkBFhNkYnJvd25AY2VydGljb20uY29t
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDRc70RE0/FL9ZbfN64YjA0lkQOLR9ipGebc9nH
jB93OfYfR7CVsCUYy3+v9PO1DiUS9MeWWR4nxB9Ztee32d3syDxGg3PGFwSrms/ORAW9pgiS/yKH
An9SKRKyqMz9LSn/VQrEgoyPBPT0S/vg521MGH58MwMXyLm1cLBQU5gtCQIDAQABo4IDmDCCA5Qw
CwYDVR0PBAQDAgWgMEQGCSqGSIb3DQEJDwQ3MDUwDgYIKoZIhvcNAwICAgCAMA4GCCqGSIb3DQME
AgIAgDAHBgUrDgMCBzAKBggqhkiG9w0DBzAdBgNVHQ4EFgQUAlQmTNpWxnzoCUVjxGTtDz2JvLww
FwYJKwYBBAGCNxQCBAoeCABVAHMAZQByMB8GA1UdIwQYMBaAFLgwF25vZ5X+hYxoO6XhF7M/+CU6
MIIBMQYDVR0fBIIBKDCCASQwggEgoIIBHKCCARiGgctsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGlu
YXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1NQ0EwM1lLRixDTj1DRFAsQ049UHVibGljJTIwS2V5JTIw
U2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2Fs
P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRp
b25Qb2ludIZIaHR0cDovL21jYTAzeWtmLnJpbS5uZXQvQ2VydEVucm9sbC9SSU0lMjBTdWJvcmRp
bmF0ZSUyMENBJTIwTUNBMDNZS0YuY3JsMIIBQQYIKwYBBQUHAQEEggEzMIIBLzCBwgYIKwYBBQUH
MAKGgbVsZGFwOi8vL0NOPVJJTSUyMFN1Ym9yZGluYXRlJTIwQ0ElMjBNQ0EwM1lLRixDTj1BSUEs
Q049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixE
Qz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZp
Y2F0aW9uQXV0aG9yaXR5MGgGCCsGAQUFBzAChlxodHRwOi8vbWNhMDN5a2YucmltLm5ldC9DZXJ0
RW5yb2xsL01DQTAzWUtGLnJpbS5uZXRfUklNJTIwU3Vib3JkaW5hdGUlMjBDQSUyME1DQTAzWUtG
KDMpLmNydDApBgNVHSUEIjAgBgorBgEEAYI3CgMEBggrBgEFBQcDBAYIKwYBBQUHAwIwQQYDVR0R
BDowOKAhBgorBgEEAYI3FAIDoBMMEWRhbmlicm93bkByaW0ubmV0gRNkYnJvd25AY2VydGljb20u
Y29tMA0GCSqGSIb3DQEBBQUAA4IBAQC6hxWgDv96DUDS3m8XfyVGAv1CKOcWSVOShz/jofFMFzoN
o2dhc0Jg9XTTZBVS+ozakEM+87YUENfP3IODRbCiJBsbiXJxS+fVo7L/bqPp47TB+Lg2/tezlNa2
ab4psmc9xjZGU9+A4lBzS5PpRjvHofsIwETpwt/aPxHIbJ5Cf7kBi7B8hR4mIqc7EJMYXeI0xHLg
k3NqBYSGC3XtbykuFV0vPFoTYLO7G3pAP2RzGhuxQoaH4fpWvE3rdakjd1MZFqJrarXSvWi6ah6G
Alt7+sOTzlGNqoTQqb55VZEOrU2A1VbmAFjiFR1/229A2KaHhnN6cuNe8bhzoBcnuxtyMIIGvzCC
BKegAwIBAgIQMhrzkrEUWZRNTS+VEbN74TANBgkqhkiG9w0BAQUFADBPMRUwEwYKCZImiZPyLGQB
GRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQDExRSSU0gUm9vdCBDQSBN
Q0EwMVlLRjAeFw0wNjEwMTMwMTI0NTVaFw0xNjEwMTMwMTMwNDFaME8xFTATBgoJkiaJk/IsZAEZ
FgVsb2NhbDEXMBUGCgmSJomT8ixkARkWB3dpbmRvd3MxHTAbBgNVBAMTFFJJTSBSb290IENBIE1D
QTAxWUtGMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAxui6zvytVAEtPzv6NhK7OZna
iw/jQEyEVskDf5yzcFkLT/+5PztIbv+eFmL1CP2FhvLv8eQZJDKF4Yv+UsjPEN1lX4DDGKKt0NPp
yT9pwQzFaiUt0rnERgSabo7EtpS4S+DuL8G9c+lmWwDqb0UWtPMdVfbr3fDwigyz1yh+vVMAHdhg
Oe9lPC6nPtiJ9IXTam7V5mJmDT0mNpq/0fJo3JEaNvDKoXBOkKv6IdbtKxKzPInG6VYaCdgJCAT3
mWgr9kxiEQEUJKrvI2fXI0zRYnlL648gvK84pdsT2xZLFtr4OdZAm4RkK8U+cgurlSCr6NVqnfbq
6/3N6MGmyc9SB2Ayhk2VS66757V4nBzeaeD+srpk4IXU3NTM/+YgR1zVS41XwvZaq9Uf59j0TJhN
9xGVZO871eVVr2VfNxr0xOqUpwcxh5JZYkWcmUJFlYiQh0CM2PrfaDRTTqRZQd4F3xUlcXFAXOGh
vaXKvikeI6/utnX6vCnDwMUxmenzlv8epNatxDsuIgOWO4pfqgGMyzWo2hudQ97+5ynUqDLX34nr
UzszGeIE3KoqYsksxMF3tqIgadt9hNWXaP/EknZpRAmaP0s0V5ZvgiyXw9UrqnWwmRbLQk7HnYc0
hHQBjXoByKSiOyhgSS9yL6a+7AA2rhBPpsSVI9LYBs2cNKlPsZcCAwEAAaOCAZUwggGRMBMGCSsG
AQQBgjcUAgQGHgQAQwBBMAsGA1UdDwQEAwIBRjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTW
aYJkJBbBzCTb8RR9RxJ83MlN7jCCASkGA1UdHwSCASAwggEcMIIBGKCCARSgggEQhoHEbGRhcDov
Ly9DTj1SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRixDTj1NQ0EwMVlLRixDTj1DRFAsQ049UHVi
bGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5k
b3dzLERDPWxvY2FsP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1j
UkxEaXN0cmlidXRpb25Qb2ludIZHaHR0cDovL21jYTAxeWtmLndpbmRvd3MubG9jYWwvQ2VydEVu
cm9sbC9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcmwwEAYJKwYBBAGCNxUBBAMCAQAwDQYJ
KoZIhvcNAQEFBQADggIBAEOeWFu4OVTnx9+jYk92iDra2f1Bc5j1WesEGINl4VCY9WJy6n17b/h2
fDmjj9KfIto3LE2Wej77lSJqv/LSd7wnfTQVZVb1wBe2Zt+LuPAqi6vWSDAQVOfdOMYVu5imznnf
+ZNMLduTqXZ/bFQKTWsg2qhBWwaiYfxEY7nVg3+ZfStqwc9R3v/tHH+b9kX3FuKLoVQ6KSrqUyBi
fhIRj57eOw6/JjPA+SId/p2yEZ+xmANQ31vE3BHFRm20kZHHqAfdCmTt1S7LDSLHBj3GZXIFUge9
aPKqzAXee2DCYTP3YYcgrP/FbFF2RqGRIhPM+MdjJraMjex+nNT+2KC/EIWsbU9DgFII0wHKpRx8
rlJNN8kmb/H9qGqcNaW9Q/pwUTpX1bXSdbzvYFs3NY7KmYYii4Q0RQCGr96OvDT0/S6/IrnW+vqZ
jnPV2MXqEuyQ0L5HXVOnCi769uGYcRkEo5xzEJ/EMvj07vCWnG7h9ykNhLEEMcygVmBdXP9qOqog
dyPJB0AzxAYGqCSMT8Ors1M/srZSXUCfSfENH5iBd7bxH7uXmF7kbOEghom7AccC2Clt4DU0tj9s
FyIWg5H6zy6NLetm2/kzdD3mGY3u2tWtijVnd2CWY2YszYo1lbDAfEfjGL/9uFpH79Zt9ekRSD5Z
bSn1SNr1njjeGpV3jwyuMIIHRjCCBS6gAwIBAgIKFnKQQQAAAAABuDANBgkqhkiG9w0BAQUFADBP
MRUwEwYKCZImiZPyLGQBGRYFbG9jYWwxFzAVBgoJkiaJk/IsZAEZFgd3aW5kb3dzMR0wGwYDVQQD
ExRSSU0gUm9vdCBDQSBNQ0EwMVlLRjAeFw0xMjA1MTcwMDEzMzNaFw0xNDA1MTcwMDIzMzNaMFAx
EzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBT
dWJvcmRpbmF0ZSBDQSBNQ0EwM1lLRjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfx
jFzEuYa/qd6dXu4HILtBdH3+Bgwz3uQakDcxvrf3fyVQBy69KFOS8/h5REe6bit3tp5wsQQv/nFV
mmXK/jq9zD72zl3jv63UzZgOWC90846UxTTmmNEyHzo1M54B3LrnE6L2Q6QbEZMAnrJ96uV8pN2X
Zsn5j+MvfI5ajFu+6oPbHeYzQjZB3GDju7sELm7cAcr0YYX3xeLTB2rLUUZF6Nyyc0btD57ARYEa
99A+6JslO8VcxtlgRddx17NB6gttNjwmJFT3l3UVcK5O5+UVSWpW1zQbZQBvl0iP7gXcrJW4Dv0p
036iHg9lgDV1qQChi9NCixwm7yYtCHLq9akCAwEAAaOCAyEwggMdMA8GA1UdEwEB/wQFMAMBAf8w
HQYDVR0OBBYEFLgwF25vZ5X+hYxoO6XhF7M/+CU6MAsGA1UdDwQEAwIBhjAQBgkrBgEEAYI3FQEE
AwIBAzAjBgkrBgEEAYI3FQIEFgQUZUBVml3ak56Kwnbul6AULvNdck8wGQYJKwYBBAGCNxQCBAwe
CgBTAHUAYgBDAEEwHwYDVR0jBBgwFoAU1mmCZCQWwcwk2/EUfUcSfNzJTe4wggEpBgNVHR8EggEg
MIIBHDCCARigggEUoIIBEIaBxGxkYXA6Ly8vQ049UklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Ys
Q049TUNBMDFZS0YsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz
LENOPUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRp
b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnSGR2h0dHA6Ly9tY2Ew
MXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvUklNJTIwUm9vdCUyMENBJTIwTUNBMDFZS0Yu
Y3JsMIIBPAYIKwYBBQUHAQEEggEuMIIBKjCBuwYIKwYBBQUHMAKGga5sZGFwOi8vL0NOPVJJTSUy
MFJvb3QlMjBDQSUyME1DQTAxWUtGLENOPUFJQSxDTj1QdWJsaWMlMjBLZXklMjBTZXJ2aWNlcyxD
Tj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9uLERDPXdpbmRvd3MsREM9bG9jYWw/Y0FDZXJ0aWZp
Y2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwagYIKwYBBQUHMAKG
Xmh0dHA6Ly9tY2EwMXlrZi53aW5kb3dzLmxvY2FsL0NlcnRFbnJvbGwvTUNBMDFZS0Yud2luZG93
cy5sb2NhbF9SSU0lMjBSb290JTIwQ0ElMjBNQ0EwMVlLRi5jcnQwDQYJKoZIhvcNAQEFBQADggIB
AK/ZTtcAxFAZJo37z0KG3EGIGIScPRus90jBJGQO9+Mrb4QRoMjkCwZP9GbYq2CxCqOBiKOZfkSK
PMSupPLRlE70z9tGbsMz13ExQy50WZS9n4XRxglyDRga1fQVwGNF+SMPaBzQapiFi3CkBWNSdz+f
aRdkdiqIvG3hxkbk6AXr6xhlu2mvnhJ/dE248lZDmN3FkWDHXEgEd5uHxwd7nWjxXVuzRV0oNgrG
E96uTqLHVsdefHplPwyrIlgV4SY1ST1y8nKhZlB4IX8fDIj1Xr3rRssW+8XEKSILvawoU47n34x6
xZrO8nbramu3s3BPDnPBe5d1akBYA/nTKb9l6by6dNzJ7u1r73w7/tC53Hgf+826w6Gw+Z6Xs1d2
6RvukJ+7VCyKTR+rg+jASrfhS7naerxVMoOZwr6GxqqHYbK1gp3ag8Ek1U62/LYLqbvYMn58e23k
q1pR6vLfQY4AhteMJipLmkxioYjHMCm9rTCZCnU2e/yvNNGXXq8WEeJpAc7hXbFR8L7VTaawkSxg
jtJ2YTLvGH0cM/lEOAn3UGUG1lAhBBBzpLS4oW+ITZ5LsPWx2UiWAHLF79XE+PzvFE1+haf4HzJ0
KNKizMaj6DyVJN/oLOvdlVn32x70hCkr9zPFM6f4wEtQoY+qV3Q13zB7FePumyia5+/xmioObwts
MYICrjCCAqoCAQEwXjBQMRMwEQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmlt
MSQwIgYDVQQDExtSSU0gU3Vib3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwCQYFKw4D
AhoFAKCCAaYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTI2
MTY0NjM4WjAjBgkqhkiG9w0BCQQxFgQUmYJ906ZBkUqMhosjBOqWrr2tseswZwYJKoZIhvcNAQkP
MVowWDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw
DQYIKoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwbQYJKwYBBAGCNxAEMWAwXjBQMRMw
EQYKCZImiZPyLGQBGRYDbmV0MRMwEQYKCZImiZPyLGQBGRYDcmltMSQwIgYDVQQDExtSSU0gU3Vi
b3JkaW5hdGUgQ0EgTUNBMDNZS0YCChfYCekAAwAXxTIwbwYLKoZIhvcNAQkQAgsxYKBeMFAxEzAR
BgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xJDAiBgNVBAMTG1JJTSBTdWJv
cmRpbmF0ZSBDQSBNQ0EwM1lLRgIKF9gJ6QADABfFMjANBgkqhkiG9w0BAQEFAASBgI/Pj78zffJx
ILhkBVju310RKvDKIkr4sjufkTkH1Tez/KvFQwhzNVG5zsXtuU7/mc+2lXvTcD3/RmFc4/oz13BO
gv8eOuHK5qJ1ukJiY3ebV6jvQUXUHrkkeV9cEnCGIlqmFWjhQ9uzOeVpAoFFrxsdkKIrGo7OacWl
g79LZFIzAAAAAAAA

------=_NextPart_000_0000_01CEBAB6.714ABA20--

--===============0395656752==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info=
rmation, privileged material (including material protected by the solicitor=
-client or other applicable privileges), or constitute non-public informati=
on. Any use of this information by anyone other than the intended recipient=
 is prohibited. If you have received this transmission in error, please imm=
ediately reply to the sender and delete this information from your system. =
Use, dissemination, distribution, or reproduction of this transmission by u=
nintended recipients is not authorized and may be unlawful.
--===============0395656752==--

From yaronf.ietf@gmail.com  Thu Sep 26 13:15:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AE521E80AA for ; Thu, 26 Sep 2013 13:15:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.501
X-Spam-Level: 
X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6UZmr1708oj for ; Thu, 26 Sep 2013 13:15:03 -0700 (PDT)
Received: from mail-ee0-x22a.google.com (mail-ee0-x22a.google.com [IPv6:2a00:1450:4013:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 388B121F89A5 for ; Thu, 26 Sep 2013 13:15:01 -0700 (PDT)
Received: by mail-ee0-f42.google.com with SMTP id b45so809560eek.1 for ; Thu, 26 Sep 2013 13:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=tKl/uHtwXEpQb9/yOtv4e/SHp1Q2qqXYgcNpb7Wl++8=; b=v0SbOq9yfbuz/nQq2cKAAyETiTSF2XT6hkAHOxmk0jjJJZYWzTwWxL2YydcDHpyUTQ 4BR10UDXguxdm0EcNR+u9wZeYo8vXVv8kjjq1hohkbAAIlIehv7dPgt5qeAkWhUmqSc2 cvYJoZPyw7DJ03nkB7EzJcINZNSahKc5dBQpUjqk/UXp6LmooUcgneLwByN1IVX5aAH1 ojgNBaIO6OqqwMLScIPdgdvHyHCrnvZul9B0aokrrbOO/qvqccjWLcle3YajaSWGYCG3 AgOrUSrgF8zIA10ktcB8Pt+NvQ6TBZWQgfs6YzjmyEdvis5bVXFCHEgJ/3z1tO0rwsdu ZeJg==
X-Received: by 10.15.36.9 with SMTP id h9mr4164148eev.30.1380226500386; Thu, 26 Sep 2013 13:15:00 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id k7sm7786288eeg.13.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 26 Sep 2013 13:14:58 -0700 (PDT)
Message-ID: <524495C0.5010701@gmail.com>
Date: Thu, 26 Sep 2013 23:14:56 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Wan-Teh Chang ,  Phillip Hallam-Baker 
References:  
In-Reply-To: 
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" 
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 26 Sep 2013 20:15:04 -0000

Yes, the problem is with clients not accepting the server's parameter 
choice.

I would prefer an extension to solve this problem, because:
- You can encode more information, e.g. the minimum AND maximum 
parameter sizes acceptable to the client.
- It is similar to RFC 4492.
- You avoid the cross-product problem of specifying large DHE versions 
for lots of cipher suites.

Thanks,
	Yaron

On 09/26/2013 05:51 PM, Wan-Teh Chang wrote:
> On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker  wrote:
>> My understanding of the 1024 bit Ephemeral DH key issue is that it is not
>> currently possible to use longer keys because a certain number of deployed
>> Web servers will abort the connection if a client presents a longer key.
>
> The size of ephemeral DH keys is specified by the server, and the
> client must present a key of that size. (This doesn't change the
> problem though.)
>
> The client needs a way to negotiate the ephemeral DH key size (or the
> DH domain parameters) with the server. This can be done by either an
> extension (similar to the elliptic_curves extension of RFC 4492 for
> ephemeral ECDH keys) or new cipher suites.
>
> Wan-Teh Chang
>
>
>>

From pgut001@cs.auckland.ac.nz  Thu Sep 26 23:41:22 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84D21E80E7 for ; Thu, 26 Sep 2013 23:41:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.587
X-Spam-Level: 
X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovDFmmNQNupA for ; Thu, 26 Sep 2013 23:41:16 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37621E808F for ; Thu, 26 Sep 2013 23:41:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1380264074; x=1411800074; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=kP25js6bM2VW0vIR62NZpHIALP+U/8UQOCgpIf1Uf8g=; b=F8KkuZyMgXfBuRqvvQgECb7ay8fvN6AOpLEoWYk8bbwGa1GX1SIAArDq mGhMm90x5FLF1qpUEcmPWNAfgtRxZj+O4gFzEmJ+6y6siUzif2/IKp+7y AeqJNrN1JVldnOGYFHC3lJhJPMk0wQ4yn+dORQQ/ctOVEUXjLyzvoW7BB Y=;
X-IronPort-AV: E=Sophos;i="4.90,991,1371038400"; d="scan'208";a="214508260"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing
Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 27 Sep 2013 18:41:10 +1200
Received: from UXCN10-6.UoA.auckland.ac.nz ([169.254.10.92]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 18:41:09 +1200
From: Peter Gutmann 
To: "" 
Thread-Topic: [TLS] New Algorithm identifier for EDH > 1024 bits?
Thread-Index: Ac67TImS2B3T+9kATv+sBl6Xqb9E8Q==
Date: Fri, 27 Sep 2013 06:41:09 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C735567E500@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 06:41:22 -0000

Phillip Hallam-Baker  writes:=0A=
=0A=
>My understanding of the 1024 bit Ephemeral DH key issue is that it is not=
=0A=
>currently possible to use longer keys because a certain number of deployed=
=0A=
>Web servers will abort the connection if a client presents a longer key.=
=0A=
>=0A=
>Hmmm, wonder who made that decision...=0A=
=0A=
Could that be because of all of the TLS_DHE_DSS_* suites, with DSS limited =
to=0A=
1024 bits so implementers also limited the matching DH to 1024 bits?  Just=
=0A=
wondering what other reason there could possibly be for artificially limiti=
ng=0A=
the size to 1024 bits.=0A=
=0A=
Peter.=0A=

From ynir@checkpoint.com  Fri Sep 27 06:44:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EFB21F9CAF for ; Fri, 27 Sep 2013 06:44:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.353
X-Spam-Level: 
X-Spam-Status: No, score=-10.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLgWK3lKhcSD for ; Fri, 27 Sep 2013 06:44:32 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6175921F9C9A for ; Fri, 27 Sep 2013 06:44:32 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8RDhnJh006218; Fri, 27 Sep 2013 16:43:54 +0300
X-CheckPoint: {52458B95-B-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Fri, 27 Sep 2013 16:43:49 +0300
From: Yoav Nir 
To: Peter Gutmann 
Thread-Topic: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
Thread-Index: Ac66cK4N1LGTHq4KZUmWOLq5UD/ySAA/c8MA
Date: Fri, 27 Sep 2013 13:43:49 +0000
Message-ID: 
References: <9A043F3CF02CD34C8E74AC1594475C735567DB9B@uxcn10-6.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567DB9B@uxcn10-6.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.136]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17B27E781271C34C8F482ED3195FE624@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] Comments/Questions on draft-gutmann-tls-encrypt-then-mac-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 13:44:38 -0000

On Sep 26, 2013, at 7:27 AM, Peter Gutmann  wrot=
e:

> Michael D'Errico  writes:
>=20
>> Instead of particular versions, it seems to me that an indicator of "I
>> tried to connect using a higher version than I'm using now but had to
>> fall back to this verion" would cover any case now or later.
>=20
> That seems more intuitively useful from the server admin's point of view,
> you could use it to gather traffic stats on forced fallbacks, detect
> middleboxes, and so on.  It'd also allow you to make informed decisions
> on how far you want to fall back, for example you could use it to=20
> determine that only 0.5% of users are having to fall back to SSLv3 and=20
> therefore refuse to connect below TLS 1.0.

That kind of statistics collection would work if clients did something like=
 this:
 - Try with TLS 1.2 with extensions... failed
 - Try with TLS 1.1 with extensions... failed
 - Try with TLS 1.0 with extensions... failed
 - Try with TLS 1.0 without extensions... failed
 - Try with SSLv3

But browser makers are very much concerned about connection time. So the se=
quence is going to be TLS 1.0 (with 1.2 in the ClientHello) with extensions=
, and then straight down to SSLv3 (or TLS 1.0 without extensions if SSLv3 i=
s disabled).

So if something blocks TLS 1.1 or 1.2, you're going to get the percentage o=
f clients that have SSLv3 enabled (and are behind some meddling middlebox)

Yoav


From ynir@checkpoint.com  Fri Sep 27 06:48:41 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5721F9F88 for ; Fri, 27 Sep 2013 06:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.36
X-Spam-Level: 
X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239,  BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2tcEJ6HYXuS for ; Fri, 27 Sep 2013 06:48:32 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 307CC11E80F8 for ; Fri, 27 Sep 2013 06:48:28 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8RDmRn6008119; Fri, 27 Sep 2013 16:48:27 +0300
X-CheckPoint: {52458CAB-31-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Fri, 27 Sep 2013 16:48:27 +0300
From: Yoav Nir 
To: "Yngve N. Pettersen" 
Thread-Topic: [TLS] New Algorithm identifier for EDH > 1024 bits?
Thread-Index: AQHOusLlwoOMr2hLMkyK9fecAbG0bZnX6AOAgAACgQCAAX47AA==
Date: Fri, 27 Sep 2013 13:48:26 +0000
Message-ID: <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>
References:   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.21.136]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3F6F27E4FC308240BBE3824DCE6FDBB0@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 13:48:41 -0000

On Sep 26, 2013, at 6:00 PM, Yngve N. Pettersen  wrote=
:

> Hi,
>=20
>=20
> On Thu, 26 Sep 2013 16:51:43 +0200, Wan-Teh Chang  wrote:
>=20
>> On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker =
 wrote:
>>> My understanding of the 1024 bit Ephemeral DH key issue is that it is n=
ot
>>> currently possible to use longer keys because a certain number of deplo=
yed
>>> Web servers will abort the connection if a client presents a longer key=
.
>>=20
>> The size of ephemeral DH keys is specified by the server, and the
>> client must present a key of that size. (This doesn't change the
>> problem though.)
>>=20
>> The client needs a way to negotiate the ephemeral DH key size (or the
>> DH domain parameters) with the server. This can be done by either an
>> extension (similar to the elliptic_curves extension of RFC 4492 for
>> ephemeral ECDH keys) or new cipher suites.
>=20
> In my opinion the length of the DHE key should have at least the same len=
gth (number of bits) as the signing RSA key. And similar for ECDHE, if nece=
ssary.

Not for ECDHE_RSA, though. That would require that we define what ECDHE cur=
ve is equivalent to X-bit RSA.

In general I don't like us doing the NIST magic tables of naming equivalent=
 strength key lengths among different algorithms, as in 1024-bit RSA is sim=
ilar to some non-existing 80-bit perfect symmetric algorithm, and a 1024-bi=
t MODP group is sort of like that.

Yoav


From yaronf.ietf@gmail.com  Fri Sep 27 08:08:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAB911E8160 for ; Fri, 27 Sep 2013 08:08:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level: 
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj4UaYHwz1l9 for ; Fri, 27 Sep 2013 08:08:19 -0700 (PDT)
Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1170D11E814E for ; Fri, 27 Sep 2013 08:08:03 -0700 (PDT)
Received: by mail-ea0-f181.google.com with SMTP id d10so1263484eaj.26 for ; Fri, 27 Sep 2013 08:07:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=unxE/cSHKvp7MMyg/GJ7tbiH5FQW9HHJ3Vdxe/QOf3g=; b=C7t9cVYfcbj5+6fRbMAIMz53T/iDFF64bVWJ6qpH0I/GVrv0l7/H9pVz2idmCR6kzs 75R96JBsmUhSIKMfsqCJlAJ38bHVHhYYB4D63Nbm+syklDA0MNYM6siEecADME7wQP7N qe6j9Qpfk+JrDBN/jTYbJpDqrCWs0drwqUClFyF0JdEqSKgDrBR0Ml8KvqZahX3mQesN 1HbWgyMdDb9A7CLZ6vdkVwkv+JDnwa7jYkJcByG9MHi3zGFMZ994FEqPMSKaplQr4tj5 KFHDj49YcH7j+dvbpO0pM0n0mTdiMoDrD8QMS8t6LHe9+eINNbcV6Db8qCX8XoLu6l0P D8bA==
X-Received: by 10.14.198.197 with SMTP id v45mr4850536een.52.1380294471280; Fri, 27 Sep 2013 08:07:51 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id a43sm17147368eep.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 08:07:50 -0700 (PDT)
Message-ID: <52459F3E.2050101@gmail.com>
Date: Fri, 27 Sep 2013 18:07:42 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Yoav Nir ,  "Yngve N. Pettersen" , "" 
References: 		 <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>
In-Reply-To: <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 15:08:20 -0000

While we're opening (maybe) the negotiation of DHE, I'd like to clarify 
an issue that bothers me in the implementation of DHE in TLS:

With DHE, the premaster secret depends only on the DH shared secret. We 
know that DHE is commonly used with 1024-bit parameters. So even if you 
have a 2048-bit RSA certificate, the session strength will be 1024 bits.

What if we mixed *both* the DH secret and the regular encrypted nonce 
that's used in RSA ciphersuites into the premaster secret? Wouldn't we 
get forward secrecy, as well as crypto strength equivalent to the higher 
of the two lengths?

Thanks,
	Yaron

On 09/27/2013 04:48 PM, Yoav Nir wrote:
>
> On Sep 26, 2013, at 6:00 PM, Yngve N. Pettersen  wrote:
>
>> Hi,
>>
>>
>> On Thu, 26 Sep 2013 16:51:43 +0200, Wan-Teh Chang  wrote:
>>
>>> On Thu, Sep 26, 2013 at 7:15 AM, Phillip Hallam-Baker  wrote:
>>>> My understanding of the 1024 bit Ephemeral DH key issue is that it is not
>>>> currently possible to use longer keys because a certain number of deployed
>>>> Web servers will abort the connection if a client presents a longer key.
>>>
>>> The size of ephemeral DH keys is specified by the server, and the
>>> client must present a key of that size. (This doesn't change the
>>> problem though.)
>>>
>>> The client needs a way to negotiate the ephemeral DH key size (or the
>>> DH domain parameters) with the server. This can be done by either an
>>> extension (similar to the elliptic_curves extension of RFC 4492 for
>>> ephemeral ECDH keys) or new cipher suites.
>>
>> In my opinion the length of the DHE key should have at least the same length (number of bits) as the signing RSA key. And similar for ECDHE, if necessary.
>
> Not for ECDHE_RSA, though. That would require that we define what ECDHE curve is equivalent to X-bit RSA.
>
> In general I don't like us doing the NIST magic tables of naming equivalent strength key lengths among different algorithms, as in 1024-bit RSA is similar to some non-existing 80-bit perfect symmetric algorithm, and a 1024-bit MODP group is sort of like that.
>
> Yoav
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

From mike-list@pobox.com  Fri Sep 27 08:22:11 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4813D21F91B7 for ; Fri, 27 Sep 2013 08:22:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.572
X-Spam-Level: 
X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6NdswImppuj for ; Fri, 27 Sep 2013 08:22:03 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 44E1821F9E33 for ; Fri, 27 Sep 2013 08:22:00 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 70206DA47; Fri, 27 Sep 2013 11:21:57 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=vs0yOxwZGz2q d7C5nWtSdELA2FA=; b=Ehci7Woxs9fR1sZsSeK/0Xpx4CYEiEpiGH0SKC8JzQgB I234M3l2gfgFbBxzsJUZsl2/5KARxclyC1jDgqibty95viz1qu9UrR/sdQoSkeZ/ Rv4qbzPQMawzOrEG9bri/9lC2RuEGrjpjalV5WSHVsxY35b0s4guK3KWQeti5SQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ryUzl/ ClHWQK+NSOPSwC01j4m4q9ljnrbqGzKCj9vlZxsyAaNFayJyVSMNCt4n2TPMdw0T tH1MFyg77DGL3IP6T3L5ZOTvbctiIoQFwmmEVE775RJpeTwIKdDvJgiICHgLtvqN oxuU2WCuf9MkG4lTGAKMZd6aWkFSrmeJFlEJU=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 66C08DA46; Fri, 27 Sep 2013 11:21:57 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 948F1DA45; Fri, 27 Sep 2013 11:21:56 -0400 (EDT)
Message-ID: <5245A292.1060909@pobox.com>
Date: Fri, 27 Sep 2013 08:21:54 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Yaron Sheffer 
References: 			<36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com>
In-Reply-To: <52459F3E.2050101@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 8BEE6E8C-2788-11E3-B021-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 15:22:12 -0000

Yaron Sheffer wrote:
> While we're opening (maybe) the negotiation of DHE, I'd like to clarify 
> an issue that bothers me in the implementation of DHE in TLS:
> 
> With DHE, the premaster secret depends only on the DH shared secret. We 
> know that DHE is commonly used with 1024-bit parameters. So even if you 
> have a 2048-bit RSA certificate, the session strength will be 1024 bits.
> 
> What if we mixed *both* the DH secret and the regular encrypted nonce 
> that's used in RSA ciphersuites into the premaster secret? Wouldn't we 
> get forward secrecy, as well as crypto strength equivalent to the higher 
> of the two lengths?

In DHE_RSA, RSA is used in signature mode to sign the DH parameters.
It is not recommended to use the same RSA key for both signing and
key encipherment.

Mike

From mrex@sap.com  Fri Sep 27 08:35:02 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B8F11E8166 for ; Fri, 27 Sep 2013 08:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.175
X-Spam-Level: 
X-Spam-Status: No, score=-10.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXw6E6GAx0af for ; Fri, 27 Sep 2013 08:34:46 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC4311E814F for ; Fri, 27 Sep 2013 08:34:42 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8RFYdJj002992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 27 Sep 2013 17:34:39 +0200 (MEST)
In-Reply-To: <5245A292.1060909@pobox.com>
To: "Michael D'Errico" 
Date: Fri, 27 Sep 2013 17:34:39 +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: <20130927153439.54C8A1A9B4@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 27 Sep 2013 15:35:02 -0000

Michael D'Errico wrote:
> Yaron Sheffer wrote:
> > While we're opening (maybe) the negotiation of DHE, I'd like to clarify 
> > an issue that bothers me in the implementation of DHE in TLS:
> > 
> > With DHE, the premaster secret depends only on the DH shared secret. We 
> > know that DHE is commonly used with 1024-bit parameters. So even if you 
> > have a 2048-bit RSA certificate, the session strength will be 1024 bits.
> > 
> > What if we mixed *both* the DH secret and the regular encrypted nonce 
> > that's used in RSA ciphersuites into the premaster secret? Wouldn't we 
> > get forward secrecy, as well as crypto strength equivalent to the higher 
> > of the two lengths?
> 
> In DHE_RSA, RSA is used in signature mode to sign the DH parameters.
> It is not recommended to use the same RSA key for both signing and
> key encipherment.

Isn't that (using the same RSA key for both signing and key encipherment)
what pretty much all TLS Servers do when they support both,
traditional RSA ciphersuites plus DHE_RSA and/or ECDHE_RSA?

-Martin

From dkg@fifthhorseman.net  Fri Sep 27 08:40:53 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E3111E8101 for ; Fri, 27 Sep 2013 08:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQkOKcu8c+5z for ; Fri, 27 Sep 2013 08:40:48 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB1011E80D5 for ; Fri, 27 Sep 2013 08:40:48 -0700 (PDT)
Received: from [192.168.13.175] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 755E1F983 for ; Fri, 27 Sep 2013 11:40:43 -0400 (EDT)
Message-ID: <5245A6FA.8080607@fifthhorseman.net>
Date: Fri, 27 Sep 2013 11:40:42 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: 			<36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com> <5245A292.1060909@pobox.com>
In-Reply-To: <5245A292.1060909@pobox.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2SJERQFROUUOGTEBFBTJD"
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 27 Sep 2013 15:40:53 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2SJERQFROUUOGTEBFBTJD
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/27/2013 11:21 AM, Michael D'Errico wrote:
> In DHE_RSA, RSA is used in signature mode to sign the DH parameters.
> It is not recommended to use the same RSA key for both signing and
> key encipherment.

I hear this recommendation a lot, and I think it makes sense, but i'm
wondering if there is a "canonical" reference for it.  It seems to be
violated far more often than it is honored.

There are many RSA X.509 certificates in use on the web today that
indicate both "key encipherment" and "digital signatures" in their
X.509v3 "key usage" extensions.

Just picking a random example (not trying to name-and-shame, since this
practice is so widespread), the 2048-bit RSA end-entity key used on port
443 of geotrust.com is marked in its certificate both key usages, and is
used regardless of whether you negotiate a DHE cipher suite or a non-PFS
suite.

Do we need to address this as well, perhaps by encouraging server
operators to use distinct keys/certificates depending on whether the
negotiated cipher suite is PFS or not?

	--dkg


------enig2SJERQFROUUOGTEBFBTJD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSRab6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcisgP/0YY2I8iqB0OXmjjDW3m+yKS
c8WL4UJM6YMwCWG0ZqOJCz6PGMwGvL1xR9Mojl1S0F8Z1OVxjI2CHTNRQCgnzw2K
yvK/IE91ax+OPLfUOAdzCPnOWX/v/4fr+8Z4a/ahFikGZS9eGwDWt8lhfPzejpLg
Ex5sUTUBOvYxxd+bxkkjSdUd5B3MVkUJxzbsSiTIHkmWJ5jVuo5rC8xgHY7jysng
ZnertmdEJfnYexoSfTOx2gXW75nS1RBoZNz+tWjtKj7mBELtOOFwsM4RE5442gq7
L6zqejNBiAuLBiiiyZiV9eRdmTDutPr0E4B2sJJKI8holCGcFiduH6kA7oCqQIPp
ifFh/ac93QXJSYSbiUnFBx/QVxltAO1RDZNgvb9LM73Coa+7fgXLYn7CxYb+KBNN
CZkJYxHTqQUjJLpVqdHLLYLNBirMS2chMc6G/9/zrRP59qUQB+N//kPYsPNxmsxy
XRntl1sDOW9KpmgWMmhzcGrHti08JMWMuxqBlPH+f4rFr02DpLtf3kZkpWcRkxU+
A991C9LuNCT5oIGMEdesltpLywwYqBexFGrjXPnmrTPr/OUQYUyUBrwOe4AQ3z+t
NiqnXrEDJVuaEeC9AVrVbcV9SZ3ugM+OEiZ97DCf8Di40sv+fMAWUEZq6/4n6ZV8
HIFZr37wTz3DZL0ZBInt
=SuGN
-----END PGP SIGNATURE-----

------enig2SJERQFROUUOGTEBFBTJD--

From mike-list@pobox.com  Fri Sep 27 09:05:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5910121F9D0E for ; Fri, 27 Sep 2013 09:05:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.574
X-Spam-Level: 
X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhRltl-WErLO for ; Fri, 27 Sep 2013 09:05:44 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id 8D36721F8A38 for ; Fri, 27 Sep 2013 09:05:44 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DC0CFDD26; Fri, 27 Sep 2013 12:05:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=5k49+22qL4DC 9o3z7MFqqztu2mo=; b=INzU0OS+LGCDc5/pY3UMuYIE2B7myi4YekCtdUWmONMj WQ0M+YafvTMW381Li4wHFe0JUI2Hoq9cIYkyzflqSCadzVJ8qk/8RBkcDM4kWbNM 1NHMkuefb8epllgMIy6tR8194DHKylk4s95cTfkL5xHfFh1Jyulz8qhfq8+Kh+U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=i9FCee JgQjPwMTVL8tieSsE2aAV4kzyBgkvG+2R9HcB9L/lU0igSWfPTyAFVdzn0jfzNb5 Nct/rKiG7kHA+HtbozenBujRKf3j8CW63zSuhjI26Xkbpzxk/TaIevaLJkYWzxhK Mdu1JoPXgM7IJ9iltOUBVUm/JQcEGHR9bhTCA=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id A3F11DD22; Fri, 27 Sep 2013 12:05:19 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 0D1C1DD12; Fri, 27 Sep 2013 12:04:57 -0400 (EDT)
Message-ID: <5245ACA8.3020504@pobox.com>
Date: Fri, 27 Sep 2013 09:04:56 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: mrex@sap.com
References: <20130927153439.54C8A1A9B4@ld9781.wdf.sap.corp>
In-Reply-To: <20130927153439.54C8A1A9B4@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 8E96F5EA-278E-11E3-95F6-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 16:05:49 -0000

Martin Rex wrote:
>> It is not recommended to use the same RSA key for both signing and
>> key encipherment.
> 
> Isn't that (using the same RSA key for both signing and key encipherment)
> what pretty much all TLS Servers do when they support both,
> traditional RSA ciphersuites plus DHE_RSA and/or ECDHE_RSA?

I believe that many servers do use the same key for both, though
they don't have to.  This practice is likely due to cost (buy one
certificate instead of two) and software limitations.

Mike

From mike-list@pobox.com  Fri Sep 27 09:18:58 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8B821F9A31 for ; Fri, 27 Sep 2013 09:18:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level: 
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rnu8TCXhkOfG for ; Fri, 27 Sep 2013 09:18:53 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id C880721F9633 for ; Fri, 27 Sep 2013 09:18:53 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 5371FDE01 for ; Fri, 27 Sep 2013 12:18:53 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=Bmfi6cfuCGPx SoGKlHHPg//i+n8=; b=T6CkI+NFq/ox/KzYJ9vylrGiWYjlDeqGYqIiNDLFpaTo asq0xI+xCVy4paF3+PaaXbkco/Zr1vxTJp6zaJkswlm0NIM4VzxqUupWg1co70Ha wHwFIEO7qbNBWP5MY10Z8lldwPNFH2ZBCvMKPyHdgRQQqPQMAb0x8rA6W21UpeQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=dOnlNH zz18RnQ8ltUCDPnIAQlNT+kgbUx+BByNj3sZmLWK9pIJQ2csjhIWtVwu3YcoQ4oy 0iw70t9IGu563K3fyXz4lOP9FI0nJ8ExCBjIm3xjSqq6HcyBLpI4LHoWgL0PVPZ7 5eX6NL29QK5aUbJxmnn0VKy/gdUNXsOptnRqQ=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 4BDFCDE00 for ; Fri, 27 Sep 2013 12:18:53 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id BA860DDFF for ; Fri, 27 Sep 2013 12:18:52 -0400 (EDT)
Message-ID: <5245AFEB.7040202@pobox.com>
Date: Fri, 27 Sep 2013 09:18:51 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: TLS Mailing List 
References: 			<36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>	<52459F3E.2050101@gmail.com> <5245A292.1060909@pobox.com> <5245A6FA.8080607@fifthhorseman.net>
In-Reply-To: <5245A6FA.8080607@fifthhorseman.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 8010AA78-2790-11E3-8274-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 16:18:58 -0000

Daniel Kahn Gillmor wrote:
>> It is not recommended to use the same RSA key for both signing and
>> key encipherment.
> 
> I hear this recommendation a lot, and I think it makes sense, but i'm
> wondering if there is a "canonical" reference for it.  It seems to be
> violated far more often than it is honored.

One contemporary reference is Cryptography Engineering, page 201.

The recommendation is if you want to reuse N for both operations, then
choose different public exponents such as e=3 for signing and e=5 for
encryption.  I'm pretty sure you can't do this using the same X.509
certificate.

Mike

From mike-list@pobox.com  Fri Sep 27 09:19:15 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7F21F9A57 for ; Fri, 27 Sep 2013 09:19:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level: 
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uC0qHATYCsP4 for ; Fri, 27 Sep 2013 09:19:10 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by ietfa.amsl.com (Postfix) with ESMTP id D891C21F9ADD for ; Fri, 27 Sep 2013 09:19:09 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E3770DE06; Fri, 27 Sep 2013 12:19:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=5k49+22qL4DC 9o3z7MFqqztu2mo=; b=vMlO9nUh/rhSwbogF+NljAsjFkinxsk2UTDYD6wC34Lt Mau567ZMEd/jJNvxtcG+L2W0wN/Wj7zBEGayVPbpnb7XMDA1wV6Qb2Jt3gzza1bm Y3kPU0oRgFt5dEIOrbITbkiBSNQgj+1uEtreAQEjbIacNF6i2wzVWa3GvE7/pZo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=WoNK1p UszxRZIL8TGSn1I0fx7fqe4JAzNXe/E6cjBXtfz6gmrIY3ECGC2RIrnSurE/0LxM xEv67DXgPub7NkawHCwl2c3/O9N5XpbOaVO6fldZjyOOIFDL0FQmB1wzCmGdOtl+ teo4NvtH0yu0j5aX5XUiRBlqUybjKAiJbrUNw=
Received: from a-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id DC0CFDE05; Fri, 27 Sep 2013 12:19:08 -0400 (EDT)
Received: from iMac.local (unknown [24.234.153.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id CF6D6DE03; Fri, 27 Sep 2013 12:19:03 -0400 (EDT)
Message-ID: <5245AFF7.5020903@pobox.com>
Date: Fri, 27 Sep 2013 09:19:03 -0700
From: Michael D'Errico 
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: mrex@sap.com
References: <20130927153439.54C8A1A9B4@ld9781.wdf.sap.corp>
In-Reply-To: <20130927153439.54C8A1A9B4@ld9781.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 86B7CBAE-2790-11E3-9801-CE710E5B5709-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 16:19:15 -0000

Martin Rex wrote:
>> It is not recommended to use the same RSA key for both signing and
>> key encipherment.
> 
> Isn't that (using the same RSA key for both signing and key encipherment)
> what pretty much all TLS Servers do when they support both,
> traditional RSA ciphersuites plus DHE_RSA and/or ECDHE_RSA?

I believe that many servers do use the same key for both, though
they don't have to.  This practice is likely due to cost (buy one
certificate instead of two) and software limitations.

Mike

From dkg@fifthhorseman.net  Fri Sep 27 09:42:04 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37EF21E8100 for ; Fri, 27 Sep 2013 09:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHwScZZNr+rL for ; Fri, 27 Sep 2013 09:41:58 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id BDB2621E809F for ; Fri, 27 Sep 2013 09:41:58 -0700 (PDT)
Received: from [192.168.13.175] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 1029FF983 for ; Fri, 27 Sep 2013 12:41:54 -0400 (EDT)
Message-ID: <5245B550.70606@fifthhorseman.net>
Date: Fri, 27 Sep 2013 12:41:52 -0400
From: Daniel Kahn Gillmor 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130821 Icedove/17.0.8
MIME-Version: 1.0
To: TLS Mailing List 
References: 			<36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>	<52459F3E.2050101@gmail.com> <5245A292.1060909@pobox.com> <5245A6FA.8080607@fifthhorseman.net> <5245AFEB.7040202@pobox.com>
In-Reply-To: <5245AFEB.7040202@pobox.com>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2XSIKWQMKIDTSIGRSKSQC"
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 27 Sep 2013 16:42:04 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
------enig2XSIKWQMKIDTSIGRSKSQC
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 09/27/2013 12:18 PM, Michael D'Errico wrote:
> The recommendation is if you want to reuse N for both operations, then
> choose different public exponents such as e=3D3 for signing and e=3D5 f=
or
> encryption.  I'm pretty sure you can't do this using the same X.509
> certificate.

Right, you can't do that with the same X.509 certificate because the
subjectPublicKeyInfo (SPKI) data for RSA keys includes both N and E, and
is covered by the certificate's signature.

So: is this common practice something we should be pushing back on (e.g.
encouraging implementors to provide mechanisms to use separate keys and
certs for the PFS suites, and administrators to adopt those mechanisms)?

	--dkg


------enig2XSIKWQMKIDTSIGRSKSQC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQJ8BAEBCgBmBQJSRbVQXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB
NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcqVAP/3bsInZ1DggnZyFW2fmi6PwO
d+rU6RaEncKvUQxMkVpd09Nid1Th5cHTduK3UITat5BHIfqA9zIE5kuh4Js4ZDOT
ktNR2KLshJsX+xSLVjzbV1elp9iNxbjkk6ExQfOG6PIh3A6Ycpflb6vPMwtzNLtU
3A8uQInlX0H4jZcKabqN59+4tH7QddYFJR/eM2pwSqJCxJIyBEmPRqPreH/TkEMf
c6GuRVsy4GgJ0u02GLme/Xf0y9QsBI2aIX7SbPZiwTrHjrKtNcWjQivTimWt4tBm
AdF33iXmP4s2exOyIe/2cfHGgaK3oVqu719SnMBvPlJ8vNpluDDKrfZPsh8M2S5r
Eqkn70KvFAw3X3ylLbDjla25B0OCyWgs1gkEHWaxOtJhEvBRr8tIy2UQBE6DVmYq
BdFSzq75dMijANy6BwI1yXN6QJUBFqfFMt2i8ovD6RoGb9hVlKHTKVCpjFClaq4X
J/1cvVU4cZ66OvIU5yrYt69QxBYLdv5C9sQo8K3HReXapjh7A67a/QKmaxOygZet
RpkUSxRN4InFuincBfqNNZc8fHKEFyTGDpATGN0BUHVzMYZyYkG5+XFBBtgGqKQg
6ZRI6HK4pfOc6TbT3JCbUaZVig8X8jTa4Jdt8vY+fLyA4olLpo2v/rcOo/jIlkPi
9vt5a9Xscg8lEQKa1tVL
=SFYb
-----END PGP SIGNATURE-----

------enig2XSIKWQMKIDTSIGRSKSQC--

From hanno@hboeck.de  Fri Sep 27 09:55:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866C21F9F45 for ; Fri, 27 Sep 2013 09:55:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPZwWcUMsroq for ; Fri, 27 Sep 2013 09:55:44 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 7017721F9D2A for ; Fri, 27 Sep 2013 09:55:43 -0700 (PDT)
Received: from localhost (91-66-72-107-dynip.superkabel.de [::ffff:91.66.72.107]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Sep 2013 18:55:40 +0200 id 00000000000000B1.000000005245B88C.00006FA9
Date: Fri, 27 Sep 2013 18:55:35 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20130927185535.5b971c1d@hboeck.de>
In-Reply-To: <52459F3E.2050101@gmail.com>
References:    <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com>
X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-28585-1380300940-0001-2"
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 16:55:49 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-28585-1380300940-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 27 Sep 2013 18:07:42 +0300
Yaron Sheffer  wrote:

> While we're opening (maybe) the negotiation of DHE, I'd like to
> clarify an issue that bothers me in the implementation of DHE in TLS:
>=20
> With DHE, the premaster secret depends only on the DH shared secret.
> We know that DHE is commonly used with 1024-bit parameters. So even
> if you have a 2048-bit RSA certificate, the session strength will be
> 1024 bits.
>=20
> What if we mixed *both* the DH secret and the regular encrypted nonce=20
> that's used in RSA ciphersuites into the premaster secret? Wouldn't
> we get forward secrecy, as well as crypto strength equivalent to the
> higher of the two lengths?

I feel this would add even more confusion.

What you'd get:
- Connection Security of the RSA key size, BUT
- Forward Secrecy only with the security of the DHE modulus size

Or to be concrete: an attacker able to steal the certificate's key
AFTER recording a connection and at the same time being able to break
the DHE would still be able to decrypt.

I don't really get why that should make any sense. Okay, it would avoid
that DHE "downgrades" the security of the RSA key.
But: This would require changes to the protocol. Won't work with
existing software, so it won't solve the mess we have today.

If you are already changing the protocol, you can also do something
that makes much more sense: Forbid DHE modulus size smaller than RSA
key size. (which also could be achieved just by server policy without
protocol changes, but then breaks messy clients like java - see past
discussion)

--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-28585-1380300940-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQIcBAEBCAAGBQJSRbiKAAoJEKWIAHK7tR5Cq4kP/2Ms1wI04p8n0eVx/najID85
jM1LcjzJBH9q0jFWFHp1AvpzIWdWZg7pQ+P67RQRT50FiM4B8EIl7NTGu1eqMr+7
5ogUaGG3adp6oYv5+lb+WL6B80IbO40wh0SxBQnTIhBytAyL1lHs2mgfnQE1UWCV
zauVnUgwgMmBBD0jU4Ay86MaoGJlatG3S6tRkKfuJuYDAww6n5BFTU/DsMMWimH8
OtJtJhGVqYCcWRl74rc7vn+IXb/wh/FttKADGChRHvWsyrfUB9g6lYbpbFdfJ21e
Sg9y6CWqF89djV8sO/+UBgL/G82hv9t2Qgw/pqb4Wm0vLdvpPCMqz7m6Owrj28vo
WfsV7+Uqb1rRTDB0AhxiJqTrVOfWZIOpUsiYissRn975UxpVvJTKR0oVK8pI6rZ9
32gha1vXRXEf1Ah//zWueQHv6n/wc8jhpImUMfRbwoMNX4D44o/QYPjHkl/peozS
x3GY82MVsoWpaxatbtFs2C0G+T29QwdHz6Y3TNEIUFulH2lk5BIC+a7JRVoc9V/n
mlhC+C/HnAZiPi94UPynrJYFaQujjNyo5gG4wUAxGqFzrTHoEpEemqCJ7UYetpId
QmqsIZxjuzGvGPHm9OL9KgvZrubQT9nAMzjE9WWEl1XGwpuNgxB4OF2zLFsHKKrz
N9Cd2+5sqdzvFIwc5pjF
=JU8Z
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-28585-1380300940-0001-2--

From hanno@hboeck.de  Fri Sep 27 09:59:49 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C894D21F93F3 for ; Fri, 27 Sep 2013 09:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level: 
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wfQPc8UpPtl for ; Fri, 27 Sep 2013 09:59:43 -0700 (PDT)
Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) by ietfa.amsl.com (Postfix) with ESMTP id 07F0511E814D for ; Fri, 27 Sep 2013 09:59:37 -0700 (PDT)
Received: from localhost (91-66-72-107-dynip.superkabel.de [::ffff:91.66.72.107]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Fri, 27 Sep 2013 18:59:36 +0200 id 00000000000000AA.000000005245B978.00007310
Date: Fri, 27 Sep 2013 18:59:31 +0200
From: Hanno =?UTF-8?B?QsO2Y2s=?= 
To: tls@ietf.org
Message-ID: <20130927185931.65d84034@hboeck.de>
In-Reply-To: <5245B550.70606@fifthhorseman.net>
References:    <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com> <5245A292.1060909@pobox.com> <5245A6FA.8080607@fifthhorseman.net> <5245AFEB.7040202@pobox.com> <5245B550.70606@fifthhorseman.net>
X-Mailer: Claws Mail 3.9.2-dirty (GTK+ 2.24.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA256; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-29456-1380301176-0001-2"
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 16:59:49 -0000

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_zucker.schokokeks.org-29456-1380301176-0001-2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, 27 Sep 2013 12:41:52 -0400
Daniel Kahn Gillmor  wrote:

> Right, you can't do that with the same X.509 certificate because the
> subjectPublicKeyInfo (SPKI) data for RSA keys includes both N and E,
> and is covered by the certificate's signature.
>=20
> So: is this common practice something we should be pushing back on
> (e.g. encouraging implementors to provide mechanisms to use separate
> keys and certs for the PFS suites, and administrators to adopt those
> mechanisms)?

PFS should be default and non-PFS should be phased out. Problem solved.

(Another reference for this principle "one key one usage" is by the way
an old paper by Schneier with the title "Chosen Protocol attack":
https://www.schneier.com/paper-chosen-protocol.html
)

--=20
Hanno B=C3=B6ck
http://hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: BBB51E42

--=_zucker.schokokeks.org-29456-1380301176-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)

iQIcBAEBCAAGBQJSRbl2AAoJEKWIAHK7tR5C8F4QAKlfjW43v02jqIMtE86t0UfM
XuB/r0ZX9TVhCDMkjeseE+54dtyO8O/OcV7OMEaM9LnKFm5gUW7yM6RCosj/Y1cF
f4bv4H+dO83UfH9fRvJ4ksH2oDNQb0j7SX3rzzMkOAmqSFpEQNxgPP/4N3b0Egg+
Sw9L7r73Nj2C9+8NkifyUn2c4Of9OH2vGsk+PKIZH/gN4ZvUascZPXFI1LEb9ryw
c288PMENL5OLb8ZSGzvcZPcneX3aeMOd2gKymCpPWv+2ew7o7aAeX2SHu5lrudyD
NM94+QsDwNuF+lVIS3w+eFu3IGXpReA8GuYqNbvShw4UgRmh21q+y2T5m1lqrStB
zs3/O7dOYQ77m3EnGgZeDsLcB2j7IVsJhhhocOZH/zdfC4V0YHNuWhD2BwbvrA4b
DtL92Z2+duCdYhW3gcdCtb7wixi8ThgcWTJmkPCUAbDe0gqaeYC0pdRcJIvQsGUI
oCTu9Gn8R+yHkIFnI+kRyRWbHSHPe+WTx/tPPa+gcw6cuOvUP0Jco3FqmuugCgkW
HnXp76qrzSMFoXiFey7tf605yvYOcVRkrYVIwJVNx0sIsTsvowqsZUDn9GBuWPdL
IU3v4+xi7Olr4Z2iKKm6bZPLMlBpEAYhsRyEQiriTBb0riKq8cGWTjRfDVeM8zOe
AcCWXvndNRj5VHWmwxX+
=P8go
-----END PGP SIGNATURE-----

--=_zucker.schokokeks.org-29456-1380301176-0001-2--

From yaronf.ietf@gmail.com  Fri Sep 27 14:00:19 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40E721F9E54 for ; Fri, 27 Sep 2013 14:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.362
X-Spam-Level: 
X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6w1b4KyYBB1C for ; Fri, 27 Sep 2013 14:00:19 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7132621E8095 for ; Fri, 27 Sep 2013 14:00:17 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id cb5so1388420wib.5 for ; Fri, 27 Sep 2013 14:00:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=FSv14RQfZTtv7NyKdTElhu1jN4b6pYK34bQBD+NTZ7c=; b=sjCIGWW7nCmmANoXBjGMoVNy6q31tA6/d3u1MWXwWGJabvw0Tw4gAi3aABHkFa+bKo VLwwNuTWt6UEIj4pDmN6y4xzoJ7VqPtB//rRiftQJDx4hS8Tu2le1rg5wJmdNNftYQnP 4H2qdNgUmK2f8hD82zm4Kgupe4pt8cpE33gWyPOr9tse8ENp8pNjKvHKGA2ulMXEPgpS V/yzYvpBu2+5ppo4rmgxisJU1+DOs61kOhDUELTrdPVsTnz4UEndyjn0lDXhzcLrpo82 g37i/ihCilurFIC3gW8GXtYJ248jtegH3cuH4ncXSkXvWkQSn3vEQ9PBVFfd8YhtfYQN Hb7A==
X-Received: by 10.194.158.67 with SMTP id ws3mr7405944wjb.5.1380315616559; Fri, 27 Sep 2013 14:00:16 -0700 (PDT)
Received: from [10.0.0.8] ([109.64.175.213]) by mx.google.com with ESMTPSA id dq11sm42118314wid.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 27 Sep 2013 14:00:15 -0700 (PDT)
Message-ID: <5245F1DE.10903@gmail.com>
Date: Sat, 28 Sep 2013 00:00:14 +0300
From: Yaron Sheffer 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: =?ISO-8859-1?Q?Hanno_B=F6ck?= , tls@ietf.org
References: 			<36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>	<52459F3E.2050101@gmail.com> <20130927185535.5b971c1d@hboeck.de>
In-Reply-To: <20130927185535.5b971c1d@hboeck.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 21:00:20 -0000

On 09/27/2013 07:55 PM, Hanno Böck wrote:
> On Fri, 27 Sep 2013 18:07:42 +0300
> Yaron Sheffer  wrote:
>
>> While we're opening (maybe) the negotiation of DHE, I'd like to
>> clarify an issue that bothers me in the implementation of DHE in TLS:
>>
>> With DHE, the premaster secret depends only on the DH shared secret.
>> We know that DHE is commonly used with 1024-bit parameters. So even
>> if you have a 2048-bit RSA certificate, the session strength will be
>> 1024 bits.
>>
>> What if we mixed *both* the DH secret and the regular encrypted nonce
>> that's used in RSA ciphersuites into the premaster secret? Wouldn't
>> we get forward secrecy, as well as crypto strength equivalent to the
>> higher of the two lengths?
>
> I feel this would add even more confusion.
>
> What you'd get:
> - Connection Security of the RSA key size, BUT
> - Forward Secrecy only with the security of the DHE modulus size
>
> Or to be concrete: an attacker able to steal the certificate's key
> AFTER recording a connection and at the same time being able to break
> the DHE would still be able to decrypt.
>
> I don't really get why that should make any sense. Okay, it would avoid
> that DHE "downgrades" the security of the RSA key.
> But: This would require changes to the protocol. Won't work with
> existing software, so it won't solve the mess we have today.
>
> If you are already changing the protocol, you can also do something
> that makes much more sense: Forbid DHE modulus size smaller than RSA
> key size. (which also could be achieved just by server policy without
> protocol changes, but then breaks messy clients like java - see past
> discussion)
>
Hi Hanno,

Just a few weeks ago we as a community thought the server's private key 
was generally secure. Now the entire community seems to assume the 
private key is easy to steal. Practically, most private keys will 
probably not be stolen. OTOH the NSA (and also much smaller 
organizations) will have a pile of DH-1024 encrypted traffic for years 
to come just waiting for compute power to enable decryption en masse.

I'm sure you're not seriously suggesting that if I have a 3072-bit RSA 
cert, but my crypto library can only do 2048-bit DH, then I should never 
do DHE, and instead fall back to simple RSA, are you? Looking forward, 
there will always be mismatches and we should prefer the best possible 
TLS "mix", rather than enforce an idealistic policy.

Thanks,
	Yaron

From ynir@checkpoint.com  Fri Sep 27 14:25:03 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D6311E80DE for ; Fri, 27 Sep 2013 14:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.378
X-Spam-Level: 
X-Spam-Status: No, score=-10.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K86sIwKLCH8c for ; Fri, 27 Sep 2013 14:24:56 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id D3FCC21E8053 for ; Fri, 27 Sep 2013 14:24:51 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r8RLOjE8014286; Sat, 28 Sep 2013 00:24:45 +0300
X-CheckPoint: {5245F79D-0-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Sat, 28 Sep 2013 00:24:45 +0300
From: Yoav Nir 
To: Yaron Sheffer 
Thread-Topic: [TLS] DHE key derivation
Thread-Index: AQHOu5NbQv44CSd39EaD4bVemn9dSJnZm1OAgABEWwCAAAbYAA==
Date: Fri, 27 Sep 2013 21:24:44 +0000
Message-ID: <66004AFF-3120-4887-9591-094404792ED6@checkpoint.com>
References:    <36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com> <52459F3E.2050101@gmail.com> <20130927185535.5b971c1d@hboeck.de> <5245F1DE.10903@gmail.com>
In-Reply-To: <5245F1DE.10903@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.24.227]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" 
Subject: Re: [TLS] DHE key derivation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 27 Sep 2013 21:25:03 -0000

On Sep 28, 2013, at 12:00 AM, Yaron Sheffer  wrote:
>=20
> Hi Hanno,
>=20
> Just a few weeks ago we as a community thought the server's private key w=
as generally secure.

Did we? Private keys are just files on a web server. Sometimes they leak ([=
1])

> Now the entire community seems to assume the private key is easy to steal=
.

Easy or hard depends on the practices of the web server administrators. I p=
ersonally (and maybe others feel the same) think it's easier than factoring=
 a 2048-bit number (or even factoring a 1024-bit number, or calculating a d=
iscrete logarithm in a 1024-bit MODP group). I understand it's problematic =
comparing unlike things, like what's easier: peace in the middle east or a =
manned flight to Mars? But when assessing risks to your website, you do hav=
e to figure out where to invest your resources.

> Practically, most private keys will probably not be stolen. OTOH the NSA =
(and also much smaller organizations) will have a pile of DH-1024 encrypted=
 traffic for years to come just waiting for compute power to enable decrypt=
ion en masse.

The longer they wait, the less valuable decrypting them becomes. And storin=
g that pile costs them. Also, what do you mean by "en masse". If the entire=
 traffic on the Internet was encrypted with DES (broken by civilians over 1=
8 years ago), could the NSA afford to decrypt it all today?

> I'm sure you're not seriously suggesting that if I have a 3072-bit RSA ce=
rt, but my crypto library can only do 2048-bit DH, then I should never do D=
HE, and instead fall back to simple RSA, are you? Looking forward, there wi=
ll always be mismatches and we should prefer the best possible TLS "mix", r=
ather than enforce an idealistic policy.

That I agree with, but rather than optimizing mixes, I prefer to think of i=
t as a minimum level for each primitive, and mandating at least that. An RS=
A ciphersuite has zero bits for PFS. Obviously, 1024-bit DH is better than =
zero bits (80 bits according to NIST estimates). If for various legal, comm=
ercial and BC reasons we can't mandate the 112 bits of 2048-bit DH or the 1=
28 bits of ECDHE with the P-256 or equivalent brainpool curve or some other=
 curve, then we should set the minimum level for now at 1024-bit DHE.

Yoav

[1] http://www.net-security.org/secworld.php?id=3D11144=

From 57756671618275-ietf-tls@sublist.cr.yp.to  Sat Sep 28 15:37:12 2013
Return-Path: <57756671618275-ietf-tls@sublist.cr.yp.to>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD3D21F9BD8 for ; Sat, 28 Sep 2013 15:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.17
X-Spam-Level: 
X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_50=0.001, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtAM2xh59KBG for ; Sat, 28 Sep 2013 15:37:08 -0700 (PDT)
Received: from mace.cs.uic.edu (mace.cs.uic.edu [131.193.32.224]) by ietfa.amsl.com (Postfix) with SMTP id 7A0AE11E8107 for ; Sat, 28 Sep 2013 15:37:06 -0700 (PDT)
Received: (qmail 31746 invoked by uid 1011); 28 Sep 2013 22:37:04 -0000
Received: from unknown (unknown) by unknown with QMTP; 28 Sep 2013 22:37:04 -0000
Received: (qmail 1115 invoked by uid 1001); 28 Sep 2013 22:36:48 -0000
Date: 28 Sep 2013 22:36:48 -0000
Message-ID: <20130928223648.1113.qmail@cr.yp.to>
From: "D. J. Bernstein" 
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net>
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 28 Sep 2013 22:37:12 -0000

Dan Brown writes:
> Five NIST curves are Koblitz curves, which do not have seeds at all.

Agreed. There's nothing unexplained in, e.g., the K-233 curve. However,
as I wrote in the Curve25519 paper in 2005, prime fields have "the
virtue of minimizing the number of security concerns for elliptic-curve
cryptography; see, e.g., [1998 Frey] and [2003 Diem]."

Maybe Frey's Weil-descent attack strategy has reached its limits, but
maybe not; see, e.g., http://eprint.iacr.org/2012/146. The performance
benefits of Koblitz curves aren't big enough to justify having to worry
about further developments in this area. It's best to use prime fields,
eliminating this entire class of attacks.

> I must have forgotten that aspect of the Brainpool standard.  If
> possible, please remind me of the issue, if only by link to the relevant
> document (and section thereof).

This is the second bullet item in the list of "major issues" stated at
the beginning of "ECC Brainpool Standard Curves and Curve Generation v.
1.0".

> a consistent treatment of ECC must mildly reduce, or at least revise,
> the claimed security of any EC curve if the treatment also posits that NIST
> curves have an undisclosed strong weakness.

No.

Suppose NSA knows---and knew in the late 1990s---a cost-2^64 attack that
breaks one P1363-compliant 256-bit curve in a billion. This wouldn't be
out of line with the spectrum of known ECC attacks, such as

   * the Pohlig--Hellman attack breaking most curve orders (this is why
     P1363 requires a large prime to divide the order),
   * twist attacks breaking most of the remaining curve orders in many
     protocols,
   * Weil descent breaking many curves for some field sizes,
   * the MOV attack on curves of order p-1 and p+1 and so on, and
   * an attack on curves of order p.

Suppose that NSA can recognize immediately from the group order whether
the attack will be successful---again a reasonable assumption. NSA could
then

   * have generated many billions of seeds until finding a
     P1363-compliant curve vulnerable to this attack (a feasible
     computation for NSA in the 1990s),

   * have standardized that curve as NIST P-256 (we already know that
     NIST took its curves from NSA), falsely claiming the curve to be
     "verifiably random", and

   * be applying the cost-2^64 attack to NIST P-256 users today.

You claim that such an attack would be a threat to "any EC curve". But
this claim is obviously not correct for curves that really are randomly
generated (and you have zero justification for making the same claim for
any particular curve). The correct comparison, under exactly the same
hypotheses, is simple:

   * Honest curve: NSA has _a one-in-a-billion chance_ that we obtained
     a weak curve, in which case NSA finds our keys with cost 2^64.

   * NIST curve: NSA is _guaranteed_ that we're using a weak curve, so
     NSA finds our keys with cost 2^64.

These are obviously not the same situation. The attack costs are the
same, but the success probabilities are on totally different scales.

I don't think there's a high risk of being in this situation---there
have been many years of intensive cryptanalysis of ECC, and for prime
fields the security story seems to have converged. But there's also no
reason for ECC users to expose themselves to risks that are so trivial
to avoid. There are also much larger risks that definitely bite people
(see http://cr.yp.to/talks/2013.05.31/slides-dan+tanja-20130531-4x3.pdf)
and that one can avoid by moving away from the NIST curves.

> I have argued on this list that
> Curve25519 is special in its use of small coefficients.

Well, yes, you've declared that y^2=x^3+486662x^2+x mod 2^255-19 is
"special", but you haven't actually given an argument for this---for
example, an attack strategy in which the size of the 486662 plays a
role. Index calculus sees sizes, but the whole point of ECC is to stop
index calculus. You could equally well declare that NIST P-256 is
"special" since its prime can be written as a low-degree polynomial in a
power of 2 with coefficients {-1,0,1}, or declare that brainpoolP256r1
is "special" since it contains the scary string BCCDC.

> Does Curve25519 ignore Cheon-type "attacks" (which are rather weak)?

Key derivation stops such attacks, and is easy to do securely, as
discussed in the Curve25519 paper. As far as I know, all Curve25519
deployment is using appropriate key derivation.

---D. J. Bernstein
   Research Professor, Computer Science, University of Illinois at Chicago

From dbrown@certicom.com  Sat Sep 28 19:57:31 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C180B21F9FF2 for ; Sat, 28 Sep 2013 19:57:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level: 
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, OBSCURED_EMAIL=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfctQ83E-adI for ; Sat, 28 Sep 2013 19:57:26 -0700 (PDT)
Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) by ietfa.amsl.com (Postfix) with ESMTP id 35D3721E80AC for ; Sat, 28 Sep 2013 19:57:24 -0700 (PDT)
Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs214cnc.rim.net with ESMTP/TLS/AES128-SHA; 28 Sep 2013 22:57:17 -0400
Received: from XCT116CNC.rim.net (10.65.161.216) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 28 Sep 2013 22:57:17 -0400
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT116CNC.rim.net ([::1]) with mapi id 14.03.0123.003; Sat, 28 Sep 2013 22:57:16 -0400
From: Dan Brown 
To: "D. J. Bernstein" , "tls@ietf.org" 
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: Ac68v5o8xn3XJXmgAkKRAg2ZE6kwfw==
Date: Sun, 29 Sep 2013 02:57:15 +0000
Message-ID: <20130929025714.5578895.47771.4422@certicom.com>
Accept-Language: en-CA, en-US
Content-Language: en-CA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Content-Type: text/plain; charset="utf-8"
Content-ID: 
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Sep 2013 02:57:32 -0000

RGVhciBQcm9mZXNzb3IgQmVybnN0ZWluLA0KDQpUaGFua3MgZm9yIHlvdXIgaGVscGZ1bCByZXNw
b25zZS4NCg0KSSB0b28gZmVlbCBDdXJ2ZTI1NTE5IGlzIHNhZmUsIGFuZCBpbiBtYW55IGFzcGVj
dHMgbW9yZSBzZWN1cmUgdGhhbiBhbHRlcm5hdGl2ZXMuIEkganVzdCB3YW50IHF1YW50aWZpZWQg
Y2xhaW1zIG9mIGFkdmFudGFnZXMsIHdpdGggZm9ybWFsIGFyZ3VtZW50cywgYW5kIGJhbGFuY2Vk
IHRyZWF0bWVudCBvZiBhbnkgYXNwZWN0cyBpbiB3aGljaCBpdCBtYXkgbm90IGJlIG1vcmUgc2Vj
dXJlLiBZb3VyIGZpbmRpbmcgdGhpcyBjdXJ2ZSBpcyBpbmdlbml1cyBhbmQgY29tbWVuZGFibGUu
DQoNCkFmdGVyIEkgc2VudCBteSBlbWFpbCwgSSBub3RpY2VkIEkgd3JvdGUgYWJvdXQgYSBoeXBv
dGhldGljYWwgInN0cm9uZyB3ZWFrbmVzcyIuIEkgc2hvdWxkIGhhdmUg4oCOd3JpdHRlbiAic2V2
ZXJlIHdlYWtuZXNzIi4gTWF5YmUgZm9yIHRoaXMsIG9yIG90aGVyd2lzZSwgSSB3YXMgdW5jbGVh
cjogdG8gY2xhcmlmeSBteXNlbGYgUDI1NiBhbmQgQ3VydmUyNTUxOSBhcmUgbm90IGF0IGFsbCBp
biB0aGUgInNhbWUgc2l0dWF0aW9uIi4gSWYgd2UgY29uc2lkZXIgYWR2ZXJzYXJpZXMgY2hvb3Np
bmcgY3VydmVzLCB0aGVuIEN1cnZlMjU1MTkgZmFyZXMgd2F5IGJldHRlciB0aGFuIFAyNTYgKHVu
bGVzcyB5b3UgYXJlIGh5cGVyZ2VuaXVzKS4NCg0KQWxzbywgSSB0aGluayB0aGVzZSBoeXBvdGhl
c2VzIG1lcml0IGF0dGVudGlvbiwgYnV0IHNob3VsZCBiZSB0cmVhdGVkIG51bWVyaWNhbGx5LCBq
dXN0IGxpa2UgYW55IG90aGVyIGNyeXB0by4NCg0KDQoNCuKAjkFueXdheS4uLiBJIHdpbGwgcGFy
YXBocmFzZSB5b3VyIHN1cHBvc2l0aW9uIGJlbG93Og0KDQpEZW5zaXR5IHEgPSAyXigtMzApIGNs
YXNzIG9mIHdlYWsgY3VydmVzLg0KDQpXaGVyZSB3ZWFrIG1lYW4gbG9ncyBzb2x2YWJsZSBhdCBj
b3N0IDJeNjQuDQoNClByb2JhYmlsaXR5IDJeKC1iKSB0aGF0IHRoYXQgYW4gYWR2ZXJzYXJ5IGZv
dW5kIHRoZSB3ZWFrbmVzcy4gVmFyaWFibGUgYiBpcyB1bmtub3duLCB3aGljaCB3ZSBtdXN0IGlu
ZmVyLiBXZSBjb3VsZCBnZW5lcmFsaXplIGl0LCBhcyBpbiBiKDMwLDY0KS4NCg0KWW91IHJlc3Bv
bmRlZCAibm8iIHRvIG15IHBvc2l0aW9uIHRoYXQgd2UgbXVzdCBtaWxkbHkgcmV2aXNlIG91ciBj
bGFpbXMgZm9yIGFueSBFQyBjdXJ2ZS4NCg0KU28sIEkgY29uY2x1ZGUgdGhhdCB0aGUgcmVjZW50
IG5ld3MgZG9lcyBub3Qgc3VnZ2VzdCB0byB5b3UgcmV2aXNpbmcgeW91ciBlc3RpbWF0ZSBvZiBi
LiBBbHNvLCB5b3UgZXN0aW1hdGUgYiBpcyBoaWdoIChidXQgSSBkb24ndCBrbm93IGhvdyBoaWdo
KSwgYmVjYXVzZSB5b3Ugc2F5IHRoZSByaXNrIGlzIGxvdy4NCkluZmVycmluZyBiIGlzIGRpZmZp
Y3VsdCwgYmVjYXVzZSBvZiB0aGUgbGFjayBvZiBldmlkZW5jZSBhbmQgdGhlIG1hbnkgZmFjdG9y
cy4NCg0KTXkgaW50ZXJwcmV0YXRpb24gb2YgbW9zdCBFQ0MgY2xhaW1zIGlzIHRoYXQgd2UgaGF2
ZSBpbmZlcnJlZCBiIHRvIHNvIGxhcmdl4oCOIHRoYXQgdGhlIHByb2JhYmlsaXR5IDJeLSg2NCti
KSB5aWVsZGVkIG5vdGhpbmcgbW9yZSBlZmZlY3RpdmUgdGhhbiBzdGFuZGFyZCBnZW5lcmljIGdy
b3VwIHRyYWRlb2ZmcyBiZXR3ZWVuIGNvc3QgYW5kIHN1Y2Nlc3MgcmF0ZS4gVGhlIGJhc2lzIGZv
ciB0aGlzIGluZmVyZW5jZSB3YXMgdGhlIGxhY2sgb2YgcHVibGlzaGVkIHByb2dyZXNzIG9uIEVD
RExQLCBmb3IgYWxsIGJ1dCBhIG5lZ2xpZ2libGUgZGVuc2l0eSBvZiBjdXJ2ZXMuIE1heWJlIHRo
aXMgd2FzIHVuanVzdGlmaWVkLCBidXQgSSBmZWVsIHRoYXQgd2FzIHRoZSBjbGFpbS4gQXMgYSBy
ZXN1bHQgdGhpcyByaXNrIHdhcyBhYnNvcmJlZCBieSB0aGUgcmlza3MgZHVlIHRvIHB1Ymxpc2hl
ZCBhbGdvcml0aG1zLg0KDQpTb3JyeSBmb3Igc2F5aW5nICJ0aHJlYXQgdG8gYW55IEVDIGN1cnZl
Ii4gSSBob3BlIHRoYXQgSSd2ZSBjbGFyaWZpZWQgd2hhdCBJIG1lYW50IGJ5ICJtaWxkbHkgcmVk
dWNl4oCOIiBub3cuDQoNCg0KDQoNCkkgZG9uJ3Qga25vdyBpZiB5b3UgY2xhaW0oZWQpIHNvbWV0
aGluZyBkaWZmZXJlbnQgLi4u4oCODQoNCg0KDQpTb3JyeSwgYnkgInNwZWNpYWwiLCBJIGp1c3Qg
bWVhbnQgbm90IHBzZXVkb3JhbmRvbS4gWWVzLCBQMjU2IGhhcyBhIHNwZWNpYWwgZmllbGQuIEkg
dGhpbmsgYnJhaW5wb29sIGN1cnZlcyBkb24ndCBoYXZlIHNwZWNpYWwgZmllbGRzLCB3aGljaCBt
YXkgaGF2ZSBzb21lIG1lcml0LiAgWW91IGFyZSByaWdodCB0aGF0IEkgaGF2ZSBub3QgZ2l2ZW4g
YW4gYXJndW1lbnQgd2h5IHNwZWNpYWwgbWlnaHQgYmUgd2Vhay4gWW91ciBjb3VudGVyIGFyZ3Vt
ZW50cyBpcyBnb29kLCB0b28sIGZvciB0aGUgY2FzZSBvZiBDdXJ2ZTI1NTE5Lg0KDQpXaGF0IEkg
bWVhbnQuLi4gWW91IG5vdGVkIHRoYXQgY3VydmUgc2l6ZXMgcCxwLTEsIGFuZCBwKzEgYXJlIHdl
YWsuIFRoZXNlIG1pZ2h0IGJlIGNhbGxlZCBzcGVjaWFsIGN1cnZlIHNpemVzLCBzaW5jZSBmb3Ig
YSByYW5kb20gY3VydmUsIG9mIG9yZGVyIHArZCwgd2UgZXhwZWN0IHxkfCBhcm91bmQgcF4oMS8y
KSwgYW5kIGZvciB0aGVzZSBkIGlzIG11Y2ggc21hbGxlci4gIE9mIGNvdXJzZSwgaXQncyBhIGxv
Z2ljYWwgbGVhcCB0byBqdW1wIGZyb20gc21hbGwgZCB0byBzbWFsbCBjdXJ2ZSBjb2VmZmljaWVu
dHMsIGJ1dCBpZiB3ZSBhcmUgZ29pbmcgdG8gYmUgcHJ1ZGVudCwgdGhlbiB3aHkgbm90IGF2b2lk
IHNtYWxsIGNvZWZmaWNpZW50cyB0b28/ICBNb3JlIHByZWNpc2VseSwgbGV0J3Mgc3RpY2sgdG8g
dmVyaWZpYWJseSByYW5kb20gY3VydmVzLCBhcyBhIG1hdHRlciBvZiBwcnVkZW5jZS4NCg0KDQoN
Cg0KDQoNCg0KU2VudCBmcm9tIG15IEJsYWNrQmVycnkgMTAgc21hcnRwaG9uZSBvbiB0aGUgUm9n
ZXJzIG5ldHdvcmsuDQpGcm9tOiBELiBKLiBCZXJuc3RlaW4NClNlbnQ6IFNhdHVyZGF5LCBTZXB0
ZW1iZXIgMjgsIDIwMTMgNjozNyBQTQ0KVG86IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtU
TFNdIFNhZmUgRUNDIHVzYWdlDQoNCg0KRGFuIEJyb3duIHdyaXRlczoNCj4gRml2ZSBOSVNUIGN1
cnZlcyBhcmUgS29ibGl0eiBjdXJ2ZXMsIHdoaWNoIGRvIG5vdCBoYXZlIHNlZWRzIGF0IGFsbC4N
Cg0KQWdyZWVkLiBUaGVyZSdzIG5vdGhpbmcgdW5leHBsYWluZWQgaW4sIGUuZy4sIHRoZSBLLTIz
MyBjdXJ2ZS4gSG93ZXZlciwNCmFzIEkgd3JvdGUgaW4gdGhlIEN1cnZlMjU1MTkgcGFwZXIgaW4g
MjAwNSwgcHJpbWUgZmllbGRzIGhhdmUgInRoZQ0KdmlydHVlIG9mIG1pbmltaXppbmcgdGhlIG51
bWJlciBvZiBzZWN1cml0eSBjb25jZXJucyBmb3IgZWxsaXB0aWMtY3VydmUNCmNyeXB0b2dyYXBo
eTsgc2VlLCBlLmcuLCBbMTk5OCBGcmV5XSBhbmQgWzIwMDMgRGllbV0uIg0KDQpNYXliZSBGcmV5
J3MgV2VpbC1kZXNjZW50IGF0dGFjayBzdHJhdGVneSBoYXMgcmVhY2hlZCBpdHMgbGltaXRzLCBi
dXQNCm1heWJlIG5vdDsgc2VlLCBlLmcuLCBodHRwOi8vZXByaW50LmlhY3Iub3JnLzIwMTIvMTQ2
LiBUaGUgcGVyZm9ybWFuY2UNCmJlbmVmaXRzIG9mIEtvYmxpdHogY3VydmVzIGFyZW4ndCBiaWcg
ZW5vdWdoIHRvIGp1c3RpZnkgaGF2aW5nIHRvIHdvcnJ5DQphYm91dCBmdXJ0aGVyIGRldmVsb3Bt
ZW50cyBpbiB0aGlzIGFyZWEuIEl0J3MgYmVzdCB0byB1c2UgcHJpbWUgZmllbGRzLA0KZWxpbWlu
YXRpbmcgdGhpcyBlbnRpcmUgY2xhc3Mgb2YgYXR0YWNrcy4NCg0KPiBJIG11c3QgaGF2ZSBmb3Jn
b3R0ZW4gdGhhdCBhc3BlY3Qgb2YgdGhlIEJyYWlucG9vbCBzdGFuZGFyZC4gSWYNCj4gcG9zc2li
bGUsIHBsZWFzZSByZW1pbmQgbWUgb2YgdGhlIGlzc3VlLCBpZiBvbmx5IGJ5IGxpbmsgdG8gdGhl
IHJlbGV2YW50DQo+IGRvY3VtZW50IChhbmQgc2VjdGlvbiB0aGVyZW9mKS4NCg0KVGhpcyBpcyB0
aGUgc2Vjb25kIGJ1bGxldCBpdGVtIGluIHRoZSBsaXN0IG9mICJtYWpvciBpc3N1ZXMiIHN0YXRl
ZCBhdA0KdGhlIGJlZ2lubmluZyBvZiAiRUNDIEJyYWlucG9vbCBTdGFuZGFyZCBDdXJ2ZXMgYW5k
IEN1cnZlIEdlbmVyYXRpb24gdi4NCjEuMCIuDQoNCj4gYSBjb25zaXN0ZW50IHRyZWF0bWVudCBv
ZiBFQ0MgbXVzdCBtaWxkbHkgcmVkdWNlLCBvciBhdCBsZWFzdCByZXZpc2UsDQo+IHRoZSBjbGFp
bWVkIHNlY3VyaXR5IG9mIGFueSBFQyBjdXJ2ZSBpZiB0aGUgdHJlYXRtZW50IGFsc28gcG9zaXRz
IHRoYXQgTklTVA0KPiBjdXJ2ZXMgaGF2ZSBhbiB1bmRpc2Nsb3NlZCBzdHJvbmcgd2Vha25lc3Mu
DQoNCk5vLg0KDQpTdXBwb3NlIE5TQSBrbm93cy0tLWFuZCBrbmV3IGluIHRoZSBsYXRlIDE5OTBz
LS0tYSBjb3N0LTJeNjQgYXR0YWNrIHRoYXQNCmJyZWFrcyBvbmUgUDEzNjMtY29tcGxpYW50IDI1
Ni1iaXQgY3VydmUgaW4gYSBiaWxsaW9uLiBUaGlzIHdvdWxkbid0IGJlDQpvdXQgb2YgbGluZSB3
aXRoIHRoZSBzcGVjdHJ1bSBvZiBrbm93biBFQ0MgYXR0YWNrcywgc3VjaCBhcw0KDQoqIHRoZSBQ
b2hsaWctLUhlbGxtYW4gYXR0YWNrIGJyZWFraW5nIG1vc3QgY3VydmUgb3JkZXJzICh0aGlzIGlz
IHdoeQ0KUDEzNjMgcmVxdWlyZXMgYSBsYXJnZSBwcmltZSB0byBkaXZpZGUgdGhlIG9yZGVyKSwN
CiogdHdpc3QgYXR0YWNrcyBicmVha2luZyBtb3N0IG9mIHRoZSByZW1haW5pbmcgY3VydmUgb3Jk
ZXJzIGluIG1hbnkNCnByb3RvY29scywNCiogV2VpbCBkZXNjZW50IGJyZWFraW5nIG1hbnkgY3Vy
dmVzIGZvciBzb21lIGZpZWxkIHNpemVzLA0KKiB0aGUgTU9WIGF0dGFjayBvbiBjdXJ2ZXMgb2Yg
b3JkZXIgcC0xIGFuZCBwKzEgYW5kIHNvIG9uLCBhbmQNCiogYW4gYXR0YWNrIG9uIGN1cnZlcyBv
ZiBvcmRlciBwLg0KDQpTdXBwb3NlIHRoYXQgTlNBIGNhbiByZWNvZ25pemUgaW1tZWRpYXRlbHkg
ZnJvbSB0aGUgZ3JvdXAgb3JkZXIgd2hldGhlcg0KdGhlIGF0dGFjayB3aWxsIGJlIHN1Y2Nlc3Nm
dWwtLS1hZ2FpbiBhIHJlYXNvbmFibGUgYXNzdW1wdGlvbi4gTlNBIGNvdWxkDQp0aGVuDQoNCiog
aGF2ZSBnZW5lcmF0ZWQgbWFueSBiaWxsaW9ucyBvZiBzZWVkcyB1bnRpbCBmaW5kaW5nIGENClAx
MzYzLWNvbXBsaWFudCBjdXJ2ZSB2dWxuZXJhYmxlIHRvIHRoaXMgYXR0YWNrIChhIGZlYXNpYmxl
DQpjb21wdXRhdGlvbiBmb3IgTlNBIGluIHRoZSAxOTkwcyksDQoNCiogaGF2ZSBzdGFuZGFyZGl6
ZWQgdGhhdCBjdXJ2ZSBhcyBOSVNUIFAtMjU2ICh3ZSBhbHJlYWR5IGtub3cgdGhhdA0KTklTVCB0
b29rIGl0cyBjdXJ2ZXMgZnJvbSBOU0EpLCBmYWxzZWx5IGNsYWltaW5nIHRoZSBjdXJ2ZSB0byBi
ZQ0KInZlcmlmaWFibHkgcmFuZG9tIiwgYW5kDQoNCiogYmUgYXBwbHlpbmcgdGhlIGNvc3QtMl42
NCBhdHRhY2sgdG8gTklTVCBQLTI1NiB1c2VycyB0b2RheS4NCg0KWW91IGNsYWltIHRoYXQgc3Vj
aCBhbiBhdHRhY2sgd291bGQgYmUgYSB0aHJlYXQgdG8gImFueSBFQyBjdXJ2ZSIuIEJ1dA0KdGhp
cyBjbGFpbSBpcyBvYnZpb3VzbHkgbm90IGNvcnJlY3QgZm9yIGN1cnZlcyB0aGF0IHJlYWxseSBh
cmUgcmFuZG9tbHkNCmdlbmVyYXRlZCAoYW5kIHlvdSBoYXZlIHplcm8ganVzdGlmaWNhdGlvbiBm
b3IgbWFraW5nIHRoZSBzYW1lIGNsYWltIGZvcg0KYW55IHBhcnRpY3VsYXIgY3VydmUpLiBUaGUg
Y29ycmVjdCBjb21wYXJpc29uLCB1bmRlciBleGFjdGx5IHRoZSBzYW1lDQpoeXBvdGhlc2VzLCBp
cyBzaW1wbGU6DQoNCiogSG9uZXN0IGN1cnZlOiBOU0EgaGFzIF9hIG9uZS1pbi1hLWJpbGxpb24g
Y2hhbmNlXyB0aGF0IHdlIG9idGFpbmVkDQphIHdlYWsgY3VydmUsIGluIHdoaWNoIGNhc2UgTlNB
IGZpbmRzIG91ciBrZXlzIHdpdGggY29zdCAyXjY0Lg0KDQoqIE5JU1QgY3VydmU6IE5TQSBpcyBf
Z3VhcmFudGVlZF8gdGhhdCB3ZSdyZSB1c2luZyBhIHdlYWsgY3VydmUsIHNvDQpOU0EgZmluZHMg
b3VyIGtleXMgd2l0aCBjb3N0IDJeNjQuDQoNClRoZXNlIGFyZSBvYnZpb3VzbHkgbm90IHRoZSBz
YW1lIHNpdHVhdGlvbi4gVGhlIGF0dGFjayBjb3N0cyBhcmUgdGhlDQpzYW1lLCBidXQgdGhlIHN1
Y2Nlc3MgcHJvYmFiaWxpdGllcyBhcmUgb24gdG90YWxseSBkaWZmZXJlbnQgc2NhbGVzLg0KDQpJ
IGRvbid0IHRoaW5rIHRoZXJlJ3MgYSBoaWdoIHJpc2sgb2YgYmVpbmcgaW4gdGhpcyBzaXR1YXRp
b24tLS10aGVyZQ0KaGF2ZSBiZWVuIG1hbnkgeWVhcnMgb2YgaW50ZW5zaXZlIGNyeXB0YW5hbHlz
aXMgb2YgRUNDLCBhbmQgZm9yIHByaW1lDQpmaWVsZHMgdGhlIHNlY3VyaXR5IHN0b3J5IHNlZW1z
IHRvIGhhdmUgY29udmVyZ2VkLiBCdXQgdGhlcmUncyBhbHNvIG5vDQpyZWFzb24gZm9yIEVDQyB1
c2VycyB0byBleHBvc2UgdGhlbXNlbHZlcyB0byByaXNrcyB0aGF0IGFyZSBzbyB0cml2aWFsDQp0
byBhdm9pZC4gVGhlcmUgYXJlIGFsc28gbXVjaCBsYXJnZXIgcmlza3MgdGhhdCBkZWZpbml0ZWx5
IGJpdGUgcGVvcGxlDQooc2VlIGh0dHA6Ly9jci55cC50by90YWxrcy8yMDEzLjA1LjMxL3NsaWRl
cy1kYW4rdGFuamEtMjAxMzA1MzEtNHgzLnBkZikNCmFuZCB0aGF0IG9uZSBjYW4gYXZvaWQgYnkg
bW92aW5nIGF3YXkgZnJvbSB0aGUgTklTVCBjdXJ2ZXMuDQoNCj4gSSBoYXZlIGFyZ3VlZCBvbiB0
aGlzIGxpc3QgdGhhdA0KPiBDdXJ2ZTI1NTE5IGlzIHNwZWNpYWwgaW4gaXRzIHVzZSBvZiBzbWFs
bCBjb2VmZmljaWVudHMuDQoNCldlbGwsIHllcywgeW91J3ZlIGRlY2xhcmVkIHRoYXQgeV4yPXhe
Mys0ODY2NjJ4XjIreCBtb2QgMl4yNTUtMTkgaXMNCiJzcGVjaWFsIiwgYnV0IHlvdSBoYXZlbid0
IGFjdHVhbGx5IGdpdmVuIGFuIGFyZ3VtZW50IGZvciB0aGlzLS0tZm9yDQpleGFtcGxlLCBhbiBh
dHRhY2sgc3RyYXRlZ3kgaW4gd2hpY2ggdGhlIHNpemUgb2YgdGhlIDQ4NjY2MiBwbGF5cyBhDQpy
b2xlLiBJbmRleCBjYWxjdWx1cyBzZWVzIHNpemVzLCBidXQgdGhlIHdob2xlIHBvaW50IG9mIEVD
QyBpcyB0byBzdG9wDQppbmRleCBjYWxjdWx1cy4gWW91IGNvdWxkIGVxdWFsbHkgd2VsbCBkZWNs
YXJlIHRoYXQgTklTVCBQLTI1NiBpcw0KInNwZWNpYWwiIHNpbmNlIGl0cyBwcmltZSBjYW4gYmUg
d3JpdHRlbiBhcyBhIGxvdy1kZWdyZWUgcG9seW5vbWlhbCBpbiBhDQpwb3dlciBvZiAyIHdpdGgg
Y29lZmZpY2llbnRzIHstMSwwLDF9LCBvciBkZWNsYXJlIHRoYXQgYnJhaW5wb29sUDI1NnIxDQpp
cyAic3BlY2lhbCIgc2luY2UgaXQgY29udGFpbnMgdGhlIHNjYXJ5IHN0cmluZyBCQ0NEQy4NCg0K
PiBEb2VzIEN1cnZlMjU1MTkgaWdub3JlIENoZW9uLXR5cGUgImF0dGFja3MiICh3aGljaCBhcmUg
cmF0aGVyIHdlYWspPw0KDQpLZXkgZGVyaXZhdGlvbiBzdG9wcyBzdWNoIGF0dGFja3MsIGFuZCBp
cyBlYXN5IHRvIGRvIHNlY3VyZWx5LCBhcw0KZGlzY3Vzc2VkIGluIHRoZSBDdXJ2ZTI1NTE5IHBh
cGVyLiBBcyBmYXIgYXMgSSBrbm93LCBhbGwgQ3VydmUyNTUxOQ0KZGVwbG95bWVudCBpcyB1c2lu
ZyBhcHByb3ByaWF0ZSBrZXkgZGVyaXZhdGlvbi4NCg0KLS0tRC4gSi4gQmVybnN0ZWluDQpSZXNl
YXJjaCBQcm9mZXNzb3IsIENvbXB1dGVyIFNjaWVuY2UsIFVuaXZlcnNpdHkgb2YgSWxsaW5vaXMg
YXQgQ2hpY2Fnbw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby90bHMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KVGhpcyB0cmFuc21pc3Npb24g
KGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZv
cm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3Rl
ZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp
LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBp
bmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlz
IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy
cm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo
aXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0
cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVu
ZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4K


From aerowolf@gmail.com  Sun Sep 29 00:33:09 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 742C821F9EB0 for ; Sun, 29 Sep 2013 00:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.366
X-Spam-Level: 
X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_BAYES_5x8=0.8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muB3fT87CNsD for ; Sun, 29 Sep 2013 00:33:08 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 0459921F9E83 for ; Sun, 29 Sep 2013 00:33:07 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id c11so4225605wgh.18 for ; Sun, 29 Sep 2013 00:33:07 -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 :content-type; bh=e5yUhbavPjLR7oPpcv+bOIOL5k2S4HouwsQPD3Rb+Vk=; b=vTMmBcWI8nCVUrmsvwT3hN45V2ne2eRHKndBrIsVs6l9tumIV0gMnusETZkQ2dslGT ptgdo4dQI7fNKnFXaqQLW/k4tYDNCkVIQ9PT8uvRCgY4Ndjft6Xea+WBJPqeWF7E3GRD wOH8cQ4aUw/0B8opkmoVQdbeYkEp9jkSP/zPqa3Mb8BZsEtJDnOt0hkVQfNWLKZFpxRa VOi05//faeG76irtlswgHoiNXikOZ01W1cSwMeBQOIkpBYRX20ViAlcCmejqVwaSYHjK 50vMVC2Dd2m1JqA5pghxz9Zv2HLYvrV2zddPUVyKY0gdH3I5q6QlUxBOn2O3oy4iuAX7 aVXA==
MIME-Version: 1.0
X-Received: by 10.180.160.165 with SMTP id xl5mr8918719wib.48.1380439986908; Sun, 29 Sep 2013 00:33:06 -0700 (PDT)
Received: by 10.194.134.67 with HTTP; Sun, 29 Sep 2013 00:33:06 -0700 (PDT)
In-Reply-To: <20130926152757.15842.qmail@cr.yp.to>
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to>
Date: Sun, 29 Sep 2013 00:33:06 -0700
Message-ID: 
From: Kyle Hamilton 
To: "tls@ietf.org" 
Content-Type: multipart/alternative; boundary=047d7b62509c0db3f504e780bb2f
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Sep 2013 07:33:09 -0000

--047d7b62509c0db3f504e780bb2f
Content-Type: text/plain; charset=UTF-8

Dr Bernstein,

That's all well and good, but perhaps should you try to figure out how your
functions can in fact be used in such standards as TLS without having to
resort to pulling hens' teeth?

Or perhaps apply your (admittedly much better than mine) intellect to
figure out how to create a single public key from a single private key
which can be used for both signing and key derivation, thus permitting
consolidation of both into a single X.509 Certificate structure?  The lack
of this is in fact a major impediment to using self-signed certificates as
containers for curve25519 public keys.

Granted, I've been severely out of touch for quite a while, and it's
possible that (e.g.) Ed25519 permits the use of the same public key in this
manner (even though Ed25519 has a peculiar recordkeeping requirement which
makes it less than ideal).  If it does, please accept my humble apology.
If it does not, however, I'd like to ask you to design a function which can
be used for both signature and derivation from the same public key, so as
to create a clear path forward for at least one (if not more)
externally-developed elliptical function for ease of integration into the
preexisting TLS (and perhaps more importantly PKI) infrastructure.

BULLRUN's first major visible success was in inducing everyone to think
about "how do you know it's who you think you're talking to?", completely
ignoring SSLv1's opportunistic encryption.  Netscape carried this further
by simply refusing to speak with SSL sites that didn't authenticate
themselves.  I don't know if there is any webserver out there that will do
TLS without an identity certificate, and even if there is I doubt there is
a client that will communicate in those conditions.  So, we need at the
very least a self-signed certificate to carry the public key used to derive
the shared key.

(Also, while I've hopefully got your attention, have you any plan to create
an x64 ABI for Curve25519?  I'm currently having to use it via a COM
wrapper I hacked up in C#, 64-bit processes calling via COM to a 32-bit
process which exports only one function that COM doesn't mandate:
curve25519(). This is insecure to COM-debug capable processes at the very
least, as it requires that the caller provide the caller's private key over
a public data bus.)

I have the utmost respect for your knowledge and intellect, but without
having a plan to fit your function into a common framework, there is simply
no way to use the function you keep trying to promote.

-Kyle H

(Note: I would -love- to find out that I'm wrong, on any or all of this.)


On Thu, Sep 26, 2013 at 8:27 AM, D. J. Bernstein  wrote:

> Modern elliptic-curve cryptography solidly takes care of all of the
> "brittleness" mentioned in this thread, and is much easier than RSA to
> implement securely. Compare https://twitter.com/tweetnacl to the amount
> of code required to implement similar functionality in OpenSSL.
>
> Peter Gutmann writes:
> > potentially NSA-influenced values like P256
>
> There is indisputably an unexplained seed c49d3608 86e70493 6a6678e1
> 139d26b7 819f7e90 for the NIST P-256 curve mod 2^256-2^224+2^192+2^96-1,
> and similarly for the other NIST curves. This was identified by the 2005
> Brainpool standard as a major issue for the NIST curves; it has also
> been highlighted recently by Bruce Schneier.
>
> Fortunately, one can design high-security elliptic curves that don't
> have any unexplained constants. That's what I did with Curve25519.
> Curve25519 is the curve y^2=x^3+486662x^2+x mod 2^255-19; every number
> here is completely explained in the Curve25519 paper.
>
> > even without NSA skullduggery make a nice single target for attack.
>
> There have already been several detailed studies of the cost of finding
> multiple discrete logs on the same curve (authors: Escott, Sager,
> Selkirk, Tsapakidis, Kuhn, Struik, Hitchcock, Montague, Carter, Dawson,
> Lee, Cheon, Hong, Bernstein, Lange). Basically, if finding one ECC key
> costs 2^128, then finding 1000000 keys costs 1000*2^128, and the first
> key found will still cost 2^128. For comparison, finding 1000000 AES
> keys costs the same 2^128 as finding a single key, and the first AES key
> will be found with cost only 2^128/1000000.
>
> Yaron Sheffer writes:
> > The recipient needs to test that the received point is actually on
> > the relevant curve.
>
> This is certainly an issue for the NIST curves. Fortunately, this test
> is completely unnecessary for x-coordinate ECC using twist-secure curves
> such as Curve25519. I introduced this approach at ECC 2001, using the
> smaller curve y^2=x^3+7530x^2+x mod 2^226-5 as an illustration.
>
> Peter Gutmann writes:
> > For example if you used the recommended (until not too long ago) way
> > to generate your k for (EC)DSA then you'd leak a tiny bit of your
> > private key on each signature (again, that nasty propensity of DLP
> > algorithms to leak the private key).
>
> Ed25519 has three levels of defense against this type of problem.
>
> First, k is chosen as a random 512-bit string, many bits larger than the
> group order l (around 2^252). This is overkill (compare to the 64 bits
> in Algorithm 2 in Section 4.1.1 of BSI Technical Guideline TR-03111) but
> also an inexpensive and comprehensive defense.
>
> Second, the group order l is very close to a power of 2, specifically
> within 2^125 of 2^252, so the bias would be unnoticeable even if k were
> as small as 256 bits.
>
> Third, k is actually produced in a deterministic way as a secret hash,
> so the k-generation mechanism is fully testable---there's no need to
> worry about the implementor accidentally choosing a biased RNG.
>
> ---D. J. Bernstein
>    Research Professor, Computer Science, University of Illinois at Chicago
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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


Dr Bernstein,

That's all we=
ll and good, but perhaps should you try to figure out how your functions ca=
n in fact be used in such standards as TLS without having to resort to pull=
ing hens' teeth?


Or perhaps apply your (admittedly much better than mine) intellec=
t to figure out how to create a single public key from a single private key=
 which can be used for both signing and key derivation, thus permitting con=
solidation of both into a single X.509 Certificate structure?=C2=A0 The lac=
k of this is in fact a major impediment to using self-signed certificates a=
s containers for curve25519 public keys.


Granted, I've been severely out of touch for quite a while, a=
nd it's possible that (e.g.) Ed25519 permits the use of the same public=
 key in this manner (even though Ed25519 has a peculiar recordkeeping requi=
rement which makes it less than ideal).=C2=A0 If it does, please accept my =
humble apology.=C2=A0 If it does not, however, I'd like to ask you to d=
esign a function which can be used for both signature and derivation from t=
he same public key, so as to create a clear path forward for at least one (=
if not more) externally-developed elliptical function for ease of integrati=
on into the preexisting TLS (and perhaps more importantly PKI) infrastructu=
re.


BULLRUN's first major visible success was in inducing ev=
eryone to think about "how do you know it's who you think you'=
re talking to?", completely ignoring SSLv1's opportunistic encrypt=
ion.=C2=A0 Netscape carried this further by simply refusing to speak with S=
SL sites that didn't authenticate themselves.=C2=A0 I don't know if=
 there is any webserver out there that will do TLS without an identity cert=
ificate, and even if there is I doubt there is a client that will communica=
te in those conditions.=C2=A0 So, we need at the very least a self-signed c=
ertificate to carry the public key used to derive the shared key.


(Also, while I've hopefully got your attention, have you=
 any plan to create an x64 ABI for Curve25519?=C2=A0 I'm currently havi=
ng to use it via a COM wrapper I hacked up in C#, 64-bit processes calling =
via COM to a 32-bit process which exports only one function that COM doesn&=
#39;t mandate: curve25519(). This is insecure to COM-debug capable processe=
s at the very least, as it requires that the caller provide the caller'=
s private key over a public data bus.)



I have the utmost respect for your knowledge and =
intellect, but without having a plan to fit your function into a common fra=
mework, there is simply no way to use the function you keep trying to promo=
te.



-Kyle H

(Note: I would -love- to find out=
 that I'm wrong, on any or all of this.)


On Thu, Sep 26, 2013 at 8:27 AM, D=
. J. Bernstein <djb@cr.yp.to> wrote:


Modern elliptic-curve cryptography solidly t=
akes care of all of the

"brittleness" mentioned in this thread, and is much easier than R=
SA to

implement securely. Compare https://twitter.com/tweetnacl to the amount

of code required to implement similar functionality in OpenSSL.



Peter Gutmann writes:

> potentially NSA-influenced values like P256



There is indisputably an unexplained seed c49d3608 86e70493 6a6678e1

139d26b7 819f7e90 for the NIST P-256 curve mod 2^256-2^224+2^192+2^96-1,
and similarly for the other NIST curves. This was identified by the 2005
Brainpool standard as a major issue for the NIST curves; it has also

been highlighted recently by Bruce Schneier.



Fortunately, one can design high-security elliptic curves that don't
have any unexplained constants. That's what I did with Curve25519.

Curve25519 is the curve y^2=3Dx^3+486662x^2+x mod 2^255-19; every number
here is completely explained in the Curve25519 paper.



> even without NSA skullduggery make a nice single target for attack.


There have already been several detailed studies of the cost of finding

multiple discrete logs on the same curve (authors: Escott, Sager,

Selkirk, Tsapakidis, Kuhn, Struik, Hitchcock, Montague, Carter, Dawson,

Lee, Cheon, Hong, Bernstein, Lange). Basically, if finding one ECC key

costs 2^128, then finding 1000000 keys costs 1000*2^128, and the first

key found will still cost 2^128. For comparison, finding 1000000 AES

keys costs the same 2^128 as finding a single key, and the first AES key
will be found with cost only 2^128/1000000.



Yaron Sheffer writes:

> The recipient needs to test that the received point is actually on

> the relevant curve.



This is certainly an issue for the NIST curves. Fortunately, this test

is completely unnecessary for x-coordinate ECC using twist-secure curves
such as Curve25519. I introduced this approach at ECC 2001, using the

smaller curve y^2=3Dx^3+7530x^2+x mod 2^226-5 as an illustration.



Peter Gutmann writes:

> For example if you used the recommended (until not too long ago) way
> to generate your k for (EC)DSA then you'd leak a tiny bit of your<=
br>
> private key on each signature (again, that nasty propensity of DLP

> algorithms to leak the private key).



Ed25519 has three levels of defense against this type of problem.



First, k is chosen as a random 512-bit string, many bits larger than the
group order l (around 2^252). This is overkill (compare to the 64 bits

in Algorithm 2 in Section 4.1.1 of BSI Technical Guideline TR-03111) but
also an inexpensive and comprehensive defense.



Second, the group order l is very close to a power of 2, specifically

within 2^125 of 2^252, so the bias would be unnoticeable even if k were

as small as 256 bits.



Third, k is actually produced in a deterministic way as a secret hash,

so the k-generation mechanism is fully testable---there's no need to
worry about the implementor accidentally choosing a biased RNG.



---D. J. Bernstein

=C2=A0 =C2=A0Research Professor, Computer Science, University of Illinois a=
t Chicago

_______________________________________________

TLS mailing list

TLS@ietf.org

htt=
ps://www.ietf.org/mailman/listinfo/tls





--047d7b62509c0db3f504e780bb2f--

From msj@nthpermutation.com  Sun Sep 29 10:20:54 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A898421E8050 for ; Sun, 29 Sep 2013 10:20:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.575
X-Spam-Level: 
X-Spam-Status: No, score=-3.575 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQ-+zA6SI+f5 for ; Sun, 29 Sep 2013 10:20:48 -0700 (PDT)
Received: from mail-qe0-f53.google.com (mail-qe0-f53.google.com [209.85.128.53]) by ietfa.amsl.com (Postfix) with ESMTP id 636BD21F85EF for ; Sun, 29 Sep 2013 10:20:48 -0700 (PDT)
Received: by mail-qe0-f53.google.com with SMTP id jy17so3160669qeb.12 for ; Sun, 29 Sep 2013 10:20:47 -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=cByqCGClbJ4hlKyZwyi/27qWdlT1cOyFuRcJOzJ4FyE=; b=QjeL//Gglbr35gALiCqe7XfkJkUyRIw2X536rFldTA4m4tbSVwtV2sOKnOX8XKYCjn EK6QkAGCgnGJNFpZEf4SiDVI08KI7gHuQqTmsG1nrsCPkYmM5B/iIARqhiS7gNoqx3mT DFq1+jmR0ackt4UryWCyqgNWmrxygtaY+CtN+/dVfRBONVfaMRNcbzyCpx6Ob3/0qYVv H+skj6fnqMvHwdHJMoxFTDirgkwH62SW/opSSWkqJTdhGXqfAwZDGdDBwSdPQ4O8x8ed f6jiFFktGjQN3QvGStdwXVCJjAHA26oJ1Vh5nVtxZyr2aT/VQ0qKstqxuvcYTBolev06 z9ZQ==
X-Gm-Message-State: ALoCoQllzi87UA/umxDNyDswOf6TNlYspXgp3fv5GFOgb2BT/kz1DdfSE0CnDANT1T20USuNpVRI
X-Received: by 10.49.128.68 with SMTP id nm4mr23432237qeb.68.1380475247693; Sun, 29 Sep 2013 10:20:47 -0700 (PDT)
Received: from [192.168.1.112] (c-68-83-212-126.hsd1.md.comcast.net. [68.83.212.126]) by mx.google.com with ESMTPSA id n9sm41819795qag.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Sep 2013 10:20:47 -0700 (PDT)
Message-ID: <52486175.4010807@nthpermutation.com>
Date: Sun, 29 Sep 2013 13:20:53 -0400
From: Michael StJohns 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org
References: 			<36E4901E-E7BB-4DA9-B7E4-49FAB7C7A3A2@checkpoint.com>	<52459F3E.2050101@gmail.com> <20130927185535.5b971c1d@hboeck.de> <5245F1DE.10903@gmail.com>
In-Reply-To: <5245F1DE.10903@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [TLS] Private Key Security [Was Re:  DHE key derivation]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 29 Sep 2013 17:20:54 -0000

On 9/27/2013 5:00 PM, Yaron Sheffer wrote:
>
> Just a few weeks ago we as a community thought the server's private 
> key was generally secure. Now the entire community seems to assume the 
> private key is easy to steal.

If the server private key isn't inside an HSM (hardware security module) 
of some sort, normal attacks on the server will make it possible to 
steal the key.  Even if encrypted at rest, to be used the key must be 
decrypted and moved to memory at some point.  Anyone who thought 
datafile based server private keys were unconditionally or even 
marginally secure probably hadn't thought it through.

If the server private key IS inside an HSM, the current way session keys 
are derived from the session master key makes it possible for an 
attacker to steal those keys unless the entire TLS negotiation and 
packet processing takes place inside an HSM specifically designed for 
that version of TLS.
> Practically, most private keys will probably not be stolen. 

With respect to whether a key will be stolen or not, you really need 
only compare the value of the data being protected by that key to the 
cost to an attacker to retrieve that key (and the data).  If the value 
of the data is >> or >>> than the cost to attack, chances are someone 
has done so.

HSMs increase the cost of attack and that's a good reason to use them, 
but you still need to consider the relationship of the expected cost to 
attack to the value of the data being protected and adjust your 
protections if the value of the data - to the attacker - exceeds the 
attackers cost of attack.

Mike



From Johannes.Merkle@secunet.com  Mon Sep 30 05:00:01 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3597721F8E70 for ; Mon, 30 Sep 2013 05:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GwDoEiQdQXA for ; Mon, 30 Sep 2013 04:59:56 -0700 (PDT)
Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4D22021F8F2A for ; Mon, 30 Sep 2013 04:59:53 -0700 (PDT)
Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 6601E1A0078; Mon, 30 Sep 2013 13:59:51 +0200 (CEST)
X-Virus-Scanned: by secunet
Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nBRAIUV8t5vy; Mon, 30 Sep 2013 13:59:50 +0200 (CEST)
Received: from mail-srv1.secumail.de (unknown [10.53.40.200]) by a.mx.secunet.com (Postfix) with ESMTP id 4BF5A1A0075; Mon, 30 Sep 2013 13:59:50 +0200 (CEST)
Received: from [10.208.1.57] ([10.208.1.57]) by mail-srv1.secumail.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 30 Sep 2013 13:59:50 +0200
Message-ID: <524967B5.70007@secunet.com>
Date: Mon, 30 Sep 2013 13:59:49 +0200
From: Johannes Merkle 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: tls@ietf.org, dbrown@certicom.com
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> <810C31990B57ED40B2062BA10D43FBF5BDB49B@XMB116CNC.rim.net> <20130928223648.1113.qmail@cr.yp.to>
In-Reply-To: <20130928223648.1113.qmail@cr.yp.to>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Sep 2013 11:59:50.0821 (UTC) FILETIME=[91444550:01CEBDD4]
Cc: Manfred Lochter , djb@cr.yp.to
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 12:00:01 -0000

>> I must have forgotten that aspect of the Brainpool standard.  If
>> possible, please remind me of the issue, if only by link to the relevant
>> document (and section thereof).
> 
> This is the second bullet item in the list of "major issues" stated at
> the beginning of "ECC Brainpool Standard Curves and Curve Generation v.
> 1.0".

This aspect is also addressed in RFC 5639 as first bullet point in Section 1 and as security requirement 5 in section 2.1.

Johannes


From hauke@hauke-m.de  Mon Sep 30 07:51:44 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36E021F9B12 for ; Mon, 30 Sep 2013 07:51:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do2faxerEL0z for ; Mon, 30 Sep 2013 07:51:41 -0700 (PDT)
Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1B921F9AF0 for ; Mon, 30 Sep 2013 07:51:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 2DF0D85EA for ; Mon, 30 Sep 2013 16:51:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at hauke-m.de 
Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sg7X5J9mfttm for ; Mon, 30 Sep 2013 16:51:33 +0200 (CEST)
Received: from [IPv6:2001:470:1f0b:447:a84f:72c0:6139:6a42] (unknown [IPv6:2001:470:1f0b:447:a84f:72c0:6139:6a42]) by hauke-m.de (Postfix) with ESMTPSA id 869ED857F for ; Mon, 30 Sep 2013 16:51:32 +0200 (CEST)
Message-ID: <52498FF1.1090701@hauke-m.de>
Date: Mon, 30 Sep 2013 16:51:29 +0200
From: Hauke Mehrtens 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: tls@ietf.org
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [TLS] draft-ietf-tls-oob-pubkey-09: client auth, but no client key
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 14:51:44 -0000

RFC 5246 7.4.6 "Client Certificate" says:

      If no suitable certificate is available,
      the client MUST send a certificate message containing no
      certificates.  That is, the certificate_list structure has a
      length of zero.

How should a client act when raw public keys are used and the server
requests client authentication, but there is no public key or no
suitable public key?

Not adding client_certificate_type to the ClientHello is not enough,
because this could also indicate that the client supports client
authentication with X.509 certificates.

I would send an empty client certificate handshake message and no
certificate verify message and the server should decide, like it is
specified for X.509 certificates in RFC 5246 7.4.6.

Hauke

From alangley@gmail.com  Mon Sep 30 08:03:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52A2E21F9B5A for ; Mon, 30 Sep 2013 08:03:23 -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=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDn-AAg7S0uw for ; Mon, 30 Sep 2013 08:03:22 -0700 (PDT)
Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC0521F9BB6 for ; Mon, 30 Sep 2013 08:03:22 -0700 (PDT)
Received: by mail-la0-f44.google.com with SMTP id eo20so4588516lab.17 for ; Mon, 30 Sep 2013 08:03:21 -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=YYcUAMSCD4vtkGViwo5MD7zsw2hGJaDayZUlWEEs5fk=; b=vXL8wrHBOrkFJ6TxPBxA9id3f4Uk0ZymqOfH0vepG0diSWxbK8V3ZlnU4mClc+eoGa hqpGcFuwtsUiu+1YLSpi8ShsMuivuDgeh9j2Jj6/ceD9wxhAMh3NqBmXnmFH1Jsdtg1N xisxHAvOhgyAMM3nChJDs+85vyXIIVCYGRU0AvLUlkA/129Ql74yAdpxZwh1Z/uxrlJV umMn8eLAG9Vr6xYA6xAbw5MIRkHaapw9rhDTyAHS13/10qrtxuAvIz3e0+a8hRngIffm bxlJq4nbdWlQ596ms3TRd1txDHVWqvbkkNgc26tOHSgpLj4NvPViFsrnGJ5HdwANDTlE 6j6A==
MIME-Version: 1.0
X-Received: by 10.152.28.105 with SMTP id a9mr2180027lah.41.1380553401056; Mon, 30 Sep 2013 08:03:21 -0700 (PDT)
Sender: alangley@gmail.com
Received: by 10.112.6.170 with HTTP; Mon, 30 Sep 2013 08:03:20 -0700 (PDT)
In-Reply-To: 
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to> 
Date: Mon, 30 Sep 2013 11:03:20 -0400
X-Google-Sender-Auth: DpwfUArUkXzJGO7CMKUkLCG0pss
Message-ID: 
From: Adam Langley 
To: Kyle Hamilton 
Content-Type: text/plain; charset=UTF-8
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 15:03:23 -0000

On Sun, Sep 29, 2013 at 3:33 AM, Kyle Hamilton  wrote:
> Or perhaps apply your (admittedly much better than mine) intellect to figure
> out how to create a single public key from a single private key which can be
> used for both signing and key derivation, thus permitting consolidation of
> both into a single X.509 Certificate structure?  The lack of this is in fact
> a major impediment to using self-signed certificates as containers for
> curve25519 public keys.

Current ECDSA deployments involve an ECDSA key in an X.509 certificate
and ephemeral, ECDHE keys being generated by the server as needed.
These ephemeral keys are signed by the ECDSA key.

A similar design would have an Ed25519 key in the X.509 certificate
and curve25519 used for ECDHE. I don't believe there's anything needed
to get that working save for switching out the algorithms.

(It is the case that some ECDSA certificates have both the signature
and key derivation bits set in the key usage. This means that OpenSSL,
at least, will allow it to be used for both ECDSA and fixed-ECDH. I'm
not aware of anyone who actually wants that however. As far as I've
seen, it's just the result of copying an RSA certificate template and
forgetting to update the KeyUsage.)

> Granted, I've been severely out of touch for quite a while, and it's
> possible that (e.g.) Ed25519 permits the use of the same public key in this
> manner (even though Ed25519 has a peculiar recordkeeping requirement which
> makes it less than ideal).

Ed25519 and curve25519 are the same curve so it is technically
possible to use an Ed25519 public key, with a bit of thought, as a
curve25519 key. However, I wouldn't recommend it. TLS certainly
doesn't need that.

> (Also, while I've hopefully got your attention, have you any plan to create
> an x64 ABI for Curve25519?  I'm currently having to use it via a COM wrapper
> I hacked up in C#, 64-bit processes calling via COM to a 32-bit process
> which exports only one function that COM doesn't mandate: curve25519(). This
> is insecure to COM-debug capable processes at the very least, as it requires
> that the caller provide the caller's private key over a public data bus.)

There are several implementations of curve25519 in SUPERCOP, including
amd64, asm versions (amd64-51); 64-bit, C code (donna_c64) and
portable C code (ref10). It would be pretty simple to convert the
ref10 code to C# if you wished.


Cheers

AGL

From internet-drafts@ietf.org  Mon Sep 30 10:06:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A622421F8FAC; Mon, 30 Sep 2013 10:06:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWhYq5DtL5Ok; Mon, 30 Sep 2013 10:06:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EB721F9AFE; Mon, 30 Sep 2013 10:06:21 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.72
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20130930170621.31558.31620.idtracker@ietfa.amsl.com>
Date: Mon, 30 Sep 2013 10:06:21 -0700
Cc: tls@ietf.org
Subject: [TLS] I-D Action: draft-ietf-tls-applayerprotoneg-02.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 17:06:25 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the Transport Layer Security Working Group of=
 the IETF.

	Title           : Transport Layer Security (TLS) Application Layer Protoco=
l Negotiation Extension
	Author(s)       : Stephan Friedl
                          Andrei Popov
                          Adam Langley
                          Emile Stephan
	Filename        : draft-ietf-tls-applayerprotoneg-02.txt
	Pages           : 9
	Date            : 2013-09-30

Abstract:
   This document describes a Transport Layer Security (TLS) extension
   for application layer protocol negotiation within the TLS handshake.
   For instances in which the TLS connection is established over a well
   known TCP/IP port not associated with the desired application layer
   protocol, this extension allows the application layer to negotiate
   which protocol will be used within the TLS session.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-applayerprotoneg-02


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From mrex@sap.com  Mon Sep 30 10:17:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34A921F9AD5 for ; Mon, 30 Sep 2013 10:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.178
X-Spam-Level: 
X-Spam-Status: No, score=-10.178 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPpCS9f64naw for ; Mon, 30 Sep 2013 10:17:14 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 356BF21F960D for ; Mon, 30 Sep 2013 10:17:02 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8UHGvpV011101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 19:16:58 +0200 (MEST)
In-Reply-To: 
To: Bodo Moeller 
Date: Mon, 30 Sep 2013 19:16:57 +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: <20130930171657.C8BE01A9C2@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Fwd: New Version Notification for draft-bmoeller-tls-downgrade-scsv-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Sep 2013 17:17:19 -0000

Bodo Moeller wrote:
> >
> > https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-00#section-3
> >
> >    This section specifies server behavior when receiving the
> >    TLS_DOWNGRADE_SCSV cipher suite from a client in
> >    ClientHello.cipher_suites.
> > [...]
> >
> > To me, this part of your document places two requirements on the _server_
> > to abort the handshake.
> 
> Yes. My point is that there's no server-side guesswork involved -- no
> "flawed or unjustified" assumptions. This is entirely client-directed
> behavior!


To me, these two requirements amount to an unnecessary knee-jerk reaction,
while we are fully aware that most TLS version interop problems are
non-malicious, i.e. _not_ caused by an active attacker.


I really see harm in increasing the amount of TLS handshake failures
with new "abort" requirements of the TLS protocol itself.  Any new/additional
handshake failures ought to be left purely and entirely to the calling
applications and their security trade-offs / policies, which may or
may not involve the decision of an interactive user.  Our concern in
TLS WG ought to be reducing handshake failures, and getting rid of
the reconnect fallback entirely.


TLS version negotiation is royally broken (throughout the installed base),
and has been a well known fact since before TLSv1.1 (rfc4346) was
published in 2006.  And it doesn't look like time is helping to improve
the situation.  Actually, by shipping a defective RSA premaster client_version
check in Windows7/2008R2 the situation has become more challenging
today than it was in 2006.

Maybe you remember that there was a change to OpenSSL in order to
*improve* interoperability (=less failed TLS handshakes) in face
of this defective RSA premaster client_version check:

  http://www.ietf.org/mail-archive/web/tls/current/msg09417.html

  Relevant OpenSSL ChangeLog:

   Changes between 1.0.0h and 1.0.1  [14 Mar 2012]
  [...]
   *) Some servers which support TLS 1.0 can choke if we initially indicate
      support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA
      encrypted premaster secret. As a workaround use the maximum pemitted
      client version in client hello, this should keep such servers happy
      and still work with previous versions of OpenSSL.
      [Steve Henson]

Another example for TLS version challenges are defective middle-boxes
(Bluecoat seems popular for internet access from company networks):
https://kb.bluecoat.com/index?page=content&id=KB5493&actp=search&viewlocale=en_US&searchid=1380557656642


Yet another example would be the upgrade path for an installed server-farm,
where you would get yourself into trouble if the existing server-farm
causes clients to perform reconnect-fallbacks and trying to test
a new implementation of the kind you suggest would cause occasional
handshake failures for handshake where the first request went to an
old server, and the reconnect fallback to the updated server.
So for such a setup, this kind of feature would require a "flag day".


There is similar serious breakage in the TLS cipher suite documents that
describe AES in counter mode:
  http://tools.ietf.org/html/rfc5288#section-4
  http://tools.ietf.org/html/rfc6655#section-5

Implementing AEAD for TLSv1.0 or TLSv1.1 would be simple and straight-
forward, and the cipher suites (themselves) would exhibit the same
security properties.  But this breakage prohibits clients from even
proposing these cipher suites when they're doing a fallback, independent
of what is causing the fallback.

Consumers will typically (have to) limit the TLS version that their
client offers upfront to obtain robust behaviour.  And such a
configured limitation will typically be used for years (for as long
as the hardware is used and the software only upgraded).



To really improve the situation, new protocol features (including
TLS protocol versions >1.1) ought to be negotiated in a fashion that
increases the amount of successful TLS handshakes for the entire
installed base, and avoids the necessity for reconnect fallbacks--
something that the majority of programmtic TLS clients do not
even have.


-Martin

From mrex@sap.com  Mon Sep 30 11:00:18 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B45621F9A59 for ; Mon, 30 Sep 2013 11:00:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.18
X-Spam-Level: 
X-Spam-Status: No, score=-10.18 tagged_above=-999 required=5 tests=[AWL=0.069,  BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSFXcfa6h4bw for ; Mon, 30 Sep 2013 11:00:12 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14A21F9A3B for ; Mon, 30 Sep 2013 11:00:11 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8UI07r8002228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 20:00:07 +0200 (MEST)
In-Reply-To: <52486175.4010807@nthpermutation.com>
To: Michael StJohns 
Date: Mon, 30 Sep 2013 20:00: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: <20130930180007.65F4B1A9C2@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Private Key Security [Was Re: DHE key derivation]
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Sep 2013 18:00:18 -0000

Michael StJohns wrote:
> 
> With respect to whether a key will be stolen or not, you really need 
> only compare the value of the data being protected by that key to the 
> cost to an attacker to retrieve that key (and the data).  If the value 
> of the data is >> or >>> than the cost to attack, chances are someone 
> has done so.

If someone if after the data, then it will go after the data,
not after the keys.  

> 
> HSMs increase the cost of attack and that's a good reason to use them, 

For the vast majority of useful attacks it is entirely irrelevant
whether your keys are in a HSM or not.

First of all, HSMs will always and significantly increase the cost
of setting up and running a TLS peer by a significant amount, and
in particular, for a server, when performance is an issue.
HSMs also do not scale with multi-core CPUs; instead, you got to pay
factors more for a faster HSM.

With existing TLS, your HSM would have to implement current TLS versions
in its entirety, which most of the current HSMs probably do not.  And
interop with current TLS is likely going to be necessary for another
two decades (SSLv3 is 18 years old and we only recently managed to put
SSLv2 to rest (on paper, that is)).

Even when you have your keys in a HSM, this will not prevent that a
subverted server could look at incoming connections and perform
TLS-protected communication with a purely software-based TLS protocol
and software-based keys with the attacker.  In many situations,
the value is primarily in the data of the server, i.e. access to
data the server is processing or has on persistent storage.

Listening into communication and determining which client does what
might be interesting for collection by spooks (NSA, GCQH, etc.)
for performing data mining on the bigger picture, but is pretty
irrelevant for the average malfeasant attacker.

Being able to impersonate users might be *MUCH* more interesting
to attackers than being able to listen into boring communication,
e.g. obtaining credentials for users by various means, such as
pulling them from the data persistence, modifying access control lists,
capturing credentials of a disclosing authentication within the server
(rather than trying to sniff and decrypt them from the network),
setting/overwriting user credentials, creating new admin users,
adding X.509 trust anchors for acceptable TLS client certs and
probably lots of other things that are more powerful and more
devastating than obtaining the server's boring private key.


-Martin

From Andrei.Popov@microsoft.com  Mon Sep 30 12:15:48 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D922F21F9A1C for ; Mon, 30 Sep 2013 12:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Z0SbpYy4gVv for ; Mon, 30 Sep 2013 12:15:44 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0154.outbound.protection.outlook.com [207.46.163.154]) by ietfa.amsl.com (Postfix) with ESMTP id C295721F9A6C for ; Mon, 30 Sep 2013 12:15:40 -0700 (PDT)
Received: from BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) by BL2PR03MB194.namprd03.prod.outlook.com (10.255.230.142) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 30 Sep 2013 19:15:38 +0000
Received: from BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.243]) by BL2PR03MB194.namprd03.prod.outlook.com ([169.254.14.243]) with mapi id 15.00.0785.001; Mon, 30 Sep 2013 19:15:38 +0000
From: Andrei Popov 
To: "Joseph Salowey (jsalowey)" 
Thread-Topic: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tls-applayerprotoneg-01)
Thread-Index: AQHOmgayI7Fz7QRaikC2dRjq1euU/Zm/svEAgB864jA=
Date: Mon, 30 Sep 2013 19:15:37 +0000
Message-ID: <5bbe4c7a3148466ba27406bb0f2b6d03@BL2PR03MB194.namprd03.prod.outlook.com>
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
x-forefront-prvs: 0985DA2459
x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(13464003)(24454002)(164054003)(189002)(199002)(51704005)(31966008)(19580405001)(74662001)(19580395003)(51856001)(83322001)(47446002)(74502001)(54316002)(50986001)(76482001)(47976001)(49866001)(56776001)(53806001)(54356001)(33646001)(80976001)(59766001)(63696002)(74366001)(4396001)(77982001)(47736001)(80022001)(74706001)(74876001)(83072001)(74316001)(79102001)(65816001)(81342001)(81542001)(56816003)(77096001)(81816001)(46102001)(81686001)(76796001)(76576001)(76786001)(15975445006)(69226001)(15202345003)(3826001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB194; H:BL2PR03MB194.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
Cc: "" 
Subject: Re: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tls-applayerprotoneg-01)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 19:15:49 -0000

A revised draft-ietf-tls-applayerprotoneg-02.html has been submitted. The c=
hanges address the feedback we received during the TLS WG last call, and in=
clude:
- Removal of the experimental namespace;
- Removal of the HTTP/2 protocol ID with the intent that the HTTP WG reques=
t the appropriate protocol ID(s);
- More specific information in the IANA section.

Thanks,

Andrei

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Josep=
h Salowey (jsalowey)
Sent: Tuesday, September 10, 2013 10:17 AM
To: Joseph Salowey (jsalowey)
Cc: 
Subject: Re: [TLS] Start of Working Group Last Call for ALPN (draft-ietf-tl=
s-applayerprotoneg-01)

The working group last call for draft-ietf-tls-applayerprotoneg-01 has comp=
leted.  There is consensus in moving this work forward with some fixes to t=
he IANA section and some editorial nits.   I am going to ask the authors to=
 submit a revised draft which will be submitted to the IESG. =20

Thanks,

Joe


On Aug 15, 2013, at 3:27 PM, Joseph Salowey (jsalowey) =
 wrote:

> This is the working group last call for draft-ietf-tls-applayerprotoneg-0=
1. Please send your reviews and comments to the TLS list by September 6, 20=
13. =20
>=20
> The draft can be found at http://tools.ietf.org/html/draft-ietf-tls-appla=
yerprotoneg-01
>=20
> Thanks,
>=20
> Joe
>=20
>=20
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

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

From SChokhani@cygnacom.com  Mon Sep 30 12:27:38 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAB0D21F9B08 for ; Mon, 30 Sep 2013 12:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UKKbt3UEKq8I for ; Mon, 30 Sep 2013 12:27:34 -0700 (PDT)
Received: from ipedge2.cygnacom.com (ipedge2.cygnacom.com [216.191.252.27]) by ietfa.amsl.com (Postfix) with ESMTP id A81A021F9AA2 for ; Mon, 30 Sep 2013 12:27:33 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.90,1009,1371096000"; d="scan'208";a="6967927"
Received: from unknown (HELO scygexch10.cygnacom.com) ([10.4.60.26]) by ipedge2.cygnacom.com with ESMTP; 30 Sep 2013 15:27:33 -0400
Received: from SCYGEXCH10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62]) by scygexch10.cygnacom.com ([fe80::d8df:b0bd:28be:ad62%15]) with mapi id 14.02.0247.003; Mon, 30 Sep 2013 15:27:32 -0400
From: Santosh Chokhani 
To: Adam Langley , Kyle Hamilton 
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOus0hxRWfY2/0v0+mMH+5HrNeJpncmboAgAIQIACAAAYSwA==
Date: Mon, 30 Sep 2013 19:27:31 +0000
Message-ID: <4262AC0DB9856847A2D00EF817E81139086932@scygexch10.cygnacom.com>
References: <523E176F.3050304@gmail.com> <9A043F3CF02CD34C8E74AC1594475C7355674EE0@uxcn10-6.UoA.auckland.ac.nz> <20130926152757.15842.qmail@cr.yp.to>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.60.117.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 30 Sep 2013 19:27:38 -0000

Adam,

Simply copying RSA template and thus the key usage bits should not yield th=
e behavior you mention.  RSA certificates should set the key encipherment b=
it.  EC type certificates should not set that bit; the appropriate bit is k=
ey agreement.

So, either someone or software is doing that mental translation.

Products should not use a certificate for ECDH or DH key agreement if the k=
ey encipherment bit is set.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Adam =
Langley
Sent: Monday, September 30, 2013 11:03 AM
To: Kyle Hamilton
Cc: tls@ietf.org
Subject: Re: [TLS] Safe ECC usage

On Sun, Sep 29, 2013 at 3:33 AM, Kyle Hamilton  wrote:
> Or perhaps apply your (admittedly much better than mine) intellect to=20
> figure out how to create a single public key from a single private key=20
> which can be used for both signing and key derivation, thus permitting=20
> consolidation of both into a single X.509 Certificate structure?  The=20
> lack of this is in fact a major impediment to using self-signed=20
> certificates as containers for
> curve25519 public keys.

Current ECDSA deployments involve an ECDSA key in an X.509 certificate and =
ephemeral, ECDHE keys being generated by the server as needed.
These ephemeral keys are signed by the ECDSA key.

A similar design would have an Ed25519 key in the X.509 certificate and cur=
ve25519 used for ECDHE. I don't believe there's anything needed to get that=
 working save for switching out the algorithms.

(It is the case that some ECDSA certificates have both the signature and ke=
y derivation bits set in the key usage. This means that OpenSSL, at least, =
will allow it to be used for both ECDSA and fixed-ECDH. I'm not aware of an=
yone who actually wants that however. As far as I've seen, it's just the re=
sult of copying an RSA certificate template and forgetting to update the Ke=
yUsage.)

> Granted, I've been severely out of touch for quite a while, and it's=20
> possible that (e.g.) Ed25519 permits the use of the same public key in=20
> this manner (even though Ed25519 has a peculiar recordkeeping=20
> requirement which makes it less than ideal).

Ed25519 and curve25519 are the same curve so it is technically possible to =
use an Ed25519 public key, with a bit of thought, as a
curve25519 key. However, I wouldn't recommend it. TLS certainly doesn't nee=
d that.

> (Also, while I've hopefully got your attention, have you any plan to=20
> create an x64 ABI for Curve25519?  I'm currently having to use it via=20
> a COM wrapper I hacked up in C#, 64-bit processes calling via COM to a=20
> 32-bit process which exports only one function that COM doesn't=20
> mandate: curve25519(). This is insecure to COM-debug capable processes=20
> at the very least, as it requires that the caller provide the caller's=20
> private key over a public data bus.)

There are several implementations of curve25519 in SUPERCOP, including amd6=
4, asm versions (amd64-51); 64-bit, C code (donna_c64) and portable C code =
(ref10). It would be pretty simple to convert the
ref10 code to C# if you wished.


Cheers

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

From mrex@sap.com  Mon Sep 30 12:28:23 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C866321F9BD3 for ; Mon, 30 Sep 2013 12:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.182
X-Spam-Level: 
X-Spam-Status: No, score=-10.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jVqpN4LX6wbL for ; Mon, 30 Sep 2013 12:28:18 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1D83D21F9D44 for ; Mon, 30 Sep 2013 12:28:14 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8UJS5hp012136 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 30 Sep 2013 21:28:05 +0200 (MEST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C735567E500@uxcn10-6.UoA.auckland.ac.nz>
To: Peter Gutmann 
Date: Mon, 30 Sep 2013 21:28:05 +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: <20130930192805.1984A1A9C2@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "" 
Subject: Re: [TLS] New Algorithm identifier for EDH > 1024 bits?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Sep 2013 19:28:24 -0000

Peter Gutmann wrote:
> Phillip Hallam-Baker  writes:
> 
> >My understanding of the 1024 bit Ephemeral DH key issue is that it is not
> >currently possible to use longer keys because a certain number of deployed
> >Web servers will abort the connection if a client presents a longer key.
> >
> >Hmmm, wonder who made that decision...
> 
> Could that be because of all of the TLS_DHE_DSS_* suites, with DSS limited to
> 1024 bits so implementers also limited the matching DH to 1024 bits?  Just
> wondering what other reason there could possibly be for artificially limiting
> the size to 1024 bits.

The delay incurred by key generation maybe?

The app-supplied credentials are either RSA or DSA.  So for DHE,
_everything_ has to be newly generated after process start and potentially
in-band during the TLS handshake, unless the application caller has
written some code that does generation out-of-band and installs/updates
the DHE keying material regularly.

-Martin

From mrex@sap.com  Mon Sep 30 15:50:46 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB39421F8D12 for ; Mon, 30 Sep 2013 15:50:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.184
X-Spam-Level: 
X-Spam-Status: No, score=-10.184 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBpxvUwF6r4d for ; Mon, 30 Sep 2013 15:50:33 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D9C7321F8F09 for ; Mon, 30 Sep 2013 15:50:29 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r8UMoQXk026048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 Oct 2013 00:50:26 +0200 (MEST)
In-Reply-To: 
To: Kyle Hamilton 
Date: Tue, 1 Oct 2013 00:50:26 +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: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Sep 2013 22:50:49 -0000

Kyle Hamilton wrote:
> 
> That's all well and good, but perhaps should you try to figure out how your
> functions can in fact be used in such standards as TLS without having to
> resort to pulling hens' teeth?
> 
> Or perhaps apply your (admittedly much better than mine) intellect to
> figure out how to create a single public key from a single private key
> which can be used for both signing and key derivation, thus permitting
> consolidation of both into a single X.509 Certificate structure?  The lack
> of this is in fact a major impediment to using self-signed certificates as
> containers for curve25519 public keys.

I currently do not see any benefit from using EC for digital signatures,
but instead a huge amount of code, complexity and IPR issues (did you
look at the CertiCom idea how to charge?).

What I believe would be more attractive is an alternative to rfc4492
for ECDHE_RSA based on curve25519 (and _just_ curve25519), i.e.
a small number of new cipher suites and an additional ClientKeyExchange
and ServerKeyExchange variant specifically tailord for curve25519, so
that there are real benefits to a full-blown and generic rfc4492 TLS EC
crypto.

-Martin

From aerowolf@gmail.com  Mon Sep 30 20:36:57 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34C121F9A10 for ; Mon, 30 Sep 2013 20:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.983
X-Spam-Level: 
X-Spam-Status: No, score=-1.983 tagged_above=-999 required=5 tests=[AWL=0.617,  BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwCXcdRLHrEI for ; Mon, 30 Sep 2013 20:36:57 -0700 (PDT)
Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id CED1E21F923D for ; Mon, 30 Sep 2013 20:36:56 -0700 (PDT)
Received: by mail-wg0-f50.google.com with SMTP id f12so6659530wgh.17 for ; Mon, 30 Sep 2013 20:36:55 -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=MjhlFe+cN+6Nc8RiVIwBrrEN9LebN4CQeC8WIMrwKWM=; b=RfVhVl8B1MyxROSwokjSyp69X51Hx60vJOPe2OgYNpJjPawiI9rEEajGnYTXaqD2iS N2z8Qtrex3nk6WagfrHyOKirbAefLZocnMdsOmdl3+ylMtiVCARF9aSo09lg2IqoRI1j Mhoik7ZkqhBYYbc+JsyFWPU9ixTyocyPwKHp4GpIq6eZgEZpmC/ZWlpFQCrjHgGfxLY5 tWW0+Ht9GuJYvSvxtSYiV/cKOiPuPDBErm8Vw3o5ouf1pibfyZXdy2wlwgS+nR7z1yjS c7Us1bSsrIMkY2aPlpbzPCDc5M2NJ9NXneAZmdzqGkPe8jz+OjXveRwf4HDrxNod95MV IMXg==
MIME-Version: 1.0
X-Received: by 10.180.85.197 with SMTP id j5mr16634005wiz.22.1380598614633; Mon, 30 Sep 2013 20:36:54 -0700 (PDT)
Received: by 10.194.134.67 with HTTP; Mon, 30 Sep 2013 20:36:54 -0700 (PDT)
In-Reply-To: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
References:  <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
Date: Mon, 30 Sep 2013 20:36:54 -0700
Message-ID: 
From: Kyle Hamilton 
To: mrex 
Content-Type: multipart/alternative; boundary=f46d044480b700b59104e7a5aace
Cc: "tls@ietf.org" 
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Oct 2013 03:36:58 -0000

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

Martin,

When is the last time a purely mathematical algorithm was in fact
patentable and defensible?

Not to mention, Ed25519 is in fact a nonpatented EC signature capability,
but it is more a one-time authenticator than anything resembling a flat
signature.

Please stop being a shill for BULLRUN.

-Kyle H


On Mon, Sep 30, 2013 at 3:50 PM, Martin Rex  wrote:

> Kyle Hamilton wrote:
> >
> > That's all well and good, but perhaps should you try to figure out how
> your
> > functions can in fact be used in such standards as TLS without having to
> > resort to pulling hens' teeth?
> >
> > Or perhaps apply your (admittedly much better than mine) intellect to
> > figure out how to create a single public key from a single private key
> > which can be used for both signing and key derivation, thus permitting
> > consolidation of both into a single X.509 Certificate structure?  The
> lack
> > of this is in fact a major impediment to using self-signed certificates
> as
> > containers for curve25519 public keys.
>
> I currently do not see any benefit from using EC for digital signatures,
> but instead a huge amount of code, complexity and IPR issues (did you
> look at the CertiCom idea how to charge?).
>
> What I believe would be more attractive is an alternative to rfc4492
> for ECDHE_RSA based on curve25519 (and _just_ curve25519), i.e.
> a small number of new cipher suites and an additional ClientKeyExchange
> and ServerKeyExchange variant specifically tailord for curve25519, so
> that there are real benefits to a full-blown and generic rfc4492 TLS EC
> crypto.
>
> -Martin
>

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


Martin,

When is the last time a pur=
ely mathematical algorithm was in fact patentable and defensible?

Not to mention, Ed25519 is in fact a nonpatented EC signature capa=
bility, but it is more a one-time authenticator than anything resembling a =
flat signature.



Please stop being a shill for BULLRUN.

-Ky=
le H


On Mon, Sep 30, 2013 at 3:50 PM, Martin Rex <mrex@sap.com>=
 wrote:


Kyle Hamilton wrote:

>

> That's all well and good, but perhaps should you try to figure out=
 how your

> functions can in fact be used in such standards as TLS without having =
to

> resort to pulling hens' teeth?

>

> Or perhaps apply your (admittedly much better than mine) intellect to<=
br>
> figure out how to create a single public key from a single private key=


> which can be used for both signing and key derivation, thus permitting=


> consolidation of both into a single X.509 Certificate structure? =C2=
=A0The lack

> of this is in fact a major impediment to using self-signed certificate=
s as

> containers for curve25519 public keys.




I currently do not see any benefit from using EC for digital signatur=
es,

but instead a huge amount of code, complexity and IPR issues (did you

look at the CertiCom idea how to charge?).



What I believe would be more attractive is an alternative to rfc4492

for ECDHE_RSA based on curve25519 (and _just_ curve25519), i.e.

a small number of new cipher suites and an additional ClientKeyExchange

and ServerKeyExchange variant specifically tailord for curve25519, so

that there are real benefits to a full-blown and generic rfc4492 TLS EC

crypto.



-Martin





--f46d044480b700b59104e7a5aace--

From ynir@checkpoint.com  Mon Sep 30 22:14:25 2013
Return-Path: 
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 707C821F9A44 for ; Mon, 30 Sep 2013 22:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.383
X-Spam-Level: 
X-Spam-Status: No, score=-10.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QXNti+EblbG for ; Mon, 30 Sep 2013 22:14:19 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 251DE21F9A6C for ; Mon, 30 Sep 2013 22:14:18 -0700 (PDT)
Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r915E9G9007390; Tue, 1 Oct 2013 08:14:09 +0300
X-CheckPoint: {524A5A21-13-1B221DC2-1FFFF}
Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.30]) by IL-EX10.ad.checkpoint.com ([169.254.2.92]) with mapi id 14.02.0347.000; Tue, 1 Oct 2013 08:14:09 +0300
From: Yoav Nir 
To: "" 
Thread-Topic: [TLS] Safe ECC usage
Thread-Index: AQHOus0om0uHYDyqy0CSy5O2MDQzFJncJGEAgAKSogCAAGtCAA==
Date: Tue, 1 Oct 2013 05:14:09 +0000
Message-ID: 
References: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
In-Reply-To: <20130930225026.5DBF11A9C3@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.31.20.43]
x-kse-antivirus-interceptor-info: protection disabled
Content-Type: text/plain; charset="Windows-1252"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" , Kyle Hamilton 
Subject: Re: [TLS] Safe ECC usage
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 01 Oct 2013 05:14:25 -0000

On Oct 1, 2013, at 1:50 AM, Martin Rex  wrote:

>=20
> I currently do not see any benefit from using EC for digital signatures,

Other than certificate size and the speed of making those calculations?  Re=
ally, try "openssl speed rsa2048 ecdsap256" on any Linux or Mac machine.

> but instead a huge amount of code, complexity and IPR issues (did you
> look at the CertiCom idea how to charge?).

Yes, I have: "If the standard is adopted, Patent Holder will not assert any=
 claims of any patents owned or controlled by the Patent Holder against any=
 party for making, using, selling importing or offering for sale a product =
that implements the Standard=85" (weird capitalization theirs, not mine)

Also, there's RFC 6090 on how you can do all the ECC operations with 1994 t=
echnology.

Also, public CAs, a notoriously careful bunch, have started issuing ECC cer=
ts, all browsers have ECC ciphersuites as does OpenSSL and others. Clearly =
the market is not afraid of the IPR issue.

> What I believe would be more attractive is an alternative to rfc4492
> for ECDHE_RSA based on curve25519 (and _just_ curve25519),

IANAL and neither are you. What makes you think that the IPR issues apply t=
o P-256 more than they do to Curve25519?

> i.e.
> a small number of new cipher suites and an additional ClientKeyExchange
> and ServerKeyExchange variant specifically tailord for curve25519, so
> that there are real benefits to a full-blown and generic rfc4492 TLS EC
> crypto.

ECDHE_RSA is slower than plain RSA. ECDHE_ECDSA is faster. Once you've dipp=
ed your toe in the ECC pool, there's no reason not to have it in the signat=
ure as well.

Yoav