From tls-bounces@lists.ietf.org Fri Aug 04 07:32:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8xuQ-0003MH-Nx; Fri, 04 Aug 2006 07:32:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G8xuP-0003MC-Io for tls@ietf.org; Fri, 04 Aug 2006 07:32:05 -0400 Received: from ws6-5.us4.outblaze.com ([205.158.62.152]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G8xuN-0000ps-4h for tls@ietf.org; Fri, 04 Aug 2006 07:32:05 -0400 Received: (qmail 14619 invoked from network); 4 Aug 2006 11:31:34 -0000 Received: from unknown (HELO ?192.168.0.2?) (nelson@bolyard.com@67.169.18.8) by ws6-5.us4.outblaze.com with SMTP; 4 Aug 2006 11:31:33 -0000 Message-ID: <44D32FC2.2080606@bolyard.com> Date: Fri, 04 Aug 2006 04:30:10 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060701 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Subject: [TLS] sending error alerts: MUST? SHOULD? MAY? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The existing TLS RFCs and IDs don't say that an implementation MUST send any error alerts. There's lots of "will", "should", "may", but not nearly enough "MUST" (IMO) regarding error alerts (whether fatal or not). Consequently, one of the newer implementations (which I won't name here), one with which I've been doing interoperability testing, simply NEVER sends error alerts. When any problem occurs, it silently closes the connection without offering any clues to the peer about why it has done so. The developer's explanation to me for the implementation's behavior was simple: the RFCs do not require that error alerts be sent. Sending error alerts is simply not a MUST. Doing so is implicitly a MAY, at most. I think this is going to be a nightmare for trouble shooting. When a peer system drops a TLS connection, we're going to have to rely on the ability of the user or administrator who runs that peer to determine why it did so, rather than relying on alerts. So, I put the question to the TLS WG: Is there consensus that the RFC language should be strengthened in the next version (e.g. rfc4346-bis) to say that the error alerts MUST be sent, and when? A survey of error alert discussion in the first 40-some pages of the draft. Regarding close notify alerts, the existing RFC and drafts say that "each party is required to" (why not MUST?) send a close_notify alert if no error condition has occurred and that upon receiving a close-notify alert, the peer MUST send one in respnse. So, close_notify alerts will get sent, but not error alerts. The latest draft says that when an error alert is sent or received, the session MUST be invalidated, but doesn't require that it be sent. The draft says: "When an error is detected, the detecting party sends a message to the other party." I think that should be MUST SEND, but as written it's not a MUST. There are some "SHOULD"s in the current draft rfc4346-bis: "The receiver MUST check this padding and SHOULD use the bad_record_mac alert to indicate padding errors." I think this was intended to be understood as "MUST check, MUST send an alert to indicate errors, and SHOULD use bad_record_mac alert when appropriate". But as written, it clearly makes sending any alert at all at most a SHOULD for bad macs. no_renegotiation is a should, (and a MUST NOT) but never a SHOULD nor a MUST. certificate_unobtainable is a MAY. The text for client_hello says "The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection." No MUST in there. The alerts on page 30 MUST NOT be sent except when the client used a hello extension. But there is no time when they MUST be used. In the current draft, I did find a few MUSTs. Page 37 has an inferred "will": The server will select a cipher suite or, if no acceptable choices are presented, return a handshake failure alert and close the connection. page 39 has a MUST: "... if not then it MUST send a fatal "decode_error" alert." section 7.4.1.3 says: "it will respond with a handshake failure alert." no MUST there. I found two MUSTS in 7.4.1.4.2 on page 44. Also a SHALL (isn't that supposed to be a MUST?) I'll stop there without reviewing every weak description of an error alert. Let's please have more MUSTs. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 09 18:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwfA-0002a2-Uo; Wed, 09 Aug 2006 18:36:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GAwfA-0002Zx-01 for tls@lists.ietf.org; Wed, 09 Aug 2006 18:36:32 -0400 Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAwf8-0005t7-Lz for tls@lists.ietf.org; Wed, 09 Aug 2006 18:36:31 -0400 Received: from phys-ha14sca-2.sfbay.sun.com ([129.145.155.211]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k79MaROS008176 for ; Wed, 9 Aug 2006 16:36:27 -0600 (MDT) Received: from [192.18.120.70] by ha14sca-mail1.sfbay.sun.com (Sun Java System Messaging Server 6.2 Patch 1 (built Jan 31 2005)) with ESMTP id <0J3R0053U5GQ6W00@ha14sca-mail1.sfbay.sun.com> for tls@lists.ietf.org; Wed, 09 Aug 2006 15:36:26 -0700 (PDT) Date: Wed, 09 Aug 2006 15:36:24 -0700 From: Nelson B Bolyard Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt In-reply-to: <86y7vg52jq.fsf@raman.networkresonance.com> To: tls@lists.ietf.org Message-id: <44DA6368.8050002@bolyard.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit References: <20060626203923.59F81222426@laser.networkresonance.com> <200606270659.37003.nmav@gnutls.org> <200606290020.10111.nmav@gnutls.org> <86y7vg52jq.fsf@raman.networkresonance.com> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060723 SeaMonkey/1.5a X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > I think I have to agree with Nikos here. TLS (2246 and 4346) are > deliberately agnostic about how to determine whether a certificate > matches the expected client or server. That is relegated to > the upper layer protocol, in the case of HTTP it's described > in RFC 2818. So, I don't think that the document in question > needs to specify this. Eric, As you know (:-) , RFC 2818 is not a standards track document. "It does not specify an Internet standard of any kind. " Maybe it needs a standards-track successor. /Nelson _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 21 16:10:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFG4s-00085o-Qe; Mon, 21 Aug 2006 16:08:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GFG4r-00085S-6u for tls@ietf.org; Mon, 21 Aug 2006 16:08:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFEC1-0001Jv-Vz for tls@ietf.org; Mon, 21 Aug 2006 14:08:10 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFDiQ-0006e2-DF for tls@ietf.org; Mon, 21 Aug 2006 13:37:36 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 2D68A222425 for ; Mon, 21 Aug 2006 10:45:31 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Mon, 21 Aug 2006 10:37:33 -0700 From: Eric Rescorla Message-Id: <20060821174531.2D68A222425@laser.networkresonance.com> X-Spam-Score: -2.4 (--) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [TLS] Extended nonces X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Folks, Some folks from the USG have recently raised a requirement with me that I thought deserved some consideration from the WG. The issue is that they would like to have the client and server provide some opaque (to TLS) but structured data which is then fed into the PRF so that the traffic keys depend on it. Because the data is longer than 32 bytes it can't be packed into the Random structure and because it's structured and needs to be parsed on the other end, it can't be hashed and then placed in the Random. My thought was that they should define a new extension, something like: struct { opaque material<255>; } PublicKeyingMaterial; By offering this extension the client would be saying: 1. I want to do this extension, here's my data. 2. Please provide your own data. If the server doesn't respond with the extension it's not used. We would then mix these into the PRF as follows: master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + Client.PublicKeyingMaterial + ServerHello.random + Server.PublicKeyingMaterial)[0..47]; Do people see a problem with this? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 06:29:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHeKC-0004nm-Se; Mon, 28 Aug 2006 06:26:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHeKB-0004nh-Pu for tls@ietf.org; Mon, 28 Aug 2006 06:26:35 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHeK9-0003aR-Fn for tls@ietf.org; Mon, 28 Aug 2006 06:26:35 -0400 Received: from [192.168.1.3] (p5481FEBB.dip.t-dialin.net [84.129.254.187]) by ilsa.franken.de (Postfix) with ESMTP id 19B93245C4; Mon, 28 Aug 2006 12:26:25 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Michael Tuexen Date: Mon, 28 Aug 2006 12:26:22 +0200 To: tls@ietf.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: lars.eggert@netlab.nec.de, hartmans-ietf@mit.edu Subject: [TLS] draft-tuexen-dtls-for-sctp-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dear all, I would like to get some comments on draft-tuexen-dtls-for- sctp-00.txt. This includes - technical comments We would like to use the TLS master secret to generate an additional shared secret which we would use at the transport layer (SCTP) for SCTP-AUTH. It was already brought up, that this is a layer violation (but a nice one) and the risk would be that multiple instances would do this, then these multiple instances would use the same key material which is definitely bad. How should we progress here? From an implementation point of view I see only a limited risk here, because we will modify the TLS implementation to generate the additional material and would provide to to SCTP via a socket option. So there is NOT API to the TLS user involved. Another point was to have something like a registry for the material generated. This would avoid two instances to use the same material. What about this? Is this a good or bad idea? How can we achieve this, if it is a good idea? - procedural advises (Sam, Lars this is why you are CCed) Currently this document is an individual submission. How can it be progressed? Should it be taken to a WG? Which one? SCTP (including SCTP-AUTH) is handled in TSVWG and TLS is handled in the TLS WG. I'm not sure where DTLS was handled, if it was handled in any WG. I think having DTLS for SCTP is important because it is needed by anyone using SCTP with PR-SCTP or unordered delivery and wanting to have a TLS like security solution. IPFIX is one example. Best regards Michael _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 11:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHjBa-00021u-T5; Mon, 28 Aug 2006 11:38:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHjBZ-00021X-6t for tls@ietf.org; Mon, 28 Aug 2006 11:38:01 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHjBZ-0004uw-4Q for tls@ietf.org; Mon, 28 Aug 2006 11:38:01 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHjAv-0007MP-BM for tls@ietf.org; Mon, 28 Aug 2006 11:37:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2006 08:37:21 -0700 X-IronPort-AV: i="4.08,176,1154934000"; d="scan'208"; a="441731926:sNHT33561124" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k7SFbKJJ011849; Mon, 28 Aug 2006 08:37:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7SFbJYp002446; Mon, 28 Aug 2006 08:37:20 -0700 (PDT) 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, 28 Aug 2006 08:37:19 -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 Subject: RE: [TLS] draft-tuexen-dtls-for-sctp-00.txt Date: Mon, 28 Aug 2006 08:37:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] draft-tuexen-dtls-for-sctp-00.txt Thread-Index: AcbKjXD2rSUtLI1MSwuMS8RaE+1CjAAKhgPg From: "Joseph Salowey \(jsalowey\)" To: "Michael Tuexen" , X-OriginalArrivalTime: 28 Aug 2006 15:37:19.0720 (UTC) FILETIME=[D91FBE80:01C6CAB7] DKIM-Signature: a=rsa-sha1; q=dns; l=2745; t=1156779440; x=1157643440; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20[TLS]=20draft-tuexen-dtls-for-sctp-00.txt; X=v=3Dcisco.com=3B=20h=3DH3M2wQ5zx0eq8GVThq76l3vAc4s=3D; b=0bYWE1meLiFDk1dL8bna40flNPltrmgwgGg0S1AmVdM2H2r7E/X7fgM91Lbwbb7/m6CfEePM cIq0P8/4BFNDSuUwyqNAvu9DVChr1V8WjqOt+gmLy/w0XsaRT7v1asMl; Authentication-Results: sj-dkim-2.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: lars.eggert@netlab.nec.de, hartmans-ietf@mit.edu X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Michael, In the context of extended EAP keying material, we have been looking at the problem of deriving multiple keys from a single root in a coordinated fashion to avoid conflicts. A similar approach may work for TLS. I'm not sure that it makes sense to use the same details such as IANA registry or key derivation function, but it may. =20 The current version of the draft is http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk-deriv-01.txt. Let me know if you have any questions.=20 Cheers, Joe=20 > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: Monday, August 28, 2006 3:26 AM > To: tls@ietf.org > Cc: lars.eggert@netlab.nec.de; hartmans-ietf@mit.edu > Subject: [TLS] draft-tuexen-dtls-for-sctp-00.txt >=20 > Dear all, >=20 > I would like to get some comments on draft-tuexen-dtls-for-=20 > sctp-00.txt. This includes >=20 > - technical comments > We would like to use the TLS master secret to generate an=20 > additional shared secret which > we would use at the transport layer (SCTP) for SCTP-AUTH.=20 > It was already brought up, > that this is a layer violation (but a nice one) and the=20 > risk would be that multiple > instances would do this, then these multiple instances=20 > would use the same key material > which is definitely bad. > How should we progress here? From an implementation point=20 > of view I see only a limited > risk here, because we will modify the TLS implementation=20 > to generate the additional > material and would provide to to SCTP via a socket option.=20 > So there is NOT API to the > TLS user involved. > Another point was to have something like a registry for=20 > the material generated. This > would avoid two instances to use the same material. What=20 > about this? Is this a good or > bad idea? How can we achieve this, if it is a good idea? >=20 > - procedural advises (Sam, Lars this is why you are CCed) > Currently this document is an individual submission. How=20 > can it be progressed? Should > it be taken to a WG? Which one? SCTP (including SCTP-AUTH)=20 > is handled in TSVWG and > TLS is handled in the TLS WG. I'm not sure where DTLS was=20 > handled, if it was handled in > any WG. >=20 > I think having DTLS for SCTP is important because it is=20 > needed by anyone using SCTP with PR-SCTP or unordered=20 > delivery and wanting to have a TLS like security solution. > IPFIX is one example. >=20 > Best regards > Michael >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 12:35:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHk4c-0004WS-FC; Mon, 28 Aug 2006 12:34:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHk4a-0004Sb-Nc for tls@ietf.org; Mon, 28 Aug 2006 12:34:52 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHj06-0001ag-R3 for tls@ietf.org; Mon, 28 Aug 2006 11:26:14 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7D246E00C0; Mon, 28 Aug 2006 11:26:15 -0400 (EDT) From: Sam Hartman To: Lars Eggert References: <0B8150D7-EBEF-4D98-9587-4C6E838B69A1@netlab.nec.de> Date: Mon, 28 Aug 2006 11:26:15 -0400 In-Reply-To: <0B8150D7-EBEF-4D98-9587-4C6E838B69A1@netlab.nec.de> (Lars Eggert's message of "Mon, 28 Aug 2006 12:59:19 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org Subject: [TLS] Re: draft-tuexen-dtls-for-sctp-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org >>>>> "Lars" == Lars Eggert writes: Lars> Hi, Lars> On Aug 28, 2006, at 12:26, Michael Tuexen wrote: >> I would like to get some comments on draft-tuexen-dtls-for- >> sctp-00.txt. This includes - technical comments Lars> I think Sam is the one to handle these. I thought this draft was briefly presented at the last TLS working group meeting. I thought that there were some general comments made at that point. I'd talk to the TLS chairs, and see how they want to proceed. If for some reason that discussion blocks then please involve Russ Housley and I to unblock it. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 16:54:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHo6V-0008JI-Iz; Mon, 28 Aug 2006 16:53:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHo6U-0008JC-CU for tls@ietf.org; Mon, 28 Aug 2006 16:53:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHnZP-0003Wj-1f for tls@ietf.org; Mon, 28 Aug 2006 16:18:55 -0400 Received: from mail-n.franken.de ([193.175.24.27] helo=ilsa.franken.de) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHmeU-0005qH-O3 for tls@ietf.org; Mon, 28 Aug 2006 15:20:08 -0400 Received: from [192.168.1.3] (p5481FEBB.dip.t-dialin.net [84.129.254.187]) by ilsa.franken.de (Postfix) with ESMTP id 5EB06245D3; Mon, 28 Aug 2006 21:20:00 +0200 (CEST) (KNF account authenticated via SMTP-AUTH) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4572CCD5-382C-464B-A507-20D1084D6EAC@lurchi.franken.de> Content-Transfer-Encoding: 7bit From: Michael Tuexen Subject: Re: [TLS] draft-tuexen-dtls-for-sctp-00.txt Date: Mon, 28 Aug 2006 21:19:59 +0200 To: Joseph Salowey (jsalowey) X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.6 (--) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Joe, (taking of the ADs from CC...) thank you very much for the pointer. I'll look into it. Best regards Michael On Aug 28, 2006, at 5:37 PM, Joseph Salowey (jsalowey) wrote: > Hi Michael, > > In the context of extended EAP keying material, we have been > looking at > the problem of deriving multiple keys from a single root in a > coordinated fashion to avoid conflicts. A similar approach may > work for > TLS. I'm not sure that it makes sense to use the same details such as > IANA registry or key derivation function, but it may. > > The current version of the draft is > http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk- > deriv-01.txt. > Let me know if you have any questions. > > Cheers, > > Joe > >> -----Original Message----- >> From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] >> Sent: Monday, August 28, 2006 3:26 AM >> To: tls@ietf.org >> Cc: lars.eggert@netlab.nec.de; hartmans-ietf@mit.edu >> Subject: [TLS] draft-tuexen-dtls-for-sctp-00.txt >> >> Dear all, >> >> I would like to get some comments on draft-tuexen-dtls-for- >> sctp-00.txt. This includes >> >> - technical comments >> We would like to use the TLS master secret to generate an >> additional shared secret which >> we would use at the transport layer (SCTP) for SCTP-AUTH. >> It was already brought up, >> that this is a layer violation (but a nice one) and the >> risk would be that multiple >> instances would do this, then these multiple instances >> would use the same key material >> which is definitely bad. >> How should we progress here? From an implementation point >> of view I see only a limited >> risk here, because we will modify the TLS implementation >> to generate the additional >> material and would provide to to SCTP via a socket option. >> So there is NOT API to the >> TLS user involved. >> Another point was to have something like a registry for >> the material generated. This >> would avoid two instances to use the same material. What >> about this? Is this a good or >> bad idea? How can we achieve this, if it is a good idea? >> >> - procedural advises (Sam, Lars this is why you are CCed) >> Currently this document is an individual submission. How >> can it be progressed? Should >> it be taken to a WG? Which one? SCTP (including SCTP-AUTH) >> is handled in TSVWG and >> TLS is handled in the TLS WG. I'm not sure where DTLS was >> handled, if it was handled in >> any WG. >> >> I think having DTLS for SCTP is important because it is >> needed by anyone using SCTP with PR-SCTP or unordered >> delivery and wanting to have a TLS like security solution. >> IPFIX is one example. >> >> Best regards >> Michael >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/tls >> > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 18:38:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpiu-0001XJ-4z; Mon, 28 Aug 2006 18:36:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpis-0001XE-Ug for tls@ietf.org; Mon, 28 Aug 2006 18:36:50 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpir-0007m3-I1 for tls@ietf.org; Mon, 28 Aug 2006 18:36:50 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7SMad6O032707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2006 15:36:41 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-68.qualcomm.com [10.50.77.68]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7SMaZPB025243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Aug 2006 15:36:37 -0700 (PDT) Message-Id: <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 15:36:35 -0700 To: "Joseph Salowey \(jsalowey\)" , "Michael Tuexen" , From: Lakshminath Dondeti Subject: RE: [TLS] draft-tuexen-dtls-for-sctp-00.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: lars.eggert@netlab.nec.de, hartmans-ietf@mit.edu X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org After a quick look at the documents in consideration, I am thinking something like an IKEv2 PRF+ might also work. Each time an instance draws on the key material there would be a new key. Would that work? regards, Lakshminath At 08:37 AM 8/28/2006, Joseph Salowey \(jsalowey\) wrote: >Hi Michael, > >In the context of extended EAP keying material, we have been looking at >the problem of deriving multiple keys from a single root in a >coordinated fashion to avoid conflicts. A similar approach may work for >TLS. I'm not sure that it makes sense to use the same details such as >IANA registry or key derivation function, but it may. > >The current version of the draft is >http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk-deriv-01.txt. >Let me know if you have any questions. > >Cheers, > >Joe > > > -----Original Message----- > > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de] > > Sent: Monday, August 28, 2006 3:26 AM > > To: tls@ietf.org > > Cc: lars.eggert@netlab.nec.de; hartmans-ietf@mit.edu > > Subject: [TLS] draft-tuexen-dtls-for-sctp-00.txt > > > > Dear all, > > > > I would like to get some comments on draft-tuexen-dtls-for- > > sctp-00.txt. This includes > > > > - technical comments > > We would like to use the TLS master secret to generate an > > additional shared secret which > > we would use at the transport layer (SCTP) for SCTP-AUTH. > > It was already brought up, > > that this is a layer violation (but a nice one) and the > > risk would be that multiple > > instances would do this, then these multiple instances > > would use the same key material > > which is definitely bad. > > How should we progress here? From an implementation point > > of view I see only a limited > > risk here, because we will modify the TLS implementation > > to generate the additional > > material and would provide to to SCTP via a socket option. > > So there is NOT API to the > > TLS user involved. > > Another point was to have something like a registry for > > the material generated. This > > would avoid two instances to use the same material. What > > about this? Is this a good or > > bad idea? How can we achieve this, if it is a good idea? > > > > - procedural advises (Sam, Lars this is why you are CCed) > > Currently this document is an individual submission. How > > can it be progressed? Should > > it be taken to a WG? Which one? SCTP (including SCTP-AUTH) > > is handled in TSVWG and > > TLS is handled in the TLS WG. I'm not sure where DTLS was > > handled, if it was handled in > > any WG. > > > > I think having DTLS for SCTP is important because it is > > needed by anyone using SCTP with PR-SCTP or unordered > > delivery and wanting to have a TLS like security solution. > > IPFIX is one example. > > > > Best regards > > Michael > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 18:42:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpnW-0003ey-73; Mon, 28 Aug 2006 18:41:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHpnU-0003em-KZ for tls@ietf.org; Mon, 28 Aug 2006 18:41:36 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHpnT-0008S8-Ap for tls@ietf.org; Mon, 28 Aug 2006 18:41:36 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6F12A1E8C1C; Mon, 28 Aug 2006 15:41:34 -0700 (PDT) To: Lakshminath Dondeti Subject: Re: [TLS] draft-tuexen-dtls-for-sctp-00.txt References: <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com> From: Eric Rescorla Date: Mon, 28 Aug 2006 15:41:34 -0700 In-Reply-To: <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com> (Lakshminath Dondeti's message of "Mon, 28 Aug 2006 15:36:35 -0700") Message-ID: <86psekcwkh.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: lars.eggert@netlab.nec.de, tls@ietf.org, hartmans-ietf@mit.edu X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Lakshminath Dondeti writes: > After a quick look at the documents in consideration, I am thinking > something like an IKEv2 PRF+ might also work. > > Each time an instance draws on the key material there would be a new > key. Would that work? Well, the issue isn't really which PRF to use. Given that TLS has one and that it's got the ability generate disjoint keys from the same underlying entropy, that's kind of the obvious one to use. that's kind of a no-brainer. The issue is the layer violation and making sure that each side gets the same (unique) key even if multiple other protocols are trying to get keys out of TLS this way... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 20:48:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrkq-0002LT-FZ; Mon, 28 Aug 2006 20:47:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHrkn-0002Kw-I6; Mon, 28 Aug 2006 20:46:57 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHqDQ-0003M6-M3; Mon, 28 Aug 2006 19:08:24 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHpw8-0004Xa-Qq; Mon, 28 Aug 2006 18:50:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 7B4E1176A1; Mon, 28 Aug 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GHpve-0000ma-1j; Mon, 28 Aug 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 28 Aug 2006 18:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-openpgp-keys-11.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using OpenPGP keys for TLS authentication Author(s) : N. Mavroyanopoulos Filename : draft-ietf-tls-openpgp-keys-11.txt Pages : 13 Date : 2006-8-28 This memo proposes extensions to the TLS protocol to support the OpenPGP key format. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-openpgp-keys-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-openpgp-keys-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-8-28162842.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-openpgp-keys-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-openpgp-keys-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-8-28162842.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon Aug 28 23:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuBq-0002Mk-Qj; Mon, 28 Aug 2006 23:23:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuBo-0002Mf-Tp for tls@ietf.org; Mon, 28 Aug 2006 23:23:00 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHuBm-0007kY-IH for tls@ietf.org; Mon, 28 Aug 2006 23:23:00 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k7T3Muai006919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 28 Aug 2006 20:22:57 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-103.qualcomm.com [10.50.76.103]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k7T3MsWU021220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Aug 2006 20:22:55 -0700 (PDT) Message-Id: <7.0.1.0.2.20060828200239.06996c80@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 28 Aug 2006 20:22:54 -0700 To: EKR From: Lakshminath Dondeti Subject: Re: [TLS] draft-tuexen-dtls-for-sctp-00.txt In-Reply-To: <86psekcwkh.fsf@raman.networkresonance.com> References: <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com> <86psekcwkh.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: lars.eggert@netlab.nec.de, tls@ietf.org, hartmans-ietf@mit.edu X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org At 03:41 PM 8/28/2006, Eric Rescorla wrote: >Lakshminath Dondeti writes: > > After a quick look at the documents in consideration, I am thinking > > something like an IKEv2 PRF+ might also work. > > > > Each time an instance draws on the key material there would be a new > > key. Would that work? > >Well, the issue isn't really which PRF to use. > >Given that TLS has one and that it's got the ability generate disjoint >keys from the same underlying entropy, that's kind of the obvious one >to use. > >that's kind of a no-brainer. The issue is the layer violation >and making sure that each side gets the same (unique) key >even if multiple other protocols are trying to get keys out >of TLS this way... Hi Eric, Thanks for the explanation. Looks like I have some more reading to do to understand this fully :). Let me ask you a follow-up question: would a PRF with protocol labels and protocol specific data as input would work better instead? It is plausible then to maintain an IANA registry of such labels so there is a unique key per protocol. That was the idea Joe was proposing earlier. regards, Lakshminath >-Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 28 23:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuaz-0005Im-MS; Mon, 28 Aug 2006 23:49:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GHuax-0005Ic-L4 for tls@ietf.org; Mon, 28 Aug 2006 23:48:59 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHuaw-0001fL-Bp for tls@ietf.org; Mon, 28 Aug 2006 23:48:59 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 5D7341E8C1C; Mon, 28 Aug 2006 20:48:57 -0700 (PDT) To: Lakshminath Dondeti Subject: Re: [TLS] draft-tuexen-dtls-for-sctp-00.txt References: <7.0.1.0.2.20060828153142.06aa3fd0@qualcomm.com> <86psekcwkh.fsf@raman.networkresonance.com> <7.0.1.0.2.20060828200239.06996c80@qualcomm.com> From: Eric Rescorla Date: Mon, 28 Aug 2006 20:48:57 -0700 In-Reply-To: <7.0.1.0.2.20060828200239.06996c80@qualcomm.com> (Lakshminath Dondeti's message of "Mon, 28 Aug 2006 20:22:54 -0700") Message-ID: <86k64scic6.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: lars.eggert@netlab.nec.de, tls@ietf.org, hartmans-ietf@mit.edu X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Lakshminath Dondeti writes: > Thanks for the explanation. Looks like I have some more reading to do > to understand this fully :). > Let me ask you a follow-up question: would a PRF with protocol labels > and protocol specific data as input would work better instead? It is > plausible then to maintain an IANA registry of such labels so there is > a unique key per protocol. That was the idea Joe was proposing > earlier. That's basically what Michael is talking about.... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 30 11:05:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRbg-0000hC-2m; Wed, 30 Aug 2006 11:03:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIRbf-0000h7-J0 for tls@ietf.org; Wed, 30 Aug 2006 11:03:55 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIRbe-0006CI-Cz for tls@ietf.org; Wed, 30 Aug 2006 11:03:55 -0400 Received: (qmail 20227 invoked by uid 0); 30 Aug 2006 14:57:10 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 30 Aug 2006 14:57:10 -0000 Message-Id: <7.0.0.16.2.20060830105445.078b67d8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 30 Aug 2006 10:57:10 -0400 To: tls@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] draft-housley-evidence-extns-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt I would like the TLS WG to be aware of this document. Review is encouraged, and comments are welcome. I would like to make a presentation about this document at the San Diego IETF so that the TLS WG can decide if this should become a WG document. Thanks, Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 30 21:03:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIawZ-0002DP-M4; Wed, 30 Aug 2006 21:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIawY-0002DK-VE for tls@ietf.org; Wed, 30 Aug 2006 21:02:06 -0400 Received: from smtp-out2.blueyonder.co.uk ([195.188.213.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIawV-0004SL-LI for tls@ietf.org; Wed, 30 Aug 2006 21:02:06 -0400 Received: from [172.23.170.146] (helo=anti-virus03-09) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1GIawN-0003ye-Rp for tls@ietf.org; Thu, 31 Aug 2006 02:01:55 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out1.blueyonder.co.uk with esmtp (Exim 4.52) id 1GIawH-0007ER-0T for tls@ietf.org; Thu, 31 Aug 2006 02:01:49 +0100 Message-ID: <44F634F8.1070900@blueyonder.co.uk> Date: Thu, 31 Aug 2006 02:01:44 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] draft-housley-evidence-extns-00.txt References: <7.0.0.16.2.20060830105445.078b67d8@vigilsec.com> In-Reply-To: <7.0.0.16.2.20060830105445.078b67d8@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Russ Housley wrote: > http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt > > I would like the TLS WG to be aware of this document. Review is > encouraged, and comments are welcome. What is the rationale for complicating TLS with this, when it seems as though it could just as easily be supported at the application protocol level? -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Aug 31 11:42:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIody-0005i0-Qd; Thu, 31 Aug 2006 11:39:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GIodx-0005hv-II for tls@ietf.org; Thu, 31 Aug 2006 11:39:49 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIodv-0002ZA-9Q for tls@ietf.org; Thu, 31 Aug 2006 11:39:49 -0400 Received: (qmail 1246 invoked by uid 0); 31 Aug 2006 15:39:39 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.235.104) by woodstock.binhost.com with SMTP; 31 Aug 2006 15:39:39 -0000 Message-Id: <7.0.0.16.2.20060831113221.03e77080@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 31 Aug 2006 11:39:36 -0400 To: tls@ietf.org From: Russ Housley Subject: Re: [TLS] draft-housley-evidence-extns-00.txt In-Reply-To: <44F634F8.1070900@blueyonder.co.uk> References: <7.0.0.16.2.20060830105445.078b67d8@vigilsec.com> <44F634F8.1070900@blueyonder.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org David: That is true, an application running on top of TLS could handle this feature, but then every application would have to do so. By putting it into TLS, any application can easily be supported. The alerts to mark the beginning and end were intended to allow applications to generate evidence for a portion of the application exchange, but these can be sent at the beginning and the at end of the TLS session to support arbitrary applications. Russ At 09:01 PM 8/30/2006, David Hopwood wrote: >Russ Housley wrote: > > http://www.ietf.org/internet-drafts/draft-housley-evidence-extns-00.txt > > > > I would like the TLS WG to be aware of this document. Review is > > encouraged, and comments are welcome. > >What is the rationale for complicating TLS with this, when it seems as >though it could just as easily be supported at the application protocol >level? > >-- >David Hopwood > > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls