From fweimer@bfk.de Sat Oct 1 09:13:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2361E21F8E0F for ; Sat, 1 Oct 2011 09:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.929 X-Spam-Level: X-Spam-Status: No, score=-1.929 tagged_above=-999 required=5 tests=[AWL=0.320, 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 J2KuxW-7yFeP for ; Sat, 1 Oct 2011 09:13:56 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 65A8F21F8E10 for ; Sat, 1 Oct 2011 09:13:56 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RA2F7-0004hf-9q; Sat, 01 Oct 2011 16:16:49 +0000 Received: by bfk.de with local id 1RA2F7-0001W0-6a; Sat, 01 Oct 2011 16:16:49 +0000 From: Florian Weimer To: mrex@sap.com References: <201109261642.p8QGgHet015841@fs4113.wdf.sap.corp> Date: Sat, 01 Oct 2011 16:16:49 +0000 In-Reply-To: <201109261642.p8QGgHet015841@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 26 Sep 2011 18:42:17 +0200 (MEST)") Message-ID: <82y5x4sn4e.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proposal for detecting fraudulent certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2011 16:13:57 -0000 * Martin Rex: > Florian Weimer wrote: >>=20 >> * Martin Rex: >>=20 >> > Having the client send _only_ the servers certificate and not the >> > entire certificate path should IMO be sufficient for the purpose you >> > outline. >>=20 >> I don't think it is. The certificate itself is not proof of fraud if an >> intermediate CA is involved. More importantly, you cannot tell an >> intercepting corporate proxy (whose certificate is not rooted in the >> browser PKI) from a certificate which is. > > The Web Server certificate nails down the public&private key for the > server. If a MITM has access to the servers private key, then > you've lost already, because that MITM can perform a perfect > impersonation for the client (the only thing that the MITM could > not do is a client-certificate authentication to the real server > (unless the real server lacks rfc5746 renegotiation protection). Let me rephrase. I'm concerned that without the full chain, server operators dealing with larger user bases will drown in reports of wrong server certificates, some of them created by Fiddler, some of them by HTTPS-aware AV-scanning web proxies. I'm not sure if these cases are interesting. The full chain, on the other hand, provides a cryptographi proof how the server certificate is rooted in the browser PKI. If it is properly rooted, but is not yours, you definitely have got a problem. >> > I don't know why you think the 64 KByte TLS extension size limit would >> > be a problem. >>=20 >> The wire format allows for larger server chains (up to 16 MB). This >> could be abused to bypass detection (just use a certificate with a >> logotype extension). I just felt I had to say something about that. > > The client could decide to not talk to such TLS servers at all > (while theoretically not "standards compliant", it is what a > non-marginal fraction of the installed base is doing...) I considered that. But I don't think we need any more of that. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer@bfk.de Sat Oct 1 09:19:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433A021F8FC9 for ; Sat, 1 Oct 2011 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.306, 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 9LkaylQVkB1w for ; Sat, 1 Oct 2011 09:19:47 -0700 (PDT) Received: from mx01.bfk.de (mx01.bfk.de [193.227.124.2]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3A21F8F87 for ; Sat, 1 Oct 2011 09:19:47 -0700 (PDT) Received: from mx00.int.bfk.de ([10.119.110.2]) by mx01.bfk.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) id 1RA2Kn-0004zM-Sm; Sat, 01 Oct 2011 16:22:41 +0000 Received: by bfk.de with local id 1RA2Kn-0003He-Pu; Sat, 01 Oct 2011 16:22:41 +0000 From: Florian Weimer To: Eric Rescorla References: Date: Sat, 01 Oct 2011 16:22:41 +0000 In-Reply-To: (Eric Rescorla's message of "Fri, 23 Sep 2011 18:00:10 -0700") Message-ID: <82sjncsmum.fsf@mid.bfk.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paul Hoffman , tls@ietf.org Subject: Re: [TLS] Duong and Rizzo, the actual attack X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 01 Oct 2011 16:19:48 -0000 * Eric Rescorla: > I'm also not Adam Langley, but here's my writeup: > http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.h= tml I think a semi-passive eavesdropper (which is present under this threat model) can bypass the same-origin protection in practically all cases. An attacker which can route requests through the browser and can otherwise only observe traffic, but not inject it, seems a rather unrealistic scenario to me. If you can observe traffic, clairvoyant DNS spoofing should be possible, and with that, SOP falls completely. The Oracle browser plugin for Java some folks seem to concentrate on is probably not that relevant. Anyway, is there are full writeup? The copies of the paper I've seen still has many blank sections. --=20 Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra=DFe 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Nilesh.Tayade@netscout.com Sun Oct 2 22:34:50 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AC221F8505 for ; Sun, 2 Oct 2011 22:34:50 -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 Gh63k4wbj+2I for ; Sun, 2 Oct 2011 22:34:49 -0700 (PDT) Received: from exprod6og110.obsmtp.com (exprod6og110.obsmtp.com [64.18.1.25]) by ietfa.amsl.com (Postfix) with SMTP id 55B6C21F8508 for ; Sun, 2 Oct 2011 22:34:48 -0700 (PDT) Received: from nsmailfe2k3.netscout.com ([12.187.89.175]) (using TLSv1) by exprod6ob110.postini.com ([64.18.5.12]) with SMTP; Sun, 02 Oct 2011 22:37:51 PDT Received: from nsmail.netscout.com ([192.168.39.90]) by nsmailfe2k3.netscout.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Oct 2011 01:37:27 -0400 Received: from [172.16.32.29] ([172.16.32.29]) by nsmail.netscout.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 3 Oct 2011 01:37:26 -0400 Message-ID: <4E894A15.3010500@netscout.com> Date: Mon, 03 Oct 2011 11:07:25 +0530 From: nilesh Organization: NetScout User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Joshua Davies References: <4E818EF3.4090206@netscout.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Oct 2011 05:37:27.0090 (UTC) FILETIME=[8902C120:01CC818E] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.800.1017-18422.004 X-TM-AS-Result: No--7.844000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: tls@ietf.org Subject: Re: [TLS] Query regarding generating client_write_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, 03 Oct 2011 05:34:50 -0000 On Friday 30 September 2011 07:52 PM, Joshua Davies wrote: > On the contrary - the entire SSL handshake is sent in the clear - this is > why its important that both sides keep a running digest of the entire > handshake sequence and compare notes at the end, after encryption keys have > been exchanged (see RFC 2246, 7.4.9). The first encrypted message in the > handshake is the "finished" message. If you're using Wireshark/Ethereal to > sniff packets, it will decode the protocol details for you - if you're using > a non-standard port (say, testing on 8443), you'll need to select > analyze->decode as->SSL. Thanks. Yes, the Wireshark decoded it after the traces were saved. -- Thanks, Nilesh From jsalowey@cisco.com Mon Oct 3 09:21:44 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31BA21F8BE7 for ; Mon, 3 Oct 2011 09:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.508 X-Spam-Level: X-Spam-Status: No, score=-103.508 tagged_above=-999 required=5 tests=[AWL=-0.909, 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 sfxP4Dsf1pYq for ; Mon, 3 Oct 2011 09:21:42 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id D520721F8B62 for ; Mon, 3 Oct 2011 09:21:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=6130; q=dns/txt; s=iport; t=1317659085; x=1318868685; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=e1TcSvslhqGJwEwWZitxb3ExYQb6LOTFVxTXq5CkiKQ=; b=lh7NSRMsWGhzg0Zj+bYtdHAfQPfncOqu5z1pzLC8FpQFf2HiQ4xgDzyr FR9jXcSC1wG2sL7uVTEXaVDvwY33UJRCNNfSY+cFX2MepOawafRH2V4W6 iRIf/UnKuYxkgsBoxjayxy7DtOSL+hmMHozytK6ivUwK3XuRn4+zlZGBC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAOngiU6rRDoI/2dsb2JhbABBqAKBBYFsAScxDoE+NYdfmx0BnVqGQGEEh3eLaYUljDk X-IronPort-AV: E=Sophos;i="4.68,480,1312156800"; d="scan'208";a="5642248" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Oct 2011 16:24:45 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93GOhVn025946; Mon, 3 Oct 2011 16:24:44 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Oct 2011 09:25:03 -0700 Message-Id: To: Sean Turner Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: tls@ietf.org Subject: [TLS] Proto write-up for draft-ietf-tls-dtls-heartbeat-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 16:21:44 -0000 Below is the proto write-up for draft-ietf-tls-dtls-heartbeat-03 which = is ready for consideration by the IESG for publication as an RFC. =20 Cheers, Joe (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the=20 document and, in particular, does he or she believe this=20 version is ready for forwarding to the IESG for publication?=20 I, Joe Salowey, TLS working group co-chair, am the Document Shepherd for = this document. I have personally reviewed this version of the document = and I believe it to be ready for forwarding to the IESG for publication. = =20 (1.b) Has the document had adequate review both from key WG members=20 and from key non-WG members? Does the Document Shepherd have=20 any concerns about the depth or breadth of the reviews that=20 have been performed? =20 The document has had adequate review from key WG and non-WG members. = The document Shepherd does not have concerns about the depth or breadth = of the reviews. The document has been reviewed by the transport = directorate.=20 (1.c) Does the Document Shepherd have concerns that the document=20 needs more review from a particular or broader perspective,=20 e.g., security, operational complexity, someone familiar with=20 AAA, internationalization or XML?=20 No. (1.d) Does the Document Shepherd have any specific concerns or=20 issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he=20 or she is uncomfortable with certain parts of the document, or=20= has concerns whether there really is a need for it. In any=20 event, if the WG has discussed those issues and has indicated=20 that it still wishes to advance the document, detail those=20 concerns here. Has an IPR disclosure related to this document=20 been filed? If so, please include a reference to the=20 disclosure and summarize the WG discussion and conclusion on=20 this issue.=20 No specific concerns with the document. There has not been an IPR = disclosure for the document.=20 (1.e) How solid is the WG consensus behind this document? Does it=20 represent the strong concurrence of a few individuals, with=20 others being silent, or does the WG as a whole understand and=20 agree with it? =20 There is broad support within the working group for this document.=20 (1.f) Has anyone threatened an appeal or otherwise indicated extreme=20= discontent? If so, please summarise the areas of conflict in=20 separate email messages to the Responsible Area Director. (It=20 should be in a separate email because this questionnaire is=20 entered into the ID Tracker.)=20 No. (1.g) Has the Document Shepherd personally verified that the=20 document satisfies all ID nits? (See the Internet-Drafts = Checklist and=20 http://tools.ietf.org/tools/idnits/). Boilerplate checks are=20 not enough; this check needs to be thorough. Has the document=20 met all formal review criteria it needs to, such as the MIB=20 Doctor, media type and URI type reviews?=20 Yes. (1.h) Has the document split its references into normative and=20 informative? Are there normative references to documents that=20 are not ready for advancement or are otherwise in an unclear=20 state? If such normative references exist, what is the=20 strategy for their completion? Are there normative references=20 that are downward references, as described in [RFC3967]? If=20 so, list these downward references to support the Area=20 Director in the Last Call procedure for them [RFC3967].=20 The document has appropriate references.=20 (1.i) Has the Document Shepherd verified that the document IANA=20 consideration section exists and is consistent with the body=20 of the document? If the document specifies protocol=20 extensions, are reservations requested in appropriate IANA=20 registries? Are the IANA registries clearly identified? If=20 the document creates a new registry, does it define the=20 proposed initial contents of the registry and an allocation=20 procedure for future registrations? Does it suggest a=20 reasonable name for the new registry? See [RFC5226]. If the=20 document describes an Expert Review process has Shepherd=20 conferred with the Responsible Area Director so that the IESG=20 can appoint the needed Expert during the IESG Evaluation?=20 The IANA considerations are complete. (1.j) Has the Document Shepherd verified that sections of the=20 document that are written in a formal language, such as XML=20 code, BNF rules, MIB definitions, etc., validate correctly in=20 an automated checker?=20 Not applicable. (1.k) The IESG approval announcement includes a Document=20 Announcement Write-Up. Please provide such a Document=20 Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval=20 announcement contains the following sections:=20 Technical Summary=20 The Heartbeat Extension provides a new protocol for TLS/DTLS allowing = the usage of keep-alive functionality without performing a renegotiation = and a basis for path maximum transmission unit (PMTU) discovery for = DTLS. Working Group Summary=20 The is broad working group support for this document. =20 Document Quality=20 The document has been reviewed by the transport area directorate and = feedback from that review was incorporated into the document. Several = implementations are planned to enhance the support for DTLS to protect = management and other UDP protocols.=20 From Nilesh.Tayade@netscout.com Tue Oct 4 04:35:42 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9182D21F8CB0 for ; Tue, 4 Oct 2011 04:35:42 -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 xzfG-KhWAGpE for ; Tue, 4 Oct 2011 04:35:42 -0700 (PDT) Received: from exprod6ob111.obsmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by ietfa.amsl.com (Postfix) with SMTP id EF23921F8CAE for ; Tue, 4 Oct 2011 04:35:41 -0700 (PDT) Received: from nsmailfe2k3.netscout.com ([12.187.89.175]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP; Tue, 04 Oct 2011 04:38:46 PDT Received: from nsmail.netscout.com ([192.168.39.90]) by nsmailfe2k3.netscout.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Oct 2011 07:38:38 -0400 Received: from [172.16.32.29] ([172.16.32.29]) by nsmail.netscout.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 07:38:38 -0400 Message-ID: <4E8AF03D.2080702@netscout.com> Date: Tue, 04 Oct 2011 17:08:37 +0530 From: nilesh Organization: NetScout User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Oct 2011 11:38:38.0273 (UTC) FILETIME=[28749B10:01CC828A] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.800.1017-18424.004 X-TM-AS-Result: No--2.483500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [TLS] About the key block generation for different 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: Tue, 04 Oct 2011 11:35:42 -0000 Hi, In case of SSL/TLS we generate the master_secret and then the key_block. The size of the key block depends upon the cipher suit that is negotiated. Do we have any reference where I can understand the fields in key_block? E.g. I could identify that For AES_256_CBC_SHA we need - 2 * 32 bytes of keys and 2 * 20 bytes of MAC. For 3DES_EDE_CBC_SHA we need - 2 * 24bytes of keys, 2 * 20bytes of MAC and 2 * 8bytes of IV. So based on the above information I can generate 104bytes of key_block for these ciphers and extract the required keys. So for AES_256_CBC_SHA- key_block[0..19] - MAC for client, key_block[20..39] - MAC for server. key_block[40..71] - client write key and key_block[72..104] - server write key. Could someone please advice any reference on how to get the key_block details for a give cipher suit? -- Thanks, Nilesh From marsh@extendedsubset.com Tue Oct 4 08:04:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA9E21F8C0D for ; Tue, 4 Oct 2011 08:04:23 -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 bilKalaj-LWG for ; Tue, 4 Oct 2011 08:04:22 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56021F8BEF for ; Tue, 4 Oct 2011 08:04:22 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RB6ad-000MnW-G3; Tue, 04 Oct 2011 15:07:27 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id E1D4863BF; Tue, 4 Oct 2011 15:07:25 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19JallqZ2F0PnSYPaXxdrrkjYn2S7UJqDo= Message-ID: <4E8B212D.5090305@extendedsubset.com> Date: Tue, 04 Oct 2011 10:07:25 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: nilesh References: <4E8AF03D.2080702@netscout.com> In-Reply-To: <4E8AF03D.2080702@netscout.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] About the key block generation for different 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: Tue, 04 Oct 2011 15:04:23 -0000 On 10/04/2011 06:38 AM, nilesh wrote: > > Could someone please advice any reference on how to get the key_block > details for a give cipher suit? http://tools.ietf.org/html/rfc2246 TLS 1.0: > 6.3. Key calculation ... > Then the key_block is > partitioned as follows: > > client_write_MAC_secret[SecurityParameters.hash_size] > server_write_MAC_secret[SecurityParameters.hash_size] > client_write_key[SecurityParameters.key_material_length] > server_write_key[SecurityParameters.key_material_length] > client_write_IV[SecurityParameters.IV_size] > server_write_IV[SecurityParameters.IV_size] > > The client_write_IV and server_write_IV are only generated for non- > export block ciphers. For exportable block ciphers, the > initialization vectors are generated later, as described below. Any > extra key_block material is discarded. - Marsh From iesg-secretary@ietf.org Tue Oct 4 17:48:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D7621F8B73; Tue, 4 Oct 2011 17:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 dn1mQRwENDdM; Tue, 4 Oct 2011 17:48:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DF321F8B57; Tue, 4 Oct 2011 17:48:42 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111005004842.28108.96901.idtracker@ietfa.amsl.com> Date: Tue, 04 Oct 2011 17:48:42 -0700 Cc: tls@ietf.org Subject: [TLS] Last Call: (Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 00:48:43 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-18. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocol. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path maximum transmission unit (PMTU) discovery for DTLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/ No IPR declarations have been submitted directly on this I-D. From dharkins@lounge.org Tue Oct 4 23:09:09 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8BC21F8B08 for ; Tue, 4 Oct 2011 23:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 iU1ZbxST6tmr for ; Tue, 4 Oct 2011 23:09:09 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 11A4521F8AD8 for ; Tue, 4 Oct 2011 23:09:08 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D7E591022404C; Tue, 4 Oct 2011 23:12:15 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 4 Oct 2011 23:12:15 -0700 (PDT) Message-ID: Date: Tue, 4 Oct 2011 23:12:15 -0700 (PDT) From: "Dan Harkins" To: tls@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dhalasz@intwineenergy.com Subject: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 06:09:09 -0000 Hi, I just uploaded a -00 draft that defines a new key exchange for TLS that does not require certificates-- authentication using a simple password only. It can be found at: http://tools.ietf.org/html/draft-harkins-tls-pwd-00 Please take a look. The authors solicit comments. regards, Dan. From Nilesh.Tayade@netscout.com Tue Oct 4 23:12:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4E121F84FB for ; Tue, 4 Oct 2011 23:12:22 -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 ng2QUJEFYY3O for ; Tue, 4 Oct 2011 23:12:21 -0700 (PDT) Received: from exprod6og114.obsmtp.com (exprod6og114.obsmtp.com [64.18.1.33]) by ietfa.amsl.com (Postfix) with SMTP id 17E5521F84F5 for ; Tue, 4 Oct 2011 23:12:21 -0700 (PDT) Received: from nsmailfe2k3.netscout.com ([12.187.89.175]) (using TLSv1) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP; Tue, 04 Oct 2011 23:15:28 PDT Received: from nsmail.netscout.com ([192.168.39.90]) by nsmailfe2k3.netscout.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Oct 2011 02:15:24 -0400 Received: from [172.16.32.29] ([172.16.32.29]) by nsmail.netscout.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 5 Oct 2011 02:15:24 -0400 Message-ID: <4E8BF5FC.1000405@netscout.com> Date: Wed, 05 Oct 2011 11:45:24 +0530 From: nilesh Organization: NetScout User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: Marsh Ray References: <4E8AF03D.2080702@netscout.com> <4E8B212D.5090305@extendedsubset.com> In-Reply-To: <4E8B212D.5090305@extendedsubset.com> Content-Type: multipart/mixed; boundary="------------050203090707000300020107" X-OriginalArrivalTime: 05 Oct 2011 06:15:24.0806 (UTC) FILETIME=[2B762260:01CC8326] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.800.1017-18426.004 X-TM-AS-Result: No--18.147300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: tls@ietf.org Subject: Re: [TLS] About the key block generation for different 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, 05 Oct 2011 06:12:22 -0000 This is a multi-part message in MIME format. --------------050203090707000300020107 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On Tuesday 04 October 2011 08:37 PM, Marsh Ray wrote: > On 10/04/2011 06:38 AM, nilesh wrote: >> >> Could someone please advice any reference on how to get the key_block >> details for a give cipher suit? > > http://tools.ietf.org/html/rfc2246 TLS 1.0: >> 6.3. Key calculation > ... >> Then the key_block is >> partitioned as follows: >> >> client_write_MAC_secret[SecurityParameters.hash_size] >> server_write_MAC_secret[SecurityParameters.hash_size] >> client_write_key[SecurityParameters.key_material_length] >> server_write_key[SecurityParameters.key_material_length] >> client_write_IV[SecurityParameters.IV_size] >> server_write_IV[SecurityParameters.IV_size] >> >> The client_write_IV and server_write_IV are only generated for non- >> export block ciphers. For exportable block ciphers, the >> initialization vectors are generated later, as described below. Any >> extra key_block material is discarded. Thanks. I had gone through that, but couldn't really get reference to the cipher suites with the key length. Attached is the file what I was exactly looking for. Thanks to Joshua Davies for the compilation. > > - Marsh -- Thanks, Nilesh --------------050203090707000300020107 Content-Type: text/plain; name="cipher_suites_list.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="cipher_suites_list.txt" [Cipher suit, digest size, key length, IV size] TLS_NULL_WITH_NULL_NULL, 0, 0, 0 TLS_RSA_WITH_NULL_MD5, 0, 0, 4 * sizeof(int) TLS_RSA_WITH_NULL_SHA, 0, 0, 5 * sizeof(int) TLS_RSA_EXPORT_WITH_RC4_40_MD5, 0, 5, 4 * sizeof(int) TLS_RSA_WITH_RC4_128_MD5, 0, 16, 4 * sizeof(int) TLS_RSA_WITH_RC4_128_SHA, 0, 16, 5 * sizeof(int) TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5, 0, 0, 4 * sizeof(int) TLS_RSA_WITH_IDEA_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_RSA_WITH_DES_CBC_SHA, 8, 8, 5 * sizeof(int) TLS_RSA_WITH_3DES_EDE_CBC_SHA, 8, 24, 5 * sizeof(int) TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_DSS_WITH_DES_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA, 8, 24, 5 * sizeof(int) TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_RSA_WITH_DES_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DHE_DSS_WITH_DES_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DHE_RSA_WITH_DES_CBC_SHA, 8, 8, 5 * sizeof(int) TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_anon_EXPORT_WITH_RC4_40_MD5, 0, 0, 4 * sizeof(int) TLS_DH_anon_WITH_RC4_128_MD5, 0, 0, 4 * sizeof(int) TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_anon_WITH_DES_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_DH_anon_WITH_3DES_EDE_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_WITH_DES_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_WITH_3DES_EDE_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_WITH_RC4_128_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_WITH_IDEA_CBC_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_WITH_DES_CBC_MD5, 0, 0, 4 * sizeof(int) TLS_KRB5_WITH_3DES_EDE_CBC_MD5, 0, 0, 4 * sizeof(int) TLS_KRB5_WITH_RC4_128_MD5, 0, 0, 4 * sizeof(int) TLS_KRB5_WITH_IDEA_CBC_MD5, 0, 0, 4 * sizeof(int) TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_EXPORT_WITH_RC4_40_SHA, 0, 0, 5 * sizeof(int) TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5, 0, 0, 4 * sizeof(int) TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5, 0, 0, 4 * sizeof(int) TLS_KRB5_EXPORT_WITH_RC4_40_MD5, 0, 0, 4 * sizeof(int) TLS_RSA_WITH_AES_128_CBC_SHA, 16, 16, 5 * sizeof(int) TLS_DH_DSS_WITH_AES_128_CBC_SHA, 16, 16, 5 * sizeof(int) TLS_DH_RSA_WITH_AES_128_CBC_SHA, 16, 16, 5 * sizeof(int) TLS_DHE_DSS_WITH_AES_128_CBC_SHA, 16, 16, 5 * sizeof(int) TLS_DHE_RSA_WITH_AES_128_CBC_SHA, 16, 16, 5 * sizeof(int) TLS_DH_anon_WITH_AES_128_CBC_SHA, 16, 16, 5 * sizeof(int) TLS_RSA_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) TLS_DH_DSS_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) TLS_DH_RSA_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) TLS_DHE_DSS_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) TLS_DHE_RSA_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) TLS_DH_anon_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) --------------050203090707000300020107-- From turners@ieca.com Wed Oct 5 06:31:00 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3622821F8CA5 for ; Wed, 5 Oct 2011 06:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 FzmbUq8545lH for ; Wed, 5 Oct 2011 06:30:59 -0700 (PDT) Received: from nm15.access.bullet.mail.mud.yahoo.com (nm15.access.bullet.mail.mud.yahoo.com [66.94.237.216]) by ietfa.amsl.com (Postfix) with SMTP id A86AA21F8C9F for ; Wed, 5 Oct 2011 06:30:59 -0700 (PDT) Received: from [66.94.237.127] by nm15.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Oct 2011 13:34:05 -0000 Received: from [98.139.221.43] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 05 Oct 2011 13:34:05 -0000 Received: from [127.0.0.1] by smtp105.biz.mail.bf1.yahoo.com with NNFMP; 05 Oct 2011 13:34:04 -0000 X-Yahoo-Newman-Id: 990753.775.bm@smtp105.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BiX0IbUVM1kDwRunS7NgkhLjKiuceI8k3h07oaBNnvJd9yG D8ivqSYtnIlN6VPLrL99JkqmOO7i3T2u.MGhyTH9AOXKzL0LPlHdK1pgo7Se y6v9VBAwTn7albxzZuVqPYVwTU2gQSdbypnRHjw9ltbTApuZMpT1E2Td1vDE yeunKi0qMvTYvjVR3BsIM8bVpRCrjSzvutBQPvnq1HH6VXmN4D_iCdB8ckzc bWlOMBxbnG9fCg3uLf2PHnAhb_pY0ZXoI_rVrv8G2Q1D2_4crDiPTLPuv8k4 Q1pmcPxbSBrimICVFOL4XQEYXntf..JopCkRlzygEBnluj0sJxmpkhw1WjwR 8lviFJZ7abxRRjaYKXLaFLyhXGf1ggvHDNTgwB42ae9peM1elvioLLjEagAL d38KAXr7rgFTXJiYS X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ Received: from thunderfish.local (turners@71.191.1.163 with plain) by smtp105.biz.mail.bf1.yahoo.com with SMTP; 05 Oct 2011 06:34:04 -0700 PDT Message-ID: <4E8C5CCC.5040709@ieca.com> Date: Wed, 05 Oct 2011 09:34:04 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20111005004842.28108.96901.idtracker@ietfa.amsl.com> In-Reply-To: <20111005004842.28108.96901.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Last Call: (Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 13:31:00 -0000 I've also placed this draft on the 11/03 IESG telechat. spt On 10/4/11 8:48 PM, The IESG wrote: > > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'Transport Layer Security (TLS) and Datagram Transport Layer Security > (DTLS) Heartbeat Extension' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2011-10-18. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes the Heartbeat Extension for the Transport > Layer Security (TLS) and Datagram Transport Layer Security (DTLS) > protocol. > > The Heartbeat Extension provides a new protocol for TLS/DTLS allowing > the usage of keep-alive functionality without performing a > renegotiation and a basis for path maximum transmission unit (PMTU) > discovery for DTLS. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-tls-dtls-heartbeat/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From marsh@extendedsubset.com Wed Oct 5 07:00:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E61B21F8D76 for ; Wed, 5 Oct 2011 07:00:02 -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 z5m5h4aioT7t for ; Wed, 5 Oct 2011 07:00:01 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3213921F8D6F for ; Wed, 5 Oct 2011 06:59:58 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RBS3u-000Mbw-26; Wed, 05 Oct 2011 14:03:06 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 53B1163BF; Wed, 5 Oct 2011 14:03:03 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18qYonbK2BRuaYZtkx4EYGELQYz4gvCvys= Message-ID: <4E8C6397.4050608@extendedsubset.com> Date: Wed, 05 Oct 2011 09:03:03 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: nilesh References: <4E8AF03D.2080702@netscout.com> <4E8B212D.5090305@extendedsubset.com> <4E8BF5FC.1000405@netscout.com> In-Reply-To: <4E8BF5FC.1000405@netscout.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] About the key block generation for different 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, 05 Oct 2011 14:00:02 -0000 On 10/05/2011 01:15 AM, nilesh wrote: > > Thanks. I had gone through that, but couldn't really get reference to > the cipher suites with the key length. > Attached is the file what I was exactly looking for. > > Thanks to Joshua Davies for the compilation. > [Cipher suit, digest size, key length, IV size] > TLS_RSA_WITH_AES_256_CBC_SHA, 16, 32, 5 * sizeof(int) No way that could be right. But you have a software problem at this point, which is not so relevant for the TLS WG. (Ping me off-list if you need a hint :-) - Marsh From geoffk@geoffk.org Wed Oct 5 14:06:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617931F0C6F for ; Wed, 5 Oct 2011 14:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 ycJC6vJ3U9aN for ; Wed, 5 Oct 2011 14:06:16 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id F0B361F0C5F for ; Wed, 5 Oct 2011 14:06:15 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E492933D1D7; Wed, 5 Oct 2011 21:09:19 +0000 (UTC) Sender: geoffk@localhost.localdomain To: "Dan Harkins" References: From: Geoffrey Keating Date: 05 Oct 2011 14:09:19 -0700 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:06:16 -0000 "Dan Harkins" writes: > http://tools.ietf.org/html/draft-harkins-tls-pwd-00 > > Please take a look. The authors solicit comments. It would be helpful to have a comparison between this proposal and RFC5054, since both protocols appear to have the same aim ("secure authentication using only a simple, low-entropy, password"). Some features of RFC5054 I noticed that could be used to improve this draft are: - RFC5054 requires that the server store only the 'verifier', while this protocol appears to require storing the plaintext password. There doesn't seem to be any discussion on the risks of storing the plaintext password or any mitigations (for example, using a salted hash of the password instead of the password directly). - RFC5054 already specifies an extension for the user name. I would suggest using the same extension for this protocol rather than creating a new one. - RFC5054 has test vectors, this draft doesn't. From dharkins@lounge.org Wed Oct 5 16:03:56 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FD111E8082 for ; Wed, 5 Oct 2011 16:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.194 X-Spam-Level: X-Spam-Status: No, score=-6.194 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 fUk7tJkZEAh0 for ; Wed, 5 Oct 2011 16:03:56 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E9E0821F8CEE for ; Wed, 5 Oct 2011 16:03:55 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D390F1022404C; Wed, 5 Oct 2011 16:07:04 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Oct 2011 16:07:05 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Wed, 5 Oct 2011 16:07:05 -0700 (PDT) From: "Dan Harkins" To: "Geoffrey Keating" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 23:03:56 -0000 Hello, On Wed, October 5, 2011 2:09 pm, Geoffrey Keating wrote: > "Dan Harkins" writes: > >> http://tools.ietf.org/html/draft-harkins-tls-pwd-00 >> >> Please take a look. The authors solicit comments. > > It would be helpful to have a comparison between this proposal and > RFC5054, since both protocols appear to have the same aim ("secure > authentication using only a simple, low-entropy, password"). TLS is rife with drafts and RFCs that have the same aim but go about it differently. > Some features of RFC5054 I noticed that could be used to improve this > draft are: > > - RFC5054 requires that the server store only the 'verifier', while > this protocol appears to require storing the plaintext password. > There doesn't seem to be any discussion on the risks of storing the > plaintext password or any mitigations (for example, using a salted > hash of the password instead of the password directly). Yes, I got another comment to add something to the security considerations regarding compromise of the client and server. This draft does not propose any protection against server compromise the way RFC 5054 does. On the other hand, with this scheme one is not required to fix a particular domain parameter set to a user at password provisioning time. This allows for the choice of domain parameter set to be based on the particular ciphersuite the server is proposing to use (and removes a security critical decision from someone-- the person provisioning the password on the server-- who might not have the competence to make that decision). We could add some protection against server compromise by salting the password when it is provisioned and sending the salt in the ServerKeyExchange. The drawback to this is that the salting technique has to be determined at provisioning time, but that's probably not that big of a deal as the technique has no bearing on the security of the underlying key exchange. Thanks for the suggestion! > - RFC5054 already specifies an extension for the user name. I would > suggest using the same extension for this protocol rather than > creating a new one. It's named "srp" though which makes it less desirable. We'll note your suggestion but unless there is strong desire by the WG to change this we'd like to keep it as is. There's 65k extensions available so exhaustion of this resource is unlikely. > - RFC5054 has test vectors, this draft doesn't. Another good suggestion. We'll add some. thanks, Dan. From jmdesp@free.fr Wed Oct 5 17:36:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADCE1F0C4A for ; Wed, 5 Oct 2011 17:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.745, 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 3KURNeQGEnw5 for ; Wed, 5 Oct 2011 17:36:10 -0700 (PDT) Received: from smtp1-g21.free.fr (unknown [IPv6:2a01:e0c:1:1599::10]) by ietfa.amsl.com (Postfix) with ESMTP id DD3081F0C41 for ; Wed, 5 Oct 2011 17:36:08 -0700 (PDT) Received: from [IPv6:2a01:e35:2f1a:f7d0:61eb:1dd1:88b2:6cc5] (unknown [IPv6:2a01:e35:2f1a:f7d0:61eb:1dd1:88b2:6cc5]) by smtp1-g21.free.fr (Postfix) with ESMTP id 6A0AA9400FD; Thu, 6 Oct 2011 02:39:10 +0200 (CEST) Message-ID: <4E8CF8AD.9020509@free.fr> Date: Thu, 06 Oct 2011 02:39:09 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0a2) Gecko/20111002 Thunderbird/9.0a2 MIME-Version: 1.0 To: Dan Harkins , tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 00:36:10 -0000 On 06/10/2011 01:07, Dan Harkins wrote: > TLS is rife with drafts and RFCs that have the same aim but go about > it differently Even if there might indeed be quite a few like that in the TLS case, it's still against IETF policy. There should be at least some specific advantage to your approach over the other one (or enough existing usage to justify documenting it through an experimental RFC), which is far from being proved for now. SRP has the advantage over the other PAKE to be covered by a defensive patent with a royalty free license, which makes it safer to use. If needed, it's also actually very easy to use SRP in symmetric mode, regenerating the verifier from the password on the fly. Nothing in RFC5054 says how the client sends the verifier to the server initially. If you really want to send the password instead, you just can. From pgut001@login01.cs.auckland.ac.nz Wed Oct 5 17:37:29 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732B021F8C3C for ; Wed, 5 Oct 2011 17:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.069 X-Spam-Level: X-Spam-Status: No, score=-3.069 tagged_above=-999 required=5 tests=[AWL=-0.470, 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 f4lQH1Bf4VCV for ; Wed, 5 Oct 2011 17:37:27 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF2921F8C04 for ; Wed, 5 Oct 2011 17:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1317861632; x=1349397632; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org,=20tls@ietf.org|Subject:=20Re: =20[TLS]=20draft=20on=20new=20TLS=20key=20exchange|Cc:=20 dhalasz@intwineenergy.com|In-Reply-To:=20 |Message-Id:=20|Date:=20Thu,=2006=20Oct=202011=2013:40:29=20+1300; bh=ZE/FZ1ltReWNWWycD3ne8HdWl0qyQRHn3+Sg/P/V69A=; b=RALjDMTdMi/GJH+E1sHAsE6NPqeQJ+8U0bKjt8/tfP8ruc+e5ZIypVA0 tmnJAxf1gSf5j0pZ7IaJoL5HonDzpByq4LOfFOkh0OBkBLiziEOkfBZsT +ngX5RPFBjqrNUWIfEv+Zn4Fz+OX+kYI3NQ9Wt8cb7YGHaug1N719KIgW U=; X-IronPort-AV: E=Sophos;i="4.68,494,1312113600"; d="scan'208";a="103703769" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Oct 2011 13:40:29 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RBc0j-0002KE-H1; Thu, 06 Oct 2011 13:40:29 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RBc0j-00043q-7j; Thu, 06 Oct 2011 13:40:29 +1300 From: Peter Gutmann To: dharkins@lounge.org, tls@ietf.org In-Reply-To: Message-Id: Date: Thu, 06 Oct 2011 13:40:29 +1300 Cc: dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 00:37:29 -0000 "Dan Harkins" writes: >I just uploaded a -00 draft that defines a new key exchange for TLS that does >not require certificates-- authentication using a simple password only. It can >be found at: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-00 > >Please take a look. The authors solicit comments. Oooh, oooh, I have one! It's: "What does this give us that TLS-PSK and TLS-SRP don't already do?". Peter. From dharkins@lounge.org Wed Oct 5 18:27:19 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525F221F8CBC for ; Wed, 5 Oct 2011 18:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.196 X-Spam-Level: X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 3HGMiOg+xoPx for ; Wed, 5 Oct 2011 18:27:18 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E23CE21F8CB9 for ; Wed, 5 Oct 2011 18:27:18 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 49AC71022404C; Wed, 5 Oct 2011 18:30:27 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Oct 2011 18:30:27 -0700 (PDT) Message-ID: <1a5b08230d13e530b3c88f645074caf8.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 5 Oct 2011 18:30:27 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 01:27:19 -0000 On Wed, October 5, 2011 5:40 pm, Peter Gutmann wrote: > "Dan Harkins" writes: > >>I just uploaded a -00 draft that defines a new key exchange for TLS that >> does >>not require certificates-- authentication using a simple password only. >> It can >>be found at: >> >> http://tools.ietf.org/html/draft-harkins-tls-pwd-00 >> >>Please take a look. The authors solicit comments. > > Oooh, oooh, I have one! It's: > > "What does this give us that TLS-PSK and TLS-SRP don't already do?". TLS-PSK: resistance to dictionary attack TLS-SRP: elliptic curve support, divorcing domain parameter set from the password I'm curious why you are not asking the authors of the SEED, Camellia, and Clefia drafts what those drafts give us that the AES ciphersuites don't already do. Dan. From pgut001@login01.cs.auckland.ac.nz Wed Oct 5 18:46:49 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D460E1F0C5E for ; Wed, 5 Oct 2011 18:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.061 X-Spam-Level: X-Spam-Status: No, score=-3.061 tagged_above=-999 required=5 tests=[AWL=-0.462, 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 6uGS9jnftd8l for ; Wed, 5 Oct 2011 18:46:49 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id DA4CC1F0C55 for ; Wed, 5 Oct 2011 18:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1317865799; x=1349401799; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20draft=20on=20new=20TLS=20key=20 exchange|Cc:=20dhalasz@intwineenergy.com,=20tls@ietf.org |In-Reply-To:=20<1a5b08230d13e530b3c88f645074caf8.squirre l@www.trepanning.net>|Message-Id:=20|Date:=20Thu,=2006=20Oct=202011 =2014:49:45=20+1300; bh=Z5MDQ8diSD4wBpRz2Y98ld/W1A6t0FfLuNN+mc6zL1w=; b=clkUdJKebu4zo06A29kDNxesDO20sFrF0nkg2Ejj7wXswef31iQAFa/J 994rlDcEAdZJf8iJrj9xA2fDktwC1RkZeN16UjOmvYHTnQRuHVjCwXc8/ vDbaUIoIoIfSA9VtRTYbl1yDkQ4+QxY1Mf9V9X8JsUeM4c8KH1ha8Hdjf M=; X-IronPort-AV: E=Sophos;i="4.68,495,1312113600"; d="scan'208";a="103741537" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Oct 2011 14:49:45 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RBd5l-0004se-H0; Thu, 06 Oct 2011 14:49:45 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RBd5l-0000Hy-7O; Thu, 06 Oct 2011 14:49:45 +1300 From: Peter Gutmann To: dharkins@lounge.org, pgut001@cs.auckland.ac.nz In-Reply-To: <1a5b08230d13e530b3c88f645074caf8.squirrel@www.trepanning.net> Message-Id: Date: Thu, 06 Oct 2011 14:49:45 +1300 Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 01:46:49 -0000 "Dan Harkins" writes: > TLS-PSK: resistance to dictionary attack > TLS-SRP: elliptic curve support, divorcing domain parameter set from > the password So it's a proposal that adds a few obscure geeky features to two existing mechanisms that vendors have already decided not to adopt (wrongly, in my opinion, but that doesn't change the lack of adoption). Why would they suddenly rush to support this one if they've ignored the other two (and a string of earlier drafts along the same lines)? (As a more general comment, this draft should be, if anything, an Experimental and not a Standards-Track, given its context). >I'm curious why you are not asking the authors of the SEED, Camellia, and >Clefia drafts what those drafts give us that the AES ciphersuites don't >already do. Those three are fashion-statement RFCs whose reasons for existence have little (if anything) to do with security. Does that mean this draft is also a fashion statement? Peter. From dharkins@lounge.org Wed Oct 5 18:49:43 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A221F8D5E for ; Wed, 5 Oct 2011 18:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 cUspW5y96C-0 for ; Wed, 5 Oct 2011 18:49:42 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id CDCC621F8D02 for ; Wed, 5 Oct 2011 18:49:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id E08021022404C; Wed, 5 Oct 2011 18:52:49 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Oct 2011 18:52:50 -0700 (PDT) Message-ID: <515f8ee2775802d5503dd952f80d2d8b.squirrel@www.trepanning.net> In-Reply-To: <4E8CF8AD.9020509@free.fr> References: <4E8CF8AD.9020509@free.fr> Date: Wed, 5 Oct 2011 18:52:50 -0700 (PDT) From: "Dan Harkins" To: "Jean-Marc Desperrier" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 01:49:43 -0000 On Wed, October 5, 2011 5:39 pm, Jean-Marc Desperrier wrote: > On 06/10/2011 01:07, Dan Harkins wrote: >> TLS is rife with drafts and RFCs that have the same aim but go about >> it differently > Even if there might indeed be quite a few like that in the TLS case, > it's still against IETF policy. I asked Peter and I'll ask you: why have you not brought up this with Camellia, SEED, and Clefia? And I'd be really interested in seeing the IETF policy statement that mandates one and only one way of doing one particular thing. > There should be at least some specific advantage to your approach over > the other one (or enough existing usage to justify documenting it > through an experimental RFC), which is far from being proved for now. I don't think such language is appropriate for an I-D. But in an email exchange I'll tell you that this scheme allows the cryptographic strength of the domain parameter set to be matched with ciphersuites of commensurate strength. This also allows for the use of elliptic curves. It doesn't hard-code a particular hash algorithm (that the IETF is planning on moving away from) so it's more "crypto agile". > SRP has the advantage over the other PAKE to be covered by a defensive > patent with a royalty free license, which makes it safer to use. This key exchange is not patented. > If needed, it's also actually very easy to use SRP in symmetric mode, > regenerating the verifier from the password on the fly. > Nothing in RFC5054 says how the client sends the verifier to the server > initially. If you really want to send the password instead, you just can. You can change the way RFC 5054 works but then it's not SRP anymore and then people will start telling you that it's "against IETF policy". Furthermore, the client doesn't send the verifier to the server in SRP so I'm not really sure what you're talking about. Dan. From dharkins@lounge.org Wed Oct 5 19:14:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E4B21F8CC4 for ; Wed, 5 Oct 2011 19:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.201 X-Spam-Level: X-Spam-Status: No, score=-6.201 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 r3ZqiRLx6JlA for ; Wed, 5 Oct 2011 19:14:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 265B921F8CC1 for ; Wed, 5 Oct 2011 19:14:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 7806D1022404C; Wed, 5 Oct 2011 19:17:12 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 5 Oct 2011 19:17:12 -0700 (PDT) Message-ID: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net> In-Reply-To: References: Date: Wed, 5 Oct 2011 19:17:12 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 02:14:03 -0000 On Wed, October 5, 2011 6:49 pm, Peter Gutmann wrote: > "Dan Harkins" writes: > >> TLS-PSK: resistance to dictionary attack >> TLS-SRP: elliptic curve support, divorcing domain parameter set from >> the password > > So it's a proposal that adds a few obscure geeky features to two existing > mechanisms that vendors have already decided not to adopt (wrongly, in my > opinion, but that doesn't change the lack of adoption). Why would they > suddenly rush to support this one if they've ignored the other two (and a > string of earlier drafts along the same lines)? This came out of some discussions around security for "smart energy" applications whose specifications do much hand waving and assume that certificates magically appear on the most unlikely of places and are all used properly. They also make it highly problematic for any off-the-shelf device that is supposed to be integrated into a network of other "smart energy" devices from working properly. They assume an unrealistic level of security clue on the people installing and provisioning the device. Having Joe Random enter a simple password on the UI of his thermostat, for instance, is much more believable. Also, this is the same key exchange used by 802.11 mesh networks to secure traffic going across the mesh, as well as traffic to create and maintain the mesh (e.g. routing). Using the same key exchange to secure a management interface (i.e. a TLS-protected connection to the GUI or a UI) of a mesh networking device would be useful-- conservation of crypto algorithms, it's straightforward to set a consistent security level across interfaces, etc. As a general purpose ciphersuite, no I don't imagine it will get much more widespread use than SRP though. But I don't think that's necessarily a reason to oppose it. > (As a more general comment, this draft should be, if anything, an > Experimental > and not a Standards-Track, given its context). I highly doubt that this hopeful stab at a track would be supported by the ADs. But I can hope. >>I'm curious why you are not asking the authors of the SEED, Camellia, and >>Clefia drafts what those drafts give us that the AES ciphersuites don't >>already do. > > Those three are fashion-statement RFCs whose reasons for existence have > little > (if anything) to do with security. Does that mean this draft is also a > fashion statement? No, it's not a fashion statement. I just don't like following a whole bunch of other people only to have the door slammed in my face. It does not jibe with my notion of fairness. Dan. From marsh@extendedsubset.com Wed Oct 5 22:44:20 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6732421F8D25 for ; Wed, 5 Oct 2011 22:44:20 -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 qGyEb+fXU1hP for ; Wed, 5 Oct 2011 22:44:19 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id 79C8921F8CF2 for ; Wed, 5 Oct 2011 22:44:19 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RBgnp-000OJm-2E; Thu, 06 Oct 2011 05:47:29 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 3CD5063BF; Thu, 6 Oct 2011 05:47:25 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/ZMrpmgVN4/mCDqG/44YQRPbubQ2rwvRY= Message-ID: <4E8D40EF.4070406@extendedsubset.com> Date: Thu, 06 Oct 2011 00:47:27 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Peter Gutmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 05:44:20 -0000 On 10/05/2011 08:49 PM, Peter Gutmann wrote: > "Dan Harkins" writes: > >> TLS-PSK: resistance to dictionary attack >> TLS-SRP: elliptic curve support, divorcing domain parameter set from >> the password > > So it's a proposal that adds a few obscure geeky features to two existing > mechanisms Almost everything in crypto-land starts out obscure and geeky to even your average geek. > that vendors have already decided not to adopt (wrongly, in my > opinion, but that doesn't change the lack of adoption). Why would they > suddenly rush to support this one if they've ignored the other two (and a > string of earlier drafts along the same lines)? That's not a particularly strong argument against this one though. You never know when vendors will have to change their minds, often in a hurry. When they do, it's better if there's something in place ahead of time IMHO. > (As a more general comment, this draft should be, if anything, an Experimental > and not a Standards-Track, given its context). > >> I'm curious why you are not asking the authors of the SEED, Camellia, and >> Clefia drafts what those drafts give us that the AES ciphersuites don't >> already do. I think a lot of people have been asking that. Probably more would ask it out loud on the list if they didn't feel it would be unnecessarily redundant and confrontational. > Those three are fashion-statement RFCs whose reasons for existence have little > (if anything) to do with security. They're also less new protocol and more of a code point assignment for an existing spec. Perhaps in some cases there will even be a little interoperating usage to justify it. The above notwithstanding, I have to say my initial reaction is also a bit skeptical of the utility of this thing. - Marsh From ynir@checkpoint.com Wed Oct 5 23:44:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A2A21F8CCC for ; Wed, 5 Oct 2011 23:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.377 X-Spam-Level: X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 WYrmFXLxAm6m for ; Wed, 5 Oct 2011 23:44:47 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4E52421F8CCB for ; Wed, 5 Oct 2011 23:44:47 -0700 (PDT) X-CheckPoint: {4E8D4EF4-10004-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p966lUn1021844; Thu, 6 Oct 2011 08:47:31 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 6 Oct 2011 08:47:30 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 6 Oct 2011 08:47:30 +0200 From: Yoav Nir To: Dan Harkins Date: Thu, 6 Oct 2011 08:47:31 +0200 Thread-Topic: [TLS] draft on new TLS key exchange Thread-Index: AcyD89GSOOKFqHLnQteCta9uk6AFzQ== Message-ID: <82F94F0D-F1C3-4ED0-8600-814B88021EBC@checkpoint.com> References: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net> In-Reply-To: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "dhalasz@intwineenergy.com" , "tls@ietf.org" Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 06:44:48 -0000 On Oct 6, 2011, at 4:17 AM, Dan Harkins wrote: >=20 > On Wed, October 5, 2011 6:49 pm, Peter Gutmann wrote: >> "Dan Harkins" writes: >>=20 >>> TLS-PSK: resistance to dictionary attack >>> TLS-SRP: elliptic curve support, divorcing domain parameter set from >>> the password >>=20 >> So it's a proposal that adds a few obscure geeky features to two existin= g >> mechanisms that vendors have already decided not to adopt (wrongly, in m= y >> opinion, but that doesn't change the lack of adoption). Why would they >> suddenly rush to support this one if they've ignored the other two (and = a >> string of earlier drafts along the same lines)? >=20 > This came out of some discussions around security for "smart energy" > applications whose specifications do much hand waving and assume that > certificates magically appear on the most unlikely of places and are > all used properly. They also make it highly problematic for any > off-the-shelf device that is supposed to be integrated into a network > of other "smart energy" devices from working properly. They assume an > unrealistic level of security clue on the people installing and > provisioning the device. Having Joe Random enter a simple password on > the UI of his thermostat, for instance, is much more believable. Joe Random will throw out a thermostat that regularly requires entering a p= assword. The use case is more likely entering the password once at installa= tion, and then that password is one chosen by the utility. For the last 17 = years, Microsoft has trained us all to enter 30-digit numbers. Once. In tha= t use case the passwords can be (relatively) high entropy, and then TLS-PSK= is acceptable. I am far more interested in using a password method for TLS= for authenticating to web sites. >>> I'm curious why you are not asking the authors of the SEED, Camellia, a= nd >>> Clefia drafts what those drafts give us that the AES ciphersuites don't >>> already do. Oh, they get a lot of grief every time they come up with "XXXX and its use = in IPSec/TLS/SSH". They always get that question, and they say something ab= out it being a standard of some national government. Sometimes the document= s end up as proposed standards (SEED, Camelia), and other times they end up= as Informational (GOST). Protocol changes get a lot more scrutiny than algorithms, probably because = many more of us think we are qualified to have informed opinions about prot= ocols than about algorithms. And protocol changes are far less likely to be= published.=20 >>=20 >> Those three are fashion-statement RFCs whose reasons for existence have >> little >> (if anything) to do with security. Does that mean this draft is also a >> fashion statement? >=20 > No, it's not a fashion statement. I just don't like following a whole > bunch of other people only to have the door slammed in my face. It > does not jibe with my notion of fairness. Peter and I have been trying to push draft-nir-tls-eap for over 4 years now= , and the TLS WG is not biting. You are following a bunch of people who hav= e already had the door slammed in their faces. Yoav From marsh@extendedsubset.com Wed Oct 5 23:55:24 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6803221F8AB9 for ; Wed, 5 Oct 2011 23:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 T0moMGGIhRPH for ; Wed, 5 Oct 2011 23:55:23 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE3E21F8C2A for ; Wed, 5 Oct 2011 23:55:23 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RBhua-0006jG-V6; Thu, 06 Oct 2011 06:58:33 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4D0A863BF; Thu, 6 Oct 2011 06:58:30 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19MG0r48uF4sGMd48OOeAWx6AINzneFPCg= Message-ID: <4E8D5198.4020809@extendedsubset.com> Date: Thu, 06 Oct 2011 01:58:32 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Dan Harkins References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 06:55:24 -0000 On 10/05/2011 01:12 AM, Dan Harkins wrote: > > Hi, > > I just uploaded a -00 draft that defines a new key exchange > for TLS that does not require certificates-- authentication using > a simple password only. It can be found at: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-00 > > Please take a look. The authors solicit comments. http://tools.ietf.org/html/draft-harkins-tls-pwd-00 : > 4. Specification of the TLS-PWD Handshake > > The authenticated key exchange is accomplished by each side deriving > a password-based element, PE, in the chosen group, making a > "committment" to a single guess of the password using PE, and > generating the Premaster Secret. The ability of each side to produce > a valid finished message authenticates itself to the other side. Here are my comments. Some of them probably apply to other TLS password-only schemes too. Comment 1: Are you familiar with the studies showing that the great majority of users re-use passwords across sites and a large percentage have same password everywhere? http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html http://nakedsecurity.sophos.com/2009/03/10/password-website/ This one finds that the average password is used at 6 different sites: http://research.microsoft.com/apps/pubs/?id=74164 I don't see anything in this protocol that allows the client endpoint to actually authenticate the server. Can the client know if he's authenticating with the legitimate server? If not, perhaps it's OK as long as either the handshake fails or the bad guy is reduced to the role of a dumb router between the legit client and server. Comment 2: But the server DNS name and port do not appear to be bound into the authentication. Couldn't the bad guy take a connection destined for one web site/service and feed it to another? Comment 3: The standard of practice for actual "secure" web sites (e.g. PCI compliance if you want to handle credit cards) forbids storing plaintext passwords on the server side. Any web app developer who was not using at least salted hashes today would be ridiculed as incompetent (e.g., Sony). The industry seems to be recognizing the importance of imposing a work factor (PBKDF2, bcrypt, scrypt) to resist dictionary attacks when the authentication database gets compromised, say, by a typical SQL injection. Is there any way to impose a work factor onto the attacker's guesses? Who do you envision will deploy a protocol that requires the storage of plaintext passwords? Conceivably there could be special-purpose systems that could generate handle these passwords securely, but couldn't they just as easily manage a private cert infrastructure? Comment 4: The hunting and pecking loops for both the ECC and FFC password elements look like a timing oracle to me. They seem to require a large exponentiation or sqrt on every iteration and the number of iterations is data-dependent. If I'm not mistaken, every input to the loop except the password itself is transmitted in cleartext during the handshake. Couldn't an attacker observe the timings of a sufficient number of failed handshakes to enable an offline brute force attack on the low-entropy password? - Marsh From dharkins@lounge.org Thu Oct 6 09:35:48 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC511F0C43 for ; Thu, 6 Oct 2011 09:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.203 X-Spam-Level: X-Spam-Status: No, score=-6.203 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 seBkCdFQ2JlJ for ; Thu, 6 Oct 2011 09:35:47 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id A6EC81F0C3F for ; Thu, 6 Oct 2011 09:35:47 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A19F610224062; Thu, 6 Oct 2011 09:38:58 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Oct 2011 09:38:58 -0700 (PDT) Message-ID: <63ad01d6fca38d4d44979254d6b48178.squirrel@www.trepanning.net> In-Reply-To: <4E8D5198.4020809@extendedsubset.com> References: <4E8D5198.4020809@extendedsubset.com> Date: Thu, 6 Oct 2011 09:38:58 -0700 (PDT) From: "Dan Harkins" To: "Marsh Ray" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 16:35:48 -0000 Hello, On Wed, October 5, 2011 11:58 pm, Marsh Ray wrote: > On 10/05/2011 01:12 AM, Dan Harkins wrote: >> >> Hi, >> >> I just uploaded a -00 draft that defines a new key exchange >> for TLS that does not require certificates-- authentication using >> a simple password only. It can be found at: >> >> http://tools.ietf.org/html/draft-harkins-tls-pwd-00 >> >> Please take a look. The authors solicit comments. > > http://tools.ietf.org/html/draft-harkins-tls-pwd-00 : >> 4. Specification of the TLS-PWD Handshake >> >> The authenticated key exchange is accomplished by each side deriving >> a password-based element, PE, in the chosen group, making a >> "committment" to a single guess of the password using PE, and >> generating the Premaster Secret. The ability of each side to produce >> a valid finished message authenticates itself to the other side. > > Here are my comments. Some of them probably apply to other TLS > password-only schemes too. > > Comment 1: > > Are you familiar with the studies showing that the great majority of > users re-use passwords across sites and a large percentage have same > password everywhere? > > http://www.pcworld.com/article/188763/too_many_people_reuse_logins_study_finds.html > http://nakedsecurity.sophos.com/2009/03/10/password-website/ > > This one finds that the average password is used at 6 different sites: > http://research.microsoft.com/apps/pubs/?id=74164 > > I don't see anything in this protocol that allows the client endpoint to > actually authenticate the server. Can the client know if he's > authenticating with the legitimate server? > > If not, perhaps it's OK as long as either the handshake fails or the bad > guy is reduced to the role of a dumb router between the legit client and > server. The client definitely authenticates the server. They both perform the same calculations to arrive at the same premaster secret. If either side has the wrong password, the secret group element will be different and they'll be doing their calculations with a different generator and that won't work. > Comment 2: > > But the server DNS name and port do not appear to be bound into the > authentication. Couldn't the bad guy take a connection destined for one > web site/service and feed it to another? Only if that other website had provisioned the same username/password. > Comment 3: > > The standard of practice for actual "secure" web sites (e.g. PCI > compliance if you want to handle credit cards) forbids storing plaintext > passwords on the server side. Any web app developer who was not using at > least salted hashes today would be ridiculed as incompetent (e.g., > Sony). The industry seems to be recognizing the importance of imposing a > work factor (PBKDF2, bcrypt, scrypt) to resist dictionary attacks when > the authentication database gets compromised, say, by a typical SQL > injection. > > Is there any way to impose a work factor onto the attacker's guesses? As I mentioned in a previous email it's possible to salt the password at provisioning time and have the server send the salt to the client in the ServerKeyExchange. I will do that in -01. > Who do you envision will deploy a protocol that requires the storage of > plaintext passwords? That sounds like a general, non-TLS-specific, question so I'll answer it generally: when either side can initiate to the other, or in a true peer-to-peer situation where both sides could theoretically initiate simultaneously. But that's not the case for TLS where there are strict client and server roles. And, as I mentioned, I'll add some salt to the stored password. > Conceivably there could be special-purpose systems that could generate > handle these passwords securely, but couldn't they just as easily manage > a private cert infrastructure? > > Comment 4: > > The hunting and pecking loops for both the ECC and FFC password elements > look like a timing oracle to me. They seem to require a large > exponentiation or sqrt on every iteration and the number of iterations > is data-dependent. If I'm not mistaken, every input to the loop except > the password itself is transmitted in cleartext during the handshake. > > Couldn't an attacker observe the timings of a sufficient number of > failed handshakes to enable an offline brute force attack on the > low-entropy password? This is a very good point. I think the attacker would have to observe successful handshakes though. It's the number of times through the loop until the PE is determined that the attacker wants to know and a failed guess will not provide any useful information. And I don't think this attack enables an offline dictionary attack. I think that it will allow the attacker to exclude large chunks of the password pool with each observed successful exchange until what's left is manageable (or until there's just 1 entry left in the pool). But I'm not sure how concerned I am about this. After finding PE there will be a modular exponentiation or point multiply using this random element as the generator. That's a random generator and a random scalar and the timing variablities on that will make it hard to isolate the timing dependencies of the hunting-and-pecking loop. Especially since it's a random PE used for each run of the protocol. Combine that with the system knowledge and control required to glean timing information out of an observed run of the protocol and I'm not sure how practical this would be. Thanks for your comments. Regards, Dan. From marsh@extendedsubset.com Thu Oct 6 10:56:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F55521F8CF7 for ; Thu, 6 Oct 2011 10:56:43 -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 sxK7N-qDWuWC for ; Thu, 6 Oct 2011 10:56:42 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id E2E6821F8CEC for ; Thu, 6 Oct 2011 10:56:41 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RBsEa-00020j-UP; Thu, 06 Oct 2011 17:59:53 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6696563BF; Thu, 6 Oct 2011 17:59:51 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19SeVfjgwhrywS/7N20jj+QZTIEj3nA2Wg= Message-ID: <4E8DEC96.5000508@extendedsubset.com> Date: Thu, 06 Oct 2011 12:59:50 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Dan Harkins References: <4E8D5198.4020809@extendedsubset.com> <63ad01d6fca38d4d44979254d6b48178.squirrel@www.trepanning.net> In-Reply-To: <63ad01d6fca38d4d44979254d6b48178.squirrel@www.trepanning.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 17:56:46 -0000 On 10/06/2011 11:38 AM, Dan Harkins wrote: > > The client definitely authenticates the server. They both perform the > same calculations to arrive at the same premaster secret. If either side > has the wrong password, the secret group element will be different and > they'll be doing their calculations with a different generator and > that won't work. But that's not exactly the same as the client authenticating the server. That's the client authenticating that "the server endpoint knows the password for the username I supplied", the server name and port are not bound into the authentication anywhere. There's an implied assumption that only the intended server would know the password, but this assumption is not reliable in practice. IMHO this does not constitute strong authentication of the server to the client. >> Comment 2: >> >> But the server DNS name and port do not appear to be bound into the >> authentication. Couldn't the bad guy take a connection destined for one >> web site/service and feed it to another? > > Only if that other website had provisioned the same username/password. This is a common case and the security properties differ dramatically in this regard from most existing uses of TLS. So it probably should be discussed in the security considerations section. >> Is there any way to impose a work factor onto the attacker's guesses? > > As I mentioned in a previous email it's possible to salt the password > at provisioning time and have the server send the salt to the client in > the ServerKeyExchange. I will do that in -01. I think people will be looking for bcrypt, scrypt, or PBKDF2 with some SHA > 1. They will want to choose the work factor. >> Who do you envision will deploy a protocol that requires the storage of >> plaintext passwords? > > That sounds like a general, non-TLS-specific, question so I'll answer > it generally: when either side can initiate to the other, or in a true > peer-to-peer situation where both sides could theoretically initiate > simultaneously. But that's not the case for TLS where there are strict > client and server roles. http://tools.ietf.org/html/rfc2246 > client > The application entity that initiates a TLS connection to a > server. This may or may not imply that the client initiated the > underlying transport connection. The primary operational > difference between the server and client is that the server is > generally authenticated, while the client is only optionally > authenticated. Those roles are not actually so strict, and this proposal seems to sort of reverse the primary direction of authentication compared to existing uses of TLS. Could be useful, but deserves to be stated explicitly. >> Couldn't an attacker observe the timings of a sufficient number of >> failed handshakes to enable an offline brute force attack on the >> low-entropy password? > > This is a very good point. I think the attacker would have to observe > successful handshakes though. It's the number of times through the loop > until the PE is determined that the attacker wants to know and a failed > guess will not provide any useful information. Won't at least one of the attacked endpoints still be working from the correct password? Won't his timing be enough? > And I don't think this attack enables an offline dictionary attack. > I think that it will allow the attacker to exclude large chunks of the > password pool with each observed successful exchange until what's left > is manageable (or until there's just 1 entry left in the pool). That probably would be more sophisticated, but he could probably also just run through the 10000 most common passwords and see which ones fit the observed timings. A busy server is going to have orders of magnitude more TLS handshakes than users over any reasonable period of time. > But I'm not sure how concerned I am about this. After finding PE > there will be a modular exponentiation or point multiply using this > random element as the generator. That's a random generator and a random > scalar and the timing variablities on that will make it hard to isolate > the timing dependencies of the hunting-and-pecking loop. Especially > since it's a random PE used for each run of the protocol. But if it's perfectly random (or at least doesn't correlate to the number of iterations) then all that averages out quite nicely. It's simply a question of how many samples are needed. > Combine that > with the system knowledge and control required to glean timing information > out of an observed run of the protocol and I'm not sure how practical > this would be. Famous last words. - Marsh From mrex@sap.com Thu Oct 6 12:03:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47411F0C5D for ; Thu, 6 Oct 2011 12:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.07 X-Spam-Level: X-Spam-Status: No, score=-10.07 tagged_above=-999 required=5 tests=[AWL=0.179, 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 ggPP1KCXnyPa for ; Thu, 6 Oct 2011 12:03:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1281B1F0C3B for ; Thu, 6 Oct 2011 12:03:44 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p96J6qiE005416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Oct 2011 21:06:52 +0200 (MEST) From: Martin Rex Message-Id: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp> To: dharkins@lounge.org (Dan Harkins) Date: Thu, 6 Oct 2011 21:06:52 +0200 (MEST) In-Reply-To: <63ad01d6fca38d4d44979254d6b48178.squirrel@www.trepanning.net> from "Dan Harkins" at Oct 6, 11 09:38:58 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange 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, 06 Oct 2011 19:03:45 -0000 Dan Harkins wrote: > > Marsh Ray wrote: > > > > Comment 4: > > > > The hunting and pecking loops for both the ECC and FFC password elements > > look like a timing oracle to me. They seem to require a large > > exponentiation or sqrt on every iteration and the number of iterations > > is data-dependent. If I'm not mistaken, every input to the loop except > > the password itself is transmitted in cleartext during the handshake. > > > > Couldn't an attacker observe the timings of a sufficient number of > > failed handshakes to enable an offline brute force attack on the > > low-entropy password? I agree with Marsh, it is difficult to conceive how to implement this without being a timing oracle. The question is, how much does it help you. If you already have an account or could create one, then the timing would help you sort out unlikely passwords, I assume, because you know the algorithm and can determine "off-line" whether a computation for a newly guessed password is faster or slower than your own password and you can measure the servers response times for your password and for the unknown password and therefore know their relation. > > This is a very good point. I think the attacker would have to observe > successful handshakes though. It's the number of times through the loop > until the PE is determined that the attacker wants to know and a failed > guess will not provide any useful information. I don't find it very attractive if an authentication protocol gives an attacker a huge advantage at guessing an unknown account credential if he can create or obtain a valid account credential. I also feel very uncomforable with the extremely vague term "low-entropy password" and the idea that this could be secure. "low-entropy" to me means something like a 4-digit numeric PIN, e.g. a complexity of 10^4 or 2^13.28 The only means to retain a meaningful security margin against brute-force attacks is a very low lockout counter (e.g 2^4 or less). If the whole handshake takes 1 second to complete (or fail), then a brute force of the entire 2^13.28 entropy universe completes in less than 3 hours. Without a lockout, there just is not any meaningful security possible. -Martin From anders.rundgren@telia.com Thu Oct 6 12:47:25 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15BA11E80D4 for ; Thu, 6 Oct 2011 12:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.114, 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 XitEaL9Ex2xt for ; Thu, 6 Oct 2011 12:47:25 -0700 (PDT) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id DFECE11E8090 for ; Thu, 6 Oct 2011 12:47:24 -0700 (PDT) Received: from [192.168.0.204] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E79D7E2006228F4; Thu, 6 Oct 2011 21:50:27 +0200 Message-ID: <4E8E0677.4020907@telia.com> Date: Thu, 06 Oct 2011 21:50:15 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Yoav Nir References: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net> <82F94F0D-F1C3-4ED0-8600-814B88021EBC@checkpoint.com> In-Reply-To: <82F94F0D-F1C3-4ED0-8600-814B88021EBC@checkpoint.com> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: [TLS] TLS-EAP. Was: draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 19:47:25 -0000 On 2011-10-06 08:47, Yoav Nir wrote: >> No, it's not a fashion statement. I just don't like following a whole >> bunch of other people only to have the door slammed in my face. It >> does not jibe with my notion of fairness. > > Peter and I have been trying to push draft-nir-tls-eap for over 4 years now, > and the TLS WG is not biting. You are following a bunch of people who have > already had the door slammed in their faces. In TrustedComputingGroup Intel was recently suggesting TLS-EAP as an alternative to another TCG TLS-hack in progress. Why isn't the TLS WG "biting"? Who cares if an IETF WG says no? Why not try other venues such as actually donating code? The IETF has en huge stack of s.c. "standards" that aren't even worth the disk-space they occupy! Anders From marsh@extendedsubset.com Thu Oct 6 12:55:47 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE77211E80E2 for ; Thu, 6 Oct 2011 12:55:47 -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 dIVVx4cKS-Fe for ; Thu, 6 Oct 2011 12:55:47 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5F43A11E80A3 for ; Thu, 6 Oct 2011 12:55:47 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RBu5q-000GUB-OG for tls@ietf.org; Thu, 06 Oct 2011 19:58:58 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A45B563BF for ; Thu, 6 Oct 2011 19:58:57 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/fa5WfUtBiAtHj5MPCTKBbnZy8j67Xdmk= Message-ID: <4E8E0880.3050409@extendedsubset.com> Date: Thu, 06 Oct 2011 14:58:56 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: tls@ietf.org References: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net> <82F94F0D-F1C3-4ED0-8600-814B88021EBC@checkpoint.com> <4E8E0677.4020907@telia.com> In-Reply-To: <4E8E0677.4020907@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] TLS-EAP. Was: draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 19:55:47 -0000 On 10/06/2011 02:50 PM, Anders Rundgren wrote: > Who cares if an IETF WG says no? You won't get a code point assignment for your extension otherwise. - Marsh From marsh@extendedsubset.com Thu Oct 6 13:22:51 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAEB321F8E1B for ; Thu, 6 Oct 2011 13:22:51 -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 f6pVitbL0lcA for ; Thu, 6 Oct 2011 13:22:51 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1A21F8E0A for ; Thu, 6 Oct 2011 13:22:51 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RBuW2-00043l-EG; Thu, 06 Oct 2011 20:26:02 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AB32063BF; Thu, 6 Oct 2011 20:26:00 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19yTWxndkCs8upEW68MOnX+JzhSPPjARTk= Message-ID: <4E8E0ED7.80705@extendedsubset.com> Date: Thu, 06 Oct 2011 15:25:59 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: mrex@sap.com References: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp> In-Reply-To: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 20:22:51 -0000 On 10/06/2011 02:06 PM, Martin Rex wrote: >> >> Marsh Ray wrote: >>> >>> Couldn't an attacker observe the timings of a sufficient number of >>> failed handshakes to enable an offline brute force attack on the >>> low-entropy password? > > I agree with Marsh, it is difficult to conceive how to implement > this without being a timing oracle. I disagree with Martin. :-) It probably could be implemented without being a timing oracle, but blinding the timing channel might impose something approximating worst-case latency in all cases. Without benchmarking, I don't know if that means microseconds or milliseconds. But mainly the fix wouldn't happen by accident. It needs to be pointed out with a high profile in the security considerations section. > The question is, how much does it help you. > > If you already have an account or could create one, then the timing > would help you sort out unlikely passwords, I assume, because you > know the algorithm and can determine "off-line" whether a computation > for a newly guessed password is faster or slower than your own password > and you can measure the servers response times for your password and > for the unknown password and therefore know their relation. Collect timing on a few thousand handshakes for a given user. Observe the server response time clustering into buckets with a log_2 decaying distribution. > I don't find it very attractive if an authentication protocol gives > an attacker a huge advantage at guessing an unknown account credential > if he can create or obtain a valid account credential. I don't think it requires the attacker to obtain an account on the same server (but even if it did, that would still be bad). > I also feel very uncomforable with the extremely vague term > "low-entropy password" and the idea that this could be secure. Sometimes we have to make the best of what we've got. Maybe sometimes all we've got is a password. Still, I'm skeptical about who would use this thing and that they wouldn't be better served with something else. > If the whole handshake takes 1 second to complete (or fail), then > a brute force of the entire 2^13.28 entropy universe completes > in less than 3 hours. Without a lockout, there just is not any > meaningful security possible. Consider a "smart grid" of electric meters with a service lifetime of 30 years. The meters probably have very slow CPUs making timing values relatively large and easy to distinguish. They may handshake regularly with the controlling systems. The power line network is about as open and undefended as you can get. An attacker may be able to gather timing statistics for several years, after which he has obtained complete "blinkenlights capability" over the service region. That would be bad. - Marsh From dharkins@lounge.org Thu Oct 6 14:00:03 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D9411E80A3 for ; Thu, 6 Oct 2011 14:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 NGASUBgTl3jB for ; Thu, 6 Oct 2011 14:00:03 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 31DDC11E808E for ; Thu, 6 Oct 2011 14:00:03 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 95A301022404C; Thu, 6 Oct 2011 14:03:14 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Oct 2011 14:03:14 -0700 (PDT) Message-ID: <8d93ad0b8c3b53995c28a38cf8c6bf3e.squirrel@www.trepanning.net> In-Reply-To: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp> References: <201110061906.p96J6qKa003260@fs4113.wdf.sap.corp> Date: Thu, 6 Oct 2011 14:03:14 -0700 (PDT) From: "Dan Harkins" To: mrex@sap.com User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 21:00:03 -0000 On Thu, October 6, 2011 12:06 pm, Martin Rex wrote: > Dan Harkins wrote: >> >> Marsh Ray wrote: >> > >> > Comment 4: >> > >> > The hunting and pecking loops for both the ECC and FFC password >> elements >> > look like a timing oracle to me. They seem to require a large >> > exponentiation or sqrt on every iteration and the number of iterations >> > is data-dependent. If I'm not mistaken, every input to the loop except >> > the password itself is transmitted in cleartext during the handshake. >> > >> > Couldn't an attacker observe the timings of a sufficient number of >> > failed handshakes to enable an offline brute force attack on the >> > low-entropy password? > > I agree with Marsh, it is difficult to conceive how to implement > this without being a timing oracle. > > The question is, how much does it help you. Indeed. And I think the answer is, not much. > If you already have an account or could create one, then the timing > would help you sort out unlikely passwords, I assume, because you > know the algorithm and can determine "off-line" whether a computation > for a newly guessed password is faster or slower than your own password > and you can measure the servers response times for your password and > for the unknown password and therefore know their relation. The relation-- yours is "faster" than the unknown one-- means nothing. That knowledge doesn't help. Knowing how many iterations the hunting- and-pecking loop went through to find PE for an unknown password might but the relationship between two means nothing. In fact, since both sides are contributing randomness into the hunting-and-pecking loop yours might be "faster" one time and considerably slower the next time. That knowledge doesn't really help. After the hunting-and-pecking loop there is a modular exponentiation (or equivalent in EEC) using a random generator raised to a random exponent. The timing variations in that calculation will be tremendous. The server won't respond until it has done both of these actions so what the attacker sees is a sum of the time it took to perform both actions. But the high variability in the time it takes to perform one of those actions will interfere with the attacker's attempt to find out how long the other action took. This is not a feasible attack. >> This is a very good point. I think the attacker would have to observe >> successful handshakes though. It's the number of times through the loop >> until the PE is determined that the attacker wants to know and a failed >> guess will not provide any useful information. > > I don't find it very attractive if an authentication protocol gives > an attacker a huge advantage at guessing an unknown account credential > if he can create or obtain a valid account credential. I don't think it's attractive for an authentication protocol to give an attack a huge advantage either. And this one doesn't. > I also feel very uncomforable with the extremely vague term > "low-entropy password" and the idea that this could be secure. > > > "low-entropy" to me means something like a 4-digit numeric PIN, > e.g. a complexity of 10^4 or 2^13.28 > > The only means to retain a meaningful security margin against > brute-force attacks is a very low lockout counter (e.g 2^4 or less). > > If the whole handshake takes 1 second to complete (or fail), then > a brute force of the entire 2^13.28 entropy universe completes > in less than 3 hours. Without a lockout, there just is not any > meaningful security possible. Yes, good point. At the bottom of section 6 I mention some countermeasures to deal with repeated, failed, active attacks. I should be more specific and mention what those countermeasures might look like. thanks, Dan. From pgladstone@cisco.com Thu Oct 6 16:18:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6095A21F8BFE for ; Thu, 6 Oct 2011 16:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJEKz5x-NQPQ for ; Thu, 6 Oct 2011 16:18:57 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id D708221F8BEF for ; Thu, 6 Oct 2011 16:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pgladstone@cisco.com; l=8383; q=dns/txt; s=iport; t=1317943328; x=1319152928; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=BJAM9DSDR+9FOAALSuzypryb67G/gvMkfMTwNieI6XA=; b=jsSNWcgE/Tb2tprgjsiFa+3ytHKCng4k+RM6uLgWjn3SffGqihIeePX1 Gx0DfjVaYXIqTbx85U35XW5thZyGj46FRAWdP2wz2fo7L7kdzxPb/6jTz ra7drWUZyKt6nawv9+5WcKM29w/ZDpzHlXfYaGAqaGv1Ub60KN7vIsgjx s=; X-Files: smime.p7s : 4899 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngGAOw2jk6rRDoG/2dsb2JhbAA/A4R0lGuOWYEFgVMBAQEEEgEQVQ8CCxgJDwcLAgICBwMCAQIBCTwTCAEBHodjmgIBjEaRQgKEFwaBeYEUBI5QhR6FKIw6 X-IronPort-AV: E=Sophos;i="4.68,499,1312156800"; d="p7s'?scan'208";a="6392511" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Oct 2011 23:22:04 +0000 Received: from [171.69.143.168] (dhcp-171-69-143-168.cisco.com [171.69.143.168]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p96NM3jS009794 for ; Thu, 6 Oct 2011 23:22:04 GMT Message-ID: <4E8E3819.2000907@cisco.com> Date: Thu, 06 Oct 2011 19:22:01 -0400 From: Philip Gladstone Organization: Cisco Systems, Inc User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000406000002060703060805" Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 06 Oct 2011 23:18:57 -0000 This is a cryptographically signed message in MIME format. --------------ms000406000002060703060805 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable On 10/5/2011 2:12 AM, Dan Harkins wrote: > Hi, > > I just uploaded a -00 draft that defines a new key exchange > for TLS that does not require certificates-- authentication using > a simple password only. It can be found at: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-00 > > Please take a look. The authors solicit comments. > > There is a note in Security Considerations section that indicates that=20 an active attack that tried a hundred thousand passwords would be easily = detected. The problem is that, in many cases, finding the password of a=20 single user is sufficient (and you don't care which user it is). This=20 means that you iterate over all users, only trying a single password for = each user. This is *much* more difficult to detect and stop. [It does=20 assume that usernames are drawn from a small pool. This may well be the=20 case for electricity meters where the username might well be the device=20 serial number -- and these are in a small, consecutive, range] Philip --=20 Philip Gladstone Phone: +1 978-ZEN-TOAD (+1 978 936 8623) Google: +1 978 800 1010 Ham radio: N1DQ --------------ms000406000002060703060805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO2TCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFGjCCBAKgAwIBAgIQbRnqpxlPajMi 5iIyeqpx3jANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0xMTA0MjgwMDAwMDBa Fw0yMDA1MzAxMDQ4MzhaMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5j aGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5 MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoSEW0tXmNReL4uk4UDIo1NY X2Zl8TJO958yfVXQeExVt0KU4PkncQfFxmmkuTLE8UAakMwnVmJ/F7Vxaa7lIBvky2NeYMqi QfZq4aP/uN8fSG1lQ4wqLitjOHffsReswtqCAtbUMmrUZ28gE49cNfrlVICv2HEKHTcKAlBT bJUdqRAUtJmVWRIx/wmi0kzcUtve4kABW0ho3cVKtODtJB86r3FfB+OsvxQ7sCVxaD30D9YX WEYVgTxoi4uDD216IVfmNLDbMn7jSuGlUnJkJpFOpZIP/+CxYP0ab2hRmWONGoulzEKbm30i Y9OpoPzOnpDfRBn0XFs1uhbzp5v/wQIDAQABo4IBSzCCAUcwHwYDVR0jBBgwFoAUiYJnfcSd JnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFHoTTgB0W8Z4Y2QnwS/ioFu8ecV7MA4GA1UdDwEB /wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgEAMBEGA1UdIAQKMAgwBgYEVR0gADBYBgNVHR8E UTBPME2gS6BJhkdodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vVVROLVVTRVJGaXJzdC1DbGll bnRBdXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDB0BggrBgEFBQcBAQRoMGYwPQYIKwYBBQUH MAKGMWh0dHA6Ly9jcnQudXNlcnRydXN0LmNvbS9VVE5BZGRUcnVzdENsaWVudF9DQS5jcnQw JQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVzZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQEFBQAD ggEBAIXWvnhXVW0zf0RS/kLVBqgBA4CK+w2y/Uq/9q9BSfUbWsXSrRtzbj7pJnzmTJjBMCjf y/tCPKElPgp11tA9OYZm0aGbtU2bb68obB2v5ep0WqjascDxdXovnrqTecr+4pEeVnSy+I3T 4ENyG+2P/WA5IEf7i686ZUg8mD2lJb+972DgSeUWyOs/Q4Pw4O4NwdPNM1+b0L1garM7/vrU yTo8H+2b/5tJM75CKTmD7jNpLoKdRU2oadqAGx490hpdfEeZpZsIbRKZhtZdVwcbpzC+S0lE uJB+ytF5OOu0M/qgOl0mWJ5hVRi0IdWZ1eBDQEIwvuql55TSsP7zdfl/bucwggUpMIIEEaAD AgECAhBluzNhw6CDObOmDguxgJDVMA0GCSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEb MBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDkwNjAwMDAwMFoXDTEyMDkwNTIzNTk1 OVowJTEjMCEGCSqGSIb3DQEJARYUcGdsYWRzdG9uZUBjaXNjby5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC8ShP963c4uAJcGoHC2JCwJKJth79tIXQ2aVrtbK1tN5vi eX+0nKzylBxgLOfpyPuYxGuya1GNLXPXCnIp8sYpy6AlaQw2laBBODjl13Yjgnv/jlpVmE4d AwhRqWdcCH0WkrKniZiFEr72GUfhemnFNXILC5D82IiDOjqQ4guzO+ll/OoyYNBwx7ux4WAH hebTSrXcciAq/TqZnc8HlimFC6kS53kQdNd/MsYWNKVSj/60WxaHqFAjeRDopmZ4IDR2GvgX W7N4UIzXIcpJW8DC/KktfMxo/DXhi64RY3mLE0cxepA/D0T94uVwKXHneE9Q+GNhcNBIE4hT NrcsSlNbAgMBAAGjggHkMIIB4DAfBgNVHSMEGDAWgBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAd BgNVHQ4EFgQUEB9ztHyHGmanfNM9BLyVUI828nEwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB /wQCMAAwIAYDVR0lBBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQE AwIFIDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczov L3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8vY3JsLmNv bW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0Eu Y3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2Eu Y29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYI KwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAfBgNVHREEGDAWgRRwZ2xhZHN0 b25lQGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAASu4Jrf2J6VFo8sJU04WDaW5P3wa jd5RSUWyhAgC/Doog4YlFvfQInnsMiEh069+czqynhigU8ahGOwzRCvZC044sPWU53wtz0Wp jzz9I/2ekKDceJr+Neu1tcIrH2eqrjwE0Mn+pbsUw1eUn7G7bq1B8gT6TAEx3mrrxXCr2mkQ VABiT1L1rkkcGpvV5ls040AU5Oe9bPPgtlWh7qjcaXBeOsYu5EAqRtbP+w7LeVfs0W0vXG1O h9O3X2FCHqZrQTh5gj3by4p0bssKCMKk/pELMzi5uHfB2OZhG4gLxTqwkVVXXcfCt2s/Womp 4TeiuQm/aozNUjlJQSfDYKaaETGCBAwwggQIAgEBMIGoMIGTMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDVMAkGBSsOAwIaBQCgggI4 MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMTAwNjIzMjIw MVowIwYJKoZIhvcNAQkEMRYEFHX2qhA7b+GVhHH10G8BmqfYAy/sMF8GCSqGSIb3DQEJDzFS MFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0D AgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBuQYJKwYBBAGCNxAEMYGrMIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBluzNhw6CDObOmDguxgJDV MIG7BgsqhkiG9w0BCRACCzGBq6CBqDCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExp bWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3Vy ZSBFbWFpbCBDQQIQZbszYcOggzmzpg4LsYCQ1TANBgkqhkiG9w0BAQEFAASCAQCBTGxLWF4x qYUa1aUpyRU7RW2l9k43Z+vmBwVr8rrIIdJ7AQkZ2eS+/MA6oLi+mzPERHwc6o871qRtmY2Z +Ys92RpP0K7f1eIMiLRjS03waRUUCm2jGZCymjRsGsFY7lqp+YjjGsPbMfH2u59xcdV05AJ0 bGNJKWoWOybS8na5gpb60q/iRdzkCzpcQVnfq5ZDvUNuM74g8A2g1jX4AWA7HbfirCJAmStq 2QTsZrrgRQNJ2SO37tEn9ghZdSxEdC44VYC+Pez/5AioT1TRkoi3p92ULL1WVSjxSLb8SIbB DAtFaqXWT2LtiBUaeDNI/l277ii/v1TvQV50MTKCi2PIAAAAAAAA --------------ms000406000002060703060805-- From pgut001@login01.cs.auckland.ac.nz Thu Oct 6 22:13:57 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B7121F8B58 for ; Thu, 6 Oct 2011 22:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.053 X-Spam-Level: X-Spam-Status: No, score=-3.053 tagged_above=-999 required=5 tests=[AWL=-0.454, 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 kh+Kr33LUYyU for ; Thu, 6 Oct 2011 22:13:56 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id BC51221F8B40 for ; Thu, 6 Oct 2011 22:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1317964606; x=1349500606; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20draft=20on=20new=20TLS=20key=20 exchange|Cc:=20dhalasz@intwineenergy.com,=20tls@ietf.org |In-Reply-To:=20<38d039888fa33cc08706ad7dca7fe201.squirre l@www.trepanning.net>|Message-Id:=20|Date:=20Fri,=2007=20Oct=202011 =2018:16:41=20+1300; bh=IAxfXzqdmNUiurF1lvttKEGzYlXKWJaco6nv2Ty5e5E=; b=nSEmPthhhO7vpb0dLcVCpwUaQ2+5xR7gVJvz7hcuLxzFO8kIdJcuIEoO TnhvPex1scK4rcNyuNBXepb7AyxA3FfHqGgJk/Q9h/oEOxqclzuXzvuRs QRtt9DCv3iKniLGUs92qfwRcLtZhXisK74RE4got71Rjp1ZyqiKAFL/L7 k=; X-IronPort-AV: E=Sophos;i="4.68,500,1312113600"; d="scan'208";a="104306770" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Oct 2011 18:16:42 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RC2na-0006Bo-GD; Fri, 07 Oct 2011 18:16:42 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RC2nZ-0000zV-Vh; Fri, 07 Oct 2011 18:16:41 +1300 From: Peter Gutmann To: dharkins@lounge.org, pgut001@cs.auckland.ac.nz In-Reply-To: <38d039888fa33cc08706ad7dca7fe201.squirrel@www.trepanning.net> Message-Id: Date: Fri, 07 Oct 2011 18:16:41 +1300 Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 05:13:57 -0000 "Dan Harkins" writes: >This came out of some discussions around security for "smart energy" >applications whose specifications do much hand waving and assume that >certificates magically appear on the most unlikely of places and are all used >properly. They also make it highly problematic for any off-the-shelf device >that is supposed to be integrated into a network of other "smart energy" >devices from working properly. They assume an unrealistic level of security >clue on the people installing and provisioning the device. Having Joe Random >enter a simple password on the UI of his thermostat, for instance, is much >more believable. Hmm, that was pretty much the argument that was made for TLS-PSK (well, not thermostats, but that it was something that didn't require deploying certs and was suitable for low-power devices). >As a general purpose ciphersuite, no I don't imagine it will get much more >widespread use than SRP though. But I don't think that's necessarily a reason >to oppose it. Speaking of SRP, I'm told the EKE patent expired a few days ago. Peter. From dharkins@lounge.org Thu Oct 6 22:57:41 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D0A21F8B47 for ; Thu, 6 Oct 2011 22:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.207 X-Spam-Level: X-Spam-Status: No, score=-6.207 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 y0O4ZHBupjt0 for ; Thu, 6 Oct 2011 22:57:40 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8A91321F8B07 for ; Thu, 6 Oct 2011 22:57:40 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C82891022404C; Thu, 6 Oct 2011 23:00:51 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Oct 2011 23:00:52 -0700 (PDT) Message-ID: <56bb9808f168ea916762ceb844cea755.squirrel@www.trepanning.net> In-Reply-To: <4E8E3819.2000907@cisco.com> References: <4E8E3819.2000907@cisco.com> Date: Thu, 6 Oct 2011 23:00:52 -0700 (PDT) From: "Dan Harkins" To: "Philip Gladstone" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 05:57:41 -0000 Hi, On Thu, October 6, 2011 4:22 pm, Philip Gladstone wrote: > On 10/5/2011 2:12 AM, Dan Harkins wrote: >> Hi, >> >> I just uploaded a -00 draft that defines a new key exchange >> for TLS that does not require certificates-- authentication using >> a simple password only. It can be found at: >> >> http://tools.ietf.org/html/draft-harkins-tls-pwd-00 >> >> Please take a look. The authors solicit comments. >> >> > There is a note in Security Considerations section that indicates that > an active attack that tried a hundred thousand passwords would be easily > detected. The problem is that, in many cases, finding the password of a > single user is sufficient (and you don't care which user it is). This > means that you iterate over all users, only trying a single password for > each user. This is *much* more difficult to detect and stop. [It does > assume that usernames are drawn from a small pool. This may well be the > case for electricity meters where the username might well be the device > serial number -- and these are in a small, consecutive, range] That's a great observation. It does suppose that for some given password there is at least one user in the pool of usernames that has that password. I'm not sure how true that is in general, but some text in the security considerations on this is probably needed. Do you have any? Dan. From dharkins@lounge.org Thu Oct 6 23:10:28 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6E9D21F8B77 for ; Thu, 6 Oct 2011 23:10:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 f5k4dSLzH5fY for ; Thu, 6 Oct 2011 23:10:28 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7A21F8558 for ; Thu, 6 Oct 2011 23:10:28 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DB4311022404C; Thu, 6 Oct 2011 23:13:40 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Oct 2011 23:13:41 -0700 (PDT) Message-ID: <011852a236125784b1bdfbbc353db408.squirrel@www.trepanning.net> In-Reply-To: References: Date: Thu, 6 Oct 2011 23:13:41 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 06:10:28 -0000 On Thu, October 6, 2011 10:16 pm, Peter Gutmann wrote: > Speaking of SRP, I'm told the EKE patent expired a few days ago. Yes! This is a good thing. But EKE cannot be used with elliptic curves and has its own particular constraints on what types of finite field domain parameter sets it can use (for instance, it can't be used with groups 1-3 in RFC 5054). This puts more of a burden on the client in evaluating whether an offer by the server should be accepted or not. Unlike EKE, the scheme described in draft-harkins-tls-eap can be used with any domain parameter set from RFC 3526, RFC 5114 or RFC 5639. Dan. From dharkins@lounge.org Thu Oct 6 23:12:52 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3921F8888 for ; Thu, 6 Oct 2011 23:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.21 X-Spam-Level: X-Spam-Status: No, score=-6.21 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7p1OiBLEITC6 for ; Thu, 6 Oct 2011 23:12:52 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 8434B21F87FC for ; Thu, 6 Oct 2011 23:12:52 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2AF2F1022404C; Thu, 6 Oct 2011 23:16:05 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Oct 2011 23:16:05 -0700 (PDT) Message-ID: In-Reply-To: <011852a236125784b1bdfbbc353db408.squirrel@www.trepanning.net> References: <011852a236125784b1bdfbbc353db408.squirrel@www.trepanning.net> Date: Thu, 6 Oct 2011 23:16:05 -0700 (PDT) From: "Dan Harkins" To: "Dan Harkins" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 06:12:53 -0000 Oh Jesus, what a typo... s/tls-eap/tls-pwd/ Dan. On Thu, October 6, 2011 11:13 pm, Dan Harkins wrote: > > > On Thu, October 6, 2011 10:16 pm, Peter Gutmann wrote: >> Speaking of SRP, I'm told the EKE patent expired a few days ago. > > Yes! This is a good thing. > > But EKE cannot be used with elliptic curves and has its own particular > constraints on what types of finite field domain parameter sets it can > use (for instance, it can't be used with groups 1-3 in RFC 5054). This > puts more of a burden on the client in evaluating whether an offer by the > server should be accepted or not. > > Unlike EKE, the scheme described in draft-harkins-tls-eap can be used > with any domain parameter set from RFC 3526, RFC 5114 or RFC 5639. > > Dan. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From pgut001@login01.cs.auckland.ac.nz Thu Oct 6 23:44:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BC421F8B27 for ; Thu, 6 Oct 2011 23:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.045 X-Spam-Level: X-Spam-Status: No, score=-3.045 tagged_above=-999 required=5 tests=[AWL=-0.446, 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 TSGdfpM5S2Qc for ; Thu, 6 Oct 2011 23:44:23 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id EFD8F21F85D1 for ; Thu, 6 Oct 2011 23:44:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1317970056; x=1349506056; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20draft=20on=20new=20TLS=20key=20 exchange|Cc:=20dhalasz@intwineenergy.com,=20tls@ietf.org |In-Reply-To:=20<011852a236125784b1bdfbbc353db408.squirre l@www.trepanning.net>|Message-Id:=20|Date:=20Fri,=2007=20Oct=202011 =2019:47:32=20+1300; bh=g3E6MOhiroFOYY2ORDlHva1dqHYwuNEeYRY+W9yMNHk=; b=sx8s/TN+6rLUFm3MxD0kXJWFyIR5HRAvW4f0Y24zKiBaWVAm0T3bQmjR mawHGk9NO74TYRCiTJ3ayeFmDR5ln1wVmUntCp5ETz1x3Y9KDs122GiPs wUTWReAwhmi8Y99vsdhai0+2sVzp0WhoBa8+7+BcYyUcPvBxEHJyZXSSg Y=; X-IronPort-AV: E=Sophos;i="4.68,500,1312113600"; d="scan'208";a="104326129" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Oct 2011 19:47:33 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RC4DU-0000Cq-Ii; Fri, 07 Oct 2011 19:47:32 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RC4DU-0007Nc-OW; Fri, 07 Oct 2011 19:47:32 +1300 From: Peter Gutmann To: dharkins@lounge.org, pgut001@cs.auckland.ac.nz In-Reply-To: <011852a236125784b1bdfbbc353db408.squirrel@www.trepanning.net> Message-Id: Date: Fri, 07 Oct 2011 19:47:32 +1300 Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 06:44:23 -0000 "Dan Harkins" writes: >But EKE cannot be used with elliptic curves Speaking of PAKE for ECC, from reading a writeup of PACE (for passport EAC) a while back, the claimed reason for introducing PACE was that a lot of standard DLP PAKE mechanisms aren't secure when used with ECDLPs. OTOH this RFC proposes a complex protocol for ECDLP use with no explanation of how it's derived, what its security properties are, or why it's secure. What's the security argument for it? Peter. From dharkins@lounge.org Thu Oct 6 23:55:23 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAC821F8B77 for ; Thu, 6 Oct 2011 23:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.212 X-Spam-Level: X-Spam-Status: No, score=-6.212 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7v1Km4k5UhNX for ; Thu, 6 Oct 2011 23:55:22 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD9021F8B76 for ; Thu, 6 Oct 2011 23:55:22 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 17FBA1022404C; Thu, 6 Oct 2011 23:58:35 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 6 Oct 2011 23:58:35 -0700 (PDT) Message-ID: In-Reply-To: References: Date: Thu, 6 Oct 2011 23:58:35 -0700 (PDT) From: "Dan Harkins" To: "Peter Gutmann" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 06:55:23 -0000 On Thu, October 6, 2011 11:47 pm, Peter Gutmann wrote: > "Dan Harkins" writes: > >>But EKE cannot be used with elliptic curves > > Speaking of PAKE for ECC, from reading a writeup of PACE (for passport > EAC) a > while back, the claimed reason for introducing PACE was that a lot of > standard > DLP PAKE mechanisms aren't secure when used with ECDLPs. OTOH this RFC > proposes a complex protocol for ECDLP use with no explanation of how it's > derived, what its security properties are, or why it's secure. What's the > security argument for it? I'm sorry, but I don't understand. Are you asking questions of a different PAKE scheme (PACE)? Which RFC are you talking about? Do you think there is something missing from the security considerations of our draft? Is there some statement of security, or argument, you'd like to see? Dan. From jmdesp@free.fr Fri Oct 7 07:25:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BAD21F8ACE for ; Fri, 7 Oct 2011 07:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 Oau+VjV-C0Wq for ; Fri, 7 Oct 2011 07:25:45 -0700 (PDT) Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8F79C21F8520 for ; Fri, 7 Oct 2011 07:25:45 -0700 (PDT) Received: from smtp-ex6.fr.colt.net (smtp-ex6.fr.colt.net [213.41.78.122]) by smtp-ft5.fr.colt.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p97ESn4e027262; Fri, 7 Oct 2011 16:28:49 +0200 Received: from host.104.92.68.195.rev.coltfrance.com ([195.68.92.104] helo=[172.30.24.37]) by smtp-ex6.fr.colt.net with esmtp (Exim) (envelope-from ) id 1RCBPr-0006X7-1F; Fri, 07 Oct 2011 16:28:51 +0200 Message-ID: <4E8F0C9B.5060403@free.fr> Date: Fri, 07 Oct 2011 16:28:43 +0200 From: Jean-Marc Desperrier User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.20pre) Gecko/20110606 SeaMonkey/2.0.15pre MIME-Version: 1.0 To: Peter Gutmann , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Warning: IP [195.68.92.104] is listed at dnsbl.sorbs.net (127.0.0.10: Dynamic IP Addresses See: http://www.sorbs.net/lookup.shtml?195.68.92.104) X-ACL-Warn: 2/2 recipients OK. Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 14:25:54 -0000 Peter Gutmann wrote: > Speaking of SRP, I'm told the EKE patent expired a few days ago. True for US 5,241,599 : http://www.google.com/patents?id=LxgbAAAAEBAJ Filing date: Oct 2, 1991, Issue date: Aug 31, 1993 (US patent law for patents filed before Aug 95 : Valid for 20 years after filing date, or 17 years after issue date, whichever is longer ) Not true for US 5,440,635 : http://www.google.com/patents?id=ByMhAAAAEBAJ Filing date: Aug 23, 1993, Issue date: Aug 8, 1995 => Valid until Aug 23, 2013 Lucent used to claim both /could/ apply to SRP http://www.ietf.org/proceedings/53/slides/ips-9/tsld010.htm before reverting to a position of pure FUD on the subject http://www.ietf.org/proceedings/53/slides/ips-9/tsld011.htm From mrex@sap.com Fri Oct 7 10:55:45 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89F821F85B5 for ; Fri, 7 Oct 2011 10:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.074 X-Spam-Level: X-Spam-Status: No, score=-10.074 tagged_above=-999 required=5 tests=[AWL=0.175, 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 8ZzFyZk83XsR for ; Fri, 7 Oct 2011 10:55:45 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 31BF721F8C0E for ; Fri, 7 Oct 2011 10:55:44 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p97HwoH9017253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Oct 2011 19:58:55 +0200 (MEST) From: Martin Rex Message-Id: <201110071758.p97HwniX022621@fs4113.wdf.sap.corp> To: dharkins@lounge.org (Dan Harkins) Date: Fri, 7 Oct 2011 19:58:49 +0200 (MEST) In-Reply-To: <8d93ad0b8c3b53995c28a38cf8c6bf3e.squirrel@www.trepanning.net> from "Dan Harkins" at Oct 6, 11 02:03:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange 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, 07 Oct 2011 17:55:46 -0000 Dan Harkins wrote: > > The relation-- yours is "faster" than the unknown one-- means nothing. > That knowledge doesn't help. Knowing how many iterations the hunting- > and-pecking loop went through to find PE for an unknown password might > but the relationship between two means nothing. In fact, since both > sides are contributing randomness into the hunting-and-pecking loop > yours might be "faster" one time and considerably slower the next time. > That knowledge doesn't really help. The number of iterations for the hunting and pecking is visible in the timing unless a reliable response time blending is employed (which would have to account for an attacker running multiple requests in parallel to slow down server-side processing). Although both sides contribute randomness into the process, the only unknown in the low-entropy password, everything else is revealed. Since it is revealed, the attacker can use the timing "distance" between processing his own password and processing guessed passwords with the EXACT same parameters to sort out unlikely candidates. -Martin From rstruik.ext@gmail.com Fri Oct 7 11:37:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4B4921F8509 for ; Fri, 7 Oct 2011 11:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=1.177, 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 nNzd0GMZOZUo for ; Fri, 7 Oct 2011 11:37:20 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5836E21F8507 for ; Fri, 7 Oct 2011 11:37:20 -0700 (PDT) Received: by ggnk3 with SMTP id k3so3682067ggn.31 for ; Fri, 07 Oct 2011 11:40:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=C1P/BZQkUKEF7SLLrZThqkwnxKrqttQBJWHjHd1wwG8=; b=lTXVPocf3AArJkDJ+YaxS/LS2S4jmw8FP0xLzmJ0yGvW6khZAsDrgo7Emykxq1LDga HVYPAbmXTn62SPDsqx8CE1z8cSIbmkBjsreQc+CDyi3k+3jRHu0rtLkxsr9qjk+vR/eJ LnfdVx5xD8zfcG1y8nCDrNqOG6oTSz7RBj59E= Received: by 10.101.193.17 with SMTP id v17mr1789292anp.75.1318012834330; Fri, 07 Oct 2011 11:40:34 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.117.243]) by mx.google.com with ESMTPS id r12sm26909453anm.13.2011.10.07.11.40.32 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Oct 2011 11:40:33 -0700 (PDT) Message-ID: <4E8F4797.9000008@gmail.com> Date: Fri, 07 Oct 2011 14:40:23 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: mrex@sap.com References: <201110071758.p97HwniX022621@fs4113.wdf.sap.corp> In-Reply-To: <201110071758.p97HwniX022621@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.3.2 Content-Type: multipart/alternative; boundary="------------070807050900070700010805" Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 18:37:22 -0000 This is a multi-part message in MIME format. --------------070807050900070700010805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear colleagues: The discussion re draft-harkins-tls-pwd-00 seems to focus on two elements, viz.: 1) use case of password-based key agreement schemes and differentiation w.r.t. other IETF work products (EKE, etc.); 2) the mapping from passwords to elliptic curve points. As to #2, indeed, the procedure in Section 4.1.1 for mapping a password to a point on the curve ("hunting and pecking") has indeed a non-deterministic running time, due to "trial-and-error" approach and may, therefore, by vulnerable to a side channel attack. Note, however, that there are also deterministic methods for mapping a a value to a curve as introduced, e.g., in the Crypto 2010 paper by Icart, Coron, et al (cf. also IACR ePrint 2009-340) and the CRYPTO 2009 paper by Icart et al. The CRYPTO 2009 paper discusses the probabilistic method Dan Harkins describes (cf. Section 1.1 - Try and Increment Method; Section 5 - Practical Implementations). Table 1 of Section 6 (Try and Increment v3) provides results for an implementation that supposedly prevents potential leakage of information from determining whether x^3 + a x + b is a quadratic residue in GFp via the Legendre symbol computations. Thus, that paper suggests that side channel resistance can be dealt with, at the expense of time latency. The paper also illustrates that the deterministic method for "hashing to a curve" has better performance (again, refer to Table 1 of Section 6 of the CRYPTO 2009 paper). I hope this helps. Best regards, Rene On 07/10/2011 1:58 PM, Martin Rex wrote: > Dan Harkins wrote: >> The relation-- yours is "faster" than the unknown one-- means nothing. >> That knowledge doesn't help. Knowing how many iterations the hunting- >> and-pecking loop went through to find PE for an unknown password might >> but the relationship between two means nothing. In fact, since both >> sides are contributing randomness into the hunting-and-pecking loop >> yours might be "faster" one time and considerably slower the next time. >> That knowledge doesn't really help. > The number of iterations for the hunting and pecking is visible in the > timing unless a reliable response time blending is employed (which would > have to account for an attacker running multiple requests in parallel to > slow down server-side processing). > > Although both sides contribute randomness into the process, the only > unknown in the low-entropy password, everything else is revealed. > Since it is revealed, the attacker can use the timing "distance" > between processing his own password and processing guessed passwords > with the EXACT same parameters to sort out unlikely candidates. > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------070807050900070700010805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear colleagues:

The discussion re draft-harkins-tls-pwd-00 seems to focus on two elements, viz.:
1) use case of password-based key agreement schemes and differentiation w.r.t. other IETF work products (EKE, etc.);
2) the mapping from passwords to elliptic curve points.

As to #2, indeed, the procedure in Section 4.1.1 for mapping a password to a point on the curve ("hunting and pecking") has indeed a non-deterministic running time, due to “trial-and-error” approach and may, therefore, by vulnerable to a side channel attack. Note, however, that there are also deterministic methods for mapping a a value to a curve as introduced, e.g., in the Crypto 2010 paper by Icart, Coron, et al (cf. also IACR ePrint 2009-340) and the CRYPTO 2009 paper by Icart et al. The CRYPTO 2009 paper discusses the probabilistic method Dan Harkins describes (cf. Section 1.1 - Try and Increment Method; Section 5 - Practical Implementations). Table 1 of Section 6 (Try and Increment v3) provides results for an implementation that supposedly prevents potential leakage of information from determining whether x^3 + a x + b is a quadratic residue in GFp via the Legendre symbol computations. Thus, that paper suggests that side channel resistance can be dealt with, at the expense of time latency. The paper also illustrates that the deterministic method for "hashing to a curve" has better performance (again, refer to Table 1 of Section 6 of the CRYPTO 2009 paper).

I hope this helps.

Best regards, Rene


On 07/10/2011 1:58 PM, Martin Rex wrote: 
Dan Harkins wrote:

The relation-- yours is "faster" than the unknown one-- means nothing.
That knowledge doesn't help. Knowing how many iterations the hunting-
and-pecking loop went through to find PE for an unknown password might
but the relationship between two means nothing.  In fact, since both
sides are contributing randomness into the hunting-and-pecking loop
yours might be "faster" one time and considerably slower the next time.
That knowledge doesn't really help.

