From tls-bounces@lists.ietf.org Tue Nov 01 10:19:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxvL-0000km-FJ; Tue, 01 Nov 2005 10:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWxvJ-0000kb-EB for tls@megatron.ietf.org; Tue, 01 Nov 2005 10:19:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26170 for ; Tue, 1 Nov 2005 10:19:21 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EWy9i-0004q3-TC for tls@ietf.org; Tue, 01 Nov 2005 10:34:35 -0500 Received: (qmail 3430 invoked by uid 0); 1 Nov 2005 15:18:07 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (129.6.193.7) by woodstock.binhost.com with SMTP; 1 Nov 2005 15:18:07 -0000 Message-Id: <7.0.0.10.2.20051101093131.05fb99e0@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Tue, 01 Nov 2005 10:17:44 -0500 To: Bodo Moeller From: Russ Housley Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 In-Reply-To: <20051030044633.GA12388@tau.local> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> <20051030044633.GA12388@tau.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Bodo: Two points: 1) I understand your points, and I understood them before I made my comments. It seems to me that we would be doing the community a big service is the same API could be used in both environments. I think it is work a bit of discussion before we assume that different APIs are the way to go. 2) I am concerned that the nonces that are exchanged in the ClinetHello and ServerHello might not big enough when the ECDH keys are not ephemeral. The random values are a fixed length (28 bytes or 224 bits), which is quite a bit smaller that the EC values (either 256, 384, or 512 bits). The inclusion of a UKM would resolve this concern by allowing the client to provide more random input. Russ At 11:46 PM 10/29/2005, Bodo Moeller wrote: >On Sat, Oct 29, 2005 at 04:41:04PM -0400, Russ Housley wrote: > > >>> [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two > >>> specifications are not compatible in some significant ways. By this, > >>> I mean that a subroutine cannot be written that works with both this > >>> document and with RFC 3278. To me, this would be highly desirable. > >>> One glaring difference is the support for UserKeyingMaterial (or UKM) > >>> that is provided by the originator (the client in this context). The > >>> UKM and the ECDH shared secret are both inputs to the KDF. ] > > >> SBW> Both documents use the same ECDH primitive but different KDFs. This > >> is a very common situation, isn't it? You can use a single subroutine for > >> both if your subroutine only does the Z computation, or takes the KDF as a > >> parameter. > > > I agree that the computation of Z is the same. If you consider the KDF to > > be a selectable parameter, the the inputs still do not line up. Maybe I > > am missing something. Here is how I am interpreting your comment: > > > > RFC 3278: > > > > 1) Use ECDH to compute the shared secret Z. > > > > 2) Compute KEK using a KDF with the following inputs: > > a) Z > > b) KEK algorithm identifier and key size > > c) UserKeyingMaterial > > > > TLS-ECC Draft: > > > > 1) Use ECDH to compute the shared secret Z. > > > > 2) Compute KEK using the identity KDF one input: Z > > > > So, I continue to be confused about the API. It does not look to me > > like the same API can be used for ECDH_Key_Agreement() in these two > > cases. > >TLS has no need for something like the UserKeyingMaterial in CMS since >TLS always includes client and server nonces in the hash computation >that obtains the master secret from the premaster secret. > >When using an API designed for the CMS case *with* these additional >parameters (where the result is supposed to be a key-encryption key, >KEK), you'd just not use them for the TLS case -- i.e. write NULL or >an appropriate equivalent. TLS does not need such parameters and has >no input to provide for them. So the TLS case of ECDH_Key_Agreement() >presumably would fail if any UserKeyingMaterial *is* provided, since >this would indicate a programming error. The inputs don't line up, >but they don't have to. > >Note that the ECDH computations in the TLS-ECC draft are modelled >quite closely after the standard DH computations in TLS. This >delivers what TLS needs in a straightforward way and avoids >unnecessary protocol complexity. There is no reason to do ECDH >fundamentally different from DH -- and there certainly is no reason to >make the *differences* between ECDH in CMS and ECDH in TLS >fundamentally different from those between DH in CMS and DH in TLS. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 01 10:53:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyS2-0001lH-Dn; Tue, 01 Nov 2005 10:53:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWyS1-0001kn-8C for tls@megatron.ietf.org; Tue, 01 Nov 2005 10:53:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28486 for ; Tue, 1 Nov 2005 10:53:08 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWygQ-0008Mi-3S for tls@ietf.org; Tue, 01 Nov 2005 11:08:23 -0500 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.55.50] (helo=tau.local) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1EWyRw0mG8-0006R2; Tue, 01 Nov 2005 16:53:24 +0100 Received: by tau.local (Postfix, from userid 500) id B3AF22F235; Tue, 1 Nov 2005 08:52:41 -0700 (MST) Date: Tue, 1 Nov 2005 08:52:41 -0700 From: Bodo Moeller To: Russ Housley Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 Message-ID: <20051101155240.GA18238@tau.local> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> <20051030044633.GA12388@tau.local> <7.0.0.10.2.20051101093131.05fb99e0@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.0.10.2.20051101093131.05fb99e0@vigilsec.com> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Tue, Nov 01, 2005 at 10:17:44AM -0500, Russ Housley wrote: > 2) I am concerned that the nonces that are exchanged in the > ClinetHello and ServerHello might not big enough when the ECDH keys > are not ephemeral. The random values are a fixed length (28 bytes or > 224 bits), which is quite a bit smaller that the EC values (either > 256, 384, or 512 bits). The inclusion of a UKM would resolve this > concern by allowing the client to provide more random input. Would we require more from the nonces than that they be unique? Even if so, 224 bits (plus a few from the 32-bit timestamp) is plenty. In comparison, from the 384-bit curve, we can expect only 384/2 = 192 "bits of security" (which, if course, is actually a lot). I certainly understand that sometimes it is preferred to be a little more paranoid, just in case. But, then, one clearly should use ephemeral ECDH and avoid using fixed keys for anything other than signatures! In an interactive protocol like TLS, there's no need to prefer fixed-key ECDH except when one is intentionally sacrificing some security in the sake of performance. And your concern applies only to the case of fixed-key ECDH. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 06 12:55:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYokJ-0002dD-OG; Sun, 06 Nov 2005 12:55:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYokI-0002a5-94 for tls@megatron.ietf.org; Sun, 06 Nov 2005 12:55:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11407 for ; Sun, 6 Nov 2005 12:55:32 -0500 (EST) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYozj-0000ON-UY for tls@ietf.org; Sun, 06 Nov 2005 13:11:56 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 17:55:33 +0000 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] AD comments on draft-ietf-tls-ecc-11 Date: Sun, 6 Nov 2005 17:55:25 -0000 Message-ID: Thread-Topic: [TLS] AD comments on draft-ietf-tls-ecc-11 Thread-Index: AcXe+EC4WRTR8dNZRkOwbF3gb2BAkgD/4GnA From: "Stefan Santesson" To: "Russ Housley" , "Bodo Moeller" X-OriginalArrivalTime: 06 Nov 2005 17:55:33.0295 (UTC) FILETIME=[489E9BF0:01C5E2FB] X-Spam-Score: 2.0 (++) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Russ, I sense a misunderstanding. You write: TLS-ECC Draft: 1) Use ECDH to compute the shared secret Z. 2) Compute KEK using the identity KDF one input: Z This is not how I read the tls-ecc draft. I read it as: TLS-ECC Draft: 1) Use ECDH to compute the ECDH shared secret 2) Use identity KDF (IEEE 1363) to obtain the TLS premaster secret from the ECDH shared secret. 3) Compute TLS master secret and KEK using the TLS PRF as defined in RFC 2246 Observe the note in 5.10 in draft-ietf-tls-ecc-12: "(Note that this use of the identity KDF is a technicality. The complete picture is that ECDH is employed with a non-trivial KDF because TLS does not directly use the premaster secret for anything other than for computing the master secret. As of TLS 1.0 [2] and 1.1 [3] this means that the MD5- and SHA-1-based TLS PRF serves as a KDF; it is conceivable that future TLS versions or new TLS extensions introduced in the future may vary this computation.)" AND "...using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the _premaster secret_ is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string." I think the draft is correct. The RFC 3278 KDF is out of scope here unless we want to change RFC 2246 key derivation. Stefan Santesson Program Manager, Standards Liaison Windows Security =20 > -----Original Message----- > From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On > Behalf Of Russ Housley > Sent: den 1 november 2005 07:18 > To: Bodo Moeller > Cc: tls@ietf.org > Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 >=20 > Bodo: >=20 > Two points: >=20 > 1) I understand your points, and I understood them before I made my > comments. It seems to me that we would be doing the community a big > service is the same API could be used in both environments. I think > it is work a bit of discussion before we assume that different APIs > are the way to go. >=20 > 2) I am concerned that the nonces that are exchanged in the > ClinetHello and ServerHello might not big enough when the ECDH keys > are not ephemeral. The random values are a fixed length (28 bytes or > 224 bits), which is quite a bit smaller that the EC values (either > 256, 384, or 512 bits). The inclusion of a UKM would resolve this > concern by allowing the client to provide more random input. >=20 > Russ >=20 >=20 > At 11:46 PM 10/29/2005, Bodo Moeller wrote: > >On Sat, Oct 29, 2005 at 04:41:04PM -0400, Russ Housley wrote: > > > > >>> [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These two > > >>> specifications are not compatible in some significant ways. By > this, > > >>> I mean that a subroutine cannot be written that works with both > this > > >>> document and with RFC 3278. To me, this would be highly > desirable. > > >>> One glaring difference is the support for UserKeyingMaterial (or > UKM) > > >>> that is provided by the originator (the client in this context). > The > > >>> UKM and the ECDH shared secret are both inputs to the KDF. ] > > > > >> SBW> Both documents use the same ECDH primitive but different KDFs. > This > > >> is a very common situation, isn't it? You can use a single subroutine > for > > >> both if your subroutine only does the Z computation, or takes the KDF > as a > > >> parameter. > > > > > I agree that the computation of Z is the same. If you consider the > KDF to > > > be a selectable parameter, the the inputs still do not line up. Maybe > I > > > am missing something. Here is how I am interpreting your comment: > > > > > > RFC 3278: > > > > > > 1) Use ECDH to compute the shared secret Z. > > > > > > 2) Compute KEK using a KDF with the following inputs: > > > a) Z > > > b) KEK algorithm identifier and key size > > > c) UserKeyingMaterial > > > > > > TLS-ECC Draft: > > > > > > 1) Use ECDH to compute the shared secret Z. > > > > > > 2) Compute KEK using the identity KDF one input: Z > > > > > > So, I continue to be confused about the API. It does not look to me > > > like the same API can be used for ECDH_Key_Agreement() in these two > > > cases. > > > >TLS has no need for something like the UserKeyingMaterial in CMS since > >TLS always includes client and server nonces in the hash computation > >that obtains the master secret from the premaster secret. > > > >When using an API designed for the CMS case *with* these additional > >parameters (where the result is supposed to be a key-encryption key, > >KEK), you'd just not use them for the TLS case -- i.e. write NULL or > >an appropriate equivalent. TLS does not need such parameters and has > >no input to provide for them. So the TLS case of ECDH_Key_Agreement() > >presumably would fail if any UserKeyingMaterial *is* provided, since > >this would indicate a programming error. The inputs don't line up, > >but they don't have to. > > > >Note that the ECDH computations in the TLS-ECC draft are modelled > >quite closely after the standard DH computations in TLS. This > >delivers what TLS needs in a straightforward way and avoids > >unnecessary protocol complexity. There is no reason to do ECDH > >fundamentally different from DH -- and there certainly is no reason to > >make the *differences* between ECDH in CMS and ECDH in TLS > >fundamentally different from those between DH in CMS and DH in TLS. >=20 >=20 > _______________________________________________ > 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 Sun Nov 06 13:19:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYp77-00007N-4g; Sun, 06 Nov 2005 13:19:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYp75-00007I-64 for tls@megatron.ietf.org; Sun, 06 Nov 2005 13:19:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12849 for ; Sun, 6 Nov 2005 13:19:05 -0500 (EST) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EYpMW-00011n-TH for tls@ietf.org; Sun, 06 Nov 2005 13:35:29 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 18:19:20 +0000 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] AD comments on draft-ietf-tls-ecc-11 Date: Sun, 6 Nov 2005 18:19:09 -0000 Message-ID: Thread-Topic: [TLS] AD comments on draft-ietf-tls-ecc-11 Thread-Index: AcXe+EC4WRTR8dNZRkOwbF3gb2BAkgD/4GnAAAGHtRA= From: "Stefan Santesson" To: "Russ Housley" , "Bodo Moeller" X-OriginalArrivalTime: 06 Nov 2005 18:19:20.0830 (UTC) FILETIME=[9B7F29E0:01C5E2FE] X-Spam-Score: 2.0 (++) X-Scan-Signature: a0534e6179a1e260079328e8b03c7901 Content-Transfer-Encoding: quoted-printable 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I was a little hot on the send button. I meant step 3 to say: 3) Compute TLS master secret and derive other keys and secrets using the TLS PRF as defined in RFC 2246 I'm not sure what secret or key you mean by "KEK" in your example. Stefan Santesson Program Manager, Standards Liaison Windows Security =20 > -----Original Message----- > From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On > Behalf Of Stefan Santesson > Sent: den 6 november 2005 09:55 > To: Russ Housley; Bodo Moeller > Cc: tls@ietf.org > Subject: RE: [TLS] AD comments on draft-ietf-tls-ecc-11 >=20 > Russ, >=20 > I sense a misunderstanding. >=20 > You write: >=20 > TLS-ECC Draft: > 1) Use ECDH to compute the shared secret Z. > 2) Compute KEK using the identity KDF one input: Z >=20 >=20 > This is not how I read the tls-ecc draft. I read it as: >=20 > TLS-ECC Draft: > 1) Use ECDH to compute the ECDH shared secret > 2) Use identity KDF (IEEE 1363) to obtain the TLS premaster secret > from > the ECDH shared secret. > 3) Compute TLS master secret and KEK using the TLS PRF as defined > in RFC 2246 >=20 > Observe the note in 5.10 in draft-ietf-tls-ecc-12: >=20 > "(Note that this use of the identity KDF is a technicality. The > complete picture is that ECDH is employed with a non-trivial KDF > because TLS does not directly use the premaster secret for anything > other than for computing the master secret. As of TLS 1.0 [2] and > 1.1 [3] this means that the MD5- and SHA-1-based TLS PRF serves as a > KDF; it is conceivable that future TLS versions or new TLS extensions > introduced in the future may vary this computation.)" >=20 > AND >=20 > "...using the ECKAS-DH1 scheme with the identity map as key derivation > function (KDF), so that the _premaster secret_ is the x-coordinate of > the ECDH shared secret elliptic curve point represented as an octet > string." >=20 >=20 >=20 > I think the draft is correct. The RFC 3278 KDF is out of scope here > unless we want to change RFC 2246 key derivation. >=20 >=20 > Stefan Santesson > Program Manager, Standards Liaison > Windows Security >=20 >=20 > > -----Original Message----- > > From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] > On > > Behalf Of Russ Housley > > Sent: den 1 november 2005 07:18 > > To: Bodo Moeller > > Cc: tls@ietf.org > > Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 > > > > Bodo: > > > > Two points: > > > > 1) I understand your points, and I understood them before I made my > > comments. It seems to me that we would be doing the community a big > > service is the same API could be used in both environments. I think > > it is work a bit of discussion before we assume that different APIs > > are the way to go. > > > > 2) I am concerned that the nonces that are exchanged in the > > ClinetHello and ServerHello might not big enough when the ECDH keys > > are not ephemeral. The random values are a fixed length (28 bytes or > > 224 bits), which is quite a bit smaller that the EC values (either > > 256, 384, or 512 bits). The inclusion of a UKM would resolve this > > concern by allowing the client to provide more random input. > > > > Russ > > > > > > At 11:46 PM 10/29/2005, Bodo Moeller wrote: > > >On Sat, Oct 29, 2005 at 04:41:04PM -0400, Russ Housley wrote: > > > > > > >>> [ RFC 3278 specifies ECDH for use with S/MIME and CMS. These > two > > > >>> specifications are not compatible in some significant ways. > By > > this, > > > >>> I mean that a subroutine cannot be written that works with > both > > this > > > >>> document and with RFC 3278. To me, this would be highly > > desirable. > > > >>> One glaring difference is the support for UserKeyingMaterial > (or > > UKM) > > > >>> that is provided by the originator (the client in this > context). > > The > > > >>> UKM and the ECDH shared secret are both inputs to the KDF. ] > > > > > > >> SBW> Both documents use the same ECDH primitive but different > KDFs. > > This > > > >> is a very common situation, isn't it? You can use a single > subroutine > > for > > > >> both if your subroutine only does the Z computation, or takes the > KDF > > as a > > > >> parameter. > > > > > > > I agree that the computation of Z is the same. If you consider > the > > KDF to > > > > be a selectable parameter, the the inputs still do not line up. > Maybe > > I > > > > am missing something. Here is how I am interpreting your comment: > > > > > > > > RFC 3278: > > > > > > > > 1) Use ECDH to compute the shared secret Z. > > > > > > > > 2) Compute KEK using a KDF with the following inputs: > > > > a) Z > > > > b) KEK algorithm identifier and key size > > > > c) UserKeyingMaterial > > > > > > > > TLS-ECC Draft: > > > > > > > > 1) Use ECDH to compute the shared secret Z. > > > > > > > > 2) Compute KEK using the identity KDF one input: Z > > > > > > > > So, I continue to be confused about the API. It does not look to > me > > > > like the same API can be used for ECDH_Key_Agreement() in these > two > > > > cases. > > > > > >TLS has no need for something like the UserKeyingMaterial in CMS > since > > >TLS always includes client and server nonces in the hash computation > > >that obtains the master secret from the premaster secret. > > > > > >When using an API designed for the CMS case *with* these additional > > >parameters (where the result is supposed to be a key-encryption key, > > >KEK), you'd just not use them for the TLS case -- i.e. write NULL or > > >an appropriate equivalent. TLS does not need such parameters and has > > >no input to provide for them. So the TLS case of > ECDH_Key_Agreement() > > >presumably would fail if any UserKeyingMaterial *is* provided, since > > >this would indicate a programming error. The inputs don't line up, > > >but they don't have to. > > > > > >Note that the ECDH computations in the TLS-ECC draft are modelled > > >quite closely after the standard DH computations in TLS. This > > >delivers what TLS needs in a straightforward way and avoids > > >unnecessary protocol complexity. There is no reason to do ECDH > > >fundamentally different from DH -- and there certainly is no reason > to > > >make the *differences* between ECDH in CMS and ECDH in TLS > > >fundamentally different from those between DH in CMS and DH in TLS. > > > > > > _______________________________________________ > > 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 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 07 16:35:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEej-0005sm-45; Mon, 07 Nov 2005 16:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEeh-0005sh-6I for tls@megatron.ietf.org; Mon, 07 Nov 2005 16:35:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09285 for ; Mon, 7 Nov 2005 16:35:30 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EZEuN-0000zp-Kn for tls@ietf.org; Mon, 07 Nov 2005 16:52:07 -0500 Received: (qmail 18624 invoked by uid 0); 7 Nov 2005 21:35:44 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (209.52.108.226) by woodstock.binhost.com with SMTP; 7 Nov 2005 21:35:44 -0000 Message-Id: <7.0.0.10.2.20051107162050.05c42f60@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Mon, 07 Nov 2005 16:26:55 -0500 To: Bodo Moeller From: Russ Housley Subject: Re: [TLS] AD comments on draft-ietf-tls-ecc-11 In-Reply-To: <20051101155240.GA18238@tau.local> References: <20051011191218.47DB78A02D@laser.networkresonance.com> <042401c5ced5$738ccb50$da6514ac@simon> <7.0.0.10.2.20051029160513.04b3eb98@vigilsec.com> <20051030044633.GA12388@tau.local> <7.0.0.10.2.20051101093131.05fb99e0@vigilsec.com> <20051101155240.GA18238@tau.local> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Bodo: > > 2) I am concerned that the nonces that are exchanged in the > > ClinetHello and ServerHello might not big enough when the ECDH keys > > are not ephemeral. The random values are a fixed length (28 bytes or > > 224 bits), which is quite a bit smaller that the EC values (either > > 256, 384, or 512 bits). The inclusion of a UKM would resolve this > > concern by allowing the client to provide more random input. > >Would we require more from the nonces than that they be unique? >Even if so, 224 bits (plus a few from the 32-bit timestamp) is plenty. >In comparison, from the 384-bit curve, we can expect only 384/2 = 192 >"bits of security" (which, if course, is actually a lot). > >I certainly understand that sometimes it is preferred to be a little >more paranoid, just in case. But, then, one clearly should use >ephemeral ECDH and avoid using fixed keys for anything other than >signatures! In an interactive protocol like TLS, there's no need to >prefer fixed-key ECDH except when one is intentionally sacrificing >some security in the sake of performance. And your concern applies >only to the case of fixed-key ECDH. While I am not satisfied with the size of the nonce with 512-bit ECDH, this document should probably not be the brunt of this criticism. I will raise this issue as the working group moves forward with updates to the base TLS protocol specification to address hash function independence. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 08 12:32:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXKp-0006uq-C9; Tue, 08 Nov 2005 12:32:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXKl-0006tu-8Y for tls@megatron.ietf.org; Tue, 08 Nov 2005 12:32:35 -0500 Received: from newodin.ietf.org (newodin.ietf.org [10.27.6.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19302 for ; Tue, 8 Nov 2005 12:32:09 -0500 (EST) Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1EZXKk-0001pN-PP; Tue, 08 Nov 2005 12:32:34 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 08 Nov 2005 12:32:34 -0500 Cc: tls@ietf.org Subject: [TLS] Last Call: 'ECC Cipher Suites for TLS' to Informational RFC X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'ECC Cipher Suites for TLS ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-11-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 08 14:25:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ5q-0006UR-2H; Tue, 08 Nov 2005 14:25:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZZ5n-0006U8-FN for tls@megatron.ietf.org; Tue, 08 Nov 2005 14:25:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27596 for ; Tue, 8 Nov 2005 14:24:48 -0500 (EST) Resent-From: nagendra@cs.stanford.edu Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZZLd-0005eS-3S for tls@ietf.org; Tue, 08 Nov 2005 14:41:39 -0500 Received: from theory.stanford.edu ([171.64.78.10]) by agp.stanford.edu with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.43) id 1EZZ5X-0003VG-K7 for tls@ietf.org; Tue, 08 Nov 2005 11:24:59 -0800 Received: from mail by theory.Stanford.EDU with spam-scanned (Exim 4.30) id 1EZZ5W-0006Da-Pq for tls@ietf.org; Tue, 08 Nov 2005 11:24:59 -0800 Received: from cipher.stanford.edu ([171.64.78.146]) by theory.Stanford.EDU with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1EZZ5W-0006DW-Ox for tls@ietf.org; Tue, 08 Nov 2005 11:24:58 -0800 Received: from cipher.Stanford.EDU (localhost.localdomain [127.0.0.1]) by cipher.Stanford.EDU (8.13.4/8.12.11) with ESMTP id jA8JOwku030176 for ; Tue, 8 Nov 2005 11:24:58 -0800 Received: (from nagendra@localhost) by cipher.Stanford.EDU (8.13.4/8.13.4/Submit) id jA8JOw2K030175 for tls@ietf.org; Tue, 8 Nov 2005 11:24:58 -0800 Resent-Message-Id: <200511081924.jA8JOw2K030175@cipher.Stanford.EDU> X-Authentication-Warning: cipher.Stanford.EDU: nagendra set sender to nagendra@cs.stanford.edu using -f Date: Tue, 8 Nov 2005 11:19:02 -0800 From: nagendra modadugu To: David McGrew Message-ID: <20051108191902.GA29787@cs.stanford.edu> References: <725E77DD-121D-493D-BF17-79A85A7F7672@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <725E77DD-121D-493D-BF17-79A85A7F7672@cisco.com> User-Agent: Mutt/1.4.1i Resent-Date: Tue, 8 Nov 2005 11:24:58 -0800 Resent-To: tls@ietf.org X-Scan-Signature: 182a93e729013cb8e6197caf3eccd507 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-2.Stanford.EDU X-Spam-Status: No, score=-104.9 required=7.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=no version=3.0.4-cs-csdcf X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ietf-tls@lists.certicom.com Subject: [TLS] Re: comments on draft-modadugu-tls-ctr-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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Dave, thanks for your comments. I'll integrate changes into the next revision of the drafts. Some comments inline: > Section 1.1. > > "Parallelizable" is a real implementation advantage, but the feature > that really buys hardware efficiency is the fact that CTR is amenable > to pipelining in hardware. It's probably worth mentioning. Good point. > Section 3.1. > > A nit: I'd clarify "The cipher stream generated by AES-CTR is much > like the cipher stream generated by stream ciphers like RC4." to > something like "AES-CTR is functionally equivalent to a stream > cipher; it generates a pseudorandom cipher stream that is exored into > the plaintext to form the ciphertext." Right. > Section 3.1.1. > > Another nit: "A given counter block MUST never be used more than once > with the same key." The term "used" might not be clear to an > implementer. It might be better to put this MUST after the > definition of AES-CTR, at which point an implementer new to CTR would > have a better understanding. Sure, I'm happy to repeat the statement. > The definition speaks of most significant and least significant, but > are we talking about integers or bit strings? "Leftmost" and > "rightmost" might be more precise. Similarly, the increment function > is presumably defined in terms of an unsigned integer in network byte > order, but that's not stated. It might be implicit from some TLS > presentation layer convention I'm not aware of, but it would be good > to state it anyway. Right. > It is great that the client_write_iv and server_write_iv values can > be used to set the initial blocks; it looks like a good design. I'm > curious about whether or not there is an 'entropy bottleneck' in the > KDF though; have you analyzed this? The output from the KDF is used in the same same way other ciphers use KDF output -- so we certainly haven't made entropy exhaustion an issue through our design. > The CtrBlk definition clears up some of the questions I'd had > earlier; might be good to move it up higher in the text. I'll look into how the layout may be modified. > A nit: it would be good to add an argument to the TRUNC() function > that indicates the length that it returns. (Here I'm passing on a > comment that I've heard when I've used implicit lengths in crypto > specs that I've written :-) > > Another nit: INCR(CtrBlk) would be more clear than CtrBlk := CtrBlk + 1. The notation here is lifted from Housley's RFC3686 -- I'd prefer to maintain some fidelity with his notation, unless clarity is a big issue here. > A question: why not include AES-192? Not that I care much either > way, but I'm curious. TLS 1.1 only supports AES-128 and AES-256 in CBC mode, so CTR mode is essentially a mirror of those modes. > In order to allow crypto hardware to really take advantage of > parallel/pipelined processing, it would make sense to also define an > AES-GCM ciphersuite for TLS, which would allow the elimination of > HMAC-SHA1 for bulk data processing. RFC4106 (GCM ESP) is in many > ways identical to RFC 3686, on which this draft is based, so I > believe that the definition would be quite easy. AES-GCM would offer > efficiency and/or speed advantages that would be useful in servers or > network devices that aggregate many TLS connections. AES-GCM is certainly interesting, but for now we'd like to focus on AES-CTR -- we'd be interested in investigating authenticated encryption modes in the future. Thanks, nagendra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 09 14:01:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvCI-00032G-1c; Wed, 09 Nov 2005 14:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX1Lc-0001sL-Nr for tls@megatron.ietf.org; Tue, 01 Nov 2005 13:59:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08036 for ; Tue, 1 Nov 2005 13:58:43 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX1a2-0007bV-VI for tls@ietf.org; Tue, 01 Nov 2005 14:14:00 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 1 Nov 2005 10:58:51 -0800 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 10:58:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 10:58:43 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Nov 2005 10:58:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Testing of CertificateStatus TLS Extension Date: Tue, 1 Nov 2005 11:00:02 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1143773E2@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [TLS] Testing of CertificateStatus TLS Extension Thread-Index: AcXPUoasC/ufeIcETy6ysBAlLOPyygPw99cg From: "Joshua Ball" To: , X-OriginalArrivalTime: 01 Nov 2005 18:58:43.0272 (UTC) FILETIME=[478E7480:01C5DF16] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Nov 2005 14:01:21 -0500 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Yes, we have implemented this for Vista. I will get some more information to you about a Beta. -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Yngve Nysaeter Pettersen Sent: Wednesday, October 12, 2005 8:29 AM To: tls@ietf.org Subject: [TLS] Testing of CertificateStatus TLS Extension Hi, I've recently started experimenting with the CertificateStatus TLS =20 Extension. Has anyone implemented serverside support for this extension? And if so, would it be possible for me to access a testserver that supports the =20 extension so that we may test each others implementation? --=20 Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 ******************************************************************** _______________________________________________ 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 Wed Nov 09 14:01:26 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZvCI-00032z-GY; Wed, 09 Nov 2005 14:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZv6b-0000oy-GF for tls@megatron.ietf.org; Wed, 09 Nov 2005 13:55:33 -0500 Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00074 for ; Wed, 9 Nov 2005 13:55:04 -0500 (EST) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA9ItL3N005553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Nov 2005 20:55:21 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA9ItHLX028419; Wed, 9 Nov 2005 20:55:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17266.17941.160710.5249@fireball.kivinen.iki.fi> Date: Wed, 9 Nov 2005 20:55:17 +0200 From: Tero Kivinen To: tls@ietf.org, Eric Rescorla X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 22 min X-Total-Time: 21 min Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 09 Nov 2005 14:01:20 -0500 Cc: Mohamad.Badra@enst.frg.cnri.reston.va.us, Ibrahim.Hajjeh@esrgroups.org Subject: [TLS] draft-badra-hajjeh-mtls-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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I promised in the TLS WG to review this draft, so here are my comments. Firstly as someone else pointed out after the meeting, there is really no reason to do any modifications to TLS to provide that kind of multiplexing support, this all could simply be done in an application layer doing normal port forwarding style connections multiplexing multiple port forwardings inside one TLS tunnel. There is nothing in the draft that I can find that would tie the multiplexed streams to the TLS exchange itself, i.e. the applications cannot really even see they are multiplexed over TLS tunnel. The whole draft seems to be adding similar feature that is in the secure shell, i.e. port forwarding (and if I understood correctly this is local to local port forwarding, so more limited than what is in secsh). See draft-ietf-secsh-connect-25.txt section 7. It does not take account some of the issues of the forwarding. I didn't really understood if it has a way to dynamimcally create and cancelo those forwardings or not. Also didn't see if it supports runnig multiple streams over same ports, i.e. if you forward port 25 from your laptop throgh tls tunnel to smtp port (250) of the mail server, do you allow multiple connections sharing that same forwarding at the asme (i.e. send multiple mails simultaneously). As far as I understood there is no flow control in the streams. That kind of feature is mandatory in case you put multiple streams inside one stream, and that flow control MUST be per stream. The common problem happening with ssh1, which didn't have this was that you forwarded 2 services over the same ssh connection. The first one was sending data to some service all the time, and then when the destination server decided, that it does not want to read data right now, there was no way to tell that to the other end of the tunnel, so the sender would stop sending data. At some point all the buffers in the destination end filled up, and the only way it could use to stop the other end sending data was to use flow control on the ssh-connection itself, i.e not reading any more data from the ssh TCP stream. This also stopped all other forwarded connections running on the same session.. SSH2 fixed this including flow control to each channel separtely, i.e. the receiving end of the channel can say that other end is only allowed to send xx bytes of data, and then it must stop. When the receiveing end managed to send those data forward to the final destination, it would again say to sender ssh that now we are ready to take xx bytes of more data and so on. The draft needs quite a lot more work to be usable, and at least for me it was very hard to understand how the protocol actually worked (thus it might be that I completely misunderstood it). On the other hand secure shell is already doing exactly what I understood what it is trying to do, and it is one of the most common use scenarios of the secure shell already, so I do not know if we want to have another way to do exactly same thing in TLS. -- kivinen@safenet-inc.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 09 16:26:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSG-0001R5-Ug; Wed, 09 Nov 2005 16:26:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZxSG-0001R0-1P for tls@megatron.ietf.org; Wed, 09 Nov 2005 16:26:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10672 for ; Wed, 9 Nov 2005 16:25:35 -0500 (EST) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EZxiK-0002UE-Dy for tls@ietf.org; Wed, 09 Nov 2005 16:42:41 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Nov 2005 21:25:46 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2005 21:25:38 -0000 Message-ID: Thread-Topic: Microsoft user mapping extension Thread-Index: AcXldCEO1TUwvYqkQFSuhfbDPgnKYA== From: "Stefan Santesson" To: "Eric Rescorla" , X-OriginalArrivalTime: 09 Nov 2005 21:25:46.0908 (UTC) FILETIME=[262875C0:01C5E574] X-Spam-Score: 2.0 (++) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: Subject: [TLS] Microsoft user mapping extension 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org At the TLS meeting yesterday I presented our plans to submit an ID on our new user mapping extension to be published as an Informational RFC. This RFC will define both a new TLS extension as well as a new handshake message. The purpose is to allow the client to send a name hint to the server in the form of a UPN (Universal Principal Name) through which the server can locate the users account in Active Directory. I got the question yesterday why we don's simply send the UPN in a client hello and thus avoid defining a new handshake message. The reason is that we don't want to expose the users UPN until we are clear that the server understands this extension and that the server is one of those that are trusted by the client to receive this information. We plan to have this new ID ready for submission next week. Stefan Santesson Program Manager, Standards Liaison Windows Security =20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 10 01:12:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea5fY-0001BN-9v; Thu, 10 Nov 2005 01:12:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea5fW-0001BF-Mb; Thu, 10 Nov 2005 01:12:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10346; Thu, 10 Nov 2005 01:11:51 -0500 (EST) Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea5vb-0007ZU-M6; Thu, 10 Nov 2005 01:29:01 -0500 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IPQ00JHE6JTH300@dps.sfvic.sunlabs.com>; Wed, 09 Nov 2005 22:11:53 -0800 (PST) Received: from [10.0.1.2] ([66.199.95.96]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IPQ0037S6JBTF41@mail.sunlabs.com>; Wed, 09 Nov 2005 22:11:51 -0800 (PST) Date: Wed, 09 Nov 2005 22:11:30 -0800 From: Douglas Stebila Subject: Re: [TLS] Last Call: 'ECC Cipher Suites for TLS' to Informational RFC To: ietf@ietf.org Message-id: <3E6A7FA2-705C-4F50-8246-558D8C06DBE9@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.746.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7BIT 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I am reviewing the most recent ECC in TLS draft (draft-ietf-tls- ecc-12.txt) for its adoption in Mozilla's Netscape Security Services library, and have noted some issues that I believe should resolved before the draft is approved as an Informational RFC. 1. DES is listed as the encryption mechanism for one of the cipher suites, namely TLS_ECDH_ECDSA_WITH_DES_CBC_SHA. No other key agreement / signature combinations in the draft include the DES cipher and I recommend that this cipher suite be eliminated. The small key size of DES makes it inappropriate for use with any named elliptic curve in the draft. This would probably require renumbering the cipher suites to maintain sequential numbering, and I recommend changing the number of TLS_ECDH_ECDSA_WITH_NULL_SHA to 0xC0, 0x01 and TLS_ECDH_ECDSA_WITH_RC4_128_SHA to 0xC0, 0x02, minimizing the total number of changes required. 2. It appears that there is an error in the name of one of the cipher suites. All of the cipher suites using NULL for bulk encryption are of the form "..._WITH_NULL_SHA", but the cipher suite TLS_ECDH_anon_NULL_WITH_SHA is not named in a similar way. I recommend changing its name to TLS_ECDH_anon_WITH_NULL_SHA. Douglas > The IESG has received a request from the Transport Layer Security > WG to > consider the following document: > > - 'ECC Cipher Suites for TLS ' > as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send any comments to the > iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists by 2005-11-22. > > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-12.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 10 01:43:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea69k-0000Cj-J4; Thu, 10 Nov 2005 01:43:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ea69i-0000CY-1y; Thu, 10 Nov 2005 01:43:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11599; Thu, 10 Nov 2005 01:43:02 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ea6Pq-0008E2-Ms; Thu, 10 Nov 2005 02:00:12 -0500 Received: from S01060030bdc6ced5.cg.shawcable.net [68.147.55.50] (helo=tau.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1Ea69c2Esa-00076D; Thu, 10 Nov 2005 07:43:24 +0100 Received: by tau.local (Postfix, from userid 500) id CC7BB2F255; Wed, 9 Nov 2005 23:43:21 -0700 (MST) Date: Wed, 9 Nov 2005 23:43:21 -0700 From: Bodo Moeller To: ietf@ietf.org, tls@ietf.org Subject: Re: [TLS] Last Call: 'ECC Cipher Suites for TLS' to Informational RFC Message-ID: <20051110064321.GA17874@tau.local> References: <3E6A7FA2-705C-4F50-8246-558D8C06DBE9@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E6A7FA2-705C-4F50-8246-558D8C06DBE9@sun.com> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Douglas Stebila 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Wed, Nov 09, 2005 at 10:11:30PM -0800, Douglas Stebila wrote: >> The IESG has received a request from the Transport Layer Security WG to >> consider the following document: >> >> - 'ECC Cipher Suites for TLS ' >> as an Informational RFC > I am reviewing the most recent ECC in TLS draft (draft-ietf-tls- > ecc-12.txt) for its adoption in Mozilla's Netscape Security Services > library, and have noted some issues that I believe should resolved > before the draft is approved as an Informational RFC. > 1. DES is listed as the encryption mechanism for one of the cipher > suites, namely TLS_ECDH_ECDSA_WITH_DES_CBC_SHA. No other key > agreement / signature combinations in the draft include the DES > cipher and I recommend that this cipher suite be eliminated. The ciphersuite list in draft-ietf-tls-ecc-12.txt combines five key exchange mechanisms (i.e., key agreement / signature combinations) with different symmetric cryptographic schemes. Each group uses the same symmetric schemes -- the only exception to the pattern is this single extra ciphersuite using DES. This ciphersuite is in the current draft by oversight. It was retained for historical reasons (compatibility with initial implementations based on earlier drafts), but there is no reason any longer to keep it. Thus I intend to make the following simple change in the next revision, draft-ietf-tls-ecc-13.txt: > The > small key size of DES makes it inappropriate for use with any named > elliptic curve in the draft. This would probably require renumbering > the cipher suites to maintain sequential numbering, and I recommend > changing the number of TLS_ECDH_ECDSA_WITH_NULL_SHA to 0xC0, 0x01 and > TLS_ECDH_ECDSA_WITH_RC4_128_SHA to 0xC0, 0x02, minimizing the total > number of changes required. I.e., the lines CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x00 } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x01 } CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0xC0, 0x02 } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 } [...] will be changed into CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 } [...] > 2. It appears that there is an error in the name of one of the cipher > suites. All of the cipher suites using NULL for bulk encryption are > of the form "..._WITH_NULL_SHA", but the cipher suite > TLS_ECDH_anon_NULL_WITH_SHA is not named in a similar way. I > recommend changing its name to TLS_ECDH_anon_WITH_NULL_SHA. This typo also is historical in that it exists since draft revision -01 (there's just no excuse explaining it). I intend to change the line that reads CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0xC0, 0x15 } in draft-ietf-tls-ecc-12.txt into CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 } for the next revision, draft-ietf-tls-ecc-13.txt. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 10 08:51:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCpf-0007tU-Aw; Thu, 10 Nov 2005 08:51:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaCpd-0007tM-62; Thu, 10 Nov 2005 08:51:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04157; Thu, 10 Nov 2005 08:50:45 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaD5q-0002Wk-3u; Thu, 10 Nov 2005 09:07:59 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 785F9101819DC; Thu, 10 Nov 2005 08:50:54 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00401-94; Thu, 10 Nov 2005 08:50:53 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id EBCAD101819D6; Thu, 10 Nov 2005 08:50:52 -0500 (EST) To: ekr@rtfm.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 10 Nov 2005 08:51:37 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/10/2005 08:51:39 AM, Serialize complete at 11/10/2005 08:51:39 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ietf@ietf.org, tls@ietf.org Subject: [TLS] draft-rescorla-dtls-05.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: , Content-Type: multipart/mixed; boundary="===============2147410151==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============2147410151== Content-Type: multipart/alternative; boundary="=_alternative 004C3402852570B5_=" This is a multipart message in MIME format. --=_alternative 004C3402852570B5_= Content-Type: text/plain; charset="US-ASCII" How does DTLS handle datagrams containing application data that are lost or delivered out of order? The draft seems to indicate that only handshake messages are subject to re-transmission, timeouts, and re-ordering. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com --=_alternative 004C3402852570B5_= Content-Type: text/html; charset="US-ASCII"
How does DTLS handle datagrams containing application data that are lost or delivered out of order?
The draft seems to indicate that only handshake messages are subject to re-transmission, timeouts, and re-ordering.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com --=_alternative 004C3402852570B5_=-- --===============2147410151== 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 --===============2147410151==-- From tls-bounces@lists.ietf.org Thu Nov 10 10:17:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEAu-0007e4-5P; Thu, 10 Nov 2005 10:17:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEAs-0007dw-JI; Thu, 10 Nov 2005 10:17:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08841; Thu, 10 Nov 2005 10:16:46 -0500 (EST) Received: from pp106-67.bctel.ca ([209.52.106.67] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaER7-0004kd-J2; Thu, 10 Nov 2005 10:34:01 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 9C109B832; Thu, 10 Nov 2005 07:17:13 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Thu, 10 Nov 2005 07:17:13 -0800 In-Reply-To: (Rob Dugal's message of "Thu, 10 Nov 2005 08:51:37 -0500") Message-ID: <86wtjgfs7a.fsf@delta.rtfm.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.6 (++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ietf@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > How does DTLS handle datagrams containing application data that are lost > or delivered out of order? > The draft seems to indicate that only handshake messages are subject to > re-transmission, timeouts, and re-ordering. That's correct. The philosophy here is to provide an interface that's as much like that provided by normal datagram transport protocols as possible. Those protocols don't take care of this stuff for application data, so neither does DTLS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 11 14:09:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeGn-0003kK-EY; Fri, 11 Nov 2005 14:09:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaeGl-0003jp-HL for tls@megatron.ietf.org; Fri, 11 Nov 2005 14:09:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28499 for ; Fri, 11 Nov 2005 14:08:33 -0500 (EST) Received: from pp111-29.bctel.ca ([209.52.111.29] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaeXD-0001V8-Rp for tls@ietf.org; Fri, 11 Nov 2005 14:26:05 -0500 Received: from networkresonance.com (delta.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 333BCB861 for ; Fri, 11 Nov 2005 11:08:34 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Fri, 11 Nov 2005 11:08:34 -0800 From: Eric Rescorla Message-Id: <20051111190834.333BCB861@delta.rtfm.com> X-Spam-Score: 2.6 (++) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] New Co-Chair/TLS 1.2 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org At the meeting in Vancouver, the WG had broad consensus to start developing TLS 1.2, with the major focus being on improved hash function/MAC agility. (minutes and presentations should be available on the agenda site shortly) I will be remaining as document editor for this document and therefore we need someone else to serve as co-chair in order to declare consensus on these documents. Pasi Eronen has agreed to take up this position. Welcome, Pasi! -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 14 07:13:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdDh-0003Bi-Iw; Mon, 14 Nov 2005 07:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbdDg-0003B3-AV for tls@megatron.ietf.org; Mon, 14 Nov 2005 07:13:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16172 for ; Mon, 14 Nov 2005 07:13:25 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbdUg-0001gR-1m for tls@ietf.org; Mon, 14 Nov 2005 07:31:32 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id C7366100233E8; Mon, 14 Nov 2005 07:13:32 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22337-12; Mon, 14 Nov 2005 07:13:30 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 4F30D100233E3; Mon, 14 Nov 2005 07:13:30 -0500 (EST) In-Reply-To: <86wtjgfs7a.fsf@delta.rtfm.com> To: EKR Subject: Re: [TLS] draft-rescorla-dtls-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Mon, 14 Nov 2005 07:14:13 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/14/2005 07:14:14 AM, Serialize complete at 11/14/2005 07:14:14 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============1738395676==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1738395676== Content-Type: multipart/alternative; boundary="=_alternative 00434E36852570B9_=" This is a multipart message in MIME format. --=_alternative 00434E36852570B9_= Content-Type: text/plain; charset="US-ASCII" Another question: If only handshake messages have a message sequence number, how can the record layer determine the correct order of a ChangeCipherSpec or Alert when some records are lost? Why not add an MSN to these too, making it clear what the order of the CCS/Alert is in relation to the handshake messages? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com tls-bounces@lists.ietf.org wrote on 11/10/2005 10:17:13 AM: > Rob Dugal writes: > > How does DTLS handle datagrams containing application data that are lost > > or delivered out of order? > > The draft seems to indicate that only handshake messages are subject to > > re-transmission, timeouts, and re-ordering. > > That's correct. The philosophy here is to provide an interface that's > as much like that provided by normal datagram transport protocols as > possible. Those protocols don't take care of this stuff for application > data, so neither does DTLS. > > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 00434E36852570B9_= Content-Type: text/html; charset="US-ASCII"
Another question:

If only handshake messages have a message sequence number, how can the record layer determine the correct order of a ChangeCipherSpec or Alert
when some records are lost?  Why not add an MSN to these too, making it clear what the order of the CCS/Alert is in relation to the handshake messages?

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

tls-bounces@lists.ietf.org wrote on 11/10/2005 10:17:13 AM:

> Rob Dugal <RDugal@certicom.com> writes:
> > How does DTLS handle datagrams containing application data that are lost
> > or delivered out of order?
> > The draft seems to indicate that only handshake messages are subject to
> > re-transmission, timeouts, and re-ordering.
>
> That's correct. The philosophy here is to provide an interface that's
> as much like that provided by normal datagram transport protocols as
> possible. Those protocols don't take care of this stuff for application
> data, so neither does DTLS.
>
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 00434E36852570B9_=-- --===============1738395676== 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 --===============1738395676==-- From tls-bounces@lists.ietf.org Mon Nov 14 10:51:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebgc7-0002ql-Pi; Mon, 14 Nov 2005 10:51:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebgc5-0002qa-Nn for tls@megatron.ietf.org; Mon, 14 Nov 2005 10:51:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00677 for ; Mon, 14 Nov 2005 10:50:49 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebgt8-0000yT-2m for tls@ietf.org; Mon, 14 Nov 2005 11:08:59 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 10FA0170F1; Mon, 14 Nov 2005 07:57:27 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Mon, 14 Nov 2005 07:57:27 -0800 In-Reply-To: (Rob Dugal's message of "Mon, 14 Nov 2005 07:14:13 -0500") Message-ID: <861x1jjk7s.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls-bounces@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > Another question: > > If only handshake messages have a message sequence number, how can the > record layer determine the correct order of a ChangeCipherSpec or Alert > when some records are lost? > Why not add an MSN to these too, making it > clear what the order of the CCS/Alert is in relation to the handshake > messages? All messages have a sequence number. The handshake messages have a second sequence number to assist in reassembly. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 14 11:33:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhGm-0003Dz-0i; Mon, 14 Nov 2005 11:33:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbhGk-0003Du-80 for tls@megatron.ietf.org; Mon, 14 Nov 2005 11:33:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02938 for ; Mon, 14 Nov 2005 11:32:49 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbhXm-0002E9-MA for tls@ietf.org; Mon, 14 Nov 2005 11:51:00 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 53712100233EB; Mon, 14 Nov 2005 11:33:01 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24244-44; Mon, 14 Nov 2005 11:32:59 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id D00EF100233E3; Mon, 14 Nov 2005 11:32:59 -0500 (EST) In-Reply-To: <861x1jjk7s.fsf@romeo.rtfm.com> To: EKR Subject: Re: [TLS] draft-rescorla-dtls-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Mon, 14 Nov 2005 11:33:42 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/14/2005 11:33:44 AM, Serialize complete at 11/14/2005 11:33:44 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0821256105==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0821256105== Content-Type: multipart/alternative; boundary="=_alternative 005B0FD3852570B9_=" This is a multipart message in MIME format. --=_alternative 005B0FD3852570B9_= Content-Type: text/plain; charset="US-ASCII" Eric Rescorla wrote on 11/14/2005 10:57:27 AM: > Rob Dugal writes: > > Another question: > > > > If only handshake messages have a message sequence number, how can the > > record layer determine the correct order of a ChangeCipherSpec or Alert > > when some records are lost? > > Why not add an MSN to these too, making it > > clear what the order of the CCS/Alert is in relation to the handshake > > messages? > > All messages have a sequence number. The handshake messages have > a second sequence number to assist in reassembly. > > -Ekr Ok I understand that all records have a record sequence number and handshake messages have a message sequence number. But suppose the peer sends a number of handshake messages plus the ChangeCipherSpec, and suppose everything is lost except the ChangeCipherSpec. I know there are some lost records based on the RSNs but I don't know how many handshake messages are lost. There could be multiple messages in each record or the messages could be fragmented across multiple records so the number of lost records doesn't tell me much. It seems to me that if you included an MSN in the ChangeCipherSpec & Alerts I could tell exactly how many handshake messages are lost. This would make it easier for me to sort through the re-transmitted messages and determine exactly when I am back in sync. --=_alternative 005B0FD3852570B9_= Content-Type: text/html; charset="US-ASCII"
Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 10:57:27 AM:

> Rob Dugal <RDugal@certicom.com> writes:
> > Another question:
> >
> > If only handshake messages have a message sequence number, how can the
> > record layer determine the correct order of a ChangeCipherSpec or Alert
> > when some records are lost?
> > Why not add an MSN to these too, making it
> > clear what the order of the CCS/Alert is in relation to the handshake
> > messages?
>
> All messages have a sequence number. The handshake messages have
> a second sequence number to assist in reassembly.
>
> -Ekr

Ok I understand that all records have a record sequence number and handshake messages have a message sequence number. But suppose the peer sends a number of handshake messages plus the ChangeCipherSpec, and suppose everything is lost except the ChangeCipherSpec. I know there are some lost records based on the RSNs
but I don't know how many handshake messages are lost. There could be multiple messages in each record or the messages could be fragmented across multiple records so the number of lost records doesn't tell me much.

It seems to me that if you included an MSN in the ChangeCipherSpec & Alerts I could tell exactly how many handshake messages are lost. This would make it easier for me to sort through the re-transmitted messages and determine exactly when I am back in sync. --=_alternative 005B0FD3852570B9_=-- --===============0821256105== 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 --===============0821256105==-- From tls-bounces@lists.ietf.org Mon Nov 14 12:07:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhnm-0001k9-J9; Mon, 14 Nov 2005 12:07:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebhnk-0001k4-Na for tls@megatron.ietf.org; Mon, 14 Nov 2005 12:07:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05081 for ; Mon, 14 Nov 2005 12:06:56 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebi4n-0003OC-Ki for tls@ietf.org; Mon, 14 Nov 2005 12:25:07 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 095B817058; Mon, 14 Nov 2005 09:14:07 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Mon, 14 Nov 2005 09:14:06 -0800 In-Reply-To: (Rob Dugal's message of "Mon, 14 Nov 2005 11:33:42 -0500") Message-ID: <86ek5j9mox.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls-bounces@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > Eric Rescorla wrote on 11/14/2005 10:57:27 AM: > >> Rob Dugal writes: >> > Another question: >> > >> > If only handshake messages have a message sequence number, how can the > >> > record layer determine the correct order of a ChangeCipherSpec or > Alert >> > when some records are lost? >> > Why not add an MSN to these too, making it >> > clear what the order of the CCS/Alert is in relation to the handshake >> > messages? >> >> All messages have a sequence number. The handshake messages have >> a second sequence number to assist in reassembly. >> >> -Ekr > > Ok I understand that all records have a record sequence number and > handshake messages have a message sequence number. But suppose the peer > sends a number of handshake messages plus the ChangeCipherSpec, and > suppose everything is lost except the ChangeCipherSpec. I know there are > some lost records based on the RSNs > but I don't know how many handshake messages are lost. There could be > multiple messages in each record or the messages could be fragmented > across multiple records so the number of lost records doesn't tell me > much. Well, sort of. In general, it's unambiguous about what messages should be sent in the State Machine. However, recall that the Finished message contains the HSN as well, so you can count backwards to see if any messages were lost. And if you don't have enough information to process the CCS/Finished, then you absolutely know messages were lost. > It seems to me that if you included an MSN in the ChangeCipherSpec & > Alerts I could tell exactly how many handshake messages are lost. This > would make it easier for me to sort through the re-transmitted messages > and determine exactly when I am back in sync. Yes, this would make things a bit easier, but at the cost of substantial additional complexity, IMO. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 14 13:33:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebj9P-0000z8-Td; Mon, 14 Nov 2005 13:33:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebj9N-0000uG-2N for tls@megatron.ietf.org; Mon, 14 Nov 2005 13:33:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12075 for ; Mon, 14 Nov 2005 13:33:21 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbjQR-0006mX-QF for tls@ietf.org; Mon, 14 Nov 2005 13:51:32 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 97843100233EB; Mon, 14 Nov 2005 13:33:39 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24244-73; Mon, 14 Nov 2005 13:33:37 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 9C8FE100233E3; Mon, 14 Nov 2005 13:33:37 -0500 (EST) In-Reply-To: <86ek5j9mox.fsf@romeo.rtfm.com> To: EKR Subject: Re: [TLS] draft-rescorla-dtls-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Mon, 14 Nov 2005 13:34:20 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/14/2005 01:34:21 PM, Serialize complete at 11/14/2005 01:34:21 PM X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0974680745==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0974680745== Content-Type: multipart/alternative; boundary="=_alternative 00661B5C852570B9_=" This is a multipart message in MIME format. --=_alternative 00661B5C852570B9_= Content-Type: text/plain; charset="US-ASCII" Eric Rescorla wrote on 11/14/2005 12:14:06 PM: > Rob Dugal writes: > > > Eric Rescorla wrote on 11/14/2005 10:57:27 AM: > > > >> Rob Dugal writes: > >> > Another question: > >> > > >> > If only handshake messages have a message sequence number, how can the > > > >> > record layer determine the correct order of a ChangeCipherSpec or > > Alert > >> > when some records are lost? > >> > Why not add an MSN to these too, making it > >> > clear what the order of the CCS/Alert is in relation to the handshake > >> > messages? > >> > >> All messages have a sequence number. The handshake messages have > >> a second sequence number to assist in reassembly. > >> > >> -Ekr > > > > Ok I understand that all records have a record sequence number and > > handshake messages have a message sequence number. But suppose the peer > > sends a number of handshake messages plus the ChangeCipherSpec, and > > suppose everything is lost except the ChangeCipherSpec. I know there are > > some lost records based on the RSNs > > but I don't know how many handshake messages are lost. There could be > > multiple messages in each record or the messages could be fragmented > > across multiple records so the number of lost records doesn't tell me > > much. > > Well, sort of. In general, it's unambiguous about what messages should > be sent in the State Machine. That's not always true. I recently looked at the salowey extension for resuming with a session ticket. It is impossible to know if the server is resuming until you receive the ChangeCipherSpec message. And the server could decide to resume but issue a new session ticket which you won't know until you receive the ticket. I don't know if anyone will wish to use this extension with DTLS but the way you wrote the draft implies (to me) that DTLS should support any of the extensions supported by TLS. > However, recall that the Finished > message contains the HSN as well, so you can count backwards to see if > any messages were lost. And if you don't have enough information to > process the CCS/Finished, then you absolutely know messages were lost. > > > > It seems to me that if you included an MSN in the ChangeCipherSpec & > > Alerts I could tell exactly how many handshake messages are lost. This > > would make it easier for me to sort through the re-transmitted messages > > and determine exactly when I am back in sync. > > Yes, this would make things a bit easier, but at the cost of substantial > additional complexity, IMO. > > -Ekr Why would you say this would add substantial complexity? You already have to handle the MSN with handshake messages so adding it to CCS/Alert shouldn't add much. And it will substantially simplify the task of determining when messages are lost and how to figure out the order of a CCS/Alert when you receive re-transmitted messages. --=_alternative 00661B5C852570B9_= Content-Type: text/html; charset="US-ASCII"
Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 12:14:06 PM:

> Rob Dugal <RDugal@certicom.com> writes:
>
> > Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 10:57:27 AM:
> >
> >> Rob Dugal <RDugal@certicom.com> writes:
> >> > Another question:
> >> >
> >> > If only handshake messages have a message sequence number, how can the
> >
> >> > record layer determine the correct order of a ChangeCipherSpec or
> > Alert
> >> > when some records are lost?
> >> > Why not add an MSN to these too, making it
> >> > clear what the order of the CCS/Alert is in relation to the handshake
> >> > messages?
> >>
> >> All messages have a sequence number. The handshake messages have
> >> a second sequence number to assist in reassembly.
> >>
> >> -Ekr
> >
> > Ok I understand that all records have a record sequence number and
> > handshake messages have a message sequence number. But suppose the peer
> > sends a number of handshake messages plus the ChangeCipherSpec, and
> > suppose everything is lost except the ChangeCipherSpec. I know there are
> > some lost records based on the RSNs
> > but I don't know how many handshake messages are lost. There could be
> > multiple messages in each record or the messages could be fragmented
> > across multiple records so the number of lost records doesn't tell me
> > much.
>
> Well, sort of. In general, it's unambiguous about what messages should
> be sent in the State Machine.

That's not always true. I recently looked at the salowey extension for resuming with a session ticket. It is impossible to know if the server is resuming until you receive the ChangeCipherSpec message. And the server could decide to resume but issue a new session ticket which you won't know until you receive the ticket.
I don't know if anyone will wish to use this extension with DTLS but the way you wrote the draft implies (to me) that DTLS should support any of the extensions supported by TLS.

> However, recall that the Finished
> message contains the HSN as well, so you can count backwards to see if
> any messages were lost.  And if you don't have enough information to
> process the CCS/Finished, then you absolutely know messages were lost.
>
>
> > It seems to me that if you included an MSN in the ChangeCipherSpec &
> > Alerts I could tell exactly how many handshake messages are lost. This
> > would make it easier for me to sort through the re-transmitted messages
> > and determine exactly when I am back in sync.
>
> Yes, this would make things a bit easier, but at the cost of substantial
> additional complexity, IMO.
>
> -Ekr

Why would you say this would add substantial complexity?
You already have to handle the MSN with handshake messages so adding it to CCS/Alert shouldn't add much.
And it will substantially simplify the task of determining when messages are lost and how to figure out the order of a CCS/Alert when you receive re-transmitted messages.


--=_alternative 00661B5C852570B9_=-- --===============0974680745== 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 --===============0974680745==-- From tls-bounces@lists.ietf.org Mon Nov 14 14:21:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebjt1-0004kB-2u; Mon, 14 Nov 2005 14:21:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebjsy-0004ij-VZ for tls@megatron.ietf.org; Mon, 14 Nov 2005 14:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15571 for ; Mon, 14 Nov 2005 14:20:26 -0500 (EST) Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EbkA0-00008i-5G for tls@ietf.org; Mon, 14 Nov 2005 14:38:37 -0500 Received: from theory.stanford.edu ([171.64.78.10]) by agp.stanford.edu with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.43) id 1Ebjsh-0004YP-6L for tls@ietf.org; Mon, 14 Nov 2005 11:20:43 -0800 Received: from mail by theory.Stanford.EDU with spam-scanned (Exim 4.30) id 1Ebjsg-0004tI-9z for tls@ietf.org; Mon, 14 Nov 2005 11:20:43 -0800 Received: from cipher.stanford.edu ([171.64.78.146]) by theory.Stanford.EDU with esmtp (TLSv1:AES256-SHA:256) (Exim 4.30) id 1Ebjsc-0004sn-9L; Mon, 14 Nov 2005 11:20:38 -0800 Received: from cipher.Stanford.EDU (localhost.localdomain [127.0.0.1]) by cipher.Stanford.EDU (8.13.4/8.12.11) with ESMTP id jAEJKcUa021526; Mon, 14 Nov 2005 11:20:38 -0800 Received: (from nagendra@localhost) by cipher.Stanford.EDU (8.13.4/8.13.4/Submit) id jAEJKcVb021525; Mon, 14 Nov 2005 11:20:38 -0800 X-Authentication-Warning: cipher.Stanford.EDU: nagendra set sender to nagendra@cs.stanford.edu using -f Date: Mon, 14 Nov 2005 11:20:38 -0800 From: nagendra modadugu To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt Message-ID: <20051114192037.GA20817@cs.stanford.edu> References: <861x1jjk7s.fsf@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-3.Stanford.EDU X-Spam-Status: No, score=-104.9 required=7.0 tests=BAYES_00, USER_IN_WHITELIST autolearn=no version=3.0.4-cs-csdcf X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls-bounces@ietf.org, 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org * Rob Dugal [2005-11-14 11:33:42 -0500]: > Ok I understand that all records have a record sequence number and > handshake messages have a message sequence number. But suppose the peer > sends a number of handshake messages plus the ChangeCipherSpec, and > suppose everything is lost except the ChangeCipherSpec. I know there are > some lost records based on the RSNs > but I don't know how many handshake messages are lost. There could be > multiple messages in each record or the messages could be fragmented > across multiple records so the number of lost records doesn't tell me > much. Actually you can tell -- there are only two possible scenarios for the situation you describe: (1) Client receives ChangeCipherSpec. This implies that there were no missing handshake messages: ChangeCipherSpec is the first message from Flight 6 (page 16 of the draft.) (2) Server receives ChangeCipherSpec. No more than three handshake messages could be missing: Certificate, ClientKeyExchange, and CertificateVerify. The server cannot proceed if necessary messages are missing, and the usual retransmission strategy is employed. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 14 20:44:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebps5-0004Yq-2P; Mon, 14 Nov 2005 20:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebps3-0004Ye-Ma; Mon, 14 Nov 2005 20:44:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19734; Mon, 14 Nov 2005 20:43:55 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ebq9B-0008P9-Ei; Mon, 14 Nov 2005 21:02:10 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F09931E8CD4; Mon, 14 Nov 2005 17:44:05 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Mon, 14 Nov 2005 17:44:05 -0800 In-Reply-To: (Rob Dugal's message of "Mon, 14 Nov 2005 13:34:20 -0500") Message-ID: <86veyuwuqi.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls-bounces@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > Eric Rescorla wrote on 11/14/2005 12:14:06 PM: > >> Rob Dugal writes: >> >> > Eric Rescorla wrote on 11/14/2005 10:57:27 AM: >> > >> >> Rob Dugal writes: >> >> > Another question: >> >> > >> >> > If only handshake messages have a message sequence number, how can > the >> > >> >> > record layer determine the correct order of a ChangeCipherSpec or >> > Alert >> >> > when some records are lost? >> >> > Why not add an MSN to these too, making it >> >> > clear what the order of the CCS/Alert is in relation to the > handshake >> >> > messages? >> >> >> >> All messages have a sequence number. The handshake messages have >> >> a second sequence number to assist in reassembly. >> >> >> >> -Ekr >> > >> > Ok I understand that all records have a record sequence number and >> > handshake messages have a message sequence number. But suppose the > peer >> > sends a number of handshake messages plus the ChangeCipherSpec, and >> > suppose everything is lost except the ChangeCipherSpec. I know there > are >> > some lost records based on the RSNs >> > but I don't know how many handshake messages are lost. There could be >> > multiple messages in each record or the messages could be fragmented >> > across multiple records so the number of lost records doesn't tell me >> > much. >> >> Well, sort of. In general, it's unambiguous about what messages should >> be sent in the State Machine. > > That's not always true. I recently looked at the salowey extension for > resuming with a session ticket. It is impossible to know if the server is > resuming until you receive the ChangeCipherSpec message. And the server > could decide to resume but issue a new session ticket which you won't know > until you receive the ticket. > I don't know if anyone will wish to use this extension with DTLS but the > way you wrote the draft implies (to me) that DTLS should support any of > the extensions supported by TLS. I agree that this is a valuable goal, but I don't agree with your interpretation of the ticket spec. You absolutely know that you need to receive *some* message after the ServerHello, so until you get that the CSS is of no value to you. And once you get that message, it's either a Certificate, SKE, or a SessionTicket, and you know how many messages you need to receive--or rather what the last message of the flight will be. Why is this problematic? And as noted previously, you can always tell what's up when you see the Finished message, since you need to see all the messages in order to compute the Finished.verify. > Why would you say this would add substantial complexity? > You already have to handle the MSN with handshake messages so adding it to > CCS/Alert shouldn't add much. It's a matter of layer clarity. CCS isn't part of the handshake layer (IMO a bad design choice, but it's the one we have) and neither is the Alert protocol. I don't want to mix the layers. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 16 09:20:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO9F-0007St-FI; Wed, 16 Nov 2005 09:20:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcO9E-0007Qa-Bv for tls@megatron.ietf.org; Wed, 16 Nov 2005 09:20:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29134 for ; Wed, 16 Nov 2005 09:19:55 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOQe-0001Vg-BF for tls@ietf.org; Wed, 16 Nov 2005 09:38:30 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAGEHP2l031224 for ; Wed, 16 Nov 2005 16:17:32 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 16:20:20 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 16:20:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2005 16:20:21 +0200 Message-ID: Thread-Topic: TLS numbers Thread-Index: AcXquOBsW6ux3RAfRCaqkcSWZV8HkQ== To: X-OriginalArrivalTime: 16 Nov 2005 14:20:20.0302 (UTC) FILETIME=[E001BEE0:01C5EAB8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: Subject: [TLS] TLS numbers 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi everyone, I've received a couple of corrections to the unofficial list of TLS numbers, and I've now posted an updated version: http://people.nokia.net/~pasi/tls-numbers.txt Note that now the official IANA registries have been created,=20 the past practice of "grabbing numbers" is no longer appropriate.=20 New drafts should just use TBD-BY-IANA instead of picking numbers,=20 and old drafts should be updated to contain a proper IANA considerations section. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 16 09:23:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOC0-0008EX-7R; Wed, 16 Nov 2005 09:23:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcOBx-0008Dr-Ei; Wed, 16 Nov 2005 09:23:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29428; Wed, 16 Nov 2005 09:22:44 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcOTP-0001c2-0z; Wed, 16 Nov 2005 09:41:19 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 700B41006B084; Wed, 16 Nov 2005 09:22:59 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23166-54; Wed, 16 Nov 2005 09:22:57 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id B853D1006B082; Wed, 16 Nov 2005 09:22:57 -0500 (EST) In-Reply-To: <86veyuwuqi.fsf@raman.networkresonance.com> To: EKR Subject: Re: [TLS] draft-rescorla-dtls-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Wed, 16 Nov 2005 09:23:39 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/16/2005 09:23:40 AM, Serialize complete at 11/16/2005 09:23:40 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: f460acdc4aacf7fc5e6f9bd32f8fd8c6 Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0689600062==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0689600062== Content-Type: multipart/alternative; boundary="=_alternative 004F28C8852570BB_=" This is a multipart message in MIME format. --=_alternative 004F28C8852570BB_= Content-Type: text/plain; charset="US-ASCII" tls-bounces@lists.ietf.org wrote on 11/14/2005 08:44:05 PM: > Rob Dugal writes: > > > Eric Rescorla wrote on 11/14/2005 12:14:06 PM: > > > >> Rob Dugal writes: > >> > >> > Eric Rescorla wrote on 11/14/2005 10:57:27 AM: > >> > > >> >> Rob Dugal writes: > >> >> > Another question: > >> >> > > >> >> > If only handshake messages have a message sequence number, how can > > the > >> > > >> >> > record layer determine the correct order of a ChangeCipherSpec or > >> > Alert > >> >> > when some records are lost? > >> >> > Why not add an MSN to these too, making it > >> >> > clear what the order of the CCS/Alert is in relation to the > > handshake > >> >> > messages? > >> >> > >> >> All messages have a sequence number. The handshake messages have > >> >> a second sequence number to assist in reassembly. > >> >> > >> >> -Ekr > >> > > >> > Ok I understand that all records have a record sequence number and > >> > handshake messages have a message sequence number. But suppose the > > peer > >> > sends a number of handshake messages plus the ChangeCipherSpec, and > >> > suppose everything is lost except the ChangeCipherSpec. I know there > > are > >> > some lost records based on the RSNs > >> > but I don't know how many handshake messages are lost. There could be > >> > multiple messages in each record or the messages could be fragmented > >> > across multiple records so the number of lost records doesn't tell me > >> > much. > >> > >> Well, sort of. In general, it's unambiguous about what messages should > >> be sent in the State Machine. > > > > That's not always true. I recently looked at the salowey extension for > > resuming with a session ticket. It is impossible to know if the server is > > resuming until you receive the ChangeCipherSpec message. And the server > > could decide to resume but issue a new session ticket which you won't know > > until you receive the ticket. > > I don't know if anyone will wish to use this extension with DTLS but the > > way you wrote the draft implies (to me) that DTLS should support any of > > the extensions supported by TLS. > > I agree that this is a valuable goal, but I don't agree with your > interpretation of the ticket spec. You absolutely know that you need > to receive *some* message after the ServerHello, so until you get that > the CSS is of no value to you. And once you get that message, it's either > a Certificate, SKE, or a SessionTicket, and you know how many messages > you need to receive--or rather what the last message of the flight will > be. Why is this problematic? When resuming, draft-salowey-tls-ticket-05.txt says that the server may issue an optional SessionTicket after the ServerHello. So there are 2 possabilities: (A) ClientHello (SessionTicket extension) --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data (B) ClientHello (SessionTicket extension) --------> ServerHello SessionTicket [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data Suppose the server does case (B). Assume the MTU is large enough that the ServerHello and SessionTicket fit into a single record. So the Server transmits 3 records: ServerHello+SessionTicket, CCS, Finished. Suppose the client only receives CCS and Finished records. It will know there is a lost record by the RSN but it doesn't know that record has 2 handshake messages. Now suppose the server retransmits the ServerHello, CCS, and Finished messages. Just to make things a little complex suppose the server uses a much smaller MTU estimate, fragmenting the ServerHello into 2 records and fragmenting the SessionTicket into 2 records. Now suppose the client receives only the 2 records containing the ServerHello. The RSNs indicate to the client that records were lost but tells nothing about how many messages. How does the client know that there is still a missing SessionTicket message? It cannot look at the MSN in the Finished message because the message is encrypted. It cannot rely on the RSNs to tell how many messages should have been received. It has received a ServerHello, CCS, and Finished message which looks like it could be the message flights from case (A). If the record layer were to pass only these 3 messages to the handshake layer the handshake will fail because the message hashes won't be correct. Am I missing something? On the other hand if the CCS had an MSN I would immediately know exactly 1 handshake message is missing. > And as noted previously, you can always tell what's up when you > see the Finished message, since you need to see all the messages > in order to compute the Finished.verify. The Finished message is encrypted so I cannot look at the MSN until the handshake layer has received the ChangeCipherSpec. The record layer will not deliver the CCS to the handshake layer until it has determined that it has received the entire flight of messages. So I don't see how the Finished message can tell me if I have received the entire flight of messages. > > > > Why would you say this would add substantial complexity? > > You already have to handle the MSN with handshake messages so adding it to > > CCS/Alert shouldn't add much. > > It's a matter of layer clarity. CCS isn't part of the handshake layer > (IMO a bad design choice, but it's the one we have) and neither is the > Alert protocol. I don't want to mix the layers. > > -Ekr > > > > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 004F28C8852570BB_= Content-Type: text/html; charset="US-ASCII"
tls-bounces@lists.ietf.org wrote on 11/14/2005 08:44:05 PM:

> Rob Dugal <RDugal@certicom.com> writes:
>
> > Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 12:14:06 PM:
> >
> >> Rob Dugal <RDugal@certicom.com> writes:
> >>
> >> > Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 10:57:27 AM:
> >> >
> >> >> Rob Dugal <RDugal@certicom.com> writes:
> >> >> > Another question:
> >> >> >
> >> >> > If only handshake messages have a message sequence number, how can
> > the
> >> >
> >> >> > record layer determine the correct order of a ChangeCipherSpec or
> >> > Alert
> >> >> > when some records are lost?
> >> >> > Why not add an MSN to these too, making it
> >> >> > clear what the order of the CCS/Alert is in relation to the
> > handshake
> >> >> > messages?
> >> >>
> >> >> All messages have a sequence number. The handshake messages have
> >> >> a second sequence number to assist in reassembly.
> >> >>
> >> >> -Ekr
> >> >
> >> > Ok I understand that all records have a record sequence number and
> >> > handshake messages have a message sequence number. But suppose the
> > peer
> >> > sends a number of handshake messages plus the ChangeCipherSpec, and
> >> > suppose everything is lost except the ChangeCipherSpec. I know there
> > are
> >> > some lost records based on the RSNs
> >> > but I don't know how many handshake messages are lost. There could be
> >> > multiple messages in each record or the messages could be fragmented
> >> > across multiple records so the number of lost records doesn't tell me
> >> > much.
> >>
> >> Well, sort of. In general, it's unambiguous about what messages should
> >> be sent in the State Machine.
> >
> > That's not always true. I recently looked at the salowey extension for
> > resuming with a session ticket. It is impossible to know if the server is
> > resuming until you receive the ChangeCipherSpec message. And the server
> > could decide to resume but issue a new session ticket which you won't know
> > until you receive the ticket.
> > I don't know if anyone will wish to use this extension with DTLS but the
> > way you wrote the draft implies (to me) that DTLS should support any of
> > the extensions supported by TLS.
>
> I agree that this is a valuable goal, but I don't agree with your
> interpretation of the ticket spec. You absolutely know that you need
> to receive *some* message after the ServerHello, so until you get that
> the CSS is of no value to you. And once you get that message, it's either
> a Certificate, SKE, or a SessionTicket, and you know how many messages
> you need to receive--or rather what the last message of the flight will
> be. Why is this problematic?

When resuming, draft-salowey-tls-ticket-05.txt says that the server may issue an optional
SessionTicket after the ServerHello. So there are 2 possabilities:

(A)
         ClientHello
        (SessionTicket extension)      -------->
                                                         ServerHello
                                                  [ChangeCipherSpec]
                                      <--------             Finished
        [ChangeCipherSpec]
        Finished                      -------->
        Application Data              <------->     Application Data

(B)
         ClientHello
        (SessionTicket extension)      -------->
                                                         ServerHello
                                                       SessionTicket
                                                  [ChangeCipherSpec]
                                      <--------             Finished
        [ChangeCipherSpec]
        Finished                      -------->
        Application Data              <------->     Application Data

Suppose the server does case (B). Assume the MTU is large enough that the ServerHello and SessionTicket fit into a single record. So the Server transmits 3 records: ServerHello+SessionTicket, CCS, Finished.
Suppose the client only receives CCS and Finished records. It will know there is a lost record by the RSN but it doesn't know that record has 2 handshake messages. Now suppose the server retransmits the ServerHello, CCS, and Finished messages. Just to make things a little complex suppose the server uses a much smaller MTU estimate, fragmenting the ServerHello into 2 records and fragmenting the SessionTicket into 2 records. Now suppose the client receives only the 2 records containing the ServerHello. The RSNs indicate to the client that records were lost but tells nothing about how many messages.
How does the client know that there is still a missing SessionTicket message?
It cannot look at the MSN in the Finished message because the message is encrypted.
It cannot rely on the RSNs to tell how many messages should have been received.
It has received a ServerHello, CCS, and Finished message which looks like it could be the message flights from case (A). If the record layer were to pass only these 3 messages to the handshake layer the handshake will fail because the message hashes won't be correct.

Am I missing something?
On the other hand if the CCS had an MSN I would immediately know exactly 1 handshake message is missing.





 
> And as noted previously, you can always tell what's up when you
> see the Finished message, since you need to see all the messages
> in order to compute the Finished.verify.

The Finished message is encrypted so I cannot look at the MSN until the handshake layer has received the ChangeCipherSpec. The record layer will not deliver the CCS to the handshake layer until it has determined that it has received the entire flight of messages. So I don't see how the Finished message can tell me if I have received the entire flight of messages.

>
>
> > Why would you say this would add substantial complexity?
> > You already have to handle the MSN with handshake messages so adding it to
> > CCS/Alert shouldn't add much.
>
> It's a matter of layer clarity. CCS isn't part of the handshake layer
> (IMO a bad design choice, but it's the one we have) and neither is the
> Alert protocol. I don't want to mix the layers.
>
> -Ekr
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 004F28C8852570BB_=-- --===============0689600062== 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 --===============0689600062==-- From tls-bounces@lists.ietf.org Wed Nov 16 10:49:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPXN-0006nL-Jy; Wed, 16 Nov 2005 10:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcPXL-0006nB-Tx; Wed, 16 Nov 2005 10:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04539; Wed, 16 Nov 2005 10:48:54 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcPon-0005kc-PG; Wed, 16 Nov 2005 11:07:31 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 1BB2A17058; Wed, 16 Nov 2005 07:55:58 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Wed, 16 Nov 2005 07:55:58 -0800 In-Reply-To: (Rob Dugal's message of "Wed, 16 Nov 2005 09:23:39 -0500") Message-ID: <86zmo48u41.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: tls-bounces@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > tls-bounces@lists.ietf.org wrote on 11/14/2005 08:44:05 PM: > >> Rob Dugal writes: >> >> > Eric Rescorla wrote on 11/14/2005 12:14:06 PM: >> > >> >> Rob Dugal writes: >> >> >> >> > Eric Rescorla wrote on 11/14/2005 10:57:27 AM: >> >> > >> >> >> Rob Dugal writes: >> >> >> > Another question: >> >> >> > >> >> >> > If only handshake messages have a message sequence number, how > can >> > the >> >> > >> >> >> > record layer determine the correct order of a ChangeCipherSpec > or >> >> > Alert >> >> >> > when some records are lost? >> >> >> > Why not add an MSN to these too, making it >> >> >> > clear what the order of the CCS/Alert is in relation to the >> > handshake >> >> >> > messages? >> >> >> >> >> >> All messages have a sequence number. The handshake messages have >> >> >> a second sequence number to assist in reassembly. >> >> >> >> >> >> -Ekr >> >> > >> >> > Ok I understand that all records have a record sequence number and >> >> > handshake messages have a message sequence number. But suppose the >> > peer >> >> > sends a number of handshake messages plus the ChangeCipherSpec, and > >> >> > suppose everything is lost except the ChangeCipherSpec. I know > there >> > are >> >> > some lost records based on the RSNs >> >> > but I don't know how many handshake messages are lost. There could > be >> >> > multiple messages in each record or the messages could be > fragmented >> >> > across multiple records so the number of lost records doesn't tell > me >> >> > much. >> >> >> >> Well, sort of. In general, it's unambiguous about what messages > should >> >> be sent in the State Machine. >> > >> > That's not always true. I recently looked at the salowey extension for > >> > resuming with a session ticket. It is impossible to know if the server > is >> > resuming until you receive the ChangeCipherSpec message. And the > server >> > could decide to resume but issue a new session ticket which you won't > know >> > until you receive the ticket. >> > I don't know if anyone will wish to use this extension with DTLS but > the >> > way you wrote the draft implies (to me) that DTLS should support any > of >> > the extensions supported by TLS. >> >> I agree that this is a valuable goal, but I don't agree with your >> interpretation of the ticket spec. You absolutely know that you need >> to receive *some* message after the ServerHello, so until you get that >> the CSS is of no value to you. And once you get that message, it's > either >> a Certificate, SKE, or a SessionTicket, and you know how many messages >> you need to receive--or rather what the last message of the flight will >> be. Why is this problematic? > > When resuming, draft-salowey-tls-ticket-05.txt says that the server may > issue an optional > SessionTicket after the ServerHello. So there are 2 possabilities: > > (A) > ClientHello > (SessionTicket extension) --------> > ServerHello > [ChangeCipherSpec] > <-------- Finished > [ChangeCipherSpec] > Finished --------> > Application Data <-------> Application Data > > > (B) > ClientHello > (SessionTicket extension) --------> > ServerHello > SessionTicket > [ChangeCipherSpec] > <-------- Finished > [ChangeCipherSpec] > Finished --------> > Application Data <-------> Application Data I don't read this the same way as you do. The way I read it is that the SessionTicket is the signal that the server wishes to resume. If it's not sent, the server does a full handshake. > >> And as noted previously, you can always tell what's up when you >> see the Finished message, since you need to see all the messages >> in order to compute the Finished.verify. > > The Finished message is encrypted so I cannot look at the MSN until the > handshake layer has received the ChangeCipherSpec. The record layer will > not deliver the CCS to the handshake layer until it has determined that it > has received the entire flight of messages. So I don't see how the > Finished message can tell me if I have received the entire flight of > messages. I think you're thinking at the wrong layer here. The handshake layer is responsible for reliability here. And it *does* get the CCS and the Finished and (even in your interpretation of -ticket) is able to decrypt them and can then determine whether things were in order. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 16 15:11:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTcV-0001kf-41; Wed, 16 Nov 2005 15:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcTcS-0001kX-5L; Wed, 16 Nov 2005 15:11:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20948; Wed, 16 Nov 2005 15:10:27 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcTtw-0006tw-Kx; Wed, 16 Nov 2005 15:29:05 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id F3AB91006B084; Wed, 16 Nov 2005 15:10:43 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27106-92; Wed, 16 Nov 2005 15:10:42 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 3451D1006B07A; Wed, 16 Nov 2005 15:10:42 -0500 (EST) In-Reply-To: <86zmo48u41.fsf@romeo.rtfm.com> To: EKR Subject: Re: [TLS] draft-rescorla-dtls-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Wed, 16 Nov 2005 15:11:23 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/16/2005 03:11:24 PM, Serialize complete at 11/16/2005 03:11:24 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: 231d7929942febf3be8fd5be2903302f Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0909937147==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0909937147== Content-Type: multipart/alternative; boundary="=_alternative 006EFEBF852570BB_=" This is a multipart message in MIME format. --=_alternative 006EFEBF852570BB_= Content-Type: text/plain; charset="US-ASCII" Eric Rescorla wrote on 11/16/2005 10:55:58 AM: > Rob Dugal writes: > > tls-bounces@lists.ietf.org wrote on 11/14/2005 08:44:05 PM: > > > >> Rob Dugal writes: > >> > >> > Eric Rescorla wrote on 11/14/2005 12:14:06 PM: > >> > > >> >> Rob Dugal writes: > >> >> > >> >> > Eric Rescorla wrote on 11/14/2005 10:57:27 AM: > >> >> > > >> >> >> Rob Dugal writes: > >> >> >> > Another question: > >> >> >> > > >> >> >> > If only handshake messages have a message sequence number, how > > can > >> > the > >> >> > > >> >> >> > record layer determine the correct order of a ChangeCipherSpec > > or > >> >> > Alert > >> >> >> > when some records are lost? > >> >> >> > Why not add an MSN to these too, making it > >> >> >> > clear what the order of the CCS/Alert is in relation to the > >> > handshake > >> >> >> > messages? > >> >> >> > >> >> >> All messages have a sequence number. The handshake messages have > >> >> >> a second sequence number to assist in reassembly. > >> >> >> > >> >> >> -Ekr > >> >> > > >> >> > Ok I understand that all records have a record sequence number and > >> >> > handshake messages have a message sequence number. But suppose the > >> > peer > >> >> > sends a number of handshake messages plus the ChangeCipherSpec, and > > > >> >> > suppose everything is lost except the ChangeCipherSpec. I know > > there > >> > are > >> >> > some lost records based on the RSNs > >> >> > but I don't know how many handshake messages are lost. There could > > be > >> >> > multiple messages in each record or the messages could be > > fragmented > >> >> > across multiple records so the number of lost records doesn't tell > > me > >> >> > much. > >> >> > >> >> Well, sort of. In general, it's unambiguous about what messages > > should > >> >> be sent in the State Machine. > >> > > >> > That's not always true. I recently looked at the salowey extension for > > > >> > resuming with a session ticket. It is impossible to know if the server > > is > >> > resuming until you receive the ChangeCipherSpec message. And the > > server > >> > could decide to resume but issue a new session ticket which you won't > > know > >> > until you receive the ticket. > >> > I don't know if anyone will wish to use this extension with DTLS but > > the > >> > way you wrote the draft implies (to me) that DTLS should support any > > of > >> > the extensions supported by TLS. > >> > >> I agree that this is a valuable goal, but I don't agree with your > >> interpretation of the ticket spec. You absolutely know that you need > >> to receive *some* message after the ServerHello, so until you get that > >> the CSS is of no value to you. And once you get that message, it's > > either > >> a Certificate, SKE, or a SessionTicket, and you know how many messages > >> you need to receive--or rather what the last message of the flight will > >> be. Why is this problematic? > > > > When resuming, draft-salowey-tls-ticket-05.txt says that the server may > > issue an optional > > SessionTicket after the ServerHello. So there are 2 possabilities: > > > > (A) > > ClientHello > > (SessionTicket extension) --------> > > ServerHello > > [ChangeCipherSpec] > > <-------- Finished > > [ChangeCipherSpec] > > Finished --------> > > Application Data <-------> Application Data > > > > > > (B) > > ClientHello > > (SessionTicket extension) --------> > > ServerHello > > SessionTicket > > [ChangeCipherSpec] > > <-------- Finished > > [ChangeCipherSpec] > > Finished --------> > > Application Data <-------> Application Data > > I don't read this the same way as you do. The way I read it is that the > SessionTicket is the signal that the server wishes to resume. If it's > not sent, the server does a full handshake. We will have to get Joe Salowey to clarify this because he also states: "If the server successfully verifies the client's ticket then it may renew the ticket by including a SessionTicket handshake message after the ServerHello." To me "may renew the ticket" implies that the SessionTicket is optional but that resumption can still take place. > > > >> And as noted previously, you can always tell what's up when you > >> see the Finished message, since you need to see all the messages > >> in order to compute the Finished.verify. > > > > The Finished message is encrypted so I cannot look at the MSN until the > > handshake layer has received the ChangeCipherSpec. The record layer will > > not deliver the CCS to the handshake layer until it has determined that it > > has received the entire flight of messages. So I don't see how the > > Finished message can tell me if I have received the entire flight of > > messages. > > I think you're thinking at the wrong layer here. The handshake layer > is responsible for reliability here. And it *does* get the CCS and > the Finished and (even in your interpretation of -ticket) is able > to decrypt them and can then determine whether things were in order. Did you mean to say the record layer is responsible for reliability? I think the record layer is responsible for ensuring that messages are transmitted and received reliably. Reliably means messages should be received by the handshake layer in the order of the original flight of messages sent by the peer. My problem with the DTLS design deals with determining how to exit a waiting state as defined in point #3 of section 4.2.4 3. The implementation receives the next flight of messages: if this is the final flight of messages the implementation transitions to FINISHED. If the implementation needs to send a new flight, it transitions to the PREPARING state. Partial reads (whether partial messages or only some of the messages in the flight) do not cause state transitions or timer resets. Determing when you have received the complete next flight of messages is not trivial unless there were no loss of records. If some records were lost then the record layer must determine when it has the complete flight of messages through examining the contents of the messages themselves and by having some understanding of what messages are expected. If I examine the ServerHello for a session id I will know whether the server is resuming and exactly how many messages to receive. If I look at the ciphersuite in the ServerHello I can tell if there will be a server key exchange message. If the client sent a certificate I can determine if a CertificateVerify message is expected. etc. I think SessionTicket is still a problem but let's wait for Joe Salowey to clear up the ambiguity in his draft. To me this does not seem to be an ideal design for the record layer. I suggested adding an MSN to the ChangeCipherSpec message because I think it would make it clear how many handshake messages appear before the ChangeCipherSpec and would make it simpler for the record layer to determine when it has received the complete set of messages belonging to the next flight. --=_alternative 006EFEBF852570BB_= Content-Type: text/html; charset="US-ASCII"
Eric Rescorla <ekr@rtfm.com> wrote on 11/16/2005 10:55:58 AM:

> Rob Dugal <RDugal@certicom.com> writes:
> > tls-bounces@lists.ietf.org wrote on 11/14/2005 08:44:05 PM:
> >
> >> Rob Dugal <RDugal@certicom.com> writes:
> >>
> >> > Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 12:14:06 PM:
> >> >
> >> >> Rob Dugal <RDugal@certicom.com> writes:
> >> >>
> >> >> > Eric Rescorla <ekr@rtfm.com> wrote on 11/14/2005 10:57:27 AM:
> >> >> >
> >> >> >> Rob Dugal <RDugal@certicom.com> writes:
> >> >> >> > Another question:
> >> >> >> >
> >> >> >> > If only handshake messages have a message sequence number, how
> > can
> >> > the
> >> >> >
> >> >> >> > record layer determine the correct order of a ChangeCipherSpec
> > or
> >> >> > Alert
> >> >> >> > when some records are lost?
> >> >> >> > Why not add an MSN to these too, making it
> >> >> >> > clear what the order of the CCS/Alert is in relation to the
> >> > handshake
> >> >> >> > messages?
> >> >> >>
> >> >> >> All messages have a sequence number. The handshake messages have
> >> >> >> a second sequence number to assist in reassembly.
> >> >> >>
> >> >> >> -Ekr
> >> >> >
> >> >> > Ok I understand that all records have a record sequence number and
> >> >> > handshake messages have a message sequence number. But suppose the
> >> > peer
> >> >> > sends a number of handshake messages plus the ChangeCipherSpec, and
> >
> >> >> > suppose everything is lost except the ChangeCipherSpec. I know
> > there
> >> > are
> >> >> > some lost records based on the RSNs
> >> >> > but I don't know how many handshake messages are lost. There could
> > be
> >> >> > multiple messages in each record or the messages could be
> > fragmented
> >> >> > across multiple records so the number of lost records doesn't tell
> > me
> >> >> > much.
> >> >>
> >> >> Well, sort of. In general, it's unambiguous about what messages
> > should
> >> >> be sent in the State Machine.
> >> >
> >> > That's not always true. I recently looked at the salowey extension for
> >
> >> > resuming with a session ticket. It is impossible to know if the server
> > is
> >> > resuming until you receive the ChangeCipherSpec message. And the
> > server
> >> > could decide to resume but issue a new session ticket which you won't
> > know
> >> > until you receive the ticket.
> >> > I don't know if anyone will wish to use this extension with DTLS but
> > the
> >> > way you wrote the draft implies (to me) that DTLS should support any
> > of
> >> > the extensions supported by TLS.
> >>
> >> I agree that this is a valuable goal, but I don't agree with your
> >> interpretation of the ticket spec. You absolutely know that you need
> >> to receive *some* message after the ServerHello, so until you get that
> >> the CSS is of no value to you. And once you get that message, it's
> > either
> >> a Certificate, SKE, or a SessionTicket, and you know how many messages
> >> you need to receive--or rather what the last message of the flight will
> >> be. Why is this problematic?
> >
> > When resuming, draft-salowey-tls-ticket-05.txt says that the server may
> > issue an optional
> > SessionTicket after the ServerHello. So there are 2 possabilities:
> >
> > (A)
> >          ClientHello
> >          (SessionTicket extension)      -------->
> >                                                           ServerHello
> >                                                    [ChangeCipherSpec]
> >                                        <--------             Finished
> >          [ChangeCipherSpec]
> >          Finished                      -------->
> >          Application Data              <------->     Application Data
> >
> >
> > (B)
> >          ClientHello
> >          (SessionTicket extension)      -------->
> >                                                           ServerHello
> >                                                         SessionTicket
> >                                                    [ChangeCipherSpec]
> >                                        <--------             Finished
> >          [ChangeCipherSpec]
> >          Finished                      -------->
> >          Application Data              <------->     Application Data
>
> I don't read this the same way as you do. The way I read it is that the
> SessionTicket is the signal that the server wishes to resume. If it's
> not sent, the server does a full handshake.

We will have to get Joe Salowey to clarify this because he also states:
        "If the server successfully verifies the client's ticket then it may renew the
       ticket by including a SessionTicket handshake message after the ServerHello."
To me "may renew the ticket" implies that the SessionTicket is optional but that resumption can still take place.


> >
> >> And as noted previously, you can always tell what's up when you
> >> see the Finished message, since you need to see all the messages
> >> in order to compute the Finished.verify.
> >
> > The Finished message is encrypted so I cannot look at the MSN until the
> > handshake layer has received the ChangeCipherSpec. The record layer will
> > not deliver the CCS to the handshake layer until it has determined that it
> > has received the entire flight of messages. So I don't see how the
> > Finished message can tell me if I have received the entire flight of
> > messages.
>
> I think you're thinking at the wrong layer here. The handshake layer
> is responsible for reliability here. And it *does* get the CCS and
> the Finished and (even in your interpretation of -ticket) is able
> to decrypt them and can then determine whether things were in order.
Did you mean to say the record layer is responsible for reliability?
I think the record layer is responsible for ensuring that messages are
transmitted and received reliably. Reliably means messages should be
received by the handshake layer in the order of the original flight of
messages sent by the peer.

My problem with the DTLS design deals with determining how to exit a waiting
state as defined in point #3 of section 4.2.4

        3. The implementation receives the next flight of messages:
     if this is the final flight of messages the implementation
     transitions to FINISHED. If the implementation needs to
     send a new flight, it transitions to the PREPARING state.
     Partial reads (whether partial messages or only some of the
     messages in the flight) do not cause state transitions or
     timer resets.

Determing when you have received the complete next flight of messages is not trivial unless there were no loss of records. If some records were lost then the record layer must determine when it has the complete
flight of messages through examining the contents of the messages themselves and by having some understanding of what messages are expected.  If I examine the ServerHello for a session id I will know whether the server is resuming and exactly how many messages to receive. If I look at the ciphersuite in the ServerHello I can tell if there will be a server key exchange message. If the client sent a certificate I can determine if a CertificateVerify message is expected. etc. I think SessionTicket is still a problem but let's wait for Joe Salowey to clear up the ambiguity in his draft.

To me this does not seem to be an ideal design for the record layer. I suggested adding an MSN to the ChangeCipherSpec message because I think it would make it clear how many handshake messages appear before
the ChangeCipherSpec and would make it simpler for the record layer to determine when it has received the complete set of messages belonging to the next flight.


--=_alternative 006EFEBF852570BB_=-- --===============0909937147== 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 --===============0909937147==-- From tls-bounces@lists.ietf.org Wed Nov 16 16:24:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUlk-0005V5-SG; Wed, 16 Nov 2005 16:24:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUli-0005UK-7n; Wed, 16 Nov 2005 16:24:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00868; Wed, 16 Nov 2005 16:24:05 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcV3D-00038s-FX; Wed, 16 Nov 2005 16:42:44 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 9124917058; Wed, 16 Nov 2005 13:31:16 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Wed, 16 Nov 2005 13:31:16 -0800 In-Reply-To: (Rob Dugal's message of "Wed, 16 Nov 2005 15:11:23 -0500") Message-ID: <86veys8el7.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: tls-bounces@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > Eric Rescorla wrote on 11/16/2005 10:55:58 AM: > We will have to get Joe Salowey to clarify this because he also states: > "If the server successfully verifies the client's ticket then it > may renew the > ticket by including a SessionTicket handshake message after the > ServerHello." > > To me "may renew the ticket" implies that the SessionTicket is optional > but that resumption can still take place. But then how would you know resumption was taking place? >> I think you're thinking at the wrong layer here. The handshake layer >> is responsible for reliability here. And it *does* get the CCS and >> the Finished and (even in your interpretation of -ticket) is able >> to decrypt them and can then determine whether things were in order. > > Did you mean to say the record layer is responsible for reliability? > I think the record layer is responsible for ensuring that messages are > transmitted and received reliably. Reliably means messages should be > received by the handshake layer in the order of the original flight of > messages sent by the peer. No, absolutely not. The record layer just hands over the packets in whatever order it gets them. The only layer that knows about reliability is the handshake layer. > My problem with the DTLS design deals with determining how to exit a > waiting > state as defined in point #3 of section 4.2.4 > > 3. The implementation receives the next flight of messages: > if this is the final flight of messages the implementation > transitions to FINISHED. If the implementation needs to > send a new flight, it transitions to the PREPARING state. > Partial reads (whether partial messages or only some of the > messages in the flight) do not cause state transitions or > timer resets. > > Determing when you have received the complete next flight of messages is > not trivial unless there were no loss of records. If some records were > lost then the record layer must determine when it has the complete > flight of messages through examining the contents of the messages > themselves and by having some understanding of what messages are expected. > If I examine the ServerHello for a session id I will know whether the > server is resuming and exactly how many messages to receive. If I look at > the ciphersuite in the ServerHello I can tell if there will be a server > key exchange message. If the client sent a certificate I can determine if > a CertificateVerify message is expected. etc. I think SessionTicket is > still a problem but let's wait for Joe Salowey to clear up the ambiguity > in his draft. > > To me this does not seem to be an ideal design for the record layer. I > suggested adding an MSN to the ChangeCipherSpec message because I think it > would make it clear how many handshake messages appear before > the ChangeCipherSpec and would make it simpler for the record layer to > determine when it has received the complete set of messages belonging to > the next flight. Again, I don't see the problem here. TLS (and DTLS) are lock-step protocols. In order to know when you're done you *always* need to know what messages to expect in a flight, whether it's TCP or UDP. If Salowey's design doesn't include that, then there's a problem because you need to feed messages into the Finished hash in order and so they can't cross in flight. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 05:10:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgiX-0008FJ-Ju; Thu, 17 Nov 2005 05:10:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcgiW-0008FB-Jq for tls@megatron.ietf.org; Thu, 17 Nov 2005 05:10:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11160 for ; Thu, 17 Nov 2005 05:09:34 -0500 (EST) Received: from revol3.enst.fr ([137.194.2.10] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ech06-00035N-9P for tls@ietf.org; Thu, 17 Nov 2005 05:28:21 -0500 Received: from localhost (localhost [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 97BB95FBB; Thu, 17 Nov 2005 11:09:55 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol3.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47561-06; Thu, 17 Nov 2005 11:09:53 +0100 (CET) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id A38E55DA2; Thu, 17 Nov 2005 11:09:53 +0100 (CET) Received: from enst.fr (dhcp164-248.enst.fr [137.194.164.248]) by infres.enst.fr (Postfix) with ESMTP id 4DE4413CBB; Thu, 17 Nov 2005 11:09:53 +0100 (MET) Message-ID: <437C56ED.1000203@enst.fr> Date: Thu, 17 Nov 2005 11:09:49 +0100 From: badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [TLS] draft-badra-hajjeh-mtls-00.txt References: <17266.17941.160710.5249@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: amavisd-new at enst.fr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 2.0 (++) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Cc: Mohamad.Badra@enst.fr, tls@ietf.org, Ibrahim.Hajjeh@esrgroups.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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Dear Tero, Thank you very much for your revision. Sorry for this late replay, some=20 comments are in-line... Tero Kivinen a =E9crit: >Firstly as someone else pointed out after the meeting, there is really >no reason to do any modifications to TLS to provide that kind of >multiplexing support, this all could simply be done in an application >layer doing normal port forwarding style connections multiplexing >multiple port forwardings inside one TLS tunnel. > Adding an extension to TLS is not really a modification, particularly=20 when the machine-state of the protocol, the handshake and the record=20 protocols remains unchangeable. Moreover, MTLS is transparent to the application except that the=20 application will connect locally to a specific port reserved for MTLS,=20 and it is the MTLS's job to deliver data to the application on the other=20 side. >There is nothing in the draft that I can find that would tie the >multiplexed streams to the TLS exchange itself, i.e. the applications >cannot really even see they are multiplexed over TLS tunnel. > The application will be configured to forward data to the mtls local=20 port, specifying the destination address (IP address or whatever).=20 However, the actual version of the draft does not precise how to do=20 that, and implementation note should be sufficient. We tried to keep the=20 characteristic of TLS concerning the transparency and the application=20 behavior. >The whole draft seems to be adding similar feature that is in the >secure shell, i.e. port forwarding (and if I understood correctly this >is local to local port forwarding, so more limited than what is in >secsh). See draft-ietf-secsh-connect-25.txt section 7. It does not >take account some of the issues of the forwarding. > I read the secsh draft and AFAIK, it is a set of signalling messages=20 exchanged between the multiplexing processes over the SSH session. In=20 the MTLS case, the negotiation is done during the handshake phase, which=20 reduces the chance to the entities to say more about their voluntaries=20 concerning some features such as packet size. Nevertheless, it could be=20 possible to add some signaling messages at the MTLS layer to allow more=20 options for the entities. In the first version on this draft, we are focused on local Port=20 forwarding with TLS. So, some issues like IP binding are not treated=20 till now. >I didn't really understood if it has a way to dynamimcally create and >cancelo those forwardings or not. Also didn't see if it supports >runnig multiple streams over same ports, i.e. if you forward port 25 >from your laptop throgh tls tunnel to smtp port (250) of the mail >server, do you allow multiple connections sharing that same forwarding >at the asme (i.e. send multiple mails simultaneously). > Once the Handshake phase has been established, actual version does not=20 allow creating or cancelling those forwarding applications. Because it=20 is related to the TLS Extensions in creating and canceling new=20 extensions (rfc 3546). Concerning the multi-mail, each mail will be sent=20 aver a different local port, so each mail will be encapsulated in mtls=20 packets, which are distinguished by the local port. >As far as I understood there is no flow control in the streams. That >kind of feature is mandatory in case you put multiple streams inside >one stream, and that flow control MUST be per stream. > >The common problem happening with ssh1, which didn't have this was >that you forwarded 2 services over the same ssh connection. The first >one was sending data to some service all the time, and then when the >destination server decided, that it does not want to read data right >now, there was no way to tell that to the other end of the tunnel, so >the sender would stop sending data. At some point all the buffers in >the destination end filled up, and the only way it could use to stop >the other end sending data was to use flow control on the >ssh-connection itself, i.e not reading any more data from the ssh TCP >stream. This also stopped all other forwarded connections running on >the same session.. > >SSH2 fixed this including flow control to each channel separtely, i.e. >the receiving end of the channel can say that other end is only >allowed to send xx bytes of data, and then it must stop. When the >receiveing end managed to send those data forward to the final >destination, it would again say to sender ssh that now we are ready to >take xx bytes of more data and so on. > Each connection will have local and destination ports and will be=20 identified by that at the MTLS layer. So I don't see why it must be per=20 stream? Even though we cited that using of stream IDs should be a=20 generic mode, but how can we do it with the MTLS context? As I cited before, if we want to add more features such as managing data=20 length transportation, we should add some signalling messages at the=20 MTLS and keeping it at the transport layer, instead of the application=20 layer. TLS does not allow sending signaling messages after the Handshake. Thus,=20 a flow control can be implemented when mtls handshake in negotiated=20 (i.e, a new field in the MTLS structure message). >The draft needs quite a lot more work to be usable, and at least for >me it was very hard to understand how the protocol actually worked >(thus it might be that I completely misunderstood it). > >On the other hand secure shell is already doing exactly what I >understood what it is trying to do, and it is one of the most common >use scenarios of the secure shell already, so I do not know if we want >to have another way to do exactly same thing in TLS.=20 > I agree that the draft needs more works. However, some mechanisms like=20 preshared keys were also defined by several security protocols before=20 they were defined by TLS. And I thing it is more appropriate to have a=20 maximum number of security services using TLS. =20 Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 07:16:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecih7-0001A8-Eq; Thu, 17 Nov 2005 07:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecih5-000183-Gg; Thu, 17 Nov 2005 07:16:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18312; Thu, 17 Nov 2005 07:16:12 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eciyg-0007QE-E3; Thu, 17 Nov 2005 07:35:01 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 6D9611006B099; Thu, 17 Nov 2005 07:16:23 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08443-25; Thu, 17 Nov 2005 07:16:20 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id AF71C100233C9; Thu, 17 Nov 2005 07:16:20 -0500 (EST) In-Reply-To: <86veys8el7.fsf@romeo.rtfm.com> To: EKR Subject: Re: [TLS] draft-rescorla-dtls-05.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 17 Nov 2005 07:16:59 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/17/2005 07:17:03 AM, Serialize complete at 11/17/2005 07:17:03 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============1345110934==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1345110934== Content-Type: multipart/alternative; boundary="=_alternative 00439012852570BC_=" This is a multipart message in MIME format. --=_alternative 00439012852570BC_= Content-Type: text/plain; charset="US-ASCII" tls-bounces@lists.ietf.org wrote on 11/16/2005 04:31:16 PM: > Rob Dugal writes: > > Eric Rescorla wrote on 11/16/2005 10:55:58 AM: > > We will have to get Joe Salowey to clarify this because he also states: > > "If the server successfully verifies the client's ticket then it > > may renew the > > ticket by including a SessionTicket handshake message after the > > ServerHello." > > > > To me "may renew the ticket" implies that the SessionTicket is optional > > but that resumption can still take place. > But then how would you know resumption was taking place? You tell if the server is resuming by receiving either ServerHello+SessionTicket+ChangeCipherSpec or ServerHello+ChangeCipherSpec. > > >> I think you're thinking at the wrong layer here. The handshake layer > >> is responsible for reliability here. And it *does* get the CCS and > >> the Finished and (even in your interpretation of -ticket) is able > >> to decrypt them and can then determine whether things were in order. > > > > Did you mean to say the record layer is responsible for reliability? > > I think the record layer is responsible for ensuring that messages are > > transmitted and received reliably. Reliably means messages should be > > received by the handshake layer in the order of the original flight of > > messages sent by the peer. > > No, absolutely not. The record layer just hands over the packets in whatever > order it gets them. The only layer that knows about reliability is > the handshake layer. Ok, I see where our difference in understanding is then. In your draft this statement from 3.2 had me believing that the record layer will be responsible for ensuring that the messages are delivered to the handshake layer in the correct order. 3.2. Providing Reliability for Handshake The TLS handshake is a lockstep cryptographic handshake. Messages must be transmitted and received in a defined order and any other order is an error. Clearly, this is incompatible with reordering and message loss. In addition, TLS handshake messages are potentially larger than any given datagram, thus creating the problem of fragmentation. DTLS must provide fixes for both these problems. In TLS, TCP ensures that the record layer delivers all the messages, including ChangeCipherSpec, in order to the handshake layer. I thought that the DTLS record layer would then also ensure that it delivers all the messages in order to the handshake layer. By adding an MSN to the ChangeCipherSpec the record layer would be able to do this easily. When the record layer reads a record it can buffer the record until it gets the next expected MSN and until it gets all the fragments for that message. The ChangeCipherSpec would then look pretty much like just another handshake record, except that it has no message data. I think this would also mean fewer changes in the handshake layer because now it receives messages in the same order as it would for TLS and all it has to do is handle differences in the message header. > > > My problem with the DTLS design deals with determining how to exit a > > waiting > > state as defined in point #3 of section 4.2.4 > > > > 3. The implementation receives the next flight of messages: > > if this is the final flight of messages the implementation > > transitions to FINISHED. If the implementation needs to > > send a new flight, it transitions to the PREPARING state. > > Partial reads (whether partial messages or only some of the > > messages in the flight) do not cause state transitions or > > timer resets. > > > > Determing when you have received the complete next flight of messages is > > not trivial unless there were no loss of records. If some records were > > lost then the record layer must determine when it has the complete > > flight of messages through examining the contents of the messages > > themselves and by having some understanding of what messages are expected. > > If I examine the ServerHello for a session id I will know whether the > > server is resuming and exactly how many messages to receive. If I look at > > the ciphersuite in the ServerHello I can tell if there will be a server > > key exchange message. If the client sent a certificate I can determine if > > a CertificateVerify message is expected. etc. I think SessionTicket is > > still a problem but let's wait for Joe Salowey to clear up the ambiguity > > in his draft. > > > > To me this does not seem to be an ideal design for the record layer. I > > suggested adding an MSN to the ChangeCipherSpec message because I think it > > would make it clear how many handshake messages appear before > > the ChangeCipherSpec and would make it simpler for the record layer to > > determine when it has received the complete set of messages belonging to > > the next flight. > > Again, I don't see the problem here. TLS (and DTLS) are lock-step > protocols. In order to know when you're done you *always* need > to know what messages to expect in a flight, whether it's TCP or > UDP. If Salowey's design doesn't include that, then there's > a problem because you need to feed messages into the Finished > hash in order and so they can't cross in flight. I don't think there is any major problem with the salowey design as far as using it in TLS, I have implemented it. I don't believe I can implement it in DTLS though because of the lack of an MSN in the ChangeCipherSpec. After a ServerHelloDone I don't know if I will get SessionTicket+ChangeCipherSpec or just ChangeCipherSpec so I don't know how to determine if I lost the SessionTicket until I actually process the Finished message, and at that point it will be too late and the handshake will fail. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 00439012852570BC_= Content-Type: text/html; charset="US-ASCII"
tls-bounces@lists.ietf.org wrote on 11/16/2005 04:31:16 PM:

> Rob Dugal <RDugal@certicom.com> writes:
> > Eric Rescorla <ekr@rtfm.com> wrote on 11/16/2005 10:55:58 AM:
> > We will have to get Joe Salowey to clarify this because he also states:
> >         "If the server successfully verifies the client's ticket then it
> > may renew the
> >         ticket by including a SessionTicket handshake message after the
> > ServerHello."
> >
> > To me "may renew the ticket" implies that the SessionTicket is optional
> > but that resumption can still take place.
> But then how would you know resumption was taking place?
You tell if the server is resuming by receiving either ServerHello+SessionTicket+ChangeCipherSpec or
ServerHello+ChangeCipherSpec.



>
> >> I think you're thinking at the wrong layer here. The handshake layer
> >> is responsible for reliability here. And it *does* get the CCS and
> >> the Finished and (even in your interpretation of -ticket) is able
> >> to decrypt them and can then determine whether things were in order.
> >
> > Did you mean to say the record layer is responsible for reliability?
> > I think the record layer is responsible for ensuring that messages are
> > transmitted and received reliably. Reliably means messages should be
> > received by the handshake layer in the order of the original flight of
> > messages sent by the peer.
>
> No, absolutely not. The record layer just hands over the packets in whatever
> order it gets them. The only layer that knows about reliability is
> the handshake layer.
Ok, I see where our difference in understanding is then.
In your draft this statement from 3.2 had me believing that the record layer will be responsible
for ensuring that the messages are delivered to the handshake layer in the correct order.

3.2. Providing Reliability for Handshake

  The TLS handshake is a lockstep cryptographic handshake.
  Messages must be transmitted and received in a defined order
  and any other order is an error. Clearly, this is incompatible
  with reordering and message loss. In addition, TLS handshake
  messages are potentially larger than any given datagram, thus
  creating the problem of fragmentation. DTLS must provide fixes
  for both these problems.

In TLS, TCP ensures that the record layer delivers all the messages, including ChangeCipherSpec, in order to the handshake layer. I thought that the DTLS record layer would then also ensure that it delivers all the messages in order to the handshake layer. By adding an MSN to the ChangeCipherSpec the record layer would be able to do this easily. When the record layer reads a record it can buffer the record until it gets the next expected MSN and until it gets all the fragments for that message. The ChangeCipherSpec would then look pretty much like just another handshake record, except that it has no message data. I think this would also mean fewer changes in the handshake layer because now it receives messages in the same order as it would for TLS and all it has to do is handle differences in the message header.

 
>
> > My problem with the DTLS design deals with determining how to exit a
> > waiting
> > state as defined in point #3 of section 4.2.4
> >
> >         3. The implementation receives the next flight of messages:
> >       if this is the final flight of messages the implementation
> >       transitions to FINISHED. If the implementation needs to
> >       send a new flight, it transitions to the PREPARING state.
> >       Partial reads (whether partial messages or only some of the
> >       messages in the flight) do not cause state transitions or
> >       timer resets.
> >
> > Determing when you have received the complete next flight of messages is
> > not trivial unless there were no loss of records. If some records were
> > lost then the record layer must determine when it has the complete
> > flight of messages through examining the contents of the messages
> > themselves and by having some understanding of what messages are expected.
> >  If I examine the ServerHello for a session id I will know whether the
> > server is resuming and exactly how many messages to receive. If I look at
> > the ciphersuite in the ServerHello I can tell if there will be a server
> > key exchange message. If the client sent a certificate I can determine if
> > a CertificateVerify message is expected. etc. I think SessionTicket is
> > still a problem but let's wait for Joe Salowey to clear up the ambiguity
> > in his draft.
> >
> > To me this does not seem to be an ideal design for the record layer. I
> > suggested adding an MSN to the ChangeCipherSpec message because I think it
> > would make it clear how many handshake messages appear before
> > the ChangeCipherSpec and would make it simpler for the record layer to
> > determine when it has received the complete set of messages belonging to
> > the next flight.
>
> Again, I don't see the problem here. TLS (and DTLS) are lock-step
> protocols. In order to know when you're done you *always* need
> to know what messages to expect in a flight, whether it's TCP or
> UDP. If Salowey's design doesn't include that, then there's
> a problem because you need to feed messages into the Finished
> hash in order and so they can't cross in flight.

I don't think there is any major problem with the salowey design as far as using it in TLS, I have implemented it.  I don't believe I can implement it in DTLS though because of the lack of an MSN in the ChangeCipherSpec.
After a ServerHelloDone I don't know if I will get SessionTicket+ChangeCipherSpec or just ChangeCipherSpec so
I don't know how to determine if I lost the SessionTicket until I actually process the Finished message, and at that point it will be too late and the handshake will fail.

>
> -Ekr
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 00439012852570BC_=-- --===============1345110934== 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 --===============1345110934==-- From tls-bounces@lists.ietf.org Thu Nov 17 07:35:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcizJ-0007IO-2a; Thu, 17 Nov 2005 07:35:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcizF-0007IG-KK for tls@megatron.ietf.org; Thu, 17 Nov 2005 07:35:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19516 for ; Thu, 17 Nov 2005 07:34:59 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcjGt-00084E-4U for tls@ietf.org; Thu, 17 Nov 2005 07:53:47 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 6F6231006B099; Thu, 17 Nov 2005 07:35:24 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06237-58; Thu, 17 Nov 2005 07:35:21 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id C8E96100233C9; Thu, 17 Nov 2005 07:35:21 -0500 (EST) In-Reply-To: <7210B31550AC934A8637D6619739CE69061B17F5@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: Re: [TLS] draft-salowey-tls-ticket-05.txt available MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 17 Nov 2005 07:36:01 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/17/2005 07:36:04 AM, Serialize complete at 11/17/2005 07:36:04 AM X-Spam-Score: 0.8 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============1378320908==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1378320908== Content-Type: multipart/alternative; boundary="=_alternative 00454E19852570BC_=" This is a multipart message in MIME format. --=_alternative 00454E19852570BC_= Content-Type: text/plain; charset="US-ASCII" During a discussion of TLS with Eric Rescorla I brought up your draft and it turns out Eric and I have interpreted session resumption in section 3.1 a little differently. I have pasted a portion of the discussion below. > > > ClientHello > > > (SessionTicket extension) --------> > > > ServerHello > > > SessionTicket > > > [ChangeCipherSpec] > > > <-------- Finished > > > [ChangeCipherSpec] > > > Finished --------> > > > Application Data <-------> Application Data > > > > I don't read this the same way as you do. The way I read it is that the > > SessionTicket is the signal that the server wishes to resume. If it's > > not sent, the server does a full handshake. > > We will have to get Joe Salowey to clarify this because he also states: > "If the server successfully verifies the client's ticket then it may renew the > ticket by including a SessionTicket handshake message after the ServerHello." > > To me "may renew the ticket" implies that the SessionTicket is optional but that resumption > can still take place. >From my reading of your draft-05 I came to the conclusion that there are 2 possible sets of messages if session resumption takes place using the client's ticket. case 1: where the server resumes but also issues a new ticket: ClientHello (SessionTicket extension) --------> ServerHello SessionTicket [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data ServerHello case 2: where the server resumes but does not issue a new ticket: ClientHello (SessionTicket extension) --------> ServerHello [ChangeCipherSpec] <-------- Finished [ChangeCipherSpec] Finished --------> Application Data <-------> Application Data ServerHello could you please clarify? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com tls-bounces@lists.ietf.org wrote on 10/24/2005 01:43:07 PM: > draft-salowey-tls-ticket-05.txt is available at > > http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt > > changes based on review comments: > > - Section 3.4 added to describe interaction with session ID > - Section 4 now indicates recommended format instead of example > - Sections 3.2 and 3.3 behavior of messages clarified > > Thanks, > > Joe > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 00454E19852570BC_= Content-Type: text/html; charset="US-ASCII"
During a discussion of TLS with Eric Rescorla  I brought up your draft and it turns out
Eric and I have interpreted session resumption in section 3.1 a little differently.
I have pasted a portion of the discussion below.

> > >          ClientHello
> > >          (SessionTicket extension)      -------->
> > >                                                           ServerHello
> > >                                                         SessionTicket
> > >                                                    [ChangeCipherSpec]
> > >                                        <--------             Finished
> > >          [ChangeCipherSpec]
> > >          Finished                      -------->
> > >          Application Data              <------->     Application Data
> >
> > I don't read this the same way as you do. The way I read it is that the
> > SessionTicket is the signal that the server wishes to resume. If it's
> > not sent, the server does a full handshake.
>
> We will have to get Joe Salowey to clarify this because he also states:
>         "If the server successfully verifies the client's ticket then it may renew the
>        ticket by including a SessionTicket handshake message after the ServerHello."
>
> To me "may renew the ticket" implies that the SessionTicket is optional but that resumption
> can still take place.

From my reading of your draft-05 I came to the conclusion that there are 2 possible sets
of messages if session resumption takes place using the client's ticket.

case 1: where the server resumes but also issues a new ticket:

          ClientHello
          (SessionTicket extension)      -------->
                                                           ServerHello
                                                         SessionTicket
                                                    [ChangeCipherSpec]
                                        <--------             Finished
          [ChangeCipherSpec]
          Finished                      -------->
          Application Data              <------->     Application Data
                                                           ServerHello


case 2: where the server resumes but does not issue a new ticket:

          ClientHello
          (SessionTicket extension)      -------->
                                                           ServerHello
                                                    [ChangeCipherSpec]
                                        <--------             Finished
          [ChangeCipherSpec]
          Finished                      -------->
          Application Data              <------->     Application Data
                                                           ServerHello

could you please clarify?
-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

tls-bounces@lists.ietf.org wrote on 10/24/2005 01:43:07 PM:

> draft-salowey-tls-ticket-05.txt is available at
>
> http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt
>
> changes based on review comments:
>
> - Section 3.4 added to describe interaction with session ID
> - Section 4 now indicates recommended format instead of example
> - Sections 3.2 and 3.3 behavior of messages clarified
>
> Thanks,
>
> Joe
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 00454E19852570BC_=-- --===============1378320908== 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 --===============1378320908==-- From tls-bounces@lists.ietf.org Thu Nov 17 10:33:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcllJ-0007mX-PQ; Thu, 17 Nov 2005 10:33:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcllI-0007mM-AU; Thu, 17 Nov 2005 10:33:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00975; Thu, 17 Nov 2005 10:32:46 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecm2w-0006If-Fk; Thu, 17 Nov 2005 10:51:35 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 7E2F117058; Thu, 17 Nov 2005 07:39:47 -0800 (PST) To: Rob Dugal Subject: Re: [TLS] draft-rescorla-dtls-05.txt References: From: Eric Rescorla Date: Thu, 17 Nov 2005 07:39:47 -0800 In-Reply-To: (Rob Dugal's message of "Thu, 17 Nov 2005 07:16:59 -0500") Message-ID: <86r79f8erg.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: tls-bounces@ietf.org, tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Rob Dugal writes: > tls-bounces@lists.ietf.org wrote on 11/16/2005 04:31:16 PM: > >> Rob Dugal writes: >> > Eric Rescorla wrote on 11/16/2005 10:55:58 AM: >> > We will have to get Joe Salowey to clarify this because he also > states: >> > "If the server successfully verifies the client's ticket then > it >> > may renew the >> > ticket by including a SessionTicket handshake message after > the >> > ServerHello." >> > >> > To me "may renew the ticket" implies that the SessionTicket is > optional >> > but that resumption can still take place. >> But then how would you know resumption was taking place? > > You tell if the server is resuming by receiving either > ServerHello+SessionTicket+ChangeCipherSpec or > ServerHello+ChangeCipherSpec. I see your point, but arguably the CSS isn't part of the Handshake state machine so I'd prefer to see cipher suites had explicit messaging of this kind of state. >> No, absolutely not. The record layer just hands over the packets in > whatever >> order it gets them. The only layer that knows about reliability is >> the handshake layer. > > Ok, I see where our difference in understanding is then. > In your draft this statement from 3.2 had me believing that the record > layer will be responsible > for ensuring that the messages are delivered to the handshake layer in the > correct order. > > 3.2. Providing Reliability for Handshake > > The TLS handshake is a lockstep cryptographic handshake. > Messages must be transmitted and received in a defined order > and any other order is an error. Clearly, this is incompatible > with reordering and message loss. In addition, TLS handshake > messages are potentially larger than any given datagram, thus > creating the problem of fragmentation. DTLS must provide fixes > for both these problems. > > > In TLS, TCP ensures that the record layer delivers all the messages, > including ChangeCipherSpec, in order to the handshake layer. I thought > that the DTLS record layer would then also ensure that it delivers all the > messages in order to the handshake layer. By adding an MSN to the > ChangeCipherSpec the record layer would be able to do this easily. When > the record layer reads a record it can buffer the record until it gets the > next expected MSN and until it gets all the fragments for that message. > The ChangeCipherSpec would then look pretty much like just another > handshake record, except that it has no message data. I think this would > also mean fewer changes in the handshake layer because now it receives > messages in the same order as it would for TLS and all it has to do is > handle differences in the message header. Well, this is certainly one potential design, but it's not the one that DTLS uses. The rationale for this is cleaner architectural separation between the protocol layers. > I don't think there is any major problem with the salowey design as far as > using it in TLS, I have implemented it. I don't believe I can implement > it in DTLS though because of the lack of an MSN in the ChangeCipherSpec. > After a ServerHelloDone I don't know if I will get > SessionTicket+ChangeCipherSpec or just ChangeCipherSpec so > I don't know how to determine if I lost the SessionTicket until I actually > process the Finished message, and at that point it will be too late and > the handshake will fail. Why would it fail? You compute the new cipher state, decrypt the Finished message, look at the MSN, and then when it's not ready yet, shove it into a buffer and wait for the next record. One concern here might be that you've lost the old cipher state but because of reordering you needed to keep it around for a while anyway. That's what the "epoch" is for... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 12:00:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecn7E-0007TY-40; Thu, 17 Nov 2005 12:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecn7B-0007Rc-Bx for tls@megatron.ietf.org; Thu, 17 Nov 2005 12:00:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06523 for ; Thu, 17 Nov 2005 11:59:27 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcnOr-000110-2R for tls@ietf.org; Thu, 17 Nov 2005 12:18:17 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2005 08:59:51 -0800 X-IronPort-AV: i="3.97,343,1125903600"; d="scan'208"; a="231697089:sNHT32041476" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id jAHGxpCJ022615; Thu, 17 Nov 2005 08:59:51 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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-salowey-tls-ticket-05.txt available Date: Thu, 17 Nov 2005 09:05:35 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6906409925@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] draft-salowey-tls-ticket-05.txt available Thread-Index: AcXrdDYfg3G2yFtjRZydpyIdLzqJ2AAHbz+Q From: "Salowey, Joe" To: "Rob Dugal" X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Content-Transfer-Encoding: quoted-printable Cc: tls-bounces@ietf.org, 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Hi Rob, I have been trying to catch up on this discussion. You are right, we modified the draft to allow the server to send a SessionTicket handshake message during session resume. It seems that this is an issue for DTLS because you don't know if you should receive this message or not. If this is the problem I can see two ways to fix this in the draft. =20 In the first approach we can disallow the sending of a new session ticket on session resume. =20 The second approach would be to have the server send a session ticket extension whenever it thought it might issue a ticket. If it did then it would be required to include a session ticket handshake message in the exchange (the message might have zero length if for some reason the server decides not to send a ticket). This extension really should work with DTLS so I think we need to do one of the above. I think the second approach would be better (the first one is probably incomplete with the second one anyway). Always require the server to send a sessionTicket extension if it may need to issue a session ticket in the handshake. If the server includes the extension then it MUST send a session ticket handshake message. The handshake message may be 0 length if the server couldn't issue a ticket for some reason. =20 Make sense? Thanks, Joe > -----Original Message----- > From: Rob Dugal [mailto:RDugal@certicom.com]=20 > Sent: Thursday, November 17, 2005 4:36 AM > To: Salowey, Joe > Cc: tls@ietf.org; tls-bounces@lists.ietf.org > Subject: Re: [TLS] draft-salowey-tls-ticket-05.txt available >=20 >=20 > During a discussion of TLS with Eric Rescorla I brought up=20 > your draft and it turns out Eric and I have interpreted=20 > session resumption in section 3.1 a little differently.=20 > I have pasted a portion of the discussion below.=20 >=20 > > > > ClientHello=20 > > > > (SessionTicket extension) -------->=20 > > > > =20 > ServerHello=20 > > > > =20 > SessionTicket=20 > > > > =20 > [ChangeCipherSpec]=20 > > > > <-------- =20 > Finished=20 > > > > [ChangeCipherSpec]=20 > > > > Finished -------->=20 > > > > Application Data <-------> =20 > Application Data=20 > > >=20 > > > I don't read this the same way as you do. The way I read=20 > it is that=20 > > > the SessionTicket is the signal that the server wishes to=20 > resume. If=20 > > > it's not sent, the server does a full handshake. > >=20 > > We will have to get Joe Salowey to clarify this because he=20 > also states:=20 > > "If the server successfully verifies the client's=20 > ticket then it may renew the=20 > > ticket by including a SessionTicket handshake=20 > message after the ServerHello."=20 > >=20 > > To me "may renew the ticket" implies that the SessionTicket is=20 > > optional but that resumption can still take place. >=20 > From my reading of your draft-05 I came to the conclusion=20 > that there are 2 possible sets of messages if session=20 > resumption takes place using the client's ticket.=20 >=20 > case 1: where the server resumes but also issues a new ticket:=20 >=20 > ClientHello=20 > (SessionTicket extension) -------->=20 > =20 > ServerHello=20 > =20 > SessionTicket=20 > =20 > [ChangeCipherSpec]=20 > <-------- =20 > Finished=20 > [ChangeCipherSpec]=20 > Finished -------->=20 > Application Data <-------> =20 > Application Data=20 > =20 > ServerHello=20 >=20 >=20 > case 2: where the server resumes but does not issue a new ticket:=20 >=20 > ClientHello=20 > (SessionTicket extension) -------->=20 > =20 > ServerHello=20 > =20 > [ChangeCipherSpec]=20 > <-------- =20 > Finished=20 > [ChangeCipherSpec]=20 > Finished -------->=20 > Application Data <-------> =20 > Application Data=20 > =20 > ServerHello=20 >=20 > could you please clarify? > ----------------------------------------------- > Robert Dugal > Member of Development Group > Certicom Corp. > EMAIL: rdugal@certicom.com > PHONE: (905) 501-3848 > FAX : (905) 507-4230 > WEBSITE: www.certicom.com=20 >=20 > tls-bounces@lists.ietf.org wrote on 10/24/2005 01:43:07 PM: >=20 > > draft-salowey-tls-ticket-05.txt is available at > >=20 > > http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt > >=20 > > changes based on review comments: > >=20 > > - Section 3.4 added to describe interaction with session ID > > - Section 4 now indicates recommended format instead of example > > - Sections 3.2 and 3.3 behavior of messages clarified > >=20 > > Thanks, > >=20 > > Joe > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 12:18:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcnPN-0005Xc-S7; Thu, 17 Nov 2005 12:18:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcnPL-0005Uq-V3 for tls@megatron.ietf.org; Thu, 17 Nov 2005 12:18:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07712 for ; Thu, 17 Nov 2005 12:18:13 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecnh1-0001f3-RC for tls@ietf.org; Thu, 17 Nov 2005 12:37:04 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 7B3CB1006B0A6; Thu, 17 Nov 2005 12:18:32 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12790-40; Thu, 17 Nov 2005 12:18:29 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id C486E1006B0A1; Thu, 17 Nov 2005 12:18:29 -0500 (EST) In-Reply-To: <7210B31550AC934A8637D6619739CE6906409925@e2k-sea-xch2.sea-alpha.cisco.com> To: "Salowey, Joe" Subject: RE: [TLS] draft-salowey-tls-ticket-05.txt available MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Thu, 17 Nov 2005 12:19:08 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/17/2005 12:19:11 PM, Serialize complete at 11/17/2005 12:19:11 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 Cc: tls-bounces@ietf.org, 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: , Content-Type: multipart/mixed; boundary="===============0481299628==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0481299628== Content-Type: multipart/alternative; boundary="=_alternative 005F39C4852570BC_=" This is a multipart message in MIME format. --=_alternative 005F39C4852570BC_= Content-Type: text/plain; charset="US-ASCII" I like the second approach. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com "Salowey, Joe" wrote on 11/17/2005 12:05:35 PM: > Hi Rob, > > I have been trying to catch up on this discussion. You are right, we > modified the draft to allow the server to send a SessionTicket handshake > message during session resume. It seems that this is an issue for DTLS > because you don't know if you should receive this message or not. If > this is the problem I can see two ways to fix this in the draft. > > In the first approach we can disallow the sending of a new session > ticket on session resume. > > The second approach would be to have the server send a session ticket > extension whenever it thought it might issue a ticket. If it did then > it would be required to include a session ticket handshake message in > the exchange (the message might have zero length if for some reason the > server decides not to send a ticket). > > This extension really should work with DTLS so I think we need to do one > of the above. I think the second approach would be better (the first one > is probably incomplete with the second one anyway). Always require the > server to send a sessionTicket extension if it may need to issue a > session ticket in the handshake. If the server includes the extension > then it MUST send a session ticket handshake message. The handshake > message may be 0 length if the server couldn't issue a ticket for some > reason. > > Make sense? > > Thanks, > > Joe > > > -----Original Message----- > > From: Rob Dugal [mailto:RDugal@certicom.com] > > Sent: Thursday, November 17, 2005 4:36 AM > > To: Salowey, Joe > > Cc: tls@ietf.org; tls-bounces@lists.ietf.org > > Subject: Re: [TLS] draft-salowey-tls-ticket-05.txt available > > > > > > During a discussion of TLS with Eric Rescorla I brought up > > your draft and it turns out Eric and I have interpreted > > session resumption in section 3.1 a little differently. > > I have pasted a portion of the discussion below. > > > > > > > ClientHello > > > > > (SessionTicket extension) --------> > > > > > > > ServerHello > > > > > > > SessionTicket > > > > > > > [ChangeCipherSpec] > > > > > <-------- > > Finished > > > > > [ChangeCipherSpec] > > > > > Finished --------> > > > > > Application Data <-------> > > Application Data > > > > > > > > I don't read this the same way as you do. The way I read > > it is that > > > > the SessionTicket is the signal that the server wishes to > > resume. If > > > > it's not sent, the server does a full handshake. > > > > > > We will have to get Joe Salowey to clarify this because he > > also states: > > > "If the server successfully verifies the client's > > ticket then it may renew the > > > ticket by including a SessionTicket handshake > > message after the ServerHello." > > > > > > To me "may renew the ticket" implies that the SessionTicket is > > > optional but that resumption can still take place. > > > > From my reading of your draft-05 I came to the conclusion > > that there are 2 possible sets of messages if session > > resumption takes place using the client's ticket. > > > > case 1: where the server resumes but also issues a new ticket: > > > > ClientHello > > (SessionTicket extension) --------> > > > > ServerHello > > > > SessionTicket > > > > [ChangeCipherSpec] > > <-------- > > Finished > > [ChangeCipherSpec] > > Finished --------> > > Application Data <-------> > > Application Data > > > > ServerHello > > > > > > case 2: where the server resumes but does not issue a new ticket: > > > > ClientHello > > (SessionTicket extension) --------> > > > > ServerHello > > > > [ChangeCipherSpec] > > <-------- > > Finished > > [ChangeCipherSpec] > > Finished --------> > > Application Data <-------> > > Application Data > > > > ServerHello > > > > could you please clarify? > > ----------------------------------------------- > > Robert Dugal > > Member of Development Group > > Certicom Corp. > > EMAIL: rdugal@certicom.com > > PHONE: (905) 501-3848 > > FAX : (905) 507-4230 > > WEBSITE: www.certicom.com > > > > tls-bounces@lists.ietf.org wrote on 10/24/2005 01:43:07 PM: > > > > > draft-salowey-tls-ticket-05.txt is available at > > > > > > http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt > > > > > > changes based on review comments: > > > > > > - Section 3.4 added to describe interaction with session ID > > > - Section 4 now indicates recommended format instead of example > > > - Sections 3.2 and 3.3 behavior of messages clarified > > > > > > Thanks, > > > > > > Joe > > > > > > _______________________________________________ > > > TLS mailing list > > > TLS@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/tls > > > > --=_alternative 005F39C4852570BC_= Content-Type: text/html; charset="US-ASCII"
I like the second approach.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

"Salowey, Joe" <jsalowey@cisco.com> wrote on 11/17/2005 12:05:35 PM:

> Hi Rob,
>
> I have been trying to catch up on this discussion.  You are right, we
> modified the draft to allow the server to send a SessionTicket handshake
> message during session resume.  It seems that this is an issue for DTLS
> because you don't know if you should receive this message or not. If
> this is the problem I can see two ways to fix this in the draft.  
>
> In the first approach we can disallow the sending of a new session
> ticket on session resume.  
>
> The second approach would be to have the server send a session ticket
> extension whenever it thought it might issue a ticket.  If it did then
> it would be required to include a session ticket handshake message in
> the exchange (the message might have zero length if for some reason the
> server decides not to send a ticket).
>
> This extension really should work with DTLS so I think we need to do one
> of the above. I think the second approach would be better (the first one
> is probably incomplete with the second one anyway).  Always require the
> server to send a sessionTicket extension if it may need to issue a
> session ticket in the handshake.  If the server includes the extension
> then it MUST send a session ticket handshake message.  The handshake
> message may be 0 length if the server couldn't issue a ticket for some
> reason.  
>
> Make sense?
>
> Thanks,
>
> Joe
>
> > -----Original Message-----
> > From: Rob Dugal [mailto:RDugal@certicom.com]
> > Sent: Thursday, November 17, 2005 4:36 AM
> > To: Salowey, Joe
> > Cc: tls@ietf.org; tls-bounces@lists.ietf.org
> > Subject: Re: [TLS] draft-salowey-tls-ticket-05.txt available
> >
> >
> > During a discussion of TLS with Eric Rescorla  I brought up
> > your draft and it turns out Eric and I have interpreted
> > session resumption in section 3.1 a little differently.
> > I have pasted a portion of the discussion below.
> >
> > > > >          ClientHello
> > > > >          (SessionTicket extension)      -------->
> > > > >                                                        
> >   ServerHello
> > > > >                                                        
> > SessionTicket
> > > > >                                                    
> > [ChangeCipherSpec]
> > > > >                                        <--------        
> >      Finished
> > > > >          [ChangeCipherSpec]
> > > > >          Finished                      -------->
> > > > >          Application Data              <------->    
> > Application Data
> > > >
> > > > I don't read this the same way as you do. The way I read
> > it is that
> > > > the SessionTicket is the signal that the server wishes to
> > resume. If
> > > > it's not sent, the server does a full handshake.
> > >
> > > We will have to get Joe Salowey to clarify this because he
> > also states:
> > >         "If the server successfully verifies the client's
> > ticket then it may renew the
> > >        ticket by including a SessionTicket handshake
> > message after the ServerHello."
> > >
> > > To me "may renew the ticket" implies that the SessionTicket is
> > > optional but that resumption can still take place.
> >
> > From my reading of your draft-05 I came to the conclusion
> > that there are 2 possible sets of messages if session
> > resumption takes place using the client's ticket.
> >
> > case 1: where the server resumes but also issues a new ticket:
> >
> >           ClientHello
> >           (SessionTicket extension)      -------->
> >                                                            
> > ServerHello
> >                                                          
> > SessionTicket
> >                                                    
> > [ChangeCipherSpec]
> >                                         <--------            
> > Finished
> >           [ChangeCipherSpec]
> >           Finished                      -------->
> >           Application Data              <------->    
> > Application Data
> >                                                            
> > ServerHello
> >
> >
> > case 2: where the server resumes but does not issue a new ticket:
> >
> >           ClientHello
> >           (SessionTicket extension)      -------->
> >                                                            
> > ServerHello
> >                                                    
> > [ChangeCipherSpec]
> >                                         <--------            
> > Finished
> >           [ChangeCipherSpec]
> >           Finished                      -------->
> >           Application Data              <------->    
> > Application Data
> >                                                            
> > ServerHello
> >
> > could you please clarify?
> > -----------------------------------------------
> > Robert Dugal
> > Member of Development Group
> > Certicom Corp.
> > EMAIL: rdugal@certicom.com
> > PHONE: (905) 501-3848
> > FAX  : (905) 507-4230
> > WEBSITE: www.certicom.com
> >
> > tls-bounces@lists.ietf.org wrote on 10/24/2005 01:43:07 PM:
> >
> > > draft-salowey-tls-ticket-05.txt is available at
> > >
> > > http://www.ietf.org/internet-drafts/draft-salowey-tls-ticket-05.txt
> > >
> > > changes based on review comments:
> > >
> > > - Section 3.4 added to describe interaction with session ID
> > > - Section 4 now indicates recommended format instead of example
> > > - Sections 3.2 and 3.3 behavior of messages clarified
> > >
> > > Thanks,
> > >
> > > Joe
> > >
> > > _______________________________________________
> > > TLS mailing list
> > > TLS@lists.ietf.org
> > > https://www1.ietf.org/mailman/listinfo/tls
> >
> >
--=_alternative 005F39C4852570BC_=-- --===============0481299628== 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 --===============0481299628==-- From tls-bounces@lists.ietf.org Thu Nov 17 12:31:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecnc7-0005P8-K6; Thu, 17 Nov 2005 12:31:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecnc6-0005P3-2S for tls@megatron.ietf.org; Thu, 17 Nov 2005 12:31:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08495 for ; Thu, 17 Nov 2005 12:31:23 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecntj-00026O-9r for tls@ietf.org; Thu, 17 Nov 2005 12:50:14 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id B4A5122243A for ; Thu, 17 Nov 2005 09:31:01 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 17 Nov 2005 09:31:37 -0800 From: Eric Rescorla Message-Id: <20051117173101.B4A5122243A@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Subject: [TLS] Proposed TLS WG recharter 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Here's my proposed TLS WG recharter. Any comments? -Ekr Description of Working Group: Goals and Milestones: The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS, version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on adding major new cipher suites to TLS, including Counter (CTR) and authenticated encryption modes. In the preparation of TLS 1.2, the Working Group will attempt to avoid gratuitous changes to TLS 1.1. Goals and Milestones ------------------- Done Agreement on charter and issues in current draft. Done Final draft for Secure Transport Layer Protocol ('STLP') Done Working group 'Last Call' Done Submit to IESG for consideration as a Proposed Standard. Done First revised draft of TLS specification 3/06 First revised draft of TLS 1.2 specification. 3/06 Submit specification of Counter Mode cipher suites to IESG for publication as Proposed Standard. 3/06 First draft of authenticated encryption mode cipher suites specification. 12/06 Submit specification of TLS 1.2 specification to IESG for publication as Proposed Standard. 12/06 Submit specification of authenticated encryption mode cipher suites to IESG for publication as Proposed Standard. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 12:36:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecng9-0006SR-7P; Thu, 17 Nov 2005 12:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecng7-0006SK-Hq for tls@megatron.ietf.org; Thu, 17 Nov 2005 12:36:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08688 for ; Thu, 17 Nov 2005 12:35:33 -0500 (EST) Received: from revol1.enst.fr ([137.194.32.27] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ecnxj-0002EY-J6 for tls@ietf.org; Thu, 17 Nov 2005 12:54:24 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 4DF06164C33; Thu, 17 Nov 2005 18:36:01 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55142-06; Thu, 17 Nov 2005 18:35:59 +0100 (CET) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id B1030164C20; Thu, 17 Nov 2005 18:35:59 +0100 (CET) Received: from enst.fr (dhcp164-248.enst.fr [137.194.164.248]) by infres.enst.fr (Postfix) with ESMTP id 6DAB713CBC; Thu, 17 Nov 2005 18:35:59 +0100 (MET) Message-ID: <437CBF7B.8080006@enst.fr> Date: Thu, 17 Nov 2005 18:35:55 +0100 From: badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [TLS] draft-badra-hajjeh-mtls-00.txt References: <17266.17941.160710.5249@fireball.kivinen.iki.fi> <437C56ED.1000203@enst.fr> <17276.25458.758901.927658@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at enst.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit Cc: Mohamad.Badra@enst.fr, tls@ietf.org, Ibrahim.Hajjeh@esrgroups.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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Tero Kivinen writes: > badra writes: > >> Moreover, MTLS is transparent to the application except that the >> application will connect locally to a specific port reserved for MTLS, >> and it is the MTLS's job to deliver data to the application on the other >> side. > > > So is usage is identical what secure shell is doing today. Hmmm, it provides the same services..., but there is no problem to borrow from SSH if we want really to add port forwarding to TLS. However, it is not the only way (plz see below). >> ... > > > Why the protocol needs to be on the TLS level? Why cannot it be simply > application level program running multiplexing protocol over normal > TLS channel? > > ... > >>> SSH2 fixed this including flow control to each channel separtely, i.e. >>> the receiving end of the channel can say that other end is only >>> allowed to send xx bytes of data, and then it must stop. When the >>> receiveing end managed to send those data forward to the final >>> destination, it would again say to sender ssh that now we are ready to >>> take xx bytes of more data and so on. >> >> Each connection will have local and destination ports and will be >> identified by that at the MTLS layer. So I don't see why it must be per >> stream? > > > Because you end up in problems if you do not do that. If you do not > have per stream flow control the only way to do flow control is to do > it for the whole TLS stream, which means all the connections are > blocked. > > For example say you have 2 connections run over the forwarded channel > one to IMAP and another to the SMTP. Now you start sending some huge > mail over the SMTP channel. The packets are trasmitted over the TLS > channel to the remote end, and the remote end transmits them over > local socket to the SMTP server. The SMTP server decides to start > doing virus check on the first 5 kilobytes of the email it has already > received (before reading the rest of the 100 MB email in). It stops > reading the local socket coming from the TLS server. After few more > kilobytes the local buffers in those sockets fill up and the writes to > the local socket connected to the SMTP server from the TLS server > blocks. The SMTP client is still sending data from the remote machine, > and that traffic is coming over the TLS stream. The TLS server do not > have any other way (as far as I know) to block that one stream of > traffic than to stop reading the whole TLS socket, i.e. stopping all > traffic going on the TLS stream. > > This also include other streams run over the same TLS connection, i.e. > the IMAP etc connections. Now if the SMTP server never wakes up, the > user has no other option than to discard the whole TLS connection > which includes other channels too. > > Because of this you DO need per stream flow control. There is no difference, in my opinion, to implement it at transport or application level. In the case of transport level, your server will listen on a specific port, and in the case of application one, your application need to connect to a port running over TLS. My point was to negotiate application types via a TLS extension and do not wait for the multiplexing protocol to do it once the handshake has been established. In other words, channel's opening is initialized implicitly during the handshake phase. However, I agree that stream flow control will be required. But I don't think we are going to use the secsh method: let's assume that for each packet send by the MTLS client through an arbitrary channel, an acknowledgement (if the server has no data to write) will be sent by the MTLS server to inform the client that MTLS server is ready to read more data (a litte bit of data is sent...). Certainly this is not sufficient if we don't control the maximum data length that the entity is ready to read. Accordingly, both entities should negotiate the maximum packet for each application they want to run and this during the Handshake phase. During the data exhange phase, the entity may be not ready to treat data with length larger than the maximum length negotiated during the Handshake phase. In this case, the acknowledgement packet must contain the appropriate length the receiver is ready to read. And if the local buffer fill up, no acknowlodgment packet will be send. Do you agree with that? (BTW, What will the server do if your scenario will happen in the case of an ordinary SMTP over TLS?) >> I agree that the draft needs more works. However, some mechanisms like >> preshared keys were also defined by several security protocols before >> they were defined by TLS. And I thing it is more appropriate to have a >> maximum number of security services using TLS. > > > I disagree here quite a lot. It would be trivial to write application > running over TLS channel that can do stream multiplexation and flow > control properly without any need to change or add anything to the TLS > level. > > As the applications using needs to be changed anyways (i.e. connect to > the local socket instead of the remote socket, i.e. mostly > configuration change) it does not really matter if they connect to the > MTLS server or some application running over TLS protected stream. I would like to say that the actual document is 00 version and it is not the only way to do data multiplexing over TLS. And it will not be a problem to choose between application and transport layers if we want really to integrate data multiplexing over TLS. Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 13:54:31 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecotz-0003lK-Lx; Thu, 17 Nov 2005 13:54:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecoty-0003ky-0Q for tls@megatron.ietf.org; Thu, 17 Nov 2005 13:54:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13941 for ; Thu, 17 Nov 2005 13:53:55 -0500 (EST) Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcpBd-0004ze-S2 for tls@ietf.org; Thu, 17 Nov 2005 14:12:47 -0500 Received: from [136.159.71.191] (helo=tau.local) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Ecotr2T3T-0005Wg; Thu, 17 Nov 2005 19:54:24 +0100 Received: by tau.local (Postfix, from userid 500) id 6A7B22F263; Thu, 17 Nov 2005 11:54:09 -0700 (MST) Date: Thu, 17 Nov 2005 11:54:09 -0700 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] Proposed TLS WG recharter Message-ID: <20051117185409.GA10828@tau.local> References: <20051117173101.B4A5122243A@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051117173101.B4A5122243A@laser.networkresonance.com> User-Agent: Mutt/1.4i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Thu, Nov 17, 2005 at 09:31:37AM -0800, Eric Rescorla wrote: > Here's my proposed TLS WG recharter. Any comments? > The primary goal of the WG is to publish a revision of TLS, version > 1.2, that removes the protocol's dependency on the MD5 and SHA-1 > digest algorithms, which have been either wholly or partially > compromised by recent research. Agreed. > The TLS WG will also work on adding major new cipher suites to TLS, > including Counter (CTR) and authenticated encryption modes. I don't quite agree to this: "Adding major new cipher suites" is just one of the options we have, and this certainly might turn out to be the best way to proceed. But another option would be to redefine existing ciphersuites to use CTR instead of CBC, depending on the protocol version (like the ciphersuites that now have "SHA" in their names, referring to SHA-1, may be using something different in TLS 1.2). The decision between such options must, obviously, be done while TLS 1.2 is being developed. But I thinks it's much too early to put the final decision into the charter. As for "authenticated encryption modes", all TLS 1.1 ciphersuites with encryption do provide authenticated encryption. There are other authenticated encryption modes that are not based on compositions like the ones in TLS 1.1 and which may be advantageous, and these are probably what you are referring to, but being "authenticated encryption modes" is not what is unique about them. Also it's not clear (to me) that we really need to put them into TLS, although this certainly is a reasonable option to consider. So here's a proposed replacement wording for the above sentence from your proposed charter: The TLS WG will also work on additional authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR), and may define major new cipher suites for TLS for this purpose. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 16:20:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr5I-0007yo-RI; Thu, 17 Nov 2005 16:14:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecr5H-0007xf-B9 for tls@megatron.ietf.org; Thu, 17 Nov 2005 16:14:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25269 for ; Thu, 17 Nov 2005 16:13:45 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcrMy-0002Sf-FS for tls@ietf.org; Thu, 17 Nov 2005 16:32:37 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id AECB41E8CD4; Thu, 17 Nov 2005 13:14:05 -0800 (PST) To: "Joshua Ball" Subject: Re: [TLS] Proposed TLS WG recharter References: <2E33960095B58E40A4D3345AB9F65EC1147DB4DF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> From: Eric Rescorla Date: Thu, 17 Nov 2005 13:14:05 -0800 In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1147DB4DF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> (Joshua Ball's message of "Thu, 17 Nov 2005 11:31:59 -0800") Message-ID: <864q6bt1sy.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org "Joshua Ball" writes: > WRT 1.2, I would also like to examine the possibility of designing a new > ciphersuite negotiation scheme, one that allows a more flexible approach > to choosing the various algorithms individually, rather than on a "per > ciphersuite" basis. That is to say, I am not against having ciphersuites > as strict definitions of support. In fact, I think it is crucial that we > maintain this notion to keep the explosion of possibilities down. But > this is no reason, IMHO, to not allow each individual variable (i.e. > symmetric cipher, key exchange, hashes, to be negotiated within a subset > of those possibilities required for compliance with the standard. > > Yes, this will require considerable design and implementation changes to > ciphersuite negotiation, but I think going forward it might very well be > worth it. I think it might be too early to make this a goal, but is this > something that we might look into? So, my position is that this charter doesn't exclude looking into this, but that it says that we would need to have a strong argument to actually move forward with it. Does that work for you? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 17 19:15:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctuP-0001t2-Pj; Thu, 17 Nov 2005 19:15:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EctuM-0001nd-JY; Thu, 17 Nov 2005 19:15:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06990; Thu, 17 Nov 2005 19:14:39 -0500 (EST) Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcuC5-0000YN-3r; Thu, 17 Nov 2005 19:33:34 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C9FAB1E8CD4; Thu, 17 Nov 2005 16:15:03 -0800 (PST) To: "Salowey, Joe" Subject: Re: [TLS] draft-salowey-tls-ticket-05.txt available References: <7210B31550AC934A8637D6619739CE6906409925@e2k-sea-xch2.sea-alpha.cisco.com> From: Eric Rescorla Date: Thu, 17 Nov 2005 16:15:03 -0800 In-Reply-To: <7210B31550AC934A8637D6619739CE6906409925@e2k-sea-xch2.sea-alpha.cisco.com> (Joe Salowey's message of "Thu, 17 Nov 2005 09:05:35 -0800") Message-ID: <86acg2stfc.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls-bounces@ietf.org, Rob Dugal , tls@ietf.org 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org "Salowey, Joe" writes: > I have been trying to catch up on this discussion. You are right, we > modified the draft to allow the server to send a SessionTicket handshake > message during session resume. It seems that this is an issue for DTLS > because you don't know if you should receive this message or not. If > this is the problem I can see two ways to fix this in the draft. > > In the first approach we can disallow the sending of a new session > ticket on session resume. > > The second approach would be to have the server send a session ticket > extension whenever it thought it might issue a ticket. If it did then > it would be required to include a session ticket handshake message in > the exchange (the message might have zero length if for some reason the > server decides not to send a ticket). > > This extension really should work with DTLS so I think we need to do one > of the above. I think the second approach would be better (the first one > is probably incomplete with the second one anyway). Always require the > server to send a sessionTicket extension if it may need to issue a > session ticket in the handshake. If the server includes the extension > then it MUST send a session ticket handshake message. The handshake > message may be 0 length if the server couldn't issue a ticket for some > reason. This works for me. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 21 11:46:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEod-0008OD-Sa; Mon, 21 Nov 2005 11:46:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeEob-0008No-LV for tls@megatron.ietf.org; Mon, 21 Nov 2005 11:46:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13618 for ; Mon, 21 Nov 2005 11:46:11 -0500 (EST) Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeF73-0000JT-QR for tls@ietf.org; Mon, 21 Nov 2005 12:05:56 -0500 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id 6975A260; Mon, 21 Nov 2005 17:46:43 +0100 (CET) Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32748-05; Mon, 21 Nov 2005 17:45:45 +0100 (CET) Received: from infres.enst.fr (infres-192.enst.fr [137.194.192.1]) by smtp2.enst.fr (Postfix) with ESMTP id 1370F1C5; Mon, 21 Nov 2005 17:36:31 +0100 (CET) Received: from enst.fr (dhcp164-248.enst.fr [137.194.164.248]) by infres.enst.fr (Postfix) with ESMTP id B670713CC0; Mon, 21 Nov 2005 17:36:30 +0100 (MET) Message-ID: <4381F787.5000708@enst.fr> Date: Mon, 21 Nov 2005 17:36:23 +0100 From: badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [TLS] draft-badra-hajjeh-mtls-00.txt References: <17266.17941.160710.5249@fireball.kivinen.iki.fi> <437C56ED.1000203@enst.fr> <17276.25458.758901.927658@fireball.kivinen.iki.fi> <437CBF7B.8080006@enst.fr> <17277.41795.506866.445122@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at enst.fr X-Spam-Score: 2.0 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Mohamad.Badra@enst.fr, tls@ietf.org, Ibrahim.Hajjeh@esrgroups.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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Tero Kivinen writes: > badra writes: > >> ...There is no difference, in my opinion, to implement it at >> transport or application level. >> In the case of transport level, your server will listen on a specific >> port, and in the case of application one, your application need to >> connect to a port running over TLS. >> > > Big difference is that if you do it on the TLS level you need to make > TLS extensions. If you do it on the application layer, you simply need > to define protocol which can be used over any channel (or simply reuse > existing protocol, like secure shell connection layer). I don't think that system administrators would like to maintain two security protocols up to date if TLS alone can offers these security services alone. Moreover, ref3546 was defined to be used and to define new extension features. However, the document needs to re-use some ssh-connexion's features (which are tcp multiplexing functions) to manage window size, etc. The extension defined in the document is to be more clarified and it is defined to negotiate what the client and the server do support as stream types. If it is defined at the application layer, I have to define some signalling and error messages and to send them each time they want to open a new connexion or to verify if the other end support an arbitrary stream. In this way the link is established between the draft and TLS. However, the window size could be initialized by each side by adding its value to the extension 's fields, and for each new connexion, a message is sent to initialize its window sender. The window size's control as defined in "ssh-connexion" may be used. However, I think the window size is able to grow up due to (implicit or explicit) acknowledgment messages (if I am correct). In this case, for each packet an acknowledgment will tell the sender about the next packet size to be sent to the receiver. And I think it is not related to the bandwidth, it is related to, among others, the socket's memory length. >> ... >> > The question is do we want to integrate data multiplexing to TLS. I do > not see any point of doing that. The pros and cons may not have their end. But I would like to resume that: - ssh-connexion is related to SSH - mtls is based on TLS Extensions so we can optionally negotiate it. The actual document's version required more work to do. - define a port forwarding at the transport layer could be more advantageous because of reducing the definition and the use of signaling and error messages. - some property solutions doing VPN by running everything through HTTP whereas SSH does it over reliable transport protocol. It could be possible to have a comon mechanism that allows port forwarding over TLS/TCP as long as over DTLS/UDP (SSH runs over reliable transport), without re-write the applications. Best regards, _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 21 12:19:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFG7-0005hT-Hy; Mon, 21 Nov 2005 12:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeFG6-0005h2-2L for tls@megatron.ietf.org; Mon, 21 Nov 2005 12:15:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15964 for ; Mon, 21 Nov 2005 12:14:36 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeFYZ-0001H7-DO for tls@ietf.org; Mon, 21 Nov 2005 12:34:20 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jALHC1wA000592; Mon, 21 Nov 2005 19:12:01 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 19:15:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 19:15:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] Proposed TLS WG recharter Date: Mon, 21 Nov 2005 19:15:01 +0200 Message-ID: Thread-Topic: [TLS] Proposed TLS WG recharter Thread-Index: AcXrvCWCvo+s+PhaTNqUAcmN78ltmQDAmlbQ To: , X-OriginalArrivalTime: 21 Nov 2005 17:15:01.0886 (UTC) FILETIME=[1B9549E0:01C5EEBF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: quoted-printable 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Joshua,=20 I'd like to better understand what would be the benefit being=20 sought here? A TLS management interface can already allow the administrator to e.g. choose the encryption algorithm and=20 hash individually, and this is mostly a user interface issue. The only case where this fails is when no ciphersuite number has=20 been assigned for the combination the administrator wants. But=20 has this been found to be a problem in practice?=20 (My guess would be no -- it it were a big problem, someone would have taken the trouble to get the numbers. And not all of the combinations make that much sense anyway.) Best regards, Pasi > -----Original Message----- > From: Eric Rescorla > Sent: 17 November, 2005 23:14 > To: Joshua Ball > Cc: tls@ietf.org > Subject: Re: [TLS] Proposed TLS WG recharter >=20 > "Joshua Ball" writes: > > > WRT 1.2, I would also like to examine the possibility of > > designing a new ciphersuite negotiation scheme, one that allows > > a more flexible approach to choosing the various algorithms > > individually, rather than on a "per ciphersuite" basis. That is > > to say, I am not against having ciphersuites as strict > > definitions of support. In fact, I think it is crucial that we > > maintain this notion to keep the explosion of possibilities > > down. But this is no reason, IMHO, to not allow each individual > > variable (i.e. symmetric cipher, key exchange, hashes, to be > > negotiated within a subset of those possibilities required for > > compliance with the standard. > > > > Yes, this will require considerable design and implementation > > changes to ciphersuite negotiation, but I think going forward it > > might very well be worth it. I think it might be too early to > > make this a goal, but is this something that we might look into? >=20 > So, my position is that this charter doesn't exclude looking > into this, but that it says that we would need to have a strong > argument to actually move forward with it. Does that work for > you? >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 22 09:20:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZ0a-0004i9-BT; Tue, 22 Nov 2005 09:20:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeZ0Y-0004hQ-8q; Tue, 22 Nov 2005 09:20:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22164; Tue, 22 Nov 2005 09:19:50 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeZJC-0005hw-P7; Tue, 22 Nov 2005 09:39:48 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 9EB021006B055; Tue, 22 Nov 2005 09:20:11 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22007-26; Tue, 22 Nov 2005 09:20:10 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 14FB31006B054; Tue, 22 Nov 2005 09:20:10 -0500 (EST) To: Eric Rescorla MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Rob Dugal Date: Tue, 22 Nov 2005 09:20:48 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/22/2005 09:20:48 AM, Serialize complete at 11/22/2005 09:20:48 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tls-bounces@ietf.org, tls@ietf.org Subject: [TLS] compression in DTLS X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1810336756==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1810336756== Content-Type: multipart/alternative; boundary="=_alternative 004EEACC852570C1_=" This is a multipart message in MIME format. --=_alternative 004EEACC852570C1_= Content-Type: text/plain; charset="US-ASCII" How is record compression supported in DTLS ? I don't have a lot of experience with compression but I have integrated RFC3749 and RFC3943 into our SSL product. Based on what I've seen, if records are delivered out of sequence or lost then I don't think it will be possible to decompress records unless the decompressor assumes that the compression history has been reset for each record. This and the fact that datagrams are going to be quite small will probably mean that most records will not compress very much. Also, in TLS a compression which results in expansion of the input is ok so long as the expansion is no more than 1024 bytes. I've seen this occur with compression of random data. In DTLS this means the compressed data could be much larger than the MTU so what does DTLS do? For handshake messages it could refragment the content into smaller pieces and try again until the output is < MTU. Of course most handshake mesages will not be compressed unless the session is re-negotiated. But what about application data? You cannot re-fragment application data. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com --=_alternative 004EEACC852570C1_= Content-Type: text/html; charset="US-ASCII"
How is record compression supported in DTLS ?

I don't have a lot of experience with compression but I have integrated RFC3749 and RFC3943 into our SSL product.  Based on what I've seen, if records are delivered out of sequence or lost then I don't think it will be possible to decompress records unless the decompressor assumes that the compression history has been reset for each record. This and the fact that datagrams are going to be quite small will probably mean that most records
will not compress very much.

Also, in TLS a compression which results in expansion of the input is ok so long as the expansion is no more than 1024 bytes.
I've seen this occur with compression of random data.
In DTLS this means the compressed data could be much larger than the MTU so what does DTLS do?
For handshake messages it could refragment the content into smaller pieces and try again until the output is < MTU.
Of course most handshake mesages will not be compressed unless the session is re-negotiated.
But what about application data? You cannot re-fragment application data.


-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com --=_alternative 004EEACC852570C1_=-- --===============1810336756== 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 --===============1810336756==-- From tls-bounces@lists.ietf.org Wed Nov 23 09:58:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew4k-0002RN-6z; Wed, 23 Nov 2005 09:58:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eew4g-0002Qm-Op for tls@megatron.ietf.org; Wed, 23 Nov 2005 09:58:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11559 for ; Wed, 23 Nov 2005 09:57:38 -0500 (EST) Received: from [216.183.86.37] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EewNY-0006V4-8e for tls@ietf.org; Wed, 23 Nov 2005 10:17:49 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 3FBDA100233D4; Wed, 23 Nov 2005 09:58:02 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09367-13; Wed, 23 Nov 2005 09:58:00 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id DC3AC1006B05A; Wed, 23 Nov 2005 09:58:00 -0500 (EST) Received: from ce00182.certicom.com ([10.0.2.59]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2005112309583801-8173 ; Wed, 23 Nov 2005 09:58:38 -0500 Received: from ce00182.certicom.com (localhost.certicom.com [127.0.0.1]) by ce00182.certicom.com (8.13.3/8.13.3) with ESMTP id jANEvx1m073692; Wed, 23 Nov 2005 09:57:59 -0500 (EST) (envelope-from bminard@ce00182.certicom.com) Received: (from bminard@localhost) by ce00182.certicom.com (8.13.3/8.13.3/Submit) id jANEvtu6073691; Wed, 23 Nov 2005 09:57:55 -0500 (EST) (envelope-from bminard) Date: Wed, 23 Nov 2005 09:57:55 -0500 From: Brian Minard To: Eric Rescorla Subject: Re: [TLS] Proposed TLS WG recharter Message-ID: <20051123145755.GD84618@certicom.com> References: <20051117173101.B4A5122243A@laser.networkresonance.com> Mime-Version: 1.0 In-Reply-To: <20051117173101.B4A5122243A@laser.networkresonance.com> User-Agent: Mutt/1.4.2.1i X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/23/2005 09:58:38 AM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 11/23/2005 09:58:39 AM, Serialize complete at 11/23/2005 09:58:39 AM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Thu, Nov 17, 2005 at 09:31:37AM -0800, Eric Rescorla wrote: > The primary goal of the WG is to publish a revision of TLS, version > 1.2, that removes the protocol's dependency on the MD5 and SHA-1 > digest algorithms, which have been either wholly or partially > compromised by recent research. The TLS WG will also work on > adding major new cipher suites to TLS, including Counter (CTR) and > authenticated encryption modes. In the preparation of TLS 1.2, the > Working Group will attempt to avoid gratuitous changes to TLS 1.1. Can you comment on your position WRT introducing multiple PRFs? Clearly the proposed wording includes the rework of the existing PRF, but it's an open question whether the scope of the charter includes provision for more than one hash algorithm migration (i.e., from SHA-1/MD5 to SHA-256 to some other algorithm). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 28 13:27:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgniR-00049W-2l; Mon, 28 Nov 2005 13:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgniO-00047s-Or for tls@megatron.ietf.org; Mon, 28 Nov 2005 13:27:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15077 for ; Mon, 28 Nov 2005 13:26:17 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ego2G-0000f4-KK for tls@ietf.org; Mon, 28 Nov 2005 13:47:36 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id B7FC222244D for ; Mon, 28 Nov 2005 10:26:00 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 28 Nov 2005 10:26:37 -0800 From: Eric Rescorla Message-Id: <20051128182600.B7FC222244D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [TLS] Moving forward on draft-ietf-tls-srp 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Folks, draft-ietf-tls-srp has been hanging around the WG for quite some time and I'd like to get a sense of the WG on advancement. The general sense of the WG at YVR was that we should be working to move it forward somehow, but it wasn't clear how. The big question for me is whether it should be Informational or Proposed. The issue, of course, is the uncertain IPR situation. So, I'd like to get comments on: 1. Should this document advance? 2. Should we be advancing it as Proposed or Informational? As a secondary considertion, I note that the current version has the unattractive property that the client has to take extreme care about what groups it accepts because a properly chosen server group may allow a fake server to extract information about the user's password. I'm not familiar enough with the PAKE literature to know if this is an essential feature of PAKE protocols. If not, should we be considering a different base cryptographic protocol? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 28 14:03:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgoHr-0001Lt-Rf; Mon, 28 Nov 2005 14:03:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgoHq-0001Lo-2t for tls@megatron.ietf.org; Mon, 28 Nov 2005 14:03:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21075 for ; Mon, 28 Nov 2005 14:02:54 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egobk-0002at-MD for tls@ietf.org; Mon, 28 Nov 2005 14:24:14 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id C9E7622244D for ; Mon, 28 Nov 2005 11:02:50 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 28 Nov 2005 11:03:27 -0800 From: Eric Rescorla Message-Id: <20051128190250.C9E7622244D@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I'd like to get some working group discussion on whether there's interest in pursuing the GOST cipher suites draft-chudov-cryptopro-cptls-02.txt as a working group document. In your responses, please indicate: 1. Whether you would like to see this as a WG document. 2. Whether you are willing to commit to reviewing it in future. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 28 14:28:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgogH-0007TB-EP; Mon, 28 Nov 2005 14:28:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgogG-0007T6-DV for tls@megatron.ietf.org; Mon, 28 Nov 2005 14:28:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23708 for ; Mon, 28 Nov 2005 14:28:08 -0500 (EST) Received: from agp.stanford.edu ([171.67.73.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egp09-0003QE-Vo for tls@ietf.org; Mon, 28 Nov 2005 14:49:28 -0500 Received: from xenon.stanford.edu ([171.64.66.201]) by agp.stanford.edu with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.43) id 1Egog4-0002Ez-Ar; Mon, 28 Nov 2005 11:28:40 -0800 Received: from tjw (helo=localhost) by xenon.Stanford.EDU with local-esmtp (Exim 4.50) id 1Egog4-0008O2-0p; Mon, 28 Nov 2005 11:28:40 -0800 Date: Mon, 28 Nov 2005 11:28:40 -0800 (PST) From: Thomas Wu To: Eric Rescorla Subject: Re: [TLS] Moving forward on draft-ietf-tls-srp In-Reply-To: <20051128182600.B7FC222244D@laser.networkresonance.com> Message-ID: References: <20051128182600.B7FC222244D@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Mon, 28 Nov 2005, Eric Rescorla wrote: > > So, I'd like to get comments on: > 1. Should this document advance? Yes > 2. Should we be advancing it as Proposed or Informational? I support advancing it as Proposed, given that its multiple interoperating implementations meet the criteria for "Licensing Requirements to Advance Standards Track IETF Documents" as described in RFC 3979, Section 10. > As a secondary considertion, I note that the current version has > the unattractive property that the client has to take extreme > care about what groups it accepts because a properly chosen server group > may allow a fake server to extract information about the > user's password. I'm not familiar enough with the PAKE literature > to know if this is an essential feature of PAKE protocols. If The client must avoid "trapdoor" groups that allow easier-than-normal computation of discrete log via SNFS instead of GNFS. This applies to any password protocol whose security is based on the difficulty of the discrete log problem, so it would not just be SRP, but DH-EKE, SPEKE, AMP, etc. The vast majority of SRP implementations check the received parameters against the groups listed in Appendix A, which seems to work quite well in practice. > -Ekr Tom -- Tom Wu http://www-cs-students.stanford.edu/~tjw/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 28 14:51:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egp1l-0005sV-8g; Mon, 28 Nov 2005 14:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egp1j-0005sJ-8Z for tls@megatron.ietf.org; Mon, 28 Nov 2005 14:51:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26143 for ; Mon, 28 Nov 2005 14:50:19 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EgpLe-00047w-BY for tls@ietf.org; Mon, 28 Nov 2005 15:11:39 -0500 Received: (qmail 2768 invoked by uid 0); 28 Nov 2005 19:50:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.40.79) by woodstock.binhost.com with SMTP; 28 Nov 2005 19:50:55 -0000 Message-Id: <7.0.0.10.2.20051128144717.02c1fc78@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Mon, 28 Nov 2005 14:49:04 -0500 To: Eric Rescorla , tls@ietf.org From: Russ Housley Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt In-Reply-To: <20051128190250.C9E7622244D@laser.networkresonance.com> References: <20051128190250.C9E7622244D@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org As written, the document needs the PRF agility that was discussed for TLS 1.2. So, I would think that this document would be a good candidate for a ciphersuite using the non-mandatory-to-implement PRF. Having one in and while developing TLS 1.2 sounds very desirable to me. Russ At 02:03 PM 11/28/2005, Eric Rescorla wrote: >I'd like to get some working group discussion on whether >there's interest in pursuing the GOST cipher suites >draft-chudov-cryptopro-cptls-02.txt as a working group >document. In your responses, please indicate: > >1. Whether you would like to see this as a WG document. >2. Whether you are willing to commit to reviewing it in > future. > >-Ekr > > > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 09:39:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6do-0003dN-F7; Tue, 29 Nov 2005 09:39:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh6dm-0003dH-In for tls@megatron.ietf.org; Tue, 29 Nov 2005 09:39:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12884 for ; Tue, 29 Nov 2005 09:38:46 -0500 (EST) Received: from cryptocom.ipmce.ru ([194.85.185.72] helo=mx.cryptocom.ru) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh6xr-0005jd-DP for tls@ietf.org; Tue, 29 Nov 2005 10:00:16 -0500 Received: by mx.cryptocom.ru (Postfix, from userid 500) id AF399F6EB; Tue, 29 Nov 2005 17:39:04 +0300 (MSK) Received: from manul.lan.cryptocom.ru (manul.lan.cryptocom.ru [10.51.17.211]) by mx.cryptocom.ru (Postfix) with ESMTP id 28513F6D3; Tue, 29 Nov 2005 17:39:04 +0300 (MSK) Date: Tue, 29 Nov 2005 17:40:25 +0300 (MSK) From: Dmitry Belyavsky X-X-Sender: beldmit@manul.lan.cryptocom.ru To: Russ Housley Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt In-Reply-To: <7.0.0.10.2.20051128144717.02c1fc78@vigilsec.com> Message-ID: References: <20051128190250.C9E7622244D@laser.networkresonance.com> <7.0.0.10.2.20051128144717.02c1fc78@vigilsec.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Greetings! On Mon, 28 Nov 2005, Russ Housley wrote: > As written, the document needs the PRF agility that was discussed for TLS 1.2. > So, I would think that this document would be a good candidate for a > ciphersuite using the non-mandatory-to-implement PRF. Having one in and while > developing TLS 1.2 sounds very desirable to me. What can you say about section 3.3 of draft-chudov-cryptopro-cptls-02.txt? It describes a non-reasoned aberration from RFC 2246: ==================== For all four cipher suites, the use of MAC is slighttly different from the one, described in section 6.2.3.1 of [TLS]. In [TLS], MAC is calculated from the following data: MACed_data[seq_num] = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment; These cipher suites use the same input for first record, but for each next record the input from all previous records is concatenated: MACed_data[0] + ... + MACed_data[n] ==================== -- SY, Dmitry Belyavsky (ICQ UIN 11116575) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 12:31:48 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9KW-0002LV-O2; Tue, 29 Nov 2005 12:31:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9KV-0002Iz-3O for tls@megatron.ietf.org; Tue, 29 Nov 2005 12:31:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08900 for ; Tue, 29 Nov 2005 12:31:01 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9eZ-0004Xx-9y for tls@ietf.org; Tue, 29 Nov 2005 12:52:34 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 29 Nov 2005 09:31:34 -0800 X-IronPort-AV: i="3.97,389,1125903600"; d="scan'208"; a="679338824:sNHT28636406" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jATHVVs2011014; Tue, 29 Nov 2005 09:31:32 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 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] Proposed TLS WG recharter Date: Tue, 29 Nov 2005 09:37:23 -0800 Message-ID: <7210B31550AC934A8637D6619739CE69064A775D@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [TLS] Proposed TLS WG recharter Thread-Index: AcXrvCWCvo+s+PhaTNqUAcmN78ltmQDAmlbQAZKcTSA= From: "Salowey, Joe" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org There could be advantage in allowing the authenticated key exchange to be negotiated separately from record layer protection (integrity and encryption). The dependencies between the two are fairly well understood and it would allow new record layer protection schemes to be used by different key exchange mechanisms and vice versa without having to define new ciphersuites for every combination. =20 I would rather not see more fine grained negotiation especially in the record layer protection since the dependencies are not as well defined. For example I think cipher and MAC algorithms are often analyzed together and varying them independently can have unexpected results.=20 Joe =20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Monday, November 21, 2005 9:15 AM > To: ekr@networkresonance.com; Joshua.Ball@microsoft.com > Cc: tls@ietf.org > Subject: RE: [TLS] Proposed TLS WG recharter >=20 >=20 > Joshua,=20 >=20 > I'd like to better understand what would be the benefit being=20 > sought here? A TLS management interface can already allow=20 > the administrator to e.g. choose the encryption algorithm and=20 > hash individually, and this is mostly a user interface issue. >=20 > The only case where this fails is when no ciphersuite number=20 > has been assigned for the combination the administrator=20 > wants. But has this been found to be a problem in practice?=20 >=20 > (My guess would be no -- it it were a big problem, someone=20 > would have taken the trouble to get the numbers. And not all=20 > of the combinations make that much sense anyway.) >=20 > Best regards, > Pasi >=20 > > -----Original Message----- > > From: Eric Rescorla > > Sent: 17 November, 2005 23:14 > > To: Joshua Ball > > Cc: tls@ietf.org > > Subject: Re: [TLS] Proposed TLS WG recharter > >=20 > > "Joshua Ball" writes: > > > > > WRT 1.2, I would also like to examine the possibility of=20 > designing a=20 > > > new ciphersuite negotiation scheme, one that allows a=20 > more flexible=20 > > > approach to choosing the various algorithms individually, rather=20 > > > than on a "per ciphersuite" basis. That is to say, I am=20 > not against=20 > > > having ciphersuites as strict definitions of support. In fact, I=20 > > > think it is crucial that we maintain this notion to keep the=20 > > > explosion of possibilities down. But this is no reason,=20 > IMHO, to not=20 > > > allow each individual variable (i.e. symmetric cipher, key=20 > > > exchange, hashes, to be negotiated within a subset of those=20 > > > possibilities required for compliance with the standard. > > > > > > Yes, this will require considerable design and implementation=20 > > > changes to ciphersuite negotiation, but I think going forward it=20 > > > might very well be worth it. I think it might be too=20 > early to make=20 > > > this a goal, but is this something that we might look into? > >=20 > > So, my position is that this charter doesn't exclude looking into=20 > > this, but that it says that we would need to have a strong=20 > argument to=20 > > actually move forward with it. Does that work for you? > >=20 > > -Ekr >=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 Tue Nov 29 12:50:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9cK-0000d5-CB; Tue, 29 Nov 2005 12:50:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eh9cI-0000ZS-P9 for tls@megatron.ietf.org; Tue, 29 Nov 2005 12:50:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11563 for ; Tue, 29 Nov 2005 12:49:25 -0500 (EST) Received: from mx2.cryptopro.ru ([213.59.158.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eh9wP-0005HA-7r for tls@ietf.org; Tue, 29 Nov 2005 13:10:58 -0500 Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Nov 2005 20:52:30 +0300 Message-ID: <055101c5f50d$ab2b78a0$0644a8c0@cp.ru> From: "Gregory S. Chudov" To: "Dmitry Belyavsky" , References: <20051128190250.C9E7622244D@laser.networkresonance.com><7.0.0.10.2.20051128144717.02c1fc78@vigilsec.com> Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt Date: Tue, 29 Nov 2005 20:52:30 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-OriginalArrivalTime: 29 Nov 2005 17:52:30.0578 (UTC) FILETIME=[AB367520:01C5F50D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Greetings. I agree that it could be useful to add a paragraph, containing the reasoning for this. IMIT_GOST28147 is not an HMAC, it is basicly a form of GOST28147 cipher. To be robust to attacks based on timing and EMI analysis, one symmetric key should not be used for large quantities of plaintext, so the key meshing algorithm from draft-popov-cryptopro-cpalgs-04.txt is applied. This "abberation" can be rephrased in a following way: MACed_data[seq_num] is MACed, using the cipher state, produced by processing the previous record. Good luck! ----- Original Message ----- From: "Dmitry Belyavsky" To: "Russ Housley" Cc: Sent: Tuesday, November 29, 2005 5:40 PM Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt > Greetings! > ... > > What can you say about section 3.3 of draft-chudov-cryptopro-cptls-02.txt? > It describes a non-reasoned aberration from RFC 2246: > > ==================== > For all four cipher suites, the use of MAC is slighttly different > from the one, described in section 6.2.3.1 of [TLS]. In [TLS], MAC > is calculated from the following data: > > MACed_data[seq_num] = seq_num + > TLSCompressed.type + > TLSCompressed.version + > TLSCompressed.length + > TLSCompressed.fragment; > > These cipher suites use the same input for first record, but for each > next record the input from all previous records is concatenated: > > MACed_data[0] + ... + MACed_data[n] > ==================== > > > -- > SY, Dmitry Belyavsky (ICQ UIN 11116575) > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 13:29:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAEk-0005bL-N6; Tue, 29 Nov 2005 13:29:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhAEj-0005bD-I7 for tls@megatron.ietf.org; Tue, 29 Nov 2005 13:29:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16506 for ; Tue, 29 Nov 2005 13:29:07 -0500 (EST) Received: from [66.199.92.10] (helo=fallback.trevp.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhAYo-0006jy-3k for tls@ietf.org; Tue, 29 Nov 2005 13:50:41 -0500 Received: from [127.0.0.1] (localhost.trevp.net [127.0.0.1]) by fallback.trevp.net (Postfix) with ESMTP id BE1ABA89392 for ; Tue, 29 Nov 2005 10:32:38 -0800 (PST) Message-ID: <438C9EC6.3000300@trevp.net> Date: Tue, 29 Nov 2005 10:32:38 -0800 From: Trevor Perrin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Moving forward on draft-ietf-tls-srp References: <20051128182600.B7FC222244D@laser.networkresonance.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Thomas Wu wrote: > On Mon, 28 Nov 2005, Eric Rescorla wrote: > >> >> So, I'd like to get comments on: >> 1. Should this document advance? > > > Yes > >> 2. Should we be advancing it as Proposed or Informational? > > > I support advancing it as Proposed +1, of course, from another of the authors. For those not at Vancouver, the TLS/SRP slides might be a useful refresher: http://trevp.net/tls_srp/ietf_tlssrp.ppt At the IETF meeting, the authors also invited technical review and comments, and I'll repeat that invitation here. The draft is essentially done (from our point of view), so now would be a great time for people to read it and send us feedback. One comment we've already noted is that the draft should use TBD-IANA for its numbers. Trevor _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 14:10:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhArr-0008Ha-ML; Tue, 29 Nov 2005 14:10:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhArq-0008HV-Ud for tls@megatron.ietf.org; Tue, 29 Nov 2005 14:10:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21757 for ; Tue, 29 Nov 2005 14:09:34 -0500 (EST) Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBBx-0008Ih-3N for tls@ietf.org; Tue, 29 Nov 2005 14:31:07 -0500 Received: from champagne.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id jATJ9vi08339; Tue, 29 Nov 2005 20:09:57 +0100 (MET) Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/2.4); Tue, 29 Nov 2005 20:09:57 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA03069; Tue, 29 Nov 2005 20:09:56 +0100 (MET) Message-ID: <438CA784.5090205@edelweb.fr> Date: Tue, 29 Nov 2005 20:09:56 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Trevor Perrin Subject: Re: [TLS] Moving forward on draft-ietf-tls-srp References: <20051128182600.B7FC222244D@laser.networkresonance.com> <438C9EC6.3000300@trevp.net> In-Reply-To: <438C9EC6.3000300@trevp.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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: , Content-Type: multipart/mixed; boundary="===============0752287124==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0752287124== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020503050309000002000700" This is a cryptographically signed message in MIME format. --------------ms020503050309000002000700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit > >> >> >> I support advancing it as Proposed > > +1, of course, from another of the authors. +1 from another authors' site. > > For those not at Vancouver, the TLS/SRP slides might be a useful > refresher: > > http://trevp.net/tls_srp/ietf_tlssrp.ppt > As already mentioned by Tom, client site validation of the group parameters can be easily done by comparing it to a fixed list in the client. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms020503050309000002000700 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDUxMTI5MTkwOTU2WjAjBgkqhkiG9w0B CQQxFgQUG9q+hlKhlB2ajP42oR5W3JAio2EwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAJuYkfrzXrN5mvL90 xgjfrQkPszialiSnO3HdYKtdLoUl5tqaWNuzlTAMHTlFbwOhl6woxdm+S74mgImVwRPi8t0w YBfBbpuakTnCc/Y44HcUNah56Js2lJfANRoKvV6FP83VFxhOkffh5+OdD7JOnuHT/a3RintS A1Hy2bO7Qe8AAAAAAAA= --------------ms020503050309000002000700-- --===============0752287124== 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 --===============0752287124==-- From tls-bounces@lists.ietf.org Tue Nov 29 14:23:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB4Q-0001Ek-7o; Tue, 29 Nov 2005 14:23:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB4O-0001Eb-TU for tls@megatron.ietf.org; Tue, 29 Nov 2005 14:23:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23142 for ; Tue, 29 Nov 2005 14:22:32 -0500 (EST) Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBOW-0000Fh-A6 for tls@ietf.org; Tue, 29 Nov 2005 14:44:05 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 5C5C422243A for ; Tue, 29 Nov 2005 11:22:21 -0800 (PST) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Tue, 29 Nov 2005 11:22:58 -0800 From: Eric Rescorla Message-Id: <20051129192221.5C5C422243A@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Subject: [TLS] Closing on TLS Charter 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org I think we pretty much have consensus on the following charter. If anyone objects, or I missed your input, please speak up before Mon Dec 7: -Ekr Goals and Milestones: The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS, version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. In the preparation of TLS 1.2, the Working Group will attempt to avoid gratuitous changes to TLS 1.1. Goals and Milestones ------------------- Done Agreement on charter and issues in current draft. Done Final draft for Secure Transport Layer Protocol ('STLP') Done Working group 'Last Call' Done Submit to IESG for consideration as a Proposed Standard. Done First revised draft of TLS specification 3/06 First draft of TLS 1.2 specification, including CTR mode cipher suites 3/06 First draft of specification for cipher suites with combined encryption/authentication modes 12/06 Submit specification of TLS 1.2 specification to IESG for publication as Proposed Standard. 12/06 Submit specification of cipher suites with combined encryption/authentication modes to IESG for publication, with at least one of these suites to be Proposed Standard. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 14:27:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB8s-00042G-QY; Tue, 29 Nov 2005 14:27:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhB8r-0003xq-6o for tls@megatron.ietf.org; Tue, 29 Nov 2005 14:27:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23486 for ; Tue, 29 Nov 2005 14:27:08 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhBSy-0000Nr-79 for tls@ietf.org; Tue, 29 Nov 2005 14:48:41 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 0C54F17058; Tue, 29 Nov 2005 11:34:32 -0800 (PST) To: Peter Sylvester Subject: Re: [TLS] Moving forward on draft-ietf-tls-srp References: <20051128182600.B7FC222244D@laser.networkresonance.com> <438C9EC6.3000300@trevp.net> <438CA784.5090205@edelweb.fr> From: Eric Rescorla Date: Tue, 29 Nov 2005 11:34:31 -0800 In-Reply-To: <438CA784.5090205@edelweb.fr> (Peter Sylvester's message of "Tue, 29 Nov 2005 20:09:56 +0100") Message-ID: <861x0z6yew.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Peter Sylvester writes: >> For those not at Vancouver, the TLS/SRP slides might be a useful >> refresher: >> >> http://trevp.net/tls_srp/ietf_tlssrp.ppt >> > As already mentioned by Tom, client site validation of the group > parameters can be easily done > by comparing it to a fixed list in the client. That's not really validation: it's effectively a fixed set of system parameters--which isn't something, for instance, that the current DH cipher suites have. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 16:08:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCib-0007y6-Nq; Tue, 29 Nov 2005 16:08:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EchYA-0002rK-4t for tls@megatron.ietf.org; Thu, 17 Nov 2005 06:03:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14301 for ; Thu, 17 Nov 2005 06:02:56 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Echpj-00053R-Ii for tls@ietf.org; Thu, 17 Nov 2005 06:21:43 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAHB3E89029530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2005 13:03:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAHB3Els027451; Thu, 17 Nov 2005 13:03:14 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17276.25458.758901.927658@fireball.kivinen.iki.fi> Date: Thu, 17 Nov 2005 13:03:14 +0200 From: Tero Kivinen To: badra Subject: Re: [TLS] draft-badra-hajjeh-mtls-00.txt In-Reply-To: <437C56ED.1000203@enst.fr> References: <17266.17941.160710.5249@fireball.kivinen.iki.fi> <437C56ED.1000203@enst.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 17 min X-Total-Time: 19 min X-Spam-Score: 2.0 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Nov 2005 16:08:48 -0500 Cc: Mohamad.Badra@enst.fr, tls@ietf.org, Ibrahim.Hajjeh@esrgroups.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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org badra writes: > Adding an extension to TLS is not really a modification, particularly > when the machine-state of the protocol, the handshake and the record > protocols remains unchangeable. > Moreover, MTLS is transparent to the application except that the > application will connect locally to a specific port reserved for MTLS, > and it is the MTLS's job to deliver data to the application on the other > side. So is usage is identical what secure shell is doing today. > I read the secsh draft and AFAIK, it is a set of signalling messages > exchanged between the multiplexing processes over the SSH session. In > the MTLS case, the negotiation is done during the handshake phase, which > reduces the chance to the entities to say more about their voluntaries > concerning some features such as packet size. Nevertheless, it could be > possible to add some signaling messages at the MTLS layer to allow more > options for the entities. Why the protocol needs to be on the TLS level? Why cannot it be simply application level program running multiplexing protocol over normal TLS channel? > Once the Handshake phase has been established, actual version does not > allow creating or cancelling those forwarding applications. Because it > is related to the TLS Extensions in creating and canceling new > extensions (rfc 3546). Concerning the multi-mail, each mail will be sent > aver a different local port, so each mail will be encapsulated in mtls > packets, which are distinguished by the local port. So it allows multiple local ports over one remote ports even after the handshake. That was not really clear from the document. > >SSH2 fixed this including flow control to each channel separtely, i.e. > >the receiving end of the channel can say that other end is only > >allowed to send xx bytes of data, and then it must stop. When the > >receiveing end managed to send those data forward to the final > >destination, it would again say to sender ssh that now we are ready to > >take xx bytes of more data and so on. > > Each connection will have local and destination ports and will be > identified by that at the MTLS layer. So I don't see why it must be per > stream? Because you end up in problems if you do not do that. If you do not have per stream flow control the only way to do flow control is to do it for the whole TLS stream, which means all the connections are blocked. For example say you have 2 connections run over the forwarded channel one to IMAP and another to the SMTP. Now you start sending some huge mail over the SMTP channel. The packets are trasmitted over the TLS channel to the remote end, and the remote end transmits them over local socket to the SMTP server. The SMTP server decides to start doing virus check on the first 5 kilobytes of the email it has already received (before reading the rest of the 100 MB email in). It stops reading the local socket coming from the TLS server. After few more kilobytes the local buffers in those sockets fill up and the writes to the local socket connected to the SMTP server from the TLS server blocks. The SMTP client is still sending data from the remote machine, and that traffic is coming over the TLS stream. The TLS server do not have any other way (as far as I know) to block that one stream of traffic than to stop reading the whole TLS socket, i.e. stopping all traffic going on the TLS stream. This also include other streams run over the same TLS connection, i.e. the IMAP etc connections. Now if the SMTP server never wakes up, the user has no other option than to discard the whole TLS connection which includes other channels too. Because of this you DO need per stream flow control. > I agree that the draft needs more works. However, some mechanisms like > preshared keys were also defined by several security protocols before > they were defined by TLS. And I thing it is more appropriate to have a > maximum number of security services using TLS. I disagree here quite a lot. It would be trivial to write application running over TLS channel that can do stream multiplexation and flow control properly without any need to change or add anything to the TLS level. As the applications using needs to be changed anyways (i.e. connect to the local socket instead of the remote socket, i.e. mostly configuration change) it does not really matter if they connect to the MTLS server or some application running over TLS protected stream. -- kivinen@safenet-inc.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 16:08:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCic-0007yV-3b; Tue, 29 Nov 2005 16:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcpUh-0001d8-1n for tls@megatron.ietf.org; Thu, 17 Nov 2005 14:32:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16018 for ; Thu, 17 Nov 2005 14:31:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcpmM-0006H5-2g for tls@ietf.org; Thu, 17 Nov 2005 14:50:44 -0500 Received: from mail2.microsoft.com ([131.107.3.124]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EcpUe-0004JN-94 for tls@ietf.org; Thu, 17 Nov 2005 14:32:24 -0500 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Nov 2005 11:32:01 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 11:32:01 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 11:32:00 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 11:32:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Proposed TLS WG recharter Date: Thu, 17 Nov 2005 11:31:59 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1147DB4DF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [TLS] Proposed TLS WG recharter Thread-Index: AcXrnQI8o4jXqabqSdWX/LgvIcvs8wADyeLg From: "Joshua Ball" To: "Eric Rescorla" , X-OriginalArrivalTime: 17 Nov 2005 19:32:00.0495 (UTC) FILETIME=[949A7FF0:01C5EBAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 29 Nov 2005 16:08:49 -0500 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org WRT 1.2, I would also like to examine the possibility of designing a new ciphersuite negotiation scheme, one that allows a more flexible approach to choosing the various algorithms individually, rather than on a "per ciphersuite" basis. That is to say, I am not against having ciphersuites as strict definitions of support. In fact, I think it is crucial that we maintain this notion to keep the explosion of possibilities down. But this is no reason, IMHO, to not allow each individual variable (i.e. symmetric cipher, key exchange, hashes, to be negotiated within a subset of those possibilities required for compliance with the standard.=20 Yes, this will require considerable design and implementation changes to ciphersuite negotiation, but I think going forward it might very well be worth it. I think it might be too early to make this a goal, but is this something that we might look into?=20 -----Original Message----- From: tls-bounces@lists.ietf.org [mailto:tls-bounces@lists.ietf.org] On Behalf Of Eric Rescorla Sent: Thursday, November 17, 2005 9:32 AM To: tls@ietf.org Subject: [TLS] Proposed TLS WG recharter Here's my proposed TLS WG recharter. Any comments? -Ekr Description of Working Group: Goals and Milestones: The TLS Working Group has completed a series of specifications that describe the Transport Layer Security protocol versions 1.0 and 1.1, extensions to the protocol, and new ciphersuites to be used with TLS. The primary goal of the WG is to publish a revision of TLS,=20 version 1.2, that removes the protocol's dependency on the MD5 and SHA-1 digest algorithms, which have been either wholly or partially compromised by recent research. The TLS WG will also work on adding major new cipher suites to TLS, including Counter (CTR) and authenticated encryption modes. In the preparation of TLS 1.2, the Working Group will attempt to avoid gratuitous changes to TLS 1.1. Goals and Milestones ------------------- Done Agreement on charter and issues in current draft. Done Final draft for Secure Transport Layer Protocol ('STLP') Done Working group 'Last Call' Done Submit to IESG for consideration as a Proposed Standard. Done First revised draft of TLS specification=20 3/06 First revised draft of TLS 1.2 specification. 3/06 Submit specification of Counter Mode cipher suites to IESG for publication as Proposed Standard. 3/06 First draft of authenticated encryption mode=20 cipher suites specification. 12/06 Submit specification of TLS 1.2 specification to IESG for publication as Proposed Standard. 12/06 Submit specification of authenticated encryption mode cipher suites to IESG for publication as Proposed Standard. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 16:08:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCic-0007yu-FY; Tue, 29 Nov 2005 16:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ecvul-00030u-S4 for tls@megatron.ietf.org; Thu, 17 Nov 2005 21:23:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13230 for ; Thu, 17 Nov 2005 21:23:12 -0500 (EST) Received: from mail1.microsoft.com ([131.107.3.125]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EcwCV-0004Pq-JL for tls@ietf.org; Thu, 17 Nov 2005 21:42:08 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 17 Nov 2005 18:23:36 -0800 Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 18:23:36 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 18:23:36 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Nov 2005 18:23:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Proposed TLS WG recharter Date: Thu, 17 Nov 2005 18:23:33 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1147DBBF4@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [TLS] Proposed TLS WG recharter Thread-Index: AcXru+KS8SkzxJ5MQy2z/ypB3qBhqwAKydKg From: "Joshua Ball" To: "EKR" X-OriginalArrivalTime: 18 Nov 2005 02:23:35.0679 (UTC) FILETIME=[141488F0:01C5EBE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 29 Nov 2005 16:08:50 -0500 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Sure. -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Thursday, November 17, 2005 1:14 PM To: Joshua Ball Cc: tls@ietf.org Subject: Re: [TLS] Proposed TLS WG recharter "Joshua Ball" writes: > WRT 1.2, I would also like to examine the possibility of designing a new > ciphersuite negotiation scheme, one that allows a more flexible approach > to choosing the various algorithms individually, rather than on a "per > ciphersuite" basis. That is to say, I am not against having ciphersuites > as strict definitions of support. In fact, I think it is crucial that we > maintain this notion to keep the explosion of possibilities down. But > this is no reason, IMHO, to not allow each individual variable (i.e. > symmetric cipher, key exchange, hashes, to be negotiated within a subset > of those possibilities required for compliance with the standard.=20 > > Yes, this will require considerable design and implementation changes to > ciphersuite negotiation, but I think going forward it might very well be > worth it. I think it might be too early to make this a goal, but is this > something that we might look into?=20 So, my position is that this charter doesn't exclude looking into this, but that it says that we would need to have a strong argument to actually move forward with it. Does that work for you? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 16:08:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCic-0007zJ-ST; Tue, 29 Nov 2005 16:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ed2qg-00018L-2E for tls@megatron.ietf.org; Fri, 18 Nov 2005 04:48:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04925 for ; Fri, 18 Nov 2005 04:47:28 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ed38S-0000oq-Mv for tls@ietf.org; Fri, 18 Nov 2005 05:06:27 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAI9lmLG024407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Nov 2005 11:47:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAI9llNI023345; Fri, 18 Nov 2005 11:47:47 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17277.41795.506866.445122@fireball.kivinen.iki.fi> Date: Fri, 18 Nov 2005 11:47:47 +0200 From: Tero Kivinen To: badra Subject: Re: [TLS] draft-badra-hajjeh-mtls-00.txt In-Reply-To: <437CBF7B.8080006@enst.fr> References: <17266.17941.160710.5249@fireball.kivinen.iki.fi> <437C56ED.1000203@enst.fr> <17276.25458.758901.927658@fireball.kivinen.iki.fi> <437CBF7B.8080006@enst.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 12 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 29 Nov 2005 16:08:48 -0500 Cc: Mohamad.Badra@enst.fr, tls@ietf.org, Ibrahim.Hajjeh@esrgroups.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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org badra writes: > Hmmm, it provides the same services..., but there is no problem to > borrow from SSH if we want really to add port forwarding to TLS. > However, it is not the only way (plz see below). I do not see any reason why we should have yet another protocol do to the same thing, instead of using very widely used protocol already doing that. I assume you next suggest that telnet should be expanded to support to transfer of www-pages instead of http... > There is no difference, in my opinion, to implement it at transport or > application level. > In the case of transport level, your server will listen on a specific > port, and in the case of application one, your application need to > connect to a port running over TLS. Big difference is that if you do it on the TLS level you need to make TLS extensions. If you do it on the application layer, you simply need to define protocol which can be used over any channel (or simply reuse existing protocol, like secure shell connection layer). > However, I agree that stream flow control will be required. But I don't > think we are going to use the secsh method: let's assume that for each > packet send by the MTLS client through an arbitrary channel, an > acknowledgement (if the server has no data to write) will be sent by the > MTLS server to inform the client that MTLS server is ready to read more > data (a litte bit of data is sent...). Certainly this is not sufficient > if we don't control the maximum data length that the entity is ready to > read. Accordingly, both entities should negotiate the maximum packet for > each application they want to run and this during the Handshake phase. To get any real performance over the streams, you need similar window code that is used both in TCP and in secure shell. And the window sizes needs to be able to grow over the time. For example first ssh2 implementations used fixed window size, but that resulted quite bad performance when transferring lots of data, so it was needed to add code that will allow the window size to grow if it detects high bandwidth transfer. On the other hand it does not want to use big window size all time, as it just consumes too much memory. > During the data exhange phase, the entity may be not ready to treat data > with length larger than the maximum length negotiated during the > Handshake phase. In this case, the acknowledgement packet must contain > the appropriate length the receiver is ready to read. And if the local > buffer fill up, no acknowlodgment packet will be send. I suggest you read for example the secure shell connection layer and see how it is doing that. On the other hand I do not still think we should be doing this kind of protocol on this level. > (BTW, What will the server do if your scenario will happen in the case > of an ordinary SMTP over TLS?) In case of the ordinary SMTP over TLS there is no problem, as TCP do provide the flow control, and the whole TLS channel is stopped. Because there is no other traffic going over the same TLS stream there is no problem. The problem only appears when you start multiplexing multiple streams to same TCP/TLS stream. > I would like to say that the actual document is 00 version and it is not > the only way to do data multiplexing over TLS. And it will not be a > problem to choose between application and transport layers if we want > really to integrate data multiplexing over TLS. The question is do we want to integrate data multiplexing to TLS. I do not see any point of doing that. -- kivinen@safenet-inc.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 29 16:08:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhCid-0007zj-8q; Tue, 29 Nov 2005 16:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EeNW9-0002ws-N7 for tls@megatron.ietf.org; Mon, 21 Nov 2005 21:04:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18255 for ; Mon, 21 Nov 2005 21:03:42 -0500 (EST) Received: from mail3.microsoft.com ([131.107.3.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EeNoe-0006sl-MH for tls@ietf.org; Mon, 21 Nov 2005 21:23:31 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499); Mon, 21 Nov 2005 18:04:07 -0800 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 18:04:07 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 18:04:07 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.5.41]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Nov 2005 18:04:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Proposed TLS WG recharter Date: Mon, 21 Nov 2005 18:04:13 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1148501BE@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: [TLS] Proposed TLS WG recharter thread-index: AcXrvCWCvo+s+PhaTNqUAcmN78ltmQDAmlbQABGH4iA= From: "Joshua Ball" To: , X-OriginalArrivalTime: 22 Nov 2005 02:04:06.0369 (UTC) FILETIME=[04C4FD10:01C5EF09] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 29 Nov 2005 16:08:50 -0500 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Pasi, I completely agree, this hasn't been a problem, nor do all combinations make sense. And believe me, I am not looking to make all combinations of ciphersuites out there part of the standard. I think that just because we can theoretically negotiate everything, doesn't necessarily mean that all of those combinations should be part of the standard. We could, for example, just declare a subset of those ciphersuites be required for compatibility, as we do now.=20 I guess my thought was that we are already seeing cipher suites negotiated outside the scope of the base protocol (i.e. ECC curves). Additionally we now have a problem with hashes that are becoming compromised. And who knows what the next issue might be. In particular, if we are going to gut the current MD5 and SHA1 out of the protocol innards, and replace it with a new hash, how do we specify this? An extension? A new protocol version? Is that the easy way or the right way? What happens when the new hash is broken? My suggestion is that we have a discussion on the benefits of tweaking the cipher suite selection protocol to include the negotiation of the innards as well as optional parameters (like curves), making it cleaner and open to possible problems we have in the future. If, after looking at this it doesn't seem to solve a problem (cleaner than extension hacks) we can drop it.=20 We have extensions for a reason. And they work (wonderfully). But they also expose deficiencies in the usability of the protocol that I think we should at least address objectively. Now one could argue this ad nauseam, but I think there is a reasonable distinction between, say a server name extension and a curve or hash selection extension. The former never being intended for the protocol, the latter arguably so. Anyway, this is clearly not a critical issue. We have patches to make this work without it. It is something I would like to discuss, but, my main concern is one of aesthetics, simplicity, and future expandability. joshua -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Monday, November 21, 2005 9:15 AM To: ekr@networkresonance.com; Joshua Ball Cc: tls@ietf.org Subject: RE: [TLS] Proposed TLS WG recharter Joshua,=20 I'd like to better understand what would be the benefit being=20 sought here? A TLS management interface can already allow the administrator to e.g. choose the encryption algorithm and=20 hash individually, and this is mostly a user interface issue. The only case where this fails is when no ciphersuite number has=20 been assigned for the combination the administrator wants. But=20 has this been found to be a problem in practice?=20 (My guess would be no -- it it were a big problem, someone would have taken the trouble to get the numbers. And not all of the combinations make that much sense anyway.) Best regards, Pasi > -----Original Message----- > From: Eric Rescorla > Sent: 17 November, 2005 23:14 > To: Joshua Ball > Cc: tls@ietf.org > Subject: Re: [TLS] Proposed TLS WG recharter >=20 > "Joshua Ball" writes: > > > WRT 1.2, I would also like to examine the possibility of > > designing a new ciphersuite negotiation scheme, one that allows > > a more flexible approach to choosing the various algorithms > > individually, rather than on a "per ciphersuite" basis. That is > > to say, I am not against having ciphersuites as strict > > definitions of support. In fact, I think it is crucial that we > > maintain this notion to keep the explosion of possibilities > > down. But this is no reason, IMHO, to not allow each individual > > variable (i.e. symmetric cipher, key exchange, hashes, to be > > negotiated within a subset of those possibilities required for > > compliance with the standard. > > > > Yes, this will require considerable design and implementation > > changes to ciphersuite negotiation, but I think going forward it > > might very well be worth it. I think it might be too early to > > make this a goal, but is this something that we might look into? >=20 > So, my position is that this charter doesn't exclude looking > into this, but that it says that we would need to have a strong > argument to actually move forward with it. Does that work for > you? >=20 > -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 30 03:25:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNHQ-0007LX-Ns; Wed, 30 Nov 2005 03:25:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhNHP-0007GZ-8q for tls@megatron.ietf.org; Wed, 30 Nov 2005 03:25:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13638 for ; Wed, 30 Nov 2005 03:24:46 -0500 (EST) Received: from cryptocom.ipmce.ru ([194.85.185.72] helo=mx.cryptocom.ru) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhNbc-0001Md-W4 for tls@ietf.org; Wed, 30 Nov 2005 03:46:26 -0500 Received: by mx.cryptocom.ru (Postfix, from userid 500) id BBA01F703; Wed, 30 Nov 2005 11:25:19 +0300 (MSK) Received: from manul.lan.cryptocom.ru (manul.lan.cryptocom.ru [10.51.17.211]) by mx.cryptocom.ru (Postfix) with ESMTP id 9AB69F6FD; Wed, 30 Nov 2005 11:25:19 +0300 (MSK) Date: Wed, 30 Nov 2005 11:26:43 +0300 (MSK) From: Dmitry Belyavsky X-X-Sender: beldmit@manul.lan.cryptocom.ru To: "Gregory S. Chudov" Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt In-Reply-To: <055101c5f50d$ab2b78a0$0644a8c0@cp.ru> Message-ID: References: <20051128190250.C9E7622244D@laser.networkresonance.com><7.0.0.10.2.20051128144717.02c1fc78@vigilsec.com> <055101c5f50d$ab2b78a0$0644a8c0@cp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Greetings! On Tue, 29 Nov 2005, Gregory S. Chudov wrote: > I agree that it could be useful to add a paragraph, containing the reasoning > for this. > > IMIT_GOST28147 is not an HMAC, it is basicly a form of GOST28147 cipher. > To be robust to attacks based on timing and EMI analysis, one symmetric key > should not be used for large quantities of plaintext, so the key meshing > algorithm > from draft-popov-cryptopro-cpalgs-04.txt is applied. Thank you, this paragraph provides enough information for me to understand your design decision. But the section 2 of draft-chudov-cryptopro-cptls-02.txt proposes two cipher suites with GOSTR3411-based MAC. Is key meshing applied for these cipher suites too or do they use usual HMAC? And what is MACed data for them? Thank you! > This "abberation" can be rephrased in a following way: MACed_data[seq_num] > is MACed, using the cipher state, produced by processing the previous record. > > Good luck! > > ----- Original Message ----- From: "Dmitry Belyavsky" > To: "Russ Housley" > Cc: > Sent: Tuesday, November 29, 2005 5:40 PM > Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt > > > > Greetings! > > > ... > > > > What can you say about section 3.3 of draft-chudov-cryptopro-cptls-02.txt? > > It describes a non-reasoned aberration from RFC 2246: > > > > ==================== > > For all four cipher suites, the use of MAC is slighttly different > > from the one, described in section 6.2.3.1 of [TLS]. In [TLS], MAC > > is calculated from the following data: > > > > MACed_data[seq_num] = seq_num + > > TLSCompressed.type + > > TLSCompressed.version + > > TLSCompressed.length + > > TLSCompressed.fragment; > > > > These cipher suites use the same input for first record, but for each > > next record the input from all previous records is concatenated: > > > > MACed_data[0] + ... + MACed_data[n] > > ==================== -- SY, Dmitry Belyavsky (ICQ UIN 11116575) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 30 07:06:30 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQjG-0007UU-Kx; Wed, 30 Nov 2005 07:06:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQjF-0007UP-28 for tls@megatron.ietf.org; Wed, 30 Nov 2005 07:06:29 -0500 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05769 for ; Wed, 30 Nov 2005 07:05:42 -0500 (EST) Received: by wproxy.gmail.com with SMTP id i23so233556wra for ; Wed, 30 Nov 2005 04:06:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=hK9NBXQ0RkRKBLMsmKnihv2gEd+Za6uv5ArfuOx/KQliM/WB80Zb4oaH6QoS36SxKGbc4rzUW6lnkHEz6OBSC2MYgyhAtB+KKpWXXk8wqF7DVot2IB8TNKh9Ragu5vLLtifPqRfrs8oaWo1h4sih2/z/FhAfjXgXqfXVRNmOqbM= Received: by 10.65.189.16 with SMTP id r16mr74525qbp; Wed, 30 Nov 2005 04:06:27 -0800 (PST) Received: from turtle.i-net.gr ( [143.233.187.87]) by mx.gmail.com with ESMTP id q14sm210807qbq.2005.11.30.04.06.25; Wed, 30 Nov 2005 04:06:27 -0800 (PST) From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt Date: Wed, 30 Nov 2005 13:05:52 +0100 User-Agent: KMail/1.8.2 References: <20051128190250.C9E7622244D@laser.networkresonance.com> In-Reply-To: <20051128190250.C9E7622244D@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511301305.52975.nmav@gnutls.org> Content-Transfer-Encoding: 7bit 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org On Monday 28 November 2005 20:03, Eric Rescorla wrote: > I'd like to get some working group discussion on whether > there's interest in pursuing the GOST cipher suites > draft-chudov-cryptopro-cptls-02.txt as a working group > document. In your responses, please indicate: > 1. Whether you would like to see this as a WG document. > 2. Whether you are willing to commit to reviewing it in > future. I think it is nice to have alternatives, so I would like to see something like this in TLS. So my anwser would be yes in both questions. -- Nikos Mavrogiannopoulos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 30 07:11:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQoY-0002M7-Ii; Wed, 30 Nov 2005 07:11:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhQoX-0002JO-Qb for tls@megatron.ietf.org; Wed, 30 Nov 2005 07:11:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06404 for ; Wed, 30 Nov 2005 07:11:11 -0500 (EST) Received: from cryptocom.ipmce.ru ([194.85.185.72] helo=mx.cryptocom.ru) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhR8n-0008Nd-RZ for tls@ietf.org; Wed, 30 Nov 2005 07:32:55 -0500 Received: by mx.cryptocom.ru (Postfix, from userid 500) id 8EE66F70D; Wed, 30 Nov 2005 15:11:46 +0300 (MSK) Received: from manul.lan.cryptocom.ru (manul.lan.cryptocom.ru [10.51.17.211]) by mx.cryptocom.ru (Postfix) with ESMTP id 6808DF70C; Wed, 30 Nov 2005 15:11:46 +0300 (MSK) Date: Wed, 30 Nov 2005 15:13:10 +0300 (MSK) From: Dmitry Belyavsky X-X-Sender: beldmit@manul.lan.cryptocom.ru To: Eric Rescorla Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt In-Reply-To: <20051128190250.C9E7622244D@laser.networkresonance.com> Message-ID: References: <20051128190250.C9E7622244D@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "tls@ietf.org" X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Greetings! On Mon, 28 Nov 2005, Eric Rescorla wrote: > I'd like to get some working group discussion on whether > there's interest in pursuing the GOST cipher suites > draft-chudov-cryptopro-cptls-02.txt as a working group > document. In your responses, please indicate: > > 1. Whether you would like to see this as a WG document. > 2. Whether you are willing to commit to reviewing it in > future. I'm interested in pursuing the GOST cipher suites specification as a working group document and would like to participate in reviewing it. -- SY, Dmitry Belyavsky (ICQ UIN 11116575) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 30 07:44:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRJY-0004BN-QD; Wed, 30 Nov 2005 07:44:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhRJX-0004BH-7x for tls@megatron.ietf.org; Wed, 30 Nov 2005 07:43:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08935 for ; Wed, 30 Nov 2005 07:43:12 -0500 (EST) Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhRdn-0000xV-3C for tls@ietf.org; Wed, 30 Nov 2005 08:04:57 -0500 Received: from localhost (loopback [127.0.0.1]) by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP id AA1D310E for ; Wed, 30 Nov 2005 13:43:42 +0100 (MET) Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26]) by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP id 42558-03 for ; Wed, 30 Nov 2005 13:43:40 +0100 (NFT) Received: from [127.0.0.1] (rouen.Informatik.Uni-Tuebingen.De [134.2.11.152]) by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP id E4DFA13D for ; Wed, 30 Nov 2005 13:43:39 +0100 (NFT) Message-ID: <438D9E7E.6040403@uni-tuebingen.de> Date: Wed, 30 Nov 2005 13:43:42 +0100 From: Ali Fessi User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "tls@ietf.org" References: <20051128190250.C9E7622244D@laser.networkresonance.com> In-Reply-To: <20051128190250.C9E7622244D@laser.networkresonance.com> X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at informatik.uni-tuebingen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Subject: [TLS] Difference between TLS and SSL X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1402144055==" Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1402144055== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030608000907040504000106" This is a cryptographically signed message in MIME format. --------------ms030608000907040504000106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, can some one tell me if there is today any differences between TLS and SSL; or if SSL implementations (e.g. OpenSSL Version 0.9.7) are basically conform to the TLS standard + a couple of extensions (such as AES Cipher Suites, ECC Cipher Suites, also Kerberos Cipher suites?!) Thanks in advance. Ali -- Ali Fessi Phone: +49 - 7071 29534 University of Tuebingen --------------ms030608000907040504000106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGOTCC AvIwggJboAMCAQICAw37QTANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDUwMjA3MTQxOTE3WhcNMDYwMjA3MTQxOTE3 WjBdMQ4wDAYDVQQEEwVGZXNzaTEMMAoGA1UEKhMDQWxpMRIwEAYDVQQDEwlBbGkgRmVzc2kx KTAnBgkqhkiG9w0BCQEWGmFsaS5mZXNzaUB1bmktdHVlYmluZ2VuLmRlMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2SH7H2KK6H3jYVitFjxylVOsL/TRXXnwlqTjUQmPU1yl 0sK3nv5xWD2lHqL/5v+n2YjYqi2kdG6ORyks51/QKVOB0NYCEVlQFWdT5DNNw6RvjGQd715K XXO4b7XRQJFcZc1Qc8L2G/fER9fvWHfCX09KhFqrJRQ2mahZ+sWcoXZlV9k5M1/jPTECR9dC iVdtI4SYdye9Aryu/P5S6mT0XgZ4JDb41qYTlUyYQpqp77VOFG4odh0vrINac0KdlHrhCjDJ PQ1c23a8/s7VbdG44GsGw5SoFJiDXjQrLhsxh62c88qhNiqMtRPvsnxgqUvv0YKEvYCS5O0e nFiUakz/kwIDAQABozcwNTAlBgNVHREEHjAcgRphbGkuZmVzc2lAdW5pLXR1ZWJpbmdlbi5k ZTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAAm748hVdHcNCjCezGHTtFHr7n/K /EnCMrAABvW3oGjM8C9xuzULk7TUubotA1GROGFIcQfDIOqDGirope4asWdEiG9NARtlJkpc JTXv0v1Dl6vEZhXLGF7efTUCI6/mANlQ3sLc22vqceYU/kDSYUijRCz68F0gyiWJ9Z/wR7ic MIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB0TELMAkGA1UEBhMCWkExFTATBgNV BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoXDTEzMDcxNjIz NTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkp IEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV 84J3PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GU MIGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50 aGF3dGUuY29tL1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkG A1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUF AAOBgQBIjNFQg+oLLswNo2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3h YWLD2ToZfoSxmRsAxRoLgnSeJVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQ Gls1TXfjViF4gtwhGTXeJLHTHUb/XV9lTzGCAkQwggJAAgEBMGkwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAgMN+0EwCQYFKw4DAhoFAKCBsTAYBgkq hkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNTExMzAxMjQzNDNaMCMG CSqGSIb3DQEJBDEWBBQDmlew5NheSTbNQIAm+mY6jVqItDBSBgkqhkiG9w0BCQ8xRTBDMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQDRJx38ldzSrX95yDraoV7U8zsmBx7q3Wqu R9tRQbFPO7xeBjlcMRZ5/7vqeACL4mnFYWfaojOTjgiJi3vG6RUcga8oVq6mUQt13PDspU59 kGWuZGN225P52QszbKw4vHdI991KetsV1+zenrVM2oMDbLzUs0zAezww1aAqWmwn7qlku7nb wDR/Fkgg0g8JiWVWkZSMyeGDcbwwSxUOA6FWm2X5xC9et8YlPALiNX7f9Y4gEdneuCU+9XJz vXGWlaw9XRmK+zWX9X01IaOky1X1XFczryyzZbtYfBuTCEcJmwAB8yRtXZQcOHtkjWsYqdHn X0XXFe9k5NJZDR5DJTzTAAAAAAAA --------------ms030608000907040504000106-- --===============1402144055== 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 --===============1402144055==-- From tls-bounces@lists.ietf.org Wed Nov 30 10:37:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhU1e-0007Yr-0E; Wed, 30 Nov 2005 10:37:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EhU1b-0007YZ-Qb for tls@megatron.ietf.org; Wed, 30 Nov 2005 10:37:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01380 for ; Wed, 30 Nov 2005 10:36:54 -0500 (EST) Received: from mx2.cryptopro.ru ([213.59.158.218]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EhULt-0007Jx-H6 for tls@ietf.org; Wed, 30 Nov 2005 10:58:39 -0500 Received: from fandra2k ([192.168.68.6]) by mx2.cryptopro.ru with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Nov 2005 18:40:03 +0300 Message-ID: <069701c5f5c4$550ce230$0644a8c0@cp.ru> From: "Gregory S. Chudov" To: "Dmitry Belyavsky" , References: <20051128190250.C9E7622244D@laser.networkresonance.com><7.0.0.10.2.20051128144717.02c1fc78@vigilsec.com> <055101c5f50d$ab2b78a0$0644a8c0@cp.ru> Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt Date: Wed, 30 Nov 2005 18:40:03 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.1830 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-OriginalArrivalTime: 30 Nov 2005 15:40:03.0937 (UTC) FILETIME=[550F0510:01C5F5C4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Greetings. They use usual HMAC, and i think it makes sense to use the standard scheme from TLS for them (Null or standard stream cipher, ch. 6.2.3.1). I think we can put it this way: Cipher suites TLS_GOST341094_WITH_NULL_GOSTR3411 and TLS_GOST34102001_WITH_NULL_GOSTR3411 use the same record payload protection scheme, as described in section 6.2.3.1 of [TLS]: MACed_data[seq_num] = seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment; CipherSpec.hash_size = 32 GenericStreamCipher.MAC = HMAC_GOSTR3411 (MACed_data[seq_num]) Cipher suites TLS_GOST341094_WITH_GOST28147_OFB_GOST28147 and TLS_GOST34102001_WITH_GOST28147_OFB_GOST28147 use IMIT_GOST28147 as MAC function. IMIT_GOST28147 is basicly a form of GOST28147 cipher. To be robust to attacks based on timing and EMI analysis, one symmetric key should not be used for large quantities of plaintext, so the CryptoPro Key Meshing algorithm from [CPALGS], section 2.3.2, is applied to the MAC keys. Each record MAC is computed, using the cipher state resulting from processing the previous record, which is equivalent to computing the MAC from concatenation of all previous records: CipherSpec.hash_size = 4 GenericStreamCipher.MAC = IMIT_GOST28147 (MACed_data[0] + ... + MACed_data[n]) Good luck and thanks for feedback. ----- Original Message ----- From: "Dmitry Belyavsky" To: "Gregory S. Chudov" Cc: Sent: Wednesday, November 30, 2005 11:26 AM Subject: Re: [TLS] WG interest in draft-chudov-cryptopro-cptls-02.txt > Greetings! ... > Thank you, this paragraph provides enough information for me to understand > your design decision. > > But the section 2 of draft-chudov-cryptopro-cptls-02.txt proposes two > cipher suites with GOSTR3411-based MAC. Is key meshing applied > for these cipher suites too or do they use usual HMAC? And what is MACed > data for them? ... > -- > SY, Dmitry Belyavsky (ICQ UIN 11116575) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls