From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 00:13:00 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16138 for ; Fri, 1 Jun 2001 00:12:59 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 31 May 2001 21:19:26 -0700 In-Reply-To: Shiho MORIAI's message of "Fri, 01 Jun 2001 11:25:22 JST" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Shiho MORIAI writes: > Our proposal also gives a new option, an efficient 128-bit block > cipher that is royalty-free! Since the only such cipher currently > available is AES, our actions with regard to Camellia should be well > received. On what basis do you say this? Twofish, Serpent and MARS are all fast, 128-bit ciphers which are royalty free. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 00:17:15 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16160 for ; Fri, 1 Jun 2001 00:17:14 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 31 May 2001 21:23:43 -0700 In-Reply-To: Shiho MORIAI's message of "Fri, 01 Jun 2001 11:25:22 JST" Message-ID: Lines: 10 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Shiho MORIAI writes: > >We don't believe that proprietary algorithms should be added to the TLS > >standard. > > I agree with you on that point. So we have decided to grant royalty-free > licenses for the essential patents of Camellia. Is the intellectual property statement for it up yet? I don't see it on the IETF site. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 00:38:42 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16570 for ; Fri, 1 Jun 2001 00:38:38 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp, shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "31 May 2001 21:19:26 MST." Date: Fri, 01 Jun 2001 13:38:47 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106010438.NAA14513@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Eric, I mean the only such cipher currently available defined (or proposed) for TLS is AES. I know Twofish, Serpent and MARS are all fast, 128-bit ciphers which are royalty free. Camellia is faster than Serpent in software implementation on many platforms. Moreover, Camellia has the advantage of small hardware over Twofish and MARS. Shiho >Shiho MORIAI writes: >> Our proposal also gives a new option, an efficient 128-bit block >> cipher that is royalty-free! Since the only such cipher currently >> available is AES, our actions with regard to Camellia should be well >> received. >On what basis do you say this? Twofish, Serpent and MARS are all >fast, 128-bit ciphers which are royalty free. > >-Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 00:49:35 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA16659 for ; Fri, 1 Jun 2001 00:49:33 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" cc: "IETF Transport Layer Security WG" , shiho@sucaba.isl.ntt.co.jp, shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "31 May 2001 21:23:43 MST." Date: Fri, 01 Jun 2001 13:49:05 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106010449.NAA14617@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Eric, I sent a formal patent statement pertaining to Camellia to the IETF Secretariat by air mail last week. I don't know when it will be available on the IETF page of IPR Notices, so I'll put it on the Camellia home page soon. http://info.isl.ntt.co.jp/camellia/ Shiho >Shiho MORIAI writes: >> >We don't believe that proprietary algorithms should be added to the TLS >> >standard. >> >> I agree with you on that point. So we have decided to grant royalty-free >> licenses for the essential patents of Camellia. >Is the intellectual property statement for it up yet? I don't >see it on the IETF site. > >-Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 01:15:38 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17498 for ; Fri, 1 Jun 2001 01:15:36 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 31 May 2001 22:20:58 -0700 In-Reply-To: Shiho MORIAI's message of "Fri, 01 Jun 2001 13:38:47 JST" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Shiho MORIAI writes: > I mean the only such cipher currently available defined (or proposed) > for TLS is AES. Sure, but this is largely because people have only felt the need for one such [fast, 128-bit, royalty free] cipher, not because no others are available. If the WG consensus is that we need another, the other AES candidates would be the obvious choices. -Ekr [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 06:13:14 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03564 for ; Fri, 1 Jun 2001 06:13:10 -0400 (EDT) Date: Fri, 1 Jun 2001 12:12:12 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from rhousley@rsasecurity.com on Thu, May 31, 2001 at 11:35:43AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010601121212.B21134@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Thu, May 31, 2001 at 11:35:43AM -0400, Housley, Russ wrote: [...] > On the other hand, RSA-OAEP is being used in many areas. [...] > I am proposing a well studied, and reasonably well adopted technique as the > successor to PKCS#1 v1.5 for TLS. RSA-OAEP is "well-studied" only as of the next CRYPTO conference. The original security argument was recently found to be flawed [1], a new proof relying on a stronger assumption was given later [2]. CRYPTO 2001 also has a paper "A Chosen Ciphertext Attack On RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized In PKCS #1" by James Manger. I am not aware of any preprints of this one, or of the details of the attack. Anyone? [1] Victor Shoup: "OAEP Reconsidered". -- CRYPTO 2001, to appear. Preprint available from and . [2] Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval and Jacques Stern: "RSA-OAEP is Secure Under the RSA Assumption" -- CRYPTO 2001, to appear. Preprint available from . -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 08:11:11 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05885 for ; Fri, 1 Jun 2001 08:11:09 -0400 (EDT) Date: Fri, 1 Jun 2001 13:11:00 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rhousley@rsasecurity.com on Thu, May 31, 2001 at 11:35:43AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010601131100.B5101@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Housley, Russ wrote: > I strongly believe that the IETF Security Area should be moving toward a > common set of security mechanisms. I gave a presentation at the August > 2000 SAAG meeting with this same message. It would be more "elegant" if the same mechanisms were used in all the protocols. It would also allow more code reuse. Do you have other reasons for supporting this? You have convinced me that your idea is a good one, but only in the sense of a long term goal. I'm not sure why there is such a sense of urgency about it. > We have an opportunity > to adopt AES and RSA-OAEP across the entire IETF Security Area. We should > not miss this opportunity. Unfortunately for reasons of backwards compatibility, the RC4-128 ciphersuite is going to be in common use for the foreseeable future. It is important to add AES because government work often requires it. But (sadly) the AES ciphersuites are unlikely to be adopted overnight by other people. It won't be possible to get the majority of people onto OAEP by piggybacking on the AES changes. > Since you believe that RSA-OAEP should be used in the future, why not > define both PKCS#1 v1.5 and OAEP now, and warn implementors that the switch > is coming. This will allow a transition period. If you think that is a good approach, why not write a separate I-D? That way, you could define OAEP versions of other ciphersuites, not just AES. Theoretically I could add those to my draft but I want it to stay focused on AES rather than drifting into being a general TLS revision document. The other advantage of a separate I-D is that then the issues can be debated separately. If people object to the way AES is being approached it won't hold up OAEP, and vice-versa. (Of course, I'm not necessarily saying that I would support an OAEP draft -- it would depend how the issue was approached.) -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 10:35:33 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08947 for ; Fri, 1 Jun 2001 10:35:31 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 01 Jun 2001 09:47:09 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010601093344.01e44ee8@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Pete: > > I strongly believe that the IETF Security Area should be moving toward a > > common set of security mechanisms. I gave a presentation at the August > > 2000 SAAG meeting with this same message. > >It would be more "elegant" if the same mechanisms were used in all the >protocols. It would also allow more code reuse. Do you have other >reasons for supporting this? No. I believe that a set of well-studied algorithms can provide the core capabilities for IETF security protocols. Of course, they will have to change over time to keep up with computing and analytical advances. In the near future, I would like to see RSA-OAEP and AES as two of those core algorithms. >You have convinced me that your idea is a good one, but only in the >sense of a long term goal. I'm not sure why there is such a sense of >urgency about it. AES has created some momentum. I would like to use that momentum to upgrade the rest of the core algorithms. This can easily be done in a way that offers backward and forward compatibility, especially in a protocol like TLS where negotiation is built in. It is more difficult in S/MIME where the originator has a large number of recipients to consider. > > We have an opportunity > > to adopt AES and RSA-OAEP across the entire IETF Security Area. We should > > not miss this opportunity. > >Unfortunately for reasons of backwards compatibility, the RC4-128 >ciphersuite is going to be in common use for the foreseeable future. >It is important to add AES because government work often requires it. >But (sadly) the AES ciphersuites are unlikely to be adopted overnight >by other people. It won't be possible to get the majority of people >onto OAEP by piggybacking on the AES changes. I agree that adoption will be gradual and incremental. If we do not include RSA-OAEP in the AES specification, then we are further delaying the start of that adoption process. > > Since you believe that RSA-OAEP should be used in the future, why not > > define both PKCS#1 v1.5 and OAEP now, and warn implementors that the > switch > > is coming. This will allow a transition period. > >If you think that is a good approach, why not write a separate I-D? >That way, you could define OAEP versions of other ciphersuites, not >just AES. Theoretically I could add those to my draft but I want it >to stay focused on AES rather than drifting into being a general TLS >revision document. >The other advantage of a separate I-D is that then the issues can be >debated separately. If people object to the way AES is being >approached it won't hold up OAEP, and vice-versa. I would be willing to do so, but as I have already stated, I believe that it is important to take advantage of the momentum that AES has created. My hope is that implementors will add RSA-OAEP and AES at the same time. Then, as the implementations are deployed, the better algorithms see more use. Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 10:55:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09238 for ; Fri, 1 Jun 2001 10:55:48 -0400 (EDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Cc: jis@mit.edu, mleech@nortelnetworks.com Sender: bounce-ietf-tls-3458737@lists.certicom.com Reply-To: "IETF Transport Layer Security WG" X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 2 Jun 2001 02:55:28 (NZST) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <99140732813130@kahu.cs.auckland.ac.nz> X-List-Host: SKYLIST.net "Housley, Russ" writes: >On the other hand, RSA-OAEP is being used in many areas. s/ignored/used/ (I guess you could also say that "OSI is being used in many areas" because every book on networking and security I've ever seen has the mandatory picture of the 7-layer model in it :-). >VISA and Master Card were probably the early adopters in SET. Since then, >there has been considerable activity involving RSA-OAEP. IEEE Std 1363-2000 >includes RSA-OAEP. The current draft of ANSI X9.44 includes RSA-OAEP. How many implementations of any of the above have you ever seen? SET is practically dead (except for a few Asian contries which don't have Reg.E/Reg.Z), X9.44 may as well not exist for all the use it sees, and OAEP in 1363 isn't being used for much either. >I am proposing a well studied, and reasonably well adopted technique as the >successor to PKCS#1 v1.5 for TLS. The technique may be well-studied, but adoption is practically nonexistant. That's not to say we shouldn't use it (requiring OAEP as part of the AES upgrade sounds like a good move), but it's not a good argument for saying we should use it. Peter. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 11:16:04 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09608 for ; Fri, 1 Jun 2001 11:15:57 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Cc: jis@mit.edu, mleech@nortelnetworks.com Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 01 Jun 2001 08:22:23 -0700 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Sat, 2 Jun 2001 02:55:28 (NZST)" Message-ID: Lines: 22 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > "Housley, Russ" writes: > > >On the other hand, RSA-OAEP is being used in many areas. > > s/ignored/used/ You mean s/used/ignored/, right? :) > >VISA and Master Card were probably the early adopters in SET. Since then, > >there has been considerable activity involving RSA-OAEP. IEEE Std 1363-2000 > >includes RSA-OAEP. The current draft of ANSI X9.44 includes RSA-OAEP. > > How many implementations of any of the above have you ever seen? SET is > practically dead (except for a few Asian contries which don't have > Reg.E/Reg.Z), X9.44 may as well not exist for all the use it sees, and OAEP in > 1363 isn't being used for much either. Even if SET were widely used, the OAEP in SET is reasonably different from the OAEP we're using here, due to the need to pack the PAN into the encryption block. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 11:28:19 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09845 for ; Fri, 1 Jun 2001 11:28:18 -0400 (EDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Sender: bounce-ietf-tls-3458737@lists.certicom.com Reply-To: "IETF Transport Layer Security WG" X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 2 Jun 2001 03:28:21 (NZST) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <99140930113269@kahu.cs.auckland.ac.nz> X-List-Host: SKYLIST.net "Housley, Russ" writes: >My hope is that implementors will add RSA-OAEP and AES at the same time. >Then, as the implementations are deployed, the better algorithms see more use. One thing which may be impeding this is that PKCS #1 is very easy to implement while OAEP isn't. Moving to AES is easy (grab Brian Gladman's reference implementation and spend 10 minutes glueing into your existing code), however there's no reference implementation for OAEP which means that everyone planning to switch to it has to invest a considerable amount of effort into figuring out what OAEP actually does (the P1363-style description is almost impenetrable to anyone outside the P1363 WG) and then making sure that what they've implemented is correct. The lack of other implementations to test against doesn't help (there are some test vectors floating around somewhere, although they're not part of the PKCS #1 RFC so it's not even easy to check the code you've written). What could really help its adoption is a freely available reference implementation to mirror the AES implementation. Until then, with no installed base, no easily-locatable test vectors, and a lot of work required to add it, I can't see it taking off. Peter (who started playing with an implementation ages ago but never finished it when he realised that doing so would be pretty pointless. If I ever get time to finish it I'll make it freely available). --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 11:34:17 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10018 for ; Fri, 1 Jun 2001 11:34:16 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Cc: jis@mit.edu, mleech@nortelnetworks.com Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 01 Jun 2001 11:34:07 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010601112616.01e8a2a0@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Peter: > >On the other hand, RSA-OAEP is being used in many areas. > >s/ignored/used/ > >(I guess you could also say that "OSI is being used in many areas" because >every book on networking and security I've ever seen has the mandatory picture >of the 7-layer model in it :-). I know of several implementations, but that is not really your point. Interoperability is the point, and everyone uses PKCS#1 v1.5. I would like to see us migrate to a better padding and encoding technique, one where the application does not need to include specific countermeasures to avoid the Million Message Attack. I grant that PKCS#1 v1.5 with those countermeasures in the application is safe. In my goal to see a common set of algorithms used in the IETF Security Area, I would like to select a symmetric key management algorithm that does not require each application developer to include application-specific countermeasures in their code. I am asking for an evolution to the better padding and encoding technique... > >I am proposing a well studied, and reasonably well adopted technique as the > >successor to PKCS#1 v1.5 for TLS. > >The technique may be well-studied, but adoption is practically nonexistant. >That's not to say we shouldn't use it (requiring OAEP as part of the AES >upgrade sounds like a good move), but it's not a good argument for saying we >should use it. Thanks for the support, I think... Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 11:47:55 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10339 for ; Fri, 1 Jun 2001 11:47:54 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 01 Jun 2001 11:47:55 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010601114446.01e941f0@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Peter: > >My hope is that implementors will add RSA-OAEP and AES at the same time. > >Then, as the implementations are deployed, the better algorithms see > more use. > >One thing which may be impeding this is that PKCS #1 is very easy to implement >while OAEP isn't. Moving to AES is easy (grab Brian Gladman's reference >implementation and spend 10 minutes glueing into your existing code), however >there's no reference implementation for OAEP which means that everyone >planning >to switch to it has to invest a considerable amount of effort into >figuring out >what OAEP actually does (the P1363-style description is almost impenetrable to >anyone outside the P1363 WG) and then making sure that what they've >implemented >is correct. The lack of other implementations to test against doesn't help >(there are some test vectors floating around somewhere, although they're not >part of the PKCS #1 RFC so it's not even easy to check the code you've >written). > >What could really help its adoption is a freely available reference >implementation to mirror the AES implementation. Until then, with no >installed >base, no easily-locatable test vectors, and a lot of work required to add >it, I >can't see it taking off. The current draft of X9.44 has several test vectors (in Annex D). If we agree to go forward with RSA-OAEP, I will gladly repackage those test vectors into an Internet-Draft (to become an Informational RFC). Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 13:17:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13338 for ; Fri, 1 Jun 2001 13:17:27 -0400 (EDT) Message-ID: From: "Greg Stark" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Date: Fri, 1 Jun 2001 13:17:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <012c01c0eabe$b0baeca0$651e10ac@netscreen5> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit The OpenSSL project (www.openssl.org) has an implementation of RSA-OAEP. It's available as a padding option to the RSA_public_encrypt() function in the crypto library. ==================== Greg Stark ghstark@pobox.com ==================== ----- Original Message ----- From: "Peter Gutmann" To: "IETF Transport Layer Security WG" Sent: Saturday, June 02, 2001 3:28 AM Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" > "Housley, Russ" writes: > > >My hope is that implementors will add RSA-OAEP and AES at the same time. > >Then, as the implementations are deployed, the better algorithms see more use. > > One thing which may be impeding this is that PKCS #1 is very easy to implement > while OAEP isn't. Moving to AES is easy (grab Brian Gladman's reference > implementation and spend 10 minutes glueing into your existing code), however > there's no reference implementation for OAEP which means that everyone planning > to switch to it has to invest a considerable amount of effort into figuring out > what OAEP actually does (the P1363-style description is almost impenetrable to > anyone outside the P1363 WG) and then making sure that what they've implemented > is correct. The lack of other implementations to test against doesn't help > (there are some test vectors floating around somewhere, although they're not > part of the PKCS #1 RFC so it's not even easy to check the code you've > written). > > What could really help its adoption is a freely available reference > implementation to mirror the AES implementation. Until then, with no installed > base, no easily-locatable test vectors, and a lot of work required to add it, I > can't see it taking off. > > Peter (who started playing with an implementation ages ago but never finished > it when he realised that doing so would be pretty pointless. If I ever > get time to finish it I'll make it freely available). > > > > --- > You are currently subscribed to ietf-tls as: gstark@ethentica.com > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 13:29:11 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13933 for ; Fri, 1 Jun 2001 13:29:10 -0400 (EDT) Date: Fri, 1 Jun 2001 18:29:22 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rhousley@rsasecurity.com on Fri, Jun 01, 2001 at 09:47:09AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010601182921.A6810@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Housley, Russ wrote: > [ I wrote: ] > > It would be more "elegant" if the same mechanisms were used in all the > > protocols. It would also allow more code reuse. Do you have other > > reasons for supporting this? > No. I believe that a set of well-studied algorithms can provide the core > capabilities for IETF security protocols. Of course, they will have to > change over time to keep up with computing and analytical advances. In the > near future, I would like to see RSA-OAEP and AES as two of those core > algorithms. I'm afraid I still don't see where the sense of urgency is coming from. There have been lots of ideas debated on this list over the past year or so. Some of them would be very beneficial, like the DNS name extension. However, the WG has limited time and so for better or worse these ideas are "queued up" to be looked at in the future. To be honest OAEP is not my top priority. Sure, in an ideal world, we would sort out a migration path, but there are far more important things to worry about. OAEP delivers no benefits to the end user. Things like the DNS name extension would deliver an immediate tangible benefit. AES delivers a tangible benefit in a different way because it allows TLS-based solutions to comply with government tenders. > I would be willing to [ write a new I-D ], but as I have already > stated, I believe that it is important to take advantage of the > momentum that AES has created. If people are interested in seeing OAEP adopted it won't need to use the momentum AES has created. If people aren't interested then it won't get adopted, but that's the way it should be. It's taken nearly a year and a lot of frustration to get the AES draft this far. Of course, errors have to be corrected at any stage of the process, but I don't think we should be adding extra material on. People doing government contracts need AES ciphersuites ASAP. So I suggest we get AES through and consider other protocol enhancements separately. -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 13:52:42 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14684 for ; Fri, 1 Jun 2001 13:52:40 -0400 (EDT) Message-ID: Date: Fri, 01 Jun 2001 16:14:54 +0100 From: David Hopwood Reply-To: "IETF Transport Layer Security WG" X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" CC: James.H.Manger@team.telstra.com Subject: [ietf-tls] RSA-OAEP in TLS (was Re: WG Last Call for "AES Ciphersuites for TLS") Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3B17B16E.91B3C997@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bodo Moeller wrote: > On Thu, May 31, 2001 at 11:35:43AM -0400, Housley, Russ wrote: > [...] > > On the other hand, RSA-OAEP is being used in many areas. [...] > > I am proposing a well studied, and reasonably well adopted technique as > > the successor to PKCS#1 v1.5 for TLS. > > RSA-OAEP is "well-studied" only as of the next CRYPTO conference. > The original security argument was recently found to be flawed [1], a > new proof relying on a stronger assumption was given later [2]. I suppose I'm being a bit pedantic here, but technically [2] does not make a stronger assumption; it gives a looser reduction. Four things need to be taken account when interpreting a security proof: - whether the proof is correct (not to be taken for granted!) - the strength of the assumptions, - the "model" in which the proof is set (standard, random oracle, generic group, etc.) - the tightness of the reduction from breaking the assumptions to breaking the scheme. In addition, standards committees have a nasty habit of making changes to schemes that have the effect of breaking the security proof. However, I fully agree with the point that OAEP, at least until *very* recently, has not been "well studied". In fact, it is a good case study in the difficulties involved in verifying and interpreting security proofs. > CRYPTO 2001 also has a paper "A Chosen Ciphertext Attack On RSA > Optimal Asymmetric Encryption Padding (OAEP) as Standardized In PKCS #1" > by James Manger. I am not aware of any preprints of this one, or > of the details of the attack. Interesting. I've cc:d James Manger; perhaps he can give a brief description. > [1] Victor Shoup: "OAEP Reconsidered". -- CRYPTO 2001, to appear. > Preprint available from and > . > > [2] Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval and Jacques Stern: > "RSA-OAEP is Secure Under the RSA Assumption" -- CRYPTO 2001, to appear. > Preprint available from . -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 14:07:32 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15049 for ; Fri, 1 Jun 2001 14:07:31 -0400 (EDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Sender: bounce-ietf-tls-3458737@lists.certicom.com Reply-To: "IETF Transport Layer Security WG" X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Sat, 2 Jun 2001 06:07:43 (NZST) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <99141886314466@kahu.cs.auckland.ac.nz> X-List-Host: SKYLIST.net Pete Chown writes: >If people are interested in seeing OAEP adopted it won't need to use the >momentum AES has created. If people aren't interested then it won't get >adopted, but that's the way it should be. Unfortunately what that means is that it's not going to be adopted (it's been around (and ignored) for several years, without some incentive to adopt it this won't change). Russ' point is that if you're going to go through the trauma of moving to AES you may as well switch to OAEP as well. As an implementor I'm not thrilled with having to put in a lot of work to implement something which doesn't offer any practical advantages to what I've already got (the OpenSSL implementation will help ease the pain), but like Y2K, the AES move is a good excuse to upgrade various other bits and pieces at the same time. Peter. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 14:19:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15341 for ; Fri, 1 Jun 2001 14:19:46 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 01 Jun 2001 11:26:13 -0700 In-Reply-To: pgut001@cs.auckland.ac.nz's message of "Sat, 2 Jun 2001 06:07:43 (NZST)" Message-ID: Lines: 26 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Pete Chown writes: > > >If people are interested in seeing OAEP adopted it won't need to use the > >momentum AES has created. If people aren't interested then it won't get > >adopted, but that's the way it should be. > > Unfortunately what that means is that it's not going to be adopted > (it's been around (and ignored) for several years, without some > incentive to adopt it this won't change). Russ' point is that if > you're going to go through the trauma of moving to AES you may as > well switch to OAEP as well. As an implementor I'm not thrilled > with having to put in a lot of work to implement something which > doesn't offer any practical advantages to what I've already got (the > OpenSSL implementation will help ease the pain), but like Y2K, the > AES move is a good excuse to upgrade various other bits and pieces > at the same time. I agree with this in theory but it's going to be really irritating if we add OAEP and then it turns out that there's some other thing we need to replace it with. The title of Manger's paper as quoted by Bodo thus makes me pretty nervous. I'd sure like to be certain that OAEP was good before we shove it in. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 1 15:04:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16449 for ; Fri, 1 Jun 2001 15:04:51 -0400 (EDT) Date: Fri, 1 Jun 2001 12:04:52 -0700 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re: WG Last Call for "AES Ciphersuites for TLS" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from ekr@speedy.rtfm.com on Fri, Jun 01, 2001 at 11:26:13AM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010601120452.B3931@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Fri, Jun 01, 2001 at 11:26:13AM -0700, Eric Rescorla wrote: > pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > > > Pete Chown writes: > > > > >If people are interested in seeing OAEP adopted it won't need to use the > > >momentum AES has created. If people aren't interested then it won't get > > >adopted, but that's the way it should be. > > > > Unfortunately what that means is that it's not going to be adopted > > (it's been around (and ignored) for several years, without some > > incentive to adopt it this won't change). Russ' point is that if > > you're going to go through the trauma of moving to AES you may as > > well switch to OAEP as well. As an implementor I'm not thrilled > > with having to put in a lot of work to implement something which > > doesn't offer any practical advantages to what I've already got (the > > OpenSSL implementation will help ease the pain), but like Y2K, the > > AES move is a good excuse to upgrade various other bits and pieces > > at the same time. > I agree with this in theory but it's going to be really irritating > if we add OAEP and then it turns out that there's some other thing > we need to replace it with. The title of Manger's paper as quoted > by Bodo thus makes me pretty nervous. I'd sure like to be certain > that OAEP was good before we shove it in. Read Shoups paper ("OAEP Reconsidered", pointer was in Bodo Moeller's email). According to it, the OEAP security proof has a hole in it. He proposes an OEAP+ which has a better proof. If the only advantage to OAEP is it's proveable security then it sounds like waiting would be a good idea. I agree with Peter's post about implementing OAEP- it's a pain in the ass especially with no test vectors. Eric --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 2 03:19:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09909 for ; Sat, 2 Jun 2001 03:19:47 -0400 (EDT) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "31 May 2001 22:20:58 MST." Date: Sat, 02 Jun 2001 16:19:57 +0900 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106020719.QAA23955@blue.h2np.net> X-List-Host: SKYLIST.net Eric said: > If the WG consensus is that we need another, the other AES > candidates would be the obvious choices. I understand your opinion. We may select 2 ciphers from AES candidates, Serpent and Twofish, because those ciphers are secure and have free license. So, we may use GPL lisenced source codes of Serpent and Twofish. But I guess many cryptographers never select MARS and RC6. I show 2 data which came from the NIST's survey of 3rd AES confernece. SHOULD AES http://h2np.net/hironobu/docs/AESSea2000July3.files/v3_slide0013_image009.gif SHOULD NOT AES http://h2np.net/hironobu/docs/AESSea2000July3.files/v3_slide0014_image010.gif I like Serpent but Serpent is too slow under small network computers like a PDA. Twofish is a good cipher but nobody proposed to TLS WG yet. Cemellia is a good cipher for TLS too. Camellia is newer than other AES candidates. But it's bulit on E2 and MISTY technologies. E2 was one of AES candidates and has no vulnerability. MISTY was developed by Mituru Matsui who is well known as a developer of Liner Crypto Analysis and the first DES breaker. Camellia is a AES style cipher, a very secure, fast and small S/H implementation. Some advantage of Camellia as below Flexible: Choice small or fast for software implementation. Fast: As fast as Twofish. Small S/W: Better than any AES finalist with resonable speed. Small H/W: Better than any AES finalist. Twofish is a good cipher. Camellia is a good cipher too and has some advantages. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://www.pp.iij4u.or.jp/~h2np/ URL: http://h2np.net --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 2 11:18:29 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11878 for ; Sat, 2 Jun 2001 11:18:28 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 02 Jun 2001 08:24:54 -0700 In-Reply-To: Hironobu SUZUKI's message of "Sat, 02 Jun 2001 16:19:57 +0900" Message-ID: Lines: 23 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Hironobu SUZUKI writes: > But I guess many cryptographers never select MARS and RC6. I show 2 > data which came from the NIST's survey of 3rd AES confernece. Presumably this argument applies a fortiori to Camellia, since it's predecessor, E2, didn't even make it to the final five. > I like Serpent but Serpent is too slow under small network computers > like a PDA. Twofish is a good cipher but nobody proposed to TLS WG > yet. That's easily fixed. I suspect that the reason for this is that it's widely believed that we don't need another AES-style cipher in TLS, not that Twofish is considered unacceptable. I'm not convinced that we need another AES-style cipher in TLS, since we have 3DES as a fallback. If you want to argue that we need another one, then that's fine. However, this is not a particularly strong argument for Camellia since other ciphers are rather more obvious choices. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 3 02:18:50 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29135 for ; Sun, 3 Jun 2001 02:18:49 -0400 (EDT) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "02 Jun 2001 08:24:54 MST." Date: Sun, 03 Jun 2001 14:42:43 +0900 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106030542.OAA26539@blue.h2np.net> X-List-Host: SKYLIST.net > Presumably this argument applies a fortiori to Camellia, since it's > predecessor, E2, didn't even make it to the final five. Technically, many cryptographers have thought that E2 has more security margin than MARS or RC6, but it's true that E2 is slower than other finalists except Serpent. From my point of view, MARS is a ill designed cipher and RC6 is too small security margin. > I'm not convinced that we need another AES-style cipher in TLS, > since we have 3DES as a fallback. Your opinion sounds a sort of backward-looking way of thinking. I'm thinking that AES, I mean Rijndael, should be as a fallback cipher. Camellia for TLS is worth considering(and Twofish also). -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://www.pp.iij4u.or.jp/~h2np/ URL: http://h2np.net --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 3 10:14:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09692 for ; Sun, 3 Jun 2001 10:14:27 -0400 (EDT) Date: Sun, 3 Jun 2001 17:11:02 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" cc: IETF Transport Layer Security WG Subject: [ietf-tls] RE: On doing TLS 1.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On 31 May 2001, Eric Rescorla wrote: > "Andreas Sterbenz" writes: > > > What's wrong with the PRF function? > > Some people on the list have argued that it is unneccessarily complex and I > > tend to agree. > Unfortunately, the reason it's so complex is that it was provided to > us by Hugo's group and is therefore allegedly free of theoretical > weaknesses. :( > Eric, your memeory is wrong. That isn't the reason it is so complex. Actually, back in 96 I was the one to oppose the mix of the two functions especially that at the time the definition of the prf was using a mix that actually gave you security of the WEAKEST of the two hashes rather than of the best. This issue was later resolved (to its current form) by the proposal of Dan Simon to change the mix to a XOR of both hashes which does achieve the property of having a PRF that remains secure as long as one of the two hashes remains secure. Even then I thought it is overkill but only because I speculated (and still do) that if one day SHA-1 is broken as a prf then MD5 will probably be broken too or, at least, our confidence in it will vanish. For those interested in history I am attaching a note from Dan that I kept in my folder where he makes his XOR proposal for the hash mix, i.e. the one that was finally adopted in TLS 1.0 (note his reference to my advise against the combination of two hash functions and our shared reservations: "If it is still deemed necessary that the PRF's security depend on the stronger of two hash functions rather than on just one...") Coming back to the present (and even to the future) I have no problem with the security of the current XOR-based mix, but if someone wants to go to a single hash (for saving complexity) I would certainly not oppose that. Hugo The historical note by Dan Simon: > Date: Wed, 12 Mar 1997 16:30:47 -0800 > Message-Id: <816EC6EBDE7BCF11BE3308002BB690AC015442BA@RED-92-MSG.dns.microsoft.com> > From: Dan Simon > Subject: RE: WG LAST CALL for draft-ietf-tls-protocol-01.txt [.....] > Moreover, the actual choice of PRF defined in the spec (and based on the > one used in SSL 3.0) has a couple of disadvantages. For one, it relies > on a newly defined "HMAC_mix" function which has not been defined > previously elsewhere and is defined only sketchily in the draft. More > importantly, it is precisely the one which Hugo explicitly advised > against, because the mixing of two hash functions in the PRF > construction makes it dependent upon the security of *both* (rather than > either) of them. It would be better to define the PRF in terms of a > single (replaceable) hash function specified by the cipher suite than to > mix two functions in this way. If it is still deemed necessary that the > PRF's security depend on the stronger of two hash functions rather than > on just one, then xoring the PRF outputs of two separate PRFs > constructed from different hash functions (with each given different > secrets as input) should suffice. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 3 10:16:21 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09703 for ; Sun, 3 Jun 2001 10:16:19 -0400 (EDT) Date: Sun, 3 Jun 2001 17:16:41 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA09703 Another one... On 30 May 2001, Eric Rescorla wrote: > "Andreas Sterbenz" writes: > > I would suggest that this working group takes on TLS 1.1 and fixes the > > (arguably) theoretical cryptographic weaknesses in the protocol and improves > > protocol efficiency. My list of topics would include the Bodo Möller > > handshake attack, MACing before encrypting (insecure according to Krawczyk), > I'd like to hear an argument as to why MACing before encrypting is > a problem. It's relatively standard practice. It is quite standard practice but it turns out not to be a good one. In a couple of days I will post my paper on the Web and then I'll write a note to this list explaining a bit about the new findings. Hugo --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 3 18:53:39 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11546 for ; Sun, 3 Jun 2001 18:53:38 -0400 (EDT) Date: Mon, 4 Jun 2001 00:53:53 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: RSA-OAEP in TLS (was Re: WG Last Call for "AES Ciphersuites for TLS") Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from david.hopwood@zetnet.co.uk on Fri, Jun 01, 2001 at 04:14:54PM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010604005353.B29684@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Fri, Jun 01, 2001 at 04:14:54PM +0100, David Hopwood wrote: > Bodo Moeller wrote: >> RSA-OAEP is "well-studied" only as of the next CRYPTO conference. >> The original security argument was recently found to be flawed [1], a >> new proof relying on a stronger assumption was given later [2]. > I suppose I'm being a bit pedantic here, but technically [2] does not > make a stronger assumption; it gives a looser reduction. You are absolutely right. For OAEP in general, [2] makes a stronger assumption; but in the specific case of RSA-OAEP, this amounts to a looser reduction for the same assumption. [Nitpicking OD: Even more technically, in terms of exact security a looser reduction implies a stronger assumption.] [...] > In addition, standards committees have a nasty habit of making changes > to schemes that have the effect of breaking the security proof. Actually in some cases it were the inventors of the methods who introduced such errors. (E.g., see Marc Joye, Jean-Jacques Quisquater, Moti Yung: "On the Power of Misbehaving Adversaries and Security Analysis of the Original EPOC" -- CT-RSA 2001, LNCS 2020, 208--222.) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 3 23:33:52 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15508 for ; Sun, 3 Jun 2001 23:33:51 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: On doing TLS 1.1 Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 03 Jun 2001 20:40:32 -0700 In-Reply-To: Hugo Krawczyk's message of "Sun, 3 Jun 2001 17:11:02 +0300 (IDT)" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Hugo Krawczyk writes: > On 31 May 2001, Eric Rescorla wrote: > > > "Andreas Sterbenz" writes: > > > > What's wrong with the PRF function? > > > Some people on the list have argued that it is unneccessarily complex and I > > > tend to agree. > > Unfortunately, the reason it's so complex is that it was provided to > > us by Hugo's group and is therefore allegedly free of theoretical > > weaknesses. :( > > > > Eric, your memeory is wrong. That isn't the reason it is so complex. > Actually, back in 96 I was the one to oppose the mix of the two functions > especially that at the time the definition of the prf was using a mix that > actually gave you security of the WEAKEST of the two hashes rather than of > the best. It depends where you believe the complexity lies. If you mean using both digests, yes, that's been there since SSLv3. However, the PRF itself came from you (see your message of Friday, Dec 27 to ietf-tls). I've always viewed that as being the complex part, but I can see how you would think differently. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 3 23:49:38 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15727 for ; Sun, 3 Jun 2001 23:49:37 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 03 Jun 2001 20:56:16 -0700 In-Reply-To: Hironobu SUZUKI's message of "Sun, 03 Jun 2001 14:42:43 +0900" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Hironobu SUZUKI writes: > > I'm not convinced that we need another AES-style cipher in TLS, > > since we have 3DES as a fallback. > > Your opinion sounds a sort of backward-looking way of thinking. I'm > thinking that AES, I mean Rijndael, should be as a fallback > cipher. Could you please clarify this? As far as I can tell, the intention is that AES will be the stadard block cipher for TLS (replacing 3DES). > Camellia for TLS is worth considering(and Twofish also). Why? The reason for adding AES is that 3DES is too slow. AES fills the niche of a fast block cipher quite well. Why is there a need to add Twofish, Camellia, or any other cipher that fills the same niche as AES? -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 08:18:24 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04707 for ; Mon, 4 Jun 2001 08:18:24 -0400 (EDT) Message-ID: From: David Blaker To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Date: Mon, 4 Jun 2001 08:18:21 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <49B96FCC784BC54F9675A6B558C3464E3A5F3F@MAIL.NetOctave.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I concur with Eric. Our company builds high-performance network security processors. I realize it has always been the ietf's policy to disregard hardware issues and only worry about software issues. However, as a practical matter, SSL/TLS is increasingly used with hardware acceleration at the server end. Proliferating cipher suites are impractical for ASIC development. We see no need for any additional encryption beyond AES with 3DES as a fallback. _________________________________________ David Blaker, CTO NetOctave, Inc. P.O. Box 14824 Research Triangle Park, NC 27709 Phone (919) 463-9903 x.206 / Fax (919) 463-9905 email mailto:dblaker@netoctave.com website http://www.netoctave.com -----Original Message----- From: Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Sunday, June 03, 2001 11:56 PM To: IETF Transport Layer Security WG Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Hironobu SUZUKI writes: > > I'm not convinced that we need another AES-style cipher in TLS, > > since we have 3DES as a fallback. > > Your opinion sounds a sort of backward-looking way of thinking. I'm > thinking that AES, I mean Rijndael, should be as a fallback > cipher. Could you please clarify this? As far as I can tell, the intention is that AES will be the stadard block cipher for TLS (replacing 3DES). > Camellia for TLS is worth considering(and Twofish also). Why? The reason for adding AES is that 3DES is too slow. AES fills the niche of a fast block cipher quite well. Why is there a need to add Twofish, Camellia, or any other cipher that fills the same niche as AES? -Ekr --- You are currently subscribed to ietf-tls as: DBlaker@NetOctave.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 11:12:45 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09520 for ; Mon, 4 Jun 2001 11:12:44 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "Mon, 04 Jun 2001 08:18:21 -0400." Date: Tue, 05 Jun 2001 00:12:06 JST From: Shiho MORIAI List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106041512.AAA22647@sucaba.isl.ntt.co.jp> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Mon, 4 Jun 2001, at 08:18:21 -0400, David Blaker wrote: >I concur with Eric. Our company builds high-performance network security >processors. I realize it has always been the ietf's policy to disregard >hardware issues and only worry about software issues. Your comment is to the point. "Don't ignore hardware" says Mitsuru Matsui, who is one of the designers of Camellia and also participated in designing KASUMI, the 3GPP standard cipher for confidentiality and authentication. >However, as a practical matter, SSL/TLS is increasingly used with >hardware acceleration at the server end. Proliferating cipher suites >are impractical for ASIC development. We see no need for any >additional encryption beyond AES with 3DES as a fallback. A distinguishing feature of Camellia is its small hardware design. The hardware design, which includes the parts for key schedule, encryption and decryption, occupies only 9.66K gates using a 0.35um CMOS ASIC library, which is in the smallest class among all existing 128-bit block ciphers. So, addition of camellia cipher suites will be allowable from hardware viewpoint. I don't know why most of the new ciphersuites are rejected. It is meaningful to adopt new designs and results based on progress in cryptgraphic techniques and research, isn't it? Is it so difficult to add them as options? Some people need RSA-OAEP, and others need Camellia. I hear that some TLS products with Camellia are being developed. Camellia is also proposed as one of the cryptographic techniques to be used in the electronic government system of Japan. Japanese government has no choice but AES or slow 3DES or other patented bulk ciphers? Shiho --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 11:20:27 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09637 for ; Mon, 4 Jun 2001 11:20:26 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Cc: shiho@sucaba.isl.ntt.co.jp Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 04 Jun 2001 08:27:11 -0700 In-Reply-To: Shiho MORIAI's message of "Tue, 05 Jun 2001 00:12:06 JST" Message-ID: Lines: 13 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Shiho MORIAI writes: > Some people need RSA-OAEP, and others need > Camellia. I don't hear much of a groundswell that we NEED OAEP either. > I hear that some TLS products with Camellia are being > developed. Camellia is also proposed as one of the cryptographic > techniques to be used in the electronic government system of Japan. > Japanese government has no choice but AES or slow 3DES or other > patented bulk ciphers? What's wrong with AES that you would need something else? -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 13:46:09 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14233 for ; Mon, 4 Jun 2001 13:46:08 -0400 (EDT) Message-ID: Date: Mon, 04 Jun 2001 16:08:06 +0100 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B1BA456.573B4903@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Shiho MORIAI wrote: > On Mon, 4 Jun 2001, at 08:18:21 -0400, > David Blaker wrote: > > >However, as a practical matter, SSL/TLS is increasingly used with > >hardware acceleration at the server end. Proliferating cipher suites > >are impractical for ASIC development. We see no need for any > >additional encryption beyond AES with 3DES as a fallback. > > A distinguishing feature of Camellia is its small hardware design. If Camellia ciphersuites are added then hardware will have to implement *both* Camellia and AES (possibly also 3DES and RC4). So small size in hardware is not a valid reason to add any new ciphersuites. > I don't know why most of the new ciphersuites are rejected. Complexity. All else being equal, a standard with fewer ciphersuites is a simpler standard, both from the point of view of security analysis, and of implementation. > It is meaningful to adopt new designs and results based on progress in > cryptgraphic techniques and research, isn't it? Is it so difficult to > add them as options? Some people need RSA-OAEP, No-one needs RSA-OAEP. As I've pointed out, it has no security advantages over the current ciphersuites with the RFC 2246 fix. > and others need > Camellia. I hear that some TLS products with Camellia are being > developed. Camellia is also proposed as one of the cryptographic > techniques to be used in the electronic government system of Japan. As are AES and 3DES, according to the CRYPTREC pages (http://www.ipa.go.jp/security/enc/CRYPTREC/index-e.html). > Japanese government has no choice but AES or slow 3DES or other > patented bulk ciphers? and RC4. Why is that insufficient choice? Adding more symmetric ciphers will do nothing to improve the security or practicality of TLS. There are more important changes that would improve security (for instance to ensure that a strong ciphersuite with forward secrecy will be negotiated in as many cases as possible - i.e. except when talking to an "old" peer implementation that doesn't support any such ciphersuite). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOxuj3TkCAxeYt5gVAQGhJwgAwX6cjqhEwzv317eQavFakpBo/OY+H9Nz 7cmPQVbmJfHMUamP6raBO5rFgsIYtP+JuO7HQ3oM8bzqgSr0uTLmwiuJyCddPthF qIx4R1eot9ZYarwcElF66p1fJdvnANbZYp+U6yysDjyZ7nWB6svPg6Gd87X75kPF qZJYeeec4ZfKaH7sm20tYeCAm/YFmreU2vbyVjBMCpnQLRJAMw1mCyCXuc2ostF3 CwqtNTJjagqDXvnqweeyj/t8ItaObYIBKB+DLCMK08ImI09vxqHWewBM7ZtiaOTz /USz0+IfgCaIiTCNg99YlOWu99jHaxeObfrEffy7Z9BcZ4dAu+zBTw== =SYWv -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 15:31:53 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16218 for ; Mon, 4 Jun 2001 15:31:52 -0400 (EDT) Date: Mon, 4 Jun 2001 12:31:45 -0700 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] draft-ietf-tls-wireless-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010604123145.A16995@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net What's the status of draft-ietf-tls-wireless-00.txt? It's recently expired, but various people here on the TLS list have implied that there will be a revised version out soon. I'm writing an I-D to propose using the generic extension mechanisim from draft-ietf-tls-wireless-00.txt to allow negotiation of a simpler PRF function, and I'd like to refer to draft-ietf-tls-wireless-00.txt or its successor. Also, I've found a small potential problem in draft-ietf-tls-wireless-00.txt. Section 3.5 (truncated MACs) specifies the following in the "unknown_extensions" field: MACTruncation MACTruncations<0..2^8-1>; struct { MACAlgorithm mac_type; uint16 trucation_size_in_bits } MACTruncation; enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm; What's potentially confusing is the MAC specification... what happens if sha1 is specified in MACTruncation and the pending ciphersuite is say TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5? Would md5 or sha1 be used? Or should MACTruncation.MAC_type always match the hash algorithim in the pending ciphersuite? Unless there's a reason why MACTruncation.MAC_type is there, I'd suggest dropping it and always using the hash that's been negotiated as part of the ciphersuite. Eric --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 16:46:05 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19024 for ; Mon, 4 Jun 2001 16:46:04 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 04 Jun 2001 16:45:42 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010604162729.01fc49e0@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Bodo: Optimal Asymmetric Encryption Padding (OAEP) can be combined with any trapdoor one-way function, not just the RSA function. However, it is typically combined with the RSA function, as in RSA-OAEP. The original OAEP paper proved that OAEP provided a certain level of provable security, and conjectured that it provided a higher level of security. [1] shows that the conjecture does not hold for an arbitrary trapdoor one-way functions. [2] shows that the conjecture does hold when the trapdoor one-way function is RSA. The results to be presented at CRYPTO 2001 thus confirm the security of RSA-OAEP. Please see http://www.rsalabs.com/rsa_algorithm/oaep_security.html for further discussion. Manger's result confirms that an implementation of RSA-OAEP decryption must not reveal whether the first byte of the output of the RSA decryption primitive is 0. This point was previously observed in PKCS #1 v2.1 draft 2. The result is not an attack on RSA-OAEP itself as it does not affect correct implementations of RSA-OAEP. Manger has not released a preprint of his paper yet, but he has indicated in correspondence with RSA Laboratories that this synopsis may be shared with standards bodies. Also, RSA-OAEP also does not raise any patent issues. Russ At 12:12 PM 6/1/2001 +0200, Bodo Moeller wrote: >On Thu, May 31, 2001 at 11:35:43AM -0400, Housley, Russ wrote: > > On the other hand, RSA-OAEP is being used in many areas. [...] > > I am proposing a well studied, and reasonably well adopted technique as > the > > successor to PKCS#1 v1.5 for TLS. > >RSA-OAEP is "well-studied" only as of the next CRYPTO conference. >The original security argument was recently found to be flawed [1], a >new proof relying on a stronger assumption was given later [2]. >CRYPTO 2001 also has a paper "A Chosen Ciphertext Attack On RSA >Optimal Asymmetric Encryption Padding (OAEP) as Standardized In PKCS #1" >by James Manger. I am not aware of any preprints of this one, or >of the details of the attack. Anyone? > > >[1] Victor Shoup: "OAEP Reconsidered". -- CRYPTO 2001, to appear. > Preprint available from and > . > >[2] Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval and Jacques Stern: > "RSA-OAEP is Secure Under the RSA Assumption" -- CRYPTO 2001, to appear. > Preprint available from . --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 17:25:59 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19538 for ; Mon, 4 Jun 2001 17:25:58 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Message from Shiho MORIAI of 5 Jun 2001 0:12:06 +0200 Date: Mon, 04 Jun 2001 17:23:46 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106042123.f54LNsb01690@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net First, I don't hear a consensus (rough or otherwise) for advancing the Camellia ciphersuite specification for TLS as a Proposed Standard. Given that, are there implementers out there who want to include Camellia in interoperable TLS implementations? If so, should the draft be published as an Informational RFC to reserve ciphersuite identifiers? (Note for those who may recall earlier discussions about ciphersuites: the IANA isn't going to register them, so it falls to the working group.) Win Treese Chair, TLS Working Group treese@acm.org --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 21:04:06 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22445 for ; Mon, 4 Jun 2001 21:04:05 -0400 (EDT) Date: Mon, 4 Jun 2001 21:03:52 -0400 From: Peter W To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from hironobu@h2np.net on Tue, Jun 05, 2001 at 09:42:12AM +0900 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010604210352.A2559@usa.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Tue, Jun 05, 2001 at 09:42:12AM +0900, Hironobu SUZUKI wrote: > > > Why is there a need to add Twofish, Camellia, or any other cipher > > that fills the same niche as AES? > > I'm thinking for the expanding reliability of TLS for the > future. Also, I'm thinking about better security for TLS users. I think David Hopwood said this best: all things being equal, simple is better than complex. If neither Camellia nor RSA-OAEP offer significant benefits (e.g., address needs or desires unmet by other ciphers), then adding them is a bad idea. -Peter --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 21:22:43 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22664 for ; Mon, 4 Jun 2001 21:22:42 -0400 (EDT) Message-Id: From: Hironobu SUZUKI To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message of "03 Jun 2001 20:56:16 MST." Date: Tue, 05 Jun 2001 09:42:12 +0900 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106050042.JAA30657@blue.h2np.net> X-List-Host: SKYLIST.net > Why is there a need to add Twofish, Camellia, or any other cipher > that fills the same niche as AES? I'm thinking for the expanding reliability of TLS for the future. Also, I'm thinking about better security for TLS users. -- Hironobu SUZUKI Independent Software Consultant E-Mail: hironobu@h2np.net URL: http://h2np.net --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 4 21:34:00 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22990 for ; Mon, 4 Jun 2001 21:33:59 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 04 Jun 2001 18:06:44 -0700 In-Reply-To: Hironobu SUZUKI's message of "Tue, 05 Jun 2001 09:42:12 +0900" Message-ID: Lines: 11 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Hironobu SUZUKI writes: > > Why is there a need to add Twofish, Camellia, or any other cipher > > that fills the same niche as AES? > > I'm thinking for the expanding reliability of TLS for the > future. Also, I'm thinking about better security for TLS users. These are both laudable goals but I fail to see how adding more cipher suites achieves them. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 08:06:08 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16573 for ; Tue, 5 Jun 2001 08:06:06 -0400 (EDT) Date: Tue, 5 Jun 2001 13:31:15 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from david.hopwood@zetnet.co.uk on Mon, Jun 04, 2001 at 04:08:06PM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010605133115.E795@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Jun 04, 2001 at 04:08:06PM +0100, David Hopwood wrote: >> I don't know why most of the new ciphersuites are rejected. > Complexity. All else being equal, a standard with fewer ciphersuites is > a simpler standard, both from the point of view of security analysis, and > of implementation. Also, with TLS as it is now, ciphersuite numbers would pretty soon be scarce if every symmetric cipher is combined with every key exchange method. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 08:24:09 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17286 for ; Tue, 5 Jun 2001 08:24:08 -0400 (EDT) Message-ID: Date: Tue, 05 Jun 2001 12:50:51 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B1CC79B.75FB21E7@celocom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bodo Moeller wrote: > > On Mon, Jun 04, 2001 at 04:08:06PM +0100, David Hopwood wrote: > > >> I don't know why most of the new ciphersuites are rejected. > > > Complexity. All else being equal, a standard with fewer ciphersuites is > > a simpler standard, both from the point of view of security analysis, and > > of implementation. > > Also, with TLS as it is now, ciphersuite numbers would pretty soon be > scarce if every symmetric cipher is combined with every key exchange > method. > I liked the idea you(?) proposed a while ago of using OIDs for other cipher suites through the proposed extension mechanism. I've lost count of the number of times someone has asked about how to use some weird cipher/digest combination (blowfish is often asked about) or indeed some not so weird combination that is not present in any of the official specs: e.g. DSA with no encryption, RSA+ephemeral DH+RC4 or anonymous RSA. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 08:38:52 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17809 for ; Tue, 5 Jun 2001 08:38:50 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Tue, 5 Jun 2001 04:21:15 -0400 Subject: [ietf-tls] Re: draft-ietf-tls-wireless-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A62.00457BDC.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi Eric, On the MAC truncation issue, I think the MAC.type field may well be useful going forward. As a client, I might prefer not to knowingly weaken the MAC by truncation, and thus be prepared to use 80 bit SHA1 but not 80 bit SHA2. Make sense? The text in the draft was meant to clarify what clients and servers do if something untoward happens ... here's the text: Servers receiving MAC truncation negotiation requests requesting values other than the allowed values, MUST abort the handshake. Similarly clients receiving MAC truncation negotiation responses that differ from the values they suggested, or that do not match the established cipher suite, MUST abort the handshake. Could we address this issue by clarifying this text, and if so, how? Best regards. Simon Eric Murray on 06/04/2001 03:31:45 PM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] draft-ietf-tls-wireless-00.txt What's the status of draft-ietf-tls-wireless-00.txt? It's recently expired, but various people here on the TLS list have implied that there will be a revised version out soon. I'm writing an I-D to propose using the generic extension mechanisim from draft-ietf-tls-wireless-00.txt to allow negotiation of a simpler PRF function, and I'd like to refer to draft-ietf-tls-wireless-00.txt or its successor. 4 Also, I've found a small potential problem in draft-ietf-tls-wireless-00.txt. Section 3.5 (truncated MACs) specifies the following in the "unknown_extensions" field: MACTruncation MACTruncations<0..2^8-1>; struct { MACAlgorithm mac_type; uint16 trucation_size_in_bits } MACTruncation; enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm; What's potentially confusing is the MAC specification... what happens if sha1 is specified in MACTruncation and the pending ciphersuite is say TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5? Would md5 or sha1 be used? Or should MACTruncation.MAC_type always match the hash algorithim in the pending ciphersuite? Unless there's a reason why MACTruncation.MAC_type is there, I'd suggest dropping it and always using the hash that's been negotiated as part of the ciphersuite. Eric --- You are currently subscribed to ietf-tls as: sblakewilson@certicom.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 08:38:58 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17823 for ; Tue, 5 Jun 2001 08:38:56 -0400 (EDT) Date: Tue, 5 Jun 2001 14:39:00 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from rhousley@rsasecurity.com on Mon, Jun 04, 2001 at 04:45:42PM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010605143900.F795@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Jun 04, 2001 at 04:45:42PM -0400, Housley, Russ wrote: > Optimal Asymmetric Encryption Padding (OAEP) can be combined with any > trapdoor one-way function, not just the RSA function. However, it is > typically combined with the RSA function, as in RSA-OAEP. > > The original OAEP paper proved that OAEP provided a certain level of > provable security, and conjectured that it provided a higher level of > security. Well, the original OAEP paper [3] showed that OAEP provides "plaintext awareness" according to a certain definition that was changed by the authors in later papers when they noticed that they had "forgotten to supply the attacker with an [encryption] oracle" [4]. As Shoup [1] showed, it is not likely that a similar security proof is possible under the corrected definition of plaintext awareness. (This problem was overlooked by [4].) [3] claims that [...] demanding awareness of a secure encryption scheme is asking a lot. In the random oracle model, we can show that a plaintext-aware scheme is non-malleable and also secure against chosen-ciphertext attack. We omit proofs of this, but the intuition is quite clear. For example, a chosen-ciphertext attack will not help because the adversary already "knows" the plaintext of any ciphertext y whose decryption she might request from an available decryption box. Nothing of this (except for the fact that they omit proofs :-) is true for the original definition of plaintext awareness used in [3]. The reason is quite simple: The OAEP paper uses a formalization of "provable security" that does not really capture what the authors had intended. It is not as if they had just made a conjecture that turned out not to be true. As mentioned before, while the general security proof for OAEP is not as much of a security proof as its authors had believed, RSA-OAEP was recently rehabilitated by a new, more meaningful security proof [2]. [1] Victor Shoup: "OAEP Reconsidered". CRYPTO 2001, to appear. [2] Eiichiro Fujisaki, Tatsuaki Okamoto, David Pointcheval and Jacques Stern: "RSA-OAEP is Secure Under the RSA Assumption". CRYPTO 2001, to appear. [3] Mihir Bellare, Phillip Rogaway: "Optimal Asymmetric Encryption -- How to Encrypt with RSA", 1994. [4] Mihir Bellare, Phillip Rogaway: "Minimizing the Use of Random Oracles in Authenticated Encryption Schemes", 1995. >> CRYPTO 2001 also has a paper "A Chosen Ciphertext Attack On RSA >> Optimal Asymmetric Encryption Padding (OAEP) as Standardized In PKCS #1" >> by James Manger. I am not aware of any preprints of this one, or >> of the details of the attack. Anyone? > Manger's result confirms that an implementation of RSA-OAEP decryption must > not reveal whether the first byte of the output of the RSA decryption > primitive is 0. This point was previously observed in PKCS #1 v2.1 draft 2. > The result is not an attack on RSA-OAEP itself as it does not affect > correct implementations of RSA-OAEP. Thanks for the information on Manger's paper. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 09:53:34 2001 Received: from 0.0.0.0 ([38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20842 for ; Tue, 5 Jun 2001 09:53:32 -0400 (EDT) X-Lotus-FromDomain: HNS From: dillon@hns.com Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Message-ID: Date: Tue, 5 Jun 2001 09:54:00 -0400 Subject: [ietf-tls] Re: draft-ietf-tls-wireless-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A62.004C9336.00@ngw2.hns.com> X-List-Host: SKYLIST.net I'd be interested in seeing a copy. Does it include compression? Doug.............. Eric Murray @lists.certicom.com on 06/04/2001 03:31:45 PM Please respond to "IETF Transport Layer Security WG" Sent by: bounce-ietf-tls-4215505@lists.certicom.com To: "IETF Transport Layer Security WG" cc: (bcc: Doug Dillon/HNS) Subject: [ietf-tls] draft-ietf-tls-wireless-00.txt What's the status of draft-ietf-tls-wireless-00.txt? It's recently expired, but various people here on the TLS list have implied that there will be a revised version out soon. I'm writing an I-D to propose using the generic extension mechanisim from draft-ietf-tls-wireless-00.txt to allow negotiation of a simpler PRF function, and I'd like to refer to draft-ietf-tls-wireless-00.txt or its successor. Also, I've found a small potential problem in draft-ietf-tls-wireless-00.txt. Section 3.5 (truncated MACs) specifies the following in the "unknown_extensions" field: MACTruncation MACTruncations<0..2^8-1>; struct { MACAlgorithm mac_type; uint16 trucation_size_in_bits } MACTruncation; enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm; What's potentially confusing is the MAC specification... what happens if sha1 is specified in MACTruncation and the pending ciphersuite is say TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5? Would md5 or sha1 be used? Or should MACTruncation.MAC_type always match the hash algorithim in the pending ciphersuite? Unless there's a reason why MACTruncation.MAC_type is there, I'd suggest dropping it and always using the hash that's been negotiated as part of the ciphersuite. Eric --- You are currently subscribed to ietf-tls as: dillon@hns.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 15:39:17 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29107 for ; Tue, 5 Jun 2001 15:39:16 -0400 (EDT) Date: Tue, 5 Jun 2001 12:38:51 -0700 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-wireless-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from dillon@hns.com on Tue, Jun 05, 2001 at 09:54:00AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010605123851.B22874@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Tue, Jun 05, 2001 at 09:54:00AM -0400, dillon@hns.com wrote: > > > > I'd be interested in seeing a copy. Does it include compression? Compression is already in the TLS spec. (section 6.2.2 and others). But to my knowledge it hasn't actually been used. Eric --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 16:12:23 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29445 for ; Tue, 5 Jun 2001 16:12:21 -0400 (EDT) Date: Tue, 5 Jun 2001 13:12:14 -0700 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: draft-ietf-tls-wireless-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from sblakewilson@certicom.com on Tue, Jun 05, 2001 at 04:21:15AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010605131214.D22874@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Tue, Jun 05, 2001 at 04:21:15AM -0400, Simon Blake-Wilson wrote: > Hi Eric, > > On the MAC truncation issue, I think the MAC.type field may well be useful going > forward. As a client, I might prefer not to knowingly weaken the MAC by > truncation, and thus be prepared to use 80 bit SHA1 but not 80 bit SHA2. Make > sense? Yea. > The text in the draft was meant to clarify what clients and servers do if > something untoward happens ... here's the text: > > Servers receiving MAC truncation negotiation requests requesting values > other than the allowed values, MUST abort the handshake. Similarly > clients receiving MAC truncation negotiation responses that differ from > the values they suggested, or that do not match the established cipher > suite, MUST abort the handshake. > > Could we address this issue by clarifying this text, and if so, how? That text is fine, but there needs to be something more that explains what the interaction between the MAC_type field and the hash in the chosen ciphersuite is. I can think of a couple different ways to do it: 1. If one or more truncated_MAC options are sent and the server wants to do MAC truncation, the server must choose a truncated_MAC from the list provided by the client that specifies a MACAlgorithm which matches the hash in the pending ciphersuite (SecurityParameters.mac_algorithm). 2. If one or more truncated_MAC options are sent and the server wants to do MAC truncation, the server must choose a truncated_MAC from the list provided by the client, and the hash in the pending ciphersuite is changed to the MACAlgorithm in the chosen truncated_MAC option. I think that #2 is pretty confusing-- the hash gets renegotiated based on the option, which seems architectually wrong to me. #1 is simpler, but still requires the server to correlate the hash algorithms in the truncated_MAC option(s) against the SecurityParameters.mac_algorithm. The structure of the Ciphersuite specs don't make for easily determining which ones are SHA and which are MD5 (implementations will need another lookup table). My suggestion (simply using the hash that's specified in the pending ciphersuite) would still allow a client to spec truncation to 80 bits for sha1 and not for sha2-- but only by sending either sha1 ciphersuites and a truncated_MAC option for truncation to 80 bits, or sha2 ciphersuites and no truncated_MAC option (or one for more bits if the client feels that's what's secure). That's not exactly straightforward either. #1 is my preferered option given that it's harder to shoot oneself in the foot with it. Eric > > Best regards. Simon > > > > > > Eric Murray on 06/04/2001 03:31:45 PM > > Please respond to "IETF Transport Layer Security WG" > > > To: "IETF Transport Layer Security WG" > cc: (bcc: Simon Blake-Wilson/Certicom) > > Subject: [ietf-tls] draft-ietf-tls-wireless-00.txt > > > > > > > > What's the status of draft-ietf-tls-wireless-00.txt? It's recently > expired, but various people here on the TLS list have implied that there > will be a revised version out soon. > > I'm writing an I-D to propose using the generic extension mechanisim > from draft-ietf-tls-wireless-00.txt to allow negotiation of a simpler > PRF function, and I'd like to refer to draft-ietf-tls-wireless-00.txt > or its successor. > > 4 > > > Also, I've found a small potential problem in draft-ietf-tls-wireless-00.txt. > Section 3.5 (truncated MACs) specifies the following in the "unknown_extensions" > field: > > MACTruncation MACTruncations<0..2^8-1>; > > struct { > MACAlgorithm mac_type; > uint16 trucation_size_in_bits > } MACTruncation; > > enum { null(0), md5(1), sha1(2), (255) } MACAlgorithm; > > What's potentially confusing is the MAC specification... what happens > if sha1 is specified in MACTruncation and the pending ciphersuite is > say TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5? Would md5 or sha1 be used? > Or should MACTruncation.MAC_type always match the hash algorithim in > the pending ciphersuite? > > Unless there's a reason why MACTruncation.MAC_type is there, I'd > suggest dropping it and always using the hash that's been negotiated > as part of the ciphersuite. > > > > Eric > > --- > You are currently subscribed to ietf-tls as: sblakewilson@certicom.com > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com > > > > > > > > --- > You are currently subscribed to ietf-tls as: ericm@lne.com > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 19:47:29 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01640 for ; Tue, 5 Jun 2001 19:47:28 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt X-Face: +m#@ Date: 06 Jun 2001 08:47:42 +0900 Message-ID: Lines: 11 User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (=?ISO-2022-JP?B?GyRCSCxMWkA+OH0bKEI=?=) APEL/10.3 Emacs/21.0.103 (i386-unknown-freebsd5.0) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <86n17mij4x.fsf@victim.isl.ntt.co.jp> X-List-Host: SKYLIST.net > Given that, are there implementers out there who want to include > Camellia in interoperable TLS implementations? If so, should the draft > be published as an Informational RFC to reserve ciphersuite > identifiers? Currently we are implementing an interoperable TLS module including Camellia, by reference to draft-ietf-tls-camellia-01.txt. -- Hiroki Ueda / NTT Labs, JAPAN. -- Je le vois, mais je ne le crois pas! --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 5 20:21:29 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01995 for ; Tue, 5 Jun 2001 20:21:28 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt X-Face: +m#@ Date: 06 Jun 2001 09:21:44 +0900 In-Reply-To: (Bodo Moeller's message of "Tue, 5 Jun 2001 13:31:15 +0200") Message-ID: Lines: 13 User-Agent: T-gnus/6.15.4 (based on Oort Gnus v0.04) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (=?ISO-2022-JP?B?GyRCSCxMWkA+OH0bKEI=?=) APEL/10.3 Emacs/21.0.103 (i386-unknown-freebsd5.0) MULE/5.0 (=?ISO-2022-JP?B?GyRCOC1MWhsoQg==?=) List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <86itiaihk7.fsf@victim.isl.ntt.co.jp> X-List-Host: SKYLIST.net Bodo Moeller writes: > Also, with TLS as it is now, ciphersuite numbers would pretty soon be > scarce if every symmetric cipher is combined with every key exchange > method. What does this word "every" mean? If it means *ALL* (algorithms that ever constructed and that someone will construct), your mention is true. -- Hiroki Ueda / NTT Labs, JAPAN. -- Je le vois, mais je ne le crois pas! --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 6 16:44:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08930 for ; Wed, 6 Jun 2001 16:44:05 -0400 (EDT) Date: Wed, 6 Jun 2001 23:44:33 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] A design weakness of SSL/TLS Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Here is the note I promised the other day regarding the new results that were mentioned in this list: In a paper to be presented in the upcoming CRYPTO'2001 conference (and available at http://eprint.iacr.org/2001/045/) I show that the ORDER of encryption and authentication as applied to the transmitted data by SSL/TLS (i.e, first-mac-then-encrypt) provides a weaker security guarantee than expected. Somewhat surprisingly, it turns out that there are very strong ciphers (e.g. providing Shannon's perfect secrecy) that in combination with any secure MAC (even one with unconditional security) make SSL/TLS vulnerable to attack. Specifically, I present an example of a perfectly-secret encryption function (a seemingly harmless variant of one-time pad encryption) which combined with any secure MAC function under SSL/TLS results in a record-layer protocol where data secrecy can be totally broken by an active attacker (for example it is possible for the attacker to find passwords transmitted under the protection of the protocol, credit card numbers, etc.). This contradicts an important design goal of a generic protocol such as TLS where different cryptographic algorithms may be used. In particular, this principle is reflected in the following statement in RFC 2246: "The TLS protocol is secure, in that any cipher suite offers its promised level of security" This seems to imply that if one chooses a secure encryption function and a secure MAC then the information protected by the protocol should be secured against passive and active attacks. The above result, however, shows that this is not guaranteed, in general, by SSL/TLS. So the bad news are that SSL/TLS is NOT generically secure: plugging in *individually secure* encryption and MAC functions does not guarantee the security of the protocol. Fortunately, there are good news too: in the same paper I prove that if the encryption mode is either CBC encryption (using a secure block cipher) or a traditional stream cipher (which are the two common modes of encryption used in SSL/TLS) then its combination with a secure MAC algorithm under the first-mac-then-encrypt method DOES provide security against passive and active attacks. This means that currently implemented ciphersuites are secure. In other words, THE IDENTIFIED PROBLEM SHOWS A SUBSTANTIAL DESIGN WEAKNESS OF THE PROTOCOL BUT NOT A PRACTICAL FLAW OF *CURRENT* IMPLEMENTATIONS. It is important to note that the above design weakness is not unavoidable: in another recent paper with Canetti (presented at Eurocrypt'2001) we show that using a different ordering of encryption and authentication, i.e. first encrypt the data then apply a MAC to the ciphertext, the obtained protocol IS generically secure, namely secure under the combination of ANY individually-secure encryption and MAC functions. This is the order used, for example, in the ESP protocol of IPSEC. While I feel that these results should be taken into consideration when designing new protocols (for which one should adopt the first-encrypt-then-mac method), it is not clear what effect they should have for a widespread standarized protocol such as SSL/TLS. Specifically for the TLS WG I see several possibilities regarding these findings: (1) Ignore these results (2) Make a note in a future revised version of the RFC about the care needed in choosing ciphertexts or adopting new algorithms or modes even when these changes seem minor and "harmless". (Indeed, while the paper proves the security of current modes it also makes clear how fragile the security of these modes is: for example, encoding data before encryption, or encrypting the data and MAC with separate IVs are enough to render the protocol insecure!) (3) change the order of encryption and authentication in a future version of the protocol (a decision that certainly changes "the bits in the wire"). Doing (2) certainly seems easy. As for (3), it would be very desirable to have a more robust and better-designed protocol but I am not in a position to judge the practical complexity of mandating such a change in widely-deployed standard as TLS. Hugo --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 7 09:23:50 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06669 for ; Thu, 7 Jun 2001 09:23:49 -0400 (EDT) Date: Thu, 7 Jun 2001 11:23:26 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from ueda@isl.ntt.co.jp on Wed, Jun 06, 2001 at 09:21:44AM +0900 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010607112325.A6528@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Wed, Jun 06, 2001 at 09:21:44AM +0900, Hiroki Ueda wrote: > Bodo Moeller writes: >> Also, with TLS as it is now, ciphersuite numbers would pretty soon be >> scarce if every symmetric cipher is combined with every key exchange >> method. > What does this word "every" mean? > If it means *ALL* (algorithms that ever constructed > and that someone will construct), your mention is true. I meant every symmetric cipher specified for use with TLS and every key exchange method specified for use with TLS. Occasionally new ciphersuites for new symmetric ciphers are proposed (e.g. a couple of AES ciphersuites, a couple of Camellia ciphersuites), and occasionally new ciphersuites for new key exchange methods are proposed (e.g. Kerberos, SRP, ECC). As negotiation of these ciphersuite aspects is not orthogonal, if all of these new ciphersuites were accepted, it would be natural to define a bunch of additional ciphersuites for Kerberos key exchange with Camellia encryption, SRP key exchange with Camellia encryption, elliptic curve key exchange with Camellia encryption, and so on. And if someone does not like SHA-1, we can repeat the same game for MACs. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 11:04:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13846 for ; Fri, 8 Jun 2001 11:04:28 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Cc: jis@mit.edu, mleech@nortelnetworks.com Message-Id: X-Sender: rhousley@exna07.securitydynamics.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 08 Jun 2001 08:11:02 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010608080057.01f8c4a0@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I think that this thread has gone off track. I do not think that we should be discussing the level of study that a RSA-OAEP has received. My any measure it exceeds the level of study that PKCS#1 v1.5 has received. The countermeasures that are implemented around PKCS#1 v1.5 allow it to thwart the Million Message Attack. This is great, as it allows the community to make a thoughtful transition instead of a hasty one. The much discussed (on this thread) security proofs of RSA-OAEP illustrate that this algorithm has better properties than PKCS#1 v1.5. It is my understanding that the structure of PKCS#1 v1.5 does lend itself to similar proofs. Therefore RSA-OAEP is much more likely to remain safe in the face of a yet undiscovered attack. I would like to see us be proactive. Migrate to AES and RSA-OAEP together. Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 12:54:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16593 for ; Fri, 8 Jun 2001 12:54:38 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 08 Jun 2001 10:01:19 -0700 In-Reply-To: "Housley, Russ"'s message of "Fri, 08 Jun 2001 08:11:02 -0400" Message-ID: Lines: 29 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net "Housley, Russ" writes: > I think that this thread has gone off track. I do not think that we > should be discussing the level of study that a RSA-OAEP has > received. My any measure it exceeds the level of study that PKCS#1 > v1.5 has received. > > The countermeasures that are implemented around PKCS#1 v1.5 allow it to > thwart the Million Message Attack. This is great, as it allows the > community to make a thoughtful transition instead of a hasty one. > > The much discussed (on this thread) security proofs of RSA-OAEP illustrate > that this algorithm has better properties than PKCS#1 v1.5. It is my > understanding that the structure of PKCS#1 v1.5 does lend itself to similar > proofs. Therefore RSA-OAEP is much more likely to remain safe in the face > of a yet undiscovered attack. > > I would like to see us be proactive. Migrate to AES and RSA-OAEP together. Russ, My concern here is that in six months we'll be hearing from the cryptographers that there's some new algorithm (NOAEP?) that we really should be using instead of OAEP. As you say, the fact that we have countermeasures for 1.5 allows us to make an orderly transition. Part of that orderly transition should be convincing ourselves that there isn't something coming down the pipeline that will force us to displace OAEP. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 13:25:53 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17495 for ; Fri, 8 Jun 2001 13:25:52 -0400 (EDT) Message-ID: From: Mark Winstead To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Date: Fri, 8 Jun 2001 13:26:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <49B96FCC784BC54F9675A6B558C3464E17CF3B@MAIL.NetOctave.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > My concern here is that in six months we'll be hearing from the > cryptographers that there's some new algorithm (NOAEP?) that we > really should be using instead of OAEP. Do OAEP, or don't do OAEP, but don't not do it because in six months there might be a better algorithm. That's like saying you won't buy a computer today because in a month or two you'll be able to get a faster, cheaper computer. If you do that, you'll never replace that 100 MgHz 2 GB hard drive machine on your desk. Mark Winstead Senior Mathematician NetOctave, Inc. P.O. Box 14824 RTP, NC 27709 919.463.9903 x328 mark.winstead@netoctave.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 13:49:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18078 for ; Fri, 8 Jun 2001 13:49:29 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 08 Jun 2001 10:55:41 -0700 In-Reply-To: Mark Winstead's message of "Fri, 8 Jun 2001 13:26:54 -0400" Message-ID: Lines: 25 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Mark Winstead writes: > > My concern here is that in six months we'll be hearing from the > > cryptographers that there's some new algorithm (NOAEP?) that we > > really should be using instead of OAEP. > > Do OAEP, or don't do OAEP, but don't not do it because in six months > there might be a better algorithm. That's like saying you won't buy > a computer today because in a month or two you'll be able to get a > faster, cheaper computer. If you do that, you'll never replace that > 100 MgHz 2 GB hard drive machine on your desk. This simply isn't a useful analogy. We currently have something that does the job just fine (PKCS #1). What OAEP offers over PKCS #1 is the claim that it's provably secure. If that claim doesn't hold up then we shouldn't make the replacement. Thus, we need to be reasonably confident that we're not going to hear in 6 months that the OAEP security proofs are flawed and that we need another construction. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 14:07:26 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18313 for ; Fri, 8 Jun 2001 14:07:24 -0400 (EDT) Message-ID: From: Mark Winstead To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Date: Fri, 8 Jun 2001 14:08:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <49B96FCC784BC54F9675A6B558C3464E17CF3C@MAIL.NetOctave.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net >> > My concern here is that in six months we'll be hearing from the >> > cryptographers that there's some new algorithm (NOAEP?) that we >> > really should be using instead of OAEP. >> >> Do OAEP, or don't do OAEP, but don't not do it because in six months >> there might be a better algorithm. That's like saying you won't buy >> a computer today because in a month or two you'll be able to get a >> faster, cheaper computer. If you do that, you'll never replace that >> 100 MgHz 2 GB hard drive machine on your desk. >This simply isn't a useful analogy. > >We currently have something that does the job just fine (PKCS >#1). What OAEP offers over PKCS #1 is the claim that it's provably >secure. If that claim doesn't hold up then we shouldn't make the >replacement. Thus, we need to be reasonably confident that we're >not going to hear in 6 months that the OAEP security proofs are >flawed and that we need another construction. > >-Ekr But you've missed my point and reinforced it at the same time (and perhaps I missed your original point). My point is rejection of a new algorithm shouldn't be based on the possibility of a better algorithm later. The criteria should lie elsewhere. I'm not arguing for OAEP. Just don't reject OAEP because of the possibility of a better algorithm later. If the consensus is what we've got now gets the job done and OAEP doesn't offer something making the bother of its inclusion worthwhile, then don't add OAEP. Mark --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 14:32:54 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18679 for ; Fri, 8 Jun 2001 14:32:53 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 08 Jun 2001 11:39:38 -0700 In-Reply-To: Mark Winstead's message of "Fri, 8 Jun 2001 14:08:01 -0400" Message-ID: Lines: 18 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Mark Winstead writes: > But you've missed my point and reinforced it at the same time (and > perhaps I missed your original point). My point is rejection of a > new algorithm shouldn't be based on the possibility of a better > algorithm later. The criteria should lie elsewhere. > > I'm not arguing for OAEP. Just don't reject OAEP because of the > possibility of a better algorithm later. If the consensus is what > we've got now gets the job done and OAEP doesn't offer something > making the bother of its inclusion worthwhile, then don't add OAEP. And my point is that I'm not yet convinced that OAEP is going to do the job. I don't want to get half-way through OAEP standardization and then hear from some cryptographer that OAEP isn't secure and we have to go to some new algorithm. I'd rather take a little more time and make sure that OAEP is going to do the job. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 16:15:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20082 for ; Fri, 8 Jun 2001 16:15:45 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 08 Jun 2001 16:14:54 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: References: <"Housley, Russ"'s message of "Fri, 08 Jun 2001 08:11:02 -0400"> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010608161124.01f87c98@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Eric: > > I think that this thread has gone off track. I do not think that we > > should be discussing the level of study that a RSA-OAEP has > > received. My any measure it exceeds the level of study that PKCS#1 > > v1.5 has received. > > > > The countermeasures that are implemented around PKCS#1 v1.5 allow it to > > thwart the Million Message Attack. This is great, as it allows the > > community to make a thoughtful transition instead of a hasty one. > > > > The much discussed (on this thread) security proofs of RSA-OAEP illustrate > > that this algorithm has better properties than PKCS#1 v1.5. It is my > > understanding that the structure of PKCS#1 v1.5 does lend itself to > similar > > proofs. Therefore RSA-OAEP is much more likely to remain safe in the face > > of a yet undiscovered attack. > > > > I would like to see us be proactive. Migrate to AES and RSA-OAEP together. >Russ, > >My concern here is that in six months we'll be hearing from the >cryptographers that there's some new algorithm (NOAEP?) that we >really should be using instead of OAEP. > >As you say, the fact that we have countermeasures for 1.5 allows us to >make an orderly transition. Part of that orderly transition should be >convincing ourselves that there isn't something coming down the >pipeline that will force us to displace OAEP. I certainly welcome the review. And, I suggest that we roll out whatever is selected after that review at the same time that AES is rolled out. Given the recent postings by Hugo, we might want to look at a mode of AES that provides confidentiality and integrity all in one. Such a mode eliminates the concerns about the order of MAC and encrypt operations. Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 17:18:48 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20751 for ; Fri, 8 Jun 2001 17:18:47 -0400 (EDT) Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Fri, 08 Jun 2001 17:16:49 -0400 To: "IETF Transport Layer Security WG" From: "Housley, Russ" Subject: [ietf-tls] Fwd: Re: WG Last Call for "AES Ciphersuites for TLS" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010608171147.020f34e0@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Eric: I asked Burt Kaliski to comment. Here is his reply: The RSA-OAEP security proofs are fine. RSA-OAEP's proofs of security have _improved_ since 1993. The issues, if any, are with OAEP for non-RSA uses, and those are primarily of theoretical interest. Yes, something better may come along, but RSA-OAEP is already in other (draft) standards (IEEE 1363, PKCS #1 v2.0, ANSI X9.44), and also under evaluation by NESSIE, Japan Cryptrec, ISO 18033, whereas the alternatives have yet to settle. Yes, PKCS #1 does the job just fine for resisting MMA with appropriate countermeasures, but it has no proof of security. There won't be another good opportunity to upgrade like this one. Why keep it around longer than necessary? Much of this has already been said on this thread. Burt's point that the issues with the OAEP proof history apply to arbitrary public key algorithms, not RSA is relevant. Maybe we can get Phil Rogaway to chime in ... Russ >> > My concern here is that in six months we'll be hearing from the >> > cryptographers that there's some new algorithm (NOAEP?) that we >> > really should be using instead of OAEP. >> >> Do OAEP, or don't do OAEP, but don't not do it because in six months >> there might be a better algorithm. That's like saying you won't buy >> a computer today because in a month or two you'll be able to get a >> faster, cheaper computer. If you do that, you'll never replace that >> 100 MgHz 2 GB hard drive machine on your desk. >This simply isn't a useful analogy. > >We currently have something that does the job just fine (PKCS >#1). What OAEP offers over PKCS #1 is the claim that it's provably >secure. If that claim doesn't hold up then we shouldn't make the >replacement. Thus, we need to be reasonably confident that we're >not going to hear in 6 months that the OAEP security proofs are >flawed and that we need another construction. > >-Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 17:50:45 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20970 for ; Fri, 8 Jun 2001 17:50:44 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] RE: SHA algorithms -- WG Last Call for "AES Ciphersuites for TLS" Date: Fri, 8 Jun 2001 14:11:00 -0700 Message-ID: Thread-Topic: [ietf-tls] WG Last Call for "AES Ciphersuites for TLS" Thread-Index: AcDpDelmjfgU3nJbStS4FKetCSK1nQHPBvUg From: "John Banes" To: "IETF Transport Layer Security WG" X-OriginalArrivalTime: 08 Jun 2001 21:11:00.0958 (UTC) FILETIME=[84F4F7E0:01C0F05F] List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <4AEE3169443CDD4796CA8A00B02191CD69BF6F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA20970 Pete, have you looked at the new SHA algorithms that are being defined over at NIST? These algorithms have a much larger digest size that SHA-1 and are intended to provide security consistent with the longer key sizes provided by AES. I think that you should consider specifying that the SHA-256 or SHA-512 algorithms be used in the new AES cipher suites, particularly the ones using 256-bit AES. Here are a couple of links to the new SHA algorithms: http://csrc.nist.gov/encryption/tkhash.html http://csrc.nist.gov/encryption/shs/dfips-180-2.pdf Regards, John Banes -----Original Message----- From: Win Treese [mailto:treese@acm.org] Sent: Wednesday, May 30, 2001 6:36 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] WG Last Call for "AES Ciphersuites for TLS" This is LAST CALL for comments on advancing the draft "AES Ciphersuites for TLS" to Proposed Standard. The last call period is two weeks for the working group. The current draft is draft-ietf-tls-ciphersuite-03.txt and is at http://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt ftp://www.ietf.org/internet-drafts/draft-ietf-tls-ciphersuite-03.txt Win Treese Chair, TLS working group treese@acm.org --- You are currently subscribed to ietf-tls as: jbanes@windows.microsoft.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 8 17:53:43 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21001 for ; Fri, 8 Jun 2001 17:53:42 -0400 (EDT) Message-ID: Date: Fri, 08 Jun 2001 20:15:32 +0100 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B212454.CF947573@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- "Housley, Russ" wrote: > I think that this thread has gone off track. I do not think that we should > be discussing the level of study that a RSA-OAEP has received. Why on earth not? Are you seriously suggesting adopting RSA-OAEP in TLS *without* discussing the level of study it has received? Besides, I've found the thread very interesting. > My any measure it exceeds the level of study that PKCS#1 v1.5 has received. > > The countermeasures that are implemented around PKCS#1 v1.5 allow it to > thwart the Million Message Attack. This is great, as it allows the > community to make a thoughtful transition instead of a hasty one. > > The much discussed (on this thread) security proofs of RSA-OAEP illustrate > that this algorithm has better properties than PKCS#1 v1.5. But what they don't show (and in fact it is false) is that RSA-OAEP has better properties than PKCS#1 v1.5 with the RFC 2246 fix. If the TLS PRF is treated as a random oracle, it's fairly easy to prove in the random oracle model that PKCS#1 v1.5 with that fix is as secure, in the sense required, as RSA-OAEP would be (the proof is much the same as that of Simple-RSA in Victor Shoup's ISO proposal [Shoup01]). > It is my understanding that the structure of PKCS#1 v1.5 does lend itself > to similar proofs. I assume you meant "does not lend itself". However, we're not discussing pure PKCS#1 v1.5; everyone agrees that is subject to an attack. The systems we're comparing are RSA-OAEP and PKCS#1 v1.5 with the RFC 2246 fix. The latter *does* lend itself to a security proof (in fact a simpler one than the corrected RSA-OAEP proof, with a tighter reduction). > Therefore RSA-OAEP is much more likely to remain safe in the face > of a yet undiscovered attack. No, I believe that's simply false. If there is a further attack on the RSA ciphersuites, it would have to be something that is outside the model in which RSA-OAEP is proven secure. [Shoup01] Victor Shoup, "A Proposal for an ISO Standard for Public Key Encryption," February 13, 2001. Available from http://www.shoup.net/papers/ or http://citeseer.nj.nec.com/shoup01proposal.html - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOyEjWjkCAxeYt5gVAQFyyggAoa5EI3EVsioIDqmufixKO0g5zOYR7cz1 aKx0cCPb5kx2mYM/71TySizamwVhV4LgnAaYF20PvhpIfbAr5NI/UQ9b1qWoJu1s QV8shO+7Kfmpo8vbA2JQd0gZ2we5VWmg9udh1HsC9xYOchA/actv+QI6H+LGvhLc QYsDe+AFrkHhWRsdy0o7+pLnYB+yKmY2MRcwsu4q0G7ivPDsigWXGZoGuMWJqIoZ K1sJnNe9t5IMSFuXvd08laRgvgPeBdQoZKecMuGQXAVYX61ymQSKOfyqjUFstOuW hOj8DrqwSj6tc4zzn1Yq47hM2zJK2FZH4fY09iydb3f6XS15WpN9YQ== =jYpv -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sun Jun 10 09:47:08 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10977 for ; Sun, 10 Jun 2001 09:47:08 -0400 (EDT) Date: Sun, 10 Jun 2001 16:47:40 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Fri, 8 Jun 2001, Housley, Russ wrote: [......] > > Given the recent postings by Hugo, we might want to look at a mode of AES > that provides confidentiality and integrity all in one. Such a mode > eliminates the concerns about the order of MAC and encrypt operations. > > Russ > The need for such all-in-one mode is not implied or justified by my new results since, as the paper shows, we already have SPECIFIC modes in TLS that are SECURE. There is nothing more secure in the proposed AES all-in-one modes than in the currently used CBC and stream cipher modes as defined and used in TLS. The main problem I point to is the lack of generic security in the design of TLS, and this is certainly NOT addressed by the all-in-one modes. Indeed, these modes are essentially dependent on CBC and do not apply to any other form of encryption. Thus, you may want to discuss addition of such a new mode based on performance considerations (even though something such as RC4 plus HMAC-MD5 is probably already faster than the new modes, and non-CBC authentication. e.g. UMAC, just gets faster) but even then I wouldn't sacrifice the more general modularity built into the protocol that allows for the use of different forms of encryption, and supports authentication-only when encryption is not really needed. Note also my remark in the paper (end of the Introduction) about the fact that the all-in-one modes authenticate and encrypt the exact same information while security protocols usually include under the authentication un-encrypted information too. In particular, in the case of TLS message sequence numbers (which are not transmitted at all) are included (and rightly so!) under the authentication. Hugo --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 11 08:44:26 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08646 for ; Mon, 11 Jun 2001 08:44:25 -0400 (EDT) Date: Mon, 11 Jun 2001 13:44:39 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: SHA algorithms -- WG Last Call for "AES Ciphersuites for TLS" Message-ID: References: <4AEE3169443CDD4796CA8A00B02191CD69BF6F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4AEE3169443CDD4796CA8A00B02191CD69BF6F@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>; from jbanes@windows.microsoft.com on Fri, Jun 08, 2001 at 02:11:00PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010611134438.C8270@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net John Banes wrote: > I think that you should consider specifying that the SHA-256 or SHA-512 > algorithms be used in the new AES cipher suites, particularly the ones > using 256-bit AES. Don't forget that when SHA-1 is used in HMAC, it delivers 160 bits of strength, as far as we know. SHA-1 is looking a bit weak when it is used as an (unkeyed) hash function because it only has 80 bits of resistance to a birthday attack. -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 11 09:11:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09594 for ; Mon, 11 Jun 2001 09:11:37 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 11 Jun 2001 09:04:58 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010611085519.020d1e40@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hugo: > > Given the recent postings by Hugo, we might want to look at a mode of AES > > that provides confidentiality and integrity all in one. Such a mode > > eliminates the concerns about the order of MAC and encrypt operations. > >The need for such all-in-one mode is not implied or justified by my new >results since, as the paper shows, we already have SPECIFIC modes in TLS >that are SECURE. There is nothing more secure in the proposed AES >all-in-one modes than in the currently used CBC and stream cipher modes as >defined and used in TLS. The main problem I point to is the lack of >generic security in the design of TLS, and this is certainly NOT addressed >by the all-in-one modes. Indeed, these modes are essentially dependent on >CBC and do not apply to any other form of encryption. > >Thus, you may want to discuss addition of such a new mode based on >performance considerations (even though something such as RC4 plus >HMAC-MD5 is probably already faster than the new modes, and non-CBC >authentication. e.g. UMAC, just gets faster) but even then I wouldn't >sacrifice the more general modularity built into the protocol that allows >for the use of different forms of encryption, and supports >authentication-only when encryption is not really needed. > >Note also my remark in the paper (end of the Introduction) about the fact >that the all-in-one modes authenticate and encrypt the exact same >information while security protocols usually include under the >authentication un-encrypted information too. In particular, in the case of >TLS message sequence numbers (which are not transmitted at all) are >included (and rightly so!) under the authentication. I spent a fair amount of time with your paper over the weekend. I need to spend more. After the reading the Introduction, I was pretty clear on the path for the TLS working group. Nothing later in the paper has altered my view. You point out that a cipher that is secure against chosen-plaintext attacks is not sufficient to provide all of the security that we expect in a security protocol that uses the AtE construct (SSL, TLS, and many more). However, block ciphers in CBC mode and stream ciphers do provide the expected security. I suggest that the best course of action is to document what properties the cipher must have (including being secure against chosen-plaintext attacks) for use with TLS. Such guidance should keep people from defining ciphersuites that do not provide the expected security. Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 11 10:01:03 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10984 for ; Mon, 11 Jun 2001 10:01:00 -0400 (EDT) Date: Mon, 11 Jun 2001 10:01:20 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Your message of Fri, 08 Jun 2001 20:15:32 +0100 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > But what they don't show (and in fact it is false) is that RSA-OAEP has > better properties than PKCS#1 v1.5 with the RFC 2246 fix. If the TLS PRF > is treated as a random oracle, it's fairly easy to prove in the random > oracle model that PKCS#1 v1.5 with that fix is as secure, in the sense > required, as RSA-OAEP would be (the proof is much the same as that of > Simple-RSA in Victor Shoup's ISO proposal [Shoup01]). I think that the discussion in this thread misses the primary motiviation of Russ' request. As long as RSA-OAEP is at least as secure as PKCS#1 v1.5, Russ' suggestion should be taken seriously. The point is not to look solely at TLS, but instead to look at the suite of protocols developed within the IETF Security Area. Not all protocols implement a common suite of crypto algorithms. By adding RSA-OAEP to all protocols we can acheive uniform security and avoid the political difficulties of convincing all groups a common algorithm that results in more work for some groups than for others. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 11 16:33:56 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18466 for ; Mon, 11 Jun 2001 16:33:55 -0400 (EDT) Date: Mon, 11 Jun 2001 13:34:10 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT Hello Win, I am writing you a note in support of advancing the Camellia ciphersuite specification for TLS as a proposed standard. I have many reasons, but will be brief: 1) I am the owner of the Project JXTA security project (www.jxta.org) which is the Sun opensource, peer-to-peer project. As such, I am planning on adding the Camellia ciphersuite to our own ciphersuites for peer-to-peer, secure communication. Our final implemenation will be "almost TLS" as specified in rfc2246 with the "p2p twist" that every client is also a server, and vice-versa. As opensource, we cannot, and will not limit the addition of new ciphersuites to our TLS-like implementation. If you are interested in more details, please let me know. 2) The addition of the Camellia suites to Project JXTA is motivated by a) Camellia's high level of security. b) the *high probability* that Camellia will become widely deployed in mobile phones and smartcards, the former beginning with I-mode, and the latter because of its hardware design which minimizes gate requirements. These small devices are perfect candidates to widely deploy p2p technology on 2.5 and 3G wireless networks. Thus, targetting TLS for small devices will become extremely important over the next several years. This is where most of the internet's secure communications will take place given even the most modest predictions for mobile device deployment during this time. Thus, I believe it is extremely important at this time to make sure we do not limit our choices with respect to the ciphersuites that TLS offers. Our goal must be to motivate, and encourage the use of TLS, and thus internet security. I've often said that the recent ".com super nova" is really the "big bang" of the internet. It is the real beginning for e-commerce. The internet is restructuring itself, using the free energy released in that super nova. The activity at its core is huge, we are all part of it, and have as an obligation, to both welcome and embrace new technologies which have at their base superior engineering. This surely includes ciphersuites like Camellia. Thank you very much for considering my comments, Bill Yeager Senior Software Architect Project JXTA Sun Microsystems, Incorporated --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 00:58:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25069 for ; Tue, 12 Jun 2001 00:58:05 -0400 (EDT) Date: Tue, 12 Jun 2001 0:58:04 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-Reply-To: Your message of Mon, 11 Jun 2001 13:34:10 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Bill: I'm also very interested in JXTA, especially its core protocols and security issues. However, I must take issue with the premise that because JXTA is open-source (how is an IETF protocol closed?) it must allow any and every bad combination of algorithms to be combined into a cipher suite. Not only does that weaken the security of the system, but it also hampers interoperability between peers AND increases the size of the code base that must be implemented to ensure minimum interoperability requirements. IETF working groups produce open standards. I strongly believe that the JXTA core protocols should follow the IETF standards process. The JXTA core protocols define a peer to peer network that in a real sense replaces the original p2p network (IP4) which has been torn apart over the last decade by dynamic addressing, firewalls, and address translation. If the network for the decades to come might be JXTA, then it should benefit from the experience and review that an IETF working can bring to it. - Jeff > Hello Win, > > I am writing you a note in support of advancing the Camellia ciphersuite > specification for TLS as a proposed standard. I have many reasons, but will be > brief: > > 1) I am the owner of the Project JXTA security project (www.jxta.org) > which is the Sun opensource, peer-to-peer project. As such, I am > planning on adding the Camellia ciphersuite to our own ciphersuites for > peer-to-peer, secure communication. > > Our final implemenation will be "almost TLS" as specified in rfc2246 > with the "p2p twist" that every client is also a server, and vice-versa. > As opensource, we cannot, and will not limit the addition of new > ciphersuites to our TLS-like implementation. > > If you are interested in more details, please let me know. > > 2) The addition of the Camellia suites to Project JXTA is motivated by > > a) Camellia's high level of security. > > b) the *high probability* that Camellia will become widely deployed in > mobile phones and smartcards, the former beginning with I-mode, and > the latter because of its hardware design which minimizes gate > requirements. > > These small devices are perfect candidates to widely deploy p2p > technology on 2.5 and 3G wireless networks. > > > Thus, targetting TLS for small devices will become extremely important over > the next several years. This is where most of the internet's secure > communications will take place given even the most modest predictions for > mobile device deployment during this time. Thus, I believe it is extremely > important at this time to make sure we do not limit our choices with respect > to the ciphersuites that TLS offers. > > > Our goal must be to motivate, and encourage the use of TLS, and thus internet > security. I've often said that the recent ".com super nova" is really the > "big bang" of the internet. > > > It is the real beginning for e-commerce. The internet is restructuring itself, > using the free energy released in that super nova. The activity at its core is > huge, we are all part of it, and have as an obligation, to both welcome and > embrace new technologies which have at their base superior engineering. This > surely includes ciphersuites like Camellia. > > Thank you very much for considering my comments, > > Bill Yeager > Senior Software Architect > Project JXTA > Sun Microsystems, Incorporated > > > > --- > You are currently subscribed to ietf-tls as: jaltman@watsun.cc.columbia.edu > To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com > Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 06:48:21 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA11511 for ; Tue, 12 Jun 2001 06:48:21 -0400 (EDT) Date: Tue, 12 Jun 2001 11:48:39 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from William.Yeager@Eng.Sun.COM on Mon, Jun 11, 2001 at 01:34:10PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010612114839.D10598@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Bill Yeager wrote: > Our final implemenation will be "almost TLS" as specified in rfc2246 > with the "p2p twist" that every client is also a server, and > vice-versa. It's not really the question you were asking, but I'm curious to know what you mean by "almost TLS". Do you just mean that each machine will be a TLS client and server at the same time (for different connections of course)? Alternatively will you actually be changing the protocol? -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 17:30:04 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24989 for ; Tue, 12 Jun 2001 17:30:03 -0400 (EDT) Date: Tue, 12 Jun 2001 14:30:01 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Cc: Jeffrey Altman Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT Hi Jeff, | However, I must take issue with the premise that | because JXTA is open-source (how is an IETF protocol closed?) it must | allow any and every bad combination of algorithms to be combined into | a cipher suite. Are you saying that Camellia is bad? I don't think so (-: Open Source has review just like the IETF, and certainly (maybe I was not precise enough in my statement), we'd review the technical merits of a cipher suite before permitting it to be used. I think Camellia qualifies here. And, for the current set of clients, we are very small with respect to the suites we support. I had to put something together in about six weeks, and am looking for volunteers to add more suites (-: Right now I only have RSA(512 bit), RC4(160bit), MD5, and SHA-1 + MAC + digital signature + a very good PRNG based on SHA-1. Currently all in Java and surprisingly fast! Volunteers appreciated. | increases the | size of the code base that must be implemented to ensure minimum | interoperability requirements. This is an important consideration, and well taken. Still, I am thinking when p2p or TLS move to mobile phones(SSL is already there for java - 64K byte implementation called KSSL), the clients will have support for a very small set of crypto suites as demanded by the footprint of these devices, and this will either be pretty much carrier/manufacturer controlled, or an agreed upon subset maybe arbitrated through, dare I say, ETSI. And, some of this will be offloaded to SIM cards. A cool thing about Java on these devices is that one can download a jar on the live network, and update or replace the classes. This creates lots of interesting possibilities ... | IETF working groups produce open standards. I strongly believe that | the JXTA core protocols should follow the IETF standards process. You will not find me disagreeing with you here. This has been discussed in our group from the very beginning. For me, it has always been difficult to decide when something has been sufficiently tested, and well enough understood, to move it to a draft-rfc. We have our initial specification. I don't say any reason why the next specification cannot be submitted as a draft-rfc. It is foolish not to take advantage of the intellectual input one will get in the IETF. Any volunteers out there? | If the network for the decades to come might be JXTA, | then it should benefit from the experience and review that an IETF | working can bring to it. 100% correct. Except, that I would say, "If the network for the decades to come might be *something like* JXTA ... ." And, this might be what is required to motivate a fully deployed IPV6! This will simplify the p2p world tremendously given: | define a peer to peer network that in a real sense | replaces the original p2p network (IP4) which has been torn apart over | the last decade by dynamic addressing, firewalls, and address | translation. Sigh ... lots to do for sure. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 17:38:26 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25141 for ; Tue, 12 Jun 2001 17:38:25 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 12 Jun 2001 14:45:11 -0700 In-Reply-To: Bill Yeager's message of "Mon, 11 Jun 2001 13:34:10 -0700 (PDT)" Message-ID: Lines: 35 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bill Yeager writes: > Our final implemenation will be "almost TLS" as specified in rfc2246 > with the "p2p twist" that every client is also a server, and vice-versa. > As opensource, we cannot, and will not limit the addition of new > ciphersuites to our TLS-like implementation. Really? So we should be expecting you to implement TLS_FIXED_KEY_WITH_ROT13_SHA real soon now? Neither open source implementations nor open source standards need to implement every single algorithm that anyone suggests. > It is the real beginning for e-commerce. The internet is > restructuring itself, using the free energy released in that super > nova. The activity at its core is huge, we are all part of it, and > have as an obligation, to both welcome and embrace new technologies > which have at their base superior engineering. This surely includes > ciphersuites like Camellia. It has yet to be established that Camellia is superior engineering or technology. Rather, it's a relatively new algorithm that has seen comparatively little analysis or review. Yes, it was designed by some big names, and yes it looks good on the surface, but such algorithms have turned out to be flawed before. Surely, to the extent to which we have an obligation it includes not basing a Proposed Standard on such an untried algorithm. I don't have a problem with a Camellia draft going to Informational or Experimental. This would provide a cipher suite number and an archival reference. Why do you believe it needs to go to Proposed instead? -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 17:46:37 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25244 for ; Tue, 12 Jun 2001 17:46:37 -0400 (EDT) Date: Tue, 12 Jun 2001 17:47:00 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: IETF Transport Layer Security WG Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-Reply-To: Your message of Tue, 12 Jun 2001 14:30:01 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > Hi Jeff, > > | However, I must take issue with the premise that > | because JXTA is open-source (how is an IETF protocol closed?) it must > | allow any and every bad combination of algorithms to be combined into > | a cipher suite. > > Are you saying that Camellia is bad? I don't think so (-: I certainly am not saying that Camellia is bad. I do not make the claim under any circumstances to state whether or not a particular cipher is good or bad. I don't have the expertise. > Open Source has review just like the IETF, and certainly (maybe I > was not precise enough in my statement), we'd review the technical > merits of a cipher suite before permitting it to be used. I think > Camellia qualifies here. And, for the current set of clients, we are > very small with respect to the suites we support. I had to put > something together in about six weeks, and am looking for volunteers > to add more suites (-: Right now I only have RSA(512 bit), > RC4(160bit), MD5, and SHA-1 + MAC + digital signature + a very good > PRNG based on SHA-1. Currently all in Java and surprisingly fast! > Volunteers appreciated. I did not say that Open Source did not have review. > | increases the > | size of the code base that must be implemented to ensure minimum > | interoperability requirements. > > This is an important consideration, and well taken. Still, I am thinking when > p2p or TLS move to mobile phones(SSL is already there for java - 64K byte > implementation called KSSL), the clients will have support for a very small > set of crypto suites as demanded by the footprint of these devices, and this > will either be pretty much carrier/manufacturer controlled, or an agreed upon > subset maybe arbitrated through, dare I say, ETSI. And, some of this will be > offloaded to SIM cards. And the easiest way to reduce the footprint size is to reduce the number of ciphers. So if you figure that there is going to be one cipher implemented it will most likely be AES. My guess is that these mobile devices are going to need to support not just JXTA p2p security protocols, but TLS, and maybe even several other protocols. It is extremely important that a small common set of ciphers suites be used across the board. This is the same nail that Russ Housley has been trying to hammer home in the Security Area over the last year. > A cool thing about Java on these devices is that one can download a > jar on the live network, and update or replace the classes. This > creates lots of interesting possibilities ... Absolutely. That is way makes dynamic programming so much fun. Unfortunately, the ability to download updated JARs does nothing to increase the available space. > | IETF working groups produce open standards. I strongly believe that > | the JXTA core protocols should follow the IETF standards process. > You will not find me disagreeing with you here. This has been > discussed in our group from the very beginning. For me, it has > always been difficult to decide when something has been sufficiently > tested, and well enough understood, to move it to a draft-rfc. We > have our initial specification. I don't say any reason why the next > specification cannot be submitted as a draft-rfc. It is foolish not > to take advantage of the intellectual input one will get in the > IETF. Any volunteers out there? Basicly, as soon as you are ready to write a published spec, you should submit it as an I-D. Then we can request a BOF for the next IETF meeting to form the actually working group. Although, in this case we can probably bypass the BOF due to the demonstrated interest in JXTA. I am happy to assist in the editing of I-Ds and working for form the necessary working groups to take the JXTA Core protocols into the IETF space. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 17:50:38 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25306 for ; Tue, 12 Jun 2001 17:50:36 -0400 (EDT) Date: Tue, 12 Jun 2001 14:50:58 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT Hi Ekr, | It has yet to be established that Camellia is superior engineering or | technology. Rather, it's a relatively new algorithm that has seen | comparatively little analysis or review. Are you certain about "comparatively little?" I defer to Shiho on this one (-: | I don't have a problem with a Camellia draft going to Informational | or Experimental. This would provide a cipher suite number and | an archival reference. Why do you believe it needs to go to Proposed | instead? I would like your group to do what is appropriate within its guidelines. I simply did not want to see Camellia stalled. I think in the end that would be regrettable. Experimental or Informational is fine by me. Thanks for you note, Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 18:03:14 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25529 for ; Tue, 12 Jun 2001 18:03:14 -0400 (EDT) Date: Tue, 12 Jun 2001 15:03:25 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Cc: Bill Yeager , IETF Transport Layer Security WG Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | And the easiest way to reduce the footprint size is to reduce the | number of ciphers. So if you figure that there is going to be one | cipher implemented it will most likely be AES. Rijndael might be the one. This really depends on deployment as you know. I still like choice. I forget the comparison Rijndael's gate density wrt Camellia. Let's revisit this in 2005 (-: | It is extremely important that a small common set of | ciphers suites be used across the board. This is the same nail | that Russ Housley has been trying to hammer home in the Security Area | over the last year. Easy to say. More difficult to coerce. I like natural selection ... | Absolutely. That is way makes dynamic programming so much fun. | Unfortunately, the ability to download updated JARs does nothing to | increase the available space. Not necessarily. It cannot reduce the absolute space available, but might reduce the relative amount of space given a better implementation, etc ... IT does permit experimentation. | Basicly, as soon as you are ready to write a published spec, you | should submit it as an I-D. Then we can request a BOF for the next | IETF meeting to form the actually working group. Although, in this | case we can probably bypass the BOF due to the demonstrated interest | in JXTA. | | I am happy to assist in the editing of I-Ds and working for form the | necessary working groups to take the JXTA Core protocols into the IETF | space. Thanks Jeff. We'll see about this Fall. More free time then (I hope). Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 18:12:34 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25695 for ; Tue, 12 Jun 2001 18:12:33 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 12 Jun 2001 15:19:17 -0700 In-Reply-To: Bill Yeager's message of "Tue, 12 Jun 2001 14:50:58 -0700 (PDT)" Message-ID: Lines: 12 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bill Yeager writes: > Hi Ekr, > > | It has yet to be established that Camellia is superior engineering or > | technology. Rather, it's a relatively new algorithm that has seen > | comparatively little analysis or review. > > Are you certain about "comparatively little?" I defer to Shiho on this one (-: Compared to AES. Definitely. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 12 19:11:35 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26625 for ; Tue, 12 Jun 2001 19:11:34 -0400 (EDT) Date: Wed, 13 Jun 2001 02:11:50 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Russ, I would like to get your feedback when you are done reading the paper. In the meantime see below for some comments on your note. On Mon, 11 Jun 2001, Housley, Russ wrote: > > > I spent a fair amount of time with your paper over the weekend. I need to > spend more. > > After the reading the Introduction, I was pretty clear on the path for the > TLS working group. Nothing later in the paper has altered my view. > > You point out that a cipher that is secure against chosen-plaintext attacks > is not sufficient to provide all of the security that we expect in a > security protocol that uses the AtE construct (SSL, TLS, and many > more). However, block ciphers in CBC mode and stream ciphers do provide > the expected security. > > I suggest that the best course of action is to document what properties the > cipher must have (including being secure against chosen-plaintext attacks) > for use with TLS. Such guidance should keep people from defining > ciphersuites that do not provide the expected security. > > Russ If TLS would use the encrypt-then-mac approach then the guidelines could be very general: just use an encryption function secure against chosen-plaintext attacks and a MAC secure against chosen message attack (all reasonably secure encryption and mac functions, including all standarized modes, are secure in the above senses). However, as long as TLS uses the current mac-then-encrypt approach then such generic guidleines are notpossible. In this case we can only be sure about the two SPECIFIC modes currently defined in TLS: (1) CBC mode as currently specified in TLS: i.e., a single CBC pass made on the whole concatenation of plaintext and MAC (just for comparison: computing CBC encryption on the plaintext and MAC *separately*, i.e. with independent IVs, is enough to break the security) (2) stream ciphers where the plaintext (fragments) are DIRECTLY xor-ed with a pseudo-random pad (just for comparison: a simple encoding of the plaintext before xoring may be enough to break the security) These SPECIFIC modes and processing are proven in the paper. Any change, addition or departure from this processing requires a new specific analysis (and not just for the "theoretical interest"). This is what needs to be made clear in the TLS document. Hugo --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 04:02:50 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17306 for ; Wed, 13 Jun 2001 04:02:49 -0400 (EDT) Message-ID: Date: Wed, 13 Jun 2001 09:03:07 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Cc: Jeffrey Altman Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B271E3B.8C36E669@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bill Yeager wrote: > A cool thing about Java on these devices is that one can download a jar on the > live network, and update or replace the classes. This creates lots of > interesting possibilities ... Many of them rather scary, IMO! Plus, I'm sure JXTA is supposed to be language independent. Or is that just a sop? > | IETF working groups produce open standards. I strongly believe that > | the JXTA core protocols should follow the IETF standards process. > > You will not find me disagreeing with you here. This has been discussed in our > group from the very beginning. For me, it has always been difficult to decide > when something has been sufficiently tested, and well enough understood, to > move it to a draft-rfc. We have our initial specification. I don't say any > reason why the next specification cannot be submitted as a draft-rfc. It is > foolish not to take advantage of the intellectual input one will get in the > IETF. Any volunteers out there? Sure. BTW, it seems to me that you should be looking at the MANET stuff (http://www.ietf.org/html.charters/manet-charter.html). Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 08:19:55 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20150 for ; Wed, 13 Jun 2001 08:19:54 -0400 (EDT) To: "IETF Transport Layer Security WG" Date: Wed, 13 Jun 2001 09:19:29 -0300 From: "Gabriel Belingueres" Message-ID: Mime-Version: 1.0 X-Sent-Mail: off Reply-To: "IETF Transport Layer Security WG" X-Mailer: MailCity Service Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" X-Sender-Ip: 200.45.74.78 Organization: Lycos Mail (http://mail.lycos.com:80) Content-Type: text/plain; charset=us-ascii Content-Language: en Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit On Wed, 13 Jun 2001 02:11:50 Hugo Krawczyk wrote: >Russ, I would like to get your feedback when you are done reading the >paper. In the meantime see below for some comments on your note. > >On Mon, 11 Jun 2001, Housley, Russ wrote: >> >> >> I spent a fair amount of time with your paper over the weekend. I need to >> spend more. >> >> After the reading the Introduction, I was pretty clear on the path for the >> TLS working group. Nothing later in the paper has altered my view. >> >> You point out that a cipher that is secure against chosen-plaintext attacks >> is not sufficient to provide all of the security that we expect in a >> security protocol that uses the AtE construct (SSL, TLS, and many >> more). However, block ciphers in CBC mode and stream ciphers do provide >> the expected security. >> >> I suggest that the best course of action is to document what properties the >> cipher must have (including being secure against chosen-plaintext attacks) >> for use with TLS. Such guidance should keep people from defining >> ciphersuites that do not provide the expected security. >> >> Russ > >If TLS would use the encrypt-then-mac approach then the guidelines could >be very general: just use an encryption function secure against >chosen-plaintext attacks and a MAC secure against chosen message attack >(all reasonably secure encryption and mac functions, including all >standarized modes, are secure in the above senses). > >However, as long as TLS uses the current mac-then-encrypt approach then >such generic guidleines are notpossible. In this case we can only be sure >about the two SPECIFIC modes currently defined in TLS: > >(1) CBC mode as currently specified in TLS: i.e., a single CBC pass made >on the whole concatenation of plaintext and MAC (just for comparison: >computing CBC encryption on the plaintext and MAC *separately*, i.e. with >independent IVs, is enough to break the security) > >(2) stream ciphers where the plaintext (fragments) are DIRECTLY xor-ed >with a pseudo-random pad (just for comparison: a simple encoding of the >plaintext before xoring may be enough to break the security) if an encoding on the plaintext could break security, then: 1) remove the compression functionality from the TLS rfc. or 2) add a note about the issues raised by encoding the plaintext before encription. >These SPECIFIC modes and processing are proven in the paper. >Any change, addition or departure from this processing requires a new >specific analysis (and not just for the "theoretical interest"). >This is what needs to be made clear in the TLS document. > >Hugo > > > > > > >--- >You are currently subscribed to ietf-tls as: gaby@ieee.org >To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com > Get 250 color business cards for FREE! http://businesscards.lycos.com/vp/fastpath/ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 08:39:27 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20862 for ; Wed, 13 Jun 2001 08:39:25 -0400 (EDT) Date: Wed, 13 Jun 2001 8:39:19 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: I-D ACTION:draft-ietf-tls-camellia-01.txt In-Reply-To: Your message of Wed, 13 Jun 2001 09:03:07 +0100 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > Bill Yeager wrote: > > A cool thing about Java on these devices is that one can download a jar on the > > live network, and update or replace the classes. This creates lots of > > interesting possibilities ... > > Many of them rather scary, IMO! Plus, I'm sure JXTA is supposed to be > language independent. Or is that just a sop? > It is not just a sop. To ensure that JXTA is language independent is one of the reasons that I want to move the core protocols into the IETF and out of the JXTA community. The IETF is strictly a language independent wire protocol community. Sure we sometimes get ourselves into the API business but it is a rarity. For JXTA to be a success, the protocols cannot be developed based upon the implementation experience of one language/technology platform. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 11:08:08 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24680 for ; Wed, 13 Jun 2001 11:08:07 -0400 (EDT) From: "Housley, Russ" To: "IETF Transport Layer Security WG" Message-Id: X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Wed, 13 Jun 2001 10:57:50 -0400 Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <5.0.1.4.2.20010613105325.02000b60@exna07.securitydynamics.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hugo: >Russ, I would like to get your feedback when you are done reading the >paper. In the meantime see below for some comments on your note. I am having a busy week, so it will not happen as soon as I would like. >On Mon, 11 Jun 2001, Housley, Russ wrote: > > > > > > I spent a fair amount of time with your paper over the weekend. I need to > > spend more. > > > > After the reading the Introduction, I was pretty clear on the path for the > > TLS working group. Nothing later in the paper has altered my view. > > > > You point out that a cipher that is secure against chosen-plaintext > attacks > > is not sufficient to provide all of the security that we expect in a > > security protocol that uses the AtE construct (SSL, TLS, and many > > more). However, block ciphers in CBC mode and stream ciphers do provide > > the expected security. > > > > I suggest that the best course of action is to document what properties > the > > cipher must have (including being secure against chosen-plaintext attacks) > > for use with TLS. Such guidance should keep people from defining > > ciphersuites that do not provide the expected security. > > > > Russ > >If TLS would use the encrypt-then-mac approach then the guidelines could >be very general: just use an encryption function secure against >chosen-plaintext attacks and a MAC secure against chosen message attack >(all reasonably secure encryption and mac functions, including all >standarized modes, are secure in the above senses). > >However, as long as TLS uses the current mac-then-encrypt approach then >such generic guidleines are notpossible. In this case we can only be sure >about the two SPECIFIC modes currently defined in TLS: > >(1) CBC mode as currently specified in TLS: i.e., a single CBC pass made >on the whole concatenation of plaintext and MAC (just for comparison: >computing CBC encryption on the plaintext and MAC *separately*, i.e. with >independent IVs, is enough to break the security) > >(2) stream ciphers where the plaintext (fragments) are DIRECTLY xor-ed >with a pseudo-random pad (just for comparison: a simple encoding of the >plaintext before xoring may be enough to break the security) > >These SPECIFIC modes and processing are proven in the paper. >Any change, addition or departure from this processing requires a new >specific analysis (and not just for the "theoretical interest"). >This is what needs to be made clear in the TLS document. SSL and TLS are widely deployed, and changing mac-then-encrypt to encrypt-then-mac is not a trivial change. In my view, it creates a whole new protocol. Therefore, I would like to avoid such a change if we can find a way to characterize the algorithms and modes that are safe with the current protocol (especially since the widely implemented algorithms are safe). Russ --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 11:16:02 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24848 for ; Wed, 13 Jun 2001 11:16:01 -0400 (EDT) Message-ID: From: David Blaker To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Date: Wed, 13 Jun 2001 11:14:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <49B96FCC784BC54F9675A6B558C3464E3A5F77@MAIL.NetOctave.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Russ, We agree with your assertion that changing the order of authentication and encryption effectively creates a new data plane protocol. It would also further complicate the task of creating high-performance network security processors. This point lends weight to the notion that we should limit the number of ciphersuites to decrease the chances of creating security problems. _________________________________________ David Blaker, CTO NetOctave, Inc. P.O. Box 14824 Research Triangle Park, NC 27709 Phone (919) 463-9903 x.206 / Fax (919) 463-9905 email mailto:dblaker@netoctave.com website http://www.netoctave.com -----Original Message----- From: Housley, Russ [mailto:rhousley@rsasecurity.com] Sent: Wednesday, June 13, 2001 10:58 AM To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Hugo: >Russ, I would like to get your feedback when you are done reading the >paper. In the meantime see below for some comments on your note. I am having a busy week, so it will not happen as soon as I would like. >On Mon, 11 Jun 2001, Housley, Russ wrote: > > > > > > I spent a fair amount of time with your paper over the weekend. I need to > > spend more. > > > > After the reading the Introduction, I was pretty clear on the path for the > > TLS working group. Nothing later in the paper has altered my view. > > > > You point out that a cipher that is secure against chosen-plaintext > attacks > > is not sufficient to provide all of the security that we expect in a > > security protocol that uses the AtE construct (SSL, TLS, and many > > more). However, block ciphers in CBC mode and stream ciphers do provide > > the expected security. > > > > I suggest that the best course of action is to document what properties > the > > cipher must have (including being secure against chosen-plaintext attacks) > > for use with TLS. Such guidance should keep people from defining > > ciphersuites that do not provide the expected security. > > > > Russ > >If TLS would use the encrypt-then-mac approach then the guidelines could >be very general: just use an encryption function secure against >chosen-plaintext attacks and a MAC secure against chosen message attack >(all reasonably secure encryption and mac functions, including all >standarized modes, are secure in the above senses). > >However, as long as TLS uses the current mac-then-encrypt approach then >such generic guidleines are notpossible. In this case we can only be sure >about the two SPECIFIC modes currently defined in TLS: > >(1) CBC mode as currently specified in TLS: i.e., a single CBC pass made >on the whole concatenation of plaintext and MAC (just for comparison: >computing CBC encryption on the plaintext and MAC *separately*, i.e. with >independent IVs, is enough to break the security) > >(2) stream ciphers where the plaintext (fragments) are DIRECTLY xor-ed >with a pseudo-random pad (just for comparison: a simple encoding of the >plaintext before xoring may be enough to break the security) > >These SPECIFIC modes and processing are proven in the paper. >Any change, addition or departure from this processing requires a new >specific analysis (and not just for the "theoretical interest"). >This is what needs to be made clear in the TLS document. SSL and TLS are widely deployed, and changing mac-then-encrypt to encrypt-then-mac is not a trivial change. In my view, it creates a whole new protocol. Therefore, I would like to avoid such a change if we can find a way to characterize the algorithms and modes that are safe with the current protocol (especially since the widely implemented algorithms are safe). Russ --- You are currently subscribed to ietf-tls as: DBlaker@NetOctave.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 17:10:37 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01698 for ; Wed, 13 Jun 2001 17:10:36 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Wireless extensions draft status? Date: Thu, 14 Jun 2001 07:13:04 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <007001c0f44d$a2fcf5c0$d0ab093d@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I am updating draft-ietf-tls-srp, and have specified use of the client hello and server hello extensions specified in draft-ietf-tls-wireless. I realise any work should not reference drafts, but those extensions look very useful. The problem is, the wireless draft has expired. Is there any news of it being updated, or is it gone for good. If it has gone, should I incorporate the extension work into the srp draft, or should extensions become a separate draft? Thanks, David Taylor. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 18:12:35 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02565 for ; Wed, 13 Jun 2001 18:12:34 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Wed, 13 Jun 2001 18:11:27 -0400 Subject: [ietf-tls] Re: Wireless extensions draft status? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A6A.0079F200.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi David, The updated draft has been delayed while we finalize text among the authors (the number of authors is increasing), but should come out shortly. Best regards. Simon "David Taylor" on 06/13/2001 05:13:04 PM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] Wireless extensions draft status? I am updating draft-ietf-tls-srp, and have specified use of the client hello and server hello extensions specified in draft-ietf-tls-wireless. I realise any work should not reference drafts, but those extensions look very useful. The problem is, the wireless draft has expired. Is there any news of it being updated, or is it gone for good. If it has gone, should I incorporate the extension work into the srp draft, or should extensions become a separate draft? Thanks, David Taylor. --- You are currently subscribed to ietf-tls as: sblakewilson@certicom.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 18:25:18 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02741 for ; Wed, 13 Jun 2001 18:25:17 -0400 (EDT) Date: Wed, 13 Jun 2001 15:23:06 -0700 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Wireless extensions draft status? Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from dtaylo11@bigpond.net.au on Thu, Jun 14, 2001 at 07:13:04AM +1000 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010613152306.A22411@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Thu, Jun 14, 2001 at 07:13:04AM +1000, David Taylor wrote: > I am updating draft-ietf-tls-srp, and have specified use of the client hello > and server hello extensions specified in draft-ietf-tls-wireless. > > I realise any work should not reference drafts, but those extensions look > very useful. > > The problem is, the wireless draft has expired. Is there any news of it > being updated, or is it gone for good. If it has gone, should I incorporate > the extension work into the srp draft, or should extensions become a > separate draft? Hi David. I'm also working on an I-D and want to use the Wireless TLS extension mechanism.. I asked the authors about the status on 6/1/00 and got an answer that a new wireless TLS draft would be out last tuesday. I haven't seen it but I just got back from a week's vacation and I'm still going through my email. BTW, we should coordinate ExtensionType ids to prevent conflicts. Eric --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 19:16:25 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03266 for ; Wed, 13 Jun 2001 19:16:24 -0400 (EDT) Date: Wed, 13 Jun 2001 16:15:07 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] JXTA and TLS To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT Hi Pete, | > Our final implemenation will be "almost TLS" as specified in rfc2246 | > with the "p2p twist" that every client is also a server, and | > vice-versa. | | It's not really the question you were asking, but I'm curious to know | what you mean by "almost TLS". Do you just mean that each machine | will be a TLS client and server at the same time (for different | connections of course)? Alternatively will you actually be changing | the protocol? This is a good question: 1) Yes, each machine is a server and a client. 2) Changing the protocol? First a brief intro to JXTA : If we look at the JXTA protocols, we will see that all information *describing* a peer is made known by the means of advertisements published by each peer. These are in XML, and sent in JXTA messages, which are also in XML. Peers themselves communicate within groups which we call peergroups. At bootstrap time a peer is a member of the world peergroup. peergroups are collections of peers that have mutual interests. Anyone can create a peergroup, put in place the requirements to join, advertise the peergroups existence (part of that peer's advertisement), and exchange content with members using JXTA messages. JXTA messages are content neutral. In order for peers in a peergroup to send/receive JXTA messages they use pipes as a transport abstraction. These are not UNIX pipes. Rather, they are advertisements by a peer to accept input for a specific purpose from other peers in a peergroup. Pipe advertisements are underlying-transport neutral. Pipes are uni-directional (for now), and a single input pipe can receive output from more than one peer. This is very nice for instant messaging pipes. If a peer has received an input pipe advertisement, then if it wishes to communicate with the associated peer, which is only known by its peerID which is part of the pipe advertisement, it uses pipe resolution to find the originating end point. This is a huge discussion that I don't want to address here. Over TCP/IP this results in binding to a remote [IP-address,port]. So, how does TLS fit into this picture? Handshake: This is functionally the same. When a peer advertises its existence, the peer advertisement (XML) current contains " TBD ". My idea is to replace the TBD with at least the supported crypto suites and the peer's certificate. An input pipe will be advertised as secure/insecure. Thus, after endpoint resolution on a secure pipe, we have: PeerA == pipe1 ===> PeerB (PeerB advertised pipe1) This is not enough to complete the handshake (unidirectional pipes). Thus during resolution, PeerA can pass a pipe advertisement, pipe2, to peerB. Finally, we have PeerA == pipe1 ===> PeerB (PeerB advertised pipe1) PeerA <= pipe2 ===> PeerB At this time the TLS handshake completes (random numbers exchanged, premaster secret computed, etc ..), the master key calculation is done, key material exchanged, security parameters passed to record layer, etc, all of this religiously following the TLS specification. I'm leaving out the details but they are familiar to all of you. When this is all done, then the application layers exchange data as per the TLS spec. So, is the handshake really the TLS handshake if the crptosuites and certs are known beforehand through advertisements? I think this is the only real difference. Sorry for being so brief. If this interests you, then sign up for the JXTA security project and contribute. The hard problem we are now working on is how to do distributed, signed certificates with or without CA's. When we are without CA's, then something very similar to the PGP "Web of Trust" is being designed where trust is really probabilistic, and based on personal knowledge and recommendations from other peer group members. We want to apply trust to data, and QOS, as well as to certs. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 19:38:02 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03478 for ; Wed, 13 Jun 2001 19:38:02 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 13 Jun 2001 16:41:53 -0700 In-Reply-To: Bill Yeager's message of "Wed, 13 Jun 2001 16:15:07 -0700 (PDT)" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Bill Yeager writes: > When a peer advertises its existence, the peer advertisement (XML) current > contains " TBD ". My idea is to replace the TBD with at > least the supported crypto suites and the peer's certificate. This seems problematic. The TLS cipher suite negotiation is protected by the Finished messages. Unless this advertisement is itself secured (you don't say yes or no) then you may be susceptible to downgrade attacks (depending on precisely how you specify the ciphersuites used in the TLS handshake). More importantly, what value is being added by having this stuff in the advertisement? TLS has a perfectly good mechanism for exchanging cipher suites and certificates. Why subvert it? -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 19:38:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03489 for ; Wed, 13 Jun 2001 19:38:05 -0400 (EDT) Date: Wed, 13 Jun 2001 16:35:16 -0700 From: Eric Murray To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: ; from William.Yeager@Eng.Sun.COM on Wed, Jun 13, 2001 at 04:15:07PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010613163516.F22411@slack.lne.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Wed, Jun 13, 2001 at 04:15:07PM -0700, Bill Yeager wrote: [..] > So, is the handshake really the TLS handshake if the crptosuites and certs > are known beforehand through advertisements? Nope. Then it's TLS-like, as you stated earlier. And unless there's something analagous to the handshake hash to authenticate the ciphersuites, there could be a downgrade attack. IIRC, Eric Rescorla's book has a lot of info in it about the various security design issues that were uncovered when SSL/TLS was designed and what was done to address them. It's probably worth a read for those attempting to improve or adapt TLS. Eric --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 20:10:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03740 for ; Wed, 13 Jun 2001 20:10:51 -0400 (EDT) Date: Wed, 13 Jun 2001 17:09:23 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | More importantly, what value is being added by having this stuff | in the advertisement? TLS has a perfectly good mechanism for | exchanging cipher suites and certificates. Why subvert it? The idea is why exchange something each time you want to communicate, when it can be known before hand when you first contact a peer. Advertisements are cached with a timeout. You are right that it might not be worth it in the end. And, your point is well taken. The closer we stick to TLS, the more trusted our implementation will be. Am I talking myself out of using advertisements? Thanks for the input! Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 20:16:40 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03781 for ; Wed, 13 Jun 2001 20:16:39 -0400 (EDT) Date: Wed, 13 Jun 2001 17:16:42 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | Nope. Then it's TLS-like, as you stated earlier. | And unless there's something analagous to the handshake hash to | authenticate the ciphersuites, there could be a downgrade attack. Good point. This is the HMAC as I recall. I need to reread the rfc here ... | IIRC, Eric Rescorla's book has a lot of info in it about | the various security design issues that were uncovered when SSL/TLS was | designed and what was done to address them. It's probably worth | a read for those attempting to improve or adapt TLS. I'll do that. Thanks, Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 13 21:49:58 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05339 for ; Wed, 13 Jun 2001 21:49:57 -0400 (EDT) Date: Wed, 13 Jun 2001 21:48:57 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Wed, 13 Jun 2001 16:15:07 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Bill: You should probably pay attention to the discussion about performing the Mac after the Encryption. The opposite of the TLS order. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 01:01:10 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA08014 for ; Thu, 14 Jun 2001 01:01:09 -0400 (EDT) Message-ID: Date: Wed, 13 Jun 2001 21:36:05 +0100 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B27CEB5.189F0AE7@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Gabriel Belingueres wrote: > On Wed, 13 Jun 2001 02:11:50 > Hugo Krawczyk wrote: > >However, as long as TLS uses the current mac-then-encrypt approach then > >such generic guidleines are not possible. In this case we can only be sure > >about the two SPECIFIC modes currently defined in TLS: > > > >(1) CBC mode as currently specified in TLS: i.e., a single CBC pass made > >on the whole concatenation of plaintext and MAC (just for comparison: > >computing CBC encryption on the plaintext and MAC *separately*, i.e. with > >independent IVs, is enough to break the security) > > > >(2) stream ciphers where the plaintext (fragments) are DIRECTLY xor-ed > >with a pseudo-random pad (just for comparison: a simple encoding of the > >plaintext before xoring may be enough to break the security) > > if an encoding on the plaintext could break security, then: > > 1) remove the compression functionality from the TLS rfc. > > or > > 2) add a note about the issues raised by encoding the plaintext before > encryption. In TLS, compression is a completely separate layer to the encryption/MAC, so the output of compression is the plaintext in Hugo's security proof. In particular, the MAC is on the compressed text, not the plaintext before compression. Also, TLS aborts immediately on the first authentication failure, so we can rely on the context that the decompression algorithm uses having been authenticated. There's no security problem here; Hugo's point about encoding doesn't apply in this case. > >These SPECIFIC modes and processing are proven in the paper. > >Any change, addition or departure from this processing requires a new > >specific analysis (and not just for the "theoretical interest"). > >This is what needs to be made clear in the TLS document. I completely agree that this should be pointed out in the next revision, although I don't think RFC 2246 needs to be revised right now because of this. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOyfOhTkCAxeYt5gVAQGtSQf6A7KKcMTGYuDMTrrp6lheSb3as1wht8Ta o/vbf9unLz/PLERwxMlPL5+jHctug86zthxQ4nf1nSN+NFxfKFxfguq1/L5IS63A cv7sSD/dE3RNPfCRUhWF+u5jHlAoewAzo9gKDUy+aG7Wcy/7mkZ6z0pS+JblnKTp 3tejdwuf6AxXZVaW+c3kQawymjgBfRv7aCv1aBQI12bjv1MQj3zG8o+y6zm6upyT THERvElDS/49ifjZ362zeMDyKtdrqO6ICzgsBcz8TEt2svAcAg3aDInsfsmKEhE7 5Ff/OFpm+Lhhw9GVub8z2qOg3LDeRMaRBuJx94zG5PAN63kLdy5k9A== =vMB1 -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 04:42:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23628 for ; Thu, 14 Jun 2001 04:42:29 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Different message digest schemes for SRP? Date: Thu, 14 Jun 2001 18:44:18 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <001701c0f4ae$4ee6f6a0$05428990@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hi, A GNU TLS project has been started, and while they were waiting for ASN.1 software they decided to implement the SRP cipher suite. In doing this, they've added a feature whereby the message digest used with SRP can be selected. My implementation just used SHA-1 as per the RFC. The GNU guys have added a blowfish based option too. Is this useful enough to put in the draft? Or is leaving it with SHA-1 good enough? I imagine the client will have to present a list of SRP message digests it knows, along with the user name. Then the server will have to respond with the one it selected, along with the n, g, s parameters. I feel SRP with SHA-1 is good enough, although if there is already a spot for a replacement if SHA-1 is found to be defective we'll have saved some time. Regards, David Taylor. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 06:42:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24409 for ; Thu, 14 Jun 2001 06:42:06 -0400 (EDT) Date: Thu, 14 Jun 2001 11:40:44 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from William.Yeager@Eng.Sun.COM on Wed, Jun 13, 2001 at 04:15:07PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010614114044.A19287@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Bill, Other people have already pointed out the possibility of a downgrade attack, but here are a couple more thoughts. Firstly, cryptographic protocols are much more fragile than they look (which is why I asked the question). Usually security is only achieved when the "recipe" is followed exactly. The downgrade attack is particularly nasty if you don't restrict the choice of ciphersuite, because you could be tricked into using TLS_NULL_WITH_NULL_NULL. Secondly, I would like to second Jeffrey Altman's call for these protocols to be discussed in an IETF working group. That way, these issues can be looked at by lots of different people, hopefully resulting in the best possible design. -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 08:29:02 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26340 for ; Thu, 14 Jun 2001 08:29:02 -0400 (EDT) Message-Id: Date: Thu, 14 Jun 2001 14:29:57 +0200 (CEST) From: Bodo Moeller To: "IETF Transport Layer Security WG" Cc: Hugo Krawczyk Subject: [ietf-tls] Re: A design weakness of SSL/TLS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit Hugo Krawczyk : > In a paper to be presented in the upcoming CRYPTO'2001 conference (and > available at http://eprint.iacr.org/2001/045/) I show that > the ORDER of encryption and authentication as applied to the transmitted > data by SSL/TLS (i.e, first-mac-then-encrypt) provides a weaker security > guarantee than expected. Somewhat surprisingly, it turns out that > there are very strong ciphers (e.g. providing Shannon's perfect secrecy) > that in combination with any secure MAC (even one with unconditional > security) make SSL/TLS vulnerable to attack. Is this really that surprising? Note that Mihir Bellare's and Chanathip Namprempre's ASIACRYPT 2000 paper "Authenticated Encryption: Relations among notions and analysis of the generic composition paradigm" already shows that Encrypt-then-MAC is sound while MAC-then-Encrypt and MAC-and-Encrypt have problems. (The paper should be avaiable from .) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 09:10:26 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27755 for ; Thu, 14 Jun 2001 09:10:25 -0400 (EDT) X-Authentication-Warning: blackbird.intercode.com.au: jmorris owned process doing -bs Date: Thu, 14 Jun 2001 23:08:29 +1000 (EST) From: James Morris To: "IETF Transport Layer Security WG" cc: Hugo Krawczyk , , Subject: [ietf-tls] Re: A design weakness of SSL/TLS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net On Thu, 14 Jun 2001, Bodo Moeller wrote: > Hugo Krawczyk : > > > In a paper to be presented in the upcoming CRYPTO'2001 conference (and > > available at http://eprint.iacr.org/2001/045/) I show that > > the ORDER of encryption and authentication as applied to the transmitted > > data by SSL/TLS (i.e, first-mac-then-encrypt) provides a weaker security > > guarantee than expected. Somewhat surprisingly, it turns out that > > there are very strong ciphers (e.g. providing Shannon's perfect secrecy) > > that in combination with any secure MAC (even one with unconditional > > security) make SSL/TLS vulnerable to attack. > > Is this really that surprising? Note that Mihir Bellare's and > Chanathip Namprempre's ASIACRYPT 2000 paper "Authenticated Encryption: > Relations among notions and analysis of the generic composition > paradigm" already shows that Encrypt-then-MAC is sound while > MAC-then-Encrypt and MAC-and-Encrypt have problems. > It's interesting that Ferguson and Schneier's paper "A Cryptographic Evaluation of IPSec" criticises IPsec's Encrypt-then-MAC for violating the Horton Principle (authenticate what was meant, not what was said), and refers to SSL's authentication of plaintext as the correct method. - James -- James Morris --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 12:45:08 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03834 for ; Thu, 14 Jun 2001 12:45:07 -0400 (EDT) Date: Thu, 14 Jun 2001 19:43:55 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: WG Last Call for "AES Ciphersuites for TLS" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Russ, > > SSL and TLS are widely deployed, and changing mac-then-encrypt to > encrypt-then-mac is not a trivial change. In my view, it creates a whole > new protocol. Therefore, I would like to avoid such a change if we can > find a way to characterize the algorithms and modes that are safe with the > current protocol (especially since the widely implemented algorithms are safe). > I have no problem with this view of yours. Although my paper raises questions about the robustness and genericity of the TLS design it also shows the current specification to be secure (something that turned out to be much less obvious that one could think) However, I do not have a simple characterization of the good algorithms and modes as you ask for (it is actually an open question stated in the paper to find such a simple and useful characterization). As I said before: you can say that what is NOW in TLS is good. This is so as long as your block cipher is secure and your processing is exactly as defined in TLS. Similarly, in the case of stream cipher, if all the cipher does is to produce a secure pseudo-random pad and xor it with the data (without further processing of the plaintext). But if you want to change to a different mode, to a different proecessing of the encryption, to random IV per-message, to an unauthenticated encoding of the message, or who knows what other idea, then you have to re-analyze the protocol. Hugo PS: An answer to some other message: there is no problem with TLS compression. When I said that encoding of plaintext before encryption may be problematic (as some examples show) I was referring to an encoding that is part of the encryption algorithm and then not authenticated under the MAC. An encoding that is done before the MAC is applied (such as the case of compression) is fine. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 12:45:45 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03865 for ; Thu, 14 Jun 2001 12:45:44 -0400 (EDT) Date: Thu, 14 Jun 2001 19:45:15 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" cc: ietf-tls@lists.certicom.com Subject: [ietf-tls] Re: A design weakness of SSL/TLS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id MAA03865 On Thu, 14 Jun 2001, Bodo Moeller wrote: > Hugo Krawczyk : > > > In a paper to be presented in the upcoming CRYPTO'2001 conference (and > > available at http://eprint.iacr.org/2001/045/) I show that > > the ORDER of encryption and authentication as applied to the transmitted > > data by SSL/TLS (i.e, first-mac-then-encrypt) provides a weaker security > > guarantee than expected. Somewhat surprisingly, it turns out that > > there are very strong ciphers (e.g. providing Shannon's perfect secrecy) > > that in combination with any secure MAC (even one with unconditional > > security) make SSL/TLS vulnerable to attack. > > Is this really that surprising? Note that Mihir Bellare's and > Chanathip Namprempre's ASIACRYPT 2000 paper "Authenticated Encryption: > Relations among notions and analysis of the generic composition > paradigm" already shows that Encrypt-then-MAC is sound while > MAC-then-Encrypt and MAC-and-Encrypt have problems. > > (The paper should be avaiable from .) Bodo, I think this question is more of academic interest than TLS interest but since you ask I'll respond. You'll find an answer to your question in my paper where I address this issue explicitly. Summary: Indeed [BN] prove that AtE is not necessarily CCA-secure. However, as it turns out by the recent results, being CCA-secure is no guarantee for security or insecurity for the purpose of building a "secure channels" protocol as TLS. To make the point even clearer, if you take the specific example in [BN] with which they show the "insecurity" of AtE composition and you plug that example as your data protection function in TLS, the resultant protocol IS SECURE. Is there a bug in [BN]? No. It is just that your conclusion that their result invalidates AtE as the method for secure channels is incorrect. (Or, in other words, CCA is not the validating notion when the problem that you are trying to solve is secure communications) Hugo > > > -- > Bodo Möller > PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html > * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt > * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 > > --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 13:49:03 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05314 for ; Thu, 14 Jun 2001 13:49:01 -0400 (EDT) Date: Thu, 14 Jun 2001 10:46:41 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | Bill: | | You should probably pay attention to the discussion about performing | the Mac after the Encryption. The opposite of the TLS order. Thanks for the pointer. I was thinking about certs in advertisements on the way home, and JXTA really needs this because they are to be used for more than TLS. Lots of apps need certs, eg, JXTA email (a project to be soon proposed). Still, there is no need to put the crypto suites in the advertisement, and maybe, one would do a cert refresh when TLS is required ... Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 13:52:29 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05399 for ; Thu, 14 Jun 2001 13:52:28 -0400 (EDT) Date: Thu, 14 Jun 2001 13:52:09 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Thu, 14 Jun 2001 10:46:41 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > | Bill: > | > | You should probably pay attention to the discussion about performing > | the Mac after the Encryption. The opposite of the TLS order. > > Thanks for the pointer. I was thinking about certs in advertisements on the > way home, and JXTA really needs this because they are to be used for more than > TLS. Lots of apps need certs, eg, JXTA email (a project to be soon proposed). > > Still, there is no need to put the crypto suites in the advertisement, and > maybe, one would do a cert refresh when TLS is required ... > > Bill Bill I'm also a little concerned about the "unreliability" of the JXTA pipes. It would be nice to have the secure pipes not require reliability. In addition, it is very important to me that Kerberos be usable instead of certificates the the applications I am building on top of JXTA. This is because I want to secure my p2p communications with Kerberos 5 User to User mode. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 14:35:02 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07025 for ; Thu, 14 Jun 2001 14:35:01 -0400 (EDT) Date: Thu, 14 Jun 2001 11:34:33 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | Firstly, cryptographic protocols are much more fragile than they look | (which is why I asked the question). Usually security is only | achieved when the "recipe" is followed exactly. The downgrade attack | is particularly nasty if you don't restrict the choice of ciphersuite, | because you could be tricked into using TLS_NULL_WITH_NULL_NULL. We are going to restrict the choice of cipher suites by necessity. Right now, our code base is small, and I'm not finding lots of voluteers to help make it grow )-: (I don't mean to contradict myself with respect to Camellia. I've known about Camellia for a long time). And, certainly, it now makes good sense to use the HMAC to make sure such an attack is not possible. I had not thought about it, and we will not put the cipher suites in advertisements for sure. | Secondly, I would like to second Jeffrey Altman's call for these | protocols to be discussed in an IETF working group. That way, these | issues can be looked at by lots of different people, hopefully | resulting in the best possible design. I "third" this. The only obstacle is work load. I'm looking at taking the next rev of the specs and turning it into a draft-rfc. I've been involved with the IETF for a long, long time, and really respect the work that gets done there. You don't see my name many places wrt to the RFC space, but you will find lots of apps out there that I've written based on the specs. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 14:55:33 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07495 for ; Thu, 14 Jun 2001 14:55:32 -0400 (EDT) Date: Thu, 14 Jun 2001 11:55:30 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT Jeff, Can we continue this discussion on the discuss@security.jxta.org mailing list? It is becoming very relevant to the work will be going on there. | I'm also a little concerned about the "unreliability" of the JXTA | pipes. It would be nice to have the secure pipes not require | reliability. Are you saying that you would like pipe/secure pipes not to require end-to-end reliability? I don't think that can be a requirement by the very nature of p2p networks. Connections can disappear anytime. Are we talking about the same thing? | In addition, it is very important to me that Kerberos be usable | instead of certificates the the applications I am building on top of | JXTA. This is because I want to secure my p2p communications with | Kerberos 5 User to User mode. What is placed in the advertisement is peer dependent. I would love to have a general scheme much like the IMAP capability command, with its AUTH=, and AUTHENTICATE. THis is all new, and we need discussions to correctly bootstrap the security part of JXTA. Right, and we really require input from IETF. This is becoming more and more apparent with each message I receive from this list! Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 15:12:55 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07935 for ; Thu, 14 Jun 2001 15:12:53 -0400 (EDT) Date: Thu, 14 Jun 2001 15:12:58 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Thu, 14 Jun 2001 11:55:30 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > Jeff, > > Can we continue this discussion on the discuss@security.jxta.org mailing list? > It is becoming very relevant to the work will be going on there. Done. > | I'm also a little concerned about the "unreliability" of the JXTA > | pipes. It would be nice to have the secure pipes not require > | reliability. > Are you saying that you would like pipe/secure pipes not to require > end-to-end reliability? I don't think that can be a requirement by > the very nature of p2p networks. Connections can disappear > anytime. Are we talking about the same thing? We are talking about a different thing. TLS assumes that the underlying connections (pipes) have the same or better reliability provided by TCP/IP. In JXTA, this assumption does not hold. As far as I can tell but I may be off a bit here, the JXTA pipe model in addition to being only unidirectional provides UDP reliability. Not only do we not know whether or not all of the messages that were sent have been received, but we cannot ensure that they were received in the correct order. JXTA also allows multiple senders to attach to a single input pipe. Therefore, it is possible for message streams to be mixed. The JXTA security model is certainly going to have to take this into account. For a TLS streaming model to work, then we must require TCP style reliability with regard to message delivery. For pipes that do not have these characteristics (and applications that do not require them) we will need a different model that simply encrypts and signs individual messages without regard to order. This will clearly affect the cipher suites that can be used. > | In addition, it is very important to me that Kerberos be usable > | instead of certificates the the applications I am building on top of > | JXTA. This is because I want to secure my p2p communications with > | Kerberos 5 User to User mode. > > What is placed in the advertisement is peer dependent. I would love to have a > general scheme much like the IMAP capability command, with its AUTH=, and > AUTHENTICATE. > > THis is all new, and we need discussions to correctly bootstrap the security > part of JXTA. Right, and we really require input from IETF. This is becoming > more and more apparent with each message I receive from this list! Its may not be too late to schedule a BOF for London (August) although we can certainly push it off until IETF 52 (December). - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 15:32:27 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08426 for ; Thu, 14 Jun 2001 15:32:26 -0400 (EDT) Message-ID: Date: Thu, 14 Jun 2001 20:32:16 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B291140.93287095@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > > > Jeff, > > > > Can we continue this discussion on the discuss@security.jxta.org mailing list? > > It is becoming very relevant to the work will be going on there. > > Done. > > > | I'm also a little concerned about the "unreliability" of the JXTA > > | pipes. It would be nice to have the secure pipes not require > > | reliability. > > > Are you saying that you would like pipe/secure pipes not to require > > end-to-end reliability? I don't think that can be a requirement by > > the very nature of p2p networks. Connections can disappear > > anytime. Are we talking about the same thing? > > We are talking about a different thing. TLS assumes that the > underlying connections (pipes) have the same or better reliability > provided by TCP/IP. In JXTA, this assumption does not hold. > > As far as I can tell but I may be off a bit here, the JXTA pipe model > in addition to being only unidirectional provides UDP reliability. > Not only do we not know whether or not all of the messages that were > sent have been received, but we cannot ensure that they were received > in the correct order. > > JXTA also allows multiple senders to attach to a single input pipe. > Therefore, it is possible for message streams to be mixed. The JXTA > security model is certainly going to have to take this into account. This doesn't have to be visible at the application layer, of course (that is, you can use secure one-to-one pipes underneath but make it look at the application level like there are multiple senders to a single pipe). > For a TLS streaming model to work, then we must require TCP style > reliability with regard to message delivery. For pipes that do not > have these characteristics (and applications that do not require them) > we will need a different model that simply encrypts and signs > individual messages without regard to order. This will clearly affect > the cipher suites that can be used. I'm still confused by what you are asking for - do you _want_ this kind of transport, or think it is necessary, or want to avoid it, or what? > > | In addition, it is very important to me that Kerberos be usable > > | instead of certificates the the applications I am building on top of > > | JXTA. This is because I want to secure my p2p communications with > > | Kerberos 5 User to User mode. > > > > What is placed in the advertisement is peer dependent. I would love to have a > > general scheme much like the IMAP capability command, with its AUTH=, and > > AUTHENTICATE. > > > > THis is all new, and we need discussions to correctly bootstrap the security > > part of JXTA. Right, and we really require input from IETF. This is becoming > > more and more apparent with each message I receive from this list! > > Its may not be too late to schedule a BOF for London (August) although > we can certainly push it off until IETF 52 (December). I'd certainly come to one in London. Cheers. Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 15:39:25 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08575 for ; Thu, 14 Jun 2001 15:39:24 -0400 (EDT) Date: Thu, 14 Jun 2001 15:39:09 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Thu, 14 Jun 2001 20:32:16 +0100 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > > For a TLS streaming model to work, then we must require TCP style > > reliability with regard to message delivery. For pipes that do not > > have these characteristics (and applications that do not require them) > > we will need a different model that simply encrypts and signs > > individual messages without regard to order. This will clearly affect > > the cipher suites that can be used. > > I'm still confused by what you are asking for - do you _want_ this kind > of transport, or think it is necessary, or want to avoid it, or what? I believe that JXTA must provide both reliable and unreliable secure pipes as part of the core protocols. > > Its may not be too late to schedule a BOF for London (August) although > > we can certainly push it off until IETF 52 (December). > > I'd certainly come to one in London. I would be happy to meet you there whether we have one or not. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 16:05:39 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08983 for ; Thu, 14 Jun 2001 16:05:38 -0400 (EDT) Message-ID: Date: Thu, 14 Jun 2001 21:05:31 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B29190B.5F3A1383@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > > > > For a TLS streaming model to work, then we must require TCP style > > > reliability with regard to message delivery. For pipes that do not > > > have these characteristics (and applications that do not require them) > > > we will need a different model that simply encrypts and signs > > > individual messages without regard to order. This will clearly affect > > > the cipher suites that can be used. > > > > I'm still confused by what you are asking for - do you _want_ this kind > > of transport, or think it is necessary, or want to avoid it, or what? > > I believe that JXTA must provide both reliable and unreliable secure > pipes as part of the core protocols. OK. The obvious way to do unreliable would be to use OpenPGP, wouldn't it? At least, assuming PKC is considered to be a good idea (I think it is). Actually, is there any point in going beyond IPSEC/ISAKMP? > > > Its may not be too late to schedule a BOF for London (August) although > > > we can certainly push it off until IETF 52 (December). > > > > I'd certainly come to one in London. > > I would be happy to meet you there whether we have one or not. I'll be there! Even remembered to register :-) Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 16:18:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09158 for ; Thu, 14 Jun 2001 16:18:51 -0400 (EDT) Date: Thu, 14 Jun 2001 16:18:21 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Thu, 14 Jun 2001 21:05:31 +0100 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > > I believe that JXTA must provide both reliable and unreliable secure > > pipes as part of the core protocols. > > OK. The obvious way to do unreliable would be to use OpenPGP, wouldn't > it? At least, assuming PKC is considered to be a good idea (I think it > is). OpenPGP is certainly the obvious choice for a distributed trust model. > Actually, is there any point in going beyond IPSEC/ISAKMP? Maybe not. I'm not really sure yet. I'm still playing around with different models of peer groups. > I'll be there! Even remembered to register :-) :-) I just reserved a room. Now to find a flight..... See you there. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 16:56:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09672 for ; Thu, 14 Jun 2001 16:56:45 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Thu, 14 Jun 2001 13:57:29 -0700 From: Tom Wu Organization: Arcot Systems X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Different message digest schemes for SRP? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B292539.C313EE3F@arcot.com> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Taylor wrote: > > Hi, > > A GNU TLS project has been started, and while they were waiting for ASN.1 > software they decided to implement the SRP cipher suite. > > In doing this, they've added a feature whereby the message digest used with > SRP can be selected. Are you referring to the digest used to convert the password into a private key, or the digest used for computing the "proof" hashes in the Finished messages? If it's the former, I would hold off on trying to extend the standard to accommodate alternate hashes until the interoperability issues are worked out. > My implementation just used SHA-1 as per the RFC. The GNU guys have added a > blowfish based option too. > > Is this useful enough to put in the draft? Or is leaving it with SHA-1 good > enough? > > I imagine the client will have to present a list of SRP message digests it > knows, along with the user name. Then the server will have to respond with > the one it selected, along with the n, g, s parameters. Assuming that we're talking about the password hash being selectable, you'd have to have the client send the user name to the server, and then have the server respond with the message digest used, along with n, g, and s. But this leads to interoperability problems because a SHA-only client could not talk to a server that allowed both SHA and blowfish. > I feel SRP with SHA-1 is good enough, although if there is already a spot > for a replacement if SHA-1 is found to be defective we'll have saved some > time. I agree. Stick to SHA-1. > Regards, > David Taylor. -- Tom Wu Principal Software Engineer Arcot Systems (408) 969-6124 "The Borg? Sounds Swedish..." --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 17:08:57 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09814 for ; Thu, 14 Jun 2001 17:08:56 -0400 (EDT) Delivered-To: fixup-ietf-tls@lists.certicom.com@fixme Message-ID: Date: Thu, 14 Jun 2001 14:04:31 -0700 From: Joseph Salowey X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" CC: jsalowey@cisco.com Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B2926DE.BD6B98B4@qwest.net> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bill Yeager wrote: > > | In addition, it is very important to me that Kerberos be usable > | instead of certificates the the applications I am building on top of > | JXTA. This is because I want to secure my p2p communications with > | Kerberos 5 User to User mode. > > What is placed in the advertisement is peer dependent. I would love to have a > general scheme much like the IMAP capability command, with its AUTH=, and > AUTHENTICATE. > > THis is all new, and we need discussions to correctly bootstrap the security > part of JXTA. Right, and we really require input from IETF. This is becoming > more and more apparent with each message I receive from this list! > There is also onging work defining kerberos ciphersuites for TLS that support user to user mode. (A new draft should be out soon). Joe --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 17:33:16 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10145 for ; Thu, 14 Jun 2001 17:33:15 -0400 (EDT) Date: Thu, 14 Jun 2001 14:33:34 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT Jeff, | As far as I can tell but I may be off a bit here, the JXTA pipe model | in addition to being only unidirectional provides UDP reliability. | Not only do we not know whether or not all of the messages that were | sent have been received, but we cannot ensure that they were received | in the correct order. This has had lots of internal discussion as you can imagine. I think reliability is extremely important. To that end, reliability layer on top of pipes has been proposed. In the simple sense, it is an ACK of data sent, and a guarantee of the correctness of order. This could be TFTP like, or a generalization. Sigh ... But, I have argued that if a pipe has TCP/IP as the underlying transport, and since this is known to the pipe end-points, we should take advantage of that to have both reliable, and bi-directional pipes with almost no software changes. I don't see this as controversial at all. I've mentioned it on discuss@jxta.org. | JXTA also allows multiple senders to attach to a single input pipe. | Therefore, it is possible for message streams to be mixed. The JXTA | security model is certainly going to have to take this into account. Yes and no. If we were using UDP/IP, sure, and what a mess for the dispatcher! In the current implementation, this is not done if the underlying transport is TCP/IP. These pipes are connection based, and handled like a primitive http server on a jxta message by message basis in a single input thread with a FIFO for connections. Listen, connect, read message, dispatch message, close, listen, connect ... So, for TLS, if one maintained sessions across messages, this should work. That needs to be fixed! I understand there is a project brewing to change the JXTA end-point resolver to solve this problem. Bi-directional, reliable byte streams end-to-end. Does this help? | | Its may not be too late to schedule a BOF for London (August) although | we can certainly push it off until IETF 52 (December). Let me take this up with my management. London may be possible, and otherwise, December is a must. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 17:36:58 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10204 for ; Thu, 14 Jun 2001 17:36:57 -0400 (EDT) Date: Thu, 14 Jun 2001 14:36:56 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | OpenPGP is certainly the obvious choice for a distributed trust | model. I'm checking this out as you read this message. I can send you another ref on trust by recommendation, if you are interested. It resembles very closely the PGP Web of Trust. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 18:07:40 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10592 for ; Thu, 14 Jun 2001 18:07:39 -0400 (EDT) Date: Thu, 14 Jun 2001 18:06:51 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Thu, 14 Jun 2001 14:33:34 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > But, I have argued that if a pipe has TCP/IP as the underlying transport, and > since this is known to the pipe end-points, we should take advantage of that > to have both reliable, and bi-directional pipes with almost no software > changes. I don't see this as controversial at all. I've mentioned it on > discuss@jxta.org. This will work as long as A <--> B but it will break down if A <--> C <--> B. Do we really want to have a different security model for different kinds of pipes? > | JXTA also allows multiple senders to attach to a single input pipe. > | Therefore, it is possible for message streams to be mixed. The JXTA > | security model is certainly going to have to take this into account. > > Yes and no. If we were using UDP/IP, sure, and what a mess for the dispatcher! > In the current implementation, this is not done if the underlying transport is > TCP/IP. These pipes are connection based, and handled like a primitive http > server on a jxta message by message basis in a single input thread with a FIFO > for connections. Listen, connect, read message, dispatch message, close, > listen, connect ... So, for TLS, if one maintained sessions across messages, > this should work. That needs to be fixed! > > I understand there is a project brewing to change the JXTA end-point resolver > to solve this problem. Bi-directional, reliable byte streams end-to-end. > > Does this help? It only helps only if it going to be the mandatory to implement pipe. However, I see a large majority of JXTA peers using an HTTP proxy in the near future. And of course, in that scenario any discussions we have about using TCP/IP go out the window. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 18:17:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10692 for ; Thu, 14 Jun 2001 18:17:27 -0400 (EDT) Message-ID: Date: Thu, 14 Jun 2001 23:15:59 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B29379F.30FC502F@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bill Yeager wrote: > > Jeff, > > | As far as I can tell but I may be off a bit here, the JXTA pipe model > | in addition to being only unidirectional provides UDP reliability. > | Not only do we not know whether or not all of the messages that were > | sent have been received, but we cannot ensure that they were received > | in the correct order. > > This has had lots of internal discussion as you can imagine. I think > reliability is extremely important. To that end, reliability layer on top of > pipes has been proposed. In the simple sense, it is an ACK of data sent, and a > guarantee of the correctness of order. This could be TFTP like, or a > generalization. Sigh ... Reinventing the wheel is a bad thing. If you want reliable, why not use existing underlying reliable transports? BTW, I didn't notice any mention of multicast in JXTA, which seems like a shame. Any plans there? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 14 19:51:12 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11586 for ; Thu, 14 Jun 2001 19:51:11 -0400 (EDT) X-Authentication-Warning: blackbird.intercode.com.au: jmorris owned process doing -bs Date: Fri, 15 Jun 2001 09:50:13 +1000 (EST) From: James Morris To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: A design weakness of SSL/TLS (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Niels asked me to forward this to the list, as his mail bounced from the server. ---------- Forwarded message ---------- Date: Thu, 14 Jun 2001 21:43:13 +0200 From: Niels Ferguson To: James Morris , IETF Transport Layer Security WG Cc: Hugo Krawczyk , niels@counterpane.com, schneier@counterpane.com Subject: Re: [ietf-tls] Re: A design weakness of SSL/TLS At 23:08 14/06/01 +1000, James Morris wrote: >On Thu, 14 Jun 2001, Bodo Moeller wrote: > >> Hugo Krawczyk : >> >> > In a paper to be presented in the upcoming CRYPTO'2001 conference (and >> > available at http://eprint.iacr.org/2001/045/) I show that >> > the ORDER of encryption and authentication as applied to the transmitted >> > data by SSL/TLS (i.e, first-mac-then-encrypt) provides a weaker security >> > guarantee than expected. Somewhat surprisingly, it turns out that >> > there are very strong ciphers (e.g. providing Shannon's perfect secrecy) >> > that in combination with any secure MAC (even one with unconditional >> > security) make SSL/TLS vulnerable to attack. >> >> Is this really that surprising? Note that Mihir Bellare's and >> Chanathip Namprempre's ASIACRYPT 2000 paper "Authenticated Encryption: >> Relations among notions and analysis of the generic composition >> paradigm" already shows that Encrypt-then-MAC is sound while >> MAC-then-Encrypt and MAC-and-Encrypt have problems. >> > >It's interesting that Ferguson and Schneier's paper "A Cryptographic >Evaluation of IPSec" criticises IPsec's Encrypt-then-MAC for violating >the Horton Principle (authenticate what was meant, not what was said), and >refers to SSL's authentication of plaintext as the correct method. I just got a copy of this from James Morris. I'm not on the TLS list so I don't know the context in which this discussion is taking place. I do have some comments. The "Horton Principle" was formulated after encountering problems in real systems. In our years of consulting we had the opportunity to analyse many fielded systems, including many proprietary ones. We broke the authentication property of several systems because the authentication would not extend to the contextual information used to interpret the authenticated data. In an encrypt-then-authenticate system the receiver first checks the authentication and then decrypts the (authenticated) ciphertext. If the receiver is using a different decryption key than the original sender intended to be used, then the received plaintext will be incorrect even though the message was authenticated. This is one of the problems that we found in IPsec. A (re)negotiated ESP connection inside a manually keyed AH connection does not provide authentication. This is of course a contrived configuration, but it is something allowed by the standard, and presumably allowed by many IPsec implementations. The basic "Horton Principle" rule is to authenticate what is meant, not was is said. The easiest way to do this is to authenticate-then-encrypt. (The authentication should also include all other system data that is used in assigning meaning to the message, but that is not relevant in this discussion.) Alternatively you can encrypt-then-authenticate as long as you include the decryption key in the authentication. Many systems don't do this, and rely on the fact that the authentication and encryption keys are tied together through the key negotiation protocol. This is a valid approach, but we have seen enough key negotiation protocols that do not have this property. I have never seen it specified as a requirement for the negotiation protocol. Adding such hidden requirements to other modules of the system is a bad idea. I scanned through Hugo Krawczyk's paper (http://eprint.iacr.org/2001/045/) to look at the (claimed) problem with authenticate-then-encrypt. The encryption scheme that leads to a weakness in authenticate-then-encrypt satisfies the IND-CPA property. In the definition of the IND-CPA property the attacker is limited using an encryption oracle, but has no access to a decryption oracle. As an engineer I find the IND-CPA definition useless because it has no relation to the real world. In real life there is almost always a party that performs the decryption, and we must assume that the attacker has access to a decryption oracle of some form. (In many systems the recipient will respond with a recognisable error code when the decrypted message makes no sense. The attacker can use this to gather information: send a bogus ciphertext to the receiver and check for the error code.) The 'attack' on authenticate-then-encrypt uses an encryption scheme that is not secure when the attacker has a decryption oracle of the type mentioned above. The paper explicitly mentions that even without any authentication, the encryption scheme is not secure when used to encrypt messages. The authenticate-then-encrypt scheme proposed is insecure because the encryption scheme is insecure. This has _nothing_ to do with the authenticate-then-encrypt construction. The encryption scheme is weak. The fact that the encryption scheme is IND-CPA is a criticism of the IND-CPA definition, not an indication of a problem with the authenticate-then-encrypt construction. If we want to we can also define an authentication scheme and an encryption scheme under which authenticate-then-encrypt is secure but encrypt-then-authenticate is weak. I don't think this tells us anything about the relative merit of authenticate-then-encrypt and encrypt-then-authenticate. Cheers! Niels ============================================================== Niels Ferguson, niels@ferguson.net, phone: +31 20 463 0977 PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 07:11:34 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03084 for ; Fri, 15 Jun 2001 07:11:33 -0400 (EDT) Date: Fri, 15 Jun 2001 12:11:53 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from William.Yeager@Eng.Sun.COM on Thu, Jun 14, 2001 at 11:55:30AM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010615121153.C21179@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Bill Yeager wrote: > What is placed in the advertisement is peer dependent. I would love to have a > general scheme much like the IMAP capability command, with its AUTH=, and > AUTHENTICATE. Isn't this insecure for the same reason as the altered TLS? An attacker could force you to use the weakest supported protocol. Suppose your systems supported TLS and a plaintext password protocol called PLAIN. The server sends: AUTH = TLS PLAIN The client supports both these too, so normally it would respond TLS. However if an attacker changed the message to read: AUTH = PLAIN the client would respond PLAIN and the data sent could be compromised. (I suppose this wouldn't be a problem if the client had a QoS parameter saying that a certain level of security was required. Then it could refuse to connect if the only method on offer was PLAIN.) -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 07:34:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03418 for ; Fri, 15 Jun 2001 07:34:12 -0400 (EDT) Message-ID: Date: Fri, 15 Jun 2001 12:33:58 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B29F2A6.6E52BDED@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > Bill Yeager wrote: > > > What is placed in the advertisement is peer dependent. I would love to have a > > general scheme much like the IMAP capability command, with its AUTH=, and > > AUTHENTICATE. > > Isn't this insecure for the same reason as the altered TLS? An > attacker could force you to use the weakest supported protocol. > Suppose your systems supported TLS and a plaintext password protocol > called PLAIN. The server sends: > > AUTH = TLS PLAIN > > The client supports both these too, so normally it would respond TLS. > However if an attacker changed the message to read: > > AUTH = PLAIN > > the client would respond PLAIN and the data sent could be compromised. > > (I suppose this wouldn't be a problem if the client had a QoS > parameter saying that a certain level of security was required. Then > it could refuse to connect if the only method on offer was PLAIN.) If you aren't prepared to support the weakest protocol, why did you advertise it? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 08:08:30 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04515 for ; Fri, 15 Jun 2001 08:08:29 -0400 (EDT) Date: Fri, 15 Jun 2001 8:08:52 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Fri, 15 Jun 2001 12:11:53 +0100 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > Bill Yeager wrote: > > > What is placed in the advertisement is peer dependent. I would love to have a > > general scheme much like the IMAP capability command, with its AUTH=, and > > AUTHENTICATE. > > Isn't this insecure for the same reason as the altered TLS? An > attacker could force you to use the weakest supported protocol. > Suppose your systems supported TLS and a plaintext password protocol > called PLAIN. The server sends: > > AUTH = TLS PLAIN > > The client supports both these too, so normally it would respond TLS. > However if an attacker changed the message to read: > > AUTH = PLAIN > > the client would respond PLAIN and the data sent could be compromised. > > (I suppose this wouldn't be a problem if the client had a QoS > parameter saying that a certain level of security was required. Then > it could refuse to connect if the only method on offer was PLAIN.) > > -- > Pete Yes. This has the same problems. At some point in the authentication process the list of offered methods must be protected. If not, you are open to a downgrade attack. The problem with QoS parameters is that they are inevitably hard coded. What is secure today may not be secure tomorrow after some new discovery. The important issue is whether or not the communication channel is being tampered with. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 08:57:34 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06017 for ; Fri, 15 Jun 2001 08:57:32 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Different message digest schemes for SRP? Date: Fri, 15 Jun 2001 07:40:01 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <000f01c0f51a$91329520$c3b3093d@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > > I imagine the client will have to present a list of SRP message digests it > > knows, along with the user name. Then the server will have to respond with > > the one it selected, along with the n, g, s parameters. > > Assuming that we're talking about the password hash being selectable, > you'd have to have the client send the user name to the server, and then > have the server respond with the message digest used, along with n, g, > and s. But this leads to interoperability problems because a SHA-only > client could not talk to a server that allowed both SHA and blowfish. I wasn't thinking very hard when I wrote the message. What you say makes sense, and the paper they pointed me to mentioned OpenBSD using the scheme for passwords, so it is probably as you say. I could still put the selection mechanism there, but define SHA-1 as the only option for now. It will add a single byte to the structure (if it's a small enum), and should not be difficult. My question was more along the lines of "is it possible that SRP will use different password hashing schemes in future?" Regards, David. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 09:09:23 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06348 for ; Fri, 15 Jun 2001 09:09:22 -0400 (EDT) Date: Fri, 15 Jun 2001 16:08:46 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" cc: IETF Transport Layer Security WG , niels@counterpane.com, schneier@counterpane.com Subject: [ietf-tls] Re: A design weakness of SSL/TLS In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > > > > It's interesting that Ferguson and Schneier's paper "A Cryptographic > Evaluation of IPSec" criticises IPsec's Encrypt-then-MAC for violating > the Horton Principle (authenticate what was meant, not what was said), and > refers to SSL's authentication of plaintext as the correct method. > The recent results show that Encrypt-then-MAC is a better and more robust method for generic and (hopefully) long-lived protocols such as TLS and IPsec. In my opinion, the above criticism against ipsec is not justified in the case of ESP which combines encryption and authentication in the right way. A valid criticism could have been applied to the early design of ipsec where authentication and confidentiality were provided by two different protocols, AH and ESP, and their intereaction and order of composition was not uniquely specified. Fortunately, however, ESP was eventually corrected to include authentication and we got a GOOD protocol. There is howver one issue related to Encrypt-then-MAC and the "Horton principle" that is relevat here and I discuss it in remark 4.1 of my paper: Note that the authentication of the ciphertext provides plaintext integrity as long as the encryption and decryption keys used at the sender and receiver, respectively, are the same. While this key synchrony is implicit in our analytical models \cite{ck}, a key mismatch can happen in practice. A system concerned with detecting such cases can check the plaintext for redundancy information (such redundancy exists in most applications: e.g., message formats, non-cryptographic checksums, etc.). If the redundancy entropy is significant then a key mismatch will corrupt this redundancy with high probability. In TLS where the encryption and MAC key are derived together from the same key this situation is quite improbable. Yet, if one was to design TLS under the EtA method this issue had to be addressed. Hugo --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 09:18:46 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06826 for ; Fri, 15 Jun 2001 09:18:45 -0400 (EDT) Date: Fri, 15 Jun 2001 16:18:53 +0300 (IDT) From: Hugo Krawczyk To: "IETF Transport Layer Security WG" cc: James Morris , IETF Transport Layer Security WG , niels@counterpane.com, schneier@counterpane.com Subject: [ietf-tls] Re: A design weakness of SSL/TLS In-Reply-To: <3.0.3.32.20010614214313.00952270@pop.xs4all.nl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Niels, If I understand your comments below, what you are saying is something like: "The negative results in Hugo's paper have no practical signifcance since they assume the encryption function to be IND-CPA, and such a security notion is obviously too weak to provide a secure MAC/encryption composition" (Note for those that did not read the paper: IND-CPA is just a scary acronym used in the crypto literature to mean resistance of an encryption function to chosen-plaintext attacks) Well, Niels, this is plain wrong. So either I misunderstood you (please correct me) or you misunderstood the paper. If what you said was true then we had no hope to create a secure protocol out of the common modes of encryption in use, including CBC encryption and stream ciphers. Indeed all these modes are just IND-CPA (i.e., resistnat to chosen plaintext attacks but not to chosen-ciphertext attacks, which is what you refer to when talking about decryption oracles). In particular, this would have left us with no hope for the security of TLS which uses these modes of encryption. What really gives PRACTICAL significance to the recent results is that they do NOT assume any fancy features of encryption not present in the EXISTING (and easier to design) encryption modes, but only assume resistance to chosen plaintext attacks (IND-CPA) which is what these modes really are. "As an engineer" you should ask yourself what is the right way to use the existing (and future) PRACTICAL cryptographic schemes, rather than to build on strong notions of security not achieved by the existing encryption functions. Hugo > > I scanned through Hugo Krawczyk's paper (http://eprint.iacr.org/2001/045/) > to look at the (claimed) problem with authenticate-then-encrypt. The > encryption scheme that leads to a weakness in authenticate-then-encrypt > satisfies the IND-CPA property. In the definition of the IND-CPA property > the attacker is limited using an encryption oracle, but has no access to a > decryption oracle. As an engineer I find the IND-CPA definition useless > because it has no relation to the real world. In real life there is almost > always a party that performs the decryption, and we must assume that the > attacker has access to a decryption oracle of some form. (In many systems > the recipient will respond with a recognisable error code when the > decrypted message makes no sense. The attacker can use this to gather > information: send a bogus ciphertext to the receiver and check for the > error code.) > > The 'attack' on authenticate-then-encrypt uses an encryption scheme that is > not secure when the attacker has a decryption oracle of the type mentioned > above. The paper explicitly mentions that even without any authentication, > the encryption scheme is not secure when used to encrypt messages. The > authenticate-then-encrypt scheme proposed is insecure because the > encryption scheme is insecure. This has _nothing_ to do with the > authenticate-then-encrypt construction. The encryption scheme is weak. The > fact that the encryption scheme is IND-CPA is a criticism of the IND-CPA > definition, not an indication of a problem with the > authenticate-then-encrypt construction. > > If we want to we can also define an authentication scheme and an encryption > scheme under which authenticate-then-encrypt is secure but > encrypt-then-authenticate is weak. I don't think this tells us anything > about the relative merit of authenticate-then-encrypt and > encrypt-then-authenticate. > > Cheers! > > Niels > > > ============================================================== > Niels Ferguson, niels@ferguson.net, phone: +31 20 463 0977 > PGP: 3EC2 3304 9B6E 27D9 72E7 E545 C1E0 5D7E > --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 13:58:53 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19861 for ; Fri, 15 Jun 2001 13:58:53 -0400 (EDT) Message-Id: Date: Fri, 15 Jun 2001 19:12:32 +0200 (CEST) From: Bodo Moeller To: "IETF Transport Layer Security WG" Cc: Hugo Krawczyk Subject: [ietf-tls] Re: A design weakness of SSL/TLS In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit Hugo Krawczyk : > On Thu, 14 Jun 2001, Bodo Moeller wrote: >> Hugo Krawczyk : >>> In a paper to be presented in the upcoming CRYPTO'2001 conference >>> (and available at http://eprint.iacr.org/2001/045/) I show that >>> the ORDER of encryption and authentication as applied to the >>> transmitted data by SSL/TLS (i.e, first-mac-then-encrypt) provides >>> a weaker security guarantee than expected. Somewhat surprisingly, >>> it turns out that there are very strong ciphers (e.g. providing >>> Shannon's perfect secrecy) that in combination with any secure MAC >>> (even one with unconditional security) make SSL/TLS vulnerable to >>> attack. >> Is this really that surprising? Note that Mihir Bellare's and >> Chanathip Namprempre's ASIACRYPT 2000 paper "Authenticated Encryption: >> Relations among notions and analysis of the generic composition >> paradigm" already shows that Encrypt-then-MAC is sound while >> MAC-then-Encrypt and MAC-and-Encrypt have problems. >> >> (The paper should be avaiable from .) > I think this question is more of academic interest than TLS interest > but since you ask I'll respond. > > You'll find an answer to your question in my paper where I address this > issue explicitly. > Summary: Indeed [BN] prove that AtE is not necessarily CCA-secure. > However, as it turns out by the recent results, being CCA-secure is no > guarantee for security or insecurity for the purpose of building a "secure > channels" protocol as TLS. To make the point even clearer, if you take > the specific example in [BN] with which they show the "insecurity" of AtE > composition and you plug that example as your data protection function in > TLS, the resultant protocol IS SECURE. > > Is there a bug in [BN]? No. It is just that your conclusion that their > result invalidates AtE as the method for secure channels is > incorrect. (Or, in other words, CCA is not the validating notion when the > problem that you are trying to solve is secure communications) I did not claim that your results were not new or not interesting. It just so happens that I was not surprised (quit possibly I should have been?). In your paper, you write that "These results [of Bellare and Namprempre] are insufficient in general for claiming the security, or demonstrating the insecurity, of channels that use these methods for protecting data". The example that you mention above shows that they are indeed insufficient for demonstrating the insecurity, but is it true that they are insufficient for demonstrating the security? For the encrypt-then-MAC construction with a strongly unforgeable MAC (as opposed to a weakly unforgeable MAC where the attacker may be able to come up with new MAC tags for messages for which a MAC tag is already known), Bellare and Namprempre show not only IND-CPA, but also IND-CCA and NM-CPA security and INT-PTEXT and INT-CTEXT integrity. If this does not suffice for building secure channels, then I'd really be surprised. Anyway, your paper shows that the security of the MAC-then-encrypt construction as used by TLS relies on various unspoken assumptions; thanks to a proper combination of intuition and luck, these assumptions are satisfied by TLS. I'd assume that there are more possibilites to make MAC-then-encrypt secure than considered in the paper: For example, the claim that separate message and MAC encryption is insecure (remark 5.4) does not appear to be true if stateful encryption is used (so that the attacker cannot directly influence IVs). (Additional requirements for the encryption operations are necessary, ENC* obviously must still be excluded; standard modes of operation or XOR-stream ciphers should be OK.) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 17:40:09 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00062 for ; Fri, 15 Jun 2001 17:40:08 -0400 (EDT) Date: Fri, 15 Jun 2001 14:40:31 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | This will work as long as A <--> B but it will break down if | A <--> C <--> B. The problem is well understood. And, "C" in the middle reminds me of the WAP gateway fiasco. It really hurt the WAP people. JXTA cannot repeat that error. | Do we really want to have a different security model | for different kinds of pipes? No. | It only helps only if it going to be the mandatory to implement pipe. | However, I see a large majority of JXTA peers using an HTTP proxy in | the near future. And of course, in that scenario any discussions we | have about using TCP/IP go out the window. As I said above, end-to-end TCP/IP is a must for secure pipes. We need to make sure that near future means just that, and argue strongly against any proxies that might break the integrity of a secure connection. Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP is the only alternative I personally know about for traversal. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 17:42:31 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00134 for ; Fri, 15 Jun 2001 17:42:27 -0400 (EDT) Date: Fri, 15 Jun 2001 14:42:55 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7BIT | Reinventing the wheel is a bad thing. If you want reliable, why not use | existing underlying reliable transports? | I totally agree. I've fought this battle many times, and fortunately won. The last time was in the WAP Forum where Sun and MS (can you believe) teamed up to kill a proxied WAP/TCP large file transport. WAP was going to sort of reinvent TCP between the phone and the gateway! | BTW, I didn't notice any mention of multicast in JXTA, which seems like | a shame. Any plans there? Multicast is used on the localnet as an initial attempt at discovery. Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 17:47:20 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00220 for ; Fri, 15 Jun 2001 17:47:19 -0400 (EDT) Date: Fri, 15 Jun 2001 14:47:35 -0700 (PDT) From: Bill Yeager Subject: [ietf-tls] Re: JXTA and TLS In-reply-to: Your message with ID To: "IETF Transport Layer Security WG" Reply-to: "IETF Transport Layer Security WG" Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=iso-8859-1 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id RAA00220 | Isn't this insecure for the same reason as the altered TLS? An | attacker could force you to use the weakest supported protocol. For AUTH à l'IMAP you are right. An attacker could with some effort pretent to be your server, and get your password in plain text. But, one might only offer secure authenticators, AUTH=DH,KERBEROS. Or as you have said | | (I suppose this wouldn't be a problem if the client had a QoS | parameter saying that a certain level of security was required. Then | it could refuse to connect if the only method on offer was PLAIN.) Good that you point out these problems (-: Bill --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 18:21:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00854 for ; Fri, 15 Jun 2001 18:21:51 -0400 (EDT) Message-ID: Date: Fri, 15 Jun 2001 23:23:01 +0100 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B2A8AC5.650F278B@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Bill Yeager wrote: > Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP > is the only alternative I personally know about for traversal. "RFC 3093: Firewall Enhancement Protocol" is a must-read reference for anyone planning to do this (be sure to note the publication date). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOyqKizkCAxeYt5gVAQGxEAf/VbffTskyvl7Ri7LUH3xwnZYg0iJtuA+E vzkGbC5628q5GQl9k8PzpL81BLpmu0qe65ciDGJSzootbiXFrwoeY3kwfGRPJlha 1cjt/0YJqaxs1B/2wtXw1FML8y3Z3mgd+1usITZ/xEXUg8WDlz+mRKx/drjA5koX dQbhiieQlM+HT5rRHfp8a1kc/wBvDoJj/kNMltdTdv1QsIHDkAGj7cx4JgL0EqXK TBkKgAxv7GYA1cj1pfYOuImKUWtewt8IRtOKk1bAyJLJuzZN3+FUFdFUqccS4UDm 35cFcZEXbwi3ljLeTh75kYXBPgwNvn/Z6rB1IJSpIXDWBeYRkyMMQQ== =1wLy -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 15 20:19:50 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01990 for ; Fri, 15 Jun 2001 20:19:49 -0400 (EDT) Date: Fri, 15 Jun 2001 20:20:11 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Fri, 15 Jun 2001 14:40:31 -0700 (PDT) Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > | This will work as long as A <--> B but it will break down if > | A <--> C <--> B. > > The problem is well understood. And, "C" in the middle reminds me of the WAP > gateway fiasco. It really hurt the WAP people. JXTA cannot repeat that error. > > | Do we really want to have a different security model > | for different kinds of pipes? > > No. > > | It only helps only if it going to be the mandatory to implement pipe. > | However, I see a large majority of JXTA peers using an HTTP proxy in > | the near future. And of course, in that scenario any discussions we > | have about using TCP/IP go out the window. > > As I said above, end-to-end TCP/IP is a must for secure pipes. We need to make > sure that near future means just that, and argue strongly against any proxies > that might break the integrity of a secure connection. > > Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP is the > only alternative I personally know about for traversal. > > Bill > I come from a world in which IP is not the only network protocol. In fact, I don't see why the JXTA security model needs to be tied to IP at all. I want to design and implement a security model that works for both streams and asynchronous messaging. One that will work just as well over an HTTP proxy (via client polling) as over an IPSEC secured TCP/IP socket. - Jeff Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 16 06:12:06 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22536 for ; Sat, 16 Jun 2001 06:11:51 -0400 (EDT) Message-ID: Date: Sat, 16 Jun 2001 11:09:38 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B2B3062.B83BFE09@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bill Yeager wrote: > Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP is the > only alternative I personally know about for traversal. NAT? But I have to say I am not keen on the whole concept that firewalls are things you should find ways to avoid. They are there for a purpose, you know! The right answer is to make sure it is possible to run appropriate stuff on a firewall to give appropriate access, if the appropriate people think its a good idea, surely? Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 16 06:13:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA22547 for ; Sat, 16 Jun 2001 06:13:14 -0400 (EDT) Message-ID: Date: Sat, 16 Jun 2001 11:10:04 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B2B307C.6695B314@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Bill Yeager wrote: > | BTW, I didn't notice any mention of multicast in JXTA, which seems like > | a shame. Any plans there? > > Multicast is used on the localnet as an initial attempt at discovery. I meant multicast pipes. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 16 09:55:33 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24272 for ; Sat, 16 Jun 2001 09:55:32 -0400 (EDT) Date: Sat, 16 Jun 2001 8:58:37 EDT From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS In-Reply-To: Your message of Sat, 16 Jun 2001 11:09:38 +0100 Message-ID: List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net > Bill Yeager wrote: > > Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP is the > > only alternative I personally know about for traversal. > > NAT? But I have to say I am not keen on the whole concept that firewalls > are things you should find ways to avoid. They are there for a purpose, > you know! The right answer is to make sure it is possible to run > appropriate stuff on a firewall to give appropriate access, if the > appropriate people think its a good idea, surely? > > Cheers, > > Ben. > My feeling on this subject is that firewalls are nothing more than a security blanket that provide a false sense of security. The appropriate place for managed access controls is at the end points; not somewhere in the middle of the cloud. Firewalls do not prevent someone from running the application of their choice. It only makes it a little more difficult. Once there is one open window any and all applications will get through. Jeffrey Altman * Sr.Software Designer C-Kermit 7.1 Alpha available The Kermit Project @ Columbia University includes Secure Telnet and FTP http://www.kermit-project.org/ using Kerberos, SRP, and kermit-support@kermit-project.org OpenSSL. SSH soon to follow. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 16 12:14:10 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24811 for ; Sat, 16 Jun 2001 12:14:09 -0400 (EDT) Message-ID: Date: Sat, 16 Jun 2001 17:14:33 +0100 From: Ben Laurie X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: JXTA and TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B2B85E9.E5FD4D4A@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Jeffrey Altman wrote: > > > Bill Yeager wrote: > > > Firewalls are a pain though if you cannot use SOCKS. In this case, HTTP is the > > > only alternative I personally know about for traversal. > > > > NAT? But I have to say I am not keen on the whole concept that firewalls > > are things you should find ways to avoid. They are there for a purpose, > > you know! The right answer is to make sure it is possible to run > > appropriate stuff on a firewall to give appropriate access, if the > > appropriate people think its a good idea, surely? > > > > Cheers, > > > > Ben. > > > > My feeling on this subject is that firewalls are nothing more than a > security blanket that provide a false sense of security. The > appropriate place for managed access controls is at the end points; > not somewhere in the middle of the cloud. Firewalls do not prevent > someone from running the application of their choice. It only makes > it a little more difficult. Once there is one open window any and > all applications will get through. Generally speaking, I agree. Most firewalls are a poor substitute for correctly setting up your machines, and where they aren't they're redundant. However there is a class of firewall that is definitely not redundant, namely non-routing hosts that allow internal machines to connect outwards (via SOCKS or NAT, preferably the latter, IMO) but do not allow the reverse. There are sometimes a few things you'd like to come inwards over such firewalls, mail being an example, SSH being another and maybe JXTA is yet another. These are normally handled by appropriate _application-level_ gateways. And that's what I'm talking about. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 19 19:15:10 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07387 for ; Tue, 19 Jun 2001 19:15:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 19 Jun 2001 16:15:02 -0700 To: "IETF Transport Layer Security WG" From: Paul Hoffman / IMC Subject: [ietf-tls] Fwd: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard Content-Type: text/plain; charset="us-ascii" ; format="flowed" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net >To: IETF-Announce: ; >From: The IESG >SUBJECT: Last Call: SMTP Service Extension for Secure SMTP over TLS to > Proposed Standard >Reply-to: iesg@ietf.org >Date: Tue, 19 Jun 2001 16:35:16 -0400 >Sender: scoya@cnri.reston.va.us > > >The IESG has received a request to consider SMTP Service Extension for >Secure SMTP over TLS as a Proposed >Standard. This has been reviewed in the IETF but is not the product of >an IETF Working Group. > >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 July 19, 2001. > >Files can be obtained via >http://www.ietf.org/internet-drafts/draft-hoffman-rfc2487bis-05.txt --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 20 06:17:10 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01469 for ; Wed, 20 Jun 2001 06:17:09 -0400 (EDT) Date: Wed, 20 Jun 2001 11:17:29 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Cc: Paul Hoffman / IMC Subject: [ietf-tls] Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from phoffman@imc.org on Tue, Jun 19, 2001 at 04:15:02PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010620111729.B2954@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Paul, I wonder if the part about backwards compatible client hello messages would benefit from clarification. Perhaps I'm missing something but I'm not quite sure what you mean -- a server is required to understand a backwards compatible client hello but is not required to offer it? I don't understand what the distinction is here, or what is meant by a server "offering" a client hello. -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 20 09:34:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06833 for ; Wed, 20 Jun 2001 09:34:13 -0400 (EDT) Date: Wed, 20 Jun 2001 14:59:29 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Last Call: SMTP Service Extension for Secure SMTP over TLS to Proposed Standard Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from Pete.Chown@skygate.co.uk on Wed, Jun 20, 2001 at 11:17:29AM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010620145929.D19322@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Wed, Jun 20, 2001 at 11:17:29AM +0100, Pete Chown wrote: > I wonder if the part about backwards compatible client hello messages > would benefit from clarification. Perhaps I'm missing something but > I'm not quite sure what you mean -- a server is required to understand > a backwards compatible client hello but is not required to offer it? > I don't understand what the distinction is here, or what is meant by a > server "offering" a client hello. The wording indeed is a little confusing: Servers MUST be able to understand backwards compatible SSL Client Hello messages (provided that client_version is TLS 1.0 or later), and clients MAY use backwards compatible Client Hellos messages. Neither clients or servers are required to actually offer Client Hello messages for anything other than TLS 1.0. Servers never "offer" Client Hello messages, so this probably should be phrased differently. The intention is as follows: We do not want to stand in the way of clients who want to tolerate SSL-only servers. Such servers violate the STARTTLS specification, but interoperability is still a good idea. So clients are allowed to use a Client Hello format suitable for connecting to such servers. However, the client is required to offer TLS 1.0 in this Client Hello message; client trying to negotiate SSL 2.0 or SSL 3.0 are not allowed by the specification. (Note the difference between the format of the Client Hello message and the client_version value given in this message: Clients can request TLS 1.0 in SSL 2.0 or SSL 3.0 compatible format, and they will be able to request TLS 1.1 in SSL 2.0, SSL 3.0, or TLS 1.0 format.) For interoperability with such backwards-compatible clients, we require servers to understand Client Hello messages using a backwards-compatible format. But the server is only required to be able to handle this if the client supports TLS 1.0. If the client tries to negotiate a protocol earlier than TLS 1.0, this is out of the scope of the specification. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 22 15:40:44 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06821 for ; Fri, 22 Jun 2001 15:40:41 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] TLS: AES draft and OAEP Date: Fri, 22 Jun 2001 15:38:22 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106221938.f5MJcMY02749@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net From the discussion of OAEP for the AES ciphersuites, I draw the following conclusions: 1. RSA with OAEP is a cryptographically better mechanism for use in TLS 2. It would be good if TLS and other protocols in the Security Area could share more cryptographic foundations 3. Since we expect AES to be important, this is a good (and rare) opportunity to use RSA with OAEP in TLS but 4. Implementers object because there is more work to be done 5. It's a big deal for hardware accelerators because they're harder to change than software On balance, it seems to me that it's a change worth making, then. Unless I missed a crucial argument, I'm asking Pete Chown to modify the draft accordingly. There will be another WG last call on the draft to review the new language. Thanks to everyone for an engaging discussion, Win Treese Chair, TLS working group treese@acm.org --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 22 17:29:04 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11944 for ; Fri, 22 Jun 2001 17:29:02 -0400 (EDT) Message-ID: Date: Fri, 22 Jun 2001 14:29:32 -0700 From: nelsonb@netscape.com (Nelson Bolyard) Organization: Netscape Communications Corp. X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en-US,en-GB,en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: TLS: AES draft and OAEP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B33B8BC.89B168FB@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Win Treese wrote: > > >From the discussion of OAEP for the AES ciphersuites, I draw the > following conclusions: > > 1. RSA with OAEP is a cryptographically better mechanism for use in TLS > 2. It would be good if TLS and other protocols in the Security Area > could share more cryptographic foundations > 3. Since we expect AES to be important, this is a good (and rare) > opportunity to use RSA with OAEP in TLS > > but > > 4. Implementers object because there is more work to be done > 5. It's a big deal for hardware accelerators because they're harder to > change than software Yes, it means sites that depend on existing accelerators won't be able to deploy suites that use OAEP any time soon. > On balance, it seems to me that it's a change worth making, then. > Unless I missed a crucial argument, I'm asking Pete Chown to modify > the draft accordingly. So, are you asking that all AES suites require OAEP? Or, are you asking for two sets of suites, one with OAEP and one without? or ?? > There will be another WG last call on the draft to review the new > language. -- Nelson Bolyard Sun / Netscape Alliance Disclaimer: I speak for myself, not for Netscape --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 22 17:43:45 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12424 for ; Fri, 22 Jun 2001 17:43:44 -0400 (EDT) Message-ID: Date: Fri, 22 Jun 2001 21:12:33 +0100 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: TLS: AES draft and OAEP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B33A6B1.D6B28F1A@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Win Treese wrote: > From the discussion of OAEP for the AES ciphersuites, I draw the > following conclusions: > > 1. RSA with OAEP is a cryptographically better mechanism for use in TLS I have explained several times why RSA with OAEP provides no security benefit over PKCS #1 v1.5 with the RFC 2246 fix. It can be proven that the fixed PKCS #1 v1.5, as used in TLS, is secure against chosen ciphertext attack in the random oracle model, in fact with a tighter reduction than the one in the corrected OAEP proof. If the WG wants to support OAEP purely for buzzword-compliance, there's not much I can do about that, but it won't help security. - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOzOmbTkCAxeYt5gVAQGO8Qf9Ghadoo1DbPMFQ1jyeSuiZRjGWfnyXT/r UhWO1+xF/kQyewU5tFqz0QJtVor1eCwhP0gSMk2EdovjOnLSlFVxKJW36hRRGVJ+ idYSYr2L8bly/qwzNG9juIjjw+F8+KWas6P5hOgZPv7Hz7IYukhCHwSnJzW1pUBt bL01s3G2w4slHKxQneYv4sgHv3iH54dHLpnsxUtpO7/QnDWOEMm8MYxkS7HnZvYs CZrCk8dvuv9uSlWG6zq/1WCxP29yjCNCOF9HbUcdJT3a4iQhcl7mTt45kd4trckP B7SUFkTERykf8YTBjtuGR+D+eK56WMPosok73A7e2aYc+BBqRxTEzA== =CzDa -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Sat Jun 23 11:37:47 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12227 for ; Sat, 23 Jun 2001 11:37:47 -0400 (EDT) Date: Sat, 23 Jun 2001 16:38:16 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: TLS: AES draft and OAEP Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from nelsonb@netscape.com on Fri, Jun 22, 2001 at 02:29:32PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010623163816.A31187@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Nelson Bolyard wrote: > So, are you asking that all AES suites require OAEP? > Or, are you asking for two sets of suites, one with OAEP and one without? > or ?? I believe the suggestion is that all AES suites will require OAEP. What is your/Netscape's view of that? -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 05:17:28 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09341 for ; Mon, 25 Jun 2001 05:17:27 -0400 (EDT) Date: Mon, 25 Jun 2001 11:18:22 +0200 (W. Europe Daylight Time) From: Magnus Nystrom Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re draft-ietf-tls-extensions-00.txt Message-ID: X-X-Sender: magnus@karon.dynas.se MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Dear All, The above mentioned document (now available from the IETF TLS WG home page) is the second incarnation of the "Wireless extensions to TLS" I-D. The name has been changed since the document now is more general to its nature. Specifically, changes and additions that has been made (in addition to several clarifications) includes: - Added support for the dns_name extension as proposed by Jan Mikkelsen et al. on the mailing list. - Maximum record size negotiation ... removed smallest size, clarifications. - Certificate URLs ... added cert hash to stop certain replacement attacks. - Trusted CA keys ... added possibility to identify issuers with cert hash. - Truncated MACs ... restricted to only HMAC, and only 80 bits - New error messages ... clarified and removed a couple of the ones in the previous draft. - Short session ids ... removed, based on feedback on the mailing list. - OCSP responses ... added support for identification of issuer, and requested extensions, in line with RFC 2560 - Significantly expanded Security Considerations section. Enjoy, -- Magnus Magnus Nystrom RSA Security --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 07:10:52 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10450 for ; Mon, 25 Jun 2001 07:10:51 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com From: Internet-Drafts@ietf.org Reply-to: "IETF Transport Layer Security WG" Subject: [ietf-tls] I-D ACTION:draft-ietf-tls-extensions-00.txt Date: Mon, 25 Jun 2001 07:10:40 -0400 Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <200106251110.HAA10401@ietf.org> X-List-Host: SKYLIST.net --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : TLS Extensions Author(s) : S. Blake-Wilson et al. Filename : draft-ietf-tls-extensions-00.txt Pages : 21 Date : 22-Jun-01 This document describes extensions that may be used to add functionality to TLS. It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-extensions-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-extensions-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-extensions-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010622075908.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-extensions-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-extensions-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010622075908.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" Content-description: footer --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --NextPart-- From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 09:01:02 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14122 for ; Mon, 25 Jun 2001 09:01:02 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com Message-ID: Date: Mon, 25 Jun 2001 14:01:25 +0100 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1.1-STABLE-20001015 i386) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re draft-ietf-tls-extensions-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <3B373625.8B477F7@algroup.co.uk> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Magnus Nystrom wrote: > > Dear All, > > The above mentioned document (now available from the IETF TLS WG home > page) is the second incarnation of the "Wireless extensions to TLS" > I-D. The name has been changed since the document now is > more general to its nature. Specifically, changes and additions that > has been made (in addition to several clarifications) includes: > > - Added support for the dns_name extension as proposed by Jan > Mikkelsen et al. on the mailing list. Why is this a wireless extension? Cheers, Ben. -- http://www.apache-ssl.org/ben.html In Boston 'til 1st July. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 09:05:09 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14247 for ; Mon, 25 Jun 2001 09:05:08 -0400 (EDT) Date: Mon, 25 Jun 2001 15:05:40 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Re draft-ietf-tls-extensions-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from ben@algroup.co.uk on Mon, Jun 25, 2001 at 02:01:25PM +0100 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010625150540.B7505@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Mon, Jun 25, 2001 at 02:01:25PM +0100, Ben Laurie wrote: > Magnus Nystrom wrote: >> The above mentioned document (now available from the IETF TLS WG home >> page) is the second incarnation of the "Wireless extensions to TLS" >> I-D. The name has been changed since the document now is >> more general to its nature. Specifically, changes and additions that >> has been made (in addition to several clarifications) includes: >> >> - Added support for the dns_name extension as proposed by Jan >> Mikkelsen et al. on the mailing list. > Why is this a wireless extension? It is not. Note that this draft is called draft-ietf-tls-extensions-00.txt (its predecessor was draft-ietf-tls-wireless-00.txt). -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 09:37:24 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15159 for ; Mon, 25 Jun 2001 09:37:23 -0400 (EDT) Date: Mon, 25 Jun 2001 15:37:55 +0200 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2i In-Reply-To: ; from Internet-Drafts@ietf.org on Mon, Jun 25, 2001 at 07:10:40AM -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010625153755.A7606@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit > TLS Extensions > > > 4. Error Alerts > - "certificate_unobtainable" - this alert is sent by servers who are > unable to retrieve a certificate chain from the URL supplied by > the client (see Section 3.3). This message is always fatal. Why is it always fatal? In practice, client certificates are often optional: If the client can identify itself, then it may be granted additional rights, but if it can't, it may still make sense to continue the connection (sometimes just for sending an HTTP error message, sometimes for more). -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 11:54:07 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19199 for ; Mon, 25 Jun 2001 11:54:06 -0400 (EDT) Message-ID: From: "David Taylor" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Next version of SRP draft using extensions Date: Mon, 25 Jun 2001 23:22:47 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <003d01c0fd79$ed885960$d3aa093d@pib> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hi all, I am working on the next version of the SRP authentication draft, and have changed it to use extended client and server hello messages, as per the extensions draft. The extensions draft says anyone proposing new extensions should post the proposal to the list for review, so here is the scheme I have come up with for SRP authentication. The SRP draft adds a new extension type - srp(6) - to the ExtensionType enumerated. This extension is used in both the client and server hello messages, if SRP authentication is used. The data structure sent in the extension is defined as: enum { client, server } ClientOrServerExtension; enum { sha-1(0), (255) } PasswordMessageDigest; struct { select(ClientOrServerExtension) { case client: opaque srp_U<1..2^8-1>; case server: PasswordMessageDigest srp_md; opaque srp_s<1..2^8-1> opaque srp_N<1..2^16-1>; opaque srp_g<1..2^16-1>; } } SRPExtension; and is used in the following handshake sequence: Client Server | | Client Hello (U) ------------------------> | | <---------------------------- Server Hello (md, g, N, s) Client Key Exchange (A) -----------------> | | <---------------------------- Server Key Exchange (B) | <---------------------------- Server Hello Done change cipher spec | Finished --------------------------------> | | change cipher spec | <---------------------------- Finished | | Other things I have specified are: The short handshake mechanism for re-using sessions for new connections, and renegotiating keys for existing connections will still work with the SRP authentication mechanism and handshake. When a client attemps to re-use a session, it must still include the SRP extension carrying the user name (U) in the client hello message, in case the server cannot or will not allow re-use of the session, meaning a full handshake sequence is required. If a client requests an existing session and the server agrees to use it (meaning the short handshake will be used), the server may omit the SRP extension from the server hello message. When encoding the numbers g, N, A, and B as opaque types, if the most significant bit is set, an extra byte of value 0x00 (all bits cleared) should be added as the most significant byte. This is done both to reduce the ambiguity of the encoding of the numbers, and as a safeguard against implementations that do not assume these numbers are positive. The passwordMessageDigest enumerated is included for future expansion. At the time of writing, SHA-1 is the only message disgest defined for use by [RFC 2945]. Thanks for your comments, David Taylor. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Mon Jun 25 23:43:13 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06388 for ; Mon, 25 Jun 2001 23:43:13 -0400 (EDT) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Mon, 25 Jun 2001 23:43:34 -0400 Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <85256A77.001464D6.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Can we adapt the language from the "client cert" section in TLS: "If client authentication is required by the server for the handshake to continue, it may respond with a fatal handshake failure alert." Something like: "If client authentication is required by the server for the handshake to continue and the server is unable to retrieve the cert chain, it should send a fatal "certificate unobtainable" alert." ? Best regards. Simon David Hopwood on 06/25/2001 10:32:39 AM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt -----BEGIN PGP SIGNED MESSAGE----- Bodo Moeller wrote: > > 4. Error Alerts > > > - "certificate_unobtainable" - this alert is sent by servers who are > > unable to retrieve a certificate chain from the URL supplied by > > the client (see Section 3.3). This message is always fatal. > > Why is it always fatal? In practice, client certificates are often > optional: If the client can identify itself, then it may be granted > additional rights, but if it can't, it may still make sense to > continue the connection (sometimes just for sending an HTTP error > message, sometimes for more). That's a reasonable point. Any objection to deleting "This message is always fatal." here? - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOzdLXTkCAxeYt5gVAQFmswgAqS2K3si0VtP5M1zj982uS3AZYDb9EDW8 tYE/fYJoGe6TbpLrTUE2xHjpAcJEofRBMTSJ+hKlzoYM83wXlCNLcnZby9+l+UqY Me1KL6jH1k6SD0iei9lfQgjW82IQn0yswrdGSrL+r8ftFCor+Y9ZQK/f29TBMOjx 1Y3UEXWmPH875ulyEvU+YRgy6fG3A+K8kDGYtGR8gO0KtvOVxxoo6pq+2bos7HyQ zu0+/S79s5ZmHDVyQPv0LoV2vk16GX/w76XfPIcTm0a+h/qVwroW5VLhjBX57ir9 y55mozk+O1cmKknnXbXUQrPLD3r7FzFQNA9LstHLFNFHMd+waDtRNA== =d3gj -----END PGP SIGNATURE----- --- You are currently subscribed to ietf-tls as: sblakewilson@certicom.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 26 00:13:01 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06963 for ; Tue, 26 Jun 2001 00:13:00 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 25 Jun 2001 21:19:44 -0700 In-Reply-To: "Simon Blake-Wilson"'s message of "Mon, 25 Jun 2001 23:43:34 -0400" Message-ID: Lines: 15 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net "Simon Blake-Wilson" writes: > Can we adapt the language from the "client cert" section in TLS: > > "If client authentication is required by the server for the handshake to > continue, it may respond with a fatal handshake failure alert." > > Something like: > > "If client authentication is required by the server for the handshake to > continue and the server is unable to retrieve the cert chain, it should send a > fatal "certificate unobtainable" alert." By analogy the RFC 2246, this should say "may" instead of "should". -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 26 10:24:22 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11200 for ; Tue, 26 Jun 2001 10:24:21 -0400 (EDT) Message-ID: Sender: bounce-ietf-tls-3458737@lists.certicom.com Date: Tue, 26 Jun 2001 10:21:09 -0400 From: "David P. Kemp" X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106261423.KAA16210@stingray.missi.ncsc.mil> X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > "Simon Blake-Wilson" writes: > > > Can we adapt the language from the "client cert" section in TLS: > > > > "If client authentication is required by the server for the handshake to > > continue, it may respond with a fatal handshake failure alert." > > > > Something like: > > > > "If client authentication is required by the server for the handshake to > > continue and the server is unable to retrieve the cert chain, it should send a > > fatal "certificate unobtainable" alert." > > By analogy the RFC 2246, this should say "may" instead of "should". Is this a bug in 2246? The premise is that client authentication is required by the server, ergo if the client can not be authenticated the connection WILL be aborted. The question is then, given that the connection will be aborted for lack of authentication, the server {may | should} be polite and send an alert before tearing down the TCP connection. "Should" seems appropriate here. If the TCP connection is persistent, there could be long hangs if the server aborts a handshake without sending some (not necessarily informative) fatal alert. --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Tue Jun 26 10:43:24 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14675 for ; Tue, 26 Jun 2001 10:43:23 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 26 Jun 2001 07:50:09 -0700 In-Reply-To: "David P. Kemp"'s message of "Tue, 26 Jun 2001 10:21:09 -0400" Message-ID: Lines: 45 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net "David P. Kemp" writes: > Eric Rescorla wrote: > > > > "Simon Blake-Wilson" writes: > > > > > Can we adapt the language from the "client cert" section in TLS: > > > > > > "If client authentication is required by the server for the handshake to > > > continue, it may respond with a fatal handshake failure alert." > > > > > > Something like: > > > > > > "If client authentication is required by the server for the handshake to > > > continue and the server is unable to retrieve the cert chain, it should send a > > > fatal "certificate unobtainable" alert." > > > > By analogy the RFC 2246, this should say "may" instead of "should". > > Is this a bug in 2246? The premise is that client authentication is required > by the server, ergo if the client can not be authenticated the connection WILL > be aborted. The question is then, given that the connection will be aborted > for lack of authentication, the server {may | should} be polite and send an > alert before tearing down the TCP connection. I think this probably is a bug but I don't think just doing "may" -> "should" is the right thing here. There seem to me to be four things the server might do: [BAD] Drop the connection [GOOD] Throw a fatal handshake alert [BAD] Throw some other alert. [GOOD] Continue and have the application throw an error. I agree that the "required for the handshake to continue" rules out the last case but I think that if we're going to change 2246 we should lay that case out as well. > "Should" seems appropriate here. If the TCP connection is persistent, there > could be long hangs if the server aborts a handshake without sending some > (not necessarily informative) fatal alert. I don't see how this would be the case. The server would presumably send a TCP FIN. This would cause an error on the client. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 27 05:38:38 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02907 for ; Wed, 27 Jun 2001 05:38:37 -0400 (EDT) From: "Rene G. Eberhard" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Date: Wed, 27 Jun 2001 11:01:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA02907 Hi The problem is that the application is also involved in the correctness of the handshake. This might be a potential security hole. More comments below. > I'd like to revisit the case > > Continue and have the application throw an error. > > I have a server application layered over TLS. The server supports > SASL/EXTERNAL but also simple password and anonymous > authentication methods. > > The server cannot know which method is going to be used until the TLS > handshaking is over. It has to request a client certificate in case > SASL/EXTERNAL is proposed. In the case of the other two methods, > the client > needn't send a certificate. I would argue that the server may continue the > handshake if the client does not return a certificate in response to the > certificate request. If SASL/EXTERNAL is proposed and the client > didn't send > a certificate, the server may return an application error. I don't agree. (See next chapter). If you have multiple client authentication methods it's not enough to just throw an error to the application. It's also necessary to tell the application what kind of client authentication occurred. IMHO it's always up to the server to "request for a specific client authentication" instead of "request for any client authentication and act accordingly". In one of our our own product "TESS" (www.tess.ch) we moved the whole security decision stuff up to the application. We now are able to ask for a client certificate on application level (within an existing TLS session) and not just at the very beginning of the TLS session. Because we are on application level we can also ask for any other authentication schemes (e.g. password based authentication). These "other authentication schemes" are not part of TLS (because they are application specific). Regards Rene --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 27 06:38:04 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09780 for ; Wed, 27 Jun 2001 06:38:03 -0400 (EDT) Message-ID: From: "Ramsay, Ron" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Date: Wed, 27 Jun 2001 14:01:31 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I'd like to revisit the case Continue and have the application throw an error. I have a server application layered over TLS. The server supports SASL/EXTERNAL but also simple password and anonymous authentication methods. The server cannot know which method is going to be used until the TLS handshaking is over. It has to request a client certificate in case SASL/EXTERNAL is proposed. In the case of the other two methods, the client needn't send a certificate. I would argue that the server may continue the handshake if the client does not return a certificate in response to the certificate request. If SASL/EXTERNAL is proposed and the client didn't send a certificate, the server may return an application error. Ron. -----Original Message----- From: Eric Rescorla [mailto:ekr@speedy.rtfm.com] Sent: Wednesday, 27 June 2001 0:50 To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt "David P. Kemp" writes: > Eric Rescorla wrote: > > > > "Simon Blake-Wilson" writes: > > > > > Can we adapt the language from the "client cert" section in TLS: > > > > > > "If client authentication is required by the server for the handshake to > > > continue, it may respond with a fatal handshake failure alert." > > > > > > Something like: > > > > > > "If client authentication is required by the server for the handshake to > > > continue and the server is unable to retrieve the cert chain, it should send a > > > fatal "certificate unobtainable" alert." > > > > By analogy the RFC 2246, this should say "may" instead of "should". > > Is this a bug in 2246? The premise is that client authentication is required > by the server, ergo if the client can not be authenticated the connection WILL > be aborted. The question is then, given that the connection will be aborted > for lack of authentication, the server {may | should} be polite and send an > alert before tearing down the TCP connection. I think this probably is a bug but I don't think just doing "may" -> "should" is the right thing here. There seem to me to be four things the server might do: [BAD] Drop the connection [GOOD] Throw a fatal handshake alert [BAD] Throw some other alert. [GOOD] Continue and have the application throw an error. I agree that the "required for the handshake to continue" rules out the last case but I think that if we're going to change 2246 we should lay that case out as well. > "Should" seems appropriate here. If the TCP connection is persistent, there > could be long hangs if the server aborts a handshake without sending some > (not necessarily informative) fatal alert. I don't see how this would be the case. The server would presumably send a TCP FIN. This would cause an error on the client. -Ekr --- You are currently subscribed to ietf-tls as: RON.RAMSAY@cai.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Wed Jun 27 21:27:21 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00030 for ; Wed, 27 Jun 2001 21:27:21 -0400 (EDT) Message-ID: From: "Ramsay, Ron" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Date: Thu, 28 Jun 2001 11:27:57 +1000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thanks, Rene. I'd just like to make one point. Our application does not interfere with the TLS handshake. In fact, we do not interact with the TLS layer at all. However, we also do not accept any authentication. We setup the server to request a client certificate but not to require it. The client connects and handshaking completes. If the client requests SASL/EXTERNAL, we ask the TLS layer whether a certificate was supplied (and validated). (I said we don't interact with the TLS layer, so let's call this monitoring!) If one was, that becomes the basis of the authentication. If not, the connection is rejected. Conversely, if the client supplies a certificate and the requested authentication is anonymous, there is no interaction with the TLS layer and the connection is accepted I can't see a security problem because we are not trying to adjust to the information supplied by the client. We simply verify that the client has supplied the information required by the authentication method they've requested. This is OK, yes? Ron. -----Original Message----- From: Rene G. Eberhard [mailto:eberhard@keyon.ch] Sent: Wednesday, 27 June 2001 19:02 To: IETF Transport Layer Security WG Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-extensions-00.txt Hi The problem is that the application is also involved in the correctness of the handshake. This might be a potential security hole. More comments below. > I'd like to revisit the case > > Continue and have the application throw an error. > > I have a server application layered over TLS. The server supports > SASL/EXTERNAL but also simple password and anonymous > authentication methods. > > The server cannot know which method is going to be used until the TLS > handshaking is over. It has to request a client certificate in case > SASL/EXTERNAL is proposed. In the case of the other two methods, > the client > needn't send a certificate. I would argue that the server may continue the > handshake if the client does not return a certificate in response to the > certificate request. If SASL/EXTERNAL is proposed and the client > didn't send > a certificate, the server may return an application error. I don't agree. (See next chapter). If you have multiple client authentication methods it's not enough to just throw an error to the application. It's also necessary to tell the application what kind of client authentication occurred. IMHO it's always up to the server to "request for a specific client authentication" instead of "request for any client authentication and act accordingly". In one of our our own product "TESS" (www.tess.ch) we moved the whole security decision stuff up to the application. We now are able to ask for a client certificate on application level (within an existing TLS session) and not just at the very beginning of the TLS session. Because we are on application level we can also ask for any other authentication schemes (e.g. password based authentication). These "other authentication schemes" are not part of TLS (because they are application specific). Regards Rene --- You are currently subscribed to ietf-tls as: RON.RAMSAY@cai.com To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 28 16:34:25 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA28764 for ; Thu, 28 Jun 2001 16:34:24 -0400 (EDT) Date: Thu, 28 Jun 2001 13:34:57 -0700 From: Mark Nottingham To: "IETF Transport Layer Security WG" Subject: [ietf-tls] London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: bounce-ietf-tls-3458737@lists.certicom.com List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010628133452.C17332@akamai.com> X-List-Host: SKYLIST.net Does TLS intend to meet in London? The extensions draft is interesting, however I'd like to see it (or at least the dns_name stuff) codified into TLS 1.1. Rationale: a version rev is more visible, and more likely to get wide adoption in clients, which is needed to make dns_name worthwhile. -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA) --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Thu Jun 28 23:25:51 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01537 for ; Thu, 28 Jun 2001 23:25:49 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ietf-tls] RE: London Date: Thu, 28 Jun 2001 20:27:07 -0700 Message-ID: Thread-Topic: [ietf-tls] London Thread-Index: AcEAEe6iVubEQQ5ERzGzsowFgdyFeAAOPBuw From: "Joseph Hui" To: "IETF Transport Layer Security WG" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA01537 > Does TLS intend to meet in London? > > The extensions draft is interesting, however I'd like to see it (or > at least the dns_name stuff) codified into TLS 1.1. This may mark the beginning of the third round of the to-increment-or-not-to-increment-rev# debate. The previous two ended in tacit intransigence. So getting together and putting our feet down in London may hopefully make a difference for the better, like: reaching a conclusion. I too would like to see the dns_name extension codified in TLS 1.1, with the understanding that it also applies as an immediate remedy for 1.0, in hope to expedite its roll-out and adoption. (Currently there's no committed timeline for 1.1. Heck, there's none for 1.0 patches (ala extensions) either. But I'm betting 1.0 patches will most likely be faster out the gate than the iffy 1.1 may.) Justification: With all due respect to the TLS/1.0 contributors, I see the lack of virtual hosting support in 1.0 as an oversight. So the dns_name extension is practically a "bug fix" that needs to go into current web clients and servers ASAP. > Rationale: a version rev is more visible, and more likely to get wide > adoption in clients, which is needed to make dns_name worthwhile. > > -- > Mark Nottingham, Research Scientist > Akamai Technologies (San Mateo, CA USA) Joe Hui, Research Engineer Digital Island --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 29 01:07:01 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12266 for ; Fri, 29 Jun 2001 01:07:00 -0400 (EDT) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Reply-to: "IETF Transport Layer Security WG" Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Eric Rescorla Date: 28 Jun 2001 22:14:11 -0700 In-Reply-To: Mark Nottingham's message of "Thu, 28 Jun 2001 13:34:57 -0700" Message-ID: Lines: 21 X-Mailer: Gnus v5.6.45/XEmacs 20.4 - "Emerald" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: X-List-Host: SKYLIST.net Mark Nottingham writes: > Does TLS intend to meet in London? > > The extensions draft is interesting, however I'd like to see it (or > at least the dns_name stuff) codified into TLS 1.1. > > Rationale: a version rev is more visible, and more likely to get wide > adoption in clients, which is needed to make dns_name worthwhile. I don't find this rationale particularly convincing. In my experience, implementors feel almost no pressure to upgrade their implementations to newer versions. Look how long it took Microsoft and Netscape to upgrade from SSLv3 to TLS. If there's a lot of market demand for dns_name then implementors will put it in whether it's a new version or not. If there's no demand then incrementing the version number will make almost no difference. -Ekr --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 29 06:05:22 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA15898 for ; Fri, 29 Jun 2001 06:05:21 -0400 (EDT) Date: Fri, 29 Jun 2001 11:05:53 +0100 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: London Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from mnot@akamai.com on Thu, Jun 28, 2001 at 01:34:57PM -0700 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20010629110553.F11652@hyena.skygate.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Mark Nottingham wrote: > Does TLS intend to meet in London? I will be there, so you can meet me at least! :-) I would certainly like a meeting -- there is plenty to talk about even if AES gets finalised before then. Also it would be nice to put faces to email addresses... -- Pete --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com From bounce-ietf-tls-3458737@lists.certicom.com Fri Jun 29 09:11:38 2001 Received: from 0.0.0.0 (lists.skylist.net [38.153.106.9]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21991 for ; Fri, 29 Jun 2001 09:11:37 -0400 (EDT) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] Re: London In-reply-to: Message from Pete Chown of 29 Jun 2001 11:05:53 BST Date: Fri, 29 Jun 2001 09:09:32 -0400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200106291309.f5TD9WL05481@cirocco.treese.org> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net I have requested a meeting slot for the TLS working group at the London meeting. Win Treese --- You are currently subscribed to ietf-tls as: tls-archive@lists.ietf.org To unsubscribe send a blank email to leave-ietf-tls-3458737E@lists.certicom.com