From tls-bounces@lists.ietf.org Sat Dec 01 22:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyfOb-0005G5-Gc; Sat, 01 Dec 2007 22:21:29 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IyfOa-00056C-AR for tls-confirm+ok@megatron.ietf.org; Sat, 01 Dec 2007 22:21:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyfOZ-00053T-Q4 for tls@ietf.org; Sat, 01 Dec 2007 22:21:27 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyfOZ-0001mK-3P for tls@ietf.org; Sat, 01 Dec 2007 22:21:27 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Sun, 2 Dec 2007 03:21:26 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Sun, 2 Dec 2007 03:21:26 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" , "tls@ietf.org" Date: Sun, 2 Dec 2007 03:21:02 +0000 Thread-Topic: WGLC for draft-ietf-tls-rfc4346-bis-07 Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIgDnBkoQ Message-ID: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Subject: [TLS] RE: WGLC for draft-ietf-tls-rfc4346-bis-07 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 I would like to submit the following Last Call comments on TLS 1.2 1) Terminology: CipherSuite, ciphersuite or cipher suite. And CipherSuites = or cipher suites The document currently includes all flavors of the above term. It would be = better to select one form and stick to it. 2) Custom signature/digest algorithms for local use or test purposes. TLS allows definition of cipher suites for private use (0xFF,0x00-FF). It w= ould be reasonable to also allocate a name space for private use also for h= ash algorithms and signature algorithms. If not, the private cipher suites = can't be used. 3) Multiple hash alternatives. In order to verify the CertificateVerify message the server must hash previ= ous messages from the client. This can be problematic if the client is stil= l allowed to choose more than one hash algorithm. In this case the server m= ust store all previous messages and hash them after receiving CertificateVe= rify or hash them with all possible hash algorithms when received. This cou= ld open for DoS and flooding attacks, dependent on the server design, if at= tack messages are constructed to be as long as legally possible. The commen= t is only to highlight the issue rather than suggesting any changes. The se= rver can mitigate this by always limiting the hash choices to only one hash= algorithm in the Certificate Request message. Perhaps this should be menti= oned in the security considerations section. 4) Stepping up the choice of hash? If the client doesn't specify any hash algorithm, the server MUST use SHA-1= in the server key exchange message. (7.4.3) "If no "signature_algorithms" = extension is present , the server MUST use SHA-1 as the hash algorithm." Th= e client is however not obligated to declare any signature_algorithms (7.4.= 1.4.1) "Clients SHOULD send this extension if they support any hash algorit= hm other than SHA-1." But what if the server has knowledge that the client does support a better = hash? For example, the selected key exchange algorithm is derived from a ci= pher suite defining a PRF based on a better hash. Would it be reasonable to= allow the Server to make use of the better hash algorithm? 5) Error: supported_signature_types -> Supported_signature_algorithms The following paragraphs in 7.4.4 contains 2 instances of supported_signatu= re_types with is not defined in this spec. Should be "supported_signature_a= lgorithms". - Any certificates provided by the client MUST be signed using a hash/signature algorithm pair found in supported_signature_types. - The end-entity certificate provided by the client MUST contain a key which is compatible with certificate_types. If the key is a signature key, it MUST be usable with some hash/signature algorithm pair in supported_signature_types. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 27 november 2007 13:58 > To: tls@ietf.org > Subject: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07 > > > This message starts a WG last call on draft-ietf-tls-rfc4346-bis-07, > prior to sending it to the IESG for publication as Proposed Standard. > > Please send your comments to the WG mailing list by Wednesday > December 19th. Comments along the lines "I've read it and it looks > OK" are helpful and encouraged. > > The last call period is longer than usual to accommodate for > the IETF meeting, but if you manage to do some reading on your > flight to Vancouver, your comments can be discussed face-to-face > there. > > Best regards, > Pasi > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 03 13:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGMG-0002jT-P4; Mon, 03 Dec 2007 13:49:32 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzGMG-0002fA-3r for tls-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:49:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzGMF-0002dR-OJ for tls@ietf.org; Mon, 03 Dec 2007 13:49:31 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzGMD-0001h9-48 for tls@ietf.org; Mon, 03 Dec 2007 13:49:31 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB3InCvi028938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Dec 2007 19:49:15 +0100 X-Hashcash: 1:22:071203:ekr@networkresonance.com::UkgQsBYxDuIjJYac:5qhN X-Hashcash: 1:22:071203:tls@ietf.org::9uFG/Bs9Zs1xFPWt:3ZTF From: Simon Josefsson To: ekr@networkresonance.com OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Mon, 03 Dec 2007 19:49:29 +0100 Message-ID: <877ijvpq9y.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org Subject: [TLS] draft-rescorla-tls-extractor-01: support and comments on IANA section 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 Eric, WG, I have read this draft, believe it is useful, and think that the WG should adopt it. (I missed parts of the WG meeting, so maybe this was already decided.) I have two comments regarding the IANA section which currently contains: Future values are allocated via RFC2434 Specification Required policy. The label is a string consisting of printable ASCII characters. IANA MUST also verify that one label is not a prefix of any other label. For example, labels "key" or "master secretary" are forbidden. 1) I think the IANA section should permit some simple first-come-first-serve based registration, possibly under a special label prefix like 'EXTRACTOR-FCFS-'. Sometimes the 'Specification Required' part is problematic, and I see no harm in permitting a FCFS-based registration process. 2) There is no reference in the IANA section about what 'printable ASCII' means. I think saying something like [A-Za-z0-9-_+.] is better. Thanks, /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 04 15:35: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 1IzeTs-0004VL-Ha; Tue, 04 Dec 2007 15:35:00 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzeTp-0004T0-IE for tls-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 15:34:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzeTp-0004Se-7y for tls@ietf.org; Tue, 04 Dec 2007 15:34:57 -0500 Received: from michael.checkpoint.com ([194.29.32.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzeTo-0003vP-72 for tls@ietf.org; Tue, 04 Dec 2007 15:34:57 -0500 Received: from yaronflap (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id lB4KYjOY004923; Tue, 4 Dec 2007 22:34:50 +0200 (IST) From: "Yaron Sheffer" To: "'Simon Josefsson'" , References: <877ijvpq9y.fsf@mocca.josefsson.org> Subject: RE: [TLS] draft-rescorla-tls-extractor-01: support and comments on IANAsection Date: Tue, 4 Dec 2007 12:34:44 -0800 Message-ID: <004401c836b5$2020f370$cd148182@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg2pgeJ8l4SX5o4QniU9rBlRZvxSgADiRnA In-Reply-To: <877ijvpq9y.fsf@mocca.josefsson.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@ietf.org 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 Comment below, Yaron -----Original Message----- From: Simon Josefsson [mailto:simon@josefsson.org] Sent: Monday, December 03, 2007 10:49 AM To: ekr@networkresonance.com Cc: tls@ietf.org Subject: [TLS] draft-rescorla-tls-extractor-01: support and comments on IANAsection Eric, WG, I have read this draft, believe it is useful, and think that the WG should adopt it. (I missed parts of the WG meeting, so maybe this was already decided.) I have two comments regarding the IANA section which currently contains: Future values are allocated via RFC2434 Specification Required policy. The label is a string consisting of printable ASCII characters. IANA MUST also verify that one label is not a prefix of any other label. For example, labels "key" or "master secretary" are forbidden. 1) I think the IANA section should permit some simple first-come-first-serve based registration, possibly under a special label prefix like 'EXTRACTOR-FCFS-'. Sometimes the 'Specification Required' part is problematic, and I see no harm in permitting a FCFS-based registration process. [YS] This is an unlimited namespace so we can go one better by requiring NO registration. We can have a special prefix "EXTRACTOR-PRIVATE-" where "name" is a DNS name owned by the entity defining the consumer application, and it's that entity's responsibility to manage their own namespace. 2) There is no reference in the IANA section about what 'printable ASCII' means. I think saying something like [A-Za-z0-9-_+.] is better. Thanks, /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 04 22:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzklY-0008Ki-Ix; Tue, 04 Dec 2007 22:17:40 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzklX-0008J2-Go for tls-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 22:17:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzklX-0008IK-6M for tls@ietf.org; Tue, 04 Dec 2007 22:17:39 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzklW-0006W3-T1 for tls@ietf.org; Tue, 04 Dec 2007 22:17:39 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB53HnDv005569 for ; Tue, 4 Dec 2007 21:17:52 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 05:16:59 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Dec 2007 05:17:00 +0200 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: Wed, 5 Dec 2007 05:16:59 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Keying material extractor as WG item Thread-Index: Acg27UyCIl5OsC+jQ122bxg4T1iG/g== From: To: X-OriginalArrivalTime: 05 Dec 2007 03:17:00.0313 (UTC) FILETIME=[4CC42090:01C836ED] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] Keying material extractor as WG item 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 meeting in Vancouver yesterday supported adopting=20 draft-rescorla-tls-extractor as a TLS working group document. As usual, the WG consensus needs to be confirmed on the mailing=20 list. Please mail me and Eric (or the whole list) if you object=20 to using this document as starting point for further WG work.=20 (If you have a comment about some technical detail, please use a separate thread and change the subject line. It is known=20 that the draft is not finished yet.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 04:24:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzqUU-0001jC-Od; Wed, 05 Dec 2007 04:24:26 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzqUU-0001j7-3r for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 04:24:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzqUT-0001iy-O7 for tls@ietf.org; Wed, 05 Dec 2007 04:24:25 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzqUR-0006Bg-RR for tls@ietf.org; Wed, 05 Dec 2007 04:24:25 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB59O5Jv012622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 10:24:06 +0100 From: Simon Josefsson To: "Yaron Sheffer" References: <877ijvpq9y.fsf@mocca.josefsson.org> <004401c836b5$2020f370$cd148182@ad.checkpoint.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071205:tls@ietf.org::+jFlIpExxfIKjQGb:ANgH X-Hashcash: 1:22:071205:ekr@networkresonance.com::UM13tWWsRQRkyoY6:8AGR X-Hashcash: 1:22:071205:yaronf@checkpoint.com::xR8cKVyTGeClIAbj:5nTX Date: Wed, 05 Dec 2007 10:24:03 +0100 In-Reply-To: <004401c836b5$2020f370$cd148182@ad.checkpoint.com> (Yaron Sheffer's message of "Tue, 4 Dec 2007 12:34:44 -0800") Message-ID: <87k5nta40c.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org Subject: [TLS] Re: draft-rescorla-tls-extractor-01: support and comments on IANAsection 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 "Yaron Sheffer" writes: > 1) I think the IANA section should permit some simple > first-come-first-serve based registration, possibly under a special > label prefix like 'EXTRACTOR-FCFS-'. Sometimes the 'Specification > Required' part is problematic, and I see no harm in permitting a > FCFS-based registration process. > > [YS] This is an unlimited namespace so we can go one better by requiring NO > registration. We can have a special prefix "EXTRACTOR-PRIVATE-" where > "name" is a DNS name owned by the entity defining the consumer application, > and it's that entity's responsibility to manage their own namespace. I like that in principle. However, it would be more complex to specify and there are potential conflicts since DNS names expire. Maybe it is not worth it. This suggest that it may be useful to be able to register a name "family" though. For example, if you register EXTRACTOR-FCFS-FOOBAR you should be able to use everything under that prefix in your own protocol, e.g. EXTRACTOR-FCFS-FOOBAR-FIRST, EXTRACTOR-FCFS-FOOBAR-SECOND etc. Some protocols may need more than one label, and it isn't entirely impossible that some of the labels may even be generated on the fly. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 09:40:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvQJ-0001oF-6d; Wed, 05 Dec 2007 09:40:27 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzvQI-0001kj-69 for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 09:40:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzvQH-0001jH-QC for tls@ietf.org; Wed, 05 Dec 2007 09:40:25 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzvQH-00033s-Af for tls@ietf.org; Wed, 05 Dec 2007 09:40:25 -0500 Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id lB5EeQxk029273; Wed, 5 Dec 2007 15:40:26 +0100 (MET) From: Martin Rex Message-Id: <200712051440.lB5EeN8Z012631@fs4113.wdf.sap.corp> Subject: Re: [TLS] Keying material extractor as WG item To: Pasi.Eronen@nokia.com Date: Wed, 5 Dec 2007 15:40:23 +0100 (MET) In-Reply-To: from "Pasi.Eronen@nokia.com" at Dec 5, 7 05:16:59 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > > The meeting in Vancouver yesterday supported adopting > draft-rescorla-tls-extractor as a TLS working group document. > > As usual, the WG consensus needs to be confirmed on the mailing > list. Please mail me and Eric (or the whole list) if you object > to using this document as starting point for further WG work. I do support this. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 10:33:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwFe-00085f-7s; Wed, 05 Dec 2007 10:33:30 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzwFd-0007xS-2D for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 10:33:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzwFc-0007ut-N4 for tls@ietf.org; Wed, 05 Dec 2007 10:33:28 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzwFa-0003rE-Cw for tls@ietf.org; Wed, 05 Dec 2007 10:33:28 -0500 Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id lB5FXQ8u010440 for ; Wed, 5 Dec 2007 16:33:26 +0100 (MET) From: Martin Rex Message-Id: <200712051533.lB5FXO0c016470@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Wed, 5 Dec 2007 16:33:24 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: Subject: [TLS] Scope of draft-rescorla-tls-extractor X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org The currently proposed scope of draft-rescorla-tls-extractor seems to be similar to the gss_prf approach in GSS-API. I believe, however, that a wider scope would be better. When combining TLS channel protection with other authentication technologies (like GSS-API authentication), one should have a means to "mix" entropy from one (cryptographic) protocol exchange into the session key of the other that is used for protection of the communication in order to provide a cryptographically secure channel binding. It would be the duty of the upper protocol layers using such a mix-in-entropy functionality in TLS to do it synchronously at both ends of the secure TLS communication channel. Ultimately the eap authentication for TLS should use this path as well, rather than messing with the TLS handshake protocol and TLS state engine. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 12:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izxus-0006dZ-U0; Wed, 05 Dec 2007 12:20:10 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Izxur-0006cl-4o for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 12:20:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izxuq-0006cc-RD for tls@ietf.org; Wed, 05 Dec 2007 12:20:08 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izxuo-0006qz-T8 for tls@ietf.org; Wed, 05 Dec 2007 12:20:08 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB5HJu7c016453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 18:19:57 +0100 From: Simon Josefsson To: martin.rex@sap.com References: <200712051533.lB5FXO0c016470@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071205:martin.rex@sap.com::5EIerRGI0uwoJxFM:5AUL X-Hashcash: 1:22:071205:tls@ietf.org::gnf0/p0811lYDSuN:HKwn Date: Wed, 05 Dec 2007 18:19:55 +0100 In-Reply-To: <200712051533.lB5FXO0c016470@fs4113.wdf.sap.corp> (Martin Rex's message of "Wed, 5 Dec 2007 16:33:24 +0100 (MET)") Message-ID: <874pexukhw.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org Subject: [TLS] Re: Scope of draft-rescorla-tls-extractor 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 Martin Rex writes: > The currently proposed scope of draft-rescorla-tls-extractor seems to > be similar to the gss_prf approach in GSS-API. > > I believe, however, that a wider scope would be better. > When combining TLS channel protection with other authentication > technologies (like GSS-API authentication), one should have > a means to "mix" entropy from one (cryptographic) protocol > exchange into the session key of the other that is used > for protection of the communication in order to provide > a cryptographically secure channel binding. > > It would be the duty of the upper protocol layers using such > a mix-in-entropy functionality in TLS to do it synchronously > at both ends of the secure TLS communication channel. Have you seen ? I agree with your observation, and believe that the problem can be solved by using both these drafts together. The application framework still have to specify the details though. Still, adding more discussions to both of these drafts on the applicability and the intended use cases would be a good idea. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 12:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izy0V-0001kJ-So; Wed, 05 Dec 2007 12:25:59 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1Izy0V-0001jR-1D for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 12:25:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izy0U-0001j6-NO for tls@ietf.org; Wed, 05 Dec 2007 12:25:58 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Izy0T-0007QS-LO for tls@ietf.org; Wed, 05 Dec 2007 12:25:58 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB5HPkuu017287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Dec 2007 18:25:47 +0100 From: Simon Josefsson To: References: <87r6iqgojd.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071205:tls@ietf.org::N/cistYzco7J0rsA:AV+f X-Hashcash: 1:22:071205:pasi.eronen@nokia.com::1jKW7aGC0BUFJNOs:5TTv Date: Wed, 05 Dec 2007 18:25:45 +0100 In-Reply-To: (Pasi Eronen's message of "Mon, 19 Nov 2007 10:33:56 +0200") Message-ID: <87zlwpt5nq.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org Subject: [TLS] Re: Interoperability failure caused by CBC block cipher padding 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 writes: > A while ago, I did some testing on how implementations > handled this, and presented the results in IETF67. See: > > http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld8.htm > http://www3.ietf.org/proceedings/06nov/slides/tls-3/sld9.htm Interesting, thanks for the pointer. Btw, I wasn't aware of the failure in GnuTLS regarding 'Unknown content types', and it seems Nikos has fixed this. > Basically, most implementations seemed to handle this OK. > Perhaps we could add this to the "implementation pitfalls" > section, though. How about adding: - Do you handle arbitrary pad lengths in GenerBlockCipher (see Section 6.2.3.2)? > (i will also try to report this bug to the people responsible > for fixing this.) Thanks, Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 12:38:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyCV-00011T-9I; Wed, 05 Dec 2007 12:38:23 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1IzyCU-00010r-En for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 12:38:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzyCU-00010c-3d for tls@ietf.org; Wed, 05 Dec 2007 12:38:22 -0500 Received: from michael.checkpoint.com ([194.29.32.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzyCT-0004W1-DD for tls@ietf.org; Wed, 05 Dec 2007 12:38:22 -0500 Received: from yaronflap (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id lB5Hc9OY017745; Wed, 5 Dec 2007 19:38:14 +0200 (IST) From: "Yaron Sheffer" To: "'Simon Josefsson'" References: <877ijvpq9y.fsf@mocca.josefsson.org><004401c836b5$2020f370$cd148182@ad.checkpoint.com> <87k5nta40c.fsf@mocca.josefsson.org> Date: Wed, 5 Dec 2007 09:38:03 -0800 Message-ID: <00ca01c83765$9cbfa8d0$89181fac@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acg3IKUxUdyqXVabSOWTwVvpto07eAARBJYg In-Reply-To: <87k5nta40c.fsf@mocca.josefsson.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@ietf.org Subject: [TLS] RE: draft-rescorla-tls-extractor-01: support and comments on IANAsection 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 Hi Simon, All I wanted to do is get rid of the IANA registration requirement, so you don't have to send Emails and wait a week just to implement a private protocol. And the DNS expiry issue can be mitigated thus: Have a special prefix "EXTRACTOR-PRIVATE-yyyymmdd-" where "name" is a DNS name owned by the entity defining the consumer application, and "yyyymmdd" is a fixed date when this application is first created (and when the DNS registration is valid). It is that entity's responsibility to manage their own namespace. Otherwise, if people don't mind the registration requirement, I support your proposal. Thanks, Yaron -----Original Message----- From: Simon Josefsson [mailto:simon@josefsson.org] Sent: Wednesday, December 05, 2007 01:24 To: Yaron Sheffer Cc: ekr@networkresonance.com; tls@ietf.org Subject: Re: draft-rescorla-tls-extractor-01: support and comments on IANAsection "Yaron Sheffer" writes: > 1) I think the IANA section should permit some simple > first-come-first-serve based registration, possibly under a special > label prefix like 'EXTRACTOR-FCFS-'. Sometimes the 'Specification > Required' part is problematic, and I see no harm in permitting a > FCFS-based registration process. > > [YS] This is an unlimited namespace so we can go one better by requiring NO > registration. We can have a special prefix "EXTRACTOR-PRIVATE-" where > "name" is a DNS name owned by the entity defining the consumer application, > and it's that entity's responsibility to manage their own namespace. I like that in principle. However, it would be more complex to specify and there are potential conflicts since DNS names expire. Maybe it is not worth it. This suggest that it may be useful to be able to register a name "family" though. For example, if you register EXTRACTOR-FCFS-FOOBAR you should be able to use everything under that prefix in your own protocol, e.g. EXTRACTOR-FCFS-FOOBAR-FIRST, EXTRACTOR-FCFS-FOOBAR-SECOND etc. Some protocols may need more than one label, and it isn't entirely impossible that some of the labels may even be generated on the fly. /Simon Scanned by Check Point Total Security Gateway. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 05 17:34:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02pC-0007qp-UV; Wed, 05 Dec 2007 17:34:38 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J02pB-0007qC-H4 for tls-confirm+ok@megatron.ietf.org; Wed, 05 Dec 2007 17:34:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J02pB-0007pr-6b for tls@ietf.org; Wed, 05 Dec 2007 17:34:37 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J02pA-00005V-Rn for tls@ietf.org; Wed, 05 Dec 2007 17:34:37 -0500 Received: (qmail 32460 invoked by uid 0); 5 Dec 2007 22:34:28 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (130.129.17.218) by woodstock.binhost.com with SMTP; 5 Dec 2007 22:34:28 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 05 Dec 2007 17:11:55 -0500 To: , From: Russ Housley Subject: Re: [TLS] Keying material extractor as WG item In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Message-Id: Cc: 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 I support the TLS WG adopting this work and publishing it on the standards track. Russ At 10:16 PM 12/4/2007, Pasi.Eronen@nokia.com wrote: >The meeting in Vancouver yesterday supported adopting >draft-rescorla-tls-extractor as a TLS working group document. > >As usual, the WG consensus needs to be confirmed on the mailing >list. Please mail me and Eric (or the whole list) if you object >to using this document as starting point for further WG work. > >(If you have a comment about some technical detail, please >use a separate thread and change the subject line. It is known >that the draft is not finished yet.) > >Best regards, >Pasi > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 06 11:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0JNf-0007Lo-Nq; Thu, 06 Dec 2007 11:15:19 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0JNd-0007Lj-5y for tls-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 11:15:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0JNc-0007Lb-RZ for tls@ietf.org; Thu, 06 Dec 2007 11:15:16 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0JNc-0000FB-Ay for tls@ietf.org; Thu, 06 Dec 2007 11:15:16 -0500 Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id lB6GFFi0012887; Thu, 6 Dec 2007 17:15:15 +0100 (MET) From: Martin Rex Message-Id: <200712061615.lB6GFD4h015066@fs4113.wdf.sap.corp> Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07 To: Pasi.Eronen@nokia.com Date: Thu, 6 Dec 2007 17:15:13 +0100 (MET) In-Reply-To: from "Pasi.Eronen@nokia.com" at Nov 27, 7 02:58:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org (sorry for being late). There is one more thing about Client Certs where I consider the guideline(s) in the existing TLS specs insufficient. What is a TLS server expected to do when it receives, as a reaction to a client certificate request, a client certificate message for which it can not build a chain to one of the known (or permitted) trust anchors? There are implementations that will unconditionally abort the SSL/TLS handshake with a fatal alert. One possibility would be for the TLS specification to say that the server should ignore such a client cert and continue as if the client did not send a certificate. I think a clearly defined (server) behaviour is important for the new option that allows the server to send a CertificateRequest with an __empty__ list of trusted CAs. When I saw the following message: = From: pgut001@cs.auckland.ac.nz (Peter Gutmann) = Subject: Re: [TLS] CertificateRequest = Date: Thu, 22 Nov 2007 22:08:38 +1300 = = [...] = = I've found that simply ignoring the contents of the cert request seems = to work pretty well. Since there are servers sending out nonsensical = requests, the safest thing to do is just record that a request for = a cert exists. If you have a cert, send it and let the server sort it out. IMHO, blindly sending a client cert is only a safe bet if the spec says that the server should (silently) ignore client certs which it does not trust. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 06 11:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0K30-0004FF-5a; Thu, 06 Dec 2007 11:58:02 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0K2y-0004ER-S2 for tls-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 11:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0K2y-0004E7-AN for tls@ietf.org; Thu, 06 Dec 2007 11:58:00 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0K2w-00062V-L8 for tls@ietf.org; Thu, 06 Dec 2007 11:58:00 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lB6Gvhli025518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Dec 2007 17:57:47 +0100 From: Simon Josefsson To: martin.rex@sap.com References: <200712061615.lB6GFD4h015066@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071206:martin.rex@sap.com::uXFOCPr6G6r+x8PP:3Wo1 X-Hashcash: 1:22:071206:tls@ietf.org::FgyNHEt7nmj76O7J:ZCOw X-Hashcash: 1:22:071206:pasi.eronen@nokia.com::4J8xjMCSAhP/U+kP:RzAw Date: Thu, 06 Dec 2007 17:57:43 +0100 In-Reply-To: <200712061615.lB6GFD4h015066@fs4113.wdf.sap.corp> (Martin Rex's message of "Thu, 6 Dec 2007 17:15:13 +0100 (MET)") Message-ID: <87prxju5fc.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org Subject: [TLS] Re: WGLC for draft-ietf-tls-rfc4346-bis-07 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 Martin Rex writes: > What is a TLS server expected to do when it receives, as a reaction > to a client certificate request, a client certificate message for > which it can not build a chain to one of the known (or permitted) > trust anchors? > > There are implementations that will unconditionally abort the > SSL/TLS handshake with a fatal alert. > > One possibility would be for the TLS specification to say that > the server should ignore such a client cert and continue as if > the client did not send a certificate. > > I think a clearly defined (server) behaviour is important for the new option > that allows the server to send a CertificateRequest with an > __empty__ list of trusted CAs. Is there any reason why this cannot be up to server policy? I think that some sites (e.g., bank that uses client certificates) would want to abort the handshake. Some other sites (e.g., webmail) would want to continue as if the client did not send a certificate. I would agree that a client may want to be able to find out whether the server was able to successfully verify the client certificate or not, though. I don't recall if this is possible today, but I think not. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 06 12:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KVM-000197-Ic; Thu, 06 Dec 2007 12:27:20 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0KVL-00018a-Dr for tls-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 12:27:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0KVJ-000181-KT for tls@ietf.org; Thu, 06 Dec 2007 12:27:19 -0500 Received: from mail.gi-de.com ([193.108.184.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0KVJ-0006Y5-4B for tls@ietf.org; Thu, 06 Dec 2007 12:27:17 -0500 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id SUAQ2HSZ outgoing id SUAQ2HSZ; 06 Dec 2007 18:27:15 +0100 In-Reply-To: <87prxju5fc.fsf@mocca.josefsson.org> To: tls@ietf.org Subject: Antwort: [TLS] Re: WGLC for draft-ietf-tls-rfc4346-bis-07 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Thu, 6 Dec 2007 18:30:03 +0100 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 06.12.2007 18:27:14, Serialize complete at 06.12.2007 18:27:14 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: 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 Hi, > I would agree that a client may want to be able to find out whether the > server was able to successfully verify the client certificate or not, > though. I don't recall if this is possible today, but I think not. Is this really necessary? To me, this appears as something that is beyond the scope of TLS and better handled on higher layers. What is the actual use case here? The client can verify the server's identity and thus it knows, which certificate(s) the server expects, if it requests one. But it is up to the layer above TLS to choose the right certificate and give it to the TLS handshake engine. Same for actually verifying the certificate(s). After verifying the server certificate, the client trusts the server to be authentic. If the server then decides that it accepts a client certificate that cannot be verified, the server may have its resons for this - otherwise if could simply abort the handshake If the client is interested in further details why the server accepted the connection with a certificate that it could not verify, dicussing further details should happen on the next higher layer without TLS beeing involved here except for data transport. regards, Axel _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 06 12:59:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L0V-0000zG-Ai; Thu, 06 Dec 2007 12:59:31 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0L0T-0000v9-Qe for tls-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 12:59:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L0T-0000tj-G9 for tls@ietf.org; Thu, 06 Dec 2007 12:59:29 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0L0S-00032m-UN for tls@ietf.org; Thu, 06 Dec 2007 12:59:29 -0500 Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id lB6HxTO0023021; Thu, 6 Dec 2007 18:59:29 +0100 (MET) From: Martin Rex Message-Id: <200712061759.lB6HxRF1021193@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Thu, 6 Dec 2007 18:59:27 +0100 (MET) In-Reply-To: <87prxju5fc.fsf@mocca.josefsson.org> from "Simon Josefsson" at Dec 6, 7 05:57:43 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@ietf.org Subject: [TLS] Re: WGLC for draft-ietf-tls-rfc4346-bis-07 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > > Martin Rex writes: > > > What is a TLS server expected to do when it receives, as a reaction > > to a client certificate request, a client certificate message for > > which it can not build a chain to one of the known (or permitted) > > trust anchors? > > > > There are implementations that will unconditionally abort the > > SSL/TLS handshake with a fatal alert. > > > > One possibility would be for the TLS specification to say that > > the server should ignore such a client cert and continue as if > > the client did not send a certificate. > > > > I think a clearly defined (server) behaviour is important for the new option > > that allows the server to send a CertificateRequest with an > > __empty__ list of trusted CAs. > > Is there any reason why this cannot be up to server policy? No. But currently it is implementation defined and the server administrator may not have the option to configure his preferred behaviour. Specifying it should be up to server policy would require implementations to implement configurable behaviour. > > I think that some sites (e.g., bank that uses client certificates) would > want to abort the handshake. Some other sites (e.g., webmail) would > want to continue as if the client did not send a certificate. The serious drawback of aborting the handshake is that it will be impossible to present a meaningful error message to the client/user. There is an awfully large installed base of Web Browsers that behaves extremely braindead when it comes to (fatal) SSL alerts, presenting the end user extremely useless and misleading error messages. If the TLS stack continues the handshake and the decision to reject the request at the application layer, then there is an established communication channel through which a beautiful, application-specific error message can be sent to the client (e.g. some HTML error page in case of a Web-Browser client). > > I would agree that a client may want to be able to find out whether the > server was able to successfully verify the client certificate or not, > though. I don't recall if this is possible today, but I think not. As I mentioned, for some (server) implementations, this is currently implicit from the servers reaction to the ClientCertificate message. With a single client cert in the browser and "select automatically" configured, it might also be very non-obvious whether a client certificate request was received and a client certificate was sent. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 06 13:00:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L1P-0001lb-IO; Thu, 06 Dec 2007 13:00:27 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0L1O-0001kB-Gd for tls-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 13:00:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0L1O-0001jt-5x for tls@ietf.org; Thu, 06 Dec 2007 13:00:26 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0L1N-0001Jr-LF for tls@ietf.org; Thu, 06 Dec 2007 13:00:26 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lB6I06K3019373; Thu, 6 Dec 2007 20:00:23 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 20:00:13 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Dec 2007 20:00:13 +0200 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: Thu, 6 Dec 2007 20:00:12 +0200 Message-ID: In-Reply-To: <87zlwpt5nq.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interoperability failure caused by CBC block cipher padding Thread-Index: Acg3Y+uHP/ejZCyFRfWGkCSt/pg1DQAzVXWQ References: <87r6iqgojd.fsf@mocca.josefsson.org> <87zlwpt5nq.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 06 Dec 2007 18:00:13.0011 (UTC) FILETIME=[D949E230:01C83831] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org Subject: [TLS] RE: Interoperability failure caused by CBC block cipher padding 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 Simon Josefsson wrote: > Btw, I wasn't aware of the failure in GnuTLS regarding=20 > 'Unknown content types', and it seems Nikos has fixed this. After the discussion in IETF 67, I wouldn't really call it a failure. Most people seemed to think that the text "SHOULD just ignore it" text in TLS 1.0/1.1 was wrong (and GnuTLS was doing the right thing). In rfc4346-bis-07 this text is changed to: Implementations MUST NOT send record types not defined in=20 this document unless negotiated by some extension. If a=20 TLS implementation receives an unexpected record type, it=20 MUST send an unexpected_message alert. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 06 13:41:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LfG-0006CQ-91; Thu, 06 Dec 2007 13:41:38 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0LfE-0005xW-QK for tls-confirm+ok@megatron.ietf.org; Thu, 06 Dec 2007 13:41:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0LfE-0005oF-4e for tls@ietf.org; Thu, 06 Dec 2007 13:41:36 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J0LfD-00059z-JW for tls@ietf.org; Thu, 06 Dec 2007 13:41:36 -0500 Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id lB6IfYd3023297; Thu, 6 Dec 2007 19:41:34 +0100 (MET) From: Martin Rex Message-Id: <200712061841.lB6IfXLI024420@fs4113.wdf.sap.corp> To: simon@josefsson.org (Simon Josefsson) Date: Thu, 6 Dec 2007 19:41:33 +0100 (MET) In-Reply-To: <874pexukhw.fsf@mocca.josefsson.org> from "Simon Josefsson" at Dec 5, 7 06:19:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal06 X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org Subject: [TLS] Re: Scope of draft-rescorla-tls-extractor X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > > Martin Rex writes: > > > The currently proposed scope of draft-rescorla-tls-extractor seems to > > be similar to the gss_prf approach in GSS-API. > > > > I believe, however, that a wider scope would be better. > > When combining TLS channel protection with other authentication > > technologies (like GSS-API authentication), one should have > > a means to "mix" entropy from one (cryptographic) protocol > > exchange into the session key of the other that is used > > for protection of the communication in order to provide > > a cryptographically secure channel binding. > > > > It would be the duty of the upper protocol layers using such > > a mix-in-entropy functionality in TLS to do it synchronously > > at both ends of the secure TLS communication channel. > > Have you seen > ? No, I haven't. Thanks for the pointer (the document expired on june 16,2007, but my local I-D mirror still has it). It's not quite what I was looking for. As far as I understand that proposal, it's a Hello extension and all application supplied data travels in the first handshake roundtrip and in cleartext. I was looking for a means to synchronously modify the keying material (Master Secret) at a time when the communication channel is already encrypted. This is can not be done through a simple hello extension and will require, admittedly, a change of the TLS handshake and state engine by itself. Moving it behind the TLS hanshake (after the finished messages) should be possible, but then require some thought because of the impact on session cache management. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 07 08:55:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dfd-000192-NK; Fri, 07 Dec 2007 08:55:13 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0dfc-00018u-72 for tls-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 08:55:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0dfb-00018m-TX for tls@ietf.org; Fri, 07 Dec 2007 08:55:11 -0500 Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0dfa-00055o-9E for tls@ietf.org; Fri, 07 Dec 2007 08:55:11 -0500 Received: from pc6 (1Cust163.tnt14.lnd4.gbr.da.uu.net [62.188.143.163]) by astro.systems.pipex.net (Postfix) with SMTP id 32160E0004E0; Fri, 7 Dec 2007 13:55:06 +0000 (GMT) Message-ID: <045f01c838d0$4da3e9c0$0601a8c0@pc6> From: "tom.petch" To: , References: <200712061615.lB6GFD4h015066@fs4113.wdf.sap.corp> Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07 Date: Fri, 7 Dec 2007 12:28:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: -101.0 (---------------------------------------------------) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: "This 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 ----- Original Message ----- From: "Martin Rex" To: Cc: Sent: Thursday, December 06, 2007 5:15 PM Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07 > (sorry for being late). > > There is one more thing about Client Certs where I consider the > guideline(s) in the existing TLS specs insufficient. > > What is a TLS server expected to do when it receives, as a reaction > to a client certificate request, a client certificate message for > which it can not build a chain to one of the known (or permitted) > trust anchors? > I think that this needs clarfying but that this I-D is not the place to do it. I notice another post made reference to an HTTP server as if that were the only use of TLS; well, no, as you know:-) My interest is in the use of TLS in device management - syslog, Netconf, ... - where client authentication is what really matters. The server might be the remote, small, underpowered device with little access to infrastructure - think hub, bridge, router, gateway - which needs to know that this client - big, fat, central, over-endowed workstation - which is telling it to reboot really is the one with authority to do so. So I am thinking that rather than each WG try to come up with its own idea of applicability - eg draft-ietf-syslog-transport-tls-11.txt, draft-badra-tls-netconf-02.txt - more guidance on applicability and usage from this WG would serve the IETF better. Tom Petch > There are implementations that will unconditionally abort the > SSL/TLS handshake with a fatal alert. > > One possibility would be for the TLS specification to say that > the server should ignore such a client cert and continue as if > the client did not send a certificate. > > I think a clearly defined (server) behaviour is important for the new option > that allows the server to send a CertificateRequest with an > __empty__ list of trusted CAs. > > When I saw the following message: > = From: pgut001@cs.auckland.ac.nz (Peter Gutmann) > = Subject: Re: [TLS] CertificateRequest > = Date: Thu, 22 Nov 2007 22:08:38 +1300 > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 07 13:35:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0i2Z-0000cb-AR; Fri, 07 Dec 2007 13:35:11 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0i2X-0000a1-Hl for tls-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 13:35:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0i2X-0000Zs-7s for tls@ietf.org; Fri, 07 Dec 2007 13:35:09 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0i2U-0000mP-QL for tls@ietf.org; Fri, 07 Dec 2007 13:35:09 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lB7IYmvX020293 for ; Fri, 7 Dec 2007 20:35:04 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 20:34:51 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Dec 2007 20:34:51 +0200 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: Fri, 7 Dec 2007 20:34:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS WG Report Thread-Index: Acg3l8gegi43lzq/SrqYBc4bsk7ahwBZ6oJA From: To: X-OriginalArrivalTime: 07 Dec 2007 18:34:51.0351 (UTC) FILETIME=[DA7D2670:01C838FF] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Subject: [TLS] FW: TLS WG Report 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 This should have been Cc'd to TLS list as well. We hope to have minutes posted early next week; presentation slides are available here: https://datatracker.ietf.org/meeting/70/materials.html#wg-tls and audio recording should be here (haven't check this yet, though): http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf70/ietf70-ch7-mo n-am-tls.mp3 Best regards, Pasi=20 > -----Original Message----- > From: Eric Rescorla > Sent: 06 December, 2007 01:25 > To: saag@mit.edu > Subject: [saag] TLS WG Report >=20 > TLS WG Report > $Id: tls-saag.txt,v 1.1 2007/12/05 23:22:34 ekr Exp $ >=20 > TLS WG met 9 AM Monday Dec 3.=20 >=20 > - TLS 1.2 >=20 > TLS 1.2 is currently in WGLC. We went over the current LC comments, > most of which were editorial. One issue was semi-contentious: > what to do with IDEA, should it be SHOULD NOT or MUST NOT. This > will go to the list. >=20 >=20 > - Extension definitions >=20 > This document hasn't seen any significant changes. It turns out > there are significant IDN issues. Paul Hoffman agreed to take a > look. We discussed hash agility for the SHA-1 in the certificate > URL extension but didn't close on it. >=20 >=20 > - RSA-AES-SIV >=20 > Dan Harkins presented SIV, another AEAD algorithm that is slower > than, but more resilient to misuse, than GCM. There was no consenus > about whether to adopt this, so it was taken to the list. >=20 >=20 > - ECDHE_PSK Ciphersuites >=20 > Mohama d Badra presented this. We'll take it to the list. >=20 >=20 > - TLS using EAP Auth >=20 > Yaron Sheffer presented this. There was a fair amount of discussion, > some pro, some con. No progress can be made here until the issue of > the EAP applicability statement can be resolved, which is an AD issue. >=20 >=20 > - TLS Extractors >=20 > There was general enthusiasm for this. Some discussion of extractor > label registration policies. Consensus to take this as a WG item. > To confirm on the mailing list. >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 07 14:12:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ick-0004b5-6u; Fri, 07 Dec 2007 14:12:34 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J0ici-0004aq-NW for tls-confirm+ok@megatron.ietf.org; Fri, 07 Dec 2007 14:12:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J0ici-0004ai-E0 for tls@lists.ietf.org; Fri, 07 Dec 2007 14:12:32 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J0ich-0003Rv-0x for tls@lists.ietf.org; Fri, 07 Dec 2007 14:12:32 -0500 Received: by nf-out-0910.google.com with SMTP id 4so401643nfv for ; Fri, 07 Dec 2007 11:12:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; bh=PHukzRKqwh8PMk8jDy1oL43wfIVKwk6Sxqk+rut8OXM=; b=scVE44kPijr54GhW9frKIh65xshvVgzMkBztT6oK2THLfddZqeS1PQ0f9ktK0UhpO3O9U9QyYwMc5EMxqVV55FDlpcCl7iMRoycpXUAqncdk3NLJNsBO2Y1MuYsAThr/9qADzTiOU0IKFr3SLkCVthY8vblHuYGgmKkUMBVC6X8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=kBEf7JiAKKbedb9nCbGraAtU9Tv6H6yAJ9Dlyhj9faMaib2i1PPB3uzcEgVZraOfwsK4Te7Tm3t4769IEBPCcxlbKids3bOncCwvyUnI472rvufgKS5MH+5FTuli3SvblITuLjW3jodPK/OCGenfNDhZAoHuEoJ6ThchRAqxTYA= Received: by 10.86.26.11 with SMTP id 11mr2483224fgz.1197054749968; Fri, 07 Dec 2007 11:12:29 -0800 (PST) Received: from crystal ( [77.49.85.93]) by mx.google.com with ESMTPS id d13sm31205fka.2007.12.07.11.12.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 07 Dec 2007 11:12:28 -0800 (PST) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] Keying material extractor as WG item Date: Fri, 7 Dec 2007 21:12:25 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712072112.26086.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 On Wednesday 05 December 2007, Pasi.Eronen@nokia.com wrote: > The meeting in Vancouver yesterday supported adopting > draft-rescorla-tls-extractor as a TLS working group document. I also support this being a WG document. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 10 10:04:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kBX-0000Lm-4M; Mon, 10 Dec 2007 10:04:43 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J1kBW-0000Lh-2H for tls-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 10:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1kBV-0000LZ-Or for tls@ietf.org; Mon, 10 Dec 2007 10:04:41 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1kBT-0002oW-TW for tls@ietf.org; Mon, 10 Dec 2007 10:04:41 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBAF4GcA013253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Dec 2007 16:04:17 +0100 From: Simon Josefsson To: References: <87r6iqgojd.fsf@mocca.josefsson.org> <87zlwpt5nq.fsf@mocca.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071210:pasi.eronen@nokia.com::JUX45tnymyxnemoj:0tEJ X-Hashcash: 1:22:071210:tls@ietf.org::0sLQMoh8fXjFSKvf:DNxi Date: Mon, 10 Dec 2007 16:04:16 +0100 In-Reply-To: (Pasi Eronen's message of "Thu, 6 Dec 2007 20:00:12 +0200") Message-ID: <87d4te8ubz.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org Subject: [TLS] Re: Interoperability failure caused by CBC block cipher padding 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 writes: > Simon Josefsson wrote: >> Btw, I wasn't aware of the failure in GnuTLS regarding >> 'Unknown content types', and it seems Nikos has fixed this. > > After the discussion in IETF 67, I wouldn't really call > it a failure. Ah. The "fail" sent a slightly different message. ;) > Most people seemed to think that the text "SHOULD just ignore it" text > in TLS 1.0/1.1 was wrong (and GnuTLS was doing the right thing). > > In rfc4346-bis-07 this text is changed to: > > Implementations MUST NOT send record types not defined in > this document unless negotiated by some extension. If a > TLS implementation receives an unexpected record type, it > MUST send an unexpected_message alert. Interesting, so we have reverted our change. However, this brings up the questions whether such text is intended to only describe what a conforming TLS 1.2 implementation should do, or whether it is also intended to update what a TLS 1.0/1.1 implementation should do? Right now GnuTLS will refuse unexpected record types regardless of the negotiated version. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 11 12:01:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J28Tu-0002q2-LO; Tue, 11 Dec 2007 12:01:18 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J28Tt-0002nf-5L for tls-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 12:01:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J28Ts-0002n3-PN for tls@ietf.org; Tue, 11 Dec 2007 12:01:16 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J28Tr-0004ab-5V for tls@ietf.org; Tue, 11 Dec 2007 12:01:16 -0500 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id lBBHwR7Z847876 for ; Tue, 11 Dec 2007 17:58:27 GMT Message-ID: <475EC23D.3050804@isima.fr> Date: Tue, 11 Dec 2007 18:00:45 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.13 (Windows/20070809) MIME-Version: 1.0 To: tls mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Tue, 11 Dec 2007 17:58:27 +0000 (WET) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] ECDHE_PSK Ciphersuites for TLS 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 Dear all, I presented the document "ECDHE_PSK Ciphersuites for TLS" [1] during last meeting and would like to take it to this list for more reviews and comments. Thank you in advance for your time and and review. Best regards, [1] http://www.ietf.org/internet-drafts/draft-badra-ecdhe-tls-psk-01.txt -- Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 11 18:28:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2EWH-0001Fw-Ke; Tue, 11 Dec 2007 18:28:09 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2EWG-0001Fr-2p for tls-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 18:28:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2EWF-0001Fj-My for tls@ietf.org; Tue, 11 Dec 2007 18:28:07 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2EWE-0004Kz-Te for tls@ietf.org; Tue, 11 Dec 2007 18:28:07 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 11 Dec 2007 23:28:05 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.88]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([2002:4135:d55c::4135:d55c]) with mapi; Tue, 11 Dec 2007 23:28:05 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" , "tls@ietf.org" Date: Tue, 11 Dec 2007 23:28:01 +0000 Thread-Topic: WGLC for draft-ietf-tls-rfc4346-bis-07 Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIgDnBkoQAe7QsfA= Message-ID: <9F11911AED01D24BAA1C2355723C3D320A10E835BA@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: Subject: [TLS] RE: WGLC for draft-ietf-tls-rfc4346-bis-07 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 As most of the feedback to these comments were made during the IETF meeting= , I summarize them here. Issue 1) Accepted. Terminology will be harmonized. Issue 2) Accepted. Experimental ranges will be added to hash and Signature = algorithm IANA assignments. Issue 3) Accepted as update to Security Considerations Issue 4) Not accepted. I will follow up on this in separate mail. Issue 5) Accepted. Error will be corrected. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Stefan Santesson [mailto:stefans@microsoft.com] > Sent: den 1 december 2007 19:21 > To: Pasi.Eronen@nokia.com; tls@ietf.org > Subject: [TLS] RE: WGLC for draft-ietf-tls-rfc4346-bis-07 > > I would like to submit the following Last Call comments on TLS 1.2 > > 1) Terminology: CipherSuite, ciphersuite or cipher suite. And > CipherSuites or cipher suites > The document currently includes all flavors of the above term. It would > be better to select one form and stick to it. > > 2) Custom signature/digest algorithms for local use or test purposes. > TLS allows definition of cipher suites for private use (0xFF,0x00-FF). > It would be reasonable to also allocate a name space for private use > also for hash algorithms and signature algorithms. If not, the private > cipher suites can't be used. > > 3) Multiple hash alternatives. > In order to verify the CertificateVerify message the server must hash > previous messages from the client. This can be problematic if the > client is still allowed to choose more than one hash algorithm. In this > case the server must store all previous messages and hash them after > receiving CertificateVerify or hash them with all possible hash > algorithms when received. This could open for DoS and flooding attacks, > dependent on the server design, if attack messages are constructed to > be as long as legally possible. The comment is only to highlight the > issue rather than suggesting any changes. The server can mitigate this > by always limiting the hash choices to only one hash algorithm in the > Certificate Request message. Perhaps this should be mentioned in the > security considerations section. > > 4) Stepping up the choice of hash? > If the client doesn't specify any hash algorithm, the server MUST use > SHA-1 in the server key exchange message. (7.4.3) "If no > "signature_algorithms" extension is present , the server MUST use SHA-1 > as the hash algorithm." The client is however not obligated to declare > any signature_algorithms (7.4.1.4.1) "Clients SHOULD send this > extension if they support any hash algorithm other than SHA-1." > But what if the server has knowledge that the client does support a > better hash? For example, the selected key exchange algorithm is > derived from a cipher suite defining a PRF based on a better hash. > Would it be reasonable to allow the Server to make use of the better > hash algorithm? > > 5) Error: supported_signature_types -> Supported_signature_algorithms > The following paragraphs in 7.4.4 contains 2 instances of > supported_signature_types with is not defined in this spec. Should be > "supported_signature_algorithms". > > - Any certificates provided by the client MUST be signed using a > hash/signature algorithm pair found in supported_signature_types. > > - The end-entity certificate provided by the client MUST contain a > key which is compatible with certificate_types. If the key is a > signature key, it MUST be usable with some hash/signature > algorithm pair in supported_signature_types. > > > > Stefan Santesson > Senior Program Manager > Windows Security, Standards > > > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: den 27 november 2007 13:58 > > To: tls@ietf.org > > Subject: [TLS] WGLC for draft-ietf-tls-rfc4346-bis-07 > > > > > > This message starts a WG last call on draft-ietf-tls-rfc4346-bis-07, > > prior to sending it to the IESG for publication as Proposed Standard. > > > > Please send your comments to the WG mailing list by Wednesday > > December 19th. Comments along the lines "I've read it and it looks > > OK" are helpful and encouraged. > > > > The last call period is longer than usual to accommodate for > > the IETF meeting, but if you manage to do some reading on your > > flight to Vancouver, your comments can be discussed face-to-face > > there. > > > > Best regards, > > Pasi > > > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Dec 11 18:40:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ei1-0002Jj-F2; Tue, 11 Dec 2007 18:40:17 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2Ei1-0002Ic-0Q for tls-confirm+ok@megatron.ietf.org; Tue, 11 Dec 2007 18:40:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ei0-0002G3-K7 for tls@ietf.org; Tue, 11 Dec 2007 18:40:16 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Ei0-0004bB-5n for tls@ietf.org; Tue, 11 Dec 2007 18:40:16 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Tue, 11 Dec 2007 23:40:15 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.88]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Tue, 11 Dec 2007 23:40:15 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" , "tls@ietf.org" Date: Tue, 11 Dec 2007 23:40:13 +0000 Thread-Topic: WGLC - Stepping up Hash Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIgDnBkoQAe8NP+A= Message-ID: <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [TLS] WGLC - Stepping up Hash 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 original LC comment was: > 4) Stepping up the choice of hash? > If the client doesn't specify any hash algorithm, the server MUST use > SHA-1 in the server key exchange message. (7.4.3) "If no > "signature_algorithms" extension is present , the server MUST use SHA-1 > as the hash algorithm." The client is however not obligated to declare > any signature_algorithms (7.4.1.4.1) "Clients SHOULD send this > extension if they support any hash algorithm other than SHA-1." > But what if the server has knowledge that the client does support a > better hash? For example, the selected key exchange algorithm is > derived from a cipher suite defining a PRF based on a better hash. > Would it be reasonable to allow the Server to make use of the better > hash algorithm? This was discussed at the TLS meeting and not accepted mainly for the follo= wing reasons: 1) It would be very hard to specify the specific conditions for when a serv= er can or cannot step up the used hash algorithm. 2) We need servers to behave uniformly on this issue. I would however challenge condition 2) and if condition 2) is not necessary= , then condition 1) falls as well. Why is it important that all servers are designed to handle this situation = uniformly? I fail to see the harm if some servers successfully deploys bett= er security while other servers in the same situation would choose to stick= to the default security level. As long as the server can determine successfully the capacity of the client= and successfully communicate the choice of algorithms, then the only thing= that can happen is that we would simply allow the server to choose better = security. If there is no need for all servers to provide a uniform behavior then we d= on't need to specify the exact conditions under which the server can gain k= nowledge of the client's capacity. This can range from local configuration = and local policy to a local convention based on the ciphersuites supported = by the client. Stefan Santesson Senior Program Manager Windows Security, Standards _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 12 02:22: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 1J2Lv4-000195-K0; Wed, 12 Dec 2007 02:22:14 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2Lv3-00018z-KE for tls-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 02:22:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Lv2-00018r-UU for tls@ietf.org; Wed, 12 Dec 2007 02:22:12 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Lv2-0007Qr-E0 for tls@ietf.org; Wed, 12 Dec 2007 02:22:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBC7Lh5r007690; Wed, 12 Dec 2007 09:22:08 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 09:21:53 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 09:21:53 +0200 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: Wed, 12 Dec 2007 09:21:55 +0200 Message-ID: In-Reply-To: <87d4te8ubz.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Interoperability failure caused by CBC block cipher padding Thread-Index: Acg7PgDS3dCUaZ4SQVO7/e2TWJEL+ABT84vg References: <87r6iqgojd.fsf@mocca.josefsson.org><87zlwpt5nq.fsf@mocca.josefsson.org> <87d4te8ubz.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 12 Dec 2007 07:21:53.0301 (UTC) FILETIME=[AB5C6C50:01C83C8F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@ietf.org Subject: [TLS] RE: Interoperability failure caused by CBC block cipher padding 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 Simon Josefsson wrote: > However, this brings up the questions whether such text is intended > to only describe what a conforming TLS 1.2 implementation should do, > or whether it is also intended to update what a TLS 1.0/1.1 > implementation should do? Right now GnuTLS will refuse unexpected > record types regardless of the negotiated version. Except when explicitly noted so, nothing in the TLS 1.2 spec is intended to change what implementations do when TLS 1.0/1.1 is negotiated. (The possible exceptions are Appendix E and Section 7.4.7.1, which apply to implementations that do both TLS 1.2 and earlier versions.) However, for this particular issue (unexpected record types), it should be noted that someone implementing RFC 2246/4346 will never send unexpected record types -- and there are no specs that expect them to be ignored -- so if you receive them, something is clearly wrong, and refusing them seems right to me. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 12 06:29:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Ple-00012c-3C; Wed, 12 Dec 2007 06:28:46 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2Plc-00012J-8d for tls-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 06:28:44 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2Plb-00012B-RC for tls@ietf.org; Wed, 12 Dec 2007 06:28:43 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2Plb-0006CV-D9 for tls@ietf.org; Wed, 12 Dec 2007 06:28:43 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBCBS1sA029040; Wed, 12 Dec 2007 05:29:03 -0600 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 13:28:17 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Dec 2007 13:28:17 +0200 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: Wed, 12 Dec 2007 13:27:54 +0200 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC - Stepping up Hash Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIgDnBkoQAe8NP+AAGNcUMA== References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> From: To: , X-OriginalArrivalTime: 12 Dec 2007 11:28:17.0520 (UTC) FILETIME=[17713700:01C83CB2] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Subject: [TLS] RE: WGLC - Stepping up Hash 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 Stefan Santesson wrote: > This was discussed at the TLS meeting and not accepted mainly=20 > for the following reasons: >=20 > 1) It would be very hard to specify the specific conditions=20 > for when a server can or cannot step up the used hash algorithm. > 2) We need servers to behave uniformly on this issue. >=20 > I would however challenge condition 2) and if condition 2) is=20 > not necessary, then condition 1) falls as well. > Why is it important that all servers are designed to handle=20 > this situation uniformly?=20 Completely uniform server behavior is perhaps not needed,=20 but interoperability is. > I fail to see the harm if some servers successfully deploys > better security while other servers in the same situation would > choose to stick to the default security level. > > As long as the server can determine successfully the capacity=20 > of the client and successfully communicate the choice of=20 > algorithms, then the only thing that can happen is that we=20 > would simply allow the server to choose better security. >=20 > If there is no need for all servers to provide a uniform=20 > behavior then we don't need to specify the exact conditions=20 > under which the server can gain knowledge of the client's=20 > capacity. This can range from local configuration and local=20 > policy to a local convention based on the ciphersuites=20 > supported by the client. Do you mean something along the lines "if the client proposes ciphersuite TLS_X_WITH_Y, then the server assumes that the client will also support hash Z, even though the client didn't include Z in signature_algorithms extension"? This sounds like a recipe for horrible interop problems unless the specification actually says that "all implementations which support TLS_X_WITH_Y must also support hash Z". While this could perhaps be done, I don't quite understand why it would be useful: if the client does indeed support Z, it=20 will include it in the signature_algorithms list. If it doesn't include it, it either doesn't support it, or does not want to use it (in this context). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 12 17:31:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2a6L-0005Li-KA; Wed, 12 Dec 2007 17:30:49 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2a6L-0005Ld-6Z for tls-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 17:30:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2a6K-0005LV-Rf for tls@ietf.org; Wed, 12 Dec 2007 17:30:48 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2a6K-0006ym-9X for tls@ietf.org; Wed, 12 Dec 2007 17:30:48 -0500 Received: from dub-exhub-c302.europe.corp.microsoft.com (65.53.213.92) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Wed, 12 Dec 2007 22:30:47 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.88]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([::1]) with mapi; Wed, 12 Dec 2007 22:30:47 +0000 From: Stefan Santesson To: "Pasi.Eronen@nokia.com" , "tls@ietf.org" Date: Wed, 12 Dec 2007 22:30:44 +0000 Thread-Topic: WGLC - Stepping up Hash Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIgDnBkoQAe8NP+AAGNcUMAAXCuDQ Message-ID: <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: Subject: [TLS] RE: WGLC - Stepping up Hash 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 In line; Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: den 12 december 2007 03:28 > To: Stefan Santesson; tls@ietf.org > Subject: RE: WGLC - Stepping up Hash > > Stefan Santesson wrote: > > > This was discussed at the TLS meeting and not accepted mainly > > for the following reasons: > > > > 1) It would be very hard to specify the specific conditions > > for when a server can or cannot step up the used hash algorithm. > > 2) We need servers to behave uniformly on this issue. > > > > I would however challenge condition 2) and if condition 2) is > > not necessary, then condition 1) falls as well. > > Why is it important that all servers are designed to handle > > this situation uniformly? > > Completely uniform server behavior is perhaps not needed, > but interoperability is. > Great. A interoperability problem that would not be acceptable is if a Serv= er based on how TLS 1.2 is defined, falsely assumes that a client can do ha= sh Z. > > I fail to see the harm if some servers successfully deploys > > better security while other servers in the same situation would > > choose to stick to the default security level. > > > > As long as the server can determine successfully the capacity > > of the client and successfully communicate the choice of > > algorithms, then the only thing that can happen is that we > > would simply allow the server to choose better security. > > > > If there is no need for all servers to provide a uniform > > behavior then we don't need to specify the exact conditions > > under which the server can gain knowledge of the client's > > capacity. This can range from local configuration and local > > policy to a local convention based on the ciphersuites > > supported by the client. > > Do you mean something along the lines "if the client > proposes ciphersuite TLS_X_WITH_Y, then the server assumes > that the client will also support hash Z, even though > the client didn't include Z in signature_algorithms > extension"? > Yes and No. No I don't want this assumption to be defined in the protocol. = That would be pretty ugly and would have to be defined per cipher suite. But Yes, the server may have deterministic knowledge that in the pool of cl= ients it serves (or for the particular service it provides) either all clie= nts, or a subgroup of the clients that uses a particular cipher suite, in f= act can handle Hash Z. > This sounds like a recipe for horrible interop problems > unless the specification actually says that "all implementations > which support TLS_X_WITH_Y must also support hash Z". While > this could perhaps be done, I don't quite understand why > it would be useful: if the client does indeed support Z, it > will include it in the signature_algorithms list. If it > doesn't include it, it either doesn't support it, or does > not want to use it (in this context). > This is not a matter of when a Server should select hash Z. This is a matte= r of allowing the server to select hash Z when the server knows that the cl= ient can, or must be able to, use hash Z. In this case there can't be any i= nterop issues by definition. As TLS 1.2 currently is written, the Server is= prohibited from stepping up the security even if it knows that it would no= t cause any problems. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 12 18:11:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ak2-0003re-Lk; Wed, 12 Dec 2007 18:11:50 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2ajz-0003rY-SL for tls-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 18:11:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ajz-0003rL-Fz for tls@ietf.org; Wed, 12 Dec 2007 18:11:47 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2ajy-00005H-Qt for tls@ietf.org; Wed, 12 Dec 2007 18:11:47 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 870E733C6D; Wed, 12 Dec 2007 15:06:17 -0800 (PST) Date: Wed, 12 Dec 2007 15:06:16 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] RE: WGLC - Stepping up Hash In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071212230617.870E733C6D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: "tls@ietf.org" 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 At Wed, 12 Dec 2007 22:30:44 +0000, > > > I fail to see the harm if some servers successfully deploys > > > better security while other servers in the same situation would > > > choose to stick to the default security level. > > > > > > As long as the server can determine successfully the capacity > > > of the client and successfully communicate the choice of > > > algorithms, then the only thing that can happen is that we > > > would simply allow the server to choose better security. > > > > > > If there is no need for all servers to provide a uniform > > > behavior then we don't need to specify the exact conditions > > > under which the server can gain knowledge of the client's > > > capacity. This can range from local configuration and local > > > policy to a local convention based on the ciphersuites > > > supported by the client. > > > > Do you mean something along the lines "if the client > > proposes ciphersuite TLS_X_WITH_Y, then the server assumes > > that the client will also support hash Z, even though > > the client didn't include Z in signature_algorithms > > extension"? > > > > Yes and No. No I don't want this assumption to be defined in the > protocol. That would be pretty ugly and would have to be defined per > cipher suite. But Yes, the server may have deterministic knowledge > that in the pool of clients it serves (or for the particular service > it provides) either all clients, or a subgroup of the clients that > uses a particular cipher suite, in fact can handle Hash Z. Yes, it might. But that's contrary to the general goal of explicit signalling. > > This sounds like a recipe for horrible interop problems > > unless the specification actually says that "all implementations > > which support TLS_X_WITH_Y must also support hash Z". While > > this could perhaps be done, I don't quite understand why > > it would be useful: if the client does indeed support Z, it > > will include it in the signature_algorithms list. If it > > doesn't include it, it either doesn't support it, or does > > not want to use it (in this context). > > > > This is not a matter of when a Server should select hash Z. This is > a matter of allowing the server to select hash Z when the server > knows that the client can, or must be able to, use hash Z. In this > case there can't be any interop issues by definition. I don't agree with this. What you are proposing is that a compliant client could offer this cipher suite but not be able to accept a signature with that digest. The server would then present a certificate with that digest and the client would fail. That's an interop issue. Yes, you could have some side agreement between the client and the server, but you've basically created some new protocol that happens to just look a lot like TLS 1.2. > As TLS 1.2 > currently is written, the Server is prohibited from stepping up the > security even if it knows that it would not cause any problems. I don't understand why it's a problem to simply have the client offer the extension in these special cases. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Dec 12 20:18: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 1J2ci5-0002Ru-An; Wed, 12 Dec 2007 20:17:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2ci3-0002Rp-Sg for tls-confirm+ok@megatron.ietf.org; Wed, 12 Dec 2007 20:17:55 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2ci3-0002Rh-IN for tls@ietf.org; Wed, 12 Dec 2007 20:17:55 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2ci3-0003me-41 for tls@ietf.org; Wed, 12 Dec 2007 20:17:55 -0500 Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id lBD1Hs4i015293; Thu, 13 Dec 2007 02:17:54 +0100 (MET) From: Martin Rex Message-Id: <200712130117.lBD1Hqeb004127@fs4113.wdf.sap.corp> Subject: Re: [TLS] RE: WGLC - Stepping up Hash To: ekr@networkresonance.com (Eric Rescorla) Date: Thu, 13 Dec 2007 02:17:52 +0100 (MET) In-Reply-To: <20071212230617.870E733C6D@delta.rtfm.com> from "Eric Rescorla" at Dec 12, 7 03:06:16 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > > As TLS 1.2 > > currently is written, the Server is prohibited from stepping up the > > security even if it knows that it would not cause any problems. > > I don't understand why it's a problem to simply have the client > offer the extension in these special cases. If there is any value in "stepping up" the hash, limiting its use to the official and correct negotiation in TLS 1.2 is not only architecturally clean, it also encourages all implementations capabable of doing it to adopt the interoperable negotiation -- whereas any permission for meta-knowlege-hacks might significantly impair adoption of a fully interoperable negotiation. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 01:48:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hrG-0000UB-Cl; Thu, 13 Dec 2007 01:47:46 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2hrF-0000U3-AS for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 01:47:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2hrE-0000Tr-83 for tls@ietf.org; Thu, 13 Dec 2007 01:47:44 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2hrD-0001oY-Lj for tls@ietf.org; Thu, 13 Dec 2007 01:47:44 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBD6lWc9030594; Thu, 13 Dec 2007 08:47:39 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 08:47:36 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Dec 2007 08:47:36 +0200 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: Thu, 13 Dec 2007 08:46:56 +0200 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC - Stepping up Hash Thread-Index: Acgw9Sz0FhpoohfNQHGlYiTjV/YjIgDnBkoQAe8NP+AAGNcUMAAXCuDQABF+9mA= References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> From: To: , X-OriginalArrivalTime: 13 Dec 2007 06:47:36.0285 (UTC) FILETIME=[0BB270D0:01C83D54] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: Subject: [TLS] RE: WGLC - Stepping up Hash 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 Stefan Santesson wrote: > Yes and No. No I don't want this assumption to be defined in=20 > the protocol. That would be pretty ugly and would have to be=20 > defined per cipher suite. > But Yes, the server may have deterministic knowledge that in=20 > the pool of clients it serves (or for the particular service=20 > it provides) either all clients, or a subgroup of the clients=20 > that uses a particular cipher suite, in fact can handle Hash Z. So you're assuming the existence of some off-line (outside TLS) negotiation capability (either between the hosts, or their=20 administrators) to exchange information about what the=20 implementations actually support? Given that we have the necessary functionality in TLS itself, why would you want to do that? (And if you do, would this extend to other parts of TLS as well -- e.g. allow server to select a cipher suite that the client didn't offer, if it has this "deterministic knowledge"?) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 13:59:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2tHE-000197-Uc; Thu, 13 Dec 2007 13:59:20 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2tHD-00018z-Vj for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 13:59:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2tHD-00018q-Kw for tls@ietf.org; Thu, 13 Dec 2007 13:59:19 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2tHD-0005Qg-76 for tls@ietf.org; Thu, 13 Dec 2007 13:59:19 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDIxHxt067654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Dec 2007 11:59:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 13 Dec 2007 10:59:16 -0800 To: tls@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [TLS] IDNs in draft-ietf-tls-rfc4366-bis 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 Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for the possibly-wrong discusion of IDNs in section 3. Summary: the text is completely broken. It does not follow the way that internationalized domain names (IDNs) have been implemented in other IETF protocols. A proposed way forward is to vastly simplify it. Old: "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding [RFC3629], without a trailing dot. If the hostname labels contain only US-ASCII characters, then the client MUST ensure that labels are separated only by the byte 0x2E, representing the dot character U+002E (requirement 1 in Section 3.1 of [RFC3490] notwithstanding). If the server needs to match the HostName against names that contain non-US-ASCII characters, it MUST perform the conversion operation described in Section 4 of [RFC3490], treating the HostName as a "query string" (i.e., the AllowUnassigned flag MUST be set). Note that IDNA allows labels to be separated by any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61; therefore, servers MUST accept any of these characters as a label separator. If the server only needs to match the HostName against names containing exclusively ASCII characters, it MUST compare ASCII names case-insensitively. New: "HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using the US-ASCII encoding described as the result of the ToASCII function in [RFC3490], without a trailing dot. Also, Section 11 should be removed; it makes no sense. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 15:19:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2uWs-0004bQ-Ae; Thu, 13 Dec 2007 15:19:34 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2uWr-0004bL-1m for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 15:19:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2uWq-0004bD-OJ for tls@ietf.org; Thu, 13 Dec 2007 15:19:32 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2uWn-000897-KT for tls@ietf.org; Thu, 13 Dec 2007 15:19:32 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBDKJA2d011073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 21:19:14 +0100 From: Simon Josefsson To: Paul Hoffman References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071213:paul.hoffman@vpnc.org::SKCndG0YcwzdEFS3:5RWB X-Hashcash: 1:22:071213:tls@ietf.org::Iav02AYLKpMCHAgK:09bIV Date: Thu, 13 Dec 2007 22:19:13 +0100 In-Reply-To: (Paul Hoffman's message of "Thu\, 13 Dec 2007 10\:59\:16 -0800") Message-ID: <873au6cmy6.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org Subject: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis 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 Paul Hoffman writes: > Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for the > possibly-wrong discusion of IDNs in section 3. Did you find out how MSIE/IIS implements this? > Summary: the text is completely broken. It does not follow the way > that internationalized domain names (IDNs) have been implemented in > other IETF protocols. A proposed way forward is to vastly simplify it. Another solution is to transfer the UTF-8 string and do processing on the receiving side. This seems to be a more reliable and future proof approach, given the changes that IDNAbis will bring. Note that this approach would not necessarily conflict with the deployed implementations that sends ACE encoded strings, such strings should be permitted as well. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 16:11:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vKr-00080t-CA; Thu, 13 Dec 2007 16:11:13 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2vKp-00080h-PS for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 16:11:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2vKp-00080X-FW for tls@ietf.org; Thu, 13 Dec 2007 16:11:11 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2vKp-00023N-0E for tls@ietf.org; Thu, 13 Dec 2007 16:11:11 -0500 Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id lBDLB20k028926; Thu, 13 Dec 2007 22:11:02 +0100 (MET) From: Martin Rex Message-Id: <200712132111.lBDLB1X5006793@fs4113.wdf.sap.corp> Subject: Re: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis To: simon@josefsson.org (Simon Josefsson) Date: Thu, 13 Dec 2007 22:11:00 +0100 (MET) In-Reply-To: <873au6cmy6.fsf@mocca.josefsson.org> from "Simon Josefsson" at Dec 13, 7 10:19:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: paul.hoffman@vpnc.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > > Paul Hoffman writes: > > > Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for the > > possibly-wrong discusion of IDNs in section 3. > > Did you find out how MSIE/IIS implements this? Yup, in case they have implemented and shipped this already, then they might have created an installed base that would be difficult to ignore. > > > Summary: the text is completely broken. It does not follow the way > > that internationalized domain names (IDNs) have been implemented in > > other IETF protocols. A proposed way forward is to vastly simplify it. > > Another solution is to transfer the UTF-8 string and do processing on > the receiving side. This seems to be a more reliable and future proof > approach, given the changes that IDNAbis will bring. > > Note that this approach would not necessarily conflict with the deployed > implementations that sends ACE encoded strings, such strings should be > permitted as well. I prefer the ACE-only approach suggest by Paul. (less options, less complexity, less code, less bugs, less interop problems) At the lower API levels, the IDNs (as provided by user or configuration) may no longer be available anyway and for TLS. Isn't the ACE encoding what the client will use to check the server's endpoint identification (e.g. rfc2818) and what is often contained in the server's certificate? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 17:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7x-00070M-Az; Thu, 13 Dec 2007 17:01:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2w7w-000707-3J for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:01:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0006zr-Oj for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0003H1-C1 for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDM1rO2086408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 15:01:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200712132111.lBDLB1X5006793@fs4113.wdf.sap.corp> References: <200712132111.lBDLB1X5006793@fs4113.wdf.sap.corp> Date: Thu, 13 Dec 2007 14:01:52 -0800 To: martin.rex@sap.com, simon@josefsson.org (Simon Josefsson) From: Paul Hoffman Subject: Re: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@ietf.org 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 At 10:11 PM +0100 12/13/07, Martin Rex wrote: >I prefer the ACE-only approach suggest by Paul. >(less options, less complexity, less code, less bugs, less interop problems) Those seem worthy of our attention. >At the lower API levels, the IDNs (as provided by user or configuration) >may no longer be available anyway and for TLS. > >Isn't the ACE encoding what the client will use to check the >server's endpoint identification (e.g. rfc2818) and what is often >contained in the server's certificate? Exactly right. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 17:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7x-00070G-2d; Thu, 13 Dec 2007 17:01:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2w7w-000706-2D for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:01:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0006zq-No for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0003H0-Bz for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDM1rO0086408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 15:01:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <873au6cmy6.fsf@mocca.josefsson.org> References: <873au6cmy6.fsf@mocca.josefsson.org> Date: Thu, 13 Dec 2007 14:01:06 -0800 To: Simon Josefsson From: Paul Hoffman Subject: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org 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 At 10:19 PM +0100 12/13/07, Simon Josefsson wrote: >Paul Hoffman writes: > >> Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for the >> possibly-wrong discusion of IDNs in section 3. > >Did you find out how MSIE/IIS implements this? No. Is that relevant? The document is not self-consistent, and it would seem likely that interoperability is not possible with the current text. >Another solution is to transfer the UTF-8 string and do processing on >the receiving side. This seems to be a more reliable and future proof >approach, given the changes that IDNAbis will bring. Which changes are those? I don't see any that would affect TLS using ASCII-encoded DNS names. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 17:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7x-00070M-Az; Thu, 13 Dec 2007 17:01:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2w7w-000707-3J for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:01:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0006zr-Oj for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0003H1-C1 for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDM1rO2086408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 15:01:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200712132111.lBDLB1X5006793@fs4113.wdf.sap.corp> References: <200712132111.lBDLB1X5006793@fs4113.wdf.sap.corp> Date: Thu, 13 Dec 2007 14:01:52 -0800 To: martin.rex@sap.com, simon@josefsson.org (Simon Josefsson) From: Paul Hoffman Subject: Re: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: tls@ietf.org 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 At 10:11 PM +0100 12/13/07, Martin Rex wrote: >I prefer the ACE-only approach suggest by Paul. >(less options, less complexity, less code, less bugs, less interop problems) Those seem worthy of our attention. >At the lower API levels, the IDNs (as provided by user or configuration) >may no longer be available anyway and for TLS. > >Isn't the ACE encoding what the client will use to check the >server's endpoint identification (e.g. rfc2818) and what is often >contained in the server's certificate? Exactly right. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 17:02:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7x-00070G-2d; Thu, 13 Dec 2007 17:01:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2w7w-000706-2D for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:01:56 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0006zq-No for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2w7v-0003H0-Bz for tls@ietf.org; Thu, 13 Dec 2007 17:01:55 -0500 Received: from [10.20.30.108] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBDM1rO0086408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Dec 2007 15:01:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <873au6cmy6.fsf@mocca.josefsson.org> References: <873au6cmy6.fsf@mocca.josefsson.org> Date: Thu, 13 Dec 2007 14:01:06 -0800 To: Simon Josefsson From: Paul Hoffman Subject: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org 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 At 10:19 PM +0100 12/13/07, Simon Josefsson wrote: >Paul Hoffman writes: > >> Greetings again. I agreed to review draft-ietf-tls-rfc4366-bis for the >> possibly-wrong discusion of IDNs in section 3. > >Did you find out how MSIE/IIS implements this? No. Is that relevant? The document is not self-consistent, and it would seem likely that interoperability is not possible with the current text. >Another solution is to transfer the UTF-8 string and do processing on >the receiving side. This seems to be a more reliable and future proof >approach, given the changes that IDNAbis will bring. Which changes are those? I don't see any that would affect TLS using ASCII-encoded DNS names. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 17:33:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wcj-0007kT-Mx; Thu, 13 Dec 2007 17:33:45 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2wch-0007k2-S4 for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:33:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wch-0007jJ-Hc for tls@ietf.org; Thu, 13 Dec 2007 17:33:43 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J2wcg-0004SM-QC for tls@ietf.org; Thu, 13 Dec 2007 17:33:43 -0500 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by DUB-EXGWY-E801.partners.extranet.microsoft.com (10.251.129.1) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 13 Dec 2007 22:33:41 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.88]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Thu, 13 Dec 2007 22:33:42 +0000 From: Stefan Santesson To: Eric Rescorla Date: Thu, 13 Dec 2007 22:33:39 +0000 Subject: RE: [TLS] RE: WGLC - Stepping up Hash Thread-Topic: [TLS] RE: WGLC - Stepping up Hash Thread-Index: Acg9FGS9zTbUNt2tQa2GeAAfo7haxwAvDotQ Message-ID: <9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> <20071212230617.870E733C6D@delta.rtfm.com> In-Reply-To: <20071212230617.870E733C6D@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "tls@ietf.org" 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 In, line Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 12 december 2007 15:06 > To: Stefan Santesson > Cc: Pasi.Eronen@nokia.com; tls@ietf.org > Subject: Re: [TLS] RE: WGLC - Stepping up Hash > > At Wed, 12 Dec 2007 22:30:44 +0000, > > > > I fail to see the harm if some servers successfully deploys > > > > better security while other servers in the same situation would > > > > choose to stick to the default security level. > > > > > > > > As long as the server can determine successfully the capacity > > > > of the client and successfully communicate the choice of > > > > algorithms, then the only thing that can happen is that we > > > > would simply allow the server to choose better security. > > > > > > > > If there is no need for all servers to provide a uniform > > > > behavior then we don't need to specify the exact conditions > > > > under which the server can gain knowledge of the client's > > > > capacity. This can range from local configuration and local > > > > policy to a local convention based on the ciphersuites > > > > supported by the client. > > > > > > Do you mean something along the lines "if the client > > > proposes ciphersuite TLS_X_WITH_Y, then the server assumes > > > that the client will also support hash Z, even though > > > the client didn't include Z in signature_algorithms > > > extension"? > > > > > > > Yes and No. No I don't want this assumption to be defined in the > > protocol. That would be pretty ugly and would have to be defined per > > cipher suite. But Yes, the server may have deterministic knowledge > > that in the pool of clients it serves (or for the particular service > > it provides) either all clients, or a subgroup of the clients that > > uses a particular cipher suite, in fact can handle Hash Z. > > Yes, it might. But that's contrary to the general goal of > explicit signalling. > Not as I see it. If the server chooses to use a better hash than SHA-1, it = MUST inform the client of this requirement. As to knowing the capacity, the= hash in the finished message is already bound to the PRF defined by the ci= phersuite. So the Server can be assured of this capacity of the client with= out it being explicitly stated in the client hello extension. Why is this s= o much harder for key and certificate exchange messages. > > > > > This sounds like a recipe for horrible interop problems > > > unless the specification actually says that "all implementations > > > which support TLS_X_WITH_Y must also support hash Z". While > > > this could perhaps be done, I don't quite understand why > > > it would be useful: if the client does indeed support Z, it > > > will include it in the signature_algorithms list. If it > > > doesn't include it, it either doesn't support it, or does > > > not want to use it (in this context). > > > > > > > This is not a matter of when a Server should select hash Z. This is > > a matter of allowing the server to select hash Z when the server > > knows that the client can, or must be able to, use hash Z. In this > > case there can't be any interop issues by definition. > > I don't agree with this. What you are proposing is that a compliant > client could offer this cipher suite but not be able to accept > a signature with that digest. The server would then present > a certificate with that digest and the client would fail. That's > an interop issue. Yes, you could have some side agreement > between the client and the server, but you've basically > created some new protocol that happens to just look a lot > like TLS 1.2. > The server should never force the client to sign or validate anything that = is not supported by the selected cipher suite. But what if the server and client agrees to CipherSuite TLS_ECDHE_ECDSA_WIT= H_AES_128_CBC_SHA256, but the client does not provide a signature_algorithm= s extension? Following the current definition in the Server Key exchange message, the se= rver would be forced to specify SHA-1 as hash algorithm. That does not make= any sense to me. > > > As TLS 1.2 > > currently is written, the Server is prohibited from stepping up the > > security even if it knows that it would not cause any problems. > > I don't understand why it's a problem to simply have the client > offer the extension in these special cases. > It is not. But what if it doesn't. This should clearly be the implementatio= n goal for all clients. However, theory and practice don't always meet and = we should not create rules that prevents the server from safely step up the= security level in case the client fail to send this info. Or we should REQ= UIRE the client to provide this extension in these cases (e.g. for some cip= her suites). The client is after all not required to provide this in the cu= rrent spec. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 17:55:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wy9-0008Pr-KP; Thu, 13 Dec 2007 17:55:53 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2wy8-0008Pg-0r for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 17:55:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2wy7-0008PY-LU for tls@ietf.org; Thu, 13 Dec 2007 17:55:51 -0500 Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2wy6-0004wo-RN for tls@ietf.org; Thu, 13 Dec 2007 17:55:51 -0500 Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 8027B33C6D; Thu, 13 Dec 2007 14:50:22 -0800 (PST) Date: Thu, 13 Dec 2007 14:50:21 -0800 From: Eric Rescorla To: Stefan Santesson Subject: Re: [TLS] RE: WGLC - Stepping up Hash In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> <20071212230617.870E733C6D@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071213225022.8027B33C6D@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: "tls@ietf.org" 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 At Thu, 13 Dec 2007 22:33:39 +0000, Stefan Santesson wrote: > > At Wed, 12 Dec 2007 22:30:44 +0000, > > > > > I fail to see the harm if some servers successfully deploys > > > > > better security while other servers in the same situation would > > > > > choose to stick to the default security level. > > > > > > > > > > As long as the server can determine successfully the capacity > > > > > of the client and successfully communicate the choice of > > > > > algorithms, then the only thing that can happen is that we > > > > > would simply allow the server to choose better security. > > > > > > > > > > If there is no need for all servers to provide a uniform > > > > > behavior then we don't need to specify the exact conditions > > > > > under which the server can gain knowledge of the client's > > > > > capacity. This can range from local configuration and local > > > > > policy to a local convention based on the ciphersuites > > > > > supported by the client. > > > > > > > > Do you mean something along the lines "if the client > > > > proposes ciphersuite TLS_X_WITH_Y, then the server assumes > > > > that the client will also support hash Z, even though > > > > the client didn't include Z in signature_algorithms > > > > extension"? > > > > > > > > > > Yes and No. No I don't want this assumption to be defined in the > > > protocol. That would be pretty ugly and would have to be defined per > > > cipher suite. But Yes, the server may have deterministic knowledge > > > that in the pool of clients it serves (or for the particular service > > > it provides) either all clients, or a subgroup of the clients that > > > uses a particular cipher suite, in fact can handle Hash Z. > > > > Yes, it might. But that's contrary to the general goal of > > explicit signalling. > > > > Not as I see it. If the server chooses to use a better hash than > SHA-1, it MUST inform the client of this requirement. Yes, I'm talking about explicit signalling of capabilities. > As to knowing > the capacity, the hash in the finished message is already bound to > the PRF defined by the ciphersuite. So the Server can be assured of > this capacity of the client without it being explicitly stated in > the client hello extension. Yes, but the capabilities of the implementation in terms of HMAC and the cipher suite may or may not be the same as the capabilities available for certificate validation. That's why we have a separate extension to indicate those capabilities. > Why is this so much harder for key and > certificate exchange messages. It's not "harder", it's just not how this is negotiated in TLS 1.2, for the reasons indicated above. > > I don't agree with this. What you are proposing is that a compliant > > client could offer this cipher suite but not be able to accept > > a signature with that digest. The server would then present > > a certificate with that digest and the client would fail. That's > > an interop issue. Yes, you could have some side agreement > > between the client and the server, but you've basically > > created some new protocol that happens to just look a lot > > like TLS 1.2. > > > > The server should never force the client to sign or validate > anything that is not supported by the selected cipher suite. But > what if the server and client agrees to CipherSuite > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, but the client does not > provide a signature_algorithms extension? Following the current > definition in the Server Key exchange message, the server would be > forced to specify SHA-1 as hash algorithm. That does not make any > sense to me. I'm sorry it doesn't make sense to you. I consider it quite reasonable. What doesn't make sense is for the server to assume the client supports a given digest when the client has explicitly declined to inform the server that it in fact does so. > > > As TLS 1.2 > > > currently is written, the Server is prohibited from stepping up the > > > security even if it knows that it would not cause any problems. > > > > I don't understand why it's a problem to simply have the client > > offer the extension in these special cases. > > > > It is not. But what if it doesn't. If it doesn't, what the server does is clear: it assumes that the client knows SHA-1. Again, I don't see what the problem is here. > should clearly be the implementation goal for all clients. However, > theory and practice don't always meet and we should not create rules > that prevents the server from safely step up the security level in > case the client fail to send this info. I don't agree. This isn't about stepping up or stepping down. It's about the server choosing to use cryptographic algorithms that the client didn't offer. That creates interop problems. > Or we should REQUIRE the > client to provide this extension in these cases (e.g. for some > cipher suites). Again, what the client supports for certificate verification and what it supports in the cipher suite are orthogonal issues. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 13 18:02: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 1J2x4F-0002IG-6M; Thu, 13 Dec 2007 18:02:11 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J2x4D-0002I7-Jg for tls-confirm+ok@megatron.ietf.org; Thu, 13 Dec 2007 18:02:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J2x4D-0002Hz-7c for tls@ietf.org; Thu, 13 Dec 2007 18:02:09 -0500 Received: from smtp-dub.microsoft.com ([213.199.138.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J2x4C-00055B-BZ for tls@ietf.org; Thu, 13 Dec 2007 18:02:09 -0500 Received: from DUB-EXHUB-C303.europe.corp.microsoft.com (65.53.213.93) by DUB-EXGWY-E802.partners.extranet.microsoft.com (10.251.129.2) with Microsoft SMTP Server (TLS) id 8.1.222.3; Thu, 13 Dec 2007 23:02:07 +0000 Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.88]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Thu, 13 Dec 2007 23:02:07 +0000 From: Stefan Santesson To: Eric Rescorla Date: Thu, 13 Dec 2007 23:02:05 +0000 Subject: RE: [TLS] RE: WGLC - Stepping up Hash Thread-Topic: [TLS] RE: WGLC - Stepping up Hash Thread-Index: Acg921YPi/aw4WKkSaClVW7s9aqK6gAAIv7w Message-ID: <9F11911AED01D24BAA1C2355723C3D320A10F36C37@EA-EXMSG-C332.europe.corp.microsoft.com> References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com> <9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> <20071212230617.870E733C6D@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> <20071213225022.8027B33C6D@delta.rtfm.com> In-Reply-To: <20071213225022.8027B33C6D@delta.rtfm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: "tls@ietf.org" 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 OK Eric, I won't take this argument any further. At least I have assured myself that= you have considered this issue from all angles. Getting this document through the process is more important. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Eric Rescorla [mailto:ekr@networkresonance.com] > Sent: den 13 december 2007 14:50 > To: Stefan Santesson > Cc: Eric Rescorla; Pasi.Eronen@nokia.com; tls@ietf.org > Subject: Re: [TLS] RE: WGLC - Stepping up Hash > > At Thu, 13 Dec 2007 22:33:39 +0000, > Stefan Santesson wrote: > > > At Wed, 12 Dec 2007 22:30:44 +0000, > > > > > > I fail to see the harm if some servers successfully deploys > > > > > > better security while other servers in the same situation > would > > > > > > choose to stick to the default security level. > > > > > > > > > > > > As long as the server can determine successfully the capacity > > > > > > of the client and successfully communicate the choice of > > > > > > algorithms, then the only thing that can happen is that we > > > > > > would simply allow the server to choose better security. > > > > > > > > > > > > If there is no need for all servers to provide a uniform > > > > > > behavior then we don't need to specify the exact conditions > > > > > > under which the server can gain knowledge of the client's > > > > > > capacity. This can range from local configuration and local > > > > > > policy to a local convention based on the ciphersuites > > > > > > supported by the client. > > > > > > > > > > Do you mean something along the lines "if the client > > > > > proposes ciphersuite TLS_X_WITH_Y, then the server assumes > > > > > that the client will also support hash Z, even though > > > > > the client didn't include Z in signature_algorithms > > > > > extension"? > > > > > > > > > > > > > Yes and No. No I don't want this assumption to be defined in the > > > > protocol. That would be pretty ugly and would have to be defined > per > > > > cipher suite. But Yes, the server may have deterministic > knowledge > > > > that in the pool of clients it serves (or for the particular > service > > > > it provides) either all clients, or a subgroup of the clients > that > > > > uses a particular cipher suite, in fact can handle Hash Z. > > > > > > Yes, it might. But that's contrary to the general goal of > > > explicit signalling. > > > > > > > Not as I see it. If the server chooses to use a better hash than > > SHA-1, it MUST inform the client of this requirement. > > Yes, I'm talking about explicit signalling of capabilities. > > > > As to knowing > > the capacity, the hash in the finished message is already bound to > > the PRF defined by the ciphersuite. So the Server can be assured of > > this capacity of the client without it being explicitly stated in > > the client hello extension. > > Yes, but the capabilities of the implementation in terms of HMAC > and the cipher suite may or may not be the same as the capabilities > available for certificate validation. That's why we have a separate > extension to indicate those capabilities. > > > > Why is this so much harder for key and > > certificate exchange messages. > > It's not "harder", it's just not how this is negotiated in TLS 1.2, > for the reasons indicated above. > > > > > I don't agree with this. What you are proposing is that a compliant > > > client could offer this cipher suite but not be able to accept > > > a signature with that digest. The server would then present > > > a certificate with that digest and the client would fail. That's > > > an interop issue. Yes, you could have some side agreement > > > between the client and the server, but you've basically > > > created some new protocol that happens to just look a lot > > > like TLS 1.2. > > > > > > > The server should never force the client to sign or validate > > anything that is not supported by the selected cipher suite. But > > what if the server and client agrees to CipherSuite > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, but the client does not > > provide a signature_algorithms extension? Following the current > > definition in the Server Key exchange message, the server would be > > forced to specify SHA-1 as hash algorithm. That does not make any > > sense to me. > > I'm sorry it doesn't make sense to you. I consider it quite > reasonable. What doesn't make sense is for the server to > assume the client supports a given digest when the client > has explicitly declined to inform the server that it in fact > does so. > > > > > > As TLS 1.2 > > > > currently is written, the Server is prohibited from stepping up > the > > > > security even if it knows that it would not cause any problems. > > > > > > I don't understand why it's a problem to simply have the client > > > offer the extension in these special cases. > > > > > > > It is not. But what if it doesn't. > > If it doesn't, what the server does is clear: it assumes that the > client > knows SHA-1. Again, I don't see what the problem is here. > > > > should clearly be the implementation goal for all clients. However, > > theory and practice don't always meet and we should not create rules > > that prevents the server from safely step up the security level in > > case the client fail to send this info. > > I don't agree. This isn't about stepping up or stepping down. It's > about the server choosing to use cryptographic algorithms that > the client didn't offer. That creates interop problems. > > > > Or we should REQUIRE the > > client to provide this extension in these cases (e.g. for some > > cipher suites). > > Again, what the client supports for certificate verification and > what it supports in the cipher suite are orthogonal issues. > > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 14 02:35:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J354N-00012i-PB; Fri, 14 Dec 2007 02:34:51 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J354M-00012a-Pb for tls-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 02:34:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J354M-00012R-5C for tls@ietf.org; Fri, 14 Dec 2007 02:34:50 -0500 Received: from smtp.nokia.com ([192.100.122.233] helo=mgw-mx06.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J354L-0006k2-Jb for tls@ietf.org; Fri, 14 Dec 2007 02:34:50 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBE7YKNw015411; Fri, 14 Dec 2007 09:34:47 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 09:34:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 09:34:07 +0200 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 Subject: RE: [TLS] RE: WGLC - Stepping up Hash Date: Fri, 14 Dec 2007 09:34:08 +0200 Message-ID: In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] RE: WGLC - Stepping up Hash Thread-Index: Acg9FGS9zTbUNt2tQa2GeAAfo7haxwAvDotQABRuVGA= References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com><9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com><9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com> <20071212230617.870E733C6D@delta.rtfm.com> <9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> From: To: X-OriginalArrivalTime: 14 Dec 2007 07:34:07.0355 (UTC) FILETIME=[B5B7ACB0:01C83E23] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@ietf.org 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 Stefan Santesson wrote: > > I don't understand why it's a problem to simply have the client > > offer the extension in these special cases. >=20 > It is not. But what if it doesn't. This should clearly be the=20 > implementation goal for all clients. However, theory and=20 > practice don't always meet and we should not create rules=20 > that prevents the server from safely step up the security=20 > level in case the client fail to send this info. Or we should=20 > REQUIRE the client to provide this extension in these cases=20 > (e.g. for some cipher suites). The client is after all not=20 > required to provide this in the current spec. I think the source of this confusion is the sentence "Clients=20 SHOULD send this extension if they support any hash algorithm=20 other than SHA-1" (in Section 7.4.1.4.1) This is not quite correct. It should say something along the lines: "If the client supports other hash and signature=20 algorithms (than the defaults listed in this section),=20 and it is willing to use them for verifying messages=20 sent by server (server certificates and server key exchange),=20 it MUST send the signature_algorithms extension listing the algorithms it is willing to accept." (IMHO this is what the current spec implicitly means.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 14 03:50:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J36FS-00056o-Fw; Fri, 14 Dec 2007 03:50:22 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J36FR-00056i-2x for tls-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 03:50:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J36FQ-00054u-OB for tls@ietf.org; Fri, 14 Dec 2007 03:50:20 -0500 Received: from smtp.nokia.com ([192.100.105.134] helo=mgw-mx09.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J36FQ-0008LP-CJ for tls@ietf.org; Fri, 14 Dec 2007 03:50:20 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBE8oEQt011975; Fri, 14 Dec 2007 02:50:35 -0600 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 10:49:59 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 10:49:59 +0200 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 Subject: RE: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis Date: Fri, 14 Dec 2007 10:50:00 +0200 Message-ID: In-Reply-To: <873au6cmy6.fsf@mocca.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: IDNs in draft-ietf-tls-rfc4366-bis Thread-Index: Acg9xZd6voGNaFZqRiGX0VCW++XCiwAaFnvQ References: <873au6cmy6.fsf@mocca.josefsson.org> From: To: X-OriginalArrivalTime: 14 Dec 2007 08:49:59.0433 (UTC) FILETIME=[4EF7A790:01C83E2E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: tls@ietf.org 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 Simon Josefsson wrote: > Did you find out how MSIE/IIS implements this? I just tested this with IE7 on Vista: it sends the ACE-encoded string (xn--) in server_name extension (just like Firefox). So Paul's proposed text seems to be OK in this regard, too. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 14 11:21:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3DHk-00030g-49; Fri, 14 Dec 2007 11:21:12 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J3DHi-0002zl-UT for tls-confirm+ok@megatron.ietf.org; Fri, 14 Dec 2007 11:21:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J3DHi-0002zF-JG for tls@ietf.org; Fri, 14 Dec 2007 11:21:10 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J3DHi-0002Ed-4S for tls@ietf.org; Fri, 14 Dec 2007 11:21:10 -0500 Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lBEGL72p019256 for ; Fri, 14 Dec 2007 11:21:07 -0500 (EST) X-AuditID: 90333308-000014d800000748-0e-4762ad735bf6 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Dec 2007 11:21:07 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 14 Dec 2007 11:21:06 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] RE: WGLC - Stepping up Hash Date: Fri, 14 Dec 2007 11:21:06 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] RE: WGLC - Stepping up Hash Thread-Index: Acg9FGS9zTbUNt2tQa2GeAAfo7haxwAvDotQABRuVGAAEgI4QA== References: <9F11911AED01D24BAA1C2355723C3D320567FF2229@EA-EXMSG-C332.europe.corp.microsoft.com><9F11911AED01D24BAA1C2355723C3D320A10E835BD@EA-EXMSG-C332.europe.corp.microsoft.com><9F11911AED01D24BAA1C2355723C3D320A10E83C0C@EA-EXMSG-C332.europe.corp.microsoft.com><20071212230617.870E733C6D@delta.rtfm.com><9F11911AED01D24BAA1C2355723C3D320A10F36C32@EA-EXMSG-C332.europe.corp.microsoft.com> From: "Kemp, David P." To: X-OriginalArrivalTime: 14 Dec 2007 16:21:06.0799 (UTC) FILETIME=[545FEFF0:01C83E6D] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: 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 I agree with Martin Rex that permitting implicit (meta-knowledge-based) signaling could inhibit implementation of proper signaling, and that the interoperability disadvantage (when meta-knowledge turns out to be wrong) outweighs any advantage of being able to use step-up hash with clients that support additional hash algorithms but do not send the extension. Such clients, if there are any, should be fixed. The spec should be modified along the lines suggested below to remove ambiguity from the requirement for explicit signaling. Dave -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Friday, December 14, 2007 2:34 AM To: stefans@microsoft.com Cc: tls@ietf.org Subject: RE: [TLS] RE: WGLC - Stepping up Hash Stefan Santesson wrote: > > I don't understand why it's a problem to simply have the client > > offer the extension in these special cases. >=20 > It is not. But what if it doesn't. This should clearly be the=20 > implementation goal for all clients. However, theory and=20 > practice don't always meet and we should not create rules=20 > that prevents the server from safely step up the security=20 > level in case the client fail to send this info. Or we should=20 > REQUIRE the client to provide this extension in these cases=20 > (e.g. for some cipher suites). The client is after all not=20 > required to provide this in the current spec. I think the source of this confusion is the sentence "Clients=20 SHOULD send this extension if they support any hash algorithm=20 other than SHA-1" (in Section 7.4.1.4.1) This is not quite correct. It should say something along the lines: "If the client supports other hash and signature=20 algorithms (than the defaults listed in this section),=20 and it is willing to use them for verifying messages=20 sent by server (server certificates and server key exchange),=20 it MUST send the signature_algorithms extension listing the algorithms it is willing to accept." (IMHO this is what the current spec implicitly means.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 17 11:02:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IQI-0002A4-CO; Mon, 17 Dec 2007 11:02:30 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J4IQH-00028L-0E for tls-confirm+ok@megatron.ietf.org; Mon, 17 Dec 2007 11:02:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J4IQG-00025R-I5 for tls@ietf.org; Mon, 17 Dec 2007 11:02:28 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J4IQG-0003k9-00 for tls@ietf.org; Mon, 17 Dec 2007 11:02:28 -0500 Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id lBHG29Af011977 for ; Mon, 17 Dec 2007 17:02:15 +0100 (MET) From: Martin Rex Message-Id: <200712171602.lBHG29TY008803@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Mon, 17 Dec 2007 17:02:09 +0100 (MET) In-Reply-To: from "Internet-Drafts@ietf.org" at Dec 15, 7 04:20:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal07 X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [TLS] Re: I-D Action:draft-hajjeh-tls-sign-04.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Here they go again. It's not verbatim the same as the previous TLS evidence proposal, but as far as application level signing is concerned, has all the same problems. Internet-Drafts@ietf.org wrote: > > Title : TLS Sign > Author(s) : I. Hajjeh, M. Badra > Filename : draft-hajjeh-tls-sign-04.txt > Pages : 12 > Date : 2007-12-15 > > TLS protocol provides authentication and data protection for > communication between two entities. However, missing from the > protocol is a way to perform non-repudiation service. If the only tool in your toolchest is a hammer, then everything looks like a nail. I don't want to see this document published in the RFC series.o -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 12:34:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5PHv-0001P8-Mh; Thu, 20 Dec 2007 12:34:27 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5PHu-0001P3-Mw for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 12:34:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5PHu-0001Ov-DC for tls@ietf.org; Thu, 20 Dec 2007 12:34:26 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5PHs-0006Gw-75 for tls@ietf.org; Thu, 20 Dec 2007 12:34:26 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id C6CD25081A for ; Thu, 20 Dec 2007 09:34:00 -0800 (PST) Date: Thu, 20 Dec 2007 09:34:00 -0800 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071220173400.C6CD25081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] Status of IDEA 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 In the current draft of TLS 1.2, IDEA is marked as MUST NOT. Some in the WG felt that it should be a SHOULD NOT. The minutes read: Pasi asked if it was really OK to make IDEA a MUST NOT do at the current codepoint Russ Housley didn't like the idea Paul Hoffman said that listing untested algorithms causes developers to use them Stefan Santesson said we should leave a holder in Straw poll: SHOULD NOT and MUST NOT got roughly equal support Will take to the list Please use this thread for discussion of this topic. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 13:30:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QA6-0002QY-MT; Thu, 20 Dec 2007 13:30:26 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5QA6-0002QS-83 for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 13:30:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QA5-0002QJ-JM for tls@ietf.org; Thu, 20 Dec 2007 13:30:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5QA5-0004SY-5t for tls@ietf.org; Thu, 20 Dec 2007 13:30:25 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBKIUMhX043137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Dec 2007 11:30:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20071220173400.C6CD25081A@romeo.rtfm.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> Date: Thu, 20 Dec 2007 10:29:59 -0800 To: tls@ietf.org From: Paul Hoffman Subject: Re: [TLS] Status of IDEA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: 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 experience in the IPsec WG for algorithms that are listed but not mandated in the base spec was that many developers did a first pass at implementing them, but rarely tested their implementations. This could easily lead to serious security issues that would go unnoticed. I do not understand what "SHOULD NOT" for IDEA would mean. "Don't do it unless you really want to"? "Don't do it unless the other side only can do IDEA and not any of the mandatory-to-implement ciphers which it did not implement"? Having IDEA and DES and RC2 MUST NOT makes it completely clear to implementers what they are allowed to do. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 14:11:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QnY-00088c-AW; Thu, 20 Dec 2007 14:11:12 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5QnW-00081N-5r for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 14:11:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5QnV-00081E-LQ for tls@ietf.org; Thu, 20 Dec 2007 14:11:09 -0500 Received: from llmail1.ll.mit.edu ([129.55.12.41] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5QnT-000824-DH for tls@ietf.org; Thu, 20 Dec 2007 14:11:09 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id lBKJB4sZ005869 for ; Thu, 20 Dec 2007 14:11:04 -0500 (EST) Received: from lle2k7-hub01.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB01.mitll.ad.local" via SMTP by llpost, id smtpdAAAGha4wl; Thu Dec 20 14:10:58 2007 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB01.mitll.ad.local ([ ]) with mapi; Thu, 20 Dec 2007 14:10:58 -0500 From: "Blumenthal, Uri" To: "tls@ietf.org" Date: Thu, 20 Dec 2007 14:10:56 -0500 Subject: Re: [TLS] Status of IDEA Thread-Topic: [TLS] Status of IDEA Thread-Index: AchDNmxFO+1SBh4RSee3aoVsglJUDwABZ/RX Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: 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: , Content-Type: multipart/mixed; boundary="===============0936694352==" Errors-To: tls-bounces@lists.ietf.org --===============0936694352== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C390287011Curillmitedu_" --_000_C390287011Curillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Paul. Meaning of "SHOULD NOT" is confusing, to say the least.= Our intention seems clear: we do not want people to put IDEA in their TLS = implementations. IMHO, let the standard say "MUST NOT". If there are exceptions convincing enough that this group is likely to cons= ider them - spell them out. On 12/20/07 1:29 PM, "Paul Hoffman" wrote: The experience in the IPsec WG for algorithms that are listed but not mandated in the base spec was that many developers did a first pass at implementing them, but rarely tested their implementations. This could easily lead to serious security issues that would go unnoticed. I do not understand what "SHOULD NOT" for IDEA would mean. "Don't do it unless you really want to"? "Don't do it unless the other side only can do IDEA and not any of the mandatory-to-implement ciphers which it did not implement"? Having IDEA and DES and RC2 MUST NOT makes it completely clear to implementers what they are allowed to do. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls -- Regards, Uri --_000_C390287011Curillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Status of IDEA I= agree with Paul. Meaning of  “SHOULD NOT” is confusing, t= o say the least. Our intention seems clear: we do not want people to put ID= EA in their TLS implementations. IMHO, let the standard say “MUST NOT= ”.

If there are exceptions convincing enough that this group is likely to cons= ider them – spell them out.


On 12/20/07 1:29 PM, "Paul Hoffman" <paul.hoffman@vpnc.org>= wrote:

The experience in the IPsec WG for algorithms that= are listed but not
mandated in the base spec was that many developers did a first pass
at implementing them, but rarely tested their implementations. This
could easily lead to serious security issues that would go unnoticed.

I do not understand what "SHOULD NOT" for IDEA would mean. "= Don't do
it unless you really want to"? "Don't do it unless the other side=
only can do IDEA and not any of the mandatory-to-implement ciphers
which it did not implement"? Having IDEA and DES and RC2 MUST NOT
makes it completely clear to implementers what they are allowed to do.

--Paul Hoffman, Director
--VPN Consortium


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



--
Regards,
Uri

 --_000_C390287011Curillmitedu_-- --===============0936694352== 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 --===============0936694352==-- From tls-bounces@lists.ietf.org Thu Dec 20 15:30:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5S2L-0001bA-6t; Thu, 20 Dec 2007 15:30:33 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5S2K-0001Zu-3K for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 15:30:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5S2I-0001VM-Fx for tls@ietf.org; Thu, 20 Dec 2007 15:30:31 -0500 Received: from colo.trepanning.net ([69.55.226.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5S2G-0001gi-UZ for tls@ietf.org; Thu, 20 Dec 2007 15:30:30 -0500 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 29EC71FA61DE; Thu, 20 Dec 2007 12:30:28 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 20 Dec 2007 12:30:28 -0800 (PST) Message-ID: <26506.216.31.249.246.1198182628.squirrel@www.trepanning.net> In-Reply-To: References: <20071220173400.C6CD25081A@romeo.rtfm.com> Date: Thu, 20 Dec 2007 12:30:28 -0800 (PST) Subject: Re: [TLS] Status of IDEA From: "Dan Harkins" To: "Paul Hoffman" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@ietf.org 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 I agree. One of the (many) lessons learned from IKE is that vanity algorithms just cause problems. Whether there's a compelling need for IDEA or not, saying "SHOULD NOT" is wrong. If there's a compelling need then "MAY" seems appropriate; if there's no compelling need then "MUST NOT" is nice and unambiguous. Dan. On Thu, December 20, 2007 10:29 am, Paul Hoffman wrote: > The experience in the IPsec WG for algorithms that are listed but not > mandated in the base spec was that many developers did a first pass > at implementing them, but rarely tested their implementations. This > could easily lead to serious security issues that would go unnoticed. > > I do not understand what "SHOULD NOT" for IDEA would mean. "Don't do > it unless you really want to"? "Don't do it unless the other side > only can do IDEA and not any of the mandatory-to-implement ciphers > which it did not implement"? Having IDEA and DES and RC2 MUST NOT > makes it completely clear to implementers what they are allowed to do. > > --Paul Hoffman, Director > --VPN Consortium > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 16:06:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Say-0000sS-Un; Thu, 20 Dec 2007 16:06:20 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Sax-0000sH-Iv for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:06:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Sav-0000s1-19 for tls@ietf.org; Thu, 20 Dec 2007 16:06:17 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J5Sas-0003iR-CF for tls@ietf.org; Thu, 20 Dec 2007 16:06:14 -0500 Received: (qmail 21989 invoked by uid 0); 20 Dec 2007 21:06:07 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 20 Dec 2007 21:06:07 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Dec 2007 16:06:06 -0500 To: Eric Rescorla ,tls@ietf.org From: Russ Housley Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220173400.C6CD25081A@romeo.rtfm.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Message-Id: Cc: 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 code point for IDEA are already assigned. I understand that some implementations support it. I'm most comfortable with MAY support IDEA, and I can live with SHOULD NOT support IDEA. If we are going to completely deprecate IDEA in TLS, we need to give notice to implementors. The SHOULD NOT gives the notice so that it can go away (not be mentioned at all) in the next version. Russ At 12:34 PM 12/20/2007, Eric Rescorla wrote: >In the current draft of TLS 1.2, IDEA is marked as MUST NOT. Some in >the WG felt that it should be a SHOULD NOT. The minutes read: > > Pasi asked if it was really OK to make IDEA a MUST NOT do at the > current codepoint > Russ Housley didn't like the idea > Paul Hoffman said that listing untested algorithms > causes developers to use them > Stefan Santesson said we should leave a holder in > Straw poll: SHOULD NOT and MUST NOT got roughly equal support > Will take to the list > >Please use this thread for discussion of this topic. > >-Ekr > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 16:11:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Sfo-0006ov-IW; Thu, 20 Dec 2007 16:11:20 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Sfm-0006QJ-AZ for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:11:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Sfl-0006Jb-EU for tls@ietf.org; Thu, 20 Dec 2007 16:11:17 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Sfl-00039C-3u for tls@ietf.org; Thu, 20 Dec 2007 16:11:17 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id E15885081A; Thu, 20 Dec 2007 13:10:53 -0800 (PST) Date: Thu, 20 Dec 2007 13:10:53 -0800 From: Eric Rescorla To: Russ Housley Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220205835.480815C027@laser.networkresonance.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071220211053.E15885081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@ietf.org 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 At Thu, 20 Dec 2007 16:06:06 -0500, Russ Housley wrote: > > The code point for IDEA are already assigned. I understand that some > implementations support it. I'm most comfortable with MAY support > IDEA, and I can live with SHOULD NOT support IDEA. If we are going > to completely deprecate IDEA in TLS, we need to give notice to > implementors. Well, this won't affect TLS < 1.2 at all, right? So given that AES is MUST implement, why do they need warning? > The SHOULD NOT gives the notice so that it can go away > (not be mentioned at all) in the next version. So, TLS practice has not been not to not mention, but rather to list the code points with MUST NOT labels. That's what we do with, for instance, DES40. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 16:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5T1F-0004Bi-9g; Thu, 20 Dec 2007 16:33:29 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5T1D-0003wS-Ga for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:33:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5T1C-0003rg-TW for tls@ietf.org; Thu, 20 Dec 2007 16:33:26 -0500 Received: from yancy.pkiclue.com ([209.172.115.117] helo=yancy.b70.net) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5T1C-0003kY-B6 for tls@ietf.org; Thu, 20 Dec 2007 16:33:26 -0500 Received: from [127.0.0.1] (localhost [127.0.0.1]) by yancy.b70.net (8.9.3/8.9.3) with ESMTP id OAA05730 for ; Thu, 20 Dec 2007 14:42:00 -0800 Message-ID: <476ADFA1.2080707@canola-jones.com> Date: Thu, 20 Dec 2007 13:33:21 -0800 From: Rodney Thayer User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Status of IDEA References: <20071220173400.C6CD25081A@romeo.rtfm.com> In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 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 Default builds of OpenSSL (including some shipped with the Mac, for example) supported IDEA. So I think 'some notice' is appropriate. I think that making it a "MAY" and making a note in the spec that the wg intends to deprecate it completely in a future version would be the thing to do. I don't think there are any current implementations in the wild that 'need' IDEA. Anyone got evidence that claim is wrong? Russ Housley wrote: > The code point for IDEA are already assigned. I understand that some > implementations support it. I'm most comfortable with MAY support IDEA, > and I can live with SHOULD NOT support IDEA. If we are going to > completely deprecate IDEA in TLS, we need to give notice to > implementors. The SHOULD NOT gives the notice so that it can go away > (not be mentioned at all) in the next version. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 16:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5T7M-0004aj-9i; Thu, 20 Dec 2007 16:39:48 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5T7K-0004GQ-6W for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:39:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5T7J-00048a-KF for tls@ietf.org; Thu, 20 Dec 2007 16:39:45 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J5T7J-0004Sd-94 for tls@ietf.org; Thu, 20 Dec 2007 16:39:45 -0500 Received: (qmail 31680 invoked by uid 0); 20 Dec 2007 21:39:37 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 20 Dec 2007 21:39:37 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Dec 2007 16:39:42 -0500 To: Eric Rescorla From: Russ Housley Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220211053.E15885081A@romeo.rtfm.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Message-Id: Cc: tls@ietf.org 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 Eric: TLS 1.1 lists the IDEA cipher suites with no real label. The text says that they are included for completeness. I take that to be equivalent to MAY implement. I think that jumping from MAY implement to MUST NOT implement without a severe security concern is unfair to the implementors. TLS 1.1 contains the following text: Warning: The ability to send Version 2.0 client hello messages will be phased out with all due haste. Implementors SHOULD make every effort to move forward as quickly as possible. Version 3.0 provides better mechanisms for moving to newer versions. I'm suggesting something similar for ciphersuites. List the ones that will become MUST NOT in the future and tell people that is the intent. I think the will-become-MUST-NOT ciphersuites should be MAY implement (the same status as in TLS 1.1) in this version of the document, but I can live with SHOULD NOT implement. Russ At 04:10 PM 12/20/2007, Eric Rescorla wrote: >At Thu, 20 Dec 2007 16:06:06 -0500, >Russ Housley wrote: > > > > The code point for IDEA are already assigned. I understand that some > > implementations support it. I'm most comfortable with MAY support > > IDEA, and I can live with SHOULD NOT support IDEA. If we are going > > to completely deprecate IDEA in TLS, we need to give notice to > > implementors. > >Well, this won't affect TLS < 1.2 at all, right? So given that AES >is MUST implement, why do they need warning? > > > > The SHOULD NOT gives the notice so that it can go away > > (not be mentioned at all) in the next version. > >So, TLS practice has not been not to not mention, but rather to >list the code points with MUST NOT labels. That's what we do with, >for instance, DES40. > >-Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 16:50:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5THI-0005MV-ND; Thu, 20 Dec 2007 16:50:04 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5THG-000519-Kr for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:50:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5THG-0004xq-5q for tls@ietf.org; Thu, 20 Dec 2007 16:50:02 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5THF-0004gv-MR for tls@ietf.org; Thu, 20 Dec 2007 16:50:02 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBKLnxNU061908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 14:50:00 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> Date: Thu, 20 Dec 2007 13:49:42 -0800 To: Russ Housley , Eric Rescorla From: Paul Hoffman Subject: Re: [TLS] Status of IDEA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org 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 At 4:39 PM -0500 12/20/07, Russ Housley wrote: >TLS 1.1 lists the IDEA cipher suites with no real label. The text >says that they are included for completeness. I take that to be >equivalent to MAY implement. That sounds right. >I think that jumping from MAY implement to MUST NOT implement >without a severe security concern is unfair to the implementors. In what way? They lose nothing by removing the ciphersuite from their 1.2 implementation, and they can leave it in their 1.0 and 1.1 implementation at no cost. >TLS 1.1 contains the following text: > > Warning: The ability to send Version 2.0 client hello messages will be > phased out with all due haste. Implementors SHOULD make every > effort to move forward as quickly as possible. Version 3.0 > provides better mechanisms for moving to newer versions. > >I'm suggesting something similar for ciphersuites. List the ones >that will become MUST NOT in the future and tell people that is the >intent. That is a possibility, but it is not clear who benefits from that. Given that TLS 1.2 has mandatory-to-implement suites that we all agree on, what is the benefit of listing ones as MAY that there is less than full confidence in? >I think the will-become-MUST-NOT ciphersuites should be MAY >implement (the same status as in TLS 1.1) in this version of the >document, but I can live with SHOULD NOT implement. See my previous message: SHOULD NOT makes no logical sense for interoperability, which is what we should be concerned with. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 16:58:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TPY-0000of-At; Thu, 20 Dec 2007 16:58:36 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5TPW-0000Vb-Sm for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 16:58:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TPW-0000R7-GM for tls@ietf.org; Thu, 20 Dec 2007 16:58:34 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5TPV-0004tC-3P for tls@ietf.org; Thu, 20 Dec 2007 16:58:34 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id D66BF5081A; Thu, 20 Dec 2007 13:58:09 -0800 (PST) Date: Thu, 20 Dec 2007 13:58:09 -0800 From: Eric Rescorla To: Russ Housley Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220213206.62B865C04A@laser.networkresonance.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> <20071220213206.62B865C04A@laser.networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071220215809.D66BF5081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@ietf.org 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 At Thu, 20 Dec 2007 16:39:42 -0500, Russ Housley wrote: > > Eric: > > TLS 1.1 lists the IDEA cipher suites with no real label. The text > says that they are included for completeness. I take that to be > equivalent to MAY implement. Agreed. > I think that jumping from MAY implement to MUST NOT implement without > a severe security concern is unfair to the implementors. I don't really get that. Again, they can continue to use it for TLS 1.1. I mean, does anyone actually use it? > TLS 1.1 contains the following text: > > Warning: The ability to send Version 2.0 client hello messages will be > phased out with all due haste. Implementors SHOULD make every > effort to move forward as quickly as possible. Version 3.0 > provides better mechanisms for moving to newer versions. > > I'm suggesting something similar for ciphersuites. List the ones > that will become MUST NOT in the future and tell people that is the > intent. I think the will-become-MUST-NOT ciphersuites should be MAY > implement (the same status as in TLS 1.1) in this version of the > document, but I can live with SHOULD NOT implement. So, I think this is a different case in that there really used to be servers which would break if you didn't send the v2 hello and so we really wanted to encourage this transition. I don't think IDEA is really that similar. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 17:05:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TWd-0006Yb-Ek; Thu, 20 Dec 2007 17:05:55 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5TWb-0006GX-H9 for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 17:05:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TWb-0006GP-2I for tls@ietf.org; Thu, 20 Dec 2007 17:05:53 -0500 Received: from py-out-1112.google.com ([64.233.166.176]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5TWa-0004cM-GG for tls@ietf.org; Thu, 20 Dec 2007 17:05:52 -0500 Received: by py-out-1112.google.com with SMTP id d32so290292pye.12 for ; Thu, 20 Dec 2007 14:05:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=s9tNHEsNjzPwmDCQcQiZzujJD8RFpWEYZlyucn1vJ0Y=; b=kE8EhpkCrxVzknqtp49na3BhpX78jdXmXBIN96VNC5aCeZYfJu8+eBkpydQzKRjNxSk9yzBAnQ2ucGxA7cMeahY6rumbKFtcWV2Jdha8C2yReBftsgvSJfvmVkgmpseltuGf4ZBTSJU+sn4CxKG1FzJsrmqXNo8mU9t88x3PGzw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q+qVtvmQpwJuwINsPjwrOWcL53nAwPLzwha+9D5fYdEMaGfuYbbwYzy7Jyg5bHY5cQXKnMS+wXW/LZKp64cFH9hS89xErHQMKbS8XhDeYVUWV6M/cxQDYTSOIjTn1MMWP5A0nICwOGauON+8OQITj4KdSglTjiMBNZ1Qe/vTGz8= Received: by 10.65.124.8 with SMTP id b8mr988490qbn.82.1198188350189; Thu, 20 Dec 2007 14:05:50 -0800 (PST) Received: by 10.64.142.19 with HTTP; Thu, 20 Dec 2007 14:05:50 -0800 (PST) Message-ID: <6b9359640712201405w1c5e1e71xa893a05de350b494@mail.gmail.com> Date: Thu, 20 Dec 2007 14:05:50 -0800 From: "Kyle Hamilton" To: "Eric Rescorla" Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220173400.C6CD25081A@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071220173400.C6CD25081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org 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 My largest issue with the way TLS is done is that it encodes policy as "MUST NOT" statements. The concept of applying a patent policy as a MUST NOT is ridiculous -- there's more than enough room in a conformant implementation to avoid using IDEA if patent constraints exist. I can see a clause stating that "implementations MUST NOT enable non-canonical ciphers by default", but I can't see a clause absolutely forbidding something based on patent constraints. (Why has there not been an extension mechanism defined for research and development work other than "hoping it doesn't conflict in the future"?) -Kyle H On Dec 20, 2007 9:34 AM, Eric Rescorla wrote: > In the current draft of TLS 1.2, IDEA is marked as MUST NOT. Some in > the WG felt that it should be a SHOULD NOT. The minutes read: > > Pasi asked if it was really OK to make IDEA a MUST NOT do at the > current codepoint > Russ Housley didn't like the idea > Paul Hoffman said that listing untested algorithms > causes developers to use them > Stefan Santesson said we should leave a holder in > Straw poll: SHOULD NOT and MUST NOT got roughly equal support > Will take to the list > > Please use this thread for discussion of this topic. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 17:19:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Tjy-0006Xq-VO; Thu, 20 Dec 2007 17:19:42 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Tju-0006Wc-HI for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 17:19:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Tju-0006WM-51 for tls@ietf.org; Thu, 20 Dec 2007 17:19:38 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Tjt-0004xO-Qz for tls@ietf.org; Thu, 20 Dec 2007 17:19:38 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 6DB0B5081A; Thu, 20 Dec 2007 14:19:14 -0800 (PST) Date: Thu, 20 Dec 2007 14:19:14 -0800 From: Eric Rescorla To: "Kyle Hamilton" Subject: Re: [TLS] Status of IDEA In-Reply-To: <6b9359640712201405w1c5e1e71xa893a05de350b494@mail.gmail.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <6b9359640712201405w1c5e1e71xa893a05de350b494@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071220221914.6DB0B5081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org 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 At Thu, 20 Dec 2007 14:05:50 -0800, Kyle Hamilton wrote: > > My largest issue with the way TLS is done is that it encodes policy as > "MUST NOT" statements. The concept of applying a patent policy as a > MUST NOT is ridiculous -- there's more than enough room in a > conformant implementation to avoid using IDEA if patent constraints > exist. This doesn't have anything to do with patents. It's purely an issue of security and the fact that we don't really understand the security of IDEA (yes, that's partly because it's unused due to patent constraints) and that we now have algorithms that we're much more comfortable with. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 17:23:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TnK-00033q-6X; Thu, 20 Dec 2007 17:23:10 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5TnJ-000303-24 for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 17:23:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TnI-0002ys-N2 for tls@ietf.org; Thu, 20 Dec 2007 17:23:08 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J5TnI-00052N-DV for tls@ietf.org; Thu, 20 Dec 2007 17:23:08 -0500 Received: (qmail 10089 invoked by uid 0); 20 Dec 2007 22:23:01 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 20 Dec 2007 22:23:01 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 20 Dec 2007 17:23:06 -0500 To: ekr@networkresonance.com,phoffman@vpnc.org From: Russ Housley Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220215809.D66BF5081A@romeo.rtfm.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> <20071220213206.62B865C04A@laser.networkresonance.com> <20071220215809.D66BF5081A@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Message-Id: Cc: tls@ietf.org 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 Eric & Paul: I guess I see the fundamental difference in our thinking. Do we want the ciphersuite processing to be specific to a TLS version? If you want IDEA, then negotiate TLS 1.1. By this line of thought, negotiate TLS 1.0 to use DES40. My feeling is that when we deprecate an algorithm, we do not want it to be used in any of the versions that are supported by the implementation. This is the reason that I advocate a polite egress... Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 17:31: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 1J5TvK-0004sI-LD; Thu, 20 Dec 2007 17:31:26 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5TvJ-0004ho-Ql for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 17:31:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5TvJ-0004eo-8K for tls@ietf.org; Thu, 20 Dec 2007 17:31:25 -0500 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5TvI-0005Z4-Rn for tls@ietf.org; Thu, 20 Dec 2007 17:31:25 -0500 Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lBKMVMIi065552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Dec 2007 15:31:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200712202223.lBKMN8uq064732@balder-227.proper.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> <20071220213206.62B865C04A@laser.networkresonance.com> <20071220215809.D66BF5081A@romeo.rtfm.com> <200712202223.lBKMN8uq064732@balder-227.proper.com> Date: Thu, 20 Dec 2007 14:31:20 -0800 To: Russ Housley , ekr@networkresonance.com, phoffman@vpnc.org From: Paul Hoffman Subject: Re: [TLS] Status of IDEA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org 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 At 5:23 PM -0500 12/20/07, Russ Housley wrote: >I guess I see the fundamental difference in our thinking. Do we >want the ciphersuite processing to be specific to a TLS version? If >you want IDEA, then negotiate TLS 1.1. By this line of thought, >negotiate TLS 1.0 to use DES40. My feeling is that when we >deprecate an algorithm, we do not want it to be used in any of the >versions that are supported by the implementation. This is the >reason that I advocate a polite egress... This is fundamentally different from the way that TLS has been updated in the past. If the WG wants to adopt the "this set of ciphersuites is for all versions of TLS" approach, it does indeed make sense to have phased approach such as "MAY in this version, but we intend to make this MUST NOT in the future". However, that "algorithms for all versions" approach is not what the TLS WG is discussing at the moment. We are discussing the algorithm requirements that apply to TLS 1.2 only. The proposal to do algorithms for all versions is a new one. --Paul Hoffman, Director --VPN Consortium _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 17:33:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Twt-0007KM-HW; Thu, 20 Dec 2007 17:33:03 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Twr-00070u-6p for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 17:33:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Twq-0006sv-NO for tls@ietf.org; Thu, 20 Dec 2007 17:33:00 -0500 Received: from colo.trepanning.net ([69.55.226.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Twq-0005GX-Az for tls@ietf.org; Thu, 20 Dec 2007 17:33:00 -0500 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A0A3B1FA61DE; Thu, 20 Dec 2007 14:32:59 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 20 Dec 2007 14:32:59 -0800 (PST) Message-ID: <21500.216.31.249.246.1198189979.squirrel@www.trepanning.net> In-Reply-To: References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> <20071220213206.62B865C04A@laser.networkresonance.com> <20071220215809.D66BF5081A@romeo.rtfm.com> Date: Thu, 20 Dec 2007 14:32:59 -0800 (PST) Subject: Re: [TLS] Status of IDEA From: "Dan Harkins" To: "Russ Housley" User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tls@ietf.org, phoffman@vpnc.org 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 Russ, It's kind of hard for version X of a protocol to mandate behavior in shipping product that support version less-than-X of the same protocol. I think we're stuck with ciphersuite processing being specific to version. Your approach seems "nicer" but impractical. Give a guy writing code the opportunity to parse "SHOULD NOT" and he's gonna think, well I have 10 other things I have to do this week so instead of removing IDEA from my TLS 1.2 implementation I'll just commit it and get on to the other things on my plate. Polite egress will be politely ignored and eventually we'll run into the same situation of a hard and fast stop on use of a ciphersuite. That being the case why not just get it over with now-- you MUST NOT use IDEA with TLS 1.2. Dan. On Thu, December 20, 2007 2:23 pm, Russ Housley wrote: > Eric & Paul: > > I guess I see the fundamental difference in our thinking. Do we want > the ciphersuite processing to be specific to a TLS version? If you > want IDEA, then negotiate TLS 1.1. By this line of thought, > negotiate TLS 1.0 to use DES40. My feeling is that when we deprecate > an algorithm, we do not want it to be used in any of the versions > that are supported by the implementation. This is the reason that I > advocate a polite egress... > > Russ > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 17:33:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Tww-0007jw-Qa; Thu, 20 Dec 2007 17:33:06 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Twv-0007Xr-72 for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 17:33:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Twu-0007Sb-Jk for tls@ietf.org; Thu, 20 Dec 2007 17:33:04 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5Twt-0005bR-Rt for tls@ietf.org; Thu, 20 Dec 2007 17:33:04 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 9A52E5081A; Thu, 20 Dec 2007 14:32:40 -0800 (PST) Date: Thu, 20 Dec 2007 14:32:40 -0800 From: Eric Rescorla To: Russ Housley Subject: Re: [TLS] Status of IDEA In-Reply-To: <20071220221529.675F95C027@laser.networkresonance.com> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> <20071220213206.62B865C04A@laser.networkresonance.com> <20071220215809.D66BF5081A@romeo.rtfm.com> <20071220221529.675F95C027@laser.networkresonance.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071220223240.9A52E5081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org, phoffman@vpnc.org 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 At Thu, 20 Dec 2007 17:23:06 -0500, Russ Housley wrote: > I guess I see the fundamental difference in our thinking. Do we want > the ciphersuite processing to be specific to a TLS version? If you > want IDEA, then negotiate TLS 1.1. By this line of thought, > negotiate TLS 1.0 to use DES40. My feeling is that when we deprecate > an algorithm, we do not want it to be used in any of the versions > that are supported by the implementation. This is the reason that I > advocate a polite egress... I think we've already crossed this bridge. Here's RFC 4346: When SSLv3 and TLS 1.0 were designed, the United States restricted the export of cryptographic software containing certain strong encryption algorithms. A series of cipher suites were designed to operate at reduced key lengths in order to comply with those regulations. Due to advances in computer performance, these algorithms are now unacceptably weak, and export restrictions have since been loosened. TLS 1.1 implementations MUST NOT negotiate these cipher suites in TLS 1.1 mode. However, for backward compatibility they may be offered in the ClientHello for use with TLS 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the server did not choose one of these cipher suites during the handshake. These ciphersuites are listed below for informational purposes and to reserve the numbers. Not saying that's right, but there it is... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 20:45:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Wwp-0008W5-0j; Thu, 20 Dec 2007 20:45:11 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Wwo-0008W0-6N for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 20:45:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Wwn-0008Vs-FU for tls@ietf.org; Thu, 20 Dec 2007 20:45:09 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Wwn-0001pG-1i for tls@ietf.org; Thu, 20 Dec 2007 20:45:09 -0500 X-IronPort-AV: E=Sophos;i="4.24,191,1196668800"; d="scan'208";a="13679800" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 20 Dec 2007 17:45:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lBL1j8iE026498; Thu, 20 Dec 2007 17:45:08 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lBL1j4i2028695; Fri, 21 Dec 2007 01:45:04 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Dec 2007 17:45:03 -0800 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 Subject: RE: [TLS] Status of IDEA Date: Thu, 20 Dec 2007 17:45:31 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Status of IDEA Thread-Index: AchDWBcQCSAOM3rSRO+gqmXGF7LE3QAGqjEg From: "Joseph Salowey (jsalowey)" To: "Paul Hoffman" , "Russ Housley" , , X-OriginalArrivalTime: 21 Dec 2007 01:45:03.0921 (UTC) FILETIME=[1B598210:01C84373] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1831; t=1198201508; x=1199065508; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[TLS]=20Status=20of=20IDEA |Sender:=20; bh=XUlsC07GLwHHrXgfYPBpUFxDfPvOI435D8Pk0Z6x+GY=; b=QO0amuC9W5aUUZhuoaH7gyeYeHWGrmP+S7kR0uZRcbYbXmpxgIHrdEujeH kgRPKi8NI+J82E5dSUyOryLuj0q2He6P7YI+Hz/hpuawIPeTN6So7gpmBelr g6YUK0gn1D; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls@ietf.org 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 Can we just drop mention of ciphersites that no one uses? =20 They would still be in the IANA registry. Isn't this what is usually done, removing unused features, as a standard progresses. =20 > -----Original Message----- > From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]=20 > Sent: Thursday, December 20, 2007 2:31 PM > To: Russ Housley; ekr@networkresonance.com; phoffman@vpnc.org > Cc: tls@ietf.org > Subject: Re: [TLS] Status of IDEA >=20 > At 5:23 PM -0500 12/20/07, Russ Housley wrote: > >I guess I see the fundamental difference in our thinking. =20 > Do we want=20 > >the ciphersuite processing to be specific to a TLS version? If you=20 > >want IDEA, then negotiate TLS 1.1. By this line of thought,=20 > negotiate=20 > >TLS 1.0 to use DES40. My feeling is that when we deprecate an=20 > >algorithm, we do not want it to be used in any of the=20 > versions that are=20 > >supported by the implementation. This is the reason that I=20 > advocate a=20 > >polite egress... >=20 > This is fundamentally different from the way that TLS has=20 > been updated in the past. If the WG wants to adopt the "this=20 > set of ciphersuites is for all versions of TLS" approach, it=20 > does indeed make sense to have phased approach such as "MAY=20 > in this version, but we intend to make this MUST NOT in the future". >=20 > However, that "algorithms for all versions" approach is not=20 > what the TLS WG is discussing at the moment. We are=20 > discussing the algorithm requirements that apply to TLS 1.2=20 > only. The proposal to do algorithms for all versions is a new one. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 21:51:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Xyt-0003Ah-Ma; Thu, 20 Dec 2007 21:51:23 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5Xys-0003Ac-M1 for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 21:51:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5Xys-00032n-08 for tls@ietf.org; Thu, 20 Dec 2007 21:51:22 -0500 Received: from moe.its.auckland.ac.nz ([130.216.12.35] helo=mailhost.auckland.ac.nz) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5Xyl-0002xO-PA for tls@ietf.org; Thu, 20 Dec 2007 21:51:16 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E00214806F2; Fri, 21 Dec 2007 15:51:09 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9EJ8rfEd-Ez; Fri, 21 Dec 2007 15:51:09 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 400934806DD; Fri, 21 Dec 2007 15:51:09 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7ECF019EC0B6; Fri, 21 Dec 2007 15:51:03 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1J5XyZ-0003hc-CH; Fri, 21 Dec 2007 15:51:03 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ekr@networkresonance.com, housley@vigilsec.com Subject: Re: [TLS] Status of IDEA In-Reply-To: Message-Id: Date: Fri, 21 Dec 2007 15:51:03 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org 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 Russ Housley writes: >TLS 1.1 contains the following text: > > Warning: The ability to send Version 2.0 client hello messages will be > phased out with all due haste. Implementors SHOULD make every > effort to move forward as quickly as possible. Version 3.0 > provides better mechanisms for moving to newer versions. > >I'm suggesting something similar for ciphersuites. Given that that text has been present in the spec for more than *ten years* (!!), perhaps the cipher equivalent should give an end-of-life date otherwise we'll still be having this debate in 2017. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 22:25:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YVR-0000xZ-BL; Thu, 20 Dec 2007 22:25:01 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5YVQ-0000xT-3G for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 22:25:00 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5YVP-0000xL-Ow for tls@ietf.org; Thu, 20 Dec 2007 22:24:59 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5YVP-0003WN-El for tls@ietf.org; Thu, 20 Dec 2007 22:24:59 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 1D04B5083A; Thu, 20 Dec 2007 19:24:36 -0800 (PST) Date: Thu, 20 Dec 2007 19:24:35 -0800 From: Eric Rescorla To: "Joseph Salowey (jsalowey)" Subject: Re: [TLS] Status of IDEA In-Reply-To: References: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071221032436.1D04B5083A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tls@ietf.org, phoffman@vpnc.org, Paul Hoffman 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 At Thu, 20 Dec 2007 17:45:31 -0800, Joseph Salowey (jsalowey) wrote: > > Can we just drop mention of ciphersites that no one uses? > > They would still be in the IANA registry. Isn't this what is usually > done, removing unused features, as a standard progresses. The TLS practice has been to list them in the document to reserve the code point but forbid their use. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 23:18:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ZLN-0007g4-Lk; Thu, 20 Dec 2007 23:18:41 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5ZLN-0007fw-3j for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 23:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ZLM-0007fo-Q3 for tls@ietf.org; Thu, 20 Dec 2007 23:18:40 -0500 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5ZLL-0003lK-5p for tls@ietf.org; Thu, 20 Dec 2007 23:18:40 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mHQcGg502AacueQ4abFHldd40paXQ3wdVP+hUM9ExmFRGxzYS2g/BG/721UJ4Gaw; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.226.18.197] (helo=ix.netcom.com) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J5ZLG-0004Um-T2; Thu, 20 Dec 2007 23:18:35 -0500 Message-ID: <476B5AAE.6CB700F1@ix.netcom.com> Date: Thu, 20 Dec 2007 22:18:23 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Eric Rescorla Subject: Re: [TLS] Status of IDEA References: <20071220173400.C6CD25081A@romeo.rtfm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606884dcf3f2cb7f5312a9b62944bb30ccf0e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.226.18.197 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tls@ietf.org 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 Eric and all, For the record, I much prefer normally MUST NOT to SHOULD NOT. Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 Eric Rescorla wrote: > In the current draft of TLS 1.2, IDEA is marked as MUST NOT. Some in > the WG felt that it should be a SHOULD NOT. The minutes read: > > Pasi asked if it was really OK to make IDEA a MUST NOT do at the > current codepoint > Russ Housley didn't like the idea > Paul Hoffman said that listing untested algorithms > causes developers to use them > Stefan Santesson said we should leave a holder in > Straw poll: SHOULD NOT and MUST NOT got roughly equal support > Will take to the list > > Please use this thread for discussion of this topic. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Dec 20 23:20: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 1J5ZMs-0000a8-W7; Thu, 20 Dec 2007 23:20:14 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5ZMr-0000a3-V2 for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 23:20:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5ZMr-0000Zt-KY for tls@ietf.org; Thu, 20 Dec 2007 23:20:13 -0500 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5ZMq-0003mr-4S for tls@ietf.org; Thu, 20 Dec 2007 23:20:13 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ai2LV0OetH01dAFirjASsGf/oxWla7F3l9TKwxRxUcrstAk5YgZCgF8T6YjMqbV5; h=Received:Message-ID:Date:From:Organization:X-Mailer:X-Accept-Language:MIME-Version:To:CC:Subject:References:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [4.226.18.197] (helo=ix.netcom.com) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1J5ZMk-00011A-Sl; Thu, 20 Dec 2007 23:20:07 -0500 Message-ID: <476B5B0C.A258497B@ix.netcom.com> Date: Thu, 20 Dec 2007 22:19:56 -0800 From: "Jeffrey A. Williams" Organization: IDNS X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [TLS] Status of IDEA References: <20071220173400.C6CD25081A@romeo.rtfm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688136d624355781290e26c6f2b9d1623df350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.226.18.197 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@ietf.org 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 Paul and all, Very much agreed and well argued, Paul. Regards, Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827 Paul Hoffman wrote: > The experience in the IPsec WG for algorithms that are listed but not > mandated in the base spec was that many developers did a first pass > at implementing them, but rarely tested their implementations. This > could easily lead to serious security issues that would go unnoticed. > > I do not understand what "SHOULD NOT" for IDEA would mean. "Don't do > it unless you really want to"? "Don't do it unless the other side > only can do IDEA and not any of the mandatory-to-implement ciphers > which it did not implement"? Having IDEA and DES and RC2 MUST NOT > makes it completely clear to implementers what they are allowed to do. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 03:10:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5cxY-0002Ki-0m; Fri, 21 Dec 2007 03:10:20 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5X1x-0000x5-Tv for tls-confirm+ok@megatron.ietf.org; Thu, 20 Dec 2007 20:50:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5X1x-0000ww-D4 for tls@lists.ietf.org; Thu, 20 Dec 2007 20:50:29 -0500 Received: from omta05ps.mx.bigpond.com ([144.140.83.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5X1v-0001h0-Ex for tls@lists.ietf.org; Thu, 20 Dec 2007 20:50:29 -0500 Received: from oaamta08ps.mx.bigpond.com ([61.9.204.42]) by omta05ps.mx.bigpond.com with ESMTP id <20071221015025.IQKG5761.omta05ps.mx.bigpond.com@oaamta08ps.mx.bigpond.com> for ; Fri, 21 Dec 2007 01:50:25 +0000 Received: from conferta.cuneata.net ([61.9.204.42]) by oaamta08ps.mx.bigpond.com with ESMTP id <20071221015020.ISUP19013.oaamta08ps.mx.bigpond.com@conferta.cuneata.net> for ; Fri, 21 Dec 2007 01:50:20 +0000 Received: by conferta.cuneata.net (Postfix, from userid 502) id ADF5279E043C; Fri, 21 Dec 2007 12:50:04 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on conferta.cuneata.net X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.2.3 Received: from conferta.cuneata.net (conferta.cuneata.net [192.168.11.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bradh) by conferta.cuneata.net (Postfix) with ESMTP id 20E2079E0437 for ; Fri, 21 Dec 2007 12:50:04 +1100 (EST) From: Brad Hards To: tls@lists.ietf.org Subject: Re: [TLS] Status of IDEA Date: Fri, 21 Dec 2007 12:50:03 +1100 User-Agent: KMail/1.9.6 (enterprise 0.20071123.740460) References: <20071220173400.C6CD25081A@romeo.rtfm.com> <6b9359640712201405w1c5e1e71xa893a05de350b494@mail.gmail.com> <20071220221914.6DB0B5081A@romeo.rtfm.com> In-Reply-To: <20071220221914.6DB0B5081A@romeo.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200712211250.03315.bradh@frogmouth.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 X-Mailman-Approved-At: Fri, 21 Dec 2007 03:10:19 -0500 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 On Friday 21 December 2007 09:19:14 am Eric Rescorla wrote: > This doesn't have anything to do with patents. It's purely an issue > of security and the fact that we don't really understand the security > of IDEA (yes, that's partly because it's unused due to patent > constraints) and that we now have algorithms that we're much > more comfortable with. That vaguely sounds like "should not" (as opposed to "SHOULD NOT") to me - not advised, but nothing actually known to be wrong with it. If we actually knew of a problem, then IDEA would be "MUST NOT". Brad _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 05:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fB4-0007Zo-BU; Fri, 21 Dec 2007 05:32:26 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5fB2-0007Zj-JN for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 05:32:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fB2-0007Za-8z for tls@ietf.org; Fri, 21 Dec 2007 05:32:24 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5fB1-0005Jx-Nl for tls@ietf.org; Fri, 21 Dec 2007 05:32:24 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBLAW9Id029771 for ; Fri, 21 Dec 2007 12:32:19 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 12:32:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 12:32:11 +0200 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 Subject: RE: [TLS] Status of IDEA Date: Fri, 21 Dec 2007 12:32:10 +0200 Message-ID: In-Reply-To: <20071221032436.1D04B5083A@romeo.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Status of IDEA Thread-Index: AchDgRj3MCVIMDw5RgSi9d6QzICKJgAOxsWQ References: <20071221032436.1D04B5083A@romeo.rtfm.com> From: To: X-OriginalArrivalTime: 21 Dec 2007 10:32:11.0722 (UTC) FILETIME=[BEFCF2A0:01C843BC] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: 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 Eric Rescorla wrote: > Joseph Salowey (jsalowey) wrote: > >=20 > > Can we just drop mention of ciphersites that no one uses? =20 > >=20 > > They would still be in the IANA registry. Isn't this what=20 > > is usually done, removing unused features, as a standard=20 > > progresses. =20 >=20 > The TLS practice has been to list them in the document to reserve > the code point but forbid their use. I think Joe's suggestion makes sense: just remove the IDEA ciphersuites from this document. (This way, the base spec contains only things we consider a good idea to implement.) We don't need to forbid their use, and there's no need to=20 mark the code points reserved in *this* document (the IANA registry is anyway the official source on what code points=20 have been allocated). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 05:37:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fFu-0002HU-5n; Fri, 21 Dec 2007 05:37:26 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5fFt-0002HH-CW for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 05:37:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5fFt-0002H9-2p for tls@ietf.org; Fri, 21 Dec 2007 05:37:25 -0500 Received: from smtp.nokia.com ([192.100.122.230] helo=mgw-mx03.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5fFs-0003t4-FW for tls@ietf.org; Fri, 21 Dec 2007 05:37:25 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id lBLAb9P5003940 for ; Fri, 21 Dec 2007 12:37:22 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 12:37:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Dec 2007 12:37:22 +0200 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 Subject: RE: [TLS] Status of IDEA Date: Fri, 21 Dec 2007 12:37:21 +0200 Message-ID: In-Reply-To: <20071220223240.9A52E5081A@romeo.rtfm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Status of IDEA Thread-Index: AchDWE20H+duBsV7RF+dCJ9M7Eg6ZQAZLJkQ References: <20071220173400.C6CD25081A@romeo.rtfm.com><20071220205835.480815C027@laser.networkresonance.com><20071220211053.E15885081A@romeo.rtfm.com><20071220213206.62B865C04A@laser.networkresonance.com><20071220215809.D66BF5081A@romeo.rtfm.com><20071220221529.675F95C027@laser.networkresonance.com> <20071220223240.9A52E5081A@romeo.rtfm.com> From: To: X-OriginalArrivalTime: 21 Dec 2007 10:37:22.0425 (UTC) FILETIME=[782E7690:01C843BD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 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 ciphersuites deprecated in RFC4346 are slightly different case, because they required special key processing in the TLS handshake protocol (key calculation for those "export" ciphersuites worked slightly differently). And that special key calculation procedure was removed in TLS 1.1. IDEA and single-DES don't require anything special here, so they can be version-agnostic. Best regards, Pasi > -----Original Message----- > From: ext Eric Rescorla [mailto:ekr@networkresonance.com]=20 > Sent: 21 December, 2007 00:33 > To: Russ Housley > Cc: tls@ietf.org; phoffman@vpnc.org > Subject: Re: [TLS] Status of IDEA >=20 > At Thu, 20 Dec 2007 17:23:06 -0500, > Russ Housley wrote: > > I guess I see the fundamental difference in our thinking. =20 > > Do we want=20 > > the ciphersuite processing to be specific to a TLS version? If you=20 > > want IDEA, then negotiate TLS 1.1. By this line of thought,=20 > > negotiate TLS 1.0 to use DES40. My feeling is that when we=20 > > deprecate=20 > > an algorithm, we do not want it to be used in any of the versions=20 > > that are supported by the implementation. This is the=20 > > reason that I=20 > > advocate a polite egress... >=20 > I think we've already crossed this bridge. Here's RFC 4346: >=20 > When SSLv3 and TLS 1.0 were designed, the United States restricted > the export of cryptographic software containing certain strong > encryption algorithms. A series of cipher suites were designed to > operate at reduced key lengths in order to comply with those > regulations. Due to advances in computer performance, these > algorithms are now unacceptably weak, and export restrictions have > since been loosened. TLS 1.1 implementations MUST NOT negotiate > these cipher suites in TLS 1.1 mode. However, for backward > compatibility they may be offered in the ClientHello for=20 > use with TLS > 1.0 or SSLv3-only servers. TLS 1.1 clients MUST check that the > server did not choose one of these cipher suites during the > handshake. These ciphersuites are listed below for informational > purposes and to reserve the numbers. >=20 > Not saying that's right, but there it is... >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 06:40:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5gF7-0007uy-8H; Fri, 21 Dec 2007 06:40:41 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5gF6-0007pA-4U for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 06:40:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5gF5-0007fU-No for tls@ietf.org; Fri, 21 Dec 2007 06:40:39 -0500 Received: from yxa.extundo.com ([83.241.177.38]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J5gF1-0007QG-3M for tls@ietf.org; Fri, 21 Dec 2007 06:40:35 -0500 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id lBLBeHkr028172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Dec 2007 12:40:18 +0100 From: Simon Josefsson To: References: <20071221032436.1D04B5083A@romeo.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:071221:tls@ietf.org::uZ3Sl/3zTiCVb4Dg:C6TG X-Hashcash: 1:22:071221:pasi.eronen@nokia.com::VmyfztQDtxi3M5lz:nuew Date: Fri, 21 Dec 2007 12:40:17 +0100 In-Reply-To: (Pasi Eronen's message of "Fri, 21 Dec 2007 12:32:10 +0200") Message-ID: <87mys46ztq.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-0.0 required=4.0 tests=SPF_PASS autolearn=disabled version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) 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.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org Subject: [TLS] Re: Status of IDEA 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 writes: > Eric Rescorla wrote: > >> Joseph Salowey (jsalowey) wrote: >> > >> > Can we just drop mention of ciphersites that no one uses? >> > >> > They would still be in the IANA registry. Isn't this what >> > is usually done, removing unused features, as a standard >> > progresses. >> >> The TLS practice has been to list them in the document to reserve >> the code point but forbid their use. > > I think Joe's suggestion makes sense: just remove the IDEA > ciphersuites from this document. (This way, the base spec > contains only things we consider a good idea to implement.) And the DES ciphersuites? I would support removing IDEA from the document, or marking it as MUST NOT, or whatever it takes to make people not consider implementing it. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 07:15:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5gmY-0006DN-JU; Fri, 21 Dec 2007 07:15:14 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5gmX-0006D5-F5 for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 07:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5gmX-0006Cv-5H for tls@ietf.org; Fri, 21 Dec 2007 07:15:13 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5gmV-0006Dt-Fr for tls@ietf.org; Fri, 21 Dec 2007 07:15:13 -0500 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.13.8/8.13.8) with ESMTP id lBLDCL55491772 for ; Fri, 21 Dec 2007 13:12:21 GMT Message-ID: <476BAE30.2090807@isima.fr> Date: Fri, 21 Dec 2007 13:14:40 +0100 From: Mohamad Badra User-Agent: Thunderbird 1.5.0.14 (Windows/20071210) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: Status of IDEA References: <20071221032436.1D04B5083A@romeo.rtfm.com> <87mys46ztq.fsf@mocca.josefsson.org> In-Reply-To: <87mys46ztq.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Fri, 21 Dec 2007 13:12:21 +0000 (WET) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id lBLDCL55491772 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 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 Simon Josefsson a =E9crit : > writes: >=20 >> Eric Rescorla wrote: >> >>> Joseph Salowey (jsalowey) wrote: >>>> Can we just drop mention of ciphersites that no one uses? =20 >>>> >>>> They would still be in the IANA registry. Isn't this what=20 >>>> is usually done, removing unused features, as a standard=20 >>>> progresses. =20 >>> The TLS practice has been to list them in the document to reserve >>> the code point but forbid their use. >> I think Joe's suggestion makes sense: just remove the IDEA >> ciphersuites from this document. (This way, the base spec >> contains only things we consider a good idea to implement.) >=20 > And the DES ciphersuites? >=20 > I would support removing IDEA from the document, or marking it as MUST > NOT, or whatever it takes to make people not consider implementing it. >=20 > /Simon Why don't we allocate values with first byte decimal 192 (0xC0) and then=20 add an "informational section on IDEA ciphersuites" to the document? Best regards, --=20 Mohamad Badra CNRS - LIMOS Laboratory _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 12:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSm-0000Hu-4U; Fri, 21 Dec 2007 12:15:08 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5lSh-0000EX-Bf for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 12:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSh-0000EP-1N; Fri, 21 Dec 2007 12:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5lSg-0003uu-Lb; Fri, 21 Dec 2007 12:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6C5DF2AB69; Fri, 21 Dec 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J5lSg-0005gm-BF; Fri, 21 Dec 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Dec 2007 12:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-new-mac-02.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-02.txt Pages : 8 Date : 2007-12-21 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-02.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-02.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-02.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-12-21110727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-new-mac-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-new-mac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-21110727.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 Fri Dec 21 12:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSn-0000I9-Vt; Fri, 21 Dec 2007 12:15:10 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5lSj-0000GN-Jq for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 12:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSj-0000GF-AA; Fri, 21 Dec 2007 12:15:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5lSg-0003uw-Vg; Fri, 21 Dec 2007 12:15:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7A9D13289E; Fri, 21 Dec 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J5lSg-0005gp-Bu; Fri, 21 Dec 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Dec 2007 12:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-extractor-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 : Keying Material Extractors for Transport Layer Security (TLS) Author(s) : E. Rescorla Filename : draft-ietf-tls-extractor-00.txt Pages : 6 Date : 2007-12-21 A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-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-extractor-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-extractor-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-12-21110853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-extractor-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-extractor-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-21110853.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 Fri Dec 21 12:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSm-0000Hu-4U; Fri, 21 Dec 2007 12:15:08 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5lSh-0000EX-Bf for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 12:15:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSh-0000EP-1N; Fri, 21 Dec 2007 12:15:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5lSg-0003uu-Lb; Fri, 21 Dec 2007 12:15:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6C5DF2AB69; Fri, 21 Dec 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J5lSg-0005gm-BF; Fri, 21 Dec 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Dec 2007 12:15:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-ecc-new-mac-02.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-02.txt Pages : 8 Date : 2007-12-21 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-02.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-02.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-02.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-12-21110727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-ecc-new-mac-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-ecc-new-mac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-21110727.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 Fri Dec 21 12:15:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSn-0000I9-Vt; Fri, 21 Dec 2007 12:15:10 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5lSj-0000GN-Jq for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 12:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5lSj-0000GF-AA; Fri, 21 Dec 2007 12:15:05 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5lSg-0003uw-Vg; Fri, 21 Dec 2007 12:15:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 7A9D13289E; Fri, 21 Dec 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1J5lSg-0005gp-Bu; Fri, 21 Dec 2007 12:15:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Dec 2007 12:15:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-extractor-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 : Keying Material Extractors for Transport Layer Security (TLS) Author(s) : E. Rescorla Filename : draft-ietf-tls-extractor-00.txt Pages : 6 Date : 2007-12-21 A number of protocols wish to leverage Transport Layer Security (TLS) to perform key establishment but then use some of the keying material for their own purposes. This document describes a general mechanism for allowing that. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-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-extractor-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-extractor-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-12-21110853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-extractor-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-extractor-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-12-21110853.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 Fri Dec 21 13:28: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 1J5mbY-0006s0-Fp; Fri, 21 Dec 2007 13:28:16 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5mbW-0006qg-VJ for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 13:28:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5mbW-0006qX-L1 for tls@ietf.org; Fri, 21 Dec 2007 13:28:14 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5mbU-0005qS-Qq for tls@ietf.org; Fri, 21 Dec 2007 13:28:14 -0500 Received: from fe-amer-10.sun.com ([192.18.109.80]) by brmea-mail-3.sun.com (8.13.6+Sun/8.12.9) with ESMTP id lBLISCbm025305 for ; Fri, 21 Dec 2007 18:28:12 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JTE00201UD9YH00@mail-amer.sun.com> (original mail from Chris.Newman@Sun.COM) for tls@ietf.org; Fri, 21 Dec 2007 11:28:12 -0700 (MST) Received: from [10.0.1.4] ([10.1.110.5]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JTE00J7SWMDFH90@mail-amer.sun.com>; Fri, 21 Dec 2007 11:27:55 -0700 (MST) Date: Fri, 21 Dec 2007 10:27:59 -0800 From: Chris Newman Subject: Re: [TLS] Status of IDEA In-reply-to: <20071220211053.E15885081A@romeo.rtfm.com> To: Eric Rescorla , Russ Housley Message-id: MIME-version: 1.0 X-Mailer: Mulberry/4.0.8 (Mac OS X) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline References: <20071220173400.C6CD25081A@romeo.rtfm.com> <20071220205835.480815C027@laser.networkresonance.com> <20071220211053.E15885081A@romeo.rtfm.com> X-Spam-Score: -1.0 (-) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@ietf.org 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 I support "MUST NOT enable IDEA for TLS 1.2." Real world security requires a lot more than just a theoretically secure protocol, it requires a simple implementation with minimal code complexity and well tested code paths. It requires a configuration mere mortals can understand and it does the right thing even if those mere mortals have no understanding what a cipher suite is or the security properties of IDEA. One thing people get is version numbers. They will assume TLS 1.1 is more secure than TLS 1.0. They will assume TLS 1.2 is more secure than TLS 1.1. The more we make that true, the more secure real-world systems will be. Options make security systems less secure in practice, and rarely used options can make security systems much less secure in practice. IDEA is clearly a rarely used option. If negotiating TLS 1.2 means IDEA is never used, then TLS 1.2 is more secure (at least by the "lines of code where vulnerabilities can lurk" measure) than TLS 1.1. I support maximizing both the theoretical and real-world security of software that chooses to be TLS 1.2 compliant. - Chris Eric Rescorla wrote on 12/20/07 13:10 -0800: > At Thu, 20 Dec 2007 16:06:06 -0500, > Russ Housley wrote: >> >> The code point for IDEA are already assigned. I understand that some >> implementations support it. I'm most comfortable with MAY support >> IDEA, and I can live with SHOULD NOT support IDEA. If we are going >> to completely deprecate IDEA in TLS, we need to give notice to >> implementors. > > Well, this won't affect TLS < 1.2 at all, right? So given that AES > is MUST implement, why do they need warning? > > >> The SHOULD NOT gives the notice so that it can go away >> (not be mentioned at all) in the next version. > > So, TLS practice has not been not to not mention, but rather to > list the code points with MUST NOT labels. That's what we do with, > for instance, DES40. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 21 13:47:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5muc-0003im-OR; Fri, 21 Dec 2007 13:47:58 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J5mub-0003iV-3M for tls-confirm+ok@megatron.ietf.org; Fri, 21 Dec 2007 13:47:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J5mua-0003iN-Pk for tls@ietf.org; Fri, 21 Dec 2007 13:47:56 -0500 Received: from colo.trepanning.net ([69.55.226.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J5mua-0006Lo-Bj for tls@ietf.org; Fri, 21 Dec 2007 13:47:56 -0500 Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id CA6E21FA61E3 for ; Fri, 21 Dec 2007 10:47:55 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 21 Dec 2007 10:47:55 -0800 (PST) Message-ID: <2247.69.12.173.8.1198262875.squirrel@www.trepanning.net> Date: Fri, 21 Dec 2007 10:47:55 -0800 (PST) From: "Dan Harkins" To: tls@ietf.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 (Normal) Importance: Normal Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [TLS] SIV Ciphersuites for TLS 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 Greetings, I presented the document RSA AES-SIV Ciphersuites for TLS at the last meeting in Vancouver. It is my hope that this document would be accepted as a WG document and solicit more review and comments from everyone here. The document can be found at: http://www.ietf.org/internet-drafts/draft-harkins-tls-rsa-aes-siv-00.txt Since this email is arriving in the midst of a discussion to drop suppo= rt for another cipher-suite I would like to explain why this one should be added: SIV is an AEAD mode that is resistant to nonce misuse (unlike othe= r counter-mode constructs like GCM) and is therefore well-suited for cases where an application writer, who may not understand the cryptographic nuances of nonce management for other cipher-suites, obtains TLS services for his application by linking to an external library. Please take a look and send comments. regards, Dan. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Dec 23 11:03:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6TI2-00032m-9x; Sun, 23 Dec 2007 11:02:58 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J6TI1-00032Z-5b for tls-confirm+ok@megatron.ietf.org; Sun, 23 Dec 2007 11:02:57 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J6TI0-00032P-SQ for tls@lists.ietf.org; Sun, 23 Dec 2007 11:02:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6TBz-0004ux-VL for tls@lists.ietf.org; Sun, 23 Dec 2007 10:56:43 -0500 Received: from gate.boinx.com ([88.217.192.98] helo=mail.boinx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6TBy-0007IV-2V for tls@lists.ietf.org; Sun, 23 Dec 2007 10:56:43 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.boinx.com (Postfix) with ESMTP id 36B2A1405F62; Sun, 23 Dec 2007 16:56:41 +0100 (CET) X-Virus-Scanned: amavisd-new at boinx.com Received: from mail.boinx.com ([127.0.0.1]) by localhost (gate.i.boinx.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M51m3rehJjTc; Sun, 23 Dec 2007 16:56:38 +0100 (CET) Received: from [192.168.2.2] (cpc2-clif1-0-0-cust535.nott.cable.ntl.com [86.10.70.24]) by mail.boinx.com (Postfix) with ESMTP id 6A1781405F51; Sun, 23 Dec 2007 16:56:37 +0100 (CET) Message-Id: From: Nicholas Shanks To: tls@lists.ietf.org, security@cryptguard.com Mime-Version: 1.0 (Apple Message framework v915) Date: Sun, 23 Dec 2007 15:56:36 +0000 X-Mailer: Apple Mail (2.915) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-TMDA-Confirmed: Sun, 23 Dec 2007 11:02:56 -0500 Cc: Mozilla Security , Darin Adler , Chris Wilson Subject: [TLS] Including Cert. Practice Statement in issued SSL certs 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: , Content-Type: multipart/mixed; boundary="===============0697660072==" Errors-To: tls-bounces@lists.ietf.org --===============0697660072== Content-Type: multipart/signed; boundary=Apple-Mail-2--1072618790; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-2--1072618790 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hello folks. I recently read Brian Pederson's comment on = http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishin= g_1.html=20 and wanted to send in a suggestion. Perhaps it is already present =20 but I am not very knowledgeable on SSL. I believe a a field should be added to SSL certificates, in a =20 compatible and consistent place, containing the steps taken to verify =20= that specific certificate before it was issued. These steps should be =20= described by index into a list of possible steps, such that they can =20 be displayed in translated forms and not as a potentially ambiguous =20 English string chosen by a dodgy CA to confuse users. As I understand it there's no way currently for the man in the street =20= who knows nothing about computer security to distinguish between =20 certificates issued after visiting the company and checking their =20 records, and certificates issued by emailing a link to the WHOIS =20 contact. By implementing something like the above, we could have =20 'encryption only' grade certificates that protect against man=E2=80=90in=E2= =80=90=20 the=E2=80=90middle, these can remain free for anyone who wants = encryption, a =20 'shopping site' grade for sites that expect to take credit card =20 numbers, and 'financial institution' grade, that verifies the site you =20= are dealing with are a regulated bank or building society and not a =20 shell company set up for phishing. Once you are doing this, web browser vendors can display what level of =20= checks were taken for each cert. and potentially grade the level of =20 trust a certificate can infer. To the browser vendors: I strongly believe your next security update =20 should display a dialogue to this effect: "The certificate issuing company =E2=80=98GeoTrust=E2=80=99 have been = caught =20 issuing certificates without Due Diligence, resulting in a =20 sophisticated attack on Utah=E2=80=90based credit union, =E2=80=98Mountain= =20 America=E2=80=99. Do you wish to revoke the trust currently placed in = this =20 company to issue SSL certificates?" with a link to "More About SSL and =20= Default Trust Settings", and two buttons "Trust" and "Don't Trust". =20 You should not set a default button. This way users will be informed about what has happened (something =20 most are undoubtedly unaware of, including me until today) and have =20 the choice If enough decide to revoke their trust, websites will =20 choose another CA, and CAs will be more careful next time! =E2=80=94 Nicholas= --Apple-Mail-2--1072618790 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDoDCCA5ww ggKEoAMCAQICAQowCwYJKoZIhvcNAQEFMIGUMR8wHQYDVQQDDBZCb2lueCBTb2Z0d2FyZSBSb290 IENBMRcwFQYDVQQKDA5Cb2lueCBTb2Z0d2FyZTEXMBUGA1UECwwOQm9pbnggU29mdHdhcmUxCzAJ BgNVBAYMAkRFMREwDwYDVQQHDAhQdWNoaGVpbTEfMB0GCSqGSIb3DQEJAQwQb2xpdmVyQGJvaW54 LmNvbTAeFw0wNzEwMjYxNjQ2NTdaFw0xMTEyMDQxNjQ2NTdaMIGPMRgwFgYDVQQDDA9OaWNob2xh cyBTaGFua3MxFzAVBgNVBAoMDkJvaW54IFNvZnR3YXJlMRcwFQYDVQQLDA5Cb2lueCBTb2Z0d2Fy ZTELMAkGA1UEBgwCREUxETAPBgNVBAcMCFB1Y2hoZWltMSEwHwYJKoZIhvcNAQkBDBJuaWNob2xh c0Bib2lueC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDVtNf1v2nGVmRrajF7 x6HOhXtK8IdPTVLv5RuTkzuESOxY7xvKCUvNpfR+10sV2NDKAN+i0bxM3g5vcH6mbN0LEYhA6QY4 XRownyrnLVjJ2wX+GORhxbsJOxjRBX/FznJ4bOHrWrOcOOvqaUrWGB/G6ARLGqN8x2n4rHhDCM4E U85WdSaVFo3MDgscsU/zrYER+x03P5afwy5oTifWa8yEsfqk+EHRDKyka1MbQUJuh2VISV9+5Xvy KWyKG15zIpGhA/ZCsMW62/urMgCM0100f8wY2+N6JFVI5x0Z2JI81lN/dhjbu06N4Cn4EjqcpegD f2WM8Gqq7Qwd39XFrRuBAgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAFhfitDzpZHl+rDF+LAl43n2 +8bPDcvgJcAkLGjUqjdjcelnBGUUFkhdnlCoe5Pk3NwsWN41GOaPw/LT0lBTkXpjge/nWWoi72Iu QHSkR/1e2jbpGw6EFhojP5T2lGAZnU7B52lPAxC7hpSJJJnr2tgCdyDQgBz4dG5PDu/KUjcv7hnV Ec7VsRGjDAcZW91815rL3Ns5KB8rcKLGpVmIetzNvXqNL/AM8oqKmWMyro/HxPhIVko0euWZn/8k sMw6+smYwGdomPP8EFn0A7ZAhwi8UZj3u1hFr77TTjo30ua/yl2xYUYj1mGcNGA/76hy6DWyOLy0 BC3T1lAJujXxMHcxggOBMIIDfQIBATCBmjCBlDEfMB0GA1UEAwwWQm9pbnggU29mdHdhcmUgUm9v dCBDQTEXMBUGA1UECgwOQm9pbnggU29mdHdhcmUxFzAVBgNVBAsMDkJvaW54IFNvZnR3YXJlMQsw CQYDVQQGDAJERTERMA8GA1UEBwwIUHVjaGhlaW0xHzAdBgkqhkiG9w0BCQEMEG9saXZlckBib2lu eC5jb20CAQowCQYFKw4DAhoFAKCCAbswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDcxMjIzMTU1NjM3WjAjBgkqhkiG9w0BCQQxFgQUlSU48K3UgJVIz+HGrTgOsY0R 4Y0wgasGCSsGAQQBgjcQBDGBnTCBmjCBlDEfMB0GA1UEAwwWQm9pbnggU29mdHdhcmUgUm9vdCBD QTEXMBUGA1UECgwOQm9pbnggU29mdHdhcmUxFzAVBgNVBAsMDkJvaW54IFNvZnR3YXJlMQswCQYD VQQGDAJERTERMA8GA1UEBwwIUHVjaGhlaW0xHzAdBgkqhkiG9w0BCQEMEG9saXZlckBib2lueC5j b20CAQowga0GCyqGSIb3DQEJEAILMYGdoIGaMIGUMR8wHQYDVQQDDBZCb2lueCBTb2Z0d2FyZSBS b290IENBMRcwFQYDVQQKDA5Cb2lueCBTb2Z0d2FyZTEXMBUGA1UECwwOQm9pbnggU29mdHdhcmUx CzAJBgNVBAYMAkRFMREwDwYDVQQHDAhQdWNoaGVpbTEfMB0GCSqGSIb3DQEJAQwQb2xpdmVyQGJv aW54LmNvbQIBCjANBgkqhkiG9w0BAQEFAASCAQBVGC1Ddu9SgyZ0PIwIeSwdiX2ZmZva1SevSC7L 71V2WHbAO33W12odh8xIbNz2hV+3FI4ly4/7hp1hupkgoCNFIR30Zzmm+vMla2E/Quq7jN4KP4fG n2QQPI561XnsJ9hIBzU58VvKIlfvg7JqOsZTfCCs41dex7L8W8t2GsUz90C3GWoskSBwo1nPv37a +1DZVz7pDDRB0pfSigY2w1Wna9hxZFd9Qefxqwzk1yBIgWdHDJHwN5A06tZhki+K8TyyU+RKbUA/ wXNvl3ugbxAbN7xsxLz7cS+fjgpXE+zUj5g4K+L27AqSXgkjpBp1OSMW+nsj7bE+1Pe5z039hyPe AAAAAAAA --Apple-Mail-2--1072618790-- --===============0697660072== 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 --===============0697660072==-- From tls-bounces@lists.ietf.org Mon Dec 24 01:07:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6gSd-0008ML-Ie; Mon, 24 Dec 2007 01:06:47 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J6gSc-0008FE-E0 for tls-confirm+ok@megatron.ietf.org; Mon, 24 Dec 2007 01:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6gSc-0008Am-0s for tls@lists.ietf.org; Mon, 24 Dec 2007 01:06:46 -0500 Received: from larry.its.auckland.ac.nz ([130.216.12.34] helo=mailhost.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J6gSX-0003DW-GR for tls@lists.ietf.org; Mon, 24 Dec 2007 01:06:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9DD29183EE; Mon, 24 Dec 2007 19:06:37 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm1zTCzkS57u; Mon, 24 Dec 2007 19:06:37 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id CA92318362; Mon, 24 Dec 2007 19:06:36 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id A2982E0808D; Mon, 24 Dec 2007 19:06:33 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1J6gSP-00046I-Gh; Mon, 24 Dec 2007 19:06:33 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: nicholas@boinx.com, security@cryptguard.com, tls@lists.ietf.org Subject: Re: [TLS] Including Cert. Practice Statement in issued SSL certs In-Reply-To: Message-Id: Date: Mon, 24 Dec 2007 19:06:33 +1300 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: security@mozilla.org, chris.wilson@microsoft.com, darin@apple.com 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 Nicholas Shanks writes: >I believe a a field should be added to SSL certificates, in a compatible and >consistent place, containing the steps taken to verify that specific >certificate before it was issued. These steps should be described by index >into a list of possible steps, such that they can be displayed in translated >forms and not as a potentially ambiguous English string chosen by a dodgy CA >to confuse users. This has been tried before in PKI-profile level efforts. AFAIK none of them ever caught on, it's easy enough to find a "compatible and consistent place" to put something but (practically) impossible to find a "compatible and consistent" way to denote it. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 24 10:28:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6pE0-00039p-6a; Mon, 24 Dec 2007 10:28:16 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J6pDz-00039a-44 for tls-confirm+ok@megatron.ietf.org; Mon, 24 Dec 2007 10:28:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J6pDy-00039O-QO for tls@lists.ietf.org; Mon, 24 Dec 2007 10:28:14 -0500 Received: from woodstock.binhost.com ([8.8.40.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J6pDy-0004nn-Ds for tls@lists.ietf.org; Mon, 24 Dec 2007 10:28:14 -0500 Received: (qmail 12107 invoked by uid 0); 24 Dec 2007 15:28:08 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 24 Dec 2007 15:28:08 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 24 Dec 2007 10:28:06 -0500 To: Nicholas Shanks ,tls@lists.ietf.org, security@cryptguard.com From: Russ Housley Subject: Re: [TLS] Including Cert. Practice Statement in issued SSL certs In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Message-Id: Cc: Mozilla Security , Darin Adler , Chris Wilson 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 This is the point of the certificate policies extension. Certificate policies are just too complex for them to fulfill the use case that you have in mind. Today, there are a few CAs that have a reputation that consumers recognize, so the issuer field seems to matter more. There are examples where the certificate policy is helping, but not for the open Internet. Showing conformance to certificate policy is important in a business context where cross certification is desired. Russ >Hello folks. I recently read Brian Pederson's comment on >http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html >and wanted to send in a suggestion. Perhaps it is already present >but I am not very knowledgeable on SSL. > >I believe a a field should be added to SSL certificates, in a >compatible and consistent place, containing the steps taken to verify >that specific certificate before it was issued. These steps should be >described by index into a list of possible steps, such that they can >be displayed in translated forms and not as a potentially ambiguous >English string chosen by a dodgy CA to confuse users. > >As I understand it there's no way currently for the man in the street >who knows nothing about computer security to distinguish between >certificates issued after visiting the company and checking their >records, and certificates issued by emailing a link to the WHOIS >contact. By implementing something like the above, we could have >'encryption only' grade certificates that protect against >man‐in‐ the‐middle, these can remain free for anyone who wants >encryption, a >'shopping site' grade for sites that expect to take credit card >numbers, and 'financial institution' grade, that verifies the site you >are dealing with are a regulated bank or building society and not a >shell company set up for phishing. > >Once you are doing this, web browser vendors can display what level of >checks were taken for each cert. and potentially grade the level of >trust a certificate can infer. > >To the browser vendors: I strongly believe your next security update >should display a dialogue to this effect: >"The certificate issuing company ‘GeoTrust’ have been caught >issuing certificates without Due Diligence, resulting in a >sophisticated attack on Utah‐based credit union, ‘Mountain >America’. Do you wish to revoke the trust currently placed in this >company to issue SSL certificates?" with a link to "More About SSL and >Default Trust Settings", and two buttons "Trust" and "Don't Trust". >You should not set a default button. > >This way users will be informed about what has happened (something >most are undoubtedly unaware of, including me until today) and have >the choice If enough decide to revoke their trust, websites will >choose another CA, and CAs will be more careful next time! > > Nicholass _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 28 10:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Hag-0003P4-PK; Fri, 28 Dec 2007 10:57:42 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J8Hag-0003Oq-7U for tls-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 10:57:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Haf-0003Oi-U7 for tls@lists.ietf.org; Fri, 28 Dec 2007 10:57:41 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8Haf-0007UD-EW for tls@lists.ietf.org; Fri, 28 Dec 2007 10:57:41 -0500 Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id lBSFuMgH012166; Fri, 28 Dec 2007 16:56:22 +0100 (MET) From: Martin Rex Message-Id: <200712281556.lBSFu9tv004934@fs4113.wdf.sap.corp> Subject: Re: [TLS] Including Cert. Practice Statement in issued SSL To: housley@vigilsec.com (Russ Housley) Date: Fri, 28 Dec 2007 16:56:09 +0100 (MET) In-Reply-To: from "Russ Housley" at Dec 24, 7 10:28:06 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal05 X-SAP: out X-Spam-Score: -4.0 (----) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: security@cryptguard.com, security@mozilla.org, tls@lists.ietf.org, darin@apple.com, chris.wilson@microsoft.com X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > > This is the point of the certificate policies extension. Certificate policies are close-to-useless complexity that do NOT work at all here, certificate policies work ONLY within a single hierarchy (they might sometimes work in a virtual single hierarchy,+ aka cross-certification), but not with Web Browsers that come with a prepopulated list of > 100 entirely unrelated trust anchors. > > Today, there are a few CAs that have a reputation > that consumers recognize, so the issuer field seems to matter more. I would like to distinguish brand name from reputation. I know one particular well known CA, that once issued two perfectly real Microsoft Authenticode certificates to someone who was not Microsoft--which is technically two magnitudes worse than issuing a Web-Server cert inappropriately. When they finally put these certs onto their CRL (a few weeks after issue), it was realized that having it in the CRL didn't really change anything, because the component that was vulnerable didn't ever look at their CRLs... The primary difference among CAs in the price tag on their certs and where the business is located in the world (i.e. jurisdiction regulating data protection and gross negligence). For businesses from other countries than the CA itself, the available payment options may influence the choice more than any kind of brand name. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Dec 28 14:17:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Khr-0005ce-02; Fri, 28 Dec 2007 14:17:19 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J8Kho-0005ID-2v for tls-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 14:17:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8Khn-0005HB-Om for tls@lists.ietf.org; Fri, 28 Dec 2007 14:17:15 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J8Khn-0003cS-F7 for tls@lists.ietf.org; Fri, 28 Dec 2007 14:17:15 -0500 Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id lBSJHUh4025089 for ; Fri, 28 Dec 2007 14:17:30 -0500 (EST) X-AuditID: 90333308-000013b000000748-2a-47754bc62f11 Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 14:17:26 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 28 Dec 2007 14:17:26 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Including Cert. Practice Statement in issued SSL Date: Fri, 28 Dec 2007 14:17:27 -0500 Message-ID: In-Reply-To: <200712281556.lBSFu9tv004934@fs4113.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Including Cert. Practice Statement in issued SSL Thread-Index: AchJaoBC88Najyw2RYacGOFWuukUSAAGTfAw References: from "Russ Housley" at Dec24, 7 10:28:06 am <200712281556.lBSFu9tv004934@fs4113.wdf.sap.corp> From: "Kemp, David P." To: , , X-OriginalArrivalTime: 28 Dec 2007 19:17:26.0288 (UTC) FILETIME=[48065900:01C84986] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -1.0 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: 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 > From: Martin Rex [mailto:Martin.Rex@sap.com]=20 > Russ Housley wrote: > >=20 > > This is the point of the certificate policies extension.=20 > > Certificate policies are close-to-useless complexity that do > NOT work at all here, certificate policies work ONLY within > a single hierarchy (they might sometimes work in a virtual > single hierarchy,+ aka cross-certification), but not with > Web Browsers that come with a prepopulated list of > 100 > entirely unrelated trust anchors. The fact that policies are useless in general does not contradict the fact that the point of the extension is to convey useful information. *IF* there were standardized policies that 100+ trust anchors followed (e.g., Policy A =3D in-person registration with 2 forms of ID and private key on a hardware token, Policy B =3D software cert issued to anyone with an email account), then the extension would be useful. If no SDO takes on adoption/development of a few standard policies, then the extension will remain about as useful as a Beta videotape. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 31 17:08:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9SnD-00038w-FY; Mon, 31 Dec 2007 17:07:31 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J9SnC-00038o-1S for tls-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 17:07:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9SnB-00038g-Nh for tls@ietf.org; Mon, 31 Dec 2007 17:07:29 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9SnA-00080o-B8 for tls@ietf.org; Mon, 31 Dec 2007 17:07:29 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 500465081A for ; Mon, 31 Dec 2007 14:07:56 -0800 (PST) Date: Mon, 31 Dec 2007 14:07:56 -0800 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071231220756.500465081A@romeo.rtfm.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [TLS] Certificate alert severity 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 In Issue #84 (http://www3.tools.ietf.org/wg/tls/trac/ticket/84) Pasi writes: Currently bad_certificate, unsupported_certificate, certificate_revoked, certificate_expired, and certificate_unknown can be either warning or fatal; unknown_ca is always fatal. This is not fully consistent. Also, my understanding is that current implementations don't usually send these as warnings -- if the certificate is e.g. expired, but the user anyway accepts it (by clicking "OK" in browser), no alert is sent. Furthermore, I don't think sending them as warnings ("I think your cert is expired, but I'm going to accept it anyway") would really work -- I'd guess that many servers would get confused, and close the connection. This is related to Martin's comment (2007-12-06) about what servers should do if they receive a client certificate they don't like (e.g. can't chain to any trust anchor): should they send a fatal alert and close the connection (which seems to be what some implementations do today), or should they continue as if no certificate had been sent? As far as I can tell, warning alerts (except for close_notify), have turned out to be pretty useless. I would be fine with making all of these fatal, but I'd like to hear comments from the WG here... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 31 17:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9TQ8-0007PV-J3; Mon, 31 Dec 2007 17:47:44 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J9TQ6-0007PP-Fu for tls-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 17:47:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9TQ6-0007PG-5t for tls@lists.ietf.org; Mon, 31 Dec 2007 17:47:42 -0500 Received: from cse-smtp.ucsd.edu ([132.239.51.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9TQ4-0000Ce-Pp for tls@lists.ietf.org; Mon, 31 Dec 2007 17:47:42 -0500 Received: from [128.54.40.88] (0-1d-4f-f6-9f-d8.dynamic.ucsd.edu [128.54.40.88]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cse-smtp.ucsd.edu (Postfix) with ESMTP id 49CE52C342 for ; Mon, 31 Dec 2007 14:47:40 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200712211250.03315.bradh@frogmouth.net> References: <20071220173400.C6CD25081A@romeo.rtfm.com> <6b9359640712201405w1c5e1e71xa893a05de350b494@mail.gmail.com> <20071220221914.6DB0B5081A@romeo.rtfm.com> <200712211250.03315.bradh@frogmouth.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2B53539D-3C13-411F-A5C5-7CC909B154BE@hovav.net> Content-Transfer-Encoding: 7bit From: Hovav Shacham Subject: Re: [TLS] Status of IDEA Date: Mon, 31 Dec 2007 14:47:46 -0800 To: tls@lists.ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 On Dec 20, 2007, at 5:50 PM, Brad Hards wrote: > If we actually knew of a problem, then IDEA would be "MUST NOT". Weighing in late, I support "MUST NOT." The conservative interpretation of an absence of extensive studies of a block cipher is that the security of that cipher cannot be relied upon. And there is no reason now to prefer IDEA to AES. I think "MUST NOT" will do the best job of steering implementations towards known-secure cipher suites. Cheers -- Hovav. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 31 17:49: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 1J9TRb-0000Vg-1i; Mon, 31 Dec 2007 17:49:15 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J9TRZ-0000Va-Th for tls-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 17:49:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9TRZ-0000VS-JV for tls@ietf.org; Mon, 31 Dec 2007 17:49:13 -0500 Received: from [74.95.2.173] (helo=romeo.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9TRZ-00007t-AJ for tls@ietf.org; Mon, 31 Dec 2007 17:49:13 -0500 Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 3FE235081A for ; Mon, 31 Dec 2007 14:49:41 -0800 (PST) Date: Mon, 31 Dec 2007 14:49:41 -0800 From: Eric Rescorla To: tls@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20071231224941.3FE235081A@romeo.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [TLS] Issue 66: HMAC-256 based ciphersuites 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 Someone, I can't remember who, suggested that we add HMAC-SHA256-based ciphersuites (i.e., ones that use it as a message MAC) directly in TLS 1.2. I'm waffling as to whether it's a good idea. Arguments for: - We made it the default for the PRF. - It's weird to to to all this trouble and not define them. Arguments against: - There's nothing known wrong with HMAC-SHA1 - This revision is about flexibility, not actually adding new digests. Comments? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Dec 31 20:43:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9W9q-0003X9-Ra; Mon, 31 Dec 2007 20:43:06 -0500 Received: from tls by megatron.ietf.org with local (Exim 4.43) id 1J9W9p-0003UF-Kn for tls-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 20:43:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9W9p-0003Qp-8g for tls@ietf.org; Mon, 31 Dec 2007 20:43:05 -0500 Received: from llmail1.ll.mit.edu ([129.55.12.41] helo=ll.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J9W9o-0002Tf-Rl for tls@ietf.org; Mon, 31 Dec 2007 20:43:05 -0500 Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id m011h2B7021704 for ; Mon, 31 Dec 2007 20:43:02 -0500 (EST) Received: from lle2k7-hub02.llan.ll.mit.edu( ), claiming to be "LLE2K7-HUB02.mitll.ad.local" via SMTP by llpost, id smtpdAAAJGaWwQ; Mon Dec 31 20:42:53 2007 Received: from LLE2K7-BE01.mitll.ad.local ([ ]) by LLE2K7-HUB02.mitll.ad.local ([ ]) with mapi; Mon, 31 Dec 2007 20:42:53 -0500 From: "Blumenthal, Uri" To: "tls@ietf.org" Date: Mon, 31 Dec 2007 20:42:55 -0500 Subject: Re: [TLS] Issue 66: HMAC-256 based ciphersuites Thread-Topic: [TLS] Issue 66: HMAC-256 based ciphersuites Thread-Index: AchL/2OOrcUvYv4ISfWiuA3avFmxEQAGD191 Message-ID: In-Reply-To: <20071231224941.3FE235081A@romeo.rtfm.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: 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: , Content-Type: multipart/mixed; boundary="===============1919030071==" Errors-To: tls-bounces@lists.ietf.org --===============1919030071== Content-Language: en Content-Type: multipart/alternative; boundary="_000_C39F04CF19Burillmitedu_" --_000_C39F04CF19Burillmitedu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am for adding SHA256-based suites. We want to phase SHA1 out and phase it= s probable replacement in. SHA1 did exhibit some weaknesses. and we hardly want to wait and see whethe= r they will turn into exploits some day. On 12/31/07 5:49 PM, "Eric Rescorla" wrote: Someone, I can't remember who, suggested that we add HMAC-SHA256-based ciphersuites (i.e., ones that use it as a message MAC) directly in TLS 1.2. I'm waffling as to whether it's a good idea. Arguments for: - We made it the default for the PRF. - It's weird to to to all this trouble and not define them. Arguments against: - There's nothing known wrong with HMAC-SHA1 - This revision is about flexibility, not actually adding new digests. Comments? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls -- Regards, Uri --_000_C39F04CF19Burillmitedu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] Issue 66: HMAC-256 based ciphersuites I= am for adding SHA256-based suites. We want to phase SHA1 out and phase its= probable replacement in.

SHA1 did exhibit some weaknesses. and we hardly want to wait and see whethe= r they will turn into exploits some day.


On 12/31/07 5:49 PM, "Eric Rescorla" <ekr@networkresonance.com= > wrote:

Someone, I can't remember who, suggested that we a= dd
HMAC-SHA256-based ciphersuites (i.e., ones that use it as a message
MAC) directly in TLS 1.2. I'm waffling as to whether it's a good
idea.

Arguments for:

- We made it the default for the PRF.
- It's weird to to to all this trouble and not define them.


Arguments against:
- There's nothing known wrong with HMAC-SHA1
- This revision is about flexibility, not actually adding new
  digests.

Comments?

-Ekr


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



--
Regards,
Uri

 --_000_C39F04CF19Burillmitedu_-- --===============1919030071== 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 --===============1919030071==--