From badra@isima.fr Mon Mar 2 02:35:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014983A6980 for ; Mon, 2 Mar 2009 02:35:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.295 X-Spam-Level: X-Spam-Status: No, score=-1.295 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-wGX705h-lo for ; Mon, 2 Mar 2009 02:35:07 -0800 (PST) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id BC59228C0FF for ; Mon, 2 Mar 2009 02:35:06 -0800 (PST) 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 n22BYwbR409804 for ; Mon, 2 Mar 2009 11:34:59 GMT Message-ID: <49ABB790.9070300@isima.fr> Date: Mon, 02 Mar 2009 11:40:16 +0100 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 CC: tls@ietf.org References: <20090228214501.E57E43A684B@core3.amsl.com> In-Reply-To: <20090228214501.E57E43A684B@core3.amsl.com> 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]); Mon, 02 Mar 2009 11:34:59 +0000 (WET) Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 10:35:08 -0000 Hi Eric, Section 4, version 03 said that the context length may be Zero (This text has been removed in Version 04). In case the context is Zero length, does this length is omitted from the PRF input? or is it concatenated to the SecurityParameters.client_random + SecurityParameters.server_random? Best regards, Badra > 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 Exporters for Transport Layer Security (TLS) > Author(s) : E. Rescorla > Filename : draft-ietf-tls-extractor-04.txt > Pages : 6 > Date : 2009-02-28 > > 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-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ekr@networkresonance.com Mon Mar 2 06:24:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20C4E28C0FD for ; Mon, 2 Mar 2009 06:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.529 X-Spam-Level: X-Spam-Status: No, score=-2.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1JG6Fl7Icv0 for ; Mon, 2 Mar 2009 06:24:49 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6991D28C284 for ; Mon, 2 Mar 2009 06:24:09 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 054FC50822; Mon, 2 Mar 2009 06:47:26 -0800 (PST) Date: Mon, 02 Mar 2009 06:47:25 -0800 From: Eric Rescorla To: Mohamad Badra In-Reply-To: <49ABB790.9070300@isima.fr> References: <20090228214501.E57E43A684B@core3.amsl.com> <49ABB790.9070300@isima.fr> 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: <20090302144726.054FC50822@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:24:50 -0000 At Mon, 02 Mar 2009 11:40:16 +0100, Mohamad Badra wrote: > > Hi Eric, > > Section 4, version 03 said that the context length may be Zero (This text has been removed in Version 04). Editor error. > In case the context is Zero length, does this length is omitted from the PRF input? or is it concatenated to the SecurityParameters.client_random + SecurityParameters.server_random? The length bytes are zero. The context isn't there. -Ekr From simon@josefsson.org Mon Mar 2 06:57:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 001D23A6A8A for ; Mon, 2 Mar 2009 06:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2HD0jTlkz3Dk for ; Mon, 2 Mar 2009 06:57:26 -0800 (PST) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 02D713A6818 for ; Mon, 2 Mar 2009 06:57:25 -0800 (PST) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Le9aW-0007aX-BW for tls@ietf.org; Mon, 02 Mar 2009 15:57:48 +0100 From: Simon Josefsson To: tls@ietf.org References: <20090228214501.E57E43A684B@core3.amsl.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090302:i-d-announce@ietf.org::EKnDjDWubzJmaEoI:37kq X-Hashcash: 1:22:090302:tls@ietf.org::iwwiNqwgV1HiaGIc:EFSr X-Hashcash: 1:22:090302:internet-drafts@ietf.org::i3fYdeWhE7tB0Ahu:9eU2 Date: Mon, 02 Mar 2009 15:57:47 +0100 Message-ID: <87hc2cas5w.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [TLS] Confidentiality of "context_value" in tls-extractor? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 14:57:27 -0000 Hi Eric, WG, I'm preparing a document that uses the tls-extractor document to strengthen Kerberos V5 encryption keys using keys derived from TLS, see: http://www.ietf.org/internet-drafts/draft-josefsson-krb5starttls-bootstrap-00.txt I would appreciate general review of how that document uses the tls-extractor construct, but I also have a specific question: The tls-extractor document reads: PRF(master_secret, label, SecurityParameters.client_random + SecurityParameters.server_random + context_value_length + context_value )[length] ... The context value allows the application using the exporter to mix its own data with the TLS PRF for the exporter output. The context value length is encoded as an unsigned 16-bit quantity (uint16) representing the length of the context value. Is it fine if "context_value" contains material intended to be confidential, e.g., encryption keys? I suspect it may be a common use-case to "strengthen" keys derived via other protocols by using tls-extractor, by placing encryption keys or other sensitive information in the context_value field, so it would be helpful to understand whether this is a good idea or whether it is something that falls outside of the intended use of tls-extractor. In particular, I'm thinking about how the data is fed to the hash functions, and whether any length extension attacks or other problems applies. Thanks, /Simon From jsalowey@cisco.com Mon Mar 2 09:20:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB93A3A6908 for ; Mon, 2 Mar 2009 09:20:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60vOa5-+BceU for ; Mon, 2 Mar 2009 09:20:54 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id EBF733A6AFA for ; Mon, 2 Mar 2009 09:20:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.38,290,1233532800"; d="scan'208";a="30700528" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2009 17:21:21 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n22HLK3o031922 for ; Mon, 2 Mar 2009 09:21:20 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n22HLKbj016935 for ; Mon, 2 Mar 2009 17:21:20 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Mar 2009 09:21:20 -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 Date: Mon, 2 Mar 2009 09:21:19 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call on draft-ietf-tls-extractor-04.txt Thread-Index: AcmbW01CISDSPuJvT9WYX0BnHfVsjg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 02 Mar 2009 17:21:20.0565 (UTC) FILETIME=[4DC1DE50:01C99B5B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=366; t=1236014480; x=1236878480; c=relaxed/simple; s=sjdkim1004; 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:=20Working=20Group=20Last=20Call=20on=20draft-ietf -tls-extractor-04.txt |Sender:=20; bh=AYRiyH5UcyKUuG1rERzlMeYKVh1qrAb9DoXWICU0fOs=; b=DB2cbAKpAXYGQHT46y0eASpp+E7hEsM8tba0q7yysu/g+trBAf5jFiYQhs nUJm7sASBqJEzlUM0IxsFnpXfI2mDZcYBBuUvWq2MlzBIFyuQmsRTSKdPegt a+m5O5pnMkB8pGOxsSJjBRkgYqZIT0oRmHJAKAqfurzBxpdValR3o=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [TLS] Working Group Last Call on draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 17:20:55 -0000 This announcement is for working group last call on draft-ietf-tls-extractor-04.txt. Please send your comments to the list by Tuesday March 10, 2009. Comments on this draft sent before this announcement will also be considered during last call. The draft and diffs can be found at: http://tools.ietf.org/html/draft-ietf-tls-extractor-04 Thanks, Joe From Henry.Story@Sun.COM Tue Mar 3 13:21:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3513A69F4 for ; Tue, 3 Mar 2009 13:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDrVUSD+qpem for ; Tue, 3 Mar 2009 13:21:33 -0800 (PST) Received: from gmp-eb-inf-1.sun.com (gmp-eb-inf-1.sun.com [192.18.6.21]) by core3.amsl.com (Postfix) with ESMTP id AFF1A3A6857 for ; Tue, 3 Mar 2009 13:21:32 -0800 (PST) Received: from fe-emea-09.sun.com (gmp-eb-lb-2-fe2.eu.sun.com [192.18.6.11]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n23LLYM9021551 for ; Tue, 3 Mar 2009 21:21:46 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; delsp=yes; format=flowed; charset=US-ASCII Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) id <0KFY00H0086Y3W00@fe-emea-09.sun.com> for tls@ietf.org; Tue, 03 Mar 2009 21:21:34 +0000 (GMT) Received: from [192.168.0.1] ([unknown] [88.163.1.232]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 23 2008)) with ESMTPSA id <0KFY004RR8NSPZF0@fe-emea-09.sun.com>; Tue, 03 Mar 2009 21:21:34 +0000 (GMT) Date: Tue, 03 Mar 2009 22:21:27 +0100 From: Henry Story In-reply-to: <49A7C991.5050309@gnutls.org> Sender: Henry.Story@Sun.COM To: Nikos Mavrogiannopoulos Message-id: <8F3D6452-2BEF-4149-ABC4-0E4281B3124C@Sun.COM> X-Mailer: Apple Mail (2.930.3) References: <6CF4BBB1-9004-44B7-A08E-62BA8D1F9F86@Sun.COM> <49A7C991.5050309@gnutls.org> Cc: tls@ietf.org, foaf-protocols@lists.foaf-project.org Subject: Re: [TLS] [foaf-protocols] foaf+tls for distributed social networks - 2 questions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2009 21:21:34 -0000 On 27 Feb 2009, at 12:08, Nikos Mavrogiannopoulos wrote: > Henry Story wrote: >> Dear TLS experts, >> >> We are working on a very simple protocol for distributed identity >> in a >> web of trust that uses TLS in a novel way. The details of this are >> short >> and can be found online [1]. Here I'd first just like to ask two >> questions, to get into the heart of the problem, then I'll explain >> why >> these came up. > > After the explanation and seeing the protocol description I still do > not > understand why you need the client certificate for what you want to > achieve. Why you don't send the information you need for foaf on the > application layer (if it is http via a cookie etc)? Why send a dummy > certificate and add some extensions on it? Also the security offerings > are not clear to me. What will that protocol offer, security-wise? I wrote up another post that may help answer some of these questions after some very interesting discussions on the foaf-protocols mailing list. "The foaf-ssl paradigm shift" http://blogs.sun.com/bblfish/entry/the_foaf_ssl_paradigm_shift I'd be very interested to know if that helps make things clearer, if you agree, if there are things I missed there? Henry > regards, > Nikos > _______________________________________________ > foaf-protocols mailing list > foaf-protocols@lists.foaf-project.org > http://lists.foaf-project.org/mailman/listinfo/foaf-protocols From A.Hoenes@tr-sys.de Wed Mar 4 03:45:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B74128C285 for ; Wed, 4 Mar 2009 03:45:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.646 X-Spam-Level: * X-Spam-Status: No, score=1.646 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWB+hafvW810 for ; Wed, 4 Mar 2009 03:45:19 -0800 (PST) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 8C55228C284 for ; Wed, 4 Mar 2009 03:45:18 -0800 (PST) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA233377027; Wed, 4 Mar 2009 12:43:47 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id MAA23377; Wed, 4 Mar 2009 12:43:46 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903041143.MAA23377@TR-Sys.de> To: tls@ietf.org, draft-kato-tls-rfc4132bis@tools.ietf.org Date: Wed, 4 Mar 2009 12:43:46 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [TLS] draft-kato-tls-rfc4132bis-03 : get rid of unneeded prose X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 11:45:20 -0000 Hello, The 'Introduction' of draft-kato-tls-rfc4132bis-03 still contains a lot of details regarding the Camellia cipher primitive proper, which IMO are out of scope and not needed for this document describing the use of that building block in TLS. The fundamental reference, RFC 3713, already contains what needs to be said, and it is not very useful to have every document making use of that cipher repeat the same or similar verbiage. I strongly suggest that the bulk of the 'marketing prose' in Section 1 (para 2 ff.) be removed from the draft -- in a similar manner as it has been done now for the companion Camellia for IPsec draft. Otherwise, I suggest that the WG consider the portfolio question I already had raised in http://www.IETF.ORG/mail-archive/web/tls/current/msg03242.html (combining Camellia-256 with SHA-384 instead of SHA-256) and make a decision on whether that document should be adopted as a WG document or recommended as an individual submission for PS. Thoughts? Opinions? Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From badra@isima.fr Wed Mar 4 07:57:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45FC628C399 for ; Wed, 4 Mar 2009 07:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.61 X-Spam-Level: X-Spam-Status: No, score=-1.61 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BN1wBXgIolXr for ; Wed, 4 Mar 2009 07:57:24 -0800 (PST) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 2929E28C3AE for ; Wed, 4 Mar 2009 07:57:23 -0800 (PST) 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 n24GvHCO1302640; Wed, 4 Mar 2009 16:57:18 GMT Message-ID: <49AEA61B.5070407@isima.fr> Date: Wed, 04 Mar 2009 17:02:35 +0100 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alfred References: <200903041143.MAA23377@TR-Sys.de> In-Reply-To: <200903041143.MAA23377@TR-Sys.de> 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]); Wed, 04 Mar 2009 16:57:18 +0000 (WET) Cc: draft-kato-tls-rfc4132bis@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] draft-kato-tls-rfc4132bis-03 : get rid of unneeded prose X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 15:57:25 -0000 Hi, I agree with Alfred, the document should avoid repeating details regarding Camellia block cipher. IMO, a pointer to RFC3713 is sufficient. To help the reader, it may be better to separate SHA1 and SHA2 into two Sections. An application statement on using them with different TLS version should be useful. Best regards, Badra > Hello, > > The 'Introduction' of draft-kato-tls-rfc4132bis-03 still contains > a lot of details regarding the Camellia cipher primitive proper, > which IMO are out of scope and not needed for this document > describing the use of that building block in TLS. > > The fundamental reference, RFC 3713, already contains what needs > to be said, and it is not very useful to have every document > making use of that cipher repeat the same or similar verbiage. > > I strongly suggest that the bulk of the 'marketing prose' in Section 1 > (para 2 ff.) be removed from the draft -- in a similar manner as > it has been done now for the companion Camellia for IPsec draft. > > > Otherwise, I suggest that the WG consider the portfolio question > I already had raised in > http://www.IETF.ORG/mail-archive/web/tls/current/msg03242.html > (combining Camellia-256 with SHA-384 instead of SHA-256) > and make a decision on whether that document should be adopted as > a WG document or recommended as an individual submission for PS. > > Thoughts? Opinions? > > > Kind regards, > Alfred H?nes. > > From Martin.Rex@sap.com Wed Mar 4 08:13:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28C423A691A for ; Wed, 4 Mar 2009 08:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAwbukTjkD-D for ; Wed, 4 Mar 2009 08:13:08 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 052583A67F5 for ; Wed, 4 Mar 2009 08:13:07 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n24GDYhb014425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 17:13:34 +0100 (MET) From: Martin Rex Message-Id: <200903041613.n24GDXBA016441@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 4 Mar 2009 17:13:33 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Feb 27, 9 07:07:21 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS Errate confirmation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 04 Mar 2009 16:13:09 -0000 Eric Rescorla wrote: > > I confirm this is correct. Sorry for nitpicking, but rather than: struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; I believe it should say: struct { ClientCertificateType certificate_types<1..2^8-1>; SignatureAndHashAlgorithm supported_signature_algorithms<1..2^16-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; -Martin From Martin.Rex@sap.com Wed Mar 4 08:38:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463283A6778 for ; Wed, 4 Mar 2009 08:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.88 X-Spam-Level: X-Spam-Status: No, score=-4.88 tagged_above=-999 required=5 tests=[AWL=1.369, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWmL57cs6LlG for ; Wed, 4 Mar 2009 08:38:49 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id A8A043A6A88 for ; Wed, 4 Mar 2009 08:38:25 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n24Gcqf6015777 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 4 Mar 2009 17:38:52 +0100 (MET) From: Martin Rex Message-Id: <200903041638.n24Gcp2K018360@fs4113.wdf.sap.corp> To: ekr@rtfm.com Date: Wed, 4 Mar 2009 17:38:51 +0100 (MET) In-Reply-To: <200903041613.n24GDXBA016441@fs4113.wdf.sap.corp> from "Martin Rex" at Mar 4, 9 05:13:33 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 Cc: tls@ietf.org Subject: Re: [TLS] TLS Errate confirmation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Wed, 04 Mar 2009 16:38:50 -0000 Martin Rex wrote: > > Eric Rescorla wrote: > > > > I confirm this is correct. > > Sorry for nitpicking, but rather than: > > struct { > ClientCertificateType certificate_types<1..2^8-1>; > SignatureAndHashAlgorithm > supported_signature_algorithms<2^16-1>; > DistinguishedName certificate_authorities<0..2^16-1>; > } CertificateRequest; > > I believe it should say: > > struct { > ClientCertificateType certificate_types<1..2^8-1>; > SignatureAndHashAlgorithm > supported_signature_algorithms<1..2^16-1>; > DistinguishedName certificate_authorities<0..2^16-1>; > } CertificateRequest; The above appears to apply to rfc5246 7.4.4. as well. I can't see anything in the text that suggests the information in SignatureAndHashAlgorithms may be left out, so I assume the length spec should read <1..2^16-1> and not <0..2^16-1>. Not being a real TLS implementor I had not noticed that the field SignatureAndHashAlgorithm had been newly added to TLS v1.2 and didn't exist in TLS v1.1. I'm not particularly happy about a backwards incompatible change in the (wire) protocol that is _not_ clearly marked as such in the spec. Things like this have happend before in the history of SSLv3 -> TLS v1.2 (e.g. the switch from NO_CERTIFICATE alert to an empty client certificate message), and I would like to politely ask that for future spec revisions, the precise difference of a backwards incompatible changes in the wire format of a protocol PDU should be described in the TLS specification. ;-) -Martin From Michael.G.Williams@nokia.com Wed Mar 4 15:19:10 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93E4428C285 for ; Wed, 4 Mar 2009 15:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFeFHh7b9Dy0 for ; Wed, 4 Mar 2009 15:19:09 -0800 (PST) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 1518628C34C for ; Wed, 4 Mar 2009 15:19:03 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n24NIxO9028845 for ; Wed, 4 Mar 2009 17:19:31 -0600 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 01:19:00 +0200 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 01:18:54 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 01:18:49 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 5 Mar 2009 00:18:47 +0100 From: To: Date: Thu, 5 Mar 2009 00:18:45 +0100 Thread-Topic: New Version Notification for draft-barrett-mobile-dtls-00 Thread-Index: AcmdHRwrIEGgWHGuSJ6JYTXzVhwtXQAAHz6w Message-ID: 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-OriginalArrivalTime: 04 Mar 2009 23:18:49.0770 (UTC) FILETIME=[934E50A0:01C99D1F] X-Nokia-AV: Clean Subject: [TLS] New Version Notification for draft-barrett-mobile-dtls-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:19:10 -0000 Hi All, Jeremey and I have created a new I-D for consideration by the TLS WG. Your = comments are more than welcome. Kind Regards, Michael -----Original Message----- From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: 04 March, 2009 15:01 To: Barrett Jeremey (Nokia-S/MtView) Cc: Williams Michael.G (Nokia-CIC/Dallas) Subject: New Version Notification for draft-barrett-mobile-dtls-00=20 A new version of I-D, draft-barrett-mobile-dtls-00.txt has been successfuly= submitted by Jeremey Barrett and posted to the IETF repository. Filename: draft-barrett-mobile-dtls Revision: 00 Title: Mobile DTLS Creation_date: 2009-03-04 WG ID: Independent Submission Number_of_pages: 12 Abstract: Mobile DTLS (Mobi-D) is an extension to DTLS that provides host mobility su= pport. After obtaining a new IP address or port, a DTLS client mobile host= can continue sending to its DTLS server correspondent host. The mobile ho= st continues to use the existing set of security parameters, from the new a= ddress, without re- negotiation. The correspondent host accepts packets fr= om the new IP address or port, also without re-negotiation. After receivin= g any valid DTLS packet from the mobile host's new address or port, the cor= respondent host uses the new address or port to send to the mobile host. = =20 The IETF Secretariat. From stefans@exmsft.com Wed Mar 4 15:47:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2D193A6B14 for ; Wed, 4 Mar 2009 15:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.976 X-Spam-Level: X-Spam-Status: No, score=-0.976 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PRXFFXvJmJD for ; Wed, 4 Mar 2009 15:47:22 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id F19523A684E for ; Wed, 4 Mar 2009 15:47:18 -0800 (PST) Received: (qmail 52198 invoked from network); 4 Mar 2009 23:47:54 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 4 Mar 2009 23:47:54 -0000 Received: (qmail 542 invoked from network); 4 Mar 2009 23:47:45 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 4 Mar 2009 23:47:45 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 05 Mar 2009 00:47:44 +0100 From: Stefan Santesson To: TLS wg Message-ID: Thread-Topic: New "Fast-Track" draft posted Thread-Index: AcmdI5z8f6uJVQ8Wz0el9b7N9kU1sQ== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3319058865_1972567" Subject: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2009 23:47:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3319058865_1972567 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable As a result of the discussions we had around last IETF I have now posted a new =B3Fast Track=B2 inspired draft. The name of this draft is draft-santesson-tls-certcache-00 It will be available in a few days from the I-D repository. Until then it can be obtained from the staging site at: http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.tx= t I have chosen to do a completely new draft instead of updating the old fast-track document as I have used a very simplified approach as starting point. My document is limited to one new TLS extension with the sole purpose of including a hash of a cached cert path to allow this cert path to be omitte= d from the server Certificate message. I submitted this draft to inject some energy into the discussion again but I=B9m not locked on the approach if there are good reasons to expand it. Please read and provide comments. I would like to request a small time slot on the TLS meeting agenda in San Francisco to discuss this if possible. Stefan Santesson AAA-sec.com =20 --B_3319058865_1972567 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable New "Fast-Track" draft posted As a result of the discussions we had around last IETF I have now posted a= new “Fast Track” inspired draft.

The name of this draft is  draft-santesson-tls-certcac= he-00
It will be available in a few days from the I-D repos= itory. Until then it can be obtained from the staging site at: ht= tp://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt

I have chosen to do a completely new draft instead of updating the old fast= -track document as I have used a very simplified approach as starting point.=
My document is limited to one new TLS extension with the sole purpose of in= cluding a hash of a cached cert path to allow this cert path to be omitted f= rom the server Certificate message.

I submitted this draft to inject some energy into the discussion again but = I’m not locked on the approach if there are good reasons to expand it.=
Please read and provide comments.

I would like to request a small time slot on the TLS meeting agenda in San = Francisco to discuss this if possible.


Stefan Santesson
AAA-sec.com
--B_3319058865_1972567-- From stefans@exmsft.com Wed Mar 4 18:39:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39AD3A6A40 for ; Wed, 4 Mar 2009 18:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.804 X-Spam-Level: X-Spam-Status: No, score=-0.804 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, URIBL_RHS_DOB=1.083] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HldGeHcs9peh for ; Wed, 4 Mar 2009 18:39:44 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id E989C3A6A1A for ; Wed, 4 Mar 2009 18:39:43 -0800 (PST) Received: (qmail 39837 invoked from network); 5 Mar 2009 02:40:20 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 5 Mar 2009 02:40:20 -0000 Received: (qmail 79566 invoked from network); 5 Mar 2009 02:40:10 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Mar 2009 02:40:10 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 05 Mar 2009 03:40:09 +0100 From: Stefan Santesson To: TLS wg Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcmdI5z8f6uJVQ8Wz0el9b7N9kU1sQAGBYbY In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3319069210_2599583" Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 02:39:48 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3319069210_2599583 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable They were very fast. The draft is already available: http://tools.ietf.org/html/draft-santesson-tls-certcache-00 The name of the extension is confused in the introduction. Stefan Santesson AAA-sec.com On 3/5/09 12:47 AM, "Stefan Santesson" wrote: > As a result of the discussions we had around last IETF I have now posted = a new > =B3Fast Track=B2 inspired draft. >=20 > The name of this draft is draft-santesson-tls-certcache-00 > It will be available in a few days from the I-D repository. Until then it= can > be obtained from the staging site at: > http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.= txt >=20 > I have chosen to do a completely new draft instead of updating the old > fast-track document as I have used a very simplified approach as starting > point. > My document is limited to one new TLS extension with the sole purpose of > including a hash of a cached cert path to allow this cert path to be omit= ted > from the server Certificate message. >=20 > I submitted this draft to inject some energy into the discussion again bu= t I=B9m > not locked on the approach if there are good reasons to expand it. > Please read and provide comments. >=20 > I would like to request a small time slot on the TLS meeting agenda in Sa= n > Francisco to discuss this if possible. >=20 >=20 > Stefan Santesson > AAA-sec.com >=20 >=20 > =20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --B_3319069210_2599583 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [TLS] New "Fast-Track" draft posted
They were very fast. The draft is already available:
http:= //tools.ietf.org/html/draft-santesson-tls-certcache-00

The name of the extension is confused in the introduction.

Stefan Santesson
AAA-sec.com




On 3/5/09 12:47 AM, "Stefan Santesson" <stefans@exmsft.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>As a result of the discussions we had around las= t IETF I have now posted a new “Fast Track” inspired draft.

The name of this draft is  draft-santesson-tls-certcac= he-00
It will be available in a few days from the I-D repos= itory. Until then it can be obtained from the staging site at: ht= tp://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt

I have chosen to do a completely new draft instead of updating the old fast= -track document as I have used a very simplified approach as starting point.=
My document is limited to one new TLS extension with the sole purpose of in= cluding a hash of a cached cert path to allow this cert path to be omitted f= rom the server Certificate message.

I submitted this draft to inject some energy into the discussion again but = I’m not locked on the approach if there are good reasons to expand it.=
Please read and provide comments.

I would like to request a small time slot on the TLS meeting agenda in San = Francisco to discuss this if possible.


Stefan Santesson
AAA-sec.com

___________= ____________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls
--B_3319069210_2599583-- From housley@vigilsec.com Thu Mar 5 07:25:43 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39BD728C139 for ; Thu, 5 Mar 2009 07:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, URIBL_RHS_DOB=1.083, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EyZdzWNDdC9W for ; Thu, 5 Mar 2009 07:25:42 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id 355833A68B0 for ; Thu, 5 Mar 2009 07:25:42 -0800 (PST) Received: (qmail 24824 invoked by uid 0); 5 Mar 2009 15:19:29 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 5 Mar 2009 15:19:29 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Mar 2009 09:46:26 -0500 To: Stefan Santesson From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090305152542.355833A68B0@core3.amsl.com> Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:25:43 -0000 Stefan: I would prefer a solution that was not tied to a single one-way hash algorithm. I do not think it would add too much complexity for the extension to include a hash algorithm identifier followed by the hash value. Russ At 09:40 PM 3/4/2009, Stefan Santesson wrote: >They were very fast. The draft is already available: >http://tools.ietf.org/html/draft-santesson-tls-certcache-00 > > >The name of the extension is confused in the introduction. > >Stefan Santesson >AAA-sec.com From ekr@networkresonance.com Thu Mar 5 07:38:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A74803A6899 for ; Thu, 5 Mar 2009 07:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2FzcGmSenD5 for ; Thu, 5 Mar 2009 07:38:31 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id DCC073A6809 for ; Thu, 5 Mar 2009 07:38:31 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id CB4FD50823; Thu, 5 Mar 2009 08:01:52 -0800 (PST) Date: Thu, 05 Mar 2009 08:01:52 -0800 From: Eric Rescorla To: Mohamad Badra In-Reply-To: <20090302144726.054FC50822@romeo.rtfm.com> References: <20090228214501.E57E43A684B@core3.amsl.com> <49ABB790.9070300@isima.fr> <20090302144726.054FC50822@romeo.rtfm.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: <20090305160152.CB4FD50823@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2009 15:38:32 -0000 At Mon, 02 Mar 2009 06:47:25 -0800, Eric Rescorla wrote: > > At Mon, 02 Mar 2009 11:40:16 +0100, > Mohamad Badra wrote: > > > > Hi Eric, > > > > Section 4, version 03 said that the context length may be Zero (This text has been removed in Version 04). > > Editor error. > > > > In case the context is Zero length, does this length is omitted from the PRF input? or is it concatenated to the SecurityParameters.client_random + SecurityParameters.server_random? > The length bytes are zero. The context isn't there. It should be clear at this point that I totally screwed up and based my -04 revision off the -02 .xml, thus reverting a lot of changes. I'll be preparing another revision shortly that merges the 02-03 changes and will ask Joe to start a new last call at that time. Best, -Ekr From Martin.Rex@sap.com Thu Mar 5 09:19:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29FE028C1BC for ; Thu, 5 Mar 2009 09:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ToEYqA2cniz for ; Thu, 5 Mar 2009 09:19:19 -0800 (PST) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 22EE228C17F for ; Thu, 5 Mar 2009 09:19:18 -0800 (PST) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n25HHiwg013574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Mar 2009 18:17:44 +0100 (MET) From: Martin Rex Message-Id: <200903051717.n25HHh6x026432@fs4113.wdf.sap.corp> To: housley@vigilsec.com (Russ Housley) Date: Thu, 5 Mar 2009 18:17:43 +0100 (MET) In-Reply-To: <20090305152542.355833A68B0@core3.amsl.com> from "Russ Housley" at Mar 5, 9 09:46:26 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 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Thu, 05 Mar 2009 17:19:20 -0000 Russ Housley wrote: > > Stefan: > > I would prefer a solution that was not tied to a single one-way hash > algorithm. I do not think it would add too much complexity for the > extension to include a hash algorithm identifier followed by the hash value. Watch out, here it comes: Hash-Agility-Poisoning. :) Reminds me of ekr request at the last IETF saag meeting to use MD5 under a different name for those things that only need a hash with low probabilistic collisions rather than one with cryptographic strength. The input from previous tls@ietf.org discussions, to which Stefan refers, did not see a requirement for hash agility. In fact, I do not remember any _security_ issue being raised against using fairly static identifiers instead, only robustness and simplicity issues. Stefan: Thanks for your efforts, I really appreciate that. I hope to find some time soon to read and provide feedback. -Martin From stefans@exmsft.com Thu Mar 5 16:48:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ADDA3A6862 for ; Thu, 5 Mar 2009 16:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1kIkFLjLWPv for ; Thu, 5 Mar 2009 16:48:23 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 5CD873A67D9 for ; Thu, 5 Mar 2009 16:48:23 -0800 (PST) Received: (qmail 2141 invoked from network); 6 Mar 2009 00:49:00 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 6 Mar 2009 00:49:00 -0000 Received: (qmail 92119 invoked from network); 6 Mar 2009 00:48:50 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 6 Mar 2009 00:48:50 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Fri, 06 Mar 2009 01:48:50 +0100 From: Stefan Santesson To: , Russ Housley Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acmd9VCBntxCURlduEmF3Z5q8MGrQA== In-Reply-To: <200903051717.n25HHh6x026432@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2009 00:48:24 -0000 Russ, You are right that it is a minor addition to add a hash algorithm identifier. I have no strong opinion about this but I did, as Martin points out, follow the conclusion of previous discussions on this list. I do think that the use of hash in this protocol is comparable to use of hash with the purpose of generating identifiers in other security protocols where algorithm agility is not required. Why do you feel we should expand the protocol? /Stefan On 3/5/09 6:17 PM, "Martin Rex" wrote: > Russ Housley wrote: >> >> Stefan: >> >> I would prefer a solution that was not tied to a single one-way hash >> algorithm. I do not think it would add too much complexity for the >> extension to include a hash algorithm identifier followed by the hash value. > > Watch out, here it comes: Hash-Agility-Poisoning. :) > > Reminds me of ekr request at the last IETF saag meeting to > use MD5 under a different name for those things that only > need a hash with low probabilistic collisions rather than > one with cryptographic strength. > > The input from previous tls@ietf.org discussions, to which Stefan > refers, did not see a requirement for hash agility. In fact, > I do not remember any _security_ issue being raised against > using fairly static identifiers instead, only robustness and > simplicity issues. > > > Stefan: Thanks for your efforts, I really appreciate that. > I hope to find some time soon to read and provide feedback. > > -Martin From housley@vigilsec.com Fri Mar 6 17:02:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6418D28C152 for ; Fri, 6 Mar 2009 17:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LlukBYweVZdh for ; Fri, 6 Mar 2009 17:02:52 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [8.8.40.152]) by core3.amsl.com (Postfix) with SMTP id B01253A67B4 for ; Fri, 6 Mar 2009 17:02:50 -0800 (PST) Received: (qmail 21715 invoked by uid 0); 7 Mar 2009 01:03:13 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (96.255.144.212) by woodstock.binhost.com with SMTP; 7 Mar 2009 01:03:13 -0000 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 06 Mar 2009 19:54:22 -0500 To: Stefan Santesson From: Russ Housley In-Reply-To: References: <200903051717.n25HHh6x026432@fs4113.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090307010250.B01253A67B4@core3.amsl.com> Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 01:02:53 -0000 At some point, I believe that we will want to use a hash function other than SHA-1. We can either insert the algorithm identifier now, or we will use a different extension when that time comes. Russ At 07:48 PM 3/5/2009, Stefan Santesson wrote: >Russ, > >You are right that it is a minor addition to add a hash algorithm >identifier. I have no strong opinion about this but I did, as Martin points >out, follow the conclusion of previous discussions on this list. > >I do think that the use of hash in this protocol is comparable to use of >hash with the purpose of generating identifiers in other security protocols >where algorithm agility is not required. > >Why do you feel we should expand the protocol? > >/Stefan > > >On 3/5/09 6:17 PM, "Martin Rex" wrote: > > > Russ Housley wrote: > >> > >> Stefan: > >> > >> I would prefer a solution that was not tied to a single one-way hash > >> algorithm. I do not think it would add too much complexity for the > >> extension to include a hash algorithm identifier followed by the > hash value. > > > > Watch out, here it comes: Hash-Agility-Poisoning. :) > > > > Reminds me of ekr request at the last IETF saag meeting to > > use MD5 under a different name for those things that only > > need a hash with low probabilistic collisions rather than > > one with cryptographic strength. > > > > The input from previous tls@ietf.org discussions, to which Stefan > > refers, did not see a requirement for hash agility. In fact, > > I do not remember any _security_ issue being raised against > > using fairly static identifiers instead, only robustness and > > simplicity issues. > > > > > > Stefan: Thanks for your efforts, I really appreciate that. > > I hope to find some time soon to read and provide feedback. > > > > -Martin From mbadra@gmail.com Sat Mar 7 01:24:57 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01ED03A69C9 for ; Sat, 7 Mar 2009 01:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwjHL4WHWbey for ; Sat, 7 Mar 2009 01:24:56 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 9B3A73A6855 for ; Sat, 7 Mar 2009 01:24:55 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so558335fgb.41 for ; Sat, 07 Mar 2009 01:25:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=CRhxF8oqbaubPB31rpq4vKnJtQrKFJYeLbZipJyDNoY=; b=w909qY2LiIzTdJyRszB/aRcdTGHuKgiaIqCR06xgYrN2lsiFoEhtsMgFY++3dLaMR+ T8KGclLeCKlLV7n9Ox1XHaLkOTCqxFcRfDUHViBQZzce4TKRtdQWvAGVFpfkO5b5UroK oJA72hMim4i4KBwcos3+uyNlxpg/WDcWh20ps= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=DauxpDASsqOxkZfnis8mL7WyJmZW/BkPzEledz/3UwEb6WQQyaKR9PrJAt/qJEZbix k5evjZg7XCh5VllDuIKHNfzQkWFM/6P47f+cCJFzbiX0Qn83H9kRjpQrnLBNF2Ue8kET gDfOSH1MkJGnz9DXl9K2T4SOX6xeJiHEDhWJk= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.65.9 with SMTP id n9mr2536472fga.61.1236417926060; Sat, 07 Mar 2009 01:25:26 -0800 (PST) In-Reply-To: <20090307010250.B01253A67B4@core3.amsl.com> References: <200903051717.n25HHh6x026432@fs4113.wdf.sap.corp> <20090307010250.B01253A67B4@core3.amsl.com> Date: Sat, 7 Mar 2009 10:25:26 +0100 X-Google-Sender-Auth: 8b7dffed843a2339 Message-ID: From: Badra To: Russ Housley Content-Type: multipart/alternative; boundary=000e0cd2515246dc57046483fb38 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 09:24:57 -0000 --000e0cd2515246dc57046483fb38 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I agree with Russ, it is better to use the hash identifier now, with SHA-1 as a mandatory to implement hash function. Best regards Badra On Sat, Mar 7, 2009 at 1:54 AM, Russ Housley wrote: > At some point, I believe that we will want to use a hash function other > than SHA-1. We can either insert the algorithm identifier now, or we will > use a different extension when that time comes. > > Russ > > > At 07:48 PM 3/5/2009, Stefan Santesson wrote: > >> Russ, >> >> You are right that it is a minor addition to add a hash algorithm >> identifier. I have no strong opinion about this but I did, as Martin >> points >> out, follow the conclusion of previous discussions on this list. >> >> I do think that the use of hash in this protocol is comparable to use of >> hash with the purpose of generating identifiers in other security >> protocols >> where algorithm agility is not required. >> >> Why do you feel we should expand the protocol? >> >> /Stefan >> >> >> On 3/5/09 6:17 PM, "Martin Rex" wrote: >> >> > Russ Housley wrote: >> >> >> >> Stefan: >> >> >> >> I would prefer a solution that was not tied to a single one-way hash >> >> algorithm. I do not think it would add too much complexity for the >> >> extension to include a hash algorithm identifier followed by the hash >> value. >> > >> > Watch out, here it comes: Hash-Agility-Poisoning. :) >> > >> > Reminds me of ekr request at the last IETF saag meeting to >> > use MD5 under a different name for those things that only >> > need a hash with low probabilistic collisions rather than >> > one with cryptographic strength. >> > >> > The input from previous tls@ietf.org discussions, to which Stefan >> > refers, did not see a requirement for hash agility. In fact, >> > I do not remember any _security_ issue being raised against >> > using fairly static identifiers instead, only robustness and >> > simplicity issues. >> > >> > >> > Stefan: Thanks for your efforts, I really appreciate that. >> > I hope to find some time soon to read and provide feedback. >> > >> > -Martin >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000e0cd2515246dc57046483fb38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
I agree with Russ,=A0it is better to use the hash identifier now, with= SHA-1 as a mandatory to implement hash function.
=A0
Best regards
Badra

On Sat, Mar 7, 2009 at 1:54 AM, Russ Housley <housley@vigilsec= .com> wrote:
At some point, I believe that we= will want to use a hash function other than SHA-1. =A0We can either insert= the algorithm identifier now, or we will use a different extension when th= at time comes.

Russ=20


At 07:48 PM 3/5/2009, Stefan Santesson wrote:
Russ,

You are right that = it is a minor addition to add a hash algorithm
identifier. I have no str= ong opinion about this but I did, as Martin points
out, follow the conclusion of previous discussions on this list.

I d= o think that the use of hash in this protocol is comparable to use of
ha= sh with the purpose of generating identifiers in other security protocols where algorithm agility is not required.

Why do you feel we should e= xpand the protocol?

/Stefan


On 3/5/09 6:17 PM, "Mart= in Rex" <Ma= rtin.Rex@sap.com> wrote:

> Russ Housley wrote:
>>
>> Stefan:
>>>> I would prefer a solution that was not tied to a single one-way h= ash
>> algorithm. =A0I do not think it would add too much complexi= ty for the
>> extension to include a hash algorithm identifier followed by the h= ash value.
>
> Watch out, here it comes: Hash-Agility-Poisoning= . =A0:)
>
> Reminds me of ekr request at the last IETF saag mee= ting to
> use MD5 under a different name for those things that only
> need= a hash with low probabilistic collisions rather than
> one with cryp= tographic strength.
>
> The input from previous tls@ietf.org discussions, to which S= tefan
> refers, did not see a requirement for hash agility. =A0In fact,
>= ; I do not remember any _security_ issue being raised against
> using= fairly static identifiers instead, only robustness and
> simplicity = issues.
>
>
> Stefan: =A0Thanks for your efforts, I really appreciat= e that.
> I hope to find some time soon to read and provide feedback.=
>
> -Martin

______________________________= _________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/tls

--000e0cd2515246dc57046483fb38-- From stefans@exmsft.com Sat Mar 7 09:06:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBC13A69CD for ; Sat, 7 Mar 2009 09:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HWLJA4UUhN5 for ; Sat, 7 Mar 2009 09:06:20 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id 8FAC83A69BF for ; Sat, 7 Mar 2009 09:06:19 -0800 (PST) Received: (qmail 70851 invoked from network); 7 Mar 2009 17:06:54 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 7 Mar 2009 17:06:54 -0000 Received: (qmail 70662 invoked from network); 7 Mar 2009 17:06:47 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 7 Mar 2009 17:06:47 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sat, 07 Mar 2009 18:06:46 +0100 From: Stefan Santesson To: Badra , Russ Housley Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcmfRxiKaiqEYtCYLEGOYyJzuc1PZg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3319294007_1630798" Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 17:06:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3319294007_1630798 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I think we all should agree though that there is no security requirement to provide a strong hash here. The only reason to allow another type of hash is so we can completely move away from SHA-1 when there is no other reason to implement and use it. I don=B9t see that happen in any foreseeable future, but if we can make this more pure and remove tension by adding an identifier, that is OK with me. If this list does not strongly object, I will add an algorithm identifier i= n the next draft. Stefan Santesson AAA-sec.com On 3/7/09 10:25 AM, "Badra" wrote: > Hi, > =A0 > I agree with Russ,=A0it is better to use the hash identifier now, with SHA-= 1 as > a mandatory to implement hash function. > =A0 > Best regards > Badra >=20 > On Sat, Mar 7, 2009 at 1:54 AM, Russ Housley wrote= : >> At some point, I believe that we will want to use a hash function other = than >> SHA-1. =A0We can either insert the algorithm identifier now, or we will us= e a >> different extension when that time comes. >>=20 >> Russ=20 >>=20 >>=20 >> At 07:48 PM 3/5/2009, Stefan Santesson wrote: >>> Russ, >>>=20 >>> You are right that it is a minor addition to add a hash algorithm >>> identifier. I have no strong opinion about this but I did, as Martin po= ints >>> out, follow the conclusion of previous discussions on this list. >>>=20 >>> I do think that the use of hash in this protocol is comparable to use o= f >>> hash with the purpose of generating identifiers in other security proto= cols >>> where algorithm agility is not required. >>>=20 >>> Why do you feel we should expand the protocol? >>>=20 >>> /Stefan >>>=20 >>>=20 >>> On 3/5/09 6:17 PM, "Martin Rex" wrote: >>>=20 >>>> > Russ Housley wrote: >>>>> >> >>>>> >> Stefan: >>>>> >> >>>>> >> I would prefer a solution that was not tied to a single one-way ha= sh >>>>> >> algorithm. =A0I do not think it would add too much complexity for th= e >>>>> >> extension to include a hash algorithm identifier followed by the h= ash >>>>> value. >>>> > >>>> > Watch out, here it comes: Hash-Agility-Poisoning. =A0:) >>>> > >>>> > Reminds me of ekr request at the last IETF saag meeting to >>>> > use MD5 under a different name for those things that only >>>> > need a hash with low probabilistic collisions rather than >>>> > one with cryptographic strength. >>>> > >>>> > The input from previous tls@ietf.org discussions, to which Stefan >>>> > refers, did not see a requirement for hash agility. =A0In fact, >>>> > I do not remember any _security_ issue being raised against >>>> > using fairly static identifiers instead, only robustness and >>>> > simplicity issues. >>>> > >>>> > >>>> > Stefan: =A0Thanks for your efforts, I really appreciate that. >>>> > I hope to find some time soon to read and provide feedback. >>>> > >>>> > -Martin >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --B_3319294007_1630798 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [TLS] New "Fast-Track" draft posted I think we all should agree though that there is no security requirement t= o provide a strong hash here.
The only reason to allow another type of hash is so we can completely move = away from SHA-1 when there is no other reason to implement and use it.
I don’t see that happen in any foreseeable future, but if we can make= this more pure and remove tension by adding an identifier, that is OK with = me.

If this list does not strongly object, I will add an algorithm identifier i= n the next draft.

Stefan Santesson
AAA-sec.com






On 3/7/09 10:25 AM, "Badra" <badra@is= ima.fr> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi,
=A0
I agree with Russ,=A0it is better to use the hash identifier now, with SHA-1 = as a mandatory to implement hash function.
=A0
Best regards
Badra

On Sat, Mar 7, 2009 at 1:54 AM, Russ Housley <housley@vigilsec.com> wrote:
<= SPAN STYLE=3D'font-size:11pt'>At some point, I believe that we will want to us= e a hash function other than SHA-1. =A0We can either insert the algorithm iden= tifier now, or we will use a different extension when that time comes.

Russ


At 07:48 PM 3/5/2009, Stefan Santesson wrote:
<= SPAN STYLE=3D'font-size:11pt'>Russ,

You are right that it is a minor addition to add a hash algorithm
identifier. I have no strong opinion about this but I did, as Martin points=
out, follow the conclusion of previous discussions on this list.

I do think that the use of hash in this protocol is comparable to use of hash with the purpose of generating identifiers in other security protocols=
where algorithm agility is not required.

Why do you feel we should expand the protocol?

/Stefan


On 3/5/09 6:17 PM, "Martin Rex" <= Martin.Rex@sap.com> wrote:

> Russ Housley wrote:
>>
>> Stefan:
>>
>> I would prefer a solution that was not tied to a single one-way ha= sh
>> algorithm. =A0I do not think it would add too much complexity for th= e
>> extension to include a hash algorithm identifier followed by the h= ash value.
>
> Watch out, here it comes: Hash-Agility-Poisoning. =A0:)
>
> Reminds me of ekr request at the last IETF saag meeting to
> use MD5 under a different name for those things that only
> need a hash with low probabilistic collisions rather than
> one with cryptographic strength.
>
> The input from previous tls@ietf.org discus= sions, to which Stefan
> refers, did not see a requirement for hash agility. =A0In fact,
> I do not remember any _security_ issue being raised against
> using fairly static identifiers instead, only robustness and
> simplicity issues.
>
>
> Stefan: =A0Thanks for your efforts, I really appreciate that.
> I hope to find some time soon to read and provide feedback.
>
> -Martin
=
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls
=

___________= ____________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls
--B_3319294007_1630798-- From mike-list@pobox.com Sat Mar 7 10:22:32 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B8073A6B4C for ; Sat, 7 Mar 2009 10:22:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTk2tob0y01d for ; Sat, 7 Mar 2009 10:22:31 -0800 (PST) Received: from sasl.smtp.pobox.com (a-sasl-quonix.sasl.smtp.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 4E5073A6B2B for ; Sat, 7 Mar 2009 10:22:30 -0800 (PST) Received: from localhost.localdomain (unknown [127.0.0.1]) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTP id 1B9954576 for ; Sat, 7 Mar 2009 13:23:02 -0500 (EST) Received: from [192.168.1.8] (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-sasl-quonix.sasl.smtp.pobox.com (Postfix) with ESMTPSA id BE5624574 for ; Sat, 7 Mar 2009 13:22:59 -0500 (EST) Message-ID: <49B2BB4F.8030908@pobox.com> Date: Sat, 07 Mar 2009 10:22:07 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: TLS@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Pobox-Relay-ID: FE5F4CB2-0B44-11DE-9A7E-CBE7E3B37BAC-38729857!a-sasl-quonix.pobox.com Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:22:32 -0000 If you add hash algorithm agility, you also need to add a way for the server to specify to the client the algorithms it knows how to compute. Otherwise, if the client uses an unimplemented algorithm, the server won't be able to determine that the client has the right cached cert. and it will have to perform a normal handshake. Technically this is unneeded complexity. I like the idea of cloning MD5 or SHA-1 under a different name to be used for non-security-critical things such as this proposal. Would that be allowed under specs such as FIPS? Mike Stefan Santesson wrote: > I think we all should agree though that there is no security requiremen= t=20 > to provide a strong hash here. > The only reason to allow another type of hash is so we can completely=20 > move away from SHA-1 when there is no other reason to implement and use= it. > I don=92t see that happen in any foreseeable future, but if we can make= =20 > this more pure and remove tension by adding an identifier, that is OK=20 > with me. >=20 > If this list does not strongly object, I will add an algorithm=20 > identifier in the next draft. >=20 > *Stefan Santesson > *AAA-sec.com From paul.hoffman@vpnc.org Sat Mar 7 10:35:22 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452C33A6B55 for ; Sat, 7 Mar 2009 10:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5W5fthWrtg7x for ; Sat, 7 Mar 2009 10:35:21 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 398E03A68ED for ; Sat, 7 Mar 2009 10:35:21 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n27IZmuF059541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 7 Mar 2009 11:35:49 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090307010250.B01253A67B4@core3.amsl.com> References: <200903051717.n25HHh6x026432@fs4113.wdf.sap.corp> <20090307010250.B01253A67B4@core3.amsl.com> Date: Sat, 7 Mar 2009 10:35:47 -0800 To: Russ Housley , Stefan Santesson From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:35:22 -0000 At 7:54 PM -0500 3/6/09, Russ Housley wrote: >At some point, I believe that we will want to use a hash function other than SHA-1. We can either insert the algorithm identifier now, or we will use a different extension when that time comes. We should do the latter, not the former. With the former, we then have a negotiation that must go on between the client and the server and, as usual, this will only end in tears after a long, repetitive argument. There is essentially no exhaustion worries on the ExtensionType namespace. There is no current worry about preimage attacks on SHA-1. If someone truly wants another hash, they can define a different-yet-nearly-identical extension with a different ExtensionType. --Paul Hoffman, Director --VPN Consortium From hovav@hovav.net Sat Mar 7 10:52:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24283A6B68 for ; Sat, 7 Mar 2009 10:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naMEE2ZT0xJC for ; Sat, 7 Mar 2009 10:52:17 -0800 (PST) Received: from cse-smtp.ucsd.edu (csesmtp.ucsd.edu [132.239.51.63]) by core3.amsl.com (Postfix) with ESMTP id 08A343A6B6B for ; Sat, 7 Mar 2009 10:52:17 -0800 (PST) Received: from [192.168.1.113] (adsl-69-105-142-89.dsl.sndg02.pacbell.net [69.105.142.89]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cse-smtp.ucsd.edu (Postfix) with ESMTP id 0FED22C289 for ; Sat, 7 Mar 2009 10:52:48 -0800 (PST) Message-Id: <90DA4E04-DD41-40E6-AB94-7CDDFECEC702@hovav.net> From: Hovav Shacham To: TLS@ietf.org In-Reply-To: <49B2BB4F.8030908@pobox.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sat, 7 Mar 2009 10:52:48 -0800 References: <49B2BB4F.8030908@pobox.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 18:52:17 -0000 On Mar 7, 2009, at 10:22 AM, Michael D'Errico wrote: > If you add hash algorithm agility, you also need to add a way for the > server to specify to the client the algorithms it knows how to > compute. > Otherwise, if the client uses an unimplemented algorithm, the server > won't be able to determine that the client has the right cached cert. > and it will have to perform a normal handshake. I agree with this. I'd prefer we stick to just SHA-1. (Or just SHA-256?) -hs. From jwkckid1@ix.netcom.com Sat Mar 7 11:38:12 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C13B13A6B25 for ; Sat, 7 Mar 2009 11:38:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_40=-0.185, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jkEgGvsWvHf for ; Sat, 7 Mar 2009 11:38:12 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 21D5728C1C1 for ; Sat, 7 Mar 2009 11:38:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=ZQRKX0Cs2rzBdV04YsZJMs9+SuE2aW4DbrlqbAnBY8kRYmLsbRn5LqnImNvVMAiT; 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.227.102.114] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Lg2M5-0000Zs-Ui; Sat, 07 Mar 2009 14:38:42 -0500 Message-ID: <49B1952C.F1687FA5@ix.netcom.com> Date: Fri, 06 Mar 2009 13:27:08 -0800 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael D'Errico References: <49B2BB4F.8030908@pobox.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b12495e52fbe5142ff9c0a4f6c7238cd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.102.114 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 19:38:12 -0000 Michael and all, MD5 fine, SHA-1, not so fine. Better would be SHA-2. Just my 2 cents... Michael D'Errico wrote: > If you add hash algorithm agility, you also need to add a way for the > server to specify to the client the algorithms it knows how to compute. > Otherwise, if the client uses an unimplemented algorithm, the server > won't be able to determine that the client has the right cached cert. > and it will have to perform a normal handshake. > > Technically this is unneeded complexity. I like the idea of cloning > MD5 or SHA-1 under a different name to be used for non-security-critical > things such as this proposal. Would that be allowed under specs such as > FIPS? > > Mike > > Stefan Santesson wrote: > > I think we all should agree though that there is no security requirement > > to provide a strong hash here. > > The only reason to allow another type of hash is so we can completely > > move away from SHA-1 when there is no other reason to implement and use it. > > I don’t see that happen in any foreseeable future, but if we can make > > this more pure and remove tension by adding an identifier, that is OK > > with me. > > > > If this list does not strongly object, I will add an algorithm > > identifier in the next draft. > > > > *Stefan Santesson > > *AAA-sec.com > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 From yaronf@checkpoint.com Sat Mar 7 12:29:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B2A28C0E2 for ; Sat, 7 Mar 2009 12:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.334 X-Spam-Level: X-Spam-Status: No, score=-3.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB1cFHbixM5V for ; Sat, 7 Mar 2009 12:29:25 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 748483A6AA6 for ; Sat, 7 Mar 2009 12:29:25 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n27KTj16027217; Sat, 7 Mar 2009 22:29:45 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sat, 7 Mar 2009 22:29:45 +0200 From: Yaron Sheffer To: "Jeffrey A. Williams" , "Michael D'Errico" Date: Sat, 7 Mar 2009 22:29:47 +0200 Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcmfX3cpmLduhW4iSD+JzfICscBQegAAvB+g Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F006@il-ex01.ad.checkpoint.com> References: <49B2BB4F.8030908@pobox.com> <49B1952C.F1687FA5@ix.netcom.com> In-Reply-To: <49B1952C.F1687FA5@ix.netcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01C99F74.38C7CA10" MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 20:29:26 -0000 ------=_NextPart_000_0016_01C99F74.38C7CA10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The test of non-security critical hashes is whether they can be replaced by CRC, right? So why not really use CRC32 (or CRC64) and avoid this discussion altogether? The reason "because we've been using MD5 to 'sign' files for ages" is not very good. BTW, this seems to be Eric's conclusion in his SAAG presentation. Thanks, Yaron > -----Original Message----- > From: Jeffrey A. Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Friday, March 06, 2009 23:27 > To: Michael D'Errico > Cc: TLS@ietf.org > Subject: Re: [TLS] New "Fast-Track" draft posted > > Michael and all, > > MD5 fine, SHA-1, not so fine. Better would be SHA-2. > Just my 2 cents... > > Michael D'Errico wrote: > > > If you add hash algorithm agility, you also need to add a way for the > > server to specify to the client the algorithms it knows how to compute. > > Otherwise, if the client uses an unimplemented algorithm, the server > > won't be able to determine that the client has the right cached cert. > > and it will have to perform a normal handshake. > > > > Technically this is unneeded complexity. I like the idea of cloning > > MD5 or SHA-1 under a different name to be used for non-security-critical > > things such as this proposal. Would that be allowed under specs such as > > FIPS? > > > > Mike > > > > Stefan Santesson wrote: > > > I think we all should agree though that there is no security > requirement > > > to provide a strong hash here. > > > The only reason to allow another type of hash is so we can completely > > > move away from SHA-1 when there is no other reason to implement and > use it. > > > I don't see that happen in any foreseeable future, but if we can make > > > this more pure and remove tension by adding an identifier, that is OK > > > with me. > > > > > > If this list does not strongly object, I will add an algorithm > > > identifier in the next draft. > > > > > > *Stefan Santesson > > > *AAA-sec.com > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > Regards, > > Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > "YES WE CAN!" Barack ( Berry ) Obama > > "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 > > > ------=_NextPart_000_0016_01C99F74.38C7CA10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMwNzIwMjk0N1owIwYJKoZIhvcNAQkEMRYEFI49fqS3RMbC HX2te+vcQlOVk1gkMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA NyxLfqcSSNyCK00oZRlxM5d2HylCc3HAjXk/7HQAhuuHmVv4EnCoflhDq9HXBsMGRj/YEA7ZZR69 zTaAKNOF6nOwj8CJf3uH5JL+Nr8zuYGnyjeVRvsmfPHGxEdWSqwnKZc7+fF3e/lPdiJnwyG00vGX Ui+lYZ1Hixlg5dWp63X+PRpI74dNcmVH7rA07FNmQA8ETa3hgTa1Yw4WNPbzsBpFGp/Ph9+9d7W0 QGMxRKLs2lyLiEx2Lo7w/B9gvzPBe1eSDGjYlbXSvAtKMltTORX2QOKOAfvd7uhcYSEJegpq7xRQ qv+umjxPMpSRxNXHV/GZw4vWdrlZbriOjEFxQgAAAAAAAA== ------=_NextPart_000_0016_01C99F74.38C7CA10-- From ekr@networkresonance.com Sat Mar 7 14:36:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958F83A69CB for ; Sat, 7 Mar 2009 14:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt+aqLDgDQtP for ; Sat, 7 Mar 2009 14:36:08 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id D24DF3A6923 for ; Sat, 7 Mar 2009 14:36:08 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 0999350822; Sat, 7 Mar 2009 14:59:33 -0800 (PST) Date: Sat, 07 Mar 2009 14:59:33 -0800 From: Eric Rescorla To: Mohamad Badra In-Reply-To: <20090305160152.CB4FD50823@romeo.rtfm.com> References: <20090228214501.E57E43A684B@core3.amsl.com> <49ABB790.9070300@isima.fr> <20090302144726.054FC50822@romeo.rtfm.com> <20090305160152.CB4FD50823@romeo.rtfm.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: <20090307225933.0999350822@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:36:09 -0000 At Thu, 05 Mar 2009 08:01:52 -0800, Eric Rescorla wrote: > > At Mon, 02 Mar 2009 06:47:25 -0800, > Eric Rescorla wrote: > > > > At Mon, 02 Mar 2009 11:40:16 +0100, > > Mohamad Badra wrote: > > > > > > Hi Eric, > > > > > > Section 4, version 03 said that the context length may be Zero (This text has been removed in Version 04). > > > > Editor error. > > > > > > > In case the context is Zero length, does this length is omitted from the PRF input? or is it concatenated to the SecurityParameters.client_random + SecurityParameters.server_random? > > The length bytes are zero. The context isn't there. > > It should be clear at this point that I totally screwed up > and based my -04 revision off the -02 .xml, thus reverting > a lot of changes. I'll be preparing another revision > shortly that merges the 02-03 changes and will ask Joe to > start a new last call at that time. OK, I believe I've unscrewed this and submitted -05. Please let me know if people think this is still hosed. -Ekr From root@core3.amsl.com Sat Mar 7 14:45:02 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 16E9C3A67D6; Sat, 7 Mar 2009 14:45:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307224502.16E9C3A67D6@core3.amsl.com> Date: Sat, 7 Mar 2009 14:45:02 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 22:45:02 -0000 --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 Exporters for Transport Layer Security (TLS) Author(s) : E. Rescorla Filename : draft-ietf-tls-extractor-05.txt Pages : 7 Date : 2009-03-07 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tls-extractor-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07143451.I-D@ietf.org> --NextPart-- From ekr@networkresonance.com Sat Mar 7 15:04:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62AAA3A67A7 for ; Sat, 7 Mar 2009 15:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXZcOhWYcm9X for ; Sat, 7 Mar 2009 15:04:19 -0800 (PST) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id AB2F03A67F9 for ; Sat, 7 Mar 2009 15:04:19 -0800 (PST) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id CFC2150822 for ; Sat, 7 Mar 2009 15:27:43 -0800 (PST) Date: Sat, 07 Mar 2009 15:27:43 -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: <20090307232743.CFC2150822@romeo.rtfm.com> Subject: [TLS] New DTLS Document X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:04:20 -0000 OK, I've submitted a new version of DTLS that I think addresses the editorial issues raised by Michael and Robin. Can you guys take a look and let me know if you think I've missed anything? Anyone else? Thanks, -Ekr From root@core3.amsl.com Sat Mar 7 15:15:01 2009 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E15A73A67F9; Sat, 7 Mar 2009 15:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090307231501.E15A73A67F9@core3.amsl.com> Date: Sat, 7 Mar 2009 15:15:01 -0800 (PST) Cc: tls@ietf.org Subject: [TLS] I-D Action:draft-ietf-tls-rfc4347-bis-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:15:02 -0000 --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 : Datagram Transport Layer Security version 1.2 Author(s) : E. Rescorla, N. Modadugu Filename : draft-ietf-tls-rfc4347-bis-02.txt Pages : 28 Date : 2009-03-07 This document specifies Version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4347-bis-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-tls-rfc4347-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-03-07150327.I-D@ietf.org> --NextPart-- From mbadra@gmail.com Sat Mar 7 15:20:15 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55213A67D6 for ; Sat, 7 Mar 2009 15:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVhEVIif2bgl for ; Sat, 7 Mar 2009 15:20:15 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by core3.amsl.com (Postfix) with ESMTP id 8DCAC3A6A95 for ; Sat, 7 Mar 2009 15:20:14 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id l26so598633fgb.41 for ; Sat, 07 Mar 2009 15:20:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=fYi8VG3vA+hQEeMuUbt6w3iWUIO51LMDwHqwrcJkx+s=; b=nv0Go7NK7VHHB33M1OFUePbbjBvm69A7aPmTMNYh1+QaawKVZ+PLVmCbVmXZtHO4Xd /knW69jwiAzfV/u+1Ptv/Oe2b9qz5Q1DGB6uHvX3J3JOObI4zaciQpGVBld4d/2Dy6a/ B4noyJWL+/I+YLMENlAk+FioknfySpHF65J6g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=bHCwdpoYyQ1bm9rb56CtYQhu08nP1MgLivNWPCt6oOjs0Jjwo6bwc7qpxovb8Xg82f NUhoK4TeGYouNOrIVUhaso3skwf/lCNtd7Z2yahVFbIaXMjp43Ui15Ku7sCA68/a3gm5 A9LuW+cVOAXnLjUJ1LL6WPd4EEz2uJ1MrSD0E= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.60.14 with SMTP id i14mr2909871fga.69.1236468046081; Sat, 07 Mar 2009 15:20:46 -0800 (PST) In-Reply-To: <20090307225933.0999350822@romeo.rtfm.com> References: <20090228214501.E57E43A684B@core3.amsl.com> <49ABB790.9070300@isima.fr> <20090302144726.054FC50822@romeo.rtfm.com> <20090305160152.CB4FD50823@romeo.rtfm.com> <20090307225933.0999350822@romeo.rtfm.com> Date: Sun, 8 Mar 2009 00:20:46 +0100 X-Google-Sender-Auth: ec470ca127db4952 Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=000e0cd34146a9b14004648fa65a Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:20:15 -0000 --000e0cd34146a9b14004648fa65a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Eric, Version 05 is fine for me. But some nits are reported but can be addressed in a future revision (see http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-tls-extractor-05.txt ) ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) ** Downref: Normative reference to an Informational RFC: RFC 5281 Beest regards, Badra On Sat, Mar 7, 2009 at 11:59 PM, Eric Rescorla wrote: > > > OK, I believe I've unscrewed this and submitted -05. Please > let me know if people think this is still hosed. > > -Ekr > --000e0cd34146a9b14004648fa65a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,
=A0
Version 05 is fine for me. But some nits are reported but can be addre= ssed in a future revision (see http://tools.i= etf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft-ietf-tls-extractor-05.t= xt)
=A0
=A0 ** Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216)<= br>
=A0 ** Downref: Normative reference to an Informational RFC: RFC 528= 1
Beest regards,
Badra

On Sat, Mar 7, 2009 at 11:59 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@networ= kresonance.com> wrote:

=A0
OK, I believe I've unscrewed this = and submitted -05. Please
let me know if people think this is still hose= d.

-Ekr

--000e0cd34146a9b14004648fa65a-- From mbadra@gmail.com Sat Mar 7 15:23:14 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AA613A6874 for ; Sat, 7 Mar 2009 15:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoeM1YGCQ0lq for ; Sat, 7 Mar 2009 15:23:13 -0800 (PST) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 27EDF3A67D6 for ; Sat, 7 Mar 2009 15:23:13 -0800 (PST) Received: by fxm24 with SMTP id 24so809535fxm.37 for ; Sat, 07 Mar 2009 15:23:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=/UHSCdOLFjtcEv0xMWbxptqmX/4vHXqlmJu7FbgN3gU=; b=UIodrmE/NrzRHDRpAREjnU0mX/TBCnHaLPSxhvJil/W3hClVhwrOAJbMErAYWkgwyu Sjd+u+DeZcb3fR12WKssYmgs+eac6OfvCBW6RJ0Oq98m4xFP+Vt6ZlDZ7w6KdVWlnkzU DAMLjBLUp3/uRgChUZg/LS4T9GYwuTHt1f8xM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=dkG6sOOcz6WJyhK8MxeR+Xek+xT6KvrlaqWMz/ttGLdW/FwSwZHBdwXKYxSu+WHp7U q4BhL8bkXp3S885N+gAPFnUeuUx6IcNs8u3S/C3P+vZS4p+4rCoYtZv54eghUDTJLUlT oBFFlsk4k57Ix3S8VbTcLrwirZIP7WXPstmT8= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.96.18 with SMTP id t18mr2946505fgb.25.1236468224782; Sat, 07 Mar 2009 15:23:44 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Mar 2009 00:23:44 +0100 X-Google-Sender-Auth: 31fd4ceef0511c44 Message-ID: From: Badra To: Michael.G.Williams@nokia.com Content-Type: multipart/alternative; boundary=000e0cd286805071aa04648fb1b5 Cc: TLS@ietf.org Subject: Re: [TLS] New Version Notification for draft-barrett-mobile-dtls-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2009 23:23:14 -0000 --000e0cd286805071aa04648fb1b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Michael, Cannot DTLS/TLS clients establish a full handshake using a first IP address and then resume the same session using a second IP address? Best regards, Badra On Thu, Mar 5, 2009 at 12:18 AM, wrote: > Hi All, > > Jeremey and I have created a new I-D for consideration by the TLS WG. Your > comments are more than welcome. > > Kind Regards, > Michael > -----Original Message----- > From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: 04 March, 2009 15:01 > To: Barrett Jeremey (Nokia-S/MtView) > Cc: Williams Michael.G (Nokia-CIC/Dallas) > Subject: New Version Notification for draft-barrett-mobile-dtls-00 > > > A new version of I-D, draft-barrett-mobile-dtls-00.txt has been successfuly > submitted by Jeremey Barrett and posted to the IETF repository. > > Filename: draft-barrett-mobile-dtls > Revision: 00 > Title: Mobile DTLS > Creation_date: 2009-03-04 > WG ID: Independent Submission > Number_of_pages: 12 > > Abstract: > Mobile DTLS (Mobi-D) is an extension to DTLS that provides host mobility > support. After obtaining a new IP address or port, a DTLS client mobile > host can continue sending to its DTLS server correspondent host. The mobile > host continues to use the existing set of security parameters, from the new > address, without re- negotiation. The correspondent host accepts packets > from the new IP address or port, also without re-negotiation. After > receiving any valid DTLS packet from the mobile host's new address or port, > the correspondent host uses the new address or port to send to the mobile > host. > > > > The IETF Secretariat. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000e0cd286805071aa04648fb1b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,
=A0
Cannot DTLS/TLS clients establish a full handshake using a firs= t IP address and then resume the same session using a second IP address?
Best regards,
Badra
=A0
On Thu, Mar 5, 2009 at 12:18 AM, <Michael.G.Williams@n= okia.com> wrote:
Hi All,

Jeremey and I hav= e created a new I-D for consideration by the TLS WG. Your comments are more= than welcome.

Kind Regards,
Michael
-----Original Message-----
From: ext IET= F I-D Submission Tool [mailto:idsu= bmission@ietf.org]
Sent: 04 March, 2009 15:01
To: Barrett Jeremey= (Nokia-S/MtView)
Cc: Williams Michael.G (Nokia-CIC/Dallas)
Subject: New Version Notificat= ion for draft-barrett-mobile-dtls-00


A new version of I-D, draft= -barrett-mobile-dtls-00.txt has been successfuly submitted by Jeremey Barre= tt and posted to the IETF repository.

Filename: =A0 =A0 =A0 =A0draft-barrett-mobile-dtls
Revision: =A0 =A0= =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Mobile DTLS
Creation_date: =A0 = 2009-03-04
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_o= f_pages: 12

Abstract:
Mobile DTLS (Mobi-D) is an extension to DTL= S that provides host mobility support. =A0After obtaining a new IP address = or port, a DTLS client mobile host can continue sending to its DTLS server = correspondent host. =A0The mobile host continues to use the existing set of= security parameters, from the new address, without re- negotiation. =A0The= correspondent host accepts packets from the new IP address or port, also w= ithout re-negotiation. =A0After receiving any valid DTLS packet from the mo= bile host's new address or port, the correspondent host uses the new ad= dress or port to send to the mobile host.



The IETF Secretariat.


______________________________= _________________
TLS mailing list
TL= S@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--000e0cd286805071aa04648fb1b5-- From ynir@checkpoint.com Sat Mar 7 23:53:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 305043A6BEE for ; Sat, 7 Mar 2009 23:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9nBgMGwwwqI for ; Sat, 7 Mar 2009 23:53:10 -0800 (PST) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7ADE13A68D1 for ; Sat, 7 Mar 2009 23:52:54 -0800 (PST) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 119BF2CC003; Sun, 8 Mar 2009 09:53:26 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 63D072CC002; Sun, 8 Mar 2009 09:53:24 +0200 (IST) X-CheckPoint: {49B378DC-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n287rN16028952; Sun, 8 Mar 2009 09:53:24 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Sun, 8 Mar 2009 09:53:23 +0200 From: Yoav Nir To: Yaron Sheffer , "Jeffrey A. Williams" , "Michael D'Errico" Date: Sun, 8 Mar 2009 09:53:52 +0200 Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcmfX3cpmLduhW4iSD+JzfICscBQegAAvB+gABe6YBA= Message-ID: <9FB7C7CE79B84449B52622B506C78036133299EDE3@il-ex01.ad.checkpoint.com> References: <49B2BB4F.8030908@pobox.com> <49B1952C.F1687FA5@ix.netcom.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F006@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F006@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 07:53:16 -0000 As long as the server (and all co-located virtual servers) is expected to h= ave less than 64K certificates, CRC32 is probably good enough. > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 > Behalf Of Yaron Sheffer > Sent: Saturday, March 07, 2009 10:30 PM > To: Jeffrey A. Williams; Michael D'Errico > Cc: TLS@ietf.org > Subject: Re: [TLS] New "Fast-Track" draft posted >=20 > The test of non-security critical hashes is whether they can=20 > be replaced by CRC, right? So why not really use CRC32 (or=20 > CRC64) and avoid this discussion altogether? The reason=20 > "because we've been using MD5 to 'sign' files for ages" is=20 > not very good. >=20 > BTW, this seems to be Eric's conclusion in his SAAG presentation. >=20 > Thanks, > Yaron >=20 > > -----Original Message----- > > From: Jeffrey A. Williams [mailto:jwkckid1@ix.netcom.com] > > Sent: Friday, March 06, 2009 23:27 > > To: Michael D'Errico > > Cc: TLS@ietf.org > > Subject: Re: [TLS] New "Fast-Track" draft posted > >=20 > > Michael and all, > >=20 > > MD5 fine, SHA-1, not so fine. Better would be SHA-2. > > Just my 2 cents... > >=20 > > Michael D'Errico wrote: > >=20 > > > If you add hash algorithm agility, you also need to add a way for=20 > > > the server to specify to the client the algorithms it=20 > knows how to compute. > > > Otherwise, if the client uses an unimplemented algorithm,=20 > the server=20 > > > won't be able to determine that the client has the right=20 > cached cert. > > > and it will have to perform a normal handshake. > > > > > > Technically this is unneeded complexity. I like the idea=20 > of cloning > > > MD5 or SHA-1 under a different name to be used for=20 > > > non-security-critical things such as this proposal. =20 > Would that be=20 > > > allowed under specs such as FIPS? > > > > > > Mike > > > > > > Stefan Santesson wrote: > > > > I think we all should agree though that there is no security > > requirement > > > > to provide a strong hash here. > > > > The only reason to allow another type of hash is so we can=20 > > > > completely move away from SHA-1 when there is no other=20 > reason to=20 > > > > implement and > > use it. > > > > I don't see that happen in any foreseeable future, but=20 > if we can=20 > > > > make this more pure and remove tension by adding an identifier,=20 > > > > that is OK with me. > > > > > > > > If this list does not strongly object, I will add an algorithm=20 > > > > identifier in the next draft. > > > > > > > > *Stefan Santesson > > > > *AAA-sec.com > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > >=20 > > Regards, > >=20 > > Spokesman for INEGroup LLA. - (Over 284k=20 > members/stakeholders strong!)=20 > > "Obedience of the law is the greatest freedom" - > > Abraham Lincoln > > "YES WE CAN!" Barack ( Berry ) Obama > >=20 > > "Credit should go with the performance of duty and not with what is=20 > > very often the accident of glory" - Theodore Roosevelt > >=20 > > "If the probability be called P; the injury, L; and the burden, B;=20 > > 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]=20 > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > 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=20 > > jwkckid1@ix.netcom.com My Phone: 214-244-4827 > >=20 > >=20 > >=20 >=20 > = Email secured by Check Point From stefans@exmsft.com Sun Mar 8 06:16:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183033A6942 for ; Sun, 8 Mar 2009 06:16:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Na1XaQJ0bFH5 for ; Sun, 8 Mar 2009 06:16:16 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id A4C393A6955 for ; Sun, 8 Mar 2009 06:16:15 -0700 (PDT) Received: (qmail 78620 invoked from network); 8 Mar 2009 13:16:50 -0000 Received: from s34.loopia.se (HELO s57.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 8 Mar 2009 13:16:50 -0000 Received: (qmail 93244 invoked from network); 8 Mar 2009 13:16:45 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s57.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 8 Mar 2009 13:16:45 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Sun, 08 Mar 2009 14:16:44 +0100 From: Stefan Santesson To: Michael D'Errico , Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: Acmf8CBSoYpLDVK5d0WCLX/WNBRRYw== In-Reply-To: <49B2BB4F.8030908@pobox.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 13:16:17 -0000 Without advocating for hash agility here, I do have to disagree that you NEED to add hash support negotiation just because you add an identifier. The only thing that will happen if the server is not capable of computing a hash of the kind used by the client, is that it will be forced to decline this optimization and send the full server cert path. A middle way is to add an identifier and say MUST support SHA-1 and MAY support other hash algorithms according to local policy. I definitely would like to avoid any kind of negotiation. Both other option= s are fine with me. /Stefan On 3/7/09 7:22 PM, "Michael D'Errico" wrote: > If you add hash algorithm agility, you also need to add a way for the > server to specify to the client the algorithms it knows how to compute. > Otherwise, if the client uses an unimplemented algorithm, the server > won't be able to determine that the client has the right cached cert. > and it will have to perform a normal handshake. >=20 > Technically this is unneeded complexity. I like the idea of cloning > MD5 or SHA-1 under a different name to be used for non-security-critical > things such as this proposal. Would that be allowed under specs such as > FIPS? >=20 > Mike >=20 >=20 > Stefan Santesson wrote: >> I think we all should agree though that there is no security requirement >> to provide a strong hash here. >> The only reason to allow another type of hash is so we can completely >> move away from SHA-1 when there is no other reason to implement and use = it. >> I don=B9t see that happen in any foreseeable future, but if we can make >> this more pure and remove tension by adding an identifier, that is OK >> with me. >>=20 >> If this list does not strongly object, I will add an algorithm >> identifier in the next draft. >>=20 >> *Stefan Santesson >> *AAA-sec.com >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jwkckid1@ix.netcom.com Sun Mar 8 13:24:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2FC23A6860 for ; Sun, 8 Mar 2009 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=1.587, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MKmWz61zA38 for ; Sun, 8 Mar 2009 13:24:51 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id BDD443A6B30 for ; Sun, 8 Mar 2009 13:24:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mpHC0rLk2Efyly/seAXhxcxJcHnRdzgPMY75lc7Ts2qbowV9/sxGPjGMGPZU7aYS; 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.227.96.246] (helo=ix.netcom.com) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LgPYo-0004hB-PC; Sun, 08 Mar 2009 16:25:23 -0400 Message-ID: <49B2F192.1939631C@ix.netcom.com> Date: Sat, 07 Mar 2009 14:13:39 -0800 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Yoav Nir References: <49B2BB4F.8030908@pobox.com> <49B1952C.F1687FA5@ix.netcom.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F006@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036133299EDE3@il-ex01.ad.checkpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688dd6d50d7ade3342171ad7d64b21af56c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.246 Cc: "TLS@ietf.org" , Yaron Sheffer Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 20:24:53 -0000 Yoav and all, With all due respect, I disagree. Again just my 2 cents... Yoav Nir wrote: > As long as the server (and all co-located virtual servers) is expected to have less than 64K certificates, CRC32 is probably good enough. > > > -----Original Message----- > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > > Behalf Of Yaron Sheffer > > Sent: Saturday, March 07, 2009 10:30 PM > > To: Jeffrey A. Williams; Michael D'Errico > > Cc: TLS@ietf.org > > Subject: Re: [TLS] New "Fast-Track" draft posted > > > > The test of non-security critical hashes is whether they can > > be replaced by CRC, right? So why not really use CRC32 (or > > CRC64) and avoid this discussion altogether? The reason > > "because we've been using MD5 to 'sign' files for ages" is > > not very good. > > > > BTW, this seems to be Eric's conclusion in his SAAG presentation. > > > > Thanks, > > Yaron > > > > > -----Original Message----- > > > From: Jeffrey A. Williams [mailto:jwkckid1@ix.netcom.com] > > > Sent: Friday, March 06, 2009 23:27 > > > To: Michael D'Errico > > > Cc: TLS@ietf.org > > > Subject: Re: [TLS] New "Fast-Track" draft posted > > > > > > Michael and all, > > > > > > MD5 fine, SHA-1, not so fine. Better would be SHA-2. > > > Just my 2 cents... > > > > > > Michael D'Errico wrote: > > > > > > > If you add hash algorithm agility, you also need to add a way for > > > > the server to specify to the client the algorithms it > > knows how to compute. > > > > Otherwise, if the client uses an unimplemented algorithm, > > the server > > > > won't be able to determine that the client has the right > > cached cert. > > > > and it will have to perform a normal handshake. > > > > > > > > Technically this is unneeded complexity. I like the idea > > of cloning > > > > MD5 or SHA-1 under a different name to be used for > > > > non-security-critical things such as this proposal. > > Would that be > > > > allowed under specs such as FIPS? > > > > > > > > Mike > > > > > > > > Stefan Santesson wrote: > > > > > I think we all should agree though that there is no security > > > requirement > > > > > to provide a strong hash here. > > > > > The only reason to allow another type of hash is so we can > > > > > completely move away from SHA-1 when there is no other > > reason to > > > > > implement and > > > use it. > > > > > I don't see that happen in any foreseeable future, but > > if we can > > > > > make this more pure and remove tension by adding an identifier, > > > > > that is OK with me. > > > > > > > > > > If this list does not strongly object, I will add an algorithm > > > > > identifier in the next draft. > > > > > > > > > > *Stefan Santesson > > > > > *AAA-sec.com > > > > > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > Regards, > > > > > > Spokesman for INEGroup LLA. - (Over 284k > > members/stakeholders strong!) > > > "Obedience of the law is the greatest freedom" - > > > Abraham Lincoln > > > "YES WE CAN!" Barack ( Berry ) Obama > > > > > > "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 > > > > > > > > > > > > > > Email secured by Check Point Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 From jwkckid1@ix.netcom.com Sun Mar 8 13:31:01 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4666A3A6860 for ; Sun, 8 Mar 2009 13:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[AWL=1.530, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1nDEE8hY1Bg for ; Sun, 8 Mar 2009 13:31:00 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 26DF93A67A3 for ; Sun, 8 Mar 2009 13:31:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=pyKn1Rw2iwABRkJPyEQmE7Ai9QTQ2vDzu+k/DdZ7X5SkWfe/oGiHA+I+1aQxvGLo; 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.227.96.246] (helo=ix.netcom.com) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1LgPel-0000Kc-Si; Sun, 08 Mar 2009 16:31:32 -0400 Message-ID: <49B2F308.11738A38@ix.netcom.com> Date: Sat, 07 Mar 2009 14:19:53 -0800 From: "Jeffrey A. Williams" Organization: IDNS and Spokesman for INEGroup X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Stefan Santesson References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e5196068843f3c10ef03f58a8e8c846189ff6b7c2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.227.96.246 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 20:31:01 -0000 Stefan and all, As a matter of policy and interoperability I disagree with your choice of "Middle Way" as such would localize acceptance. Such is not a good thing, IMHO. Stefan Santesson wrote: > Without advocating for hash agility here, I do have to disagree that you > NEED to add hash support negotiation just because you add an identifier. > > The only thing that will happen if the server is not capable of computing a > hash of the kind used by the client, is that it will be forced to decline > this optimization and send the full server cert path. > > A middle way is to add an identifier and say MUST support SHA-1 and MAY > support other hash algorithms according to local policy. > > I definitely would like to avoid any kind of negotiation. Both other options > are fine with me. > > /Stefan > > On 3/7/09 7:22 PM, "Michael D'Errico" wrote: > > > If you add hash algorithm agility, you also need to add a way for the > > server to specify to the client the algorithms it knows how to compute. > > Otherwise, if the client uses an unimplemented algorithm, the server > > won't be able to determine that the client has the right cached cert. > > and it will have to perform a normal handshake. > > > > Technically this is unneeded complexity. I like the idea of cloning > > MD5 or SHA-1 under a different name to be used for non-security-critical > > things such as this proposal. Would that be allowed under specs such as > > FIPS? > > > > Mike > > > > > > Stefan Santesson wrote: > >> I think we all should agree though that there is no security requirement > >> to provide a strong hash here. > >> The only reason to allow another type of hash is so we can completely > >> move away from SHA-1 when there is no other reason to implement and use it. > >> I don¹t see that happen in any foreseeable future, but if we can make > >> this more pure and remove tension by adding an identifier, that is OK > >> with me. > >> > >> If this list does not strongly object, I will add an algorithm > >> identifier in the next draft. > >> > >> *Stefan Santesson > >> *AAA-sec.com > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 From yaronf@checkpoint.com Sun Mar 8 15:11:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BDB728C193 for ; Sun, 8 Mar 2009 15:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.835 X-Spam-Level: X-Spam-Status: No, score=-2.835 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsmfRYlaEjkM for ; Sun, 8 Mar 2009 15:11:03 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 58BDA28C104 for ; Sun, 8 Mar 2009 15:11:02 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A50292CC003; Mon, 9 Mar 2009 00:11:34 +0200 (IST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 65DC12CC001; Mon, 9 Mar 2009 00:11:33 +0200 (IST) X-CheckPoint: {49B441F2-0-88241DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n28MBW16029868; Mon, 9 Mar 2009 00:11:33 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 9 Mar 2009 00:11:32 +0200 From: Yaron Sheffer To: "Jeffrey A. Williams" , Yoav Nir Date: Mon, 9 Mar 2009 00:11:32 +0200 Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcmgLAU63J9HgYMnQ/mxz61yLJ76VwADn93Q Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F129@il-ex01.ad.checkpoint.com> References: <49B2BB4F.8030908@pobox.com> <49B1952C.F1687FA5@ix.netcom.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8D9A7D2F006@il-ex01.ad.checkpoint.com> <9FB7C7CE79B84449B52622B506C78036133299EDE3@il-ex01.ad.checkpoint.com> <49B2F192.1939631C@ix.netcom.com> In-Reply-To: <49B2F192.1939631C@ix.netcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0000_01C9A04B.98C1F850" MIME-Version: 1.0 Cc: "TLS@ietf.org" Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 22:11:04 -0000 ------=_NextPart_000_0000_01C9A04B.98C1F850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit An explanation, based on a threat model, would be much appreciated. Thanks, Yaron > -----Original Message----- > From: Jeffrey A. Williams [mailto:jwkckid1@ix.netcom.com] > Sent: Sunday, March 08, 2009 0:14 > To: Yoav Nir > Cc: Yaron Sheffer; Michael D'Errico; TLS@ietf.org > Subject: Re: [TLS] New "Fast-Track" draft posted > > Yoav and all, > > With all due respect, I disagree. Again just my 2 cents... > > Yoav Nir wrote: > > > As long as the server (and all co-located virtual servers) is expected > to have less than 64K certificates, CRC32 is probably good enough. > > > > > -----Original Message----- > > > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On > > > Behalf Of Yaron Sheffer > > > Sent: Saturday, March 07, 2009 10:30 PM > > > To: Jeffrey A. Williams; Michael D'Errico > > > Cc: TLS@ietf.org > > > Subject: Re: [TLS] New "Fast-Track" draft posted > > > > > > The test of non-security critical hashes is whether they can > > > be replaced by CRC, right? So why not really use CRC32 (or > > > CRC64) and avoid this discussion altogether? The reason > > > "because we've been using MD5 to 'sign' files for ages" is > > > not very good. > > > > > > BTW, this seems to be Eric's conclusion in his SAAG presentation. > > > > > > Thanks, > > > Yaron > > > > > > > -----Original Message----- > > > > From: Jeffrey A. Williams [mailto:jwkckid1@ix.netcom.com] > > > > Sent: Friday, March 06, 2009 23:27 > > > > To: Michael D'Errico > > > > Cc: TLS@ietf.org > > > > Subject: Re: [TLS] New "Fast-Track" draft posted > > > > > > > > Michael and all, > > > > > > > > MD5 fine, SHA-1, not so fine. Better would be SHA-2. > > > > Just my 2 cents... > > > > > > > > Michael D'Errico wrote: > > > > > > > > > If you add hash algorithm agility, you also need to add a way for > > > > > the server to specify to the client the algorithms it > > > knows how to compute. > > > > > Otherwise, if the client uses an unimplemented algorithm, > > > the server > > > > > won't be able to determine that the client has the right > > > cached cert. > > > > > and it will have to perform a normal handshake. > > > > > > > > > > Technically this is unneeded complexity. I like the idea > > > of cloning > > > > > MD5 or SHA-1 under a different name to be used for > > > > > non-security-critical things such as this proposal. > > > Would that be > > > > > allowed under specs such as FIPS? > > > > > > > > > > Mike > > > > > > > > > > Stefan Santesson wrote: > > > > > > I think we all should agree though that there is no security > > > > requirement > > > > > > to provide a strong hash here. > > > > > > The only reason to allow another type of hash is so we can > > > > > > completely move away from SHA-1 when there is no other > > > reason to > > > > > > implement and > > > > use it. > > > > > > I don't see that happen in any foreseeable future, but > > > if we can > > > > > > make this more pure and remove tension by adding an identifier, > > > > > > that is OK with me. > > > > > > > > > > > > If this list does not strongly object, I will add an algorithm > > > > > > identifier in the next draft. > > > > > > > > > > > > *Stefan Santesson > > > > > > *AAA-sec.com > > > > > > > > > > _______________________________________________ > > > > > TLS mailing list > > > > > TLS@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > Regards, > > > > > > > > Spokesman for INEGroup LLA. - (Over 284k > > > members/stakeholders strong!) > > > > "Obedience of the law is the greatest freedom" - > > > > Abraham Lincoln > > > > "YES WE CAN!" Barack ( Berry ) Obama > > > > > > > > "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 > > > > > > > > > > > > > > > > > > > > Email secured by Check Point > > Regards, > > Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) > "Obedience of the law is the greatest freedom" - > Abraham Lincoln > "YES WE CAN!" Barack ( Berry ) Obama > > "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 > > > Scanned by Check Point Total Security Gateway. > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_0000_01C9A04B.98C1F850 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDMwODIyMTEzMFowIwYJKoZIhvcNAQkEMRYEFJ5i7b3k0+JQ tINeNHk8Y6d0J9iHMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Aa6UNoofahBIfKoTC2UOeccL7ld9/CvK6vOTT/KClbSOHS5BbvgcZBrJKphCT6hFKPazH7Uu2SNX pY2eIwi2XlCO2ETL5c42yIJQEdQ21diEThgCc7pP4yYLAfj8UuWHlLTlForYfB9uHEvqtFqG0sEE YI+eTH+pcRY7uVcWpQaiXDIYz/qXN7QR+S24Tj3tNYTk7ct/4D0A79Tnwvgf/YpEhBaV3ohL/BKi RI/odPdqS359JqNPn3JDLGBaRg8xWxuxl47hYmA1JBkPKOwgwRbvWfZFeUdQ7+iuqicU+Gs4ulPM fQbzjLi0wS45RLCx8RzbgXWflF0QPgZnqsRW0QAAAAAAAA== ------=_NextPart_000_0000_01C9A04B.98C1F850-- From ekr@networkresonance.com Sun Mar 8 18:35:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CF23A6A8E for ; Sun, 8 Mar 2009 18:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txLFQC4C0m25 for ; Sun, 8 Mar 2009 18:35:13 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 3D7973A6802 for ; Sun, 8 Mar 2009 18:35:13 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A70A650822 for ; Sun, 8 Mar 2009 18:58:38 -0700 (PDT) Date: Sun, 08 Mar 2009 18:58:38 -0700 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: <20090309015838.A70A650822@romeo.rtfm.com> Subject: [TLS] Call for Agenda Items X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 01:35:13 -0000 If you would like time to speak at the TLS WG in SFO, please send mail to before Wednesday March 11. Your request should include: - The presenter's name - The draft(s) in question - How much time you think you need If you've already asked me for time, you don't need to ask again. Thanks, -Ekr From jsalowey@cisco.com Mon Mar 9 00:01:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E2883A6A89 for ; Mon, 9 Mar 2009 00:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.253 X-Spam-Level: X-Spam-Status: No, score=-6.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rm6Kc-OlIlm4 for ; Mon, 9 Mar 2009 00:01:34 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9A9083A68BB for ; Mon, 9 Mar 2009 00:01:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.38,328,1233532800"; d="scan'208";a="263729962" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 09 Mar 2009 07:02:08 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n29728cM023107 for ; Mon, 9 Mar 2009 00:02:08 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n297284k002140 for ; Mon, 9 Mar 2009 07:02:08 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Mar 2009 00:02:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Mar 2009 00:02:06 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call draft-ietf-tls-extractor-05.txt Thread-Index: AcmghPVjhln65VGrRgC/w67zgZAoOA== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 09 Mar 2009 07:02:08.0330 (UTC) FILETIME=[F630F2A0:01C9A084] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=474; t=1236582128; x=1237446128; c=relaxed/simple; s=sjdkim1004; 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:=20Working=20Group=20Last=20Call=20draft-ietf-tls- extractor-05.txt |Sender:=20; bh=uBfZuOWZHRR6RKZAd/LdXNNeYu7zuERSWZpu4WusVq0=; b=S2GgLyxOICZK+cQxkSRsa0jpMQ5WQkIGp+bAWwBFdT9xPAkQxgHp7xEt+5 opSJCbuC94saP2FNQoNHkshr5UR0CxFxGmMpk4TozeBsyaTAz6zvSE3F/lAZ U0jTm+xbNertUbRJSCCJ37W7jLg4Ltmo9TD3FoPJ+Wf6U6+2nwaBw=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 07:01:35 -0000 This announcement is for working group last call on draft-ietf-tls-extractor-05.txt. Please send your comments to the list by Tuesday March 17, 2009. The previous draft (-04) had some errors introduced in the editing process. Please check any comments made against the previous draft against the new draft and resubmit them if they are still valid. The draft and diffs can be found at: http://tools.ietf.org/html/draft-ietf-tls-extractor-05 Thanks, Joe From stefans@exmsft.com Mon Mar 9 00:04:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA7343A6B8A for ; Mon, 9 Mar 2009 00:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN2+6LjOtoLm for ; Mon, 9 Mar 2009 00:04:03 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id EB7CE28C13E for ; Mon, 9 Mar 2009 00:03:21 -0700 (PDT) Received: (qmail 25724 invoked from network); 9 Mar 2009 07:03:55 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Mar 2009 07:03:55 -0000 Received: (qmail 20720 invoked from network); 9 Mar 2009 07:03:53 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Mar 2009 07:03:53 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 09 Mar 2009 08:03:52 +0100 From: Stefan Santesson To: Eric Rescorla , Message-ID: Thread-Topic: [TLS] Call for Agenda Items Thread-Index: AcmghTP7KL0tj9k5+kqRrOqAeyhxOQ== In-Reply-To: <20090309015838.A70A650822@romeo.rtfm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Call for Agenda Items X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 07:04:03 -0000 I asked on the list, but just to be sure: Presenter: Stefan Santesson Draft: draft-santesson-credsel-01 Time: 10 min (as hash agility seems to be an issues of interest) On 3/9/09 2:58 AM, "Eric Rescorla" wrote: > If you would like time to speak at the TLS WG in SFO, please send mail > to before Wednesday March 11. Your request > should include: > > - The presenter's name > - The draft(s) in question > - How much time you think you need > > If you've already asked me for time, you don't need to ask again. > > Thanks, > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefans@exmsft.com Mon Mar 9 00:10:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408E43A6B8C for ; Mon, 9 Mar 2009 00:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Og6IIJdDuu6 for ; Mon, 9 Mar 2009 00:10:02 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id A2A5C3A6B8A for ; Mon, 9 Mar 2009 00:10:01 -0700 (PDT) Received: (qmail 28643 invoked from network); 9 Mar 2009 07:10:35 -0000 Received: from s34.loopia.se (HELO s19.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Mar 2009 07:10:35 -0000 Received: (qmail 41020 invoked from network); 9 Mar 2009 07:10:33 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s19.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Mar 2009 07:10:33 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 09 Mar 2009 08:10:32 +0100 From: Stefan Santesson To: Eric Rescorla , Message-ID: Thread-Topic: [TLS] Call for Agenda Items Thread-Index: AcmghTP7KL0tj9k5+kqRrOqAeyhxOQAAO5p+ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] Call for Agenda Items X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 07:10:03 -0000 Sorry about the spam, First of all, this mail was intended to Ekr only, not for the list. Secondly, the name of the draft is: draft-santesson-tls-certcache-00 It's Monday morning :) /Stefan On 3/9/09 8:03 AM, "Stefan Santesson" wrote: > I asked on the list, but just to be sure: > > Presenter: Stefan Santesson > Draft: draft-santesson-credsel-01 > Time: 10 min (as hash agility seems to be an issues of interest) > > > On 3/9/09 2:58 AM, "Eric Rescorla" wrote: > >> If you would like time to speak at the TLS WG in SFO, please send mail >> to before Wednesday March 11. Your request >> should include: >> >> - The presenter's name >> - The draft(s) in question >> - How much time you think you need >> >> If you've already asked me for time, you don't need to ask again. >> >> Thanks, >> -Ekr >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Mon Mar 9 02:29:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D9733A6B8F for ; Mon, 9 Mar 2009 02:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.393 X-Spam-Level: X-Spam-Status: No, score=-2.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4NcF0lS0Fpi for ; Mon, 9 Mar 2009 02:29:33 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 4D2903A69E5 for ; Mon, 9 Mar 2009 02:29:32 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Lgbo9-0002U3-L3; Mon, 09 Mar 2009 10:30:02 +0100 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090309:tls@ietf.org::vkqfKD5tOWz15pbn:1WSN X-Hashcash: 1:22:090309:jsalowey@cisco.com::X0lh/lBKLcR8jmvh:dIIx Date: Mon, 09 Mar 2009 10:30:00 +0100 In-Reply-To: (Joseph Salowey's message of "Mon, 9 Mar 2009 00:02:06 -0700") Message-ID: <87ljrf2gdj.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 09:29:34 -0000 "Joseph Salowey (jsalowey)" writes: > This announcement is for working group last call on > draft-ietf-tls-extractor-05.txt. Please send your comments to the list > by Tuesday March 17, 2009. I support publication of this document, but I have a question that I believe would be useful to address in the document. Is the construct safe if "context_value" contains confidential information such as cryptographic keys? Or, in other words, is there any risk that the output leaks information about the context_value? If yes, I suggest adding after this text: The context value allows the application using the exporter to mix its own data with the TLS PRF for the exporter output. One example of where this might be useful is an authentication setting where the client credentials are valid for more than one identity; the context value could then be used to mix the expected identity into the keying material, thus preventing substitution attacks. the following NEW sentence: Another example is if the application wants to strengthen a cryptographic key; the context value could then be used to mix in the key. If no, I suggest adding to the Security Considerations: The exporter function should not be used to mix information intended to be confidential, because the PRF output may leak some information about the confidential information. This relates to discussions in the KRB-WG about how useful the PRFs are in IETF protocols. If the TLS Exporter function is not designed to deal with confidential input, some protocols will need to design its own PRF. This would be unfortunate, so it would be good to document what applications we can safely use the TLS Exporter function for. (Yes, I have some understanding about the answer to this question, but I think some discussion would be useful now, to possibly avoid some discussions later when this is published.) Thanks, /Simon From Martin.Rex@sap.com Mon Mar 9 02:38:27 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6046D3A6BA8 for ; Mon, 9 Mar 2009 02:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.206 X-Spam-Level: X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=1.043, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXtrJsKPZwpt for ; Mon, 9 Mar 2009 02:38:26 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 3F21E3A69E5 for ; Mon, 9 Mar 2009 02:38:26 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n299atPu019624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 10:36:55 +0100 (MET) From: Martin Rex Message-Id: <200903090936.n299asYC013547@fs4113.wdf.sap.corp> To: housley@vigilsec.com (Russ Housley) Date: Mon, 9 Mar 2009 10:36:54 +0100 (MET) In-Reply-To: <20090307010250.B01253A67B4@core3.amsl.com> from "Russ Housley" at Mar 6, 9 07:54:22 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 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 09 Mar 2009 09:38:27 -0000 Russ Housley wrote: > > At some point, I believe that we will want to use a hash function > other than SHA-1. We can either insert the algorithm identifier now, > or we will use a different extension when that time comes. I violently disagree. Anyone how is using that caching extension and has understood what he is implementing will be fine with SHA-1 forever. In the discussion that we had on the original Fast Track proposal many month ago, there was a proposal to assign an static identifier for the cached information. There was no security issue raised agains this approach (and I still don't see a security issue), The reason why I advocated for SHA-1 over the exact data that goes over the wire was simplicity and robustness. If you use a static identifier, you might not realize when the "cached" information is no longer in sync (possible reasons: cache corruption on client, information updated on server but not in client cache). When a hash over the cached data is used (over the bits-on-the-wire) rather than a static identifier, then - you don't have any configuration issues of synchronously assigning a static identifier for the same pieces of information - can implement it in a robust fashion so when the clients information gets out of sync this can be determined with very high probability and the server will send the full, currently valid information automatically, instead of having to go through a TLS handshake failure (which is quite difficult to recover from, because it cannot be done at the TLS layer). We know exactly the probabilistic collisions of SHA-1, and no matter how good the attacks on SHA-1 on precomputing collisions may become, the impact on the probabilistic collisions will remain negiligible for the purpose we're looking at here, so NO, unless we're religious about this, we will NOT want to ever use a different hash function here. -Martin From Martin.Rex@sap.com Mon Mar 9 04:35:28 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C2A43A6C1B for ; Mon, 9 Mar 2009 04:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USItgbfWNrju for ; Mon, 9 Mar 2009 04:35:27 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 53F623A6B16 for ; Mon, 9 Mar 2009 04:35:27 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n29BZxQk015570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 12:35:59 +0100 (MET) From: Martin Rex Message-Id: <200903091135.n29BZxNN021857@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 9 Mar 2009 12:35:59 +0100 (MET) In-Reply-To: <20090307225933.0999350822@romeo.rtfm.com> from "Eric Rescorla" at Mar 7, 9 02:59:33 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 Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 09 Mar 2009 11:35:28 -0000 I'm wondering whether tls-extractors should use a TLS hello extension to "negotiate" whether the TLS implementations at both ends actually implement tls-extractors, and whether its the same version of the spec. There is this statement in "1. Introduction": o Both client and server need to be able to export the same EKM value. But I don't currently see a means how both peers are able to determine that this is the case _without_ using a TLS hello extension to determine they both, in fact, offer the necessary APIs to their callers and implement the same version of the tls-extractors (TLS Exporters) spec. -Martin From simon@josefsson.org Mon Mar 9 04:57:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 458B93A6C84 for ; Mon, 9 Mar 2009 04:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.397 X-Spam-Level: X-Spam-Status: No, score=-2.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5cnVKSWdz14 for ; Mon, 9 Mar 2009 04:57:22 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 5F6143A685C for ; Mon, 9 Mar 2009 04:57:22 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Lge7D-0002h0-IW; Mon, 09 Mar 2009 12:57:52 +0100 From: Simon Josefsson To: martin.rex@sap.com References: <20090307225933.0999350822@romeo.rtfm.com> <200903091135.n29BZxNN021857@fs4113.wdf.sap.corp> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090309:ekr@networkresonance.com::MnoJ39Dx0urLDdzJ:7Px7 X-Hashcash: 1:22:090309:martin.rex@sap.com::o1Qrx+dEaIxdCX4F:NUQd X-Hashcash: 1:22:090309:tls@ietf.org::YvIV7bCyLAtZ/LDD:N56Q Date: Mon, 09 Mar 2009 12:57:50 +0100 In-Reply-To: <200903091135.n29BZxNN021857@fs4113.wdf.sap.corp> (Martin Rex's message of "Mon, 9 Mar 2009 12:35:59 +0100 (MET)") Message-ID: <873admoqm9.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 11:57:23 -0000 Martin Rex writes: > I'm wondering whether tls-extractors should use a TLS hello extension to > "negotiate" whether the TLS implementations at both ends actually > implement tls-extractors, and whether its the same version of > the spec. > > There is this statement in "1. Introduction": > > o Both client and server need to be able to export the same EKM > value. I believe that is an implementation requirement. > But I don't currently see a means how both peers are able to determine that > this is the case _without_ using a TLS hello extension to determine > they both, in fact, offer the necessary APIs to their callers and > implement the same version of the tls-extractors (TLS Exporters) spec. Doesn't this negotiation belong better in protocols that make use of tls-extractor instead? Compare one usage of tls-extractor: http://tools.ietf.org/html/draft-josefsson-krb5starttls-bootstrap-02 If the other peer does not support tls extractor, the protocol that uses tls-extractor could handle that gracefully. The tls-extractor protocol does not need to describe this negotiation. In other words, I don't see what _advantage_ you get from knowing that both peers support tls-extractor. Support for it does not mean that _use_ of the tls-extractor will do anything useful, since that will be determined by some other protocol that makes use of tls-extractor. Just some thoughts. /Simon From mbadra@gmail.com Mon Mar 9 05:03:56 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DB623A67E7 for ; Mon, 9 Mar 2009 05:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKel9qZAqITn for ; Mon, 9 Mar 2009 05:03:55 -0700 (PDT) Received: from mail-fx0-f176.google.com (mail-fx0-f176.google.com [209.85.220.176]) by core3.amsl.com (Postfix) with ESMTP id 377423A693E for ; Mon, 9 Mar 2009 05:03:55 -0700 (PDT) Received: by fxm24 with SMTP id 24so1205123fxm.37 for ; Mon, 09 Mar 2009 05:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=vCImi4No2jgQxOAY1qTIebjFn7Oj8jv9DfX259F5/l8=; b=JndL5+KdkwFGTulVlgXSzuBdyKWo6fkfNDHngy258dHO9B0S0SDL4AqmW1ausP++CS j5Yq2Q0aVyWRXH0q5PrgVpTQ+Lx6qCkkWUPwyoTvzM13yKH3GqCBwbmPXBGYTHzs5UCl nw4URFoDNjuj6BM20Hw7tEBkIVnbxUwTijoMI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=h/U7QxMuuAKDHslmmUKgQLtFrqX+PXKi6Vk3zIem9oU03ClACMdHFAvQ4h24CHY3Mm PRPPV02LhNQ2bFHtXU2C9xcA/iix0yP/yZca8JNHFpz9D7dz/WnCx+wVpQpgOi9ytkuv XUbUiH/bZbpJWPUKpOVxaUaQ7za+Do/5bq+Y8= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.86.31.18 with SMTP id e18mr3880864fge.72.1236600268349; Mon, 09 Mar 2009 05:04:28 -0700 (PDT) In-Reply-To: <200903091135.n29BZxNN021857@fs4113.wdf.sap.corp> References: <20090307225933.0999350822@romeo.rtfm.com> <200903091135.n29BZxNN021857@fs4113.wdf.sap.corp> Date: Mon, 9 Mar 2009 13:04:28 +0100 X-Google-Sender-Auth: 1e13d67f967edb88 Message-ID: From: Badra To: martin.rex@sap.com Content-Type: multipart/alternative; boundary=000e0cd24750b963490464ae6f26 Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 12:03:56 -0000 --000e0cd24750b963490464ae6f26 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think it is up to the application/spec/protocol that relies on TLS for security services, e.g. EAP-TLS specifies how to extract the keys from master_secret by both the client and the server and to verifies that both of them have extracted the same key. Best regards Badra On Mon, Mar 9, 2009 at 12:35 PM, Martin Rex wrote: > I'm wondering whether tls-extractors should use a TLS hello extension to > "negotiate" whether the TLS implementations at both ends actually > implement tls-extractors, and whether its the same version of > the spec. > > There is this statement in "1. Introduction": > > o Both client and server need to be able to export the same EKM > value. > > But I don't currently see a means how both peers are able to determine that > this is the case _without_ using a TLS hello extension to determine > they both, in fact, offer the necessary APIs to their callers and > implement the same version of the tls-extractors (TLS Exporters) spec. > > -Martin > > --000e0cd24750b963490464ae6f26 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think it is up to the application/spec/protocol that relies on TLS f= or security services, e.g. EAP-TLS specifies how to extract the keys from m= aster_secret by both the client and the server and to verifies that both of= them have extracted the same key.
=A0
Best regards
Badra


=A0
On Mon, Mar 9, 2009 at 12:35 PM, Martin Rex <Martin.Rex@sap.com<= /a>> wrote:
I'm wondering whether tls-ex= tractors should use a TLS hello extension to
"negotiate" wheth= er the TLS implementations at both ends actually
implement tls-extractors, and whether its the same version of
the spec.<= br>
There is this statement in "1. Introduction":

=A0 o= =A0Both client and server need to be able to export the same EKM
=A0 = =A0 =A0value.

But I don't currently see a means how both peers are able to determ= ine that
this is the case _without_ using a TLS hello extension to deter= mine
they both, in fact, offer the necessary APIs to their callers and implement the same version of the tls-extractors (TLS Exporters) spec.
<= font color=3D"#888888">
-Martin


--000e0cd24750b963490464ae6f26-- From Jeremey.Barrett@nokia.com Mon Mar 9 06:54:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49B703A6C1A for ; Mon, 9 Mar 2009 06:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNoSpjOsL9-v for ; Mon, 9 Mar 2009 06:54:39 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 061603A6C8B for ; Mon, 9 Mar 2009 06:54:38 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n29DspD5025272; Mon, 9 Mar 2009 15:55:09 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 15:54:58 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 9 Mar 2009 15:54:53 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-AM1MHUB-03.mgdnok.nokia.com (65.54.30.7) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 9 Mar 2009 14:54:52 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Mon, 9 Mar 2009 14:54:52 +0100 From: To: , Date: Mon, 9 Mar 2009 14:54:52 +0100 Thread-Topic: [TLS] New Version Notification for draft-barrett-mobile-dtls-00 Thread-Index: Acmfe8sgdRxyjQKHQzS8Wc1y0qzqCQBQtGQ+ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 09 Mar 2009 13:54:53.0395 (UTC) FILETIME=[9F51FA30:01C9A0BE] X-Nokia-AV: Clean Cc: TLS@ietf.org Subject: Re: [TLS] New Version Notification for draft-barrett-mobile-dtls-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 13:54:40 -0000 Hi Badra,=20 The latency of performing a handshake may not be acceptable in some applications (e.g. real-time data), especially in the case of an unforeseen move. Mobile DTLS allows an application on a mobile device to simply keep working, and this fits particularly well with applications which are alread= y sending and receiving data very frequently. Another problem with the handshake approach is that it forces the application to constantly worry about whether it has moved or not. Mobile DTLS shields the application from having to care; it can just make the simple assumption that the OS has *some* address. If the application isn't sending data, it could choose to send NOP at some frequency. Regards, Jeremey. On 3/7/09 5:23 PM, "ext Badra" wrote: > Hi Michael, > =A0 > Cannot DTLS/TLS clients establish a full handshake using a first IP addre= ss > and then resume the same session using a second IP address? >=20 > Best regards, > Badra > =A0 > On Thu, Mar 5, 2009 at 12:18 AM, wrote: >> Hi All, >>=20 >> Jeremey and I have created a new I-D for consideration by the TLS WG. Yo= ur >> comments are more than welcome. >>=20 >> Kind Regards, >> Michael >> -----Original Message----- >> From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: 04 March, 2009 15:01 >> To: Barrett Jeremey (Nokia-S/MtView) >> Cc: Williams Michael.G (Nokia-CIC/Dallas) >> Subject: New Version Notification for draft-barrett-mobile-dtls-00 >>=20 >>=20 >> A new version of I-D, draft-barrett-mobile-dtls-00.txt has been successf= uly >> submitted by Jeremey Barrett and posted to the IETF repository. >>=20 >> Filename: =A0 =A0 =A0 =A0draft-barrett-mobile-dtls >> Revision: =A0 =A0 =A0 =A000 >> Title: =A0 =A0 =A0 =A0 =A0 Mobile DTLS >> Creation_date: =A0 2009-03-04 >> WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission >> Number_of_pages: 12 >>=20 >> Abstract: >> Mobile DTLS (Mobi-D) is an extension to DTLS that provides host mobility >> support. =A0After obtaining a new IP address or port, a DTLS client mobi= le host >> can continue sending to its DTLS server correspondent host. =A0The mobil= e host >> continues to use the existing set of security parameters, from the new >> address, without re- negotiation. =A0The correspondent host accepts pack= ets >> from=20 >> the new IP address or port, also without re-negotiation. =A0After receiv= ing any >> valid DTLS packet from the mobile host's new address or port, the >> correspondent host uses the new address or port to send to the mobile ho= st. >>=20 >>=20 >>=20 >> The IETF Secretariat. >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From ekr@networkresonance.com Mon Mar 9 07:43:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296A03A6B0C for ; Mon, 9 Mar 2009 07:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNn0lb3XwAGd for ; Mon, 9 Mar 2009 07:43:30 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 6293D3A69E2 for ; Mon, 9 Mar 2009 07:43:30 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id A059650846; Mon, 9 Mar 2009 08:06:56 -0700 (PDT) Date: Mon, 09 Mar 2009 08:06:56 -0700 From: Eric Rescorla To: Simon Josefsson In-Reply-To: <87ljrf2gdj.fsf@mocca.josefsson.org> References: <87ljrf2gdj.fsf@mocca.josefsson.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: <20090309150656.A059650846@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:43:31 -0000 At Mon, 09 Mar 2009 10:30:00 +0100, Simon Josefsson wrote: > > "Joseph Salowey (jsalowey)" writes: > > > This announcement is for working group last call on > > draft-ietf-tls-extractor-05.txt. Please send your comments to the list > > by Tuesday March 17, 2009. > > I support publication of this document, but I have a question that I > believe would be useful to address in the document. > > Is the construct safe if "context_value" contains confidential > information such as cryptographic keys? Or, in other words, is there > any risk that the output leaks information about the context_value? It should be. It's part of the definition of the PRF that iot doesn't (unless you know all the other values). > If yes, I suggest adding after this text: > > The context value allows the application using the exporter to mix > its own data with the TLS PRF for the exporter output. One example > of where this might be useful is an authentication setting where the > client credentials are valid for more than one identity; the context > value could then be used to mix the expected identity into the keying > material, thus preventing substitution attacks. > > the following NEW sentence: > > Another example is if the application wants to strengthen a > cryptographic key; the context value could then be used to mix in the > key. I would suggest that TLS-PSK would be a more appropriate use here. But how about we compromise: "Because the context value is mixed with the master_secret via the PRF, it is safe to mix confidential information into the extractor provided that the master_secret will not be known to the attacker." -Ekr From ekr@networkresonance.com Mon Mar 9 07:45:26 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3093028C214 for ; Mon, 9 Mar 2009 07:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFPwIYhDsTgA for ; Mon, 9 Mar 2009 07:45:25 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 62E9C28C1D8 for ; Mon, 9 Mar 2009 07:45:25 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id DA7B850846; Mon, 9 Mar 2009 08:08:51 -0700 (PDT) Date: Mon, 09 Mar 2009 08:08:51 -0700 From: Eric Rescorla To: martin.rex@sap.com In-Reply-To: <200903091135.n29BZxNN021857@fs4113.wdf.sap.corp> References: <20090307225933.0999350822@romeo.rtfm.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: <20090309150851.DA7B850846@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:45:26 -0000 At Mon, 9 Mar 2009 12:35:59 +0100 (MET), Martin Rex wrote: > > I'm wondering whether tls-extractors should use a TLS hello extension to > "negotiate" whether the TLS implementations at both ends actually > implement tls-extractors, and whether its the same version of > the spec. That's one possibility. In fact, it's how DTLS-SRTP works. we just didn't want to preclude otehr options. > There is this statement in "1. Introduction": > > o Both client and server need to be able to export the same EKM > value. This is a requirement on the system as a whole. > But I don't currently see a means how both peers are able to determine that > this is the case _without_ using a TLS hello extension to determine > they both, in fact, offer the necessary APIs to their callers and > implement the same version of the tls-extractors (TLS Exporters) spec. Say, for the sake of argument, that we were implementing a new protocol Foo over TLS. Foo is defined to use an extractor as a key generation mechanism and whenever Foo over TLS is used, the extractor is also used. Thus, there is no need to negotiate it. -Ekr From simon@josefsson.org Mon Mar 9 07:51:31 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06EB83A6A31 for ; Mon, 9 Mar 2009 07:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.404 X-Spam-Level: X-Spam-Status: No, score=-2.404 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PBRGEblep9E for ; Mon, 9 Mar 2009 07:51:29 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id F13CF3A6909 for ; Mon, 9 Mar 2009 07:51:27 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1Lggpi-0003iu-GE; Mon, 09 Mar 2009 15:51:59 +0100 From: Simon Josefsson To: Eric Rescorla References: <87ljrf2gdj.fsf@mocca.josefsson.org> <20090309150656.A059650846@romeo.rtfm.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090309:tls@ietf.org::aWc6pYWOjBl0is97:oa5 X-Hashcash: 1:22:090309:ekr@networkresonance.com::Cy9ZPyHEtC6ULR8i:F672 Date: Mon, 09 Mar 2009 15:51:57 +0100 In-Reply-To: <20090309150656.A059650846@romeo.rtfm.com> (Eric Rescorla's message of "Mon, 09 Mar 2009 08:06:56 -0700") Message-ID: <878wnen3zm.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 14:51:31 -0000 Eric Rescorla writes: >> Another example is if the application wants to strengthen a >> cryptographic key; the context value could then be used to mix in the >> key. > > I would suggest that TLS-PSK would be a more appropriate use here. Hmm. Yes, sometimes, but not always; think for example where you need to derive keys from a long term key and from the TLS secret by mixing them together, and which long term key to use is chosen only after the TLS handshake (possibly influenced by the application data passed in the TLS session). > But how about we compromise: > "Because the context value is mixed with the master_secret via > the PRF, it is safe to mix confidential information into the > extractor provided that the master_secret will not be known to > the attacker." That would be great. Thanks, /Simon From badra@isima.fr Mon Mar 9 08:36:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FA313A6961 for ; Mon, 9 Mar 2009 08:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.336, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-s4AxTBZCYp for ; Mon, 9 Mar 2009 08:36:12 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id 722E43A67E4 for ; Mon, 9 Mar 2009 08:36:12 -0700 (PDT) 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 n29Ga9F2503984; Mon, 9 Mar 2009 16:36:09 GMT Message-ID: <49B538A5.7090309@isima.fr> Date: Mon, 09 Mar 2009 16:41:25 +0100 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Jeremey.Barrett@nokia.com References: In-Reply-To: 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]); Mon, 09 Mar 2009 16:36:09 +0000 (WET) Cc: Michael.G.Williams@nokia.com, TLS@ietf.org Subject: Re: [TLS] New Version Notification for draft-barrett-mobile-dtls-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:36:13 -0000 Hi Jeremey, > Hi Badra, > > The latency of performing a handshake may not be acceptable in some > applications (e.g. real-time data), especially in the case of an unforeseen > move. With the changes you propose to DTLS, I am not sure a "resumed handshake" will influence the performance of those applications, unless you have data to back that claim. > Mobile DTLS allows an application on a mobile device to simply keep > working, and this fits particularly well with applications which are already > sending and receiving data very frequently. Hmmm, but this is already discussed in Section 4.1 of rfc4347-bis-02. I believe the text of this Section is good enough to handle the situation you cited before. > Another problem with the handshake approach is that it forces the > application to constantly worry about whether it has moved or not. Mobile > DTLS shields the application from having to care; it can just make the > simple assumption that the OS has *some* address. But I don't see the benefits of managing the mobility at the DTLS layer for applications that will be happy to do that. > If the application isn't sending data, it could choose to send NOP at some > frequency. > > Regards, > Jeremey. Best regards, Badra > > > On 3/7/09 5:23 PM, "ext Badra" wrote: > > >> Hi Michael, >> >> Cannot DTLS/TLS clients establish a full handshake using a first IP address >> and then resume the same session using a second IP address? >> >> Best regards, >> Badra >> >> On Thu, Mar 5, 2009 at 12:18 AM, wrote: >> >>> Hi All, >>> >>> Jeremey and I have created a new I-D for consideration by the TLS WG. Your >>> comments are more than welcome. >>> >>> Kind Regards, >>> Michael >>> -----Original Message----- >>> From: ext IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >>> Sent: 04 March, 2009 15:01 >>> To: Barrett Jeremey (Nokia-S/MtView) >>> Cc: Williams Michael.G (Nokia-CIC/Dallas) >>> Subject: New Version Notification for draft-barrett-mobile-dtls-00 >>> >>> >>> A new version of I-D, draft-barrett-mobile-dtls-00.txt has been successfuly >>> submitted by Jeremey Barrett and posted to the IETF repository. >>> >>> Filename: draft-barrett-mobile-dtls >>> Revision: 00 >>> Title: Mobile DTLS >>> Creation_date: 2009-03-04 >>> WG ID: Independent Submission >>> Number_of_pages: 12 >>> >>> Abstract: >>> Mobile DTLS (Mobi-D) is an extension to DTLS that provides host mobility >>> support. After obtaining a new IP address or port, a DTLS client mobile host >>> can continue sending to its DTLS server correspondent host. The mobile host >>> continues to use the existing set of security parameters, from the new >>> address, without re- negotiation. The correspondent host accepts packets >>> from >>> the new IP address or port, also without re-negotiation. After receiving any >>> valid DTLS packet from the mobile host's new address or port, the >>> correspondent host uses the new address or port to send to the mobile host. From Martin.Rex@sap.com Mon Mar 9 08:47:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 043D43A6840 for ; Mon, 9 Mar 2009 08:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.438 X-Spam-Level: X-Spam-Status: No, score=-5.438 tagged_above=-999 required=5 tests=[AWL=0.811, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrNv5R3HSb0n for ; Mon, 9 Mar 2009 08:47:34 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C2B7F3A67E4 for ; Mon, 9 Mar 2009 08:47:33 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n29Fm6Zj004823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 16:48:06 +0100 (MET) From: Martin Rex Message-Id: <200903091548.n29Fm5PX009615@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 9 Mar 2009 16:48:05 +0100 (MET) In-Reply-To: <20090309150851.DA7B850846@romeo.rtfm.com> from "Eric Rescorla" at Mar 9, 9 08:08:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 09 Mar 2009 15:47:35 -0000 Eric Rescorla wrote: > Martin Rex wrote: > > > > I'm wondering whether tls-extractors should use a TLS hello extension to > > "negotiate" whether the TLS implementations at both ends actually > > implement tls-extractors, and whether its the same version of > > the spec. > > That's one possibility. In fact, it's how DTLS-SRTP works. we just > didn't want to preclude otehr options. > > > But I don't currently see a means how both peers are able to determine that > > this is the case _without_ using a TLS hello extension to determine > > they both, in fact, offer the necessary APIs to their callers and > > implement the same version of the tls-extractors (TLS Exporters) spec. > > Say, for the sake of argument, that we were implementing a new > protocol Foo over TLS. Foo is defined to use an extractor as a key > generation mechanism and whenever Foo over TLS is used, the > extractor is also used. Thus, there is no need to negotiate it. And if they were implementing a new revision of an existing protocol Bar over TLS, which has the option of making use of TLS extractor, then the Bar application protocol will have to use an application-level negotiation (one round-trip) und the regular TLS protection in order to determine whether the new Bar option to use TLS extractors is available on both sides before it can switch to using it. I don't see a need to make TLS extractors available to one side if the other side doesn't implmement it (doesn't offer it to the application caller). Whether and when the application makes use of it is a different matter. -Martin From ekr@networkresonance.com Mon Mar 9 08:50:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9819E3A6932 for ; Mon, 9 Mar 2009 08:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Cb31FonEehw for ; Mon, 9 Mar 2009 08:50:04 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id AF9003A6840 for ; Mon, 9 Mar 2009 08:50:03 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 92F6950822; Mon, 9 Mar 2009 09:13:28 -0700 (PDT) Date: Mon, 09 Mar 2009 09:13:28 -0700 From: Eric Rescorla To: martin.rex@sap.com In-Reply-To: <200903091548.n29Fm5PX009615@fs4113.wdf.sap.corp> References: <20090309150851.DA7B850846@romeo.rtfm.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: <20090309161328.92F6950822@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 15:50:13 -0000 At Mon, 9 Mar 2009 16:48:05 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > Martin Rex wrote: > > > > > > I'm wondering whether tls-extractors should use a TLS hello extension to > > > "negotiate" whether the TLS implementations at both ends actually > > > implement tls-extractors, and whether its the same version of > > > the spec. > > > > That's one possibility. In fact, it's how DTLS-SRTP works. we just > > didn't want to preclude otehr options. > > > > > But I don't currently see a means how both peers are able to determine that > > > this is the case _without_ using a TLS hello extension to determine > > > they both, in fact, offer the necessary APIs to their callers and > > > implement the same version of the tls-extractors (TLS Exporters) spec. > > > > Say, for the sake of argument, that we were implementing a new > > protocol Foo over TLS. Foo is defined to use an extractor as a key > > generation mechanism and whenever Foo over TLS is used, the > > extractor is also used. Thus, there is no need to negotiate it. > > > And if they were implementing a new revision of an existing protocol Bar > over TLS, which has the option of making use of TLS extractor, then > the Bar application protocol will have to use an application-level > negotiation (one round-trip) und the regular TLS protection in order > to determine whether the new Bar option to use TLS extractors is > available on both sides before it can switch to using it. Yes. I don't see a problem with that. As I said, there are several options. > I don't see a need to make TLS extractors available to one side if > the other side doesn't implmement it (doesn't offer it to the > application caller). Whether and when the application makes use > of it is a different matter. I agree with that, but I'm not sure what your point is. -Ekr From Martin.Rex@sap.com Mon Mar 9 08:59:41 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA5133A6358 for ; Mon, 9 Mar 2009 08:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDSAMqCIOZ1f for ; Mon, 9 Mar 2009 08:59:40 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 875D53A699C for ; Mon, 9 Mar 2009 08:59:40 -0700 (PDT) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n29G0Dnv017839 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Mar 2009 17:00:13 +0100 (MET) From: Martin Rex Message-Id: <200903091600.n29G0CQH010604@fs4113.wdf.sap.corp> To: ekr@networkresonance.com (Eric Rescorla) Date: Mon, 9 Mar 2009 17:00:12 +0100 (MET) In-Reply-To: <20090309161328.92F6950822@romeo.rtfm.com> from "Eric Rescorla" at Mar 9, 9 09:13:28 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Mon, 09 Mar 2009 15:59:41 -0000 Eric Rescorla wrote: > > > > > And if they were implementing a new revision of an existing protocol Bar > > over TLS, which has the option of making use of TLS extractor, then > > the Bar application protocol will have to use an application-level > > negotiation (one round-trip) und the regular TLS protection in order > > to determine whether the new Bar option to use TLS extractors is > > available on both sides before it can switch to using it. > > Yes. I don't see a problem with that. As I said, there are several > options. > > > > I don't see a need to make TLS extractors available to one side if > > the other side doesn't implmement it (doesn't offer it to the > > application caller). Whether and when the application makes use > > of it is a different matter. > > I agree with that, but I'm not sure what your point is. If the availability of TLS-extractors was negotiated between both communication peers through a TLS Hello extension, then the decision at the application level of Bar whether to use a feature based on TLS extractors or to use fallback instead can be entirely based on the return value of the respective TLS-extractors API call, no negotiation at the application level necessary. The local API would then be able to produce the following error messages: - TLS-extractor not implemented - TLS-peer did not confirm TLS-extractor availability for session - OK - misc errors (out-of-memory, ...) And if TLS-wg would want to create a different variant of TLS-Extractors in the future, one would not have to change the application negotiation to also negotiate the variants of TLS-Extractors, that would be entirely addressed by the negotiation in the TLS Hello extension. -Martin From ekr@networkresonance.com Mon Mar 9 09:05:00 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03B23A68CF for ; Mon, 9 Mar 2009 09:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83P9WvXxVBPY for ; Mon, 9 Mar 2009 09:05:00 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id E8B2C3A6358 for ; Mon, 9 Mar 2009 09:04:59 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 80A5750822; Mon, 9 Mar 2009 09:28:26 -0700 (PDT) Date: Mon, 09 Mar 2009 09:28:26 -0700 From: Eric Rescorla To: martin.rex@sap.com In-Reply-To: <200903091600.n29G0CQH010604@fs4113.wdf.sap.corp> References: <20090309161328.92F6950822@romeo.rtfm.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: <20090309162826.80A5750822@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:05:00 -0000 At Mon, 9 Mar 2009 17:00:12 +0100 (MET), Martin Rex wrote: > > Eric Rescorla wrote: > > > > > > > > And if they were implementing a new revision of an existing protocol Bar > > > over TLS, which has the option of making use of TLS extractor, then > > > the Bar application protocol will have to use an application-level > > > negotiation (one round-trip) und the regular TLS protection in order > > > to determine whether the new Bar option to use TLS extractors is > > > available on both sides before it can switch to using it. > > > > Yes. I don't see a problem with that. As I said, there are several > > options. > > > > > > > I don't see a need to make TLS extractors available to one side if > > > the other side doesn't implmement it (doesn't offer it to the > > > application caller). Whether and when the application makes use > > > of it is a different matter. > > > > I agree with that, but I'm not sure what your point is. > > > If the availability of TLS-extractors was negotiated between both > communication peers through a TLS Hello extension, then the decision > at the application level of Bar whether to use a feature based > on TLS extractors or to use fallback instead can be entirely > based on the return value of the respective TLS-extractors API call, > no negotiation at the application level necessary. > > The local API would then be able to produce the following > error messages: > > - TLS-extractor not implemented > - TLS-peer did not confirm TLS-extractor availability for session > - OK > - misc errors (out-of-memory, ...) > > And if TLS-wg would want to create a different variant of TLS-Extractors > in the future, one would not have to change the application negotiation > to also negotiate the variants of TLS-Extractors, that would be > entirely addressed by the negotiation in the TLS Hello extension. Yes, I see your point, but the extractors are suitable generally for only a specific purpose (E.g., DTLS-SRTP) and the negotiation includes the parameters for that purpose. So, I don't think a generic technique is appropriate here. -Ekr From stefans@exmsft.com Mon Mar 9 09:20:17 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75B493A6C55 for ; Mon, 9 Mar 2009 09:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.291 X-Spam-Level: X-Spam-Status: No, score=-1.291 tagged_above=-999 required=5 tests=[AWL=-0.439, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Sd-wvMFOhDJ for ; Mon, 9 Mar 2009 09:20:10 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id AD1933A695B for ; Mon, 9 Mar 2009 09:20:09 -0700 (PDT) Received: (qmail 33537 invoked from network); 9 Mar 2009 16:20:47 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 9 Mar 2009 16:20:47 -0000 Received: (qmail 75559 invoked from network); 9 Mar 2009 16:20:41 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 9 Mar 2009 16:20:41 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Mon, 09 Mar 2009 17:20:39 +0100 From: Stefan Santesson To: Min Huang Message-ID: Thread-Topic: New "Fast-Track" draft posted Thread-Index: AcmgplOWdTIYGVhvSXq8zQh1pK+pmQALKiGr In-Reply-To: <001201c9a0a6$54fc3580$cf8c1b0a@china.huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3319464041_86938" Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:20:17 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3319464041_86938 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Min, I included the possibility for the client to send more than one hash simply because I was not sure that there are no situation where that could be useful. So as the text is written now, the client may include a number of hashes, matching different sets of server certificate paths. This may for example b= e 2 hashes for the same server certificate calculated over different certificate paths. The server will compare the hashes against the hash of the certificate path it intended to send. If there is a match, the server will indicate the omitted path by including the corresponding hash in its Hello message. On 3/9/09 12:00 PM, "Min Huang" wrote: > Hi, Stefen > =20 > I have read the draft-santesson-tls-certcache-00.txt,and I have some > questions. > =20 > 1).In the section 2, =B3The certificate_hash value MUST include at least on= e > hash value calculated over an expected certificate_list element of a serv= er > side Certificate =B2 > =20 > Why do you say =B3at least one hash value=B2? Is there any possibility that c= an be > other hash value? My understanding is that the hash value is the hash of = the > whole certificate_list of a server side Certificate message. Did I miss > something here? > =20 > 2).In the section 4, > =B3Servers that receive an extended client hello containing a "cached_certs= " > extension, MAY indicate that they are willing to accept omitting certific= ate > data in the Server Certificate message by including an extension of type > "cached_certs" in the (extended) server hello, which SHALL contain a hash > received in the cached_certs extension from the client, which is a comple= te > hash calculated over all omitted certificates.=B2 >=20 > Does the two =B3which=B2 mean the same thing? I think they are not always the > same, in some cases they are different.Then the hash value will be which = one? > =20 > 3).There are two editorial errors: > a.Section 3 is missing . > b. struct { > opaque certificate_hash; <1..2^8-1> > } CachedCerts; > =B2;=B2 after =B3certificate_hash=B2 should be put after <1..2^8-1>. > =20 > regards, > Min Huang > =20 > =20 >> >Date: Thu, 05 Mar 2009 00:47:44 +0100 >> >From: Stefan Santesson = > >> >Subject: [TLS] New "Fast-Track" draft posted >> >To: TLS wg > >> >Message-ID: > > >> >Content-Type: text/plain; charset=3D"iso-8859-1" > =20 >> >As a result of the discussions we had around last IETF I have now poste= d a >> >new ?Fast Track? inspired draft. > =20 >> >The name of this draft is draft-santesson-tls-certcache-00 >> >It will be available in a few days from the I-D repository. Until then = it >> >can be obtained from the staging site at: >> >http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-0= 0.txt >>=20 > >=20 > =20 >> >I have chosen to do a completely new draft instead of updating the old >> >fast-track document as I have used a very simplified approach as starti= ng >> >point. >> >My document is limited to one new TLS extension with the sole purpose o= f >> >including a hash of a cached cert path to allow this cert path to be om= itted >> >from the server Certificate message. > =20 >> >I submitted this draft to inject some energy into the discussion again = but >> >I?m not locked on the approach if there are good reasons to expand it. >> >Please read and provide comments. > =20 >> >I would like to request a small time slot on the TLS meeting agenda in = San >> >Francisco to discuss this if possible. >> > >> > >> >Stefan Santesson >> >AAA-sec.com >=20 --B_3319464041_86938 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: New "Fast-Track" draft posted Hi Min,

I included the possibility for the client to send more than one hash simply= because I was not sure that there are no situation where that could be usef= ul.

So as the text is written now, the client may include a number of hashes, m= atching different sets of server certificate paths. This may for example be = 2 hashes for the same server certificate calculated over different certifica= te paths.
The server will compare the hashes against the hash of the certificate path= it intended to send. If there is a match, the server will indicate the omit= ted path by including the corresponding hash in its Hello message.



On 3/9/09 12:00 PM, "Min Huang" <huangmin123@huaweisymantec.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi, Stefen
 
I have read the draft-santesson-tls-certcache-00.txt,and I have some questi= ons.
 
1).In the section 2, “The certificate_hash value MUST include at leas= t one hash value calculated over an expected certificate_list element of a s= erver side Certificate ”
 
Why do you say “at least one hash value”? Is there any possibil= ity that can be other hash value? My understanding is that the hash value is= the hash of the whole certificate_list of a server side Certificate message= . Did I miss something here?
 
2).In the section 4,
“Servers that receive an extended client hello containing a "cac= hed_certs" extension, MAY indicate that they are willing to accept omit= ting certificate data in the Server Certificate message by including an exte= nsion of type "cached_certs" in the (extended) server hello, which= SHALL contain a hash received in the cached_certs extension from the client= , which is a complete hash calculated over all omitted certificates.”<= BR>
Does the two “which” mean the same thing? I think they are not = always the same, in some cases they are different.Then the hash value will b= e which one?
 
3).There are two editorial errors:
a.Section 3 is missing .
b. struct {
     opaque certificate_hash; <1..2^8-1>
  } CachedCerts;
”;” after “certificate_hash” should be put after &l= t;1..2^8-1>.
 
regards,
Min Huang
 
 
>Date: Thu, 05 Mar 2009 00:47:44 +0100
>From: Stefan Santesson <stefans@exmsft.= com <mailto:stefans@exmsft.com> >
>Subject: [TLS] New "Fast-Track" draft posted
>To: TLS wg <TLS@ietf.org <mailto:TLS@ietf.org> >
>Message-ID: <C5D4D1B0.8FC%= stefans@exmsft.com <= mailto:C5D4D1B0.8FC%stefans@exmsft.com> >
>Content-Type: text/plain; charset=3D"iso-8859-1"
 
>As a result of the discussions we had around last IETF I have now poste= d a
>new ?Fast Track? inspired draft.
 
>The name of this draft is  draft-santesson-tls-certcache-00
>It will be available in a few days from the I-D repository. Until then = it
>can be obtained from the staging site at:
>http://www.ietf.org/proceedings/staging/draft-santesson-tls-= certcache-00.txt <http://www.ietf.org/proceedings/staging/= draft-santesson-tls-certcache-00.txt>
 
>I have chosen to do a completely new draft instead of updating the old<= BR> >fast-track document as I have used a very simplified approach as starti= ng
>point.
>My document is limited to one new TLS extension with the sole purpose o= f
>including a hash of a cached cert path to allow this cert path to be om= itted
>from the server Certificate message.
 
>I submitted this draft to inject some energy into the discussion again = but
>I?m not locked on the approach if there are good reasons to expand it.<= BR> >Please read and provide comments.
 
>I would like to request a small time slot on the TLS meeting agenda in = San
>Francisco to discuss this if possible.
>
>
>Stefan Santesson
>AAA-sec.com

--B_3319464041_86938-- From badra@isima.fr Mon Mar 9 09:32:24 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085663A6C9E for ; Mon, 9 Mar 2009 09:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.939 X-Spam-Level: X-Spam-Status: No, score=-1.939 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQFZgYNQBeTS for ; Mon, 9 Mar 2009 09:32:23 -0700 (PDT) Received: from sp.isima.fr (sp.isima.fr [193.55.95.1]) by core3.amsl.com (Postfix) with ESMTP id E1B2028C0FD for ; Mon, 9 Mar 2009 09:32:22 -0700 (PDT) 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 n29HWKTl1282140; Mon, 9 Mar 2009 17:32:20 GMT Message-ID: <49B545D1.4080607@isima.fr> Date: Mon, 09 Mar 2009 17:37:37 +0100 From: Mohamad Badra User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Eric Rescorla References: <20090309161328.92F6950822@romeo.rtfm.com> <20090309162826.80A5750822@romeo.rtfm.com> In-Reply-To: <20090309162826.80A5750822@romeo.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (sp.isima.fr [193.55.95.1]); Mon, 09 Mar 2009 17:32:20 +0000 (WET) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:32:24 -0000 Eric Rescorla a écrit : > At Mon, 9 Mar 2009 17:00:12 +0100 (MET), > Martin Rex wrote: > >> Eric Rescorla wrote: >> >>>> And if they were implementing a new revision of an existing protocol Bar >>>> over TLS, which has the option of making use of TLS extractor, then >>>> the Bar application protocol will have to use an application-level >>>> negotiation (one round-trip) und the regular TLS protection in order >>>> to determine whether the new Bar option to use TLS extractors is >>>> available on both sides before it can switch to using it. >>>> >>> Yes. I don't see a problem with that. As I said, there are several >>> options. >>> >>> >>> >>>> I don't see a need to make TLS extractors available to one side if >>>> the other side doesn't implmement it (doesn't offer it to the >>>> application caller). Whether and when the application makes use >>>> of it is a different matter. >>>> >>> I agree with that, but I'm not sure what your point is. >>> >> If the availability of TLS-extractors was negotiated between both >> communication peers through a TLS Hello extension, then the decision >> at the application level of Bar whether to use a feature based >> on TLS extractors or to use fallback instead can be entirely >> based on the return value of the respective TLS-extractors API call, >> no negotiation at the application level necessary. >> >> The local API would then be able to produce the following >> error messages: >> >> - TLS-extractor not implemented >> - TLS-peer did not confirm TLS-extractor availability for session >> - OK >> - misc errors (out-of-memory, ...) >> >> And if TLS-wg would want to create a different variant of TLS-Extractors >> in the future, one would not have to change the application negotiation >> to also negotiate the variants of TLS-Extractors, that would be >> entirely addressed by the negotiation in the TLS Hello extension. >> > > Yes, I see your point, but the extractors are suitable generally for > only a specific purpose (E.g., DTLS-SRTP) and the negotiation includes > the parameters for that purpose. So, I don't think a generic technique > is appropriate here. > > -Ekr > > I think the document should state that TLS is not concerned at all in case applications export keys from the master_secret; it describes a procedure that should be followed by IANA and authors of future Applications over TLS that need to assign new labels. At the end, the document is developed to avoid exporting keys in insecure way, isn't? IMO, the time a different variant is need means that the TLS-PRF is not more secure. And in this case, we know how to resolve this problem without changing those applications' behavior (cf. cipher suites). Best regards, Badra From Michael.Tuexen@lurchi.franken.de Mon Mar 9 09:54:48 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9238F3A690F for ; Mon, 9 Mar 2009 09:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.465 X-Spam-Level: ** X-Spam-Status: No, score=2.465 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFTFZRj+GJuF for ; Mon, 9 Mar 2009 09:54:47 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id 5FFD73A6C98 for ; Mon, 9 Mar 2009 09:54:47 -0700 (PDT) Received: from [192.168.1.15] (p508FBE01.dip.t-dialin.net [80.143.190.1]) by mail-n.franken.de (Postfix) with ESMTP id E59581C0E96A3; Mon, 9 Mar 2009 17:55:17 +0100 (CET) Message-Id: From: =?ISO-8859-1?Q?Michael_T=FCxen?= To: Eric Rescorla In-Reply-To: <20090309162826.80A5750822@romeo.rtfm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 9 Mar 2009 17:55:16 +0100 References: <20090309161328.92F6950822@romeo.rtfm.com> <20090309162826.80A5750822@romeo.rtfm.com> X-Mailer: Apple Mail (2.930.3) Cc: tls@ietf.org Subject: Re: [TLS] I-D Action:draft-ietf-tls-extractor-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 16:54:48 -0000 On Mar 9, 2009, at 5:28 PM, Eric Rescorla wrote: > At Mon, 9 Mar 2009 17:00:12 +0100 (MET), > Martin Rex wrote: >> >> Eric Rescorla wrote: >>> >>>> >>>> And if they were implementing a new revision of an existing >>>> protocol Bar >>>> over TLS, which has the option of making use of TLS extractor, then >>>> the Bar application protocol will have to use an application-level >>>> negotiation (one round-trip) und the regular TLS protection in >>>> order >>>> to determine whether the new Bar option to use TLS extractors is >>>> available on both sides before it can switch to using it. >>> >>> Yes. I don't see a problem with that. As I said, there are several >>> options. >>> >>> >>>> I don't see a need to make TLS extractors available to one side if >>>> the other side doesn't implmement it (doesn't offer it to the >>>> application caller). Whether and when the application makes use >>>> of it is a different matter. >>> >>> I agree with that, but I'm not sure what your point is. >> >> >> If the availability of TLS-extractors was negotiated between both >> communication peers through a TLS Hello extension, then the decision >> at the application level of Bar whether to use a feature based >> on TLS extractors or to use fallback instead can be entirely >> based on the return value of the respective TLS-extractors API call, >> no negotiation at the application level necessary. >> >> The local API would then be able to produce the following >> error messages: >> >> - TLS-extractor not implemented >> - TLS-peer did not confirm TLS-extractor availability for session >> - OK >> - misc errors (out-of-memory, ...) >> >> And if TLS-wg would want to create a different variant of TLS- >> Extractors >> in the future, one would not have to change the application >> negotiation >> to also negotiate the variants of TLS-Extractors, that would be >> entirely addressed by the negotiation in the TLS Hello extension. > > Yes, I see your point, but the extractors are suitable generally for > only a specific purpose (E.g., DTLS-SRTP) and the negotiation includes > the parameters for that purpose. So, I don't think a generic technique > is appropriate here. Another usage is DTLS/SCTP and it is a requirement to use it. So there is no negotiation necessary. If an implementation does not provide the extractor functionality, you can not use DTLS/SCTP. > > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From huangmin123@huaweisymantec.com Mon Mar 9 04:00:40 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90C053A6C32 for ; Mon, 9 Mar 2009 04:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aY9Ce5O5nz1i for ; Mon, 9 Mar 2009 04:00:34 -0700 (PDT) Received: from mta1.huaweisymantec.com (mta1.huaweisymantec.com [121.15.168.142]) by core3.amsl.com (Postfix) with ESMTP id 3D9C93A6B85 for ; Mon, 9 Mar 2009 04:00:34 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9PX38vaKbLNxvf6LYjgWFw)" Received: from hstml02-in.huaweisymantec.com ([172.26.3.41]) by hstga01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KG8006ZXJXRT090@hstga01-in.huaweisymantec.com> for TLS@ietf.org; Mon, 09 Mar 2009 19:01:05 +0800 (CST) Received: from h00104745 ([10.27.140.207]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPA id <0KG800J0LJXM3E10@hstml02-in.huaweisymantec.com> for TLS@ietf.org; Mon, 09 Mar 2009 19:01:03 +0800 (CST) From: Min Huang To: stefans@exmsft.com Date: Mon, 09 Mar 2009 19:00:58 +0800 Message-id: <001201c9a0a6$54fc3580$cf8c1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmgplOWdTIYGVhvSXq8zQh1pK+pmQ== X-Mailman-Approved-At: Mon, 09 Mar 2009 19:34:16 -0700 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2009 12:45:37 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9PX38vaKbLNxvf6LYjgWFw) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, Stefen I have read the draft-santesson-tls-certcache-00.txt,and I have some questions. 1).In the section 2, "The certificate_hash value MUST include at least one hash value calculated over an expected certificate_list element of a server side Certificate " Why do you say "at least one hash value"? Is there any possibility that can be other hash value? My understanding is that the hash value is the hash of the whole certificate_list of a server side Certificate message. Did I miss something here? 2).In the section 4, "Servers that receive an extended client hello containing a "cached_certs" extension, MAY indicate that they are willing to accept omitting certificate data in the Server Certificate message by including an extension of type "cached_certs" in the (extended) server hello, which SHALL contain a hash received in the cached_certs extension from the client, which is a complete hash calculated over all omitted certificates." Does the two "which" mean the same thing? I think they are not always the same, in some cases they are different.Then the hash value will be which one? 3).There are two editorial errors: a.Section 3 is missing . b. struct { opaque certificate_hash; <1..2^8-1> } CachedCerts; ";" after "certificate_hash" should be put after <1..2^8-1>. regards, Min Huang >Date: Thu, 05 Mar 2009 00:47:44 +0100 >From: Stefan Santesson < stefans@exmsft.com> >Subject: [TLS] New "Fast-Track" draft posted >To: TLS wg < TLS@ietf.org> >Message-ID: < C5D4D1B0.8FC%stefans@exmsft.com> >Content-Type: text/plain; charset="iso-8859-1" >As a result of the discussions we had around last IETF I have now posted a >new ?Fast Track? inspired draft. >The name of this draft is draft-santesson-tls-certcache-00 >It will be available in a few days from the I-D repository. Until then it >can be obtained from the staging site at: > http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt >I have chosen to do a completely new draft instead of updating the old >fast-track document as I have used a very simplified approach as starting >point. >My document is limited to one new TLS extension with the sole purpose of >including a hash of a cached cert path to allow this cert path to be omitted >from the server Certificate message. >I submitted this draft to inject some energy into the discussion again but >I?m not locked on the approach if there are good reasons to expand it. >Please read and provide comments. >I would like to request a small time slot on the TLS meeting agenda in San >Francisco to discuss this if possible. > > >Stefan Santesson >AAA-sec.com --Boundary_(ID_9PX38vaKbLNxvf6LYjgWFw) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
Hi, Stefen
 
I have read the draft-santesson-tls-certcache-00.txt,and I have some questions.
 
1).In the section 2, “The certificate_hash value MUST include at least one hash value calculated over an expected certificate_list element of a server side Certificate ”
 
Why do you say “at least one hash value”? Is there any possibility that can be other hash value? My understanding is that the hash value is the hash of the whole certificate_list of a server side Certificate message. Did I miss something here?
 
2).In the section 4,
“Servers that receive an extended client hello containing a "cached_certs" extension, MAY indicate that they are willing to accept omitting certificate data in the Server Certificate message by including an extension of type "cached_certs" in the (extended) server hello, which SHALL contain a hash received in the cached_certs extension from the client, which is a complete hash calculated over all omitted certificates.”

Does the two “which” mean the same thing? I think they are not always the same, in some cases they are different.Then the hash value will be which one? 
 
3).There are two editorial errors:
a.Section 3 is missing .
b. struct {
     opaque certificate_hash; <1..2^8-1>
  } CachedCerts;
”;” after “certificate_hash” should be put after <1..2^8-1>.
 
regards,
Min Huang
 
 
>Date: Thu, 05 Mar 2009 00:47:44 +0100
>From: Stefan Santesson <stefans@exmsft.com>
>Subject: [TLS] New "Fast-Track" draft posted
>To: TLS wg <TLS@ietf.org>
>Message-ID: <C5D4D1B0.8FC%stefans@exmsft.com>
>Content-Type: text/plain; charset="iso-8859-1"
 
>As a result of the discussions we had around last IETF I have now posted a
>new ?Fast Track? inspired draft.
 
>The name of this draft is  draft-santesson-tls-certcache-00
>It will be available in a few days from the I-D repository. Until then it
>can be obtained from the staging site at:
>http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00.txt
 
>I have chosen to do a completely new draft instead of updating the old
>fast-track document as I have used a very simplified approach as starting
>point.
>My document is limited to one new TLS extension with the sole purpose of
>including a hash of a cached cert path to allow this cert path to be omitted
>from the server Certificate message.
 
>I submitted this draft to inject some energy into the discussion again but
>I?m not locked on the approach if there are good reasons to expand it.
>Please read and provide comments.
 
>I would like to request a small time slot on the TLS meeting agenda in San
>Francisco to discuss this if possible.
>
>
>Stefan Santesson
>AAA-sec.com
--Boundary_(ID_9PX38vaKbLNxvf6LYjgWFw)-- From huangmin123@huaweisymantec.com Tue Mar 10 05:42:25 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40D23A6D0D for ; Tue, 10 Mar 2009 05:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.822 X-Spam-Level: * X-Spam-Status: No, score=1.822 tagged_above=-999 required=5 tests=[AWL=-2.875, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpVvnkpJWjEO for ; Tue, 10 Mar 2009 05:42:23 -0700 (PDT) Received: from mta2.huaweisymantec.com (mta2.huaweisymantec.com [121.15.168.143]) by core3.amsl.com (Postfix) with ESMTP id 53CBB3A6CC5 for ; Tue, 10 Mar 2009 05:42:22 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_HVOVUDVMwAlbxvfGqW/ebg)" Received: from hstml01-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <0KGA00A40JBGAR10@hstga02-in.huaweisymantec.com> for TLS@ietf.org; Tue, 10 Mar 2009 20:42:54 +0800 (CST) Received: from h00104745 ([10.27.140.207]) by hstml01-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTPA id <0KGA00C5DJBBMG10@hstml01-in.huaweisymantec.com> for TLS@ietf.org; Tue, 10 Mar 2009 20:42:52 +0800 (CST) From: Min Huang To: 'Stefan Santesson' Date: Tue, 10 Mar 2009 20:42:46 +0800 Message-id: <002a01c9a17d$b82fbcd0$cf8c1b0a@china.huawei.com> X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: AcmgplOWdTIYGVhvSXq8zQh1pK+pmQALKiGrACqEZAA= In-reply-to: Cc: TLS@ietf.org Subject: [TLS] =?gb2312?b?tPC4tDogTmV3ICJGYXN0LVRyYWNrIiBkcmFmdCBwb3N0ZWQ=?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 12:42:25 -0000 This is a multi-part message in MIME format. --Boundary_(ID_HVOVUDVMwAlbxvfGqW/ebg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi=A3=ACStefan =20 Thank you for your explanation.=20 =20 According to your explanation: =20 =A1=B0the client may include a number of hashes, matching different sets = of server certificate paths.=A1=B1, =A1=B0 The server will compare the = hashes against the hash of the certificate path it intended to send. If there is a = match, the server will indicate the omitted path by including the corresponding hash in its Hello message.=A1=B1 =20 I think above statement or some similar statement should be added to the text. Moreover, some error disposals, such as if there is no matched = hash value in client hello message, what action server would take. IMO, all = of those will make the text clearer. =20 Just my two cents=A1=AD =20 regards, Min _____ =20 =B7=A2=BC=FE=C8=CB: Stefan Santesson [mailto:stefans@exmsft.com]=20 =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA3=D4=C210=C8=D5 0:21 =CA=D5=BC=FE=C8=CB: Min Huang =B3=AD=CB=CD: TLS@ietf.org =D6=F7=CC=E2: Re: New "Fast-Track" draft posted Hi Min, I included the possibility for the client to send more than one hash = simply because I was not sure that there are no situation where that could be useful. So as the text is written now, the client may include a number of = hashes, matching different sets of server certificate paths. This may for = example be 2 hashes for the same server certificate calculated over different certificate paths. The server will compare the hashes against the hash of the certificate = path it intended to send. If there is a match, the server will indicate the omitted path by including the corresponding hash in its Hello message. On 3/9/09 12:00 PM, "Min Huang" wrote: Hi, Stefen =20 I have read the draft-santesson-tls-certcache-00.txt,and I have some questions. =20 1).In the section 2, =A1=B0The certificate_hash value MUST include at = least one hash value calculated over an expected certificate_list element of a = server side Certificate =A1=B1 =20 Why do you say =A1=B0at least one hash value=A1=B1? Is there any = possibility that can be other hash value? My understanding is that the hash value is the = hash of the whole certificate_list of a server side Certificate message. Did = I miss something here? =20 2).In the section 4, =A1=B0Servers that receive an extended client hello containing a = "cached_certs" extension, MAY indicate that they are willing to accept omitting = certificate data in the Server Certificate message by including an extension of type "cached_certs" in the (extended) server hello, which SHALL contain a = hash received in the cached_certs extension from the client, which is a = complete hash calculated over all omitted certificates.=A1=B1 Does the two =A1=B0which=A1=B1 mean the same thing? I think they are not = always the same, in some cases they are different.Then the hash value will be which one?=20 =20 3).There are two editorial errors: a.Section 3 is missing . b. struct { opaque certificate_hash; <1..2^8-1> } CachedCerts; =A1=B1;=A1=B1 after =A1=B0certificate_hash=A1=B1 should be put after = <1..2^8-1>. =20 regards, Min Huang =20 =20 >Date: Thu, 05 Mar 2009 00:47:44 +0100 >From: Stefan Santesson = > >Subject: [TLS] New "Fast-Track" draft posted >To: TLS wg > >Message-ID: > >Content-Type: text/plain; charset=3D"iso-8859-1" =20 >As a result of the discussions we had around last IETF I have now = posted a >new ?Fast Track? inspired draft. =20 >The name of this draft is draft-santesson-tls-certcache-00 >It will be available in a few days from the I-D repository. Until then = it >can be obtained from the staging site at: >http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-00= .tx t = =20 =20 >I have chosen to do a completely new draft instead of updating the old >fast-track document as I have used a very simplified approach as = starting >point. >My document is limited to one new TLS extension with the sole purpose = of >including a hash of a cached cert path to allow this cert path to be omitted >from the server Certificate message. =20 >I submitted this draft to inject some energy into the discussion again = but >I?m not locked on the approach if there are good reasons to expand it. >Please read and provide comments. =20 >I would like to request a small time slot on the TLS meeting agenda in = San >Francisco to discuss this if possible. > > >Stefan Santesson >AAA-sec.com --Boundary_(ID_HVOVUDVMwAlbxvfGqW/ebg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable Re: New "Fast-Track" draft posted
Hi=A3=ACStefan
 
Thank you for = your=20 explanation.
 
According to = your=20 explanation:
 
=A1=B0the = client may include a=20 number of hashes, matching different sets of server certificate = paths.=A1=B1, =A1=B0 The=20 server will compare the hashes against the hash of the certificate path = it=20 intended to send. If there is a match, the server will indicate the = omitted path=20 by including the corresponding hash in its Hello = message.=A1=B1
 
I think above = statement or=20 some similar statement should be added to the text. Moreover, some error = disposals, such as if there = is no=20 matched hash value in client hello message, what action server would take. IMO, all of = those will=20 make the text clearer.
 
Just my two=20 cents=A1=AD
 

regards,
Min

=B7=A2=BC=FE=C8=CB: Stefan Santesson = [mailto:stefans@exmsft.com]=20
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA3=D4=C210=C8=D5 = 0:21
=CA=D5=BC=FE=C8=CB: Min Huang
=B3=AD=CB=CD:=20 TLS@ietf.org
=D6=F7=CC=E2: Re: New "Fast-Track" draft=20 posted

Hi Min,

I included the possibility for = the client=20 to send more than one hash simply because I was not sure that there are = no=20 situation where that could be useful.

So as the text is written = now, the=20 client may include a number of hashes, matching different sets of server = certificate paths. This may for example be 2 hashes for the same server=20 certificate calculated over different certificate paths.
The server = will=20 compare the hashes against the hash of the certificate path it intended = to send.=20 If there is a match, the server will indicate the omitted path by = including the=20 corresponding hash in its Hello message.



On 3/9/09 12:00 = PM, "Min=20 Huang" <huangmin123@huaweisymantec.com>=20 wrote:
Hi, Stefen
 
I have read the=20 draft-santesson-tls-certcache-00.txt,and I have some=20 questions.
 
1).In the section 2, =A1=B0The = certificate_hash value MUST=20 include at least one hash value calculated over an expected = certificate_list=20 element of a server side Certificate =A1=B1
 
Why do you = say =A1=B0at least=20 one hash value=A1=B1? Is there any possibility that can be other hash = value? My=20 understanding is that the hash value is the hash of the whole = certificate_list=20 of a server side Certificate message. Did I miss something=20 here?
 
2).In the section 4,
=A1=B0Servers that receive = an extended=20 client hello containing a "cached_certs" extension, MAY indicate that = they are=20 willing to accept omitting certificate data in the Server Certificate = message=20 by including an extension of type "cached_certs" in the (extended) = server=20 hello, which SHALL contain a hash received in the cached_certs = extension from=20 the client, which is a complete hash calculated over all omitted=20 certificates.=A1=B1

Does the two =A1=B0which=A1=B1 mean the = same thing? I think they=20 are not always the same, in some cases they are different.Then the = hash value=20 will be which one?
 
3).There are two editorial=20 errors:
a.Section 3 is missing .
b. struct=20 {
     opaque certificate_hash;=20 <1..2^8-1>
  } CachedCerts;
=A1=B1;=A1=B1 after = =A1=B0certificate_hash=A1=B1=20 should be put after <1..2^8-1>.
 
regards,
Min=20 Huang
 
 
>Date: Thu, 05 Mar 2009 00:47:44=20 +0100
>From: Stefan Santesson <stefans@exmsft.com <mailto:stefans@exmsft.com>=20 >
>Subject: [TLS] New "Fast-Track" draft posted
>To: = TLS wg=20 <TLS@ietf.org <mailto:TLS@ietf.org> = >
>Message-ID:=20 <C5D4D1B0.8FC%stefans@exmsft.com<= /A>=20 <mailto:C5D4D1B0.8FC%stefa= ns@exmsft.com>=20 >
>Content-Type: text/plain; = charset=3D"iso-8859-1"
 
>As=20 a result of the discussions we had around last IETF I have now posted=20 a
>new ?Fast Track? inspired draft.
 
>The name of = this=20 draft is  draft-santesson-tls-certcache-00
>It will be = available in=20 a few days from the I-D repository. Until then it
>can be = obtained from=20 the staging site at:
>http://www.ietf.org/proceedings/staging/draft-santesson-tls-= certcache-00.txt=20 <http://www.ietf.org/proceedings/staging/draft-santesson-tls-= certcache-00.txt>=20
 
>I have chosen to do a completely new draft instead = of=20 updating the old
>fast-track document as I have used a very = simplified=20 approach as starting
>point.
>My document is limited to = one new=20 TLS extension with the sole purpose of
>including a hash of a = cached=20 cert path to allow this cert path to be omitted
>from the server = Certificate message.
 
>I submitted this draft to inject = some=20 energy into the discussion again but
>I?m not locked on the = approach if=20 there are good reasons to expand it.
>Please read and provide=20 comments.
 
>I would like to request a small time slot = on the=20 TLS meeting agenda in San
>Francisco to discuss this if=20 possible.
>
>
>Stefan=20 = Santesson
>AAA-sec.com

--Boundary_(ID_HVOVUDVMwAlbxvfGqW/ebg)-- From stefans@exmsft.com Tue Mar 10 07:15:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 105FB3A68D8 for ; Tue, 10 Mar 2009 07:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.923 X-Spam-Level: ** X-Spam-Status: No, score=2.923 tagged_above=-999 required=5 tests=[AWL=-4.589, BAYES_40=-0.185, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iR3W7qnu78F for ; Tue, 10 Mar 2009 07:14:55 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id EB5C13A687F for ; Tue, 10 Mar 2009 07:14:54 -0700 (PDT) Received: (qmail 60201 invoked from network); 10 Mar 2009 14:15:33 -0000 Received: from s34.loopia.se (HELO s128.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 10 Mar 2009 14:15:33 -0000 Received: (qmail 93351 invoked from network); 10 Mar 2009 14:15:27 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s128.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Mar 2009 14:15:27 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Tue, 10 Mar 2009 15:15:26 +0100 From: Stefan Santesson To: Min Huang Message-ID: Thread-Topic: =?Big5?B?tarOYA==?=: New "Fast-Track" draft posted Thread-Index: AcmgplOWdTIYGVhvSXq8zQh1pK+pmQALKiGrACqEZAAAA2aw1A== In-Reply-To: <002a01c9a17d$b82fbcd0$cf8c1b0a@china.huawei.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3319542927_1444911" Cc: TLS@ietf.org Subject: Re: [TLS] =?big5?b?tarOYCA6IE5ldyAiRmFzdC1UcmFjayIgZHJhZnQgcG9zdGVk?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 14:15:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3319542927_1444911 Content-type: text/plain; charset="GB2312" Content-transfer-encoding: quoted-printable Thanks Min, I agree on both your comments. I will add text on these matters in the next version of the document. As with the issue what the server would do if there is no match. Then the server would proceed with a normal handshake. But it does not hurt to say so. /Stefan On 3/10/09 1:42 PM, "Min Huang" wrote: > Hi=A3=ACStefan > =20 > Thank you for your explanation. > =20 > According to your explanation: > =20 > =A1=B0the client may include a number of hashes, matching different sets of s= erver > certificate paths.=A1=B1, =A1=B0 The server will compare the hashes against the h= ash of > the certificate path it intended to send. If there is a match, the server= will > indicate the omitted path by including the corresponding hash in its Hell= o > message.=A1=B1 > =20 > I think above statement or some similar statement should be added to the = text. > Moreover, some error disposals, such as if there is no matched hash value= in > client hello message, what action server would take. IMO, all of those wi= ll > make the text clearer. > =20 > Just my two cents=A1=AD > =20 > regards, > Min >=20 >=20 > =B7=A2=BC=FE=C8=CB: Stefan Santesson [mailto:stefans@exmsft.com] > =B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA3=D4=C210=C8=D5 0:21 > =CA=D5=BC=FE=C8=CB: Min Huang > =B3=AD=CB=CD: TLS@ietf.org > =D6=F7=CC=E2: Re: New "Fast-Track" draft posted >=20 > Hi Min, >=20 > I included the possibility for the client to send more than one hash simp= ly > because I was not sure that there are no situation where that could be us= eful. >=20 > So as the text is written now, the client may include a number of hashes, > matching different sets of server certificate paths. This may for example= be 2 > hashes for the same server certificate calculated over different certific= ate > paths. > The server will compare the hashes against the hash of the certificate pa= th it > intended to send. If there is a match, the server will indicate the omitt= ed > path by including the corresponding hash in its Hello message. >=20 >=20 >=20 > On 3/9/09 12:00 PM, "Min Huang" wrote: >=20 >> Hi, Stefen >> =20 >> I have read the draft-santesson-tls-certcache-00.txt,and I have some >> questions. >> =20 >> 1).In the section 2, =A1=B0The certificate_hash value MUST include at least= one >> hash value calculated over an expected certificate_list element of a se= rver >> side Certificate =A1=B1 >> =20 >> Why do you say =A1=B0at least one hash value=A1=B1? Is there any possibility th= at can >> be other hash value? My understanding is that the hash value is the has= h of >> the whole certificate_list of a server side Certificate message. Did I = miss >> something here? >> =20 >> 2).In the section 4, >> =A1=B0Servers that receive an extended client hello containing a "cached_ce= rts" >> extension, MAY indicate that they are willing to accept omitting certif= icate >> data in the Server Certificate message by including an extension of typ= e >> "cached_certs" in the (extended) server hello, which SHALL contain a ha= sh >> received in the cached_certs extension from the client, which is a comp= lete >> hash calculated over all omitted certificates.=A1=B1 >>=20 >> Does the two =A1=B0which=A1=B1 mean the same thing? I think they are not always= the >> same, in some cases they are different.Then the hash value will be whic= h >> one?=20 >> =20 >> 3).There are two editorial errors: >> a.Section 3 is missing . >> b. struct { >> opaque certificate_hash; <1..2^8-1> >> } CachedCerts; >> =A1=B1;=A1=B1 after =A1=B0certificate_hash=A1=B1 should be put after <1..2^8-1>. >> =20 >> regards, >> Min Huang >> =20 >> =20 >>> >Date: Thu, 05 Mar 2009 00:47:44 +0100 >>> >From: Stefan Santesson = > >>> >Subject: [TLS] New "Fast-Track" draft posted >>> >To: TLS wg > >>> >Message-ID: >> > >>> >Content-Type: text/plain; charset=3D"iso-8859-1" >> =20 >>> >As a result of the discussions we had around last IETF I have now pos= ted >>> a >>> >new ?Fast Track? inspired draft. >> =20 >>> >The name of this draft is draft-santesson-tls-certcache-00 >>> >It will be available in a few days from the I-D repository. Until the= n it >>> >can be obtained from the staging site at: >>> >http://www.ietf.org/proceedings/staging/draft-santesson-tls-certcache-= 00.tx >>> t =20 >>> >> t> =20 >> =20 >>> >I have chosen to do a completely new draft instead of updating the ol= d >>> >fast-track document as I have used a very simplified approach as star= ting >>> >point. >>> >My document is limited to one new TLS extension with the sole purpose= of >>> >including a hash of a cached cert path to allow this cert path to be >>> omitted >>> >from the server Certificate message. >> =20 >>> >I submitted this draft to inject some energy into the discussion agai= n but >>> >I?m not locked on the approach if there are good reasons to expand it= . >>> >Please read and provide comments. >> =20 >>> >I would like to request a small time slot on the TLS meeting agenda i= n San >>> >Francisco to discuss this if possible. >>> > >>> > >>> >Stefan Santesson >>> >AAA-sec.com >>=20 >=20 --B_3319542927_1444911 Content-type: text/html; charset="GB2312" Content-transfer-encoding: quoted-printable Re: =B4=F0=B8=B4: New "Fast-Track" draft posted Thanks Min,

I agree on both your comments. I will add text on these matters in the next= version of the document.
As with the issue what the server would do if there is no match. Then the s= erver would proceed with a normal handshake. But it does not hurt to say so.=

/Stefan

On 3/10/09 1:42 PM, "Min Huang" <huangmin123@huaweisymantec.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi=A3=ACStefan
Thank you for your explanation.

According to your explanation:
“the client may include a number of hashes, mat= ching different sets of server certificate paths.”, “ The server= will compare the hashes against the hash of the certificate path it intende= d to send. If there is a match, the server will indicate the omitted path by= including the corresponding hash in its Hello message.”
I think above statement or some similar statement sho= uld be added to the text. Moreover, some error disposals, such as if there i= s no matched hash value in client hello message, what action server would ta= ke. IMO, all of those will make the text clearer.
Just my two cents…
regards,
Min

=B7=A2=BC=FE=C8=CB: Stefan Santesson [mailto:stefans@exmsft.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2009=C4=EA3=D4=C210=C8=D5 0:21
=CA=D5=BC=FE=C8=CB: Min Huang
=B3=AD=CB=CD: TLS@ietf.org
=D6=F7=CC=E2: Re: New "Fast-Track" draft posted

Hi Min,

I included the possibility for the client to send more than one hash simply= because I was not sure that there are no situation where that could be usef= ul.

So as the text is written now, the client may include a number of hashes, m= atching different sets of server certificate paths. This may for example be = 2 hashes for the same server certificate calculated over different certifica= te paths.
The server will compare the hashes against the hash of the certificate path= it intended to send. If there is a match, the server will indicate the omit= ted path by including the corresponding hash in its Hello message.



On 3/9/09 12:00 PM, "Min Huang" <huangmin123@huaweisymantec.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hi, Stefen
 
I have read the  draft-santesson-tls-certcache-00.txt,and I have some =  questions.
 
1).In the section 2, “The certificate_hash value MUST  include a= t least one hash value calculated over an expected certificate_list  el= ement of a server side Certificate ”
 
Why do you say “at least  one hash value”? Is there any po= ssibility that can be other hash value? My  understanding is that the h= ash value is the hash of the whole certificate_list  of a server side C= ertificate message. Did I miss something  here?
 
2).In the section 4,
“Servers that receive an extended  client hello containing a &qu= ot;cached_certs" extension, MAY indicate that they are  willing to= accept omitting certificate data in the Server Certificate message  by= including an extension of type "cached_certs" in the (extended) s= erver  hello, which SHALL contain a hash received in the cached_certs e= xtension from  the client, which is a complete hash calculated over all= omitted  certificates.”

Does the two “which” mean the same thing? I think they  ar= e not always the same, in some cases they are different.Then the hash value =  will be which one?
 
3).There are two editorial  errors:
a.Section 3 is missing .
b. struct  {
     opaque certificate_hash;  <1..2^8-1&g= t;
  } CachedCerts;
”;” after “certificate_hash”  should be put af= ter <1..2^8-1>.
 
regards,
Min  Huang
 
 
>Date: Thu, 05 Mar 2009 00:47:44  +0100
>From: Stefan Santesson <stefans@exmsft.= com <mailto:stefans@exmsft.com>  >
>Subject: [TLS] New "Fast-Track" draft posted
>To: TLS wg  <TLS@ietf.org <mailto:TLS@ietf.org> >
>Message-ID:  <C5D4D1B= 0.8FC%stefans@exmsft.com  <mailto:C5D4D1B0.8FC%stefans@exmsft.com>  >
>Content-Type: text/plain; charset=3D"iso-8859-1"
 
>As  a result of the discussions we had around last IETF I have now= posted  a
>new ?Fast Track? inspired draft.
 
>The name of this  draft is  draft-santesson-tls-certcache-00<= BR> >It will be available in  a few days from the I-D repository. Until= then it
>can be obtained from  the staging site at:
>http://www.ietf.org/proceedings/staging/draft-santesson-tls-= certcache-00.txt  <http://www.ietf.org/proceedings/st= aging/draft-santesson-tls-certcache-00.txt>  
 
>I have chosen to do a completely new draft instead of  updating th= e old
>fast-track document as I have used a very simplified  approach as = starting
>point.
>My document is limited to one new  TLS extension with the sole pur= pose of
>including a hash of a cached  cert path to allow this cert path to= be omitted
>from the server  Certificate message.
 
>I submitted this draft to inject some  energy into the discussion = again but
>I?m not locked on the approach if  there are good reasons to expan= d it.
>Please read and provide  comments.
 
>I would like to request a small time slot on the  TLS meeting agen= da in San
>Francisco to discuss this if  possible.
>
>
>Stefan  Santesson
>AAA-sec.com

=
--B_3319542927_1444911-- From Martin.Rex@sap.com Tue Mar 10 09:53:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC483A68FB for ; Tue, 10 Mar 2009 09:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.585 X-Spam-Level: X-Spam-Status: No, score=-5.585 tagged_above=-999 required=5 tests=[AWL=0.664, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kX0lHD+sTzzV for ; Tue, 10 Mar 2009 09:53:48 -0700 (PDT) Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 847BF3A6B45 for ; Tue, 10 Mar 2009 09:53:48 -0700 (PDT) Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n2AGs5dx011891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2009 17:54:05 +0100 (MET) From: Martin Rex Message-Id: <200903101654.n2AGs4ED024335@fs4113.wdf.sap.corp> To: stefans@exmsft.com (Stefan Santesson) Date: Tue, 10 Mar 2009 17:54:04 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Mar 9, 9 05:20:39 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 Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 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: , X-List-Received-Date: Tue, 10 Mar 2009 16:53:49 -0000 Stefan Santesson wrote: > > I included the possibility for the client to send more than one hash simply > because I was not sure that there are no situation where that could be > useful. > > So as the text is written now, the client may include a number of hashes, > matching different sets of server certificate paths. This may for example be > 2 hashes for the same server certificate calculated over different > certificate paths. > The server will compare the hashes against the hash of the certificate path > it intended to send. If there is a match, the server will indicate the > omitted path by including the corresponding hash in its Hello message. I think the peculiarities of the caching of the "server certification path" should be described with a few examples in order to make it clear what is actually meant here. At first, I was wondering why a client would collect/cache more than one certification path as "valid" in the first place. Certainly there is no need to preculude that the client can learn certificates in an out-of-band fashion and that it could "guess" hashes for certification paths that a server might send based on certificates there were learned/configured out-of-band--but it is not the general case that this spec should address. Normally, the client should learn ("cache") the path from a previous full handshake with the server, and the client should probably replace the cached certification path entirely if the server does respond with a full path instead of the omission--rather than collecting pathes and starting to announce all of the hashes for all of the cached certification pathes that a specific server has ever used in the past. Now what exactly are the characteristics for assuming that it already possesses a server certification path (this is related to the clients decision when to propose resuming a cached TLS session, but it's slightly different). When client-side proxies are involved (aka HTTP CONNECT proxies), then the target IP-address visible at the network socket is pretty useless for distinguishing entries in the client-side cache. The client probably needs access to the hostname that was used to open the network connection (or the proxy CONNECT). A TLS session resume always implies a fixed set of connection attributes (ciphersuite, server certification path). How much should a cached server certification path imply? Any particular certification path (if agreed to by the server) will restrict the subset of TLS ciphersuites that can be used based on the keytype of the server certificate in that path, e.g. DSA-cihpersuites require a server cert with a DSA-key, ECDSA-ciphersuites require a server cert with an ECDSA-key, RSA-ciphersuites require a server cert with an RSA-key, DHE-RSA ciphersuites require a server cert with an RSA-key which must have "digitalSignature" keyUsage asserted, DH-RSA ciphersuites require a server cert with a DH key, etc. I think the document should provide guidance when to "update the cache" when the server sends a full certification path instead of the omission, and when the client should or could store the full certification path sent by the server as a valid alternative. -Martin From rfc-editor@rfc-editor.org Tue Mar 10 11:15:13 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7020A3A69B8; Tue, 10 Mar 2009 11:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.905 X-Spam-Level: X-Spam-Status: No, score=-16.905 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp8LgbDd+ztM; Tue, 10 Mar 2009 11:15:08 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 404E33A684C; Tue, 10 Mar 2009 11:14:12 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 00C3D24B6A6; Tue, 10 Mar 2009 11:12:55 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090310181255.00C3D24B6A6@bosco.isi.edu> Date: Tue, 10 Mar 2009 11:12:55 -0700 (PDT) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 5487 on Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2009 18:15:13 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5487 Title: Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode Author: M. Badra Status: Standards Track Date: March 2009 Mailbox: badra@isima.fr Pages: 7 Characters: 15537 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-psk-new-mac-aes-gcm-05.txt URL: http://www.rfc-editor.org/rfc/rfc5487.txt RFC 4279 and RFC 4785 describe pre-shared key cipher suites for Transport Layer Security (TLS). However, all those cipher suites use SHA-1 in their Message Authentication Code (MAC) algorithm. This document describes a set of pre-shared key cipher suites for TLS that uses stronger digest algorithms (i.e., SHA-256 or SHA-384) and another set that uses the Advanced Encryption Standard (AES) in Galois Counter Mode (GCM). [STANDARDS TRACK] This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From kanno-s@po.ntts.co.jp Tue Mar 10 20:09:52 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E632E3A69BF for ; Tue, 10 Mar 2009 20:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvGtNOU2xLxM for ; Tue, 10 Mar 2009 20:09:52 -0700 (PDT) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id 04D553A681D for ; Tue, 10 Mar 2009 20:09:51 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id n2B3ALVZ025799; Wed, 11 Mar 2009 12:10:21 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id n2B3ALRb022986; Wed, 11 Mar 2009 12:10:21 +0900 (JST) Received: from ccm19.silk.ntts.co.jp [10.7.18.19] by sadoku34.silk.ntts.co.jp with SMTP id NAA22985; Wed, 11 Mar 2009 12:10:21 +0900 Received: from mail16.silk.ntts.co.jp (localhost [127.0.0.1]) by ccm19.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2B3ALCF004802; Wed, 11 Mar 2009 12:10:21 +0900 (JST) Received: from mail16.silk.ntts.co.jp (localhost [127.0.0.1]) by mail16.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2B3ALjj005670; Wed, 11 Mar 2009 12:10:21 +0900 (JST) Received: from [127.0.0.1] ([10.7.206.148]) by mail16.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2B3AHtS005639; Wed, 11 Mar 2009 12:10:21 +0900 (JST) Date: Wed, 11 Mar 2009 12:10:18 +0900 From: Satoru Kanno To: Nelson B Bolyard In-Reply-To: <49A7207D.20606@bolyard.me> References: <20090227005322.336D.KANNO-S@po.ntts.co.jp> <49A7207D.20606@bolyard.me> X-Face: ,\m{?h\)X Message-Id: <20090311120843.EE93.KANNO-S@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.02 [ja] X-CC-Mail-RelayStamp: CC-Mail-V4-Client X-CC-Mail-RelayStamp: CC-Mail-V4-Server Cc: tls@ietf.org Subject: Re: [TLS] draft-kato-tls-rfc4132bis-03 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:09:53 -0000 On Thu, 26 Feb 2009 15:06:37 -0800 Nelson B Bolyard wrote: > Satoru Kanno wrote, On 2009-02-26 08:19: > > Hi, List > > > > We've uploaded an updated 'Camellia Cipher Suites for TLS', > > and is available at > > > > http://www.ietf.org/internet-drafts/draft-kato-tls-rfc4132bis-03.txt > > > > Please check our document. > > > > Of course, comments and questions about our document would be welcome. > > > > Best regards, > > > > -- > > Satoru Kanno > > Please provide a brief summary of the differences between this document > and RFC 4132. Since RFC 4132 is implemented in recent versions of > Firefox, I am interested in knowing if the new document necessitates > any changes that might present interoperability issues with implementations > of that RFC. > > Regards, > /Nelson Bolyard Hi Nelson, The differences between this draft and RFC 4132 are addition of Camellia ciphersuites for TLSv1.2. New ciphersuites of this document are as follows: CipherSuite TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 CipherSuite TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256 CipherSuite TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256 CipherSuite TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256 CipherSuite TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256 CipherSuite TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256 CipherSuite TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 CipherSuite TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256 Best regards, -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno-s@po.ntts.co.jp From kanno-s@po.ntts.co.jp Tue Mar 10 20:27:49 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1CA3A6A13 for ; Tue, 10 Mar 2009 20:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.21 X-Spam-Level: X-Spam-Status: No, score=0.21 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLngH6mR6VOt for ; Tue, 10 Mar 2009 20:27:48 -0700 (PDT) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id 412A43A6970 for ; Tue, 10 Mar 2009 20:27:48 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id n2B3SNOO026183; Wed, 11 Mar 2009 12:28:23 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id n2B3SNR7023837; Wed, 11 Mar 2009 12:28:23 +0900 (JST) Received: from ccm19.silk.ntts.co.jp [10.7.18.19] by sadoku34.silk.ntts.co.jp with SMTP id NAA23836; Wed, 11 Mar 2009 12:28:23 +0900 Received: from mail16.silk.ntts.co.jp (localhost [127.0.0.1]) by ccm19.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2B3SM65004984; Wed, 11 Mar 2009 12:28:22 +0900 (JST) Received: from mail16.silk.ntts.co.jp (localhost [127.0.0.1]) by mail16.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2B3SMR5013195; Wed, 11 Mar 2009 12:28:22 +0900 (JST) Received: from [127.0.0.1] ([10.7.206.148]) by mail16.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2B3RpD7012982; Wed, 11 Mar 2009 12:28:22 +0900 (JST) Date: Wed, 11 Mar 2009 12:27:52 +0900 From: Satoru Kanno To: Mohamad Badra In-Reply-To: <49AEA61B.5070407@isima.fr> References: <200903041143.MAA23377@TR-Sys.de> <49AEA61B.5070407@isima.fr> X-Face: ,\m{?h\)X Message-Id: <20090311122550.EE98.KANNO-S@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.02 [ja] X-CC-Mail-RelayStamp: CC-Mail-V4-Client X-CC-Mail-RelayStamp: CC-Mail-V4-Server Cc: Alfred , draft-kato-tls-rfc4132bis@tools.ietf.org, tls@ietf.org Subject: Re: [TLS] draft-kato-tls-rfc4132bis-03 : get rid of unneeded prose X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 03:27:49 -0000 Hi Alfred, Badra, Thank you for useful comments. On Wed, 04 Mar 2009 17:02:35 +0100 Mohamad Badra wrote: > Hi, > > I agree with Alfred, the document should avoid repeating details > regarding Camellia block cipher. IMO, a pointer to RFC3713 is sufficient. We revised this document based on Alfred and Mohamad's comments. > To help the reader, it may be better to separate SHA1 and SHA2 into two > Sections. An application statement on using them with different TLS > version should be useful. We separate '3.3. Hash and Pseudorandom Function' to '3.3.1. Hash and Pseudorandom Function for TLS 1.1' and '3.3.2. Hash and Pseudorandom Function for TLS 1.2'. This revised document will appear after 23 March 2009 at midnight(PT). Please check it later. Best regards, --- Satoru Kanno > Best regards, > Badra > > > Hello, > > > > The 'Introduction' of draft-kato-tls-rfc4132bis-03 still contains > > a lot of details regarding the Camellia cipher primitive proper, > > which IMO are out of scope and not needed for this document > > describing the use of that building block in TLS. > > > > The fundamental reference, RFC 3713, already contains what needs > > to be said, and it is not very useful to have every document > > making use of that cipher repeat the same or similar verbiage. > > > > I strongly suggest that the bulk of the 'marketing prose' in Section 1 > > (para 2 ff.) be removed from the draft -- in a similar manner as > > it has been done now for the companion Camellia for IPsec draft. > > > > > > Otherwise, I suggest that the WG consider the portfolio question > > I already had raised in > > http://www.IETF.ORG/mail-archive/web/tls/current/msg03242.html > > (combining Camellia-256 with SHA-384 instead of SHA-256) > > and make a decision on whether that document should be adopted as > > a WG document or recommended as an individual submission for PS. > > > > Thoughts? Opinions? > > > > > > Kind regards, > > Alfred H?nes. > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno-s@po.ntts.co.jp From A.Hoenes@tr-sys.de Wed Mar 11 05:01:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFD73A687D for ; Wed, 11 Mar 2009 05:01:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.618 X-Spam-Level: * X-Spam-Status: No, score=1.618 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0wiNsFrj15n for ; Wed, 11 Mar 2009 05:01:54 -0700 (PDT) Received: from WOTAN.TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by core3.amsl.com (Postfix) with ESMTP id 5EE703A6BAD for ; Wed, 11 Mar 2009 05:01:52 -0700 (PDT) Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3) id AA270612831; Wed, 11 Mar 2009 13:00:31 +0100 Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id NAA11026; Wed, 11 Mar 2009 13:00:29 +0100 (MEZ) From: Alfred =?hp-roman8?B?SM5uZXM=?= Message-Id: <200903111200.NAA11026@TR-Sys.de> To: ekr@rtfm.com, tls@ietf.org Date: Wed, 11 Mar 2009 13:00:29 +0100 (MEZ) X-Mailer: ELM [$Revision: 1.17.214.3 $] Mime-Version: 1.0 Content-Type: text/plain; charset=hp-roman8 Content-Transfer-Encoding: 8bit Subject: [TLS] draft-ietf-tls-extractor-05 WGLC comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 12:01:55 -0000 Hello, First of all, I want to confirm that most of the changes I had proposed in the past now have been incorportated into the most recent 'TLS extractor' draft version, draft-ietf-tls-extractor-05. An iterated review unveiled the following flaws left in / added newly: (1) collateral damage of change in term "extractor" --> "exporter" There's a linguistical problem with the 1:1 replacement performed. For "extractor", the active entity is the recipient, for "exporter", the active part is the one giving something away. Therefore, the schematic replacement has caused a few semantical contortions of the text that should be corrected, to avoid confusion. In sentences stated originally with 'the application' in mind as the active role, it might be better to now talk about "import" in order to give back the active role to the application entity, or change the sentence otherwise, giving the active role to TLS/DTLS when using "export". Also, typical use is (and was in the draft) "extract _from_" ; for the 'economical picture', it is "export by/to" or "import to/from". To correct the semantics in an unambiguous way, I suggest to apply at least the following two textual changes: (1a) Section 3, 1st paragraph OLD: vvvvvvvvv vvvvvvvvvvvvvv | In addition to exporting keying material, an application using the keying material has to securely establish the upper-layer context where the keying material will be used. [...] As mentioned above, the _application_ does not 'export' the keying material, as alluded by this sentence, which would be clearly forbidden for security reasons (binding the secret to the application context). Thus, it would be much preferable to say: NEW: vv | In addition to importing keying material, an application using the keying material has to securely establish the upper-layer context where the keying material will be used. [...] (1b) Section 3, last bullet OLD: o The upper-layer protocol can include its own handshake which can | be protected using the keys exported from TLS. ^^^^^^^^ NEW: o The upper-layer protocol can include its own handshake which can | be protected using the keys imported from TLS. ^^ (2) Nits (2a) Section 3, 1st paragraph, last sentence s/At minimum,/At a minimum,/ (or use "At least"). (2b) Section 6, last paragraph In the prose: s/RF5226/RFC 5226/ . (3) Section 4 It looks like an important clause has been dropped inadvertantly after the first paragraph, making the flow of reasoning unintelligible. OLD: The output of the exporter is intended to be used in a single scope, which is associated with the TLS session, the label, and the context value. | o A disambiguating label string o A per-association context value provided by the application using the exporter o A length value ! It then computes: [...] The "then" does not make sense any more, because the indication of what happens with the items in the 3 bullets has been lost. I suggest to restore the clause from earlier draft versions, with the appropriate change in terminology applied, and modify the punctuation and capitalization within the bullets: NEW: The output of the exporter is intended to be used in a single scope, which is associated with the TLS session, the label, and the context value. | | The exporter takes three input values: | | o a disambiguating label string, o a per-association context value provided by the application using | the exporter, and | o a length value. It then computes: [...] (4) Section 6 (4a) As discussed off-list in the past, the label "master secret" contained in the list of initial registrations plays a specific role. It is *not* intended to be used by the mechanism described in the draft; it has been entered for the sole purpose to avoid registering this value in the future and thereby causing possible confusion with the unrelated use of that string in RFC 5246. Note: The algorithm in Section 3 starts with the master_secret, but in contrast, the algorithm in RFC 5246 making use of the label "master secret" does so in constructing the master_secret (from the premaster secret). Thus, the role of the entry for "master secret" is quite different than the other entries; it it NOT to be used with a formula like the one given in Section 3; thus, this is in fact a _reserved_ entry. The label "key expansion" is used in RFC 5246 (section 6.3) in a formula closely resembling the formula in setcion 3 of the draft, but without the 'context related components. Hence, this label needs to be protected to avoid possible confusion, and the entry is to be regarded as a _reserved_ entry as well, not for actual use according to section 3 of the draft. The other labels from RFC 5246, "client finished" and "server finished", are not used in any way for keying material derivation and are to be reserved as well. To make that fully clear to readers of the document and the (future) IANA registry, I suggest to amend the table by a note indicating that. (4b) Furthermore, RFC 2716 has been Obsoleted by RFC 5216; the Reference in the table should be changed accordingly. Section 8 anyway does not contain an entry '[RFC2716]' ; an entry for RFC 5216 should be added. (4c) Taking (4a) and (4b) together, I suggest to change, including some small facelifting to the table heading: OLD: | Value Reference | ----- ------------ | client finished [RFC5246] | server finished [RFC5246] | master secret [RFC5246] | key expansion [RFC5246] | client EAP encryption [RFC2716] ttls keying material [RFC5281] ttls challenge [RFC5281] NEW: | Value Reference Note | ----------------------------- --------- ---- | client finished [RFC5246] (1) | server finished [RFC5246] (1) | master secret [RFC5246] (1) | key expansion [RFC5246] (1) | client EAP encryption [RFC5216] ttls keying material [RFC5281] ttls challenge [RFC5281] | | Note(1): These entries are reserved and MUST NOT be used for | the purpose described in RFC XXXX, in order to avoid | confusion with similar, but distinct use in RFC 5246. | | [ RFC Editor: Please replace 'XXXX' above by the RFC number assigned | to this document and delete this remark. ] (5) Section 8.1 As indicated in (4b) above, an entry for RFC 5216 should be added. Kind regards, Alfred HÎnes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | +------------------------+--------------------------------------------+ From ekr@networkresonance.com Wed Mar 11 07:48:39 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085163A69C4 for ; Wed, 11 Mar 2009 07:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qxPVnC-Hkv5 for ; Wed, 11 Mar 2009 07:48:35 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C8AA03A679F for ; Wed, 11 Mar 2009 07:48:34 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 19F9A50822; Wed, 11 Mar 2009 08:12:04 -0700 (PDT) Date: Wed, 11 Mar 2009 08:12:04 -0700 From: Eric Rescorla To: Alfred =?hp-roman8?B?SM5uZXM=?= In-Reply-To: <200903111200.NAA11026@TR-Sys.de> References: <200903111200.NAA11026@TR-Sys.de> 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: <20090311151204.19F9A50822@romeo.rtfm.com> Cc: ekr@rtfm.com, tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-extractor-05 WGLC comments X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2009 14:48:39 -0000 At Wed, 11 Mar 2009 13:00:29 +0100 (MEZ), Alfred =?hp-roman8?B?SM5uZXM=?= wrote: > > Hello, > > First of all, I want to confirm that most of the changes I had > proposed in the past now have been incorportated into the most > recent 'TLS extractor' draft version, draft-ietf-tls-extractor-05. > > An iterated review unveiled the following flaws left in / added newly: > > > (1) collateral damage of change in term "extractor" --> "exporter" > > There's a linguistical problem with the 1:1 replacement performed. > > For "extractor", the active entity is the recipient, for "exporter", > the active part is the one giving something away. > > Therefore, the schematic replacement has caused a few semantical > contortions of the text that should be corrected, to avoid confusion. > > In sentences stated originally with 'the application' in mind as the > active role, it might be better to now talk about "import" in order > to give back the active role to the application entity, or change the > sentence otherwise, giving the active role to TLS/DTLS when using > "export". > > Also, typical use is (and was in the draft) "extract _from_" ; for > the 'economical picture', it is "export by/to" or "import to/from". > > To correct the semantics in an unambiguous way, I suggest to apply > at least the following two textual changes: > > (1a) Section 3, 1st paragraph > > OLD: > vvvvvvvvv vvvvvvvvvvvvvv > | In addition to exporting keying material, an application using the > keying material has to securely establish the upper-layer context > where the keying material will be used. [...] > > As mentioned above, the _application_ does not 'export' the keying > material, as alluded by this sentence, which would be clearly > forbidden for security reasons (binding the secret to the > application context). Thus, it would be much preferable to say: > > NEW: > vv > | In addition to importing keying material, an application using the > keying material has to securely establish the upper-layer context > where the keying material will be used. [...] Sure. > (1b) Section 3, last bullet > > OLD: > > o The upper-layer protocol can include its own handshake which can > | be protected using the keys exported from TLS. > ^^^^^^^^ > NEW: > > o The upper-layer protocol can include its own handshake which can > | be protected using the keys imported from TLS. I prefer "exported by" here, actually. > (2) Nits > > (2a) Section 3, 1st paragraph, last sentence > > s/At minimum,/At a minimum,/ (or use "At least"). Sure. > (2b) Section 6, last paragraph > > In the prose: s/RF5226/RFC 5226/ . Sure. > (3) Section 4 > > It looks like an important clause has been dropped inadvertantly after > the first paragraph, making the flow of reasoning unintelligible. > > OLD: > > The output of the exporter is intended to be used in a single scope, > which is associated with the TLS session, the label, and the context > value. > | > o A disambiguating label string > o A per-association context value provided by the application using > the exporter > o A length value > > ! It then computes: > > [...] > > The "then" does not make sense any more, because the indication of > what happens with the items in the 3 bullets has been lost. > I suggest to restore the clause from earlier draft versions, > with the appropriate change in terminology applied, > and modify the punctuation and capitalization within the bullets: > > NEW: > > The output of the exporter is intended to be used in a single scope, > which is associated with the TLS session, the label, and the context > value. > | > | The exporter takes three input values: > | > | o a disambiguating label string, > o a per-association context value provided by the application using > | the exporter, and > | o a length value. > > It then computes: > > [...] Agreed. My bad. > (4) Section 6 > > (4a) > As discussed off-list in the past, the label "master secret" > contained in the list of initial registrations plays a specific > role. It is *not* intended to be used by the mechanism described > in the draft; it has been entered for the sole purpose to avoid > registering this value in the future and thereby causing possible > confusion with the unrelated use of that string in RFC 5246. > > Note: The algorithm in Section 3 starts with the master_secret, > but in contrast, the algorithm in RFC 5246 making use of the > label "master secret" does so in constructing the master_secret > (from the premaster secret). > > Thus, the role of the entry for "master secret" is quite different > than the other entries; it it NOT to be used with a formula like the > one given in Section 3; thus, this is in fact a _reserved_ entry. > > The label "key expansion" is used in RFC 5246 (section 6.3) in a > formula closely resembling the formula in setcion 3 of the draft, > but without the 'context related components. > Hence, this label needs to be protected to avoid possible confusion, > and the entry is to be regarded as a _reserved_ entry as well, not > for actual use according to section 3 of the draft. > > The other labels from RFC 5246, "client finished" and "server finished", > are not used in any way for keying material derivation and are to be > reserved as well. > > To make that fully clear to readers of the document and the (future) > IANA registry, I suggest to amend the table by a note indicating that. > > (4b) > Furthermore, RFC 2716 has been Obsoleted by RFC 5216; the Reference > in the table should be changed accordingly. Section 8 anyway does not > contain an entry '[RFC2716]' ; an entry for RFC 5216 should be added. > > (4c) > Taking (4a) and (4b) together, I suggest to change, including some > small facelifting to the table heading: > > OLD: > > | Value Reference > | ----- ------------ > | client finished [RFC5246] > | server finished [RFC5246] > | master secret [RFC5246] > | key expansion [RFC5246] > | client EAP encryption [RFC2716] > ttls keying material [RFC5281] > ttls challenge [RFC5281] > > NEW: > > | Value Reference Note > | ----------------------------- --------- ---- > | client finished [RFC5246] (1) > | server finished [RFC5246] (1) > | master secret [RFC5246] (1) > | key expansion [RFC5246] (1) > | client EAP encryption [RFC5216] > ttls keying material [RFC5281] > ttls challenge [RFC5281] > | > | Note(1): These entries are reserved and MUST NOT be used for > | the purpose described in RFC XXXX, in order to avoid > | confusion with similar, but distinct use in RFC 5246. > | > | [ RFC Editor: Please replace 'XXXX' above by the RFC number assigned > | to this document and delete this remark. ] This seems fine. > (5) Section 8.1 > > As indicated in (4b) above, an entry for RFC 5216 should be added. This too. -Ekr From Pasi.Eronen@nokia.com Thu Mar 12 10:13:09 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF34B3A6BF6 for ; Thu, 12 Mar 2009 10:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.498 X-Spam-Level: X-Spam-Status: No, score=-6.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFusi7tQuvC7 for ; Thu, 12 Mar 2009 10:13:04 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D61693A6BC8 for ; Thu, 12 Mar 2009 10:13:03 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n2CHDXdF022752 for ; Thu, 12 Mar 2009 19:13:38 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 19:13:19 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Mar 2009 19:13:19 +0200 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 12 Mar 2009 18:13:18 +0100 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Thu, 12 Mar 2009 18:13:18 +0100 From: To: Date: Thu, 12 Mar 2009 18:13:21 +0100 Thread-Topic: Working Group Last Call draft-ietf-tls-extractor-05.txt Thread-Index: AcmghPVjhln65VGrRgC/w67zgZAoOACsKp4A Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F1EF9075@NOK-EUMSG-01.mgdnok.nokia.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-OriginalArrivalTime: 12 Mar 2009 17:13:19.0139 (UTC) FILETIME=[D6EF9730:01C9A335] X-Nokia-AV: Clean Subject: Re: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:13:09 -0000 It seems my comments from the previous WG "last" call (for=20 revision -03) were somehow missed: http://www.ietf.org/mail-archive/web/tls/current/msg03037.html Copying the comments here: In general, the document looks good; I have only minor nits: In Section 4, the context value is shown as "opaque context<0..2^16-1>" (and Alfred pointed out that it probably should be "context_value"). Now, if the PRF computation (slightly earlier in Section 4) uses the normal TLS presentation language notation (not an unreasonable assumption!), it would mean the length is included=20 twice (two uint16). That's probably not the intention (but folks have been confused about the exact number of length fields before, and this did cause some interop problems around TLS 1.0 time). My=20 suggestion would be just to delete the line "opaque context<0..2^16-1>";=20 it's not really needed, and without it, everything looks umambiguous. It might be good to explicitly point out that designing a secure mechanism that uses this extractor is rather difficult, and this document does not tell how to do it (and IMHO does not need to). The extractor gives you a key (that's easy), but the difficult part=20 is securely agreeing on everything else in the "security assocation"=20 or "application context". Although Section 3 gives some ideas on how=20 this can be done, it's very far from "here's how you securely use=20 this thing" instructions. Editorial: - Section 5: "MUST not" -> "MUST NOT"=20 - Missing Reference: 'DTLS-SRTP' is mentioned on line 114, but not defined - Missing Reference: 'RFC2716' is mentioned on line 211, but not defined - Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) - Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) - Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) Two new nits: - Reference RFC5281 should be Informative - Title of 8.2 should be "Informative References", not "Informational" Best regards, Pasi= From ekr@networkresonance.com Thu Mar 12 10:30:08 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 745ED3A690F for ; Thu, 12 Mar 2009 10:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jF6xcgjwVqX for ; Thu, 12 Mar 2009 10:30:03 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9CC7F3A680B for ; Thu, 12 Mar 2009 10:30:03 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 48C6C50822; Thu, 12 Mar 2009 10:53:34 -0700 (PDT) Date: Thu, 12 Mar 2009 10:53:34 -0700 From: Eric Rescorla To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F1EF9075@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F1EF9075@NOK-EUMSG-01.mgdnok.nokia.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: <20090312175334.48C6C50822@romeo.rtfm.com> Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call draft-ietf-tls-extractor-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 17:30:08 -0000 At Thu, 12 Mar 2009 18:13:21 +0100, wrote: > > > > It seems my comments from the previous WG "last" call (for > revision -03) were somehow missed: > http://www.ietf.org/mail-archive/web/tls/current/msg03037.html They were indeed. Fire the editor! I'll work to incorporate them. -Ekr > Copying the comments here: > > In general, the document looks good; I have only minor nits: > > In Section 4, the context value is shown as "opaque > context<0..2^16-1>" (and Alfred pointed out that it probably should be > "context_value"). Now, if the PRF computation (slightly earlier in > Section 4) uses the normal TLS presentation language notation > (not an unreasonable assumption!), it would mean the length is included > twice (two uint16). That's probably not the intention (but folks > have been confused about the exact number of length fields before, > and this did cause some interop problems around TLS 1.0 time). My > suggestion would be just to delete the line "opaque context<0..2^16-1>"; > it's not really needed, and without it, everything looks umambiguous. > > It might be good to explicitly point out that designing a secure > mechanism that uses this extractor is rather difficult, and this > document does not tell how to do it (and IMHO does not need to). > The extractor gives you a key (that's easy), but the difficult part > is securely agreeing on everything else in the "security assocation" > or "application context". Although Section 3 gives some ideas on how > this can be done, it's very far from "here's how you securely use > this thing" instructions. > > Editorial: > - Section 5: "MUST not" -> "MUST NOT" > - Missing Reference: 'DTLS-SRTP' is mentioned on line 114, but not defined > - Missing Reference: 'RFC2716' is mentioned on line 211, but not defined > - Obsolete undefined reference: RFC 2716 (Obsoleted by RFC 5216) > - Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) > - Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246) > > Two new nits: > - Reference RFC5281 should be Informative > - Title of 8.2 should be "Informative References", not "Informational" > > Best regards, > Pasi > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From stefans@exmsft.com Thu Mar 12 11:15:53 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392503A6BF6 for ; Thu, 12 Mar 2009 11:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6Tv0b41EsMR for ; Thu, 12 Mar 2009 11:15:52 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.95.112]) by core3.amsl.com (Postfix) with ESMTP id BF5C63A6C0C for ; Thu, 12 Mar 2009 11:15:51 -0700 (PDT) Received: (qmail 34744 invoked from network); 12 Mar 2009 18:16:33 -0000 Received: from s34.loopia.se (HELO s29.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Mar 2009 18:16:33 -0000 Received: (qmail 43572 invoked from network); 12 Mar 2009 18:16:27 -0000 Received: from 90-229-233-249-no153.tbcn.telia.com (HELO [192.168.0.17]) (stefan@fiddler.nu@[90.229.233.249]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 12 Mar 2009 18:16:26 -0000 User-Agent: Microsoft-Entourage/12.15.0.081119 Date: Thu, 12 Mar 2009 19:16:25 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: [TLS] New "Fast-Track" draft posted Thread-Index: AcmjPqd8/sjRQ3F5/kuPO5qC0R4elg== In-Reply-To: <200903101654.n2AGs4ED024335@fs4113.wdf.sap.corp> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: TLS@ietf.org Subject: Re: [TLS] New "Fast-Track" draft posted X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2009 18:15:53 -0000 Martin, Thanks for your extensive feedback. Comments in-line. /Stefan On 3/10/09 5:54 PM, "Martin Rex" wrote: > Stefan Santesson wrote: >> >> I included the possibility for the client to send more than one hash simply >> because I was not sure that there are no situation where that could be >> useful. >> >> So as the text is written now, the client may include a number of hashes, >> matching different sets of server certificate paths. This may for example be >> 2 hashes for the same server certificate calculated over different >> certificate paths. >> The server will compare the hashes against the hash of the certificate path >> it intended to send. If there is a match, the server will indicate the >> omitted path by including the corresponding hash in its Hello message. > > > I think the peculiarities of the caching of the "server certification path" > should be described with a few examples in order to make it clear what > is actually meant here. At first, I was wondering why a client would > collect/cache more than one certification path as "valid" in the first place. > Agree, I think it is reasonable to make such clarification. > > Certainly there is no need to preculude that the client can learn > certificates in an out-of-band fashion and that it could "guess" > hashes for certification paths that a server might send based on > certificates there were learned/configured out-of-band--but it is > not the general case that this spec should address. > I also imagine that we may have situations with clusters of hosts and/or proxies with slight difference in configuration and where some servers are configured to send e.g. The whole path and another only the server certificate, or where multiple paths are configured due to some CA certificate renewals. My conclusion was that it would hurt more to not have the ability to include more than one hash if we need it than to provide the capability even though it's not used. > Normally, the client should learn ("cache") the path from a previous > full handshake with the server, and the client should probably > replace the cached certification path entirely if the server > does respond with a full path instead of the omission--rather > than collecting pathes and starting to announce all of the > hashes for all of the cached certification pathes that a specific > server has ever used in the past. > I was actually only thinking of caching, but in some environments it might actually be logical to do it in another way as you mention. > > Now what exactly are the characteristics for assuming that it already > possesses a server certification path (this is related to the clients > decision when to propose resuming a cached TLS session, but it's > slightly different). > > When client-side proxies are involved (aka HTTP CONNECT proxies), > then the target IP-address visible at the network socket is pretty > useless for distinguishing entries in the client-side cache. > The client probably needs access to the hostname that was used > to open the network connection (or the proxy CONNECT). > > A TLS session resume always implies a fixed set of connection attributes > (ciphersuite, server certification path). > > How much should a cached server certification path imply? > Any particular certification path (if agreed to by the server) > will restrict the subset of TLS ciphersuites that can be used > based on the keytype of the server certificate in that path, > e.g. DSA-cihpersuites require a server cert with a DSA-key, > ECDSA-ciphersuites require a server cert with an ECDSA-key, > RSA-ciphersuites require a server cert with an RSA-key, > DHE-RSA ciphersuites require a server cert with an RSA-key > which must have "digitalSignature" keyUsage asserted, > DH-RSA ciphersuites require a server cert with a DH key, etc. > I think it should imply exactly the same as if that server certificate path was sent over the wire. > > I think the document should provide guidance when to "update > the cache" when the server sends a full certification path > instead of the omission, and when the client should or could > store the full certification path sent by the server as a > valid alternative. > Good suggestion. > > -Martin From rfc-editor@rfc-editor.org Fri Mar 13 18:08:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD8253A67A7; Fri, 13 Mar 2009 18:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.238 X-Spam-Level: X-Spam-Status: No, score=-17.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQyLnMcJIR5F; Fri, 13 Mar 2009 18:08:45 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 0CBA33A6824; Fri, 13 Mar 2009 18:08:45 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id C85212519FA; Fri, 13 Mar 2009 17:47:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090314004735.C85212519FA@bosco.isi.edu> Date: Fri, 13 Mar 2009 17:47:35 -0700 (PDT) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 5489 on ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Mar 2009 01:08:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5489 Title: ECDHE_PSK Cipher Suites for Transport Layer Security (TLS) Author: M. Badra, I. Hajjeh Status: Informational Date: March 2009 Mailbox: badra@isima.fr, ibrahim.hajjeh@ineovation.fr Pages: 7 Characters: 14194 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-ecdhe-psk-05.txt URL: http://www.rfc-editor.org/rfc/rfc5489.txt This document extends RFC 4279, RFC 4492, and RFC 4785 and specifies a set of cipher suites that use a pre-shared key (PSK) to authenticate an Elliptic Curve Diffie-Hellman exchange with Ephemeral keys (ECDHE). These cipher suites provide Perfect Forward Secrecy (PFS). This memo provides information for the Internet community. This document is a product of the Transport Layer Security Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From ekr@networkresonance.com Mon Mar 16 21:37:20 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A386F3A681A for ; Mon, 16 Mar 2009 21:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.683 X-Spam-Level: X-Spam-Status: No, score=-0.683 tagged_above=-999 required=5 tests=[AWL=-1.842, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, MIME_HTML_ONLY=1.457] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TP57rJ6COHK for ; Mon, 16 Mar 2009 21:37:19 -0700 (PDT) Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 9A0253A684B for ; Mon, 16 Mar 2009 21:37:16 -0700 (PDT) Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id F275F5085A for ; Mon, 16 Mar 2009 22:00:53 -0700 (PDT) Date: Mon, 16 Mar 2009 22:00:53 -0700 From: Eric Rescorla To: tls@ietf.org References: <20090316203312.77E099A4781@odin.smetech.net> 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: message/rfc822 Message-Id: <20090317050053.F275F5085A@romeo.rtfm.com> Subject: [TLS] Forward: Comments on draft of DTLS 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2009 04:37:20 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.4 (2008-01-01) on laser.networkresonance.com X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, MIME_HTML_ONLY autolearn=no version=3.2.4 X-Original-To: ekr@networkresonance.com Delivered-To: ekr@networkresonance.com X-Virus-Scanned: amavisd-new at smetech.net X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 16 Mar 2009 16:33:02 -0400 To: ekr@networkresonance.com From: Russ Housley Subject: Comments on draft of DTLS 1.2 Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Message-Id: <20090316203312.77E099A4781@odin.smetech.net> Passing these along ....

I have the following comments  on draft-ietf-tls-rfc43470bis-02.

1) Section 3.2.1 says that once the client has transmitted the ClientHello message, it expects to see a HelloVerifyRequest from the server.  Section 4.2.1 states that when the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message.  I assume then that the use of HelloVerifyRequest message is optional.  If this is the case, should section 3.2.1 say instead that once the client has transmitted the ClientHello message, it expects to see either a HelloVerifyRequest or a ServerHello message from the server.

2) Section 4.1, the paragraph after the descriptions of epoch, sequence_number, length and fragment.  Looking at the end of the third sentence, should this be instead "....even if the message from epoch 0 was transmitted first".

3) In the last paragraph of section 4.2.1, we have the sentence "If a server receives a ClientHello with an invalid cookie, it SHOULD treat it the same as a ClientHello with no cookie.,,,,,this may result in clients receiving multiple HelloVerifyRequest messages with different cookies....".    What does this mean exactly?  Can the server decide just to ignore the bad cookie and continue with the handshaking?  If so, then the client would calculate its finished message over this clienthello with the cookie and the server would calculate its finished message over this clienthello without the cookie.  

I'm also assuming that all messages with helloverifyrequest and clienthello's are not included in the certificateverify and finished messages until you get to the last clientHello sent (that is assumed to be valid and allows you to proceed).  For example, client sends ClientHello(1), server responds with HelloVerifyRequest(1); client sends the ClientHello with invalid cookie - call it ClientHello(2); Server sends 2nd HelloVerifyRequest(2); Client replies with the ClientHello with the valid cookie this time - call it ClientHello(3). They then proceed with the handshake.  In this case ClientHello(1), HelloVerifyRequest(1), ClientHello(2), HelloVerifyRequest(2) are omitted from Finished and CertificateVerify messages. (?)

4) Section 4.2.2    fragment_length is a uint 24.  How can this be if the overall record length is a uint16 ?  I thought that fragment_length is the length of this particular fragment while "length" , a uint24,  is the overall length of this particular handshake message.

5) Section 4.2.2.  In the descriptive section (the diagram) about retransmitting one sees (seq=0) etc.  It might be better to write out message_seq in place of "seq" just to make sure that it's clear that we're talking about the message_seq and not the sequence_number.  The paragraphs right before and right after the diagram do clarify that though. 

6) In figure 2, it might be nice to include the (epoch,sequence_number) for each line or to provide an example of this.  This would help illustrate what Michael Tuexen and Robin Seggelmann were talking about in the emails from the end of Feb.  In particular, it would clarify that the epoch changes value after the change_cipher_spec message (so, the change_cipher_spec message itself still uses the current epoch number)


Grammatical:

1) Section 1, 2nd para., last sent: requires should be require in "..they typically require a large amount of effort..."

2) Section 4.1, 3rd para. from the end; end of 2nd sentence missing a noun?  "but if packet loss causes noticeable problems, implementations MAY choose...."

3) Section 4.1, 2nd para. from the end, 2nd sent, add a "message" to "For instance, the server may send its Finished message and then start transmitting data".  I had trouble parsing the next sentence and added a ";" and "," as in "Implementations MAY either buffer or discard such packets; though, when DTLS is used over realiable...."

4) Section 4.1, last para.  I would add message to Finished in two places and change CSS to ChangeCipherSpec . In the last sentence I would change "an" to "any" and add an "s" to the last word "attack":    In any other case, the implementation MUST wait for the receipt of the Finished message to prevent downgrade attacks.

5) Section 4.1.1, 1st para., 2nd sent: remove "that" from "In order to avoid fragmentation, that clients..."

6) Section 4.1.1, 2nd para., last sent, make number plural.

7) Section 4.1.2.1, add a "," to "..is that in TLS, MAC errors ...."

8) Section 4.2.1, last para., change "may results" to "may result" in "implementors:  this may results in clients..."  Also in the last sentence, one sees "HelloVerify".  Should this be instead "ClientHello"?


 From kanno-s@po.ntts.co.jp Tue Mar 17 19:41:03 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D18203A68AB for ; Tue, 17 Mar 2009 19:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.156 X-Spam-Level: X-Spam-Status: No, score=0.156 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kk18L7cF67dg for ; Tue, 17 Mar 2009 19:41:03 -0700 (PDT) Received: from mail2.ics.ntts.co.jp (mail2.ics.ntts.co.jp [202.32.24.42]) by core3.amsl.com (Postfix) with ESMTP id F1E183A6822 for ; Tue, 17 Mar 2009 19:41:02 -0700 (PDT) Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail2.ics.ntts.co.jp (8.13.8/NTTSOFT) with ESMTP id n2I2cYD9004669 for ; Wed, 18 Mar 2009 11:38:34 +0900 (JST) Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id n2I2cYYh012048 for tls@ietf.org; Wed, 18 Mar 2009 11:38:34 +0900 (JST) Received: from ccm18.silk.ntts.co.jp [10.7.18.18] by sadoku34.silk.ntts.co.jp with SMTP id MAA11199; Wed, 18 Mar 2009 11:31:43 +0900 Received: from mail15.silk.ntts.co.jp (localhost [127.0.0.1]) by ccm18.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2I2Vhve021689; Wed, 18 Mar 2009 11:31:43 +0900 (JST) Received: from mail15.silk.ntts.co.jp (localhost [127.0.0.1]) by mail15.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2I2Vhip028577; Wed, 18 Mar 2009 11:31:43 +0900 (JST) Received: from [127.0.0.1] ([10.7.206.148]) by mail15.silk.ntts.co.jp (8.14.3/NTTSOFT) with ESMTP id n2I2VAds028351; Wed, 18 Mar 2009 11:31:43 +0900 (JST) Date: Wed, 18 Mar 2009 11:31:11 +0900 From: Satoru Kanno To: tls@ietf.org X-Face: ,\m{?h\)X Message-Id: <20090318112643.A09D.KANNO-S@po.ntts.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_49C05BE3A0BA06D03E98_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.02 [ja] X-CC-Mail-RelayStamp: CC-Mail-V4-Client X-CC-Mail-RelayStamp: CC-Mail-V4-Server Subject: [TLS] New draft 'Addition of Camellia ECC Cipher Suites' X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 02:41:03 -0000 --------_49C05BE3A0BA06D03E98_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Lists, We wrote up new draft 'Addition of Camellia ECC Cipher Suites'. This draft is also to adopt addition of Camellia with HMAC-SHA1 and HMAC-SHA2 for TLS. We think that it is proper to deal with as an individual submission. This draft is not in I-D repository, but will appear A.S.A.P after 23 March 2009 at midnight(PT). Comments and questions about our document would be welcome. Best regards, -- Satoru Kanno Security Business Unit Mobile and Security Solution Business Group NTT Software Corporation e-mail: kanno-s@po.ntts.co.jp --------_49C05BE3A0BA06D03E98_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="draft-kanno-tls-camellia-ecc-sha-00.txt" Content-Disposition: attachment; filename="draft-kanno-tls-camellia-ecc-sha-00.txt" Content-Transfer-Encoding: base64 CgoKTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIEthbm5vCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIE5UVCBTb2Z0d2FyZSBDb3Jwb3JhdGlvbgpJbnRlbmRlZCBzdGF0dXM6IEluZm9y bWF0aW9uYWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gS2FuZGEKRXhwaXJl czogU2VwdGVtYmVyIDcsIDIwMDkgICAgICAgICAgICAgICAgTmlwcG9uIFRlbGVncmFwaCBhbmQg VGVsZXBob25lCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBDb3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1hcmNoIDYsIDIwMDkKCgogQWRkaXRpb24gb2Yg Q2FtZWxsaWEgRWxsaXB0aWMgQ3VydmUgQ2lwaGVyIFN1aXRlcyB3aXRoIFNIQS0xIGFuZCBTSEEt MgogICAgICAgICAgICAgICAgICBkcmFmdC1rYW5uby10bHMtY2FtZWxsaWEtZWNjLXNoYS0wMAoK U3RhdHVzIG9mIHRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQg dG8gSUVURiBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMgb2YgQkNQ IDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRz IG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFy ZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiAgTm90ZSB0aGF0CiAgIG90aGVyIGdyb3VwcyBt YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LQogICBEcmFm dHMuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBt YXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGluYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJpYWwg b3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAgVGhl IGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0CiAgIGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4KCiAgIFRoZSBsaXN0IG9m IEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQKICAg aHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg d2lsbCBleHBpcmUgb24gU2VwdGVtYmVyIDcsIDIwMDkuCgpDb3B5cmlnaHQgTm90aWNlCgogICBD b3B5cmlnaHQgKGMpIDIwMDkgSUVURiBUcnVzdCBhbmQgdGhlIHBlcnNvbnMgaWRlbnRpZmllZCBh cyB0aGUKICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdodHMgcmVzZXJ2ZWQuCgogICBUaGlz IGRvY3VtZW50IGlzIHN1YmplY3QgdG8gQkNQIDc4IGFuZCB0aGUgSUVURiBUcnVzdCdzIExlZ2Fs CiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHMgaW4gZWZmZWN0IG9uIHRo ZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQgKGh0dHA6Ly90cnVzdGVl LmlldGYub3JnL2xpY2Vuc2UtaW5mbykuCiAgIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRz IGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJpZ2h0cwogICBhbmQgcmVzdHJpY3Rp b25zIHdpdGggcmVzcGVjdCB0byB0aGlzIGRvY3VtZW50LgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIGEgc2V0IG9mIGVsbGlwdGljIGN1cnZlIGNpcGhlciBzdWl0ZXMgZm9y IHRoZQoKCgpLYW5ubyAmIEthbmRhICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDA5 ICAgICAgICAgICAgICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgIEFkZGl0aW9uIG9mIENh bWVsbGlhIEVDQyBDaXBoZXIgU3VpdGVzICAgICAgIE1hcmNoIDIwMDkKCgogICBUcmFuc3BvcnQg U2VjdXJpdHkgTGF5ZXIgKFRMUykgcHJvdG9jb2wgdG8gc3VwcG9ydCB0aGUgQ2FtZWxsaWEKICAg ZW5jcnlwdGlvbiBhbGdvcml0aG0gYXMgYSBibG9jayBjaXBoZXIuICBUaGlzIGRvY3VtZW50IGRl c2NyaWJlcwogICBzaXh0ZWVuIG5ldyBjaXBoZXIgc3VpdGVzIGZvciBUTFMgdGhhdCBzcGVjaWZ5 IEhNQUMtU0hBMSBhbmQgSE1BQy0KICAgU0hBMi4KCgoxLiAgSW50cm9kdWN0aW9uCgogICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyBhIHNldCBvZiBlbGxpcHRpYyBjdXJ2ZSBjaXBoZXIgc3VpdGVz IGZvciB0aGUKICAgVHJhbnNwb3J0IFNlY3VyaXR5IExheWVyIChUTFMpIHByb3RvY29sIHRvIHN1 cHBvcnQgdGhlIENhbWVsbGlhCiAgIGVuY3J5cHRpb24gYWxnb3JpdGhtIGFzIGEgYmxvY2sgY2lw aGVyLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMKICAgc2l4dGVlbiBuZXcgY2lwaGVyIHN1aXRl cyBmb3IgVExTIHRoYXQgc3BlY2lmeSBITUFDLVNIQTEgYW5kIEhNQUMtCiAgIFNIQTIuCgogICBU aGUgYWxnb3JpdGhtIHNwZWNpZmljYXRpb24gYW5kIG9iamVjdCBpZGVudGlmaWVycyBhcmUgZGVz Y3JpYmVkIGluCiAgIFtSRkMzNzEzXS4KCjEuMS4gIFRlcm1pbm9sb2d5CgogICBUaGUga2V5IHdv cmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIs CiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9Q VElPTkFMIiBpbiB0aGlzCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNj cmliZWQgaW4gW1JGQzIxMTldLgoKCjIuICBDaXBoZXIgU3VpdGVzCgogICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgc2l4dGVlbiBuZXcgY2lwaGVyIHN1aXRlcyB0byBiZSBhZGRlZCB0byBUTFMuCiAg IEFsbCB1c2UgRWxsaXB0aWMgQ3VydmUgQ3J5cHRvZ3JhcGh5IGZvciBrZXkgZXhjaGFuZ2UgYW5k IGRpZ2l0YWwKICAgc2lnbmF0dXJlLCBhcyBkZWZpbmVkIGluIFtSRkM0NDkyXS4KCiAgIFRoZSBz aXh0ZWVuIGNpcGhlciBzdWl0ZXMgdXNlIENhbWVsbGlhIFtSRkMzNzEzXSBpbiBDaXBoZXIgQmxv Y2sKICAgQ2hhaW5pbmcgKENCQykgbW9kZSB3aXRoIEhNQUMtYmFzZWQgTUFDLgoKICAgVGhlIGNp cGhlciBzdWl0ZXMgZGVmaW5lZCBoZXJlIGhhdmUgdGhlIGZvbGxvd2luZyBpZGVudGlmaWVyczoK CgoKCgoKCgoKCgoKCgoKCgpLYW5ubyAmIEthbmRhICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciA3LCAyMDA5ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgIEFkZGl0 aW9uIG9mIENhbWVsbGlhIEVDQyBDaXBoZXIgU3VpdGVzICAgICAgIE1hcmNoIDIwMDkKCgogICAg IENpcGhlclN1aXRlIFRMU19FQ0RIX0VDRFNBX1dJVEhfQ0FNRUxMSUFfMTI4X0NCQ19TSEEgICAg PSB7VEJELFRCRH0KICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESF9FQ0RTQV9XSVRIX0NBTUVMTElB XzI1Nl9DQkNfU0hBICAgID0ge1RCRCxUQkR9CiAgICAgQ2lwaGVyU3VpdGUgVExTX0VDREhFX0VD RFNBX1dJVEhfQ0FNRUxMSUFfMTI4X0NCQ19TSEEgICA9IHtUQkQsVEJEfQogICAgIENpcGhlclN1 aXRlIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0NBTUVMTElBXzI1Nl9DQkNfU0hBICAgPSB7VEJELFRC RH0KICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESF9SU0FfV0lUSF9DQU1FTExJQV8xMjhfQ0JDX1NI QSAgICAgID0ge1RCRCxUQkR9CiAgICAgQ2lwaGVyU3VpdGUgVExTX0VDREhfUlNBX1dJVEhfQ0FN RUxMSUFfMjU2X0NCQ19TSEEgICAgICA9IHtUQkQsVEJEfQogICAgIENpcGhlclN1aXRlIFRMU19F Q0RIRV9SU0FfV0lUSF9DQU1FTExJQV8xMjhfQ0JDX1NIQSAgICAgPSB7VEJELFRCRH0KICAgICBD aXBoZXJTdWl0ZSBUTFNfRUNESEVfUlNBX1dJVEhfQ0FNRUxMSUFfMjU2X0NCQ19TSEEgICAgID0g e1RCRCxUQkR9CgogICAgIENpcGhlclN1aXRlIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0NBTUVMTElB XzEyOF9DQkNfU0hBMjU2ICA9IHtUQkQsVEJEfTsKICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESEVf RUNEU0FfV0lUSF9DQU1FTExJQV8yNTZfQ0JDX1NIQTM4NCAgPSB7VEJELFRCRH07CiAgICAgQ2lw aGVyU3VpdGUgVExTX0VDREhfRUNEU0FfV0lUSF9DQU1FTExJQV8xMjhfQ0JDX1NIQTI1NiAgID0g e1RCRCxUQkR9OwogICAgIENpcGhlclN1aXRlIFRMU19FQ0RIX0VDRFNBX1dJVEhfQ0FNRUxMSUFf MjU2X0NCQ19TSEEzODQgICA9IHtUQkQsVEJEfTsKICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESEVf UlNBX1dJVEhfQ0FNRUxMSUFfMTI4X0NCQ19TSEEyNTYgICAgPSB7VEJELFRCRH07CiAgICAgQ2lw aGVyU3VpdGUgVExTX0VDREhFX1JTQV9XSVRIX0NBTUVMTElBXzI1Nl9DQkNfU0hBMzg0ICAgID0g e1RCRCxUQkR9OwogICAgIENpcGhlclN1aXRlIFRMU19FQ0RIX1JTQV9XSVRIX0NBTUVMTElBXzEy OF9DQkNfU0hBMjU2ICAgICA9IHtUQkQsVEJEfTsKICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESF9S U0FfV0lUSF9DQU1FTExJQV8yNTZfQ0JDX1NIQTM4NCAgICAgPSB7VEJELFRCRH07CgoKMy4gIElB TkEgQ29uc2lkZXJhdGlvbnMKCiAgIElBTkEgaXMgcmVxdWVzdGVkIHRvIGFsbG9jYXRlIHRoZSBm b2xsb3dpbmcgbnVtYmVycyBpbiB0aGUgVExTIENpcGhlcgogICBTdWl0ZSBSZWdpc3RyeToKCiAg ICAgQ2lwaGVyU3VpdGUgVExTX0VDREhfRUNEU0FfV0lUSF9DQU1FTExJQV8xMjhfQ0JDX1NIQSAg ICA9IHtUQkQsVEJEfQogICAgIENpcGhlclN1aXRlIFRMU19FQ0RIX0VDRFNBX1dJVEhfQ0FNRUxM SUFfMjU2X0NCQ19TSEEgICAgPSB7VEJELFRCRH0KICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESEVf RUNEU0FfV0lUSF9DQU1FTExJQV8xMjhfQ0JDX1NIQSAgID0ge1RCRCxUQkR9CiAgICAgQ2lwaGVy U3VpdGUgVExTX0VDREhFX0VDRFNBX1dJVEhfQ0FNRUxMSUFfMjU2X0NCQ19TSEEgICA9IHtUQkQs VEJEfQogICAgIENpcGhlclN1aXRlIFRMU19FQ0RIX1JTQV9XSVRIX0NBTUVMTElBXzEyOF9DQkNf U0hBICAgICAgPSB7VEJELFRCRH0KICAgICBDaXBoZXJTdWl0ZSBUTFNfRUNESF9SU0FfV0lUSF9D QU1FTExJQV8yNTZfQ0JDX1NIQSAgICAgID0ge1RCRCxUQkR9CiAgICAgQ2lwaGVyU3VpdGUgVExT X0VDREhFX1JTQV9XSVRIX0NBTUVMTElBXzEyOF9DQkNfU0hBICAgICA9IHtUQkQsVEJEfQogICAg IENpcGhlclN1aXRlIFRMU19FQ0RIRV9SU0FfV0lUSF9DQU1FTExJQV8yNTZfQ0JDX1NIQSAgICAg PSB7VEJELFRCRH0KCiAgICAgQ2lwaGVyU3VpdGUgVExTX0VDREhFX0VDRFNBX1dJVEhfQ0FNRUxM SUFfMTI4X0NCQ19TSEEyNTYgID0ge1RCRCxUQkR9OwogICAgIENpcGhlclN1aXRlIFRMU19FQ0RI RV9FQ0RTQV9XSVRIX0NBTUVMTElBXzI1Nl9DQkNfU0hBMzg0ICA9IHtUQkQsVEJEfTsKICAgICBD aXBoZXJTdWl0ZSBUTFNfRUNESF9FQ0RTQV9XSVRIX0NBTUVMTElBXzEyOF9DQkNfU0hBMjU2ICAg PSB7VEJELFRCRH07CiAgICAgQ2lwaGVyU3VpdGUgVExTX0VDREhfRUNEU0FfV0lUSF9DQU1FTExJ QV8yNTZfQ0JDX1NIQTM4NCAgID0ge1RCRCxUQkR9OwogICAgIENpcGhlclN1aXRlIFRMU19FQ0RI RV9SU0FfV0lUSF9DQU1FTExJQV8xMjhfQ0JDX1NIQTI1NiAgICA9IHtUQkQsVEJEfTsKICAgICBD aXBoZXJTdWl0ZSBUTFNfRUNESEVfUlNBX1dJVEhfQ0FNRUxMSUFfMjU2X0NCQ19TSEEzODQgICAg PSB7VEJELFRCRH07CiAgICAgQ2lwaGVyU3VpdGUgVExTX0VDREhfUlNBX1dJVEhfQ0FNRUxMSUFf MTI4X0NCQ19TSEEyNTYgICAgID0ge1RCRCxUQkR9OwogICAgIENpcGhlclN1aXRlIFRMU19FQ0RI X1JTQV9XSVRIX0NBTUVMTElBXzI1Nl9DQkNfU0hBMzg0ICAgICA9IHtUQkQsVEJEfTsKCgo0LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEF0IHRoZSB0aW1lIG9mIHdyaXRpbmcgdGhpcyBk b2N1bWVudCwgdGhlcmUgYXJlIG5vIGtub3duIHdlYWsga2V5cwogICBmb3IgQ2FtZWxsaWEuCgoK CgpLYW5ubyAmIEthbmRhICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDA5ICAgICAg ICAgICAgICAgW1BhZ2UgM10KDApJbnRlcm5ldC1EcmFmdCAgIEFkZGl0aW9uIG9mIENhbWVsbGlh IEVDQyBDaXBoZXIgU3VpdGVzICAgICAgIE1hcmNoIDIwMDkKCgogICBUaGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgaW4gUkZDIDUyODkgW1JGQzUyODldIGFwcGx5IHRvIHRoaXMKICAgZG9jdW1l bnQgYXMgd2VsbC4KCgo1LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJh ZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAg ICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4K CiAgIFtSRkMzNzEzXSAgTWF0c3VpLCBNLiwgTmFrYWppbWEsIEouLCBhbmQgUy4gTW9yaWFpLCAi QSBEZXNjcmlwdGlvbiBvZgogICAgICAgICAgICAgIHRoZSBDYW1lbGxpYSBFbmNyeXB0aW9uIEFs Z29yaXRobSIsIFJGQyAzNzEzLCBBcHJpbCAyMDA0LgoKICAgW1JGQzQ0OTJdICBCbGFrZS1XaWxz b24sIFMuLCBCb2x5YXJkLCBOLiwgR3VwdGEsIFYuLCBIYXdrLCBDLiwgYW5kIEIuCiAgICAgICAg ICAgICAgTW9lbGxlciwgIkVsbGlwdGljIEN1cnZlIENyeXB0b2dyYXBoeSAoRUNDKSBDaXBoZXIg U3VpdGVzCiAgICAgICAgICAgICAgZm9yIFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSIs IFJGQyA0NDkyLCBNYXkgMjAwNi4KCiAgIFtSRkM1Mjg5XSAgUmVzY29ybGEsIEUuLCAiVExTIEVs bGlwdGljIEN1cnZlIENpcGhlciBTdWl0ZXMgd2l0aCBTSEEtCiAgICAgICAgICAgICAgMjU2LzM4 NCBhbmQgQUVTIEdhbG9pcyBDb3VudGVyIE1vZGUgKEdDTSkiLCBSRkMgNTI4OSwKICAgICAgICAg ICAgICBBdWd1c3QgMjAwOC4KCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIFNhdG9ydSBLYW5ubwog ICBOVFQgU29mdHdhcmUgQ29ycG9yYXRpb24KCiAgIFBob25lOiArODEtNDUtMjEyLTc1NzcKICAg RmF4OiAgICs4MS00NS0yMTItOTgwMAogICBFbWFpbDoga2Fubm8tc0Bwby5udHRzLmNvLmpwCgoK ICAgTWFzYXl1a2kgS2FuZGEKICAgTmlwcG9uIFRlbGVncmFwaCBhbmQgVGVsZXBob25lIENvcnBv cmF0aW9uCgogICBQaG9uZTogKzgxLTQyMi01OS0zNDU2CiAgIEZheDogICArODEtNDIyLTU5LTQw MTUKICAgRW1haWw6IGthbmRhLm1hc2F5dWtpQGxhYi5udHQuY28uanAKCgoKCgoKCgoKCgoKCgpL YW5ubyAmIEthbmRhICAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciA3LCAyMDA5ICAgICAgICAg ICAgICAgW1BhZ2UgNF0KDAoK --------_49C05BE3A0BA06D03E98_MULTIPART_MIXED_-- From ekr@rtfm.com Tue Mar 17 20:54:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 416743A69B8 for ; Tue, 17 Mar 2009 20:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G65NPQWkGL35 for ; Tue, 17 Mar 2009 20:54:34 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by core3.amsl.com (Postfix) with ESMTP id A5D6D3A6802 for ; Tue, 17 Mar 2009 20:54:34 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so181441waf.5 for ; Tue, 17 Mar 2009 20:55:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.159.17 with SMTP id h17mr441436wae.197.1237348518342; Tue, 17 Mar 2009 20:55:18 -0700 (PDT) Date: Tue, 17 Mar 2009 20:55:18 -0700 Message-ID: From: Eric Rescorla To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 03:54:35 -0000 Hi folks, As you may know, the IESG declined to advance draft-housley-tls-authz as PS. However, during the IETF Last Call, there were some expressions of interest in work in this general area, for which the TLS WG would be the appropriate venue. The TLS WG is meeting at IETF 74 in San Francisco. If there are people who want the TLS WG to take on work in this area, this would be the appropriate time to ask for agenda time to discuss it. -Ekr From umardikar@paypal.com Tue Mar 17 21:00:33 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10CB03A6873 for ; Tue, 17 Mar 2009 21:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_MED=-4, SARE_FORGED_PAYPAL_C=1.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8ZoJvvnhwwW for ; Tue, 17 Mar 2009 21:00:32 -0700 (PDT) Received: from rhv-mipot-001.corp.ebay.com (rhv-mipot-001.corp.ebay.com [216.33.244.6]) by core3.amsl.com (Postfix) with ESMTP id 18FD33A6802 for ; Tue, 17 Mar 2009 21:00:32 -0700 (PDT) DomainKey-Signature: s=ppcorp; d=paypal.com; c=nofws; q=dns; h=X-EBay-Corp:X-IronPort-AV:Received:Received:X-MimeOLE: Content-class:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:Date:Message-ID: X-MS-Has-Attach:X-MS-TNEF-Correlator:Thread-Topic: Thread-Index:References:From:To:Return-Path: X-OriginalArrivalTime; b=ZxZ9ODQcFcCTEFD+770DbHRjLvx6FMcyCcAGe5EqE20NNcSQz4GtZVaz Pr4QeM3G8QFedr0veZhwJvtOjCGXjPrJQyiSZFMwqDmcHjI2hwaxoaT4+ GWeAE5C5ieMfyAq; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=umardikar@paypal.com; q=dns/txt; s=ppcorp; t=1237348876; x=1268884876; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Mardikar,=20Upendra"=20 |Subject:=20RE:=20[TLS]=20Interest=20in=20TLS=20authoriza tion?|Date:=20Tue,=2017=20Mar=202009=2020:59:47=20-0700 |Message-ID:=20|To:=20"Eric=20Rescorla"=20,=0D=0A=09|MIME-Version:=201.0 |Content-Transfer-Encoding:=20quoted-printable |References:=20; bh=z0McXT/yjBEkQ2GFA4cQbzx4hoEU9ZRl9orq10Ow89Q=; b=dGmAHrQutRqhk+3hA7EmzM7BVURqRV5VTLXX1eGUxYufKU61y4M/0SYs /FPK3mUYanuEdAobLw/UZfDjsytExxuOQlKcN+PYuYREz6IsC+2FxxpV2 +REpfg3Djs1+ldP; X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.38,382,1233561600"; d="scan'208";a="43163317" Received: from rhv-mexbh-002.corp.ebay.com ([10.112.113.21]) by rhv-mipot-001.corp.ebay.com with ESMTP; 17 Mar 2009 21:01:15 -0700 Received: from RHV-EXM-01.corp.ebay.com ([10.245.17.61]) by RHV-MEXBH-002.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 17 Mar 2009 21:01:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Mar 2009 20:59:47 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Interest in TLS authorization? Thread-Index: AcmnfV22vz73c9i/RLKLUIceGCNcWwAAJz2x References: From: "Mardikar, Upendra" To: "Eric Rescorla" , X-OriginalArrivalTime: 18 Mar 2009 04:01:15.0114 (UTC) FILETIME=[2EE35CA0:01C9A77E] Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 04:00:33 -0000 This would be of interest to us. I am in. Upendra -----Original Message----- From: tls-bounces@ietf.org on behalf of Eric Rescorla Sent: Tue 3/17/2009 8:55 PM To: tls@ietf.org Subject: [TLS] Interest in TLS authorization? =20 Hi folks, As you may know, the IESG declined to advance draft-housley-tls-authz as PS. However, during the IETF Last Call, there were some expressions of interest in work in this general area, for which the TLS WG would be the appropriate venue. The TLS WG is meeting at IETF 74 in San Francisco. If there are people who want the TLS WG to take on work in this area, this would be the appropriate time to ask for agenda time to discuss it. -Ekr _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From sshen@huawei.com Tue Mar 17 22:30:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4354D28C131 for ; Tue, 17 Mar 2009 22:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.454 X-Spam-Level: X-Spam-Status: No, score=-0.454 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSk5SER7z2SY for ; Tue, 17 Mar 2009 22:30:03 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 44A5B28C123 for ; Tue, 17 Mar 2009 22:30:03 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGO002ZYSN0VH@szxga01-in.huawei.com> for tls@ietf.org; Wed, 18 Mar 2009 13:30:36 +0800 (CST) Received: from huawei.com ([172.24.1.12]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KGO00ERCSN05P@szxga01-in.huawei.com> for tls@ietf.org; Wed, 18 Mar 2009 13:30:36 +0800 (CST) Received: from s00102542 ([10.111.12.128]) by szxml05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KGO00FKESMZ67@szxml05-in.huawei.com> for tls@ietf.org; Wed, 18 Mar 2009 13:30:36 +0800 (CST) Date: Wed, 18 Mar 2009 13:30:35 +0800 From: Sean Shen In-reply-to: To: "'Mardikar, Upendra'" , 'Eric Rescorla' , tls@ietf.org Message-id: <034c01c9a78a$aa5a4d60$800c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcmnfV22vz73c9i/RLKLUIceGCNcWwAAJz2xAAMgP0A= Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 05:30:04 -0000 I am interested in this. Sean >-----Original Message----- >From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On >Behalf Of Mardikar, Upendra >Sent: Wednesday, March 18, 2009 12:00 PM >To: Eric Rescorla; tls@ietf.org >Subject: Re: [TLS] Interest in TLS authorization? > > >This would be of interest to us. I am in. >Upendra > > >-----Original Message----- >From: tls-bounces@ietf.org on behalf of Eric Rescorla >Sent: Tue 3/17/2009 8:55 PM >To: tls@ietf.org >Subject: [TLS] Interest in TLS authorization? > >Hi folks, > >As you may know, the IESG declined to advance >draft-housley-tls-authz as PS. However, during the IETF Last >Call, there were some expressions of interest in work in this >general area, for which the TLS WG would be the appropriate venue. > >The TLS WG is meeting at IETF 74 in San Francisco. >If there are people who want the TLS WG to take on work in >this area, this would be the appropriate time to ask for >agenda time to discuss it. > >-Ekr >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From dds@it.uc3m.es Wed Mar 18 01:02:37 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DDBAF3A67D0 for ; Wed, 18 Mar 2009 01:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4WGFPh3aXCq for ; Wed, 18 Mar 2009 01:02:36 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7E1523A66B4 for ; Wed, 18 Mar 2009 01:02:35 -0700 (PDT) X-uc3m-safe: yes Received: from dlap (unknown [163.117.141.36]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id ADCBC656FE6; Wed, 18 Mar 2009 09:03:18 +0100 (CET) From: "Daniel Diaz Sanchez" To: "'Sean Shen'" , "'Mardikar, Upendra'" , "'Eric Rescorla'" , References: <034c01c9a78a$aa5a4d60$800c6f0a@china.huawei.com> In-Reply-To: <034c01c9a78a$aa5a4d60$800c6f0a@china.huawei.com> Date: Wed, 18 Mar 2009 09:03:18 +0100 Message-ID: <000f01c9a79f$ffc99750$ff5cc5f0$@uc3m.es> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmnfV22vz73c9i/RLKLUIceGCNcWwAAJz2xAAMgP0AABV1/kA== Content-Language: es X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16526.005 Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 08:02:37 -0000 I'm interested in this. Moreover, I've already done some works and implementations.=20 If anybody is interested I can send some articles with our proposals. --- Daniel D=EDaz-Sanchez, Ph.D Telecommunication Engineer Dep. Ing. Telem=E1tica Universidad Carlos III de Madrid Av. Universidad, 30 28911 Legan=E9s (Madrid/Spain) Tel: (+34) 91-624-6233, Fax: -8749 Web: http://www.it.uc3m.es/dds Web: http://www.it.uc3m.es/pervasive A toolkit for attribute certificates (authz): http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml -----Mensaje original----- De: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] En nombre de Sean Shen Enviado el: mi=E9rcoles, 18 de marzo de 2009 6:31 Para: 'Mardikar, Upendra'; 'Eric Rescorla'; tls@ietf.org Asunto: Re: [TLS] Interest in TLS authorization? I am interested in this. Sean >-----Original Message----- >From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On=20 >Behalf Of Mardikar, Upendra >Sent: Wednesday, March 18, 2009 12:00 PM >To: Eric Rescorla; tls@ietf.org >Subject: Re: [TLS] Interest in TLS authorization? > > >This would be of interest to us. I am in. >Upendra > > >-----Original Message----- >From: tls-bounces@ietf.org on behalf of Eric Rescorla >Sent: Tue 3/17/2009 8:55 PM >To: tls@ietf.org >Subject: [TLS] Interest in TLS authorization? >=20 >Hi folks, > >As you may know, the IESG declined to advance=20 >draft-housley-tls-authz as PS. However, during the IETF Last=20 >Call, there were some expressions of interest in work in this=20 >general area, for which the TLS WG would be the appropriate venue. > >The TLS WG is meeting at IETF 74 in San Francisco. >If there are people who want the TLS WG to take on work in=20 >this area, this would be the appropriate time to ask for=20 >agenda time to discuss it. > >-Ekr >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From simon@josefsson.org Wed Mar 18 01:43:50 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E15713A68E0 for ; Wed, 18 Mar 2009 01:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp3yvHNuzS7e for ; Wed, 18 Mar 2009 01:43:49 -0700 (PDT) Received: from yxa-v.extundo.com (yxa-v.extundo.com [83.241.177.39]) by core3.amsl.com (Postfix) with ESMTP id 89A743A6822 for ; Wed, 18 Mar 2009 01:43:49 -0700 (PDT) Received: from c80-216-29-127.bredband.comhem.se ([80.216.29.127] helo=mocca.josefsson.org) by yxa-v.extundo.com with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1LjrNW-000605-0k; Wed, 18 Mar 2009 09:44:01 +0100 From: Simon Josefsson To: "Daniel Diaz Sanchez" References: <034c01c9a78a$aa5a4d60$800c6f0a@china.huawei.com> <000f01c9a79f$ffc99750$ff5cc5f0$@uc3m.es> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:090318:sshen@huawei.com::0x2PRL/6gzvCOEWZ:11xd X-Hashcash: 1:22:090318:tls@ietf.org::Tv+wqhHnxcyoDBri:69A/ X-Hashcash: 1:22:090318:ekr@rtfm.com::LsbYmSOKtYuMaoXD:9Zg0 X-Hashcash: 1:22:090318:umardikar@paypal.com::IhDXmII7NScMWUhC:YHdl X-Hashcash: 1:22:090318:dds@it.uc3m.es::KwpL1oo+Zqgj76Ev:eh7S Date: Wed, 18 Mar 2009 09:43:51 +0100 In-Reply-To: <000f01c9a79f$ffc99750$ff5cc5f0$@uc3m.es> (Daniel Diaz Sanchez's message of "Wed, 18 Mar 2009 09:03:18 +0100") Message-ID: <87fxhbgr08.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: 'Eric Rescorla' , tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 08:43:51 -0000 "Daniel Diaz Sanchez" writes: > I'm interested in this. Moreover, I've already done some works and > implementations. > > If anybody is interested I can send some articles with our proposals. Hi! Yes, please do. I'm interested in reviewing and implementing this as well. Thanks, /Simon > --- > Daniel Díaz-Sanchez, Ph.D > Telecommunication Engineer > > Dep. Ing. Telemática > Universidad Carlos III de Madrid > Av. Universidad, 30 > 28911 Leganés (Madrid/Spain) > Tel: (+34) 91-624-6233, Fax: -8749 > > Web: http://www.it.uc3m.es/dds > Web: http://www.it.uc3m.es/pervasive > A toolkit for attribute certificates (authz): > http://www.it.uc3m.es/dds/swRelease/pmi/pmi.xml > > > -----Mensaje original----- > De: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] En nombre de Sean > Shen > Enviado el: miércoles, 18 de marzo de 2009 6:31 > Para: 'Mardikar, Upendra'; 'Eric Rescorla'; tls@ietf.org > Asunto: Re: [TLS] Interest in TLS authorization? > > I am interested in this. > > Sean > >>-----Original Message----- >>From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On >>Behalf Of Mardikar, Upendra >>Sent: Wednesday, March 18, 2009 12:00 PM >>To: Eric Rescorla; tls@ietf.org >>Subject: Re: [TLS] Interest in TLS authorization? >> >> >>This would be of interest to us. I am in. >>Upendra >> >> >>-----Original Message----- >>From: tls-bounces@ietf.org on behalf of Eric Rescorla >>Sent: Tue 3/17/2009 8:55 PM >>To: tls@ietf.org >>Subject: [TLS] Interest in TLS authorization? >> >>Hi folks, >> >>As you may know, the IESG declined to advance >>draft-housley-tls-authz as PS. However, during the IETF Last >>Call, there were some expressions of interest in work in this >>general area, for which the TLS WG would be the appropriate venue. >> >>The TLS WG is meeting at IETF 74 in San Francisco. >>If there are people who want the TLS WG to take on work in >>this area, this would be the appropriate time to ask for >>agenda time to discuss it. >> >>-Ekr >>_______________________________________________ >>TLS mailing list >>TLS@ietf.org >>https://www.ietf.org/mailman/listinfo/tls >> >>_______________________________________________ >>TLS mailing list >>TLS@ietf.org >>https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From ietf@hardjono.net Wed Mar 18 07:30:16 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8743A6AA9 for ; Wed, 18 Mar 2009 07:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LjxroRUqoziI for ; Wed, 18 Mar 2009 07:30:15 -0700 (PDT) Received: from outbound-mail-09.bluehost.com (outbound-mail-09.bluehost.com [69.89.17.209]) by core3.amsl.com (Postfix) with SMTP id C6C133A68DE for ; Wed, 18 Mar 2009 07:30:15 -0700 (PDT) Received: (qmail 24063 invoked by uid 0); 18 Mar 2009 14:29:09 -0000 Received: from unknown (HELO box251.bluehost.com) (69.89.31.51) by outboundproxy1.bluehost.com with SMTP; 18 Mar 2009 14:29:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=hardjono.net; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=hHxgYmMxD1BNEgrrv5qQUeEEAINtopQvKb8otAbDCNm/pa1yW55EeKzN0IxsMG/30OexZ5njRVwE3MPvrMh75yxDcQK/icx9pNwaMxKh0MJfN/hpRinqy9u5rzmkUmjJ; Received: from dhcp-18-111-57-221.dyn.mit.edu ([18.111.57.221] helo=thomasvnf1ekrv) by box251.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1LjwnL-0002me-4D; Wed, 18 Mar 2009 08:30:59 -0600 From: "ietf+hardjono.net" To: "'Eric Rescorla'" , References: In-Reply-To: Date: Wed, 18 Mar 2009 09:30:53 -0500 Message-ID: <017b01c9a7d6$2945f3e0$7bd1dba0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmnfVvRJu0jb9PBSYSBZ9dMxldPlAAWH1wg Content-Language: en-us X-Identified-User: {727:box251.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 18.111.57.221 authed with ietf+hardjono.net} Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 14:30:16 -0000 Hi Eric, Yes I'm interested in this item. Any background as to why it was declined by the IESG? cheers, /thomas/ > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Eric Rescorla > Sent: Tuesday, March 17, 2009 10:55 PM > To: tls@ietf.org > Subject: [TLS] Interest in TLS authorization? > > Hi folks, > > As you may know, the IESG declined to advance > draft-housley-tls-authz as PS. However, during the > IETF Last Call, there were some expressions of interest > in work in this general area, for which the TLS WG > would be the appropriate venue. > > The TLS WG is meeting at IETF 74 in San Francisco. > If there are people who want the TLS WG to take on > work in this area, this would be the appropriate time > to ask for agenda time to discuss it. > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mbadra@gmail.com Wed Mar 18 13:18:55 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780BA28C1FD for ; Wed, 18 Mar 2009 13:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4xDl8e5tXcn for ; Wed, 18 Mar 2009 13:18:54 -0700 (PDT) Received: from mail-bw0-f169.google.com (mail-bw0-f169.google.com [209.85.218.169]) by core3.amsl.com (Postfix) with ESMTP id 4B96D3A6A6B for ; Wed, 18 Mar 2009 13:18:54 -0700 (PDT) Received: by bwz17 with SMTP id 17so221392bwz.37 for ; Wed, 18 Mar 2009 13:19:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=X8zovCfh3hkeHFgswajJJfUZoN1JAZpvcigLytDZe10=; b=EcbIz2JxLDluTL4oyb33P/McoiZlFRBW1txk9+hbFsUJhGLLOAtOKQOr5Fvu8wBUav MU2V0mwpzJ3xw7KyoX3y3yXU8zE+ZlpVJIWWyXp7Px9a6fhMTBfPdioG/6TEwaoxawU/ 1+WbhUC3Gspa005c6D1RMIIM0dljtTLm2oD30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=vQlDPbEgdKk7BU1LojZaQBNJ+bTG8hkOVDnbZrhP9acwJ2OVSPR4T6JD6sUWTJvsh0 ceGQ+kB0q17blO9ZAJTQEyaTB3EwGHRGb9DhL9PteosFCDKX+bFfl4nKHH90A6SOgGPh Q+PrKrst8wNXWqK1yFcv7QHz1NwK7jf7q8eGo= MIME-Version: 1.0 Sender: mbadra@gmail.com Received: by 10.204.61.137 with SMTP id t9mr531595bkh.204.1237407577999; Wed, 18 Mar 2009 13:19:37 -0700 (PDT) In-Reply-To: <20090307232743.CFC2150822@romeo.rtfm.com> References: <20090307232743.CFC2150822@romeo.rtfm.com> Date: Wed, 18 Mar 2009 21:19:37 +0100 X-Google-Sender-Auth: 634e5ecfae894e80 Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=0016e6dee96e21091304656a67ab Cc: tls@ietf.org Subject: Re: [TLS] New DTLS Document X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2009 20:18:55 -0000 --0016e6dee96e21091304656a67ab Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Eric, Should GenericAEADCipher be added to the struct of Section 4.3.1? (e.g., case aead: GenericAEADCipher;) Best regards, Badra On Sun, Mar 8, 2009 at 12:27 AM, Eric Rescorla wrote: > OK, I've submitted a new version of DTLS that I think addresses the > editorial issues raised by Michael and Robin. Can you guys take a look > and let me know if you think I've missed anything? Anyone else? > > Thanks, > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0016e6dee96e21091304656a67ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Eric,
=A0
Should GenericAEADCipher be added to the struct of Section 4.3.1?
=A0
(e.g., case aead:=A0 GenericAEADCipher;)
=A0
Best regards,
Badra

On Sun, Mar 8, 2009 at 12:27 AM, Eric Rescorla <= span dir=3D"ltr"><ekr@networ= kresonance.com> wrote:
OK, I've submitted a new ver= sion of DTLS that I think addresses the
editorial issues raised by Micha= el and Robin. Can you guys take a look
and let me know if you think I've missed anything? Anyone else?

= Thanks,
-Ekr
_______________________________________________
TLS m= ailing list
TLS@ietf.org
https://ww= w.ietf.org/mailman/listinfo/tls

--0016e6dee96e21091304656a67ab-- From housley@vigilsec.com Thu Mar 19 14:43:34 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E14B28C11B for ; Thu, 19 Mar 2009 14:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eaf0bzVBTJ0r for ; Thu, 19 Mar 2009 14:43:33 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 7BA5928C0E8 for ; Thu, 19 Mar 2009 14:43:33 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id B80959A472E for ; Thu, 19 Mar 2009 17:44:27 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id TD49w8gLh-mK for ; Thu, 19 Mar 2009 17:44:18 -0400 (EDT) Received: from THINKPADR52.vigilsec.com (pool-96-255-144-212.washdc.fios.verizon.net [96.255.144.212]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id B70F79A471B for ; Thu, 19 Mar 2009 17:44:26 -0400 (EDT) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 19 Mar 2009 17:44:15 -0400 To: tls@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20090319214426.B70F79A471B@odin.smetech.net> Subject: [TLS] Fwd: RFC 5430 on Suite B Profile for Transport Layer Security (TLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2009 21:43:34 -0000 >To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org >Subject: RFC 5430 on Suite B Profile for Transport Layer Security (TLS) >From: rfc-editor@rfc-editor.org >Date: Thu, 19 Mar 2009 11:40:39 -0700 (PDT) >Cc: rfc-editor@rfc-editor.org > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 5430 > > Title: Suite B Profile for Transport > Layer Security (TLS) > Author: M. Salter, E. Rescorla, > R. Housley > Status: Informational > Date: March 2009 > Mailbox: msalter@restarea.ncsc.mil, > ekr@rtfm.com, > housley@vigilsec.com > Pages: 12 > Characters: 27586 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-rescorla-tls-suiteb-11.txt > > URL: http://www.rfc-editor.org/rfc/rfc5430.txt > >The United States government has published guidelines for "NSA Suite >B Cryptography", which defines cryptographic algorithm policy for >national security applications. This document defines a profile of >Transport Layer Security (TLS) version 1.2 that is fully conformant >with Suite B. This document also defines a transitional profile for >use with TLS version 1.0 and TLS version 1.1 which employs Suite B >algorithms to the greatest extent possible. This memo provides >information for the Internet community. > > >INFORMATIONAL: This memo provides information for the Internet community. >It does not specify an Internet standard of any kind. Distribution of >this memo is unlimited. > >This announcement is sent to the IETF-Announce and rfc-dist lists. >To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > >For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. >For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > > >The RFC Editor Team >USC/Information Sciences Institute From ekr@rtfm.com Tue Mar 24 11:58:23 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 791743A6826 for ; Tue, 24 Mar 2009 11:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.731 X-Spam-Level: X-Spam-Status: No, score=-1.731 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuRhPh3t05WB for ; Tue, 24 Mar 2009 11:58:22 -0700 (PDT) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.181]) by core3.amsl.com (Postfix) with ESMTP id 9C7E928C351 for ; Tue, 24 Mar 2009 11:58:02 -0700 (PDT) Received: by wa-out-1112.google.com with SMTP id l35so1628172waf.5 for ; Tue, 24 Mar 2009 11:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.94.12 with SMTP id r12mr5814480wab.229.1237921133934; Tue, 24 Mar 2009 11:58:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 24 Mar 2009 11:58:53 -0700 Message-ID: From: Eric Rescorla To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 18:58:23 -0000 Discussing this topic at a meeting is pretty much a prerequisite to deciding to work on it. A number of people followed up to say they had interest in this topic, but I haven't had any requests for agenda time as of yet. If there is someone in SFO who wants to talk about this on Thursday, please e-mail me. -Ekr On Tue, Mar 17, 2009 at 8:55 PM, Eric Rescorla wrote: > Hi folks, > > As you may know, the IESG declined to advance > draft-housley-tls-authz as PS. However, during the > IETF Last Call, there were some expressions of interest > in work in this general area, for which the TLS WG > would be the appropriate venue. > > The TLS WG is meeting at IETF 74 in San Francisco. > If there are people who want the TLS WG to take on > work in this area, this would be the appropriate time > to ask for agenda time to discuss it. > > -Ekr > From hardjono@MIT.EDU Tue Mar 24 14:27:35 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64BD33A6D41 for ; Tue, 24 Mar 2009 14:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sc84uhx0kxG for ; Tue, 24 Mar 2009 14:27:34 -0700 (PDT) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by core3.amsl.com (Postfix) with ESMTP id 82B733A6C3B for ; Tue, 24 Mar 2009 14:27:34 -0700 (PDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n2OLSK6l005597; Tue, 24 Mar 2009 17:28:20 -0400 (EDT) Received: from thomasvnf1ekrv (dhcp-1788.meeting.ietf.org [130.129.23.136]) (authenticated bits=0) (User authenticated as hardjono@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n2OLSDCs005361 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 24 Mar 2009 17:28:15 -0400 (EDT) From: "Thomas Hardjono" To: "'Eric Rescorla'" , References: In-Reply-To: Date: Tue, 24 Mar 2009 16:28:13 -0500 Message-ID: <002301c9acc7$73677840$5a3668c0$@edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcmssqigcZMB24uyQuSp7fiPYk9aRwAFI8GQ Content-Language: en-us Content-Type: multipart/signed; boundary="----=_NextPart_000_001E_01C9AC9D.8710FC10"; protocol="application/x-pkcs7-signature"; micalg=SHA1 X-Scanned-By: MIMEDefang 2.42 Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 21:27:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001E_01C9AC9D.8710FC10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Eric, I was one of the persons indicating interest in this work item. However, it turns-out I will not be able to attend the TLS WG on Thu due to a clash. My apologies. cheers, /thomas/ > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Eric Rescorla > Sent: Tuesday, March 24, 2009 1:59 PM > To: tls@ietf.org > Subject: Re: [TLS] Interest in TLS authorization? > > Discussing this topic at a meeting is pretty much a prerequisite > to deciding to work on it. A number of people followed up to say > they had interest in this topic, but I haven't had any requests for > agenda time as of yet. If there is someone in SFO who wants to > talk about this on Thursday, please e-mail me. > > -Ekr > > > On Tue, Mar 17, 2009 at 8:55 PM, Eric Rescorla wrote: > > Hi folks, > > > > As you may know, the IESG declined to advance > > draft-housley-tls-authz as PS. However, during the > > IETF Last Call, there were some expressions of interest > > in work in this general area, for which the TLS WG > > would be the appropriate venue. > > > > The TLS WG is meeting at IETF 74 in San Francisco. > > If there are people who want the TLS WG to take on > > work in this area, this would be the appropriate time > > to ask for agenda time to discuss it. > > > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_001E_01C9AC9D.8710FC10 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL2zCCAj0w ggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A MIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqRDvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiH mgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNePNGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF 4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJKoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d 6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix 3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8NfH1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPR cZQwggTGMIIDrqADAgECAhB9eEvuJn8dJd9a0XpZB2odMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0 IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j b20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZl cmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIwHhcNMDkwMzA2MDAw MDAwWhcNMTAwMzA2MjM1OTU5WjCCARMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9z aXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBG dWxsIFNlcnZpY2UxGDAWBgNVBAMUD1Rob21hcyBIYXJkam9ubzEfMB0GCSqGSIb3DQEJARYQaGFy ZGpvbm9AbWl0LmVkdTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtMQMYVUaf9hf4paIPmIi 2MQtsJ1OXqzHTaGGrFcapR2DypnEylOwu8ED05xBQCN6tRhqP09/Z2wuYbhIDLlukHlbW5fbVlyM jtUGv1XgylCijK5NC31IlWBi2XGfJxqVFS7T1yF4LhfiuRX4NW7UAW06vWar3qDwymIR86kuSX8C AwEAAaOBzDCByTAJBgNVHRMEAjAAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEHFwEwKjAoBggrBgEF BQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMCBaAwHQYDVR0lBBYw FAYIKwYBBQUHAwQGCCsGAQUFBwMCMEoGA1UdHwRDMEEwP6A9oDuGOWh0dHA6Ly9JbmRDMURpZ2l0 YWxJRC1jcmwudmVyaXNpZ24uY29tL0luZEMxRGlnaXRhbElELmNybDANBgkqhkiG9w0BAQUFAAOC AQEAW9PkC8JHUEASjQMBtXPoEmiNLc1kFptdd+q1yfXTy4uCjxyqODT52yaC/mM+WQDCUpsjTMKz zUU19J5z7cElBQEIAze7ClxD6guUXUJuQbtIhce9Kl8aqbmwIrYWv/6MGuUV+Ofi2V3ja79DfHHC LKEanzzUFT/b9WNHlaWM6R+fFkuNXGJ+Hj3/kgBOEiH6EHsfbhCUNOgveoGHYRqOf/2vjPqzcvv8 WiYmtC1yFhD8JRzqK2oGSd8NrMOdKJKqmvodQzGrV7M5G2eozsobJlPeIcNHTPKudH/5n8jWdUIO 7RIIpYAAYKNsVwiFaQORI9MBOGotFbcQcDOZyUwhrzCCBMwwggQ1oAMCAQICEByunWua9OYvIoqj 2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkG A1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUx HjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdH R0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhe jVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ +dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyr zROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUCAwEAAaOCAYQwggGAMBIGA1UdEwEB /wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgGCCsGAQUFBwIBFhxodHRw czovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIBBjARBglghkgBhvhCAQEEBAMCAQYw LgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDMtMjA0OC0xNTUwHQYDVR0OBBYE FBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAkoCKGIGh0dHA6Ly9jcmwudmVyaXNp Z24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMO VmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0GCSqGSIb3DQEBBQUAA4GBALEv2Zbh kqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Yo9K/HOzWGZ9KTUP4yru+E4BJBd0h czNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqSKTw6rlTaphJRsY/IytNHeObbpR6H BuPRFMDCIfa6MYIEczCCBG8CAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMgIQfXhL7iZ/HSXfWtF6WQdqHTAJBgUrDgMCGgUAoIIC1jAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTAzMjQyMTI4MTNaMCMGCSqG SIb3DQEJBDEWBBR0NgJmlv+381SOLyrlpH3Q72CbsDBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIB KDAHBgUrDgMCGjAKBggqhkiG9w0CBTCCAQMGCSsGAQQBgjcQBDGB9TCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhB9eEvuJn8dJd9a0XpZB2od MIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2ln biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMg b2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHMgIQfXhL7iZ/HSXfWtF6WQdqHTANBgkqhkiG9w0BAQEFAASBgDd9 QU8sFxbtq0x3G1+DGSVaTH9jwwI766A3FcC3QbkhTBemv5BaMxGIm0Du0TCvB7TvSoiZM8s7013T JTMKpS1S6AK9Kj3B5LylFdLjRCTpvQmZkWOLYeVnEhqzZKMNdKEtDInfoz/tZBpFUIfa75W6701F jIwi4hGAG/G20Y0mAAAAAAAA ------=_NextPart_000_001E_01C9AC9D.8710FC10-- From dean@av8.com Tue Mar 24 15:59:04 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F26803A6BC9 for ; Tue, 24 Mar 2009 15:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXPsrJxE5n+b for ; Tue, 24 Mar 2009 15:59:04 -0700 (PDT) Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 989DA3A6B94 for ; Tue, 24 Mar 2009 15:58:59 -0700 (PDT) Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id n2OMxnvq015583 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 24 Mar 2009 18:59:50 -0400 Date: Tue, 24 Mar 2009 18:59:48 -0400 (EDT) From: Dean Anderson X-X-Sender: dean@citation2.av8.net To: Eric Rescorla In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 22:59:05 -0000 Hi Folks, I am interested in the topic of TLS authorization, but not in advancing the patented Redphone proposal. I am willing to work on non-patented alternatives. I have read the patent and the prior art. I worked on OSF DCE back in the 1990s at the OSF and as a consultant to other companies. DCE includes authorization facilities beyond those provided by Kerberos, including public key auth* RPC. I've been working recently to revive the DCE project, and I see TLS authorization as related work. I would like to see an authorization framework created which is free of patents, or least free of patents that aren't mutually-defensive. An added benefit would be if that framework isn't too specific to TLS and could be used by other protocols. Something like SASL comes to mind. Though I've never been very happy with SASL for authentication, the concept of a generic authorization layer seems desirable. Thanks, --Dean On Tue, 17 Mar 2009, Eric Rescorla wrote: > Hi folks, > > As you may know, the IESG declined to advance > draft-housley-tls-authz as PS. However, during the > IETF Last Call, there were some expressions of interest > in work in this general area, for which the TLS WG > would be the appropriate venue. > > The TLS WG is meeting at IETF 74 in San Francisco. > If there are people who want the TLS WG to take on > work in this area, this would be the appropriate time > to ask for agenda time to discuss it. > > -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 From Nicolas.Williams@sun.com Tue Mar 24 16:28:45 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E53F53A67F4 for ; Tue, 24 Mar 2009 16:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.702 X-Spam-Level: X-Spam-Status: No, score=-5.702 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVHCZAj7Kv6E for ; Tue, 24 Mar 2009 16:28:45 -0700 (PDT) Received: from sca-ea-mail-4.sun.com (sca-ea-mail-4.Sun.COM [192.18.43.22]) by core3.amsl.com (Postfix) with ESMTP id DCFF73A63D2 for ; Tue, 24 Mar 2009 16:28:44 -0700 (PDT) Received: from dm-central-01.central.sun.com ([129.147.62.4]) by sca-ea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n2ONTadM009658 for ; Tue, 24 Mar 2009 23:29:36 GMT Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by dm-central-01.central.sun.com (8.13.8+Sun/8.13.8/ENSMAIL, v2.2) with ESMTP id n2ONTa0s015138 for ; Tue, 24 Mar 2009 17:29:36 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3) with ESMTP id n2ONCpTD011005; Tue, 24 Mar 2009 18:12:51 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.14.3+Sun/8.14.3/Submit) id n2ONCoL9011004; Tue, 24 Mar 2009 18:12:50 -0500 (CDT) X-Authentication-Warning: binky.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Tue, 24 Mar 2009 18:12:50 -0500 From: Nicolas Williams To: Dean Anderson Message-ID: <20090324231250.GQ9992@Sun.COM> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i Cc: Eric Rescorla , tls@ietf.org Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2009 23:28:46 -0000 On Tue, Mar 24, 2009 at 06:59:48PM -0400, Dean Anderson wrote: > I would like to see an authorization framework created which is free of > patents, or least free of patents that aren't mutually-defensive. An > added benefit would be if that framework isn't too specific to TLS and > could be used by other protocols. Something like SASL comes to mind. > Though I've never been very happy with SASL for authentication, the > concept of a generic authorization layer seems desirable. KITTEN WG has a work item on extending GSS-API interfaces to expose authorization information, e.g., DCE or WIndows PAC type data in Kerberos V tickets, but not just those. Think SAML in krb5 tix, PKIX certs, ... The SASL WG is working on GS2 -- a new GSS-API->SASL mechanism bridge so you can use GSS-API mechanisms in SASL apps. The only things missing then would be: - how to put SAML/whatever authorization elements into Kerberos V tickets and PKIX certificates - how to use SASL in TLS The latter is a variant of "how to use the GSS-API inside TLS", and that has been controversial and has never progressed within the TLS WG. IIRC the controversy arises from the fact that the GSS-API supports arbitrary round trips, and the same is true of SASL -- so you're likely to run into the same issue. However, I think we might be able to do something about that: ride some of the SASL/GSS-API messages in TLS handshake extensions and complete the SASL/GSS-API authentication exchange after the TLS exchange completes if the SASL/GSS-API mechanism requires further round-trips. Such a protocol would only be usable by applications that support such a protocol as that'd not be "TLS" -- but consider how many SASL apps run over TLS. A bit roundabout. But I don't see how there could exist patents that cover this, short of submarine patents by really clever people or submarine patents filed by someone who overheard early discussions of putting SAML into Kerberos some three or so years ago. Nico -- From ietf-ietf-tls@m.gmane.org Wed Mar 25 07:54:19 2009 Return-Path: X-Original-To: tls@core3.amsl.com Delivered-To: tls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 163D43A69E0 for ; Wed, 25 Mar 2009 07:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hSVcyi0F8mdW for ; Wed, 25 Mar 2009 07:54:18 -0700 (PDT) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by core3.amsl.com (Postfix) with ESMTP id 922493A696F for ; Wed, 25 Mar 2009 07:54:17 -0700 (PDT) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1LmUVS-0001nk-Ha for tls@ietf.org; Wed, 25 Mar 2009 14:55:02 +0000 Received: from rain.gmane.org ([80.91.229.7]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Mar 2009 14:55:02 +0000 Received: from Bruno.Harbulot by rain.gmane.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 25 Mar 2009 14:55:02 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Bruno Harbulot Date: Wed, 25 Mar 2009 14:14:06 +0000 Lines: 34 Message-ID: References: <20090324231250.GQ9992@Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: rain.gmane.org User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) In-Reply-To: <20090324231250.GQ9992@Sun.COM> Sender: news Subject: Re: [TLS] Interest in TLS authorization? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2009 14:54:19 -0000 Hello, Nicolas Williams wrote: > On Tue, Mar 24, 2009 at 06:59:48PM -0400, Dean Anderson wrote: >> I would like to see an authorization framework created which is free of >> patents, or least free of patents that aren't mutually-defensive. An >> added benefit would be if that framework isn't too specific to TLS and >> could be used by other protocols. Something like SASL comes to mind. >> Though I've never been very happy with SASL for authentication, the >> concept of a generic authorization layer seems desirable. > > KITTEN WG has a work item on extending GSS-API interfaces to expose > authorization information, e.g., DCE or WIndows PAC type data in > Kerberos V tickets, but not just those. Think SAML in krb5 tix, PKIX > certs, ... > > The SASL WG is working on GS2 -- a new GSS-API->SASL mechanism bridge so > you can use GSS-API mechanisms in SASL apps. > > The only things missing then would be: > > - how to put SAML/whatever authorization elements into Kerberos V > tickets and PKIX certificates I'm not sure if you are aware of this work, but these links may be relevant (regarding SAML authorization elements in PKIX certificates): - https://spaces.internet2.edu/display/GS/X509BindingSAML - http://dev.globus.org/wiki/SAML_in_X.509_Validation Best wishes, Bruno.