The number of iterations for the hunting and pecking is visible in the
timing unless a reliable response time blending is employed (which would
have to account for an attacker running multiple requests in parallel to
slow down server-side processing).

Although both sides contribute randomness into the process, the only
unknown in the low-entropy password, everything else is revealed.
Since it is revealed, the attacker can use the timing "distance"
between processing his own password and processing guessed passwords
with the EXACT same parameters to sort out unlikely candidates.

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



-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------070807050900070700010805-- From nico@cryptonector.com Fri Oct 7 14:06:32 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC23B21F8C2A for ; Fri, 7 Oct 2011 14:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=-0.532, 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 bvbI3JtQc4x8 for ; Fri, 7 Oct 2011 14:06:32 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 47DF721F8C0C for ; Fri, 7 Oct 2011 14:06:32 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id E19405406F for ; Fri, 7 Oct 2011 14:09:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=Ph1AufuGmPrlpj4YmX1WfUh1qH1z2ONvTi41jxhkeYoV 3p4OAfCpmT+ftmEkWt8+brGv/zj9zcBfslJkhnhTEfS1yYiT7sZpt1Z3tQikNGxL kCMrJwAPqf676JOeXVJOfMLM+t39WQp5CWSw02iMGj+F3UbCgMTCdpAEqwt9iNk= 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:content-transfer-encoding; s= cryptonector.com; bh=ZpDGO5IhGMlv9DoYwZZP8rHJThA=; b=vWOT36/TNo5 RKo2dPHIWZGFyy1GXg66L+9Mow9BLsR6i5DFIYwlyl2V1hxeGPdJX9xvHAe2sUmA JKjJbl/GH3meIWPSb0Vl6D0kZe5uhIBy92lkQmQ37IEBwhiWOJDWFxgqvPt5e+ht hwKuDl64K/cGZvqTC89dAjzVLeOedPq4= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id BC7D45401F for ; Fri, 7 Oct 2011 14:09:25 -0700 (PDT) Received: by ywm3 with SMTP id 3so4877004ywm.31 for ; Fri, 07 Oct 2011 14:09:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.232 with SMTP id l8mr16413025pbj.75.1318021764251; Fri, 07 Oct 2011 14:09:24 -0700 (PDT) Received: by 10.68.59.169 with HTTP; Fri, 7 Oct 2011 14:09:24 -0700 (PDT) In-Reply-To: <4E8F4797.9000008@gmail.com> References: <201110071758.p97HwniX022621@fs4113.wdf.sap.corp> <4E8F4797.9000008@gmail.com> Date: Fri, 7 Oct 2011 16:09:24 -0500 Message-ID: From: Nico Williams To: Rene Struik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 21:06:32 -0000 On Fri, Oct 7, 2011 at 1:40 PM, Rene Struik wrote: > 2) the mapping from passwords to elliptic curve points. > > As to #2, indeed, the procedure in Section 4.1.1 for mapping a password t= o a > point on the curve ("hunting and pecking") has indeed a non-deterministic > running time, due to =E2=80=9Ctrial-and-error=E2=80=9D approach and may, = therefore, by > vulnerable to a side channel attack. Note, however, that there are also > deterministic methods for mapping a a value to a curve as introduced, e.g= ., > in the Crypto 2010 paper by Icart, Coron, et al (cf. also IACR ePrint > 2009-340) and the CRYPTO 2009 paper by Icart et al. The CRYPTO 2009 paper > discusses the probabilistic method Dan Harkins describes (cf. Section 1.1= - > Try and Increment Method; Section 5 - Practical Implementations). Table 1= of > Section 6 (Try and Increment v3) provides results for an implementation t= hat > supposedly prevents potential leakage of information from determining > whether x^3 + a x + b is a quadratic residue in GFp via the Legendre symb= ol > computations. Thus, that paper suggests that side channel resistance can = be > dealt with, at the expense of time latency. The paper also illustrates th= at > the deterministic method for "hashing to a curve" has better performance > (again, refer to Table 1 of Section 6 of the CRYPTO 2009 paper). Curve25519 is trivial to generate private keys for. "Security Analysis of the PACE Key-Agreement Protocol", by Jens Bender, Marc Fischlin, and Dennis K=C3=BCgler discusses and refers to papers about hashing to point values. I like and recommend recommend PACE. Nico -- From pgut001@login01.cs.auckland.ac.nz Fri Oct 7 14:56:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862DB21F8BF4 for ; Fri, 7 Oct 2011 14:56:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.038 X-Spam-Level: X-Spam-Status: No, score=-3.038 tagged_above=-999 required=5 tests=[AWL=-0.439, 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 SpKBXbFs8r6T for ; Fri, 7 Oct 2011 14:56:10 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id B18D421F8B9C for ; Fri, 7 Oct 2011 14:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1318024765; x=1349560765; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20nico@cryptonector.com,=20rstruik.ext@gmail.com |Subject:=20Re:=20[TLS]=20draft=20on=20new=20TLS=20key=20 exchange|Cc:=20dhalasz@intwineenergy.com,=20tls@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Sat,=2008=20Oct =202011=2010:59:21=20+1300; bh=JGY+iPtoMerYCQrZSjOCOjYyl12HKmgO7Kkj1HLELlM=; b=Qck44D5T0ioLVe9/fAWkTcmlNS12hTzMuTld+FiKtdAMGneCMhAZv6B/ hC8m9Oj9g3i8Y0tFN2b0aPpz1rXEExZDUQnvnMqHQBG9q8QZTLomfVL2N 8R5F/phLeO1i3bYJLHAHuV1cdz8dBFVX45IeRCSrWujUztAmsGnn4KBsC I=; X-IronPort-AV: E=Sophos;i="4.68,504,1312113600"; d="scan'208";a="104484115" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Oct 2011 10:59:21 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RCIRt-00082V-GQ; Sat, 08 Oct 2011 10:59:21 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RCIRt-0003ME-1f; Sat, 08 Oct 2011 10:59:21 +1300 From: Peter Gutmann To: nico@cryptonector.com, rstruik.ext@gmail.com In-Reply-To: Message-Id: Date: Sat, 08 Oct 2011 10:59:21 +1300 Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 21:56:10 -0000 Nico Williams writes: >I like and recommend recommend PACE. I think it's interesting, but it's also waaaay too new. Anyone with a paper that potentially breaks it hasn't even had time to decide which conference to submit it to yet. Peter. From nico@cryptonector.com Fri Oct 7 15:05:10 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50D721F8C1F for ; Fri, 7 Oct 2011 15:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=-0.527, 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 6QCWoJis4r1b for ; Fri, 7 Oct 2011 15:05:10 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2368821F8BE7 for ; Fri, 7 Oct 2011 15:05:10 -0700 (PDT) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id 93D3C2AC065 for ; Fri, 7 Oct 2011 15:08:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=FMG9oi7PRiD9+RqmS+0Vv4QSCTn/iE6fCFgAmIUT2t46 7JGHRufR9JszlXKEldLsEAUsjIY9DMVn+IIOxbP4US/E0K54jhMLIOJ0x1Sx/kNr jb64ROSN0ttqC1R1mgHxGGmSqQkzzb3ZdUBL8sQygv8e+vC0Ti89yCp3OYEd3AQ= 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:content-transfer-encoding; s= cryptonector.com; bh=XLJQ7Fs6c7bWA7NpLLeBla2oFUs=; b=yGsMl/T6Uhd 0O8ZdWEZRQPc31syxN8nerNslgWa4eg4quEuxylDdiVNQs5Y/yOZwIfv4CSZ0N57 9JIhwyT36I+iTD/xcGXLy5de9jzqnjSM6NT0OLyiBKyMU7e332haEWx784LwFskg EV/wo6Y9GgCB25u5hs7SVW4AfNbraQnM= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 691D32AC064 for ; Fri, 7 Oct 2011 15:08:24 -0700 (PDT) Received: by gyd12 with SMTP id 12so4886989gyd.31 for ; Fri, 07 Oct 2011 15:08:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.31.131 with SMTP id a3mr16842565pbi.24.1318025303624; Fri, 07 Oct 2011 15:08:23 -0700 (PDT) Received: by 10.68.59.169 with HTTP; Fri, 7 Oct 2011 15:08:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 7 Oct 2011 17:08:23 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 22:05:10 -0000 On Fri, Oct 7, 2011 at 4:59 PM, Peter Gutmann w= rote: > Nico Williams writes: > >>I like and recommend recommend PACE. > > I think it's interesting, but it's also waaaay too new. =C2=A0Anyone with= a paper > that potentially breaks it hasn't even had time to decide which conferenc= e to > submit it to yet. J-PAKE's been around a few more years. Or wait until more patents expire. We've waited long enough... From pgut001@login01.cs.auckland.ac.nz Fri Oct 7 15:25:46 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846B221F8726 for ; Fri, 7 Oct 2011 15:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.031 X-Spam-Level: X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[AWL=-0.432, 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 kCD5VJ2LsF8n for ; Fri, 7 Oct 2011 15:25:45 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.12.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9330C21F8677 for ; Fri, 7 Oct 2011 15:25:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1318026540; x=1349562540; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20 |To:=20dharkins@lounge.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20draft=20on=20new=20TLS=20key=20 exchange|Cc:=20dhalasz@intwineenergy.com,=20tls@ietf.org |In-Reply-To:=20|Message-Id:=20|Date:=20Sat,=2008=20Oct=202011 =2011:28:59=20+1300; bh=iPVnFhADmPCMsQ7tv9H9IilBT/okTVSPkLoqHgx4dLQ=; b=QncxO7ZUkvROpXYcYSNT9oqEyRk33vLROMnT8gHLgw0sY8JakDkkmLCk J+uyN4XcrGjV9lYDRrvgeGqg5690TfWZVoEdQC0m2pH1oRegIJ8wDmetf kYEtWAEZoYW7oEamZQXcN9gS10U2igVIBfz9YuM+3Wo/YbFlJsE+CvN5r M=; X-IronPort-AV: E=Sophos;i="4.68,504,1312113600"; d="scan'208";a="104488740" X-Ironport-HAT: APP-SERVERS - $RELAYED X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 08 Oct 2011 11:28:59 +1300 Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RCIuZ-0000Oo-H5; Sat, 08 Oct 2011 11:28:59 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RCIuZ-0005O5-8H; Sat, 08 Oct 2011 11:28:59 +1300 From: Peter Gutmann To: dharkins@lounge.org, pgut001@cs.auckland.ac.nz In-Reply-To: Message-Id: Date: Sat, 08 Oct 2011 11:28:59 +1300 Cc: tls@ietf.org, dhalasz@intwineenergy.com Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 07 Oct 2011 22:25:46 -0000 "Dan Harkins" writes: >I'm sorry, but I don't understand. Are you asking questions of a different >PAKE scheme (PACE)? The PACE discussion pointed out problems in doing PAKE for ECDLP, which PACE was introduced to deal with. The scheme proposed in your draft is not PACE, and has no indication of where it came from or why it's secure. >Which RFC are you talking about? Your RFC draft. >Do you think there is something missing from the security considerations of >our draft? Is there some statement of security, or argument, you'd like to >see? Yes, something like a pointer to a conference/journal paper explaining where the scheme in the RFC draft came from and why it's secure. Peter. From Nilesh.Tayade@netscout.com Tue Oct 11 04:17:18 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B5421F8D52 for ; Tue, 11 Oct 2011 04:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 ETPtbUcdeob1 for ; Tue, 11 Oct 2011 04:17:17 -0700 (PDT) Received: from exprod6ob106.obsmtp.com (exprod6ob106.obsmtp.com [64.18.1.190]) by ietfa.amsl.com (Postfix) with SMTP id A89E921F8CE2 for ; Tue, 11 Oct 2011 04:17:17 -0700 (PDT) Received: from nsmailfe2k3.netscout.com ([12.187.89.175]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP; Tue, 11 Oct 2011 04:17:16 PDT Received: from nsmail.netscout.com ([192.168.39.90]) by nsmailfe2k3.netscout.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Oct 2011 07:17:08 -0400 Received: from [172.16.32.29] ([172.16.32.29]) by nsmail.netscout.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 11 Oct 2011 07:17:08 -0400 Message-ID: <4E9425B3.8070109@netscout.com> Date: Tue, 11 Oct 2011 16:47:07 +0530 From: nilesh Organization: NetScout User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13 MIME-Version: 1.0 To: tls@ietf.org Content-Type: multipart/mixed; boundary="------------050608040300010606010308" X-OriginalArrivalTime: 11 Oct 2011 11:17:08.0446 (UTC) FILETIME=[508CDFE0:01CC8807] X-TM-AS-Product-Ver: SMEX-10.0.0.4152-6.800.1017-18442.004 X-TM-AS-Result: No--17.772500-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [TLS] Regarding the length of encrypted premaster secret. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 11:17:18 -0000 This is a multi-part message in MIME format. --------------050608040300010606010308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I have setup an apache server with TLS/SSL support. And I could capture some https packets. Also I have written a dummy code to decrypt using AES algorithm. However, in the current trace file, the size of encrypted premaster sent from client is 130bytes. I tried first getting a premaster from the encrypted premaster and it failed (my program is correct as I verified it on different trace, also the server private key is correct as wireshark could decrypt using this key). If I remove initial 2bytes of encrypted premaster secret (make it 128bytes) - then I am able to decrypt it without failure. But the master_secret and key block generated are not correct then (the application data get decrypted to junk - again, I verified my code to generate master_secret and key block with different trace). rsa = RSA_new(); fp = fopen("server.key", "rb"); // error handling is done. PEM_read_RSAPrivateKey(fp, &rsa, NULL, NULL); RSA_check_key(rsa); // Below API fails with '-1' rc - when 130bytes encrypted_premaster is used. RSA_private_decrypt(pre_master_len, encrypted_premaster, pre_master, rsa, RSA_PKCS1_PADDING); Could someone please advise if I missed anything? Should the encrypted premaster be always 128bytes? I have attached the trace file and key file with the email. -- Thanks, Nilesh --------------050608040300010606010308 Content-Type: application/cap; name="dummy_https_traces.pcap" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dummy_https_traces.pcap" 1MOyoQIABAAAAAAAAAAAAP//AAABAAAAxgaUTjOMAgA+AAAAPgAAAAAjq2YbxQAmudaXuggA RQAAMF2xQACABqGxwKg8X8CoPbUFlgG78tfO/wAAAABwAv//v1kAAAIEBOwBAQQCxgaUTjyO AgA+AAAAPgAAAAAmudaXugAjq2YbxQgARQAAMAAAQAA/BkBjwKg9tcCoPF8BuwWW2HktifLX zwBwEhbQoa0AAAIEBbQBAQQCxgaUTmSOAgA2AAAANgAAAAAjq2YbxQAmudaXuggARQAAKF2y QACABqG4wKg8X8CoPbUFlgG78tfPANh5LYpQEP//5UEAAMYGlE4gjwIAxgAAAMYAAAAAI6tm G8UAJrnWl7oIAEUAALhds0AAgAahJ8CoPF/AqD21BZYBu/LXzwDYeS2KUBj//7cJAAAWAwEA iwEAAIcDAU6UBsYmHlUXbKg0+JIltIXf3NbkOBzn4MMvm4t/kBgVAABIAP/ACsAUAIgAhwA4 wA/ABQCEADUAOcAHwAnAEcATAEUARAAzADLADMAOwALABACWAEEABAAFAC/ACMASABYAE8AN wAP+/wAKAQAAFgAKAAgABgAXABgAGQALAAIBAAAjAADGBpROBJECADwAAAA8AAAAACa51pe6 ACOrZhvFCABFAAAoEvJAAD8GLXnAqD21wKg8XwG7BZbYeS2K8tfPkFAQGSDLkQAAAAAAAAAA xgaUTmqTAgASAwAAEgMAAAAmudaXugAjq2YbxQgARQADBBLzQAA/BiqcwKg9tcCoPF8BuwWW 2HktivLXz5BQGBkgJ+MAABYDAQAwAgAALAMBTpQGxWYlNH8JsbCHLpZCAJkMTprrfZTLJySC tKfzEvsAADUAAAQAIwAAFgMBApkLAAKVAAKSAAKPMIICizCCAfQCCQDs/l3gh0YnUTANBgkq hkiG9w0BAQUFADCBiTELMAkGA1UEBhMCSU4xCzAJBgNVBAgMAk1IMQswCQYDVQQHDAJQTjEQ MA4GA1UECgwHUFJJVkFURTERMA8GA1UECwwIUEVSU09OQUwxFzAVBgNVBAMMDjE5Mi4xNjgu NjEuMTgxMSIwIAYJKoZIhvcNAQkBFhNudEBvcmdhbml6YXRpb24uY29tMB4XDTExMTAxMTA5 MDA1OVoXDTEyMTAxMDA5MDA1OVowgYkxCzAJBgNVBAYTAklOMQswCQYDVQQIDAJNSDELMAkG A1UEBwwCUE4xEDAOBgNVBAoMB1BSSVZBVEUxETAPBgNVBAsMCFBFUlNPTkFMMRcwFQYDVQQD DA4xOTIuMTY4LjYxLjE4MTEiMCAGCSqGSIb3DQEJARYTbnRAb3JnYW5pemF0aW9uLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApG5TFAreLONgVZryQqavRxIvF876utxOY1Y0 ubpzS3hEPcZsaaQls2ECnQkEP3I92CfTsFpFd7c25CYjzBK4rt6ntjqCPHwkWQr4lkOLoyk2 P5F/XccjlCl/Cs4KvY2bLxkXqtWO7GaiN+s/V1M88qq7eRlLkH6no5n+hEyJ8D0CAwEAATAN BgkqhkiG9w0BAQUFAAOBgQAuHXZX5BfT/Bwbz7R8vw1k9HAvCMamepAAaYQZoGma5ZTmZhvu 7yuNk4DrQx4Qon+ms3GoPz4noBzl4Fzpcaoh7D+CPJ3fxC2B8n2H9ppz0Hcz97Woo/abESFy t3/708uQ1McU1OvhMd94zVDd32zJbC8ce5JmEhW7ewACVfZmfRYDAQAEDgAAAMYGlE60lgIA /AAAAPwAAAAAI6tmG8UAJrnWl7oIAEUAAO5dtkAAgAag7sCoPF/AqD21BZYBu/LXz5DYeTBm UBj9I5nMAAAWAwEAhhAAAIIAgHEmTDCfd5zslAwjkX0cUQcYSpQCuZBdoqa2NL6BxLwuAQ9V CSTnB5cG1W4Fplb8sfcsKp/pfuE4CBUi98soktQaUETYqRXjioIJjkSamQikYroDZqGQ3Bcw kJcxy3DXq3Z/u+KUZOjoE16V7LZ3fW7e3D3eEIpOk/LbDVzzTucoFAMBAAEBFgMBADDFi29o wdn7CfRUk1JU8q8LLXXJT5tjRCwFqF9jVG73aFuIobm8OIu0e/UOw6goVqLGBpROsZ0CAEAB AABAAQAAACa51pe6ACOrZhvFCABFAAEyEvRAAD8GLG3AqD21wKg8XwG7BZbYeTBm8tfQVlAY HVAl6AAAFgMBAMoEAADGAAAAAADAE2g3rgUHczkRtVAkM8NbI7tAUZxz+0k49S+nSDVBUMja 9KG82wSN7nBZWQ/XoLuyr585Nu9RuZ4agyPrScCPZSRI1h6qQsoYwxX5OoAsstbT8osxpKpR QADIR3wigHyi/XVskQp74GbVoEONGA2RLzB4pfsf40WHBMuwriiIkcSk4JNNL9U6UBEl955J TB5jp+ujqDZTOTwmzMPjhSsyel9cK5JpbOqAYjcaPCu3VR8QdfN5lwzOLl0zKASuF41uFAMB AAEBFgMBADANwW9Gs4A+WX4DbRuucH+HynjGkVVwmhYP04AM8x5MhS9rQeVVx7Fn/GxFd4J6 4BLGBpRO+MECAPsBAAD7AQAAACOrZhvFACa51pe6CABFAAHtXblAAIAGn+zAqDxfwKg9tQWW Abvy19BW2HkxcFAY/BmYigAAFwMBAcDHjdMTE518UOlxeGGP3Uww/3f4Q52UIOXJDKp24ym9 IeAoM+59vn/mAx7R1SVf4gWHa+99rapGW6AsGUrSBX5r171DAoKmTLf6RmOYBSuQ+ZuZYBnQ B0gL9uYAt/trJMcv3FhaGBFg3OjPmdWx5gPBCEd2LjIjPSuM6D652pMu3hESdsTMIs7HykEV OarpGmeyIPb/RQcGp6LxbJR60hJDHaDOuty3GuHl6NZmqz2ZBPpd6JZbvA14vpDG/ufC7VoP w7zllJ8hS9sveFPvsOEhZCLEJlPPZu2AAfpHI/z12M4Y+71MHgfs8kSRnhAnmeFQ/HvA5QaC givsgfuJzhb3Wgnsvpbgs6ElZGSk9NsKScq+zjwHY/WzHRaAeRFVp+/6Bp9TZlIRWjWqyAJd rGjDeGu5AqSwcdPciFQ5z0cOEaOvSy8sCIa6WxVhpmcnp8+drDc5sJWiFVSTN1CO4oJq/U3u Q0U5YxbHsh0gkRAormOdiwkVA2qLnjHd620s4MGhNExaJAFyJvG6smztvpPTeAy9DGbcPZic LuJGVeLnXjkQv/qZdk83JnRGdRGufqgogQgOUUBLBuiGbfQUp/3pxgaUTkTJAgAiBQAAIgUA AAAmudaXugAjq2YbxQgARQAFFBL1QAA/BiiKwKg9tcCoPF8BuwWW2HkxcPLX0htQECGAA2UA ABcDAQDgv2oHqpNxDOQBsdlyrVRtbKnDexQltYg2FMV5Mp421szBLIVOCdGsyobaGX4FwPyi RtDmN61cJjY5Yx62DW7zjS7ZS8KRlF0+TSzrMVyyDyvqlVVFyjeB8LLsKUWXmKe27oycwVEC 4iPPL0PM8dXOlJ5BLyOleNqLKkeJ96kyLNlRPsq0B3TRSntwxmoN8LT7Nj+pspZnnG+ogULP yOAbLUJ50IeBDVrWV5iOWprACFFImle4QI6ns4JjZOr51GGKlmbel2Q3Al4rAaFF8R+Cp+w5 zzrTsKY+czr9XzHZjaIXAwESIIqkE4XM71miS9A6PCmoWnCu1WHSsIcQiNz1oSDRCsN8FISx BIKcOUjd7AuTy4YbkXN2bcgw4j0X+8D1pjIH6EeH9KED/Fblo74s4fnheTtjlD/h77dML3/v GmdD3b/Fo+G16zPYYPkfzZk452FETlKlq9vqfKcxSN6mZWW6geNt84hKpjJNpuEfUlhU2Blx aCJwvPLuEG2MUnkfbbnXEKmebIO/pdOAGOTMeNor0j47QxrMQNg/BlVFkDCVoJLvxbpjSivQ Q5JjM+qPYUQeJmqpZMisQxvKH0AgxVQMLvr+OhTOkzVhsHqOQMR0cs+eYQBQPZzescs4/Qw2 jkYRm1y0Dl6LX94JTljYDxAXEEF6Z+J3/HoGX6iTroFipE4kGgCiSLKFzxbqpBvKl/kgzUT4 H6bI1tc5+A1FqnyOEeNRTO3jjG+qE9sejrP/0g+aYvfhckNRUSvng+YnjLzcasxZ+Ks+VmA4 ibjHenAjQ+ORn+Dv0sFdzqRxIBqSgpsqOj4kSiI1WOVARtnd0eg6cPpl6Vog5HjTbtBpj3JC gDcCYiFncrAru79+sB/kMlgL3DaU7rDTuQCKccmbe4shhDWOso0jyCW2T9aMmpr6k25aEjZG ARtT4byyt+jcAgks0dzZ7OVDF+SYISxfVm/VKP+91ZD28q4y5GxUvOuKotNrqggAgKqdlP4r 46PPsmrCEmSz+If8Ag53XNCibMbwLlPyL7X7CUhraQ4F5iZmWB4cr+cods5Uy0PZh3964AHC yMRlSTMc/jfSy2mu33RFgFYYyUaIzAjHbQY/wzcnLCCuEmdUl6a0eDUr0Fgz0vzsyIvCfKfT HPr17tW7vUp9+6I4GKLBhDRkMNwZxIWbVS1tDABlQNcd1PqAVCq2DouCV6VlHkHbYPFTHjTL e3RVTM3lI25vUKDXhHNfuXt+rq+Ni4DtaiWm6mmQmI9ura6MAnhFdhndAEr2V5AnX7lDtRa4 JhXITzQw1PAsxyd4y6daw/ooNQx2rWRkx/IVw6DiXypGqo3JsJ4AQCSclgm1SXN89dzwoLgm sfqT7gRnJKhLlqLHdtZEXjvP5ODfe7h/b/wSuR8Bft8fleIsK4LTI0asYbtEPuUQK2w4thOp 9P3JMN+IxiweyLDQePk7OjRbwSJjQ+haRxgsng3dF116VmOqy2odiDxLMhz/gE7q2sDk4ZjN LztzvRVEqP4bKooFkYhm2FP8vwSlIG8PzsmAg2jzAw78z/3qcestOms7N1RG7HIO2In65AyL gdf6AkxGBKXR1q5kKfX17TpgykmcaN+y7DukzDaKzqY1wNZ7tvafOCWPYEkk1ayAbIvio8DR /O86whBtZ/FzryGNKbb5J+4m2w== --------------050608040300010606010308 Content-Type: application/pgp-keys; name="server.key" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="server.key" -----BEGIN RSA PRIVATE KEY----- MIICWwIBAAKBgQCkblMUCt4s42BVmvJCpq9HEi8Xzvq63E5jVjS5unNLeEQ9xmxp pCWzYQKdCQQ/cj3YJ9OwWkV3tzbkJiPMEriu3qe2OoI8fCRZCviWQ4ujKTY/kX9d xyOUKX8Kzgq9jZsvGReq1Y7sZqI36z9XUzzyqrt5GUuQfqejmf6ETInwPQIDAQAB AoGAedqEWKsBIPTTtDziYYBTDnEsUxGA/685rCX7ZtQEkx4qPDlqqBMMGVW/8Q34 hugrap+BIgSTzHcLB6I4DwiksUpR08x0hf0oxqqjMo0KykhZDfUUfxR85JHUrFZM GznurVhfSBXX4Il9Tgc/RPzD32FZ6gaz9sFumJh0LKKadeECQQDWOfP6+nIAvmyH aRINErBSlK+xv2mZ4jEKvROIQmrpyNyoOStYLG/DRPlEzAIA6oQnowGgS6gwaibg g7yVTgBpAkEAxH6dcwhIDRTILvtUdKSWB6vdhtXFGdebaU4cuUOW2kWwPpyIj4XN D+rezwfptmeOr34DCA/QKCI/BWkbFDG2tQJAVAH971nvAuOp46AMeBvwETJFg8qw Oqw81x02X6TMEEm4Xi+tE7K5UTXnGld2Ia3VjUWbCaUhm3rFLB39Af/IoQJAUn/G o5GKjtN26SLk5sRjqXzjWcVPJ/Z6bdA6Bx71q1cvFFqsi3XmDxTRz6LG4arBIbWK mEvrXa5jP2ZN1EC7MQJAYTfwPZ8/4x/USmA4vx9FKdADdDoZnA9ZSwezWaqa44My bJ0SY/WmNU+Z4ldVIkcevwwwcxqLF399hjrXWhzlBQ== -----END RSA PRIVATE KEY----- --------------050608040300010606010308-- From juhovh@iki.fi Tue Oct 11 06:23:52 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1625821F8B89 for ; Tue, 11 Oct 2011 06:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 xpoNtqx-8kCL for ; Tue, 11 Oct 2011 06:23:51 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5519E21F8B30 for ; Tue, 11 Oct 2011 06:23:51 -0700 (PDT) Received: from mail.visino.fi (88.192.37.90) by kirsi1.inet.fi (8.5.133) id 4E8F89DD002CC8F3; Tue, 11 Oct 2011 16:23:49 +0300 Received: from [192.168.0.63] (62.1.179.109.dsl.dyn.forthnet.gr [62.1.179.109]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: juhovh) by mail.visino.fi (Postfix) with ESMTPSA id 6E03F1FF3B; Tue, 11 Oct 2011 16:23:48 +0300 (EEST) References: <4E9425B3.8070109@netscout.com> In-Reply-To: <4E9425B3.8070109@netscout.com> Mime-Version: 1.0 (iPhone Mail 8L1) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <990A24B9-E252-4A9B-BBBE-0900E82A0D1E@iki.fi> X-Mailer: iPhone Mail (8L1) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Tue, 11 Oct 2011 16:23:12 +0300 To: nilesh Cc: "tls@ietf.org" Subject: Re: [TLS] Regarding the length of encrypted premaster secret. X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:23:52 -0000 On 11.10.2011, at 14.17, nilesh wrote: > If I remove initial 2bytes of encrypted premaster secret (make it 128bytes= ) - then I am able to decrypt it without failure. In TLS 1.0 first two bytes is the length of encrypted premaster secret in by= tes, in SSL 3.0 they are not used. > But the master_secret and key block generated are not correct then (the ap= plication data get decrypted to junk - > again, I verified my code to generate master_secret and key block with dif= ferent trace). I would recommend verifying again. If the encrypted premaster decrypts to 48= bytes of data it is most likely correct and your problem is elsewhere. So c= heck that first. > Could someone please advise if I missed anything? Should the encrypted pre= master be always 128bytes? > I have attached the trace file and key file with the email. The length depends on RSA key size, with 1024-bit keys it is 128 bytes. I'm not looking at the trace file since I'm writing on my phone. However Wir= eshark has a very good SSL debug log feature that logs the premaster secret a= nd master secret and other useful information, use it for debugging. I don't think this list is the right place to debug own implementation thoug= h. Test your program against other widely used implementations, if it fails i= t is probably broken. Juho From anders.rundgren@telia.com Tue Oct 25 11:44:04 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA49B21F8481 for ; Tue, 25 Oct 2011 11:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 ikXzC3U2Pc5A for ; Tue, 25 Oct 2011 11:44:04 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id B8B4A21F84C3 for ; Tue, 25 Oct 2011 11:44:03 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E79D83A009BEC98; Tue, 25 Oct 2011 20:43:22 +0200 Message-ID: <4EA70342.3060608@telia.com> Date: Tue, 25 Oct 2011 20:43:14 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Edward O'Connor References: <4EA6AF25.7090706@telia.com> <4EA6C690.5070707@telia.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Harry Halpin , "'tls@ietf.org'" Subject: [TLS] Apple. Re: Web Identity WG Composition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 18:44:05 -0000 Hi Ted, >> It is also *forbidden* to speak openly about requirements if you work >> for a vendor like Apple or Microsoft. I have in past life worked for RSA Security and a thing that made me upset was that every suggestion you did had to go through the legal department due to potential IPR issues. Of course we can standardize web identity solutions but not based on innovation. That's why this activity is *doomed*. It well-known that US companies are abusing the patent system, and Apple is by no means an exception. In fact, the only reaction I have got on my "heroic" http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf effort are from various IPR-folks who claim that I'm infringing on their patents (which I have never read). However, I won't bring up this issue again. I continue on the stuff mentioned above which is more interesting than working with people who hide their technology like Google with their wallet. My hope is that the next.next generation of wallets will be powered by SKS/KeyGen2. There are no standardization effort for wallets :-) :-) There won't be one either because it is MUCH too political, and technical to be catered by an SDO! Regards, Anders On 2011-10-25 20:03, Edward O'Connor wrote: > -public-identity, +www-archive > > Hi Anders, > > You wrote: >> It is also *forbidden* to speak openly about requirements if you work >> for a vendor like Apple or Microsoft. > > I don't know why you think this, but I can assure you it is not the > case. As far as Apple goes, we in general refrain from discussing our > future products and release plans, but we actively participate in good > faith in many Web standards efforts. I'd prefer it if you didn't suggest > otherwise. > > > Thanks, > Ted > From anders.rundgren@telia.com Tue Oct 25 11:51:30 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6521F8AA8 for ; Tue, 25 Oct 2011 11:51:30 -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=[AWL=0.300, 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 rM4hcnz0bMCD for ; Tue, 25 Oct 2011 11:51:30 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5121F8A96 for ; Tue, 25 Oct 2011 11:51:30 -0700 (PDT) Received: from [192.168.0.200] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E79D85B00D39BD6 for tls@ietf.org; Tue, 25 Oct 2011 20:51:28 +0200 Message-ID: <4EA7052A.5050601@telia.com> Date: Tue, 25 Oct 2011 20:51:22 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "'tls@ietf.org'" References: <4EA6AF25.7090706@telia.com> <4EA6C690.5070707@telia.com> In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Apple. Re: Web Identity WG Composition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 18:51:30 -0000 This message went to TLS by a mistake from my side. Anders From hhalpin@w3.org Tue Oct 25 12:04:08 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140C211E809C for ; Tue, 25 Oct 2011 12:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=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 tJQTyvLQXAsG for ; Tue, 25 Oct 2011 12:04:07 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB011E809A for ; Tue, 25 Oct 2011 12:04:06 -0700 (PDT) Received: from www-data by jay.w3.org with local (Exim 4.69) (envelope-from ) id 1RImI6-0006pa-Sp; Tue, 25 Oct 2011 15:04:03 -0400 Received: from 24.191.100.23 (SquirrelMail authenticated user hhalpin) by webmail-mit.w3.org with HTTP; Tue, 25 Oct 2011 20:04:03 +0100 (BST) Message-ID: <14bbfd338e8083b7c965ff416edbf79d.squirrel@webmail-mit.w3.org> In-Reply-To: <4EA70342.3060608@telia.com> References: <4EA6AF25.7090706@telia.com> <4EA6C690.5070707@telia.com> <4EA70342.3060608@telia.com> Date: Tue, 25 Oct 2011 20:04:03 +0100 (BST) From: "Harry Halpin" To: "Anders Rundgren" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Thu, 27 Oct 2011 12:36:33 -0700 Cc: Harry Halpin , "'tls@ietf.org'" , Edward O'Connor Subject: Re: [TLS] Apple. Re: Web Identity WG Composition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 19:04:08 -0000 > Hi Ted, > >>> It is also *forbidden* to speak openly about requirements if you work >>> for a vendor like Apple or Microsoft. Anders, First, why are you emailing off-list from public-identity@w3.org and now adding tls@ietf.org? This has little to nothing to do with the TLS effort. It appears you have limited experience with the W3C given your previous misinformation about and now this email. Note that one reason why WGs can do work is companies agree to the W3C Royalty-Free Patent Policy as regards the charter of the W3C. Of course member companies may not agree if it is not in their business interest. However, for the benefit of the Web and their business, many companies operate in good faith, including Apple. I agree with Edward and would prefer if you did not suggest otherwise. I'm happy to point you to relevant documentation about the W3C, but let's do that off-list. If you wish to continue with a "personal" project, please do that off-list as well, and best of luck. And do not add any new lists to this thread or continue this thread on list, as basic operating knowledge of the W3C and IETF is assumed on these lists. I'm happy to respond more off-list. cheers, harry > > I have in past life worked for RSA Security and a thing that made > me upset was that every suggestion you did had to go through > the legal department due to potential IPR issues. > > Of course we can standardize web identity solutions but not based > on innovation. That's why this activity is *doomed*. > > It well-known that US companies are abusing the patent system, and > Apple is by no means an exception. > > In fact, the only reaction I have got on my "heroic" > > http://webpki.org/papers/keygen2/sks-keygen2-exec-level-presentation.pdf > > effort are from various IPR-folks who claim that I'm infringing on > their patents (which I have never read). > > However, I won't bring up this issue again. I continue on the stuff > mentioned above which is more interesting than working with people > who hide their technology like Google with their wallet. > > My hope is that the next.next generation of wallets will be powered by > SKS/KeyGen2. > > There are no standardization effort for wallets :-) :-) > > There won't be one either because it is MUCH too political, > and technical to be catered by an SDO! > > Regards, > Anders > > On 2011-10-25 20:03, Edward O'Connor wrote: >> -public-identity, +www-archive >> >> Hi Anders, >> >> You wrote: >>> It is also *forbidden* to speak openly about requirements if you work >>> for a vendor like Apple or Microsoft. >> >> I don't know why you think this, but I can assure you it is not the >> case. As far as Apple goes, we in general refrain from discussing our >> future products and release plans, but we actively participate in good >> faith in many Web standards efforts. I'd prefer it if you didn't suggest >> otherwise. >> >> >> Thanks, >> Ted >> > > From smb@cs.columbia.edu Sat Oct 29 09:48:38 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6955321F86C3 for ; Sat, 29 Oct 2011 09:48: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 kjSEo9XeNYK1 for ; Sat, 29 Oct 2011 09:48:37 -0700 (PDT) Received: from brinza.cc.columbia.edu (brinza.cc.columbia.edu [128.59.29.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9D09521F84C5 for ; Sat, 29 Oct 2011 09:48:37 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p9TGmTVc008188 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 29 Oct 2011 12:48:30 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Steven Bellovin In-Reply-To: Date: Sat, 29 Oct 2011 12:48:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8DDBF358-4669-4929-9658-C3CFF07BE9DD@cs.columbia.edu> References: To: Peter Gutmann X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.8 Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 29 Oct 2011 16:48:38 -0000 > Speaking of SRP, I'm told the EKE patent expired a few days ago. Speaking only for myself and not for Alcatel-Lucent, I think you're correct -- = http://patft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO1&Sect2=3DHITOFF&d=3D= PALL&p=3D1&u=3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D1&f=3DG&l=3D50&s1=3D5,2= 41,599.PN.&OS=3DPN/5,241,599&RS=3DPN/5,241,599 shows it was filed on October 2, 1991; my understanding is that was = valid for 20 years from date of filing. (It might have fallen into the = category of "the later of that date or 17 years from date of issue, but that = would have yielded an expiration date of August 31, 2010.) --Steve Bellovin, https://www.cs.columbia.edu/~smb From anders.rundgren@telia.com Sat Oct 29 09:57:11 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7572321F8A35 for ; Sat, 29 Oct 2011 09:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 VKdSnI5e+rJY for ; Sat, 29 Oct 2011 09:57:10 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 7107321F891D for ; Sat, 29 Oct 2011 09:57:10 -0700 (PDT) Received: from [192.168.0.204] (81.232.44.37) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 4E79D85B00EBF535; Sat, 29 Oct 2011 18:56:57 +0200 Message-ID: <4EAC304E.7070004@telia.com> Date: Sat, 29 Oct 2011 18:56:46 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Steven Bellovin References: <8DDBF358-4669-4929-9658-C3CFF07BE9DD@cs.columbia.edu> In-Reply-To: <8DDBF358-4669-4929-9658-C3CFF07BE9DD@cs.columbia.edu> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 29 Oct 2011 16:57:11 -0000 The "Window of opportunity" has also since long time passed. It must have been a very "profitable" patent :-) :-) Anders On 2011-10-29 18:48, Steven Bellovin wrote: >> Speaking of SRP, I'm told the EKE patent expired a few days ago. > > > Speaking only for myself and not for Alcatel-Lucent, I think you're > correct -- http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=5,241,599.PN.&OS=PN/5,241,599&RS=PN/5,241,599 > shows it was filed on October 2, 1991; my understanding is that was valid > for 20 years from date of filing. (It might have fallen into the category > of "the later of that date or 17 years from date of issue, but that would > have yielded an expiration date of August 31, 2010.) > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From smb@cs.columbia.edu Sat Oct 29 10:36:22 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC6521F89B8 for ; Sat, 29 Oct 2011 10:36:22 -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 fX3eBAD8h8oI for ; Sat, 29 Oct 2011 10:36:22 -0700 (PDT) Received: from paneer.cc.columbia.edu (paneer.cc.columbia.edu [128.59.29.4]) by ietfa.amsl.com (Postfix) with ESMTP id DBD7A21F85C7 for ; Sat, 29 Oct 2011 10:36:21 -0700 (PDT) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by paneer.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id p9THaEIs005114 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 29 Oct 2011 13:36:14 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Steven Bellovin In-Reply-To: <4EAC304E.7070004@telia.com> Date: Sat, 29 Oct 2011 13:36:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DDBF358-4669-4929-9658-C3CFF07BE9DD@cs.columbia.edu> <4EAC304E.7070004@telia.com> To: Anders Rundgren X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.4 Cc: dhalasz@intwineenergy.com, tls@ietf.org Subject: Re: [TLS] draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list 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, 29 Oct 2011 17:36:22 -0000 I don't know of any licensees, though of course since it went to Lucent when AT&T fissioned I have little knowledge of what happened after = 1996-7. On Oct 29, 2011, at 12:56 46PM, Anders Rundgren wrote: > The "Window of opportunity" has also since long time passed. > It must have been a very "profitable" patent :-) :-) >=20 > Anders >=20 > On 2011-10-29 18:48, Steven Bellovin wrote: >>> Speaking of SRP, I'm told the EKE patent expired a few days ago. >>=20 >>=20 >> Speaking only for myself and not for Alcatel-Lucent, I think you're >> correct -- = http://patft.uspto.gov/netacgi/nph-Parser?Sect1=3DPTO1&Sect2=3DHITOFF&d=3D= PALL&p=3D1&u=3D%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=3D1&f=3DG&l=3D50&s1=3D5,2= 41,599.PN.&OS=3DPN/5,241,599&RS=3DPN/5,241,599 >> shows it was filed on October 2, 1991; my understanding is that was = valid >> for 20 years from date of filing. (It might have fallen into the = category >> of "the later of that date or 17 years from date of issue, but that = would >> have yielded an expiration date of August 31, 2010.) >>=20 >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From jsalowey@cisco.com Sun Oct 30 22:05:54 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9445A21F8C75 for ; Sun, 30 Oct 2011 22:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 fRaW0Yn5rWOn for ; Sun, 30 Oct 2011 22:05:54 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6FF21F8BF4 for ; Sun, 30 Oct 2011 22:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=140; q=dns/txt; s=iport; t=1320037554; x=1321247154; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=pgTHw9t0i34bwH9E9jzCq34nzJmuWQuxY1P4FjK5qPM=; b=KVX0D4v9Hvl9FTTiN+uZnlhTQqTBCb6Olm4mCLbmHD8rKTW8p3rZ7mHU v6JRpuWOpXBTHu/J8IlVU/sjNeb+R5BP7Y/LHdoYqXARyvZhK1iNrDDfP bfwFOhsczC70g2Rk4fBQIbXHnwca2dQwzA0lvPjd2Llc5d6/Dy+gKxHU5 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An0GADUsrk6rRDoH/2dsb2JhbABDmiSPEIEFggsBJ4IynCGBJgGdRoghYQSIBowIhS2MUg X-IronPort-AV: E=Sophos;i="4.69,429,1315180800"; d="scan'208";a="11289396" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 31 Oct 2011 05:05:53 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9V55qCs010992 for ; Mon, 31 Oct 2011 05:05:53 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Oct 2011 22:06:22 -0700 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Agenda items for IETF 82 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 05:05:54 -0000 TLS is scheduled for Thursday, November 17 from 1740-1940. Please send = requests for agenda items to the chairs. =20 Thanks, Joe= From Masanobu.Katagi@jp.sony.com Mon Oct 31 02:34:16 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F319B21F8D6D for ; Mon, 31 Oct 2011 02:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06+fMmi3j-9V for ; Mon, 31 Oct 2011 02:34:15 -0700 (PDT) Received: from ms4.sony.co.jp (ms4.sony.co.jp [IPv6:2001:cf8:0:56::198]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC9B21F8D69 for ; Mon, 31 Oct 2011 02:34:14 -0700 (PDT) Received: from mta6.sony.co.jp (mta6.sony.co.jp [137.153.71.9]) by ms4.sony.co.jp (R8/Sony) with ESMTP id p9V9YBlh023282 for ; Mon, 31 Oct 2011 18:34:11 +0900 (JST) Received: from mta6.sony.co.jp (localhost [127.0.0.1]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p9V9YAZl001980 for ; Mon, 31 Oct 2011 18:34:10 +0900 (JST) Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p9V9YAdi001890 for ; Mon, 31 Oct 2011 18:34:10 +0900 (JST) Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 18:33:58 +0900 Received: from [43.11.214.45] ([43.11.214.45]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 18:33:58 +0900 Date: Mon, 31 Oct 2011 18:36:32 +0900 From: Masanobu Katagi To: "tls@ietf.org" In-Reply-To: <20110720193845.B694.1C812BE2@jp.sony.com> References: <20110705093341.940B.1C812BE2@jp.sony.com> <20110720193845.B694.1C812BE2@jp.sony.com> Message-Id: <20111031183631.D5E6.1C812BE2@jp.sony.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] (Unregistered) X-OriginalArrivalTime: 31 Oct 2011 09:33:58.0233 (UTC) FILETIME=[37285490:01CC97B0] Cc: "Moriai, Shiho" Subject: [TLS] Review of draft-katagi-tls-clefia-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, 31 Oct 2011 09:34:16 -0000 Hi all, I have updated the draft on TLS ciphersuites using the block cipher CLEFIA. http://tools.ietf.org/id/draft-katagi-tls-clefia-01.txt The main point of updates is related to the combinations with SHA-1. I tried to minimize the number of the ciphersuites based on the comments from this ML experts in July. Any comments would be appreciated. Best regards, Masanobu Katagi Sony Corporation On Wed, 20 Jul 2011 19:38:45 +0900 "Katagi, Masanobu" wrote: > Hi all, > > Thank you for valuable comments on our proposal of CLEFIA ciphersuites: > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt. > > In our draft above, we proposed a lot of combinations with SHA-1. > In response to the comments from the TLS working group, > we would like to remove the following sets of SHA-1 based ciphersuites: > - All combinations involving CLEFIA_256 (from viewpoint of equivalent security to SHA-1) > - Combinations involving not commonly used public key primitives > > Our updated proposal of SHA-1 based ciphersuites is as follows. > > CipherSuite TLS_RSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_DHE_DSS_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_DHE_RSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_DH_anon_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_ECDHE_ECDSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_ECDHE_RSA_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_PSK_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > CipherSuite TLS_DHE_PSK_WITH_CLEFIA_128_CBC_SHA = {TBD,TBD}; > > We are going to update this change in the next version of our draft. > > Best regards, > Masanobu Katagi > Sony Corporation > > On Tue, 5 Jul 2011 09:33:42 +0900 > "Katagi, Masanobu" wrote: > > Dear all, > > > > We have submitted the Internet draft that defines cipher suites to support CLEFIA in TLS. > > http://tools.ietf.org/id/draft-katagi-tls-clefia-00.txt > > > > CLEFIA is a 128-bit block cipher presented at FSE2007 and it is now used in commercial products. > > The algorithm of CLEFIA was published as RFC6114 in March 2011. > > CLEFIA is a lightweight block cipher compared with AES, Camellia, and SEED. > > We believe that CLEFIA will contribute to the Internet of Things as a lightweight cipher algorithm. > > > > The security and performance of CLEFIA have been evaluated through the CRYPTREC project > > which evaluates and monitors the security of Japan e-Government recommended ciphers. > > It also has been submitted to the ISO/IEC standard (ISO/IEC 29192, Lightweight cryptography) and it's > > in the Final Draft International Standard. > > > > Any comments on this draft would be appreciated. > > > > Best regards, > > Masanobu Katagi > > Sony Corporation > > > > Forwarded by Masanobu Katagi > > ----------------------- Original Message ----------------------- > > From: "internet-drafts@ietf.org" > > To: "Katagi, Masanobu" > > Cc: "Katagi, Masanobu" , > > "Moriai, Shiho" > > Date: Mon, 4 Jul 2011 17:51:44 +0900 > > Subject: New Version Notification for draft-katagi-tls-clefia-00.txt > > ---- > > > > A new version of I-D, draft-katagi-tls-clefia-00.txt has been successfully submitted by Masanobu Katagi and posted to the IETF repository. > > > > Filename: draft-katagi-tls-clefia > > Revision: 00 > > Title: CLEFIA Cipher Suites for Transport Layer Security (TLS) > > Creation date: 2011-07-04 > > WG ID: Individual Submission > > Number of pages: 16 > > > > Abstract: > > This document specifies a set of cipher suites for the Transport > > Security Layer (TLS) protocol to support the CLEFIA encryption > > algorithm as a block cipher. CLEFIA is a lightweight block cipher > > and suitable for constrained devices. > > > > > > > > > > The IETF Secretariat > > > > > > --------------------- Original Message Ends -------------------- > > > > > From dharkins@lounge.org Mon Oct 31 16:08:28 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6ADC11E81BD for ; Mon, 31 Oct 2011 16:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.521 X-Spam-Level: X-Spam-Status: No, score=-5.521 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, 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 MIR+8ZzjNtsJ for ; Mon, 31 Oct 2011 16:08:28 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 756E411E815B for ; Mon, 31 Oct 2011 16:08:28 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2B1B1A88810C for ; Mon, 31 Oct 2011 16:08:28 -0700 (PDT) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 31 Oct 2011 16:08:28 -0700 (PDT) Message-ID: Date: Mon, 31 Oct 2011 16:08:28 -0700 (PDT) From: "Dan Harkins" To: tls@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [TLS] new version of draft on new TLS key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:08:28 -0000 Hello, We updated the draft to incorporate comments received on the list. Please take a look. We solicit further comment. http://tools.ietf.org/html/draft-harkins-tls-pwd-01 regards, Dave and Dan. From paul@xelerance.com Mon Oct 31 16:23:02 2011 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0001F0D6D for ; Mon, 31 Oct 2011 16:23:02 -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 pB6XZfjYZI9b for ; Mon, 31 Oct 2011 16:23:00 -0700 (PDT) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 616151F0D52 for ; Mon, 31 Oct 2011 16:23:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 5FF567EB for ; Mon, 31 Oct 2011 19:22:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:message-id :subject:subject:from:from:date:date:received:received:received :received; s=smtp; t=1320103377; x=1320708177; bh=1ADsypwaj852/I T5gKMXu3cCUFgzNs0g8QpcyrZu3mo=; b=LlYTqH+a3+CB9O3VKBXaWZvq5D/5HP nVzG6KNU+Y6Q5/UjW+T9iLP/FOghI6qMhbpxeqbhZoxrOK6NA/MSfLji4WYByYNS qxKenGK1HNgM4KKoiP1V0s5iHs4n+7OY9RM4BXnh2q76RQtmLsdU181tTtDeSE6d LHKiv/vnVU67c= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id 0awqw24FblYN for ; Mon, 31 Oct 2011 19:22:57 -0400 (EDT) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 077707F2 for ; Mon, 31 Oct 2011 19:21:12 -0400 (EDT) Received: by mail.xelerance.com (Postfix, from userid 1001) id C9A8292D; Mon, 31 Oct 2011 19:21:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id C09DE917 for ; Mon, 31 Oct 2011 19:21:11 -0400 (EDT) Date: Mon, 31 Oct 2011 19:21:11 -0400 (EDT) From: Paul Wouters To: tls@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:23:02 -0000 This is the new version of the draft incorporating the feedback from Quebec City and the TLS list since then. It changes the draft from a new TLS extension to a new Certificate Type for raw keys. It also merges in the unpublished draft material from Hannes Tschofenig and Tero Kivinen whom had also been working on raw RSA TLS keys for use with CoAP (eg devices with no real time clock where PKIX validation cannot work) I did not yet change the draft ofrom individual submission to working group item, as I was waiting for confirmation on the TLW WG list of the last Quebec City meeting. http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 Paul ---------- Forwarded message ---------- Date: Mon, 31 Oct 2011 17:44:35 From: internet-drafts@ietf.org Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, paul@xelerance.com, kivinen@iki.fi To: paul@xelerance.com Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt X-Spam-Flag: NO A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-wouters-tls-oob-pubkey Revision: 01 Title: TLS out-of-band public key validation Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 11 Abstract: This document specifies a new TLS certificate type for exchanging raw public keys or their fingerprints in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake. The IETF Secretariat