From tls-bounces@lists.ietf.org Mon Apr 23 15:50:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4YH-0003bv-QE; Mon, 23 Apr 2007 15:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Xz-0003Ck-Tx; Mon, 23 Apr 2007 15:50:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hg4Xz-0005rE-KB; Mon, 23 Apr 2007 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 29F0526FE6; Mon, 23 Apr 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hg4Xy-0004DP-S0; Mon, 23 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-new-mac-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode Author(s) : E. Rescorla Filename : draft-ietf-tls-ecc-new-mac-00.txt Pages : 8 Date : 2007-4-23 RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 as their MAC algorithm. This document describes eight new CipherSuites for TLS/DTLS which specify stronger digest algorithms. Four use HMAC with SHA-256 or SHA-384 and four use AES in Galois Counter Mode (GCM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-new-mac-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-ecc-new-mac-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-ecc-new-mac-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-23124755.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-new-mac-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-new-mac-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-23124755.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon Apr 23 16:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Zh-0007If-V3; Mon, 23 Apr 2007 15:51:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg4Z0-0005SM-7K; Mon, 23 Apr 2007 15:51:06 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Hg4Yy-00084v-Vb; Mon, 23 Apr 2007 15:51:06 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 130FE176B7; Mon, 23 Apr 2007 19:50:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Hg4Xy-0004DM-RM; Mon, 23 Apr 2007 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Apr 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-suiteb-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Suite B Cipher Suites for TLS Author(s) : M. Salter, E. Rescorla Filename : draft-ietf-tls-suiteb-00.txt Pages : 8 Date : 2007-4-23 The United States Government has published guidelines for "NSA Suite B Cryptography" dated July, 2005, which defines cryptographic algorithm polcy for national security applications. This document defines a profile of TLS which is conformant with Suite B. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-suiteb-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-suiteb-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-suiteb-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-4-23124404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-suiteb-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-suiteb-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-4-23124404.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Wed Apr 25 07:58:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgg8L-0003PG-Ih; Wed, 25 Apr 2007 07:58:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgg8K-0003PB-9v for tls@ietf.org; Wed, 25 Apr 2007 07:58:04 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgg8J-0003Hl-Si for tls@ietf.org; Wed, 25 Apr 2007 07:58:04 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l3PBvupr019691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 25 Apr 2007 13:58:00 +0200 X-Hashcash: 1:22:070425:tls@ietf.org::/WnwgM1YAYa1tsj0:vj6O From: Simon Josefsson To: tls@ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 25 Apr 2007 13:57:56 +0200 Message-ID: <87slao8y4b.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.98 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.8 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [TLS] Will CAs decide server signing algorithms in TLS 1.2? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The Signature structure has changed, and the current text in section 7.4.3 says: If the SignatureAlgorithm being used to sign the ServerKeyExchange message is DSA, the hash function used MUST be SHA-1. If the SignatureAlgorithm it must be the same hash function used in the ^^^^^^^^^^^^^^^^ signature of the server's certificate (found in the Certificate) message. This algorithm is denoted Hash below. Hash.length is the length of the output of that algorithm. I can't parse the second sentence here. What is the intention here? I'm assuming that the intention is to say that the SignatureAlgorithm must be the same as the signing algorithm in the server certificate. It seems weird that the CA who signs the server certificate will implicitly decide which signature algorithm is used inside TLS between all servers and clients. As far as I can tell, it is not possible for a server or client to negotiate the use of another hash algorithm (for the purpose of key exchange and certificate verification) than what the CA used to sign the certificates with, given the above text. That seems sub-optimal. Two examples of real-world problems: 1) A server and/or client have RSA-SHA1 certificates. They wish to use RSA-SHA256 in the ServerKeyExchange and CertificateVerify messages, but they can't negotiate that. 2) A server and/or client have RSA-MD5 certificates (there are many of these out there). They wish to use RSA-SHA1 or RSA-SHA256 in the ServerKeyExchange and CertificateVerify messages, but they can't negotiate that. An argument that using RSA-SHA256 (or RSA-SHA1), when the server certificate is signed using RSA-SHA1 (or RSA-MD5), do not increase the security is flawed. It is possible for clients to check a server's certificate fingerprint out of band, and essentially thus trust the server certificate directly. In this situation, the signature algorithm used in the server certificate is never used for verification, and thus does not influence the overall security. This is what some implementations use to achieve "leap-of-faith" security against untrusted servers. With the current text, the overall security is restricted by what the server and client CA's have chosen. I predict that RSA-SHA256 certificates will cost ten times as much as RSA-SHA1 certificates if this text stays... /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Apr 30 07:47:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUKT-0006Pw-7Q; Mon, 30 Apr 2007 07:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiUKR-0006Ov-6z for tls@ietf.org; Mon, 30 Apr 2007 07:46:03 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiUKP-0005UB-PF for tls@ietf.org; Mon, 30 Apr 2007 07:46:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l3UBjr8H008031 for ; Mon, 30 Apr 2007 14:45:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 14:45:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 14:45:51 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 30 Apr 2007 14:45:50 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Update on draft-ietf-tls-suiteb Thread-Index: AceLHRna1LCQO9hrRHa1Xrmhy4DSsg== From: To: X-OriginalArrivalTime: 30 Apr 2007 11:45:51.0706 (UTC) FILETIME=[1A6DBBA0:01C78B1D] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Subject: [TLS] Update on draft-ietf-tls-suiteb X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Folks, As you've noticed, Eric posted an update of the ECC/GCM/SHA-256/384 draft, now split to two separate documents: one containing the new cipher suites (draft-ietf-tls-ecc-new-mac) and the other containing Suite B compliance text (draft-ietf-tls-suiteb). I've asked the secretariat to remove draft-ietf-tls-suiteb-00 from=20 the I-D repository. It was posted without waiting for my approval=20 (the secretariat didn't probably notice that Eric as co-author=20 shouldn't approve his own documents), and I think we need=20 separate discussion before accepting it as WG item. (The first part, draft-ietf-tls-ecc-new-mac, is fine, though.) In particular, if the purpose of the draft is to document what NSA considers an acceptable profile or subset of TLS, then its contents are really decided by NSA (as represented by one of the authors), not TLS WG rough consensus. As such, it's probably best to keep it as an individual document, and publish it as RFC via either the=20 AD-sponsored or independent submission route. Of course, I'm sure the authors welcome comments about the=20 document, we can certainly discuss those on this mailing list. Let me know (either privately or on the list) if you have any=20 comments or concerns about this approach. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls