From bounce-ietf-tls-3458737@lists.certicom.com Fri Dec 1 04:07:17 2000 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 EAA06013 for ; Fri, 1 Dec 2000 04:07:15 -0500 (EST) Message-ID: From: "Hidenori Ohta" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: MISTY1 and CAMELLIA Ciphersuites Date: Fri, 1 Dec 2000 18:05:11 +0900 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.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <00a401c05b75$cfa25f00$32054a0a@crimefighter> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > What is the general opinion about the proposed MISTY1 and CAMELLIA > ciphersuites? I'd like to explain about MISTY1. 1. Intellectual Property Right There is the royalty-free license of MISTY1, but it does not fit with RFC2026. Mitsubishi Electric Corporation decides that it should be modified. The license, which follows RFC2026, that is to say non-encumbered, will be appeared by the end of this year. 2. Cryptanalytic Consideration MISTY1 is the first algorithm concering about both differential and linear cryptanalysis. It was designed on the basis of the theory of "provable security". It was also carefully designed to withstand various cryptanalytic attacks that were known at the time of designing. It was published in 1996. Since the publication of MISTY1, many research efforts have been done for evaluating its security level; for example, higher order differential cryptanalysis, slide attack, impossible differential cryptanalysis, Luby-Rack off style evaluation, and so on. However, no security flaws of MISTY1 have been found. MISTY1 is now widely used in many commercial and governmental application. Additionally, the 3rd generation partnership project (3GPP) adopted a variant of MISTY1, which is called KASUMI, as a mandatory algorithm in the confidentiality and integrity mechanisms of the forthcoming W-CDMA systems. Regards -- Hidenori Ohta --- 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 Dec 1 04:07:39 2000 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 EAA06213 for ; Fri, 1 Dec 2000 04:07:38 -0500 (EST) Message-ID: From: "Hidenori Ohta" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: MISTY1 and CAMELLIA (Re: New AES ciphersuites draft ) Date: Fri, 1 Dec 2000 18:04:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <00a301c05b75$be056620$32054a0a@crimefighter> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > I have thought that Camellia was builded on E2 and MISTY technology. Yes, it's right. But following figure is not correct. > DES New sbox design technique > Liner attack for chip/hardware > study > ---------->MISTY -----------------------------> Kasumi > | sbox design and > | simple key schedule > V > (FEAL ------->) E2 ---------------------------> Camellia > > Feistel AES style key/block length, > structure network and pre/post-whiting > study structure technique KASUMI is one of the variant of MISTY1. They are based on the almost same technology, and have same security level. So it may be modified as follows: +MISTY tech.---------+ | | | MISTY1 ---> KASUMI | | | +--------------------+ | | V E2 -----> Camellia > If I use/implement Camellia, I never use/implement MISTY1. Although E2 and MISTY1 are the bases of Camellia, these 3 algorithms are diffrent. MISTY1 was not obsolated by KASUMI or Camellia. Regards -- Hidenori Ohta --- 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 Dec 1 04:41:03 2000 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 EAA24089 for ; Fri, 1 Dec 2000 04:41:02 -0500 (EST) Message-ID: From: "Hidenori Ohta" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: MISTY1 and CAMELLIA Ciphersuites Date: Fri, 1 Dec 2000 18:04:12 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <009e01c05b75$ac700e60$32054a0a@crimefighter> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Hironobu-san. > MISTY1 free license is permitted for academic (non-profit) use. But it > have been uncleared what academic (non-profit) is. And There is no > obvious definition of "academic", "non-profit" and "commercial". > MISTY1 situation made me very confused. I've thought that MISTY1 was > the best choice in 1998 but legal issues was the worst. Your understanding does not reflect the current situation. Royalty- free license of MISTY1 can be provided since the end of 1998. MISTY1 can be used for both academic and commercial without paying the royalty of the patent. In fact, free license of academic is not a license. Any patented technology can be used if the patent holder does not suffer any damage. Mitsubishi Electric Corporation ragards that this kind of usage has no problem. In the early 1998 (at the time that you implemented MISTY1), the royalty- free license was not provided yet. So, MISTY1 could not be used freely except for academic use. Now, royalty-free license exists. But as some people point out, current royalty-free license does not fit with RFC 2026, so that Mitsubishi Electric Corporation is now reviewing the license. New MISTY1 royalty-free license under reasonable and non-discriminatory terms will be announced by the end of this year. Regards -- Hide. --- 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 Dec 1 04:48:21 2000 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 EAA27934 for ; Fri, 1 Dec 2000 04:48:20 -0500 (EST) From: Message-Id: To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Fri, 1 Dec 2000 09:46:52 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) 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 As I can't be at the SD meeting, I remotely signal support and interest for the I-d, just in case there is a straw poll on this at the meeting. Agree with Andreas that there is a need for new error alerts for the new abort situations that the I-d gives rise to, e.g. client abort if server indicates support of an extension the client did not indicate support of (see section 2.3 of the I-d). I thought there was an issue of a server that didn't support the new extensions not understanding the new alerts, but we can get round this by specifying that if the server indicates support of any extensions in ServerHello it must recognise all the new alerts and if the server does not indicate support of the extensions in ServerHello then the situations requiring the new alerts would not arise in any case. These new alerts would be, with suggested titles: - client must abort if receive extension in ServerHello that they did not put in ClientHello, "unsupported_extension" (section 2.3) - client and server must abort if receive extension list with extensions in the wrong order, "bad_extension_order" (section 2.3) - server abort if receive max record size negotiation request for non-admissible values, "bad_record_size_request" (section 3.1) - client abort if receive max record size negotiation response different from requested (but perhaps this is open if we follow Andreas's suggestion of allowing server to do this. Agree with Magnus that we should not - what's the point of the extension otherwise?), "bad_record_size_response" (section 3.1) - do we need a new condition and alert for the server to indicate that the Cert URL, though of valid format, did not point to a cert, represented a defunct domain, server down etc? I think it would be useful to define such a new alert, "cert_unobtainable", rather than use "unknown_certificate" (section 3.2) - server abort if client makes bad truncated MAC request, "bad_truncated_mac_request", (section 3.5) - client abort if server sends bad truncated MAC response, "bad_truncated_mac_response", (section 3.5) - client abort if server sends bad OCSP response, "bad_ocsp_response" (section 3.6) tim --- 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 Dec 1 09:45:34 2000 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 JAA19259 for ; Fri, 1 Dec 2000 09:45:30 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" References: <027701c05ba4$3aa63870$4c981b81@kant> Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Fri, 1 Dec 2000 15:45:17 +0100 Organization: IAIK 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <028801c05ba5$524fb220$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > > . I think the server should be allowed to respond with a size different > > than that requested by the client. The client can still accept the size > > selected by the server of abort the handshake. > > Why? The client has indicated its maximum size, what would the reason be > for the server to use a smaller size? I was actually thinking of a larger size, e.g. 512 byte instead of 256 byte because the server does not implement the requested size. Although I think this will hardly happen in reality it would be an extra feature that does not complicate the protocol. > > . Some maximum record sizes (e.g. 256 bytes) may be smaller than some > > handshake messages (e.g. certificate message). This is not a problem [...] > This is a good observation, but will it become a problem in practice? I.e. > even if a 256-bit maximum record size has been negotiated, won't the > effect (during a re-negotiation) b just less-than-optimal number of > handshake messages? You are right, I was thinking about our implementation which currently assumes that a handshake message is not split over multiple records. > > . Client certificate URL extension: [...] > Actually, no. The intent is to point to _a_ client certificate. In this > case, the server will have to do the chaining itself. I am not sure this is a good idea. IMHO certificate chains are always better. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- 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 Dec 1 10:38:47 2000 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 KAA21518 for ; Fri, 1 Dec 2000 10:38:45 -0500 (EST) Date: Fri, 1 Dec 2000 15:37:58 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] AES key lengths 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: <20001201153758.A6084@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Okay, on the subject of AES key lengths it seems as though there are several people wanting it and a couple of people opposed (including me). In the circumstances it seems fairest to add the new ciphersuites, because no one is actually forced to implement them. I propose that the new ciphersuites be "MAY". The interoperability requirements will be kept the same and will refer to the 128-bit ciphersuites. The number of ciphersuites will therefore increase by a factor of three, with a 192-bit and a 256-bit variant of each current ciphersuite being added. If anyone has serious objections to this way of proceeding, please let me know. I will also fix the problem where the AES block size is not specified. Another point is that many people on this list have been very helpful with suggestions and analysis. If anyone would like their contribution acknowledged more specifically in the document please let me know. As I said before, please could everyone think carefully whether there are any more outstanding issues. I get the feeling we are almost there; if all the issues can be raised now then the upcoming draft can be the last one. -- 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 Dec 1 11:07:32 2000 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 LAA01306 for ; Fri, 1 Dec 2000 11:07:31 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES key lengths 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 Dec 2000 08:09:54 -0800 In-Reply-To: Pete Chown's message of "Fri, 1 Dec 2000 15:37:58 +0000" Message-ID: Lines: 30 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 Pete Chown writes: > Okay, on the subject of AES key lengths it seems as though there are > several people wanting it and a couple of people opposed (including > me). > > In the circumstances it seems fairest to add the new ciphersuites, > because no one is actually forced to implement them. I propose that > the new ciphersuites be "MAY". The interoperability requirements will > be kept the same and will refer to the 128-bit ciphersuites. > > The number of ciphersuites will therefore increase by a factor of > three, with a 192-bit and a 256-bit variant of each current > ciphersuite being added. > > If anyone has serious objections to this way of proceeding, please let > me know. I really don't think this is necessary. Let's for the moment say that the arguments for why we need 256 are convincing. (I don't think so, but never mind that). I don't see why this means we need all three lengths. At most this motivates for 128 and 256. Sure, it's possible that 192 is more secure than 128 or 256, but if we believe that it suggests that AES is seriously broken and we need a different backup entirely. -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 Dec 1 11:58:01 2000 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 LAA17126 for ; Fri, 1 Dec 2000 11:57:59 -0500 (EST) Message-ID: From: "Khaja E. Ahmed" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Fri, 1 Dec 2000 08:58:25 -0800 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: <005f01c05bb7$eb50fcb0$e4570f18@plstn1.sfba.home.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > > > . Client certificate URL extension: > [...] > > Actually, no. The intent is to point to _a_ client certificate. In this > > case, the server will have to do the chaining itself. > > I am not sure this is a good idea. IMHO certificate chains are always > better. Is it a good idea to rely on the ability of a server to do path discovery and chain building on its own? I was under the impression that in practice this is a not a viable option. I would suspect that is it better for the standard to mandate that the client submit its entire cert chain. This should be a non issue for PC type clients. It might even work reasonably for storage space and bandwidth constrained devices like cell phones with smart cards. Or perhaps to accommodate such devices submission of the entire chain can be the default behavior and submission of just the EE cert can be allowed. That way servers that "know" they have to deal with such devices can do a better job of implementing path discovery and chain building capability. Khaja --- 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 Dec 1 15:26:58 2000 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 PAA13283 for ; Fri, 1 Dec 2000 15:26:56 -0500 (EST) Message-Id: To: "IETF Transport Layer Security WG" From: Win Treese Subject: [ietf-tls] TLS WG agenda for San Diego Date: Fri, 01 Dec 2000 15:30:22 -0500 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <200012012030.eB1KUMh07264@cirocco.openmarket.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Here is the agenda for the TLS working group meeting in San Diego. Because of an unfortunate scheduling problem, we will have a one hour slot on Tuesday, 12 December, from 1415-1515. Times are approximate. 1415 Introduction 1420 Cipher suites (Kerberos, AES, etc.) 1435 WTLS 1445 Discussion of needed changes for Draft Standard Come prepared to propose and discuss. Win Treese TLS WG chair treese@openmarket.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 Dec 1 16:42:23 2000 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 QAA29502 for ; Fri, 1 Dec 2000 16:42:22 -0500 (EST) Message-ID: Date: Fri, 01 Dec 2000 13:42:07 -0800 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: AES key lengths 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: <3A281B2F.77E4099F@netscape.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > Okay, on the subject of AES key lengths it seems as though there are > several people wanting it and a couple of people opposed (including > me). > As I said before, please could everyone think carefully whether there > are any more outstanding issues. I get the feeling we are almost > there; if all the issues can be raised now then the upcoming draft can > be the last one. In a few months, the official Federal Information Processing Standard for AES will come out, and I expect it will have something to say about requirements for use of specific key sizes. Some of our larger customers will then need a TLS that conforms to those requirements. If the TLS/AES spec limits the choice of key size to a value other than what the FIPS ultimately requires, it will almost certainly need to be revised. I think this argues for either (a) allowing a number of choices now, or (b) waiting for the FIPS before finalizing the TLS/AES spec. -- 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 Dec 1 20:07:01 2000 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 UAA21364 for ; Fri, 1 Dec 2000 20:06:56 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-043.dialup.zetnet.co.uk [194.247.41.53] claimed to be zetnet.co.uk Message-ID: Date: Sat, 02 Dec 2000 01:03:55 +0000 From: Kat 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" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A284A7B.D3BFBE41@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Andreas Sterbenz wrote: > > > > . I think the server should be allowed to respond with a size > > > different than that requested by the client. The client can still > > > accept the size selected by the server of abort the handshake. > > > > Why? The client has indicated its maximum size, what would the reason be > > for the server to use a smaller size? > > I was actually thinking of a larger size, e.g. 512 byte instead of 256 byte > because the server does not implement the requested size. Why would that happen? Support for the extension should mean implementing all possible record sizes (2^8..12 and 2^14), IMHO. The only reason I can think of for allowing the server to change the record size is if the server were also memory-limited, to a greater extent than the client. This doesn't happen very often for typical uses of TLS, and in any case using the extension mechanism for that case wouldn't solve anything, because the server wouldn't be able to limit the record size if the client does not suggest the extension. While I remember, are the maximum lengths of TLSCompressed.fragment and TLSCiphertext.fragment still to be record_size+1024 and record_size+2048 respectively? If they are, that makes the smaller record sizes (e.g. 2^8) ineffective, because the client will still have to handle a buffer of 2304 bytes in the worst case. > > > . Some maximum record sizes (e.g. 256 bytes) may be smaller than some > > > handshake messages (e.g. certificate message). This is not a problem > [...] > > This is a good observation, but will it become a problem in practice? I.e. > > even if a 256-[byte] maximum record size has been negotiated, won't the > > effect (during a re-negotiation) be just less-than-optimal number of > > handshake messages? > > You are right, I was thinking about our implementation which currently > assumes that a handshake message is not split over multiple records. Emphasize in the new draft that an implementation MUST handle handshake messages that are split over multiple records (in fact RFC 2246 already implies that it must, in section 6.2.1 by my reading, but obviously some implementors haven't understood that). > > > . Client certificate URL extension: > [...] > > Actually, no. The intent is to point to _a_ client certificate. In this > > case, the server will have to do the chaining itself. > > I am not sure this is a good idea. IMHO certificate chains are always > better. I agree - the contents of the URL should be the same as what would be sent in the client Certificate message, i.e. a certificate chain. - -- 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 iQEVAwUBOihKJjkCAxeYt5gVAQEAKAf+KzvruIyW8uwo2jt/8YP6wZJAnUe5XlYq 1jHtEQNe5iEWAy+VdKm9+sM/d3IupRGqbvevCoKRXUQs3neq+8WpJK8gOar6u80J LZpAzo+nZzByrOIqhuqF+5A2KhBbiocHUr9uJPmgkketdgkOH2SKj8vwukE9/0+4 M+O97NeRg4iWcw+0uOok5TroMvsjiqhLAHtdT7KnQDarUvV4kS8eucqL8jJEqNNE ca8l0Zsg75cw6ftABHSmU3NMKjbGGx7n9BeGzg/+gpUDqMbAgFwbP5A+tHBng5tg OaPPvaJmZI6fyIwpEEngAYJZv8kc7MxprFSWydUsW8u0vGjvvlSr/g== =EHHX -----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 Dec 2 07:07:45 2000 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 HAA10685 for ; Sat, 2 Dec 2000 07:07:44 -0500 (EST) Message-ID: Date: Sat, 02 Dec 2000 12:07:23 +0000 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES key lengths 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: <3A28E5FB.77641605@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > As I said before, please could everyone think carefully whether there > are any more outstanding issues. I get the feeling we are almost > there; if all the issues can be raised now then the upcoming draft can > be the last one. Its been raised already, but I don't remember seeing a resolution ... what about block length? 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 Mon Dec 4 05:11:23 2000 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 FAA16528 for ; Mon, 4 Dec 2000 05:11:22 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES key lengths Date: Mon, 4 Dec 2000 11:11:03 +0100 Organization: IAIK 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <005001c05dda$8235ee00$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Let's not forget that Rijndael is defined for any combinations of block size and key length of 128, 160, 192, 224, and 256 bit. that makes 25 variations times 6 ciphersuites for the various key exchanges, that is 150 ciphersuites we need to define. Just kidding of course. Regarding block sizes, NIST has not asked and nobody ever really looked at block sizes other than 128 bit. I would be very surprised if they were to become part of the FIPS and there seems no interest in them from other sources either. I think we are very safe if we keep to 128 bit only. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at ----- Original Message ----- From: "Ben Laurie" To: "IETF Transport Layer Security WG" Sent: Saturday, December 02, 2000 1:07 PM Subject: [ietf-tls] Re: AES key lengths > Pete Chown wrote: > > As I said before, please could everyone think carefully whether there > > are any more outstanding issues. I get the feeling we are almost > > there; if all the issues can be raised now then the upcoming draft can > > be the last one. > > Its been raised already, but I don't remember seeing a resolution ... > what about block length? --- 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 Dec 4 05:56:07 2000 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 FAA00730 for ; Mon, 4 Dec 2000 05:56:06 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Mon, 4 Dec 2000 11:55:30 +0100 Organization: IAIK 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <00e201c05de0$b8574b40$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit David Hopwood wrote: > Why would that happen? Support for the extension should mean implementing all > possible record sizes (2^8..12 and 2^14), IMHO. > > The only reason I can think of for allowing the server to change the record > size is if the server were also memory-limited, to a greater extent than the > client. This doesn't happen very often for typical uses of TLS, and in any > case using the extension mechanism for that case wouldn't solve anything, > because the server wouldn't be able to limit the record size if the client > does not suggest the extension. For an AES ciphersuite (without MAC truncation) and a 256 record size the average protocol overhead per record would be 33 byte or about 12%. This may reduce the maximum number of concurrent connections for bandwidth limited servers which is something they might want to avoid. This may be contrived, but as I said before I was only suggesting the change because it is an extra feature at no extra cost. If it does not happen, fine. > While I remember, are the maximum lengths of TLSCompressed.fragment and > TLSCiphertext.fragment still to be record_size+1024 and record_size+2048 > respectively? If they are, that makes the smaller record sizes (e.g. 2^8) > ineffective, because the client will still have to handle a buffer of 2304 > bytes in the worst case. The 1024 for compression only apply when compression is active, which can easily be avoided by the client by not requesting compression. The additional 1024 for TLSCiphertext are just a theoretically allowed maximum number for padding and MAC. For all RFC2246 plus the proposed AES ciphersuites the maximum size of a TLSCiphertext (with null compression) is data size + 5 (header) + 16 (padding) + 20 (MAC), i.e. for max. data 256 bytes this would be 297 byte or required memory. Regards, Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- 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 Dec 4 10:28:28 2000 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 KAA22263 for ; Mon, 4 Dec 2000 10:28:27 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Mon, 4 Dec 2000 10:27:41 -0500 Subject: [ietf-tls] Re: I-D ACTION: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: <852569AB.0054A225.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Thanks for the comments, everyone! > Emphasize in the new draft that an implementation MUST handle handshake > messages that are split over multiple records (in fact RFC 2246 already > implies that it must, in section 6.2.1 by my reading, but obviously some > implementors haven't understood that). Will do. > I agree - the contents of the URL should be the same as what would be sent > in the client Certificate message, i.e. a certificate chain. This seems like a tricky issue to me. I agree it may be a burden to expect the server to retrieve an acceptable certificate chain. At the same time, I don't like the idea that clients will have to store multiple urls to different certificate chains. When client authentication happens today, what's the average length of client certificate chains? Best regards. simon --- 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 Dec 4 12:15:58 2000 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 MAA29221 for ; Mon, 4 Dec 2000 12:15:57 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 X-Exmh-Isig-CompType: repl X-Exmh-Isig-Folder: inbox From: marcvh@aventail.com (Marc VanHeyningen) cc: ietf-tls@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in TLS In-reply-to: Your message of "Thu, 30 Nov 2000 12:30:58 EST." Mime-Version: 1.0 Content-Type: text/plain Date: Mon, 04 Dec 2000 09:15:46 -0800 Message-ID: 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: <4426.975950146@aventail.com> X-List-Host: SKYLIST.net > Years ago Eric Young added RLE and ZLIB compression to his SSLeay > package and I want to use them in OpenSSL. On some connections I have > seen dramatic improvements in performance with the use of > compression. The specific implementation is for TLS Telnet with X > Windows Forwarding and TLS FTP. > > Have numbers been assigned? If so, what are they? > > If not, what is the approved method for allocation? I don't see any > TLS related registration lists at the IANA site. I don't know of any official mechanism for it (and apparently nobody else does either); there has been some cooperation among implementors on it, obviously. FWIW, Eric (as you probably know) was using 0xe0 for ZLIB. Aventail uses LZS with SSL, with an identifier of 0xd0. What algorithm do you plan to use? - Marc --- 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 Dec 4 12:23:52 2000 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 MAA02943 for ; Mon, 4 Dec 2000 12:23:51 -0500 (EST) Date: Mon, 4 Dec 2000 12:23:38 EST From: Jeffrey Altman Reply-To: "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" Cc: ietf-tls@lists.certicom.com Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of Mon, 04 Dec 2000 09:15:46 -0800 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 > > If not, what is the approved method for allocation? I don't see any > > TLS related registration lists at the IANA site. > > I don't know of any official mechanism for it (and apparently nobody > else does either); there has been some cooperation among implementors > on it, obviously. FWIW, Eric (as you probably know) was using 0xe0 > for ZLIB. Aventail uses LZS with SSL, with an identifier of 0xd0. What > algorithm do you plan to use? I plan to use ZLIB. Do you know what value was used for RLE? All that needs to be done is for the WG chairs to ask IANA to start to maintain a list of values for use with the TLS RFC. Then IANA can assign numbers as needed. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Dec 4 12:35:17 2000 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 MAA07461 for ; Mon, 4 Dec 2000 12:35:16 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in 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: 04 Dec 2000 09:37:41 -0800 In-Reply-To: Jeffrey Altman's message of "Mon, 4 Dec 2000 12:23:38 EST" Message-ID: Lines: 19 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 Jeffrey Altman writes: > All that needs to be done is for the WG chairs to ask IANA to start to > maintain a list of values for use with the TLS RFC. Then IANA can > assign numbers as needed. Since we only have 256 possible compression algorithm values, I think it would pay to be a little careful about just letting arbitrary people assign numbers. Obviously, we won't want anywhere near that many standard algorithms, but I could easily see that many proprietary algorithms. I propose the following: 1. Algorithms with value >=192 won't be standardized and are for private use. 2. Algorithms with values between 64 and 192 may be standardized by IANA but require some kind of RFC (informational will do). 3. Algorithms with value <64 are reserved for the TLS working group. -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 Dec 4 12:44:36 2000 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 MAA09837 for ; Mon, 4 Dec 2000 12:44:30 -0500 (EST) Date: Mon, 4 Dec 2000 12:44:18 EST 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: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of 04 Dec 2000 09:37:41 -0800 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 > Jeffrey Altman writes: > > All that needs to be done is for the WG chairs to ask IANA to start to > > maintain a list of values for use with the TLS RFC. Then IANA can > > assign numbers as needed. > Since we only have 256 possible compression algorithm values, I think > it would pay to be a little careful about just letting arbitrary people > assign numbers. > > Obviously, we won't want anywhere near that many standard algorithms, > but I could easily see that many proprietary algorithms. > > I propose the following: > 1. Algorithms with value >=192 won't be standardized and are for private > use. > 2. Algorithms with values between 64 and 192 may be standardized by > IANA but require some kind of RFC (informational will do). > 3. Algorithms with value <64 are reserved for the TLS working group. > > -Ekr In general, numbers need to be assigned before there is an RFC. Given how long it takes for RFCs to be issued requiring an RFC before issuance is unrealistic. In general, IANA is rather careful about not issuing out numbers without checking first with the WG chair (if there is a working group) or the Area Director. And they (now) require an Internet-Draft be submitted before the number is issued. So I think that middle range can be removed. I agree that there should be some range allocated for private use. Now we have a partial list of algorithms. If ZLIB is 0x0e and LZS is 0x0d then does that imply that there are 13 other compression algorithms whose values are already in use? This is important to know. I recently when through a similar exercise with Telnet Options and sub option values because IANA was not asked to assign values and it was discovered that many valid values had to be blocked out because implementors had been using them at random because there was no way to find out what the official values were and no way to register their usage. It would be a shame to have to block off the first thirteen values simply because we don't know what they are used for or if they are used for anything at all. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Dec 4 12:52:29 2000 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 MAA12002 for ; Mon, 4 Dec 2000 12:52:28 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in 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: 04 Dec 2000 09:55:04 -0800 In-Reply-To: Jeffrey Altman's message of "Mon, 4 Dec 2000 12:44:18 EST" Message-ID: Lines: 17 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 Jeffrey Altman writes: > In general, IANA is rather careful about not > issuing out numbers without checking first with the WG chair (if there > is a working group) or the Area Director. And they (now) require an > Internet-Draft be submitted before the number is issued. So I think > that middle range can be removed. That's fine with me. > Now we have a partial list of algorithms. If ZLIB is 0x0e and LZS is > 0x0d then does that imply that there are 13 other compression > algorithms whose values are already in use? I don't know, but I rather suspect that Eric just decided to leave some room at the bottom :) I've never heard of any implementation that uses 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 Mon Dec 4 12:58:36 2000 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 MAA13354 for ; Mon, 4 Dec 2000 12:58:35 -0500 (EST) Date: Mon, 4 Dec 2000 12:58:24 EST 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: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of 04 Dec 2000 09:55:04 -0800 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 > Jeffrey Altman writes: > > In general, IANA is rather careful about not > > issuing out numbers without checking first with the WG chair (if there > > is a working group) or the Area Director. And they (now) require an > > Internet-Draft be submitted before the number is issued. So I think > > that middle range can be removed. > That's fine with me. > > > Now we have a partial list of algorithms. If ZLIB is 0x0e and LZS is > > 0x0d then does that imply that there are 13 other compression > > algorithms whose values are already in use? > I don't know, but I rather suspect that Eric just decided to > leave some room at the bottom :) > > I've never heard of any implementation that uses them. RLE and ZLIB were both implemented in SSLeay (by EAY) and naturally they are still supported in OpenSSL. I have been working on cleaning up this code to make it useable. I have found this code to be absolutely crucial for use in communicating over PPP links since the encryption nullifies the compression algorithms used by the modems. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Dec 4 13:03:03 2000 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 NAA14372 for ; Mon, 4 Dec 2000 13:03:01 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in 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: 04 Dec 2000 10:06:47 -0800 In-Reply-To: Jeffrey Altman's message of "Mon, 4 Dec 2000 12:58:24 EST" 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 Jeffrey Altman writes: > RLE and ZLIB were both implemented in SSLeay (by EAY) and naturally > they are still supported in OpenSSL. I have been working on cleaning > up this code to make it useable. I have found this code to be > absolutely crucial for use in communicating over PPP links since the > encryption nullifies the compression algorithms used by the modems. Sorry I wasn't clear. I know that OpenSSL supports RLE and ZLIB. What I meant was that I've never seen any implementation that used the algorithm identifiers between 1 and 0xd. -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 Dec 5 03:25:40 2000 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 DAA27098 for ; Tue, 5 Dec 2000 03:25:39 -0500 (EST) Message-ID: From: "Tord Persokrud (ETO)" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites draft Date: Tue, 5 Dec 2000 09:23:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) 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 Pete, concerning your point 2 below, i.e. always ensuring that two TLS implementations supporting AES can interoperate. It would be good, from our point of view that even our most restricted clients supporting TLS and AES could conform to this document. It follows from this that it would be good to change the wording so that Servers MUST provide both TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA. Clients MUST provide at least one of TLS_RSA_WITH_AES_128_CBC_SHA and TLS_DHE_RSA_WITH_AES_128_CBC_SHA. In case the server has a policy to only use TLS_DHE and the client doesn't provide this, the server won't accept the connection. Tord Persokrud Ericsson -----Original Message----- From: Pete Chown [mailto:Pete.Chown@skygate.co.uk] Sent: 15. november 2000 17:35 To: IETF Transport Layer Security WG Subject: [ietf-tls] New AES ciphersuites draft I have made a new version of the AES ciphersuite draft available. It can currently be downloaded from: ftp://ftp.skygate.co.uk/pub/tls-aes-drafts/draft-ietf-tls-ciphersuite-02.txt In addition, the version on the IETF website should be updated soon. Please let me know any comments which you have. The major changes with this update are: 1. A ADH ciphersuite is now included (which is not deprecated), with an appropriate security warning at the end of the document. 2. The document now indicates what an implementation must do in order to be interoperable. Of course, any two TLS implementations should be interoperable, regardless of whether they implement AES. However, I want to ensure that two TLS implementations supporting AES can always negotiate an AES ciphersuite. -- Pete --- You are currently subscribed to ietf-tls as: Tord.Persokrud@eto.ericsson.se 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 Dec 5 11:59:07 2000 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 LAA10129 for ; Tue, 5 Dec 2000 11:59:05 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: marcvh@aventail.com (Marc VanHeyningen) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in TLS In-reply-to: Your message of "04 Dec 2000 09:55:04 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Dec 2000 08:58:47 -0800 Message-ID: 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: <6428.976035527@aventail.com> X-List-Host: SKYLIST.net Eric Rescorla sed: > Jeffrey Altman writes: > > Now we have a partial list of algorithms. If ZLIB is 0x0e and LZS is > > 0x0d then does that imply that there are 13 other compression > > algorithms whose values are already in use? Er, no. ZLIB is 0xe0, not 0x0e, and LZS is 0xd0. Under EricR's proposed partitioning, that means they're in the "private use" space, which was the general intent. > I don't know, but I rather suspect that Eric just decided to > leave some room at the bottom :) EricY and I both indepdendently chose 0xe0 as the identifier for ZLIB (kind of a creepy conincidence.) I believe his reasoning was that, for the SSLeay library, the address range e0 through ef seemed the logical one to use as semi-private space for "e" to be using. I think we shared the assumptions that: - If the working group ever standardized algorithms, they would use the lower part of the range as "official" and the upper part as "private." - The WG would not be doing this soon, if ever. > I've never heard of any implementation that uses them. I haven't heard of anybody using any compression mechanism under d0 either (except for 0, of course.) - Marc -- Marc VanHeyningen marcvh@aventail.com Internet Security Architect Aventail http://www.aventail.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 Dec 5 12:19:43 2000 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 MAA16964 for ; Tue, 5 Dec 2000 12:19:42 -0500 (EST) Date: Tue, 5 Dec 2000 12:19:32 EST 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: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of Tue, 05 Dec 2000 08:58:47 -0800 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 Does anyone object to standardizing some of these values? Marc VanHeyningen wrote: > Er, no. ZLIB is 0xe0, not 0x0e, and LZS is 0xd0. Under EricR's proposed > partitioning, that means they're in the "private use" space, which was the > general intent. Thanks for the correction. > EricY and I both indepdendently chose 0xe0 as the identifier for ZLIB > (kind of a creepy conincidence.) I believe his reasoning was that, for > the SSLeay library, the address range e0 through ef seemed the logical > one to use as semi-private space for "e" to be using. > > I think we shared the assumptions that: > > - If the working group ever standardized algorithms, they would use the > lower part of the range as "official" and the upper part as "private." > - The WG would not be doing this soon, if ever. > > > I've never heard of any implementation that uses them. > > I haven't heard of anybody using any compression mechanism under d0 > either (except for 0, of course.) This makes sense. Does anyone have any objection to standardizing some values for these compression algorithms? As libraries mature, the compression algorithms they provide will become more pervasive and data compression will certainly help in the low bandwidth environments. How about TLS_COMP_NONE 0 TLS_COMP_ZLIB 1 TLS_COMP_RLE 2 TLS_COMP_LZS 3 and we can go on from there? I can write up the Internet-Draft if no one sees a problem with this. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Tue Dec 5 12:20:03 2000 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 MAA17079 for ; Tue, 5 Dec 2000 12:20:02 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in 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: 05 Dec 2000 09:23:43 -0800 In-Reply-To: marcvh@aventail.com's message of "Tue, 05 Dec 2000 08:58:47 -0800" 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 marcvh@aventail.com (Marc VanHeyningen) writes: > Eric Rescorla sed: > > Jeffrey Altman writes: > > > Now we have a partial list of algorithms. If ZLIB is 0x0e and LZS is > > > 0x0d then does that imply that there are 13 other compression > > > algorithms whose values are already in use? > > Er, no. ZLIB is 0xe0, not 0x0e, and LZS is 0xd0. Under EricR's proposed > partitioning, that means they're in the "private use" space, which was the > general intent. One question to ask here is whether support for these algorithms is sufficiently widespread to merit trying to salvage the IDs. Marc, is your ZLIB implementation compatible with EAYs? Jeff, in your code cleanup are you changing the bits on the wire? -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 Dec 5 12:25:10 2000 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 MAA18053 for ; Tue, 5 Dec 2000 12:25:09 -0500 (EST) Date: Tue, 5 Dec 2000 12:25:01 EST 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: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of 05 Dec 2000 09:23:43 -0800 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 > > Er, no. ZLIB is 0xe0, not 0x0e, and LZS is 0xd0. Under EricR's proposed > > partitioning, that means they're in the "private use" space, which was the > > general intent. > One question to ask here is whether support for these algorithms > is sufficiently widespread to merit trying to salvage the IDs. > > Marc, is your ZLIB implementation compatible with EAYs? > Jeff, in your code cleanup are you changing the bits on the > wire? I am not changing the bits on the wire. Just some items internal to OpenSSL. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Tue Dec 5 12:31:31 2000 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 MAA18874 for ; Tue, 5 Dec 2000 12:31:30 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in 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: 05 Dec 2000 09:33:59 -0800 In-Reply-To: Jeffrey Altman's message of "Tue, 5 Dec 2000 12:19:32 EST" 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 Jeffrey Altman writes: > Does anyone object to standardizing some of these values? Not in theory. > How about > > TLS_COMP_NONE 0 > TLS_COMP_ZLIB 1 > TLS_COMP_RLE 2 > TLS_COMP_LZS 3 > > and we can go on from there? I can write up the Internet-Draft if no > one sees a problem with this. The reason that the TLS WG didn't do this originally was because of intellectual property considerations. I know that Hi/fn has repeatedly asserted that they have patents on LZS (see RFC 2395). ISTR that someone claims IP on RLE, but I'm not sure. RFC 2394 claims that ZLIB (called DEFLATE in that draft) is patent-free. Would you want these drafts to be Informational or Proposed? -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 Dec 5 12:37:10 2000 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 MAA20172 for ; Tue, 5 Dec 2000 12:37:09 -0500 (EST) Date: Tue, 5 Dec 2000 12:36:59 EST 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: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of 05 Dec 2000 09:33:59 -0800 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 > Jeffrey Altman writes: > > Does anyone object to standardizing some of these values? > Not in theory. > > > How about > > > > TLS_COMP_NONE 0 > > TLS_COMP_ZLIB 1 > > TLS_COMP_RLE 2 > > TLS_COMP_LZS 3 > > > > and we can go on from there? I can write up the Internet-Draft if no > > one sees a problem with this. > The reason that the TLS WG didn't do this originally was because > of intellectual property considerations. I know that Hi/fn has > repeatedly asserted that they have patents on LZS (see RFC 2395). > > ISTR that someone claims IP on RLE, but I'm not sure. RFC 2394 > claims that ZLIB (called DEFLATE in that draft) is patent-free. > > Would you want these drafts to be Informational or Proposed? > > -Ekr Proposed Standard would be best. I would be happy with only defining a value for ZLIB (deflate). Deflate is the algorithm used in GZIP and ZIP/UNZIP. Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Tue Dec 5 12:51:51 2000 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 MAA22392 for ; Tue, 5 Dec 2000 12:51:50 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in 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: 05 Dec 2000 09:54:12 -0800 In-Reply-To: Jeffrey Altman's message of "Tue, 5 Dec 2000 12:36:59 EST" Message-ID: Lines: 7 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 Jeffrey Altman writes: > Proposed Standard would be best. I would be happy with only > defining a value for ZLIB (deflate). Deflate is the algorithm used in > GZIP and ZIP/UNZIP. I think it's best to go with that, then. -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 Dec 5 13:00:23 2000 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 NAA23534 for ; Tue, 5 Dec 2000 13:00:22 -0500 (EST) Date: Tue, 5 Dec 2000 13:00:04 EST 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: Assignment of Numbers for Compression Algorithms in TLS In-Reply-To: Your message of 05 Dec 2000 09:54:12 -0800 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 > Jeffrey Altman writes: > > Proposed Standard would be best. I would be happy with only > > defining a value for ZLIB (deflate). Deflate is the algorithm used in > > GZIP and ZIP/UNZIP. > I think it's best to go with that, then. > Ok. Then I will write up an Internet-Draft for use of ZLIB (DEFLATE) as a compression algorithm for TLS with an ID value of 0x01. (unless there is agreement to preserve the existing values.) The draft will partition the ID space into two ranges: < 192 - reserved for IANA registrations >= 192 - private use Jeffrey Altman * Sr.Software Designer The Kermit Project * Columbia University 612 West 115th St * New York, NY * 10025 * USA http://www.kermit-project.org/ * kermit-support@kermit-project.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 Tue Dec 5 20:00:04 2000 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 UAA28665 for ; Tue, 5 Dec 2000 20:00:01 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-061.dialup.zetnet.co.uk [194.247.41.76] claimed to be zetnet.co.uk Message-ID: Date: Wed, 06 Dec 2000 00:56:58 +0000 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" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A2D8EDA.314D969D@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Andreas Sterbenz wrote: > David Hopwood wrote: > > Why would that happen? Support for the extension should mean implementing > > all possible record sizes (2^8..12 and 2^14), IMHO. > > > > The only reason I can think of for allowing the server to change the > > record size is if the server were also memory-limited, to a greater extent > > than the client. This doesn't happen very often for typical uses of TLS, > > and in any case using the extension mechanism for that case wouldn't solve > > anything, because the server wouldn't be able to limit the record size if > > the client does not suggest the extension. > > For an AES ciphersuite (without MAC truncation) I suggest simply making the AES ciphersuites use 80 bit MACs instead of negotiating MAC truncation; I'll explain why in another post. > and a 256 record size the average protocol overhead per record would be > 33 byte or about 12%. This may reduce the maximum number of concurrent > connections for bandwidth limited servers which is something they might > want to avoid. This may be contrived, but as I said before I was only > suggesting the change because it is an extra feature at no extra cost. > If it does not happen, fine. It does have a cost, in both complexity and interoperability problems. What happens if a client has less than 2^14 bytes of memory remaining for use by TLS? The server has no way to know just how tight the client is on memory, other than trusting what the client says in the extension. > > While I remember, are the maximum lengths of TLSCompressed.fragment and > > TLSCiphertext.fragment still to be record_size+1024 and record_size+2048 > > respectively? If they are, that makes the smaller record sizes (e.g. 2^8) > > ineffective, because the client will still have to handle a buffer of 2304 > > bytes in the worst case. > > The 1024 for compression only apply when compression is active, No, the maximum size of a TLSCiphertext.fragment is currently defined to be 2^14 + 2048 regardless of whether compression is active or not. Remember that the padding can be longer than one block, in order to obscure the length of the plaintext record. > which can easily be avoided by the client by not requesting compression. That's an ugly kludge, and it doesn't solve the problem anyway. Why not change the maximum TLSCompressed and TLSCiphertext fragment sizes to record_size + 64 and record_size + 128 respectively when record_size != 2^14? > The additional 1024 for TLSCiphertext are just a theoretically allowed > maximum number for padding and MAC. If it's theoretically allowed then the client MUST be able to allocate that amount of memory (otherwise it may find that the 2048 additional bytes are actually used, which is valid according to the spec, and not be able to continue with the session). > For all RFC2246 plus the proposed AES ciphersuites the maximum size of > a TLSCiphertext (with null compression) is data size + 5 (header) + > 16 (padding) + 20 (MAC), i.e. for max. data 256 bytes this would be > 297 byte or required memory. No, this is not correct. The overall maximum size of a TLSCiphertext record would be 5 + 256 + 2048 = 2309 bytes (the MAC is counted in the 256 + 2048), unless the amount of extra space allowed for padding is reduced. - -- 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 iQEVAwUBOi2NGDkCAxeYt5gVAQG8vgf+JlOky32uUXYSoXnoLn+aLqBu3Wb3TZoy Ws850kmS3jQK+Yx4yXr2GH4jr/LVgvb87kXoNZ5WG+zQ9bZ8s/+uIOrj7vAAPbgI bKbrqKNT8ipmM0jouBY7bakiG+9Is/4/KmmBJnqDFKFtV2fZtmU8YRPkErNEwm+4 Q4zqLMBjR7lBk06XeB2YVYM3mj+QoIMhOwfDwZDBFTEYu/yLLbJDSx/auLQtp44D Cnol6mzH92PGIEQcdTW49ss4Fhs3lvD2m50Sa6poczIa3q2s0T4A7Wx5RnxCM1XZ qrO9Hx+7GuPhy5ScpkJC74dUpjrf750DOy7sslrvJqPk2E+oubHS+A== =u5nu -----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 Tue Dec 5 20:00:17 2000 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 UAA28719 for ; Tue, 5 Dec 2000 20:00:15 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-061.dialup.zetnet.co.uk [194.247.41.76] claimed to be zetnet.co.uk Message-ID: Date: Wed, 06 Dec 2000 00:57:17 +0000 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" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A2D8EED.3F6EE364@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Simon Blake-Wilson wrote: > David Hopwood wrote: > > I agree - the contents of the URL should be the same as what would be > > sent in the client Certificate message, i.e. a certificate chain. > > This seems like a tricky issue to me. I agree it may be a burden to > expect the server to retrieve an acceptable certificate chain. I don't see how it would be done at all. When there are 3 or more certificates in the complete chain, how is the server to know where to find the middle ones (assuming it does not know what they should be already)? > At the same time, I don't like the idea that clients will have to store > multiple urls to different certificate chains. Each certificate is normally associated with a single chain (i.e. the X.509 certificate hierarchy is a tree, not a directed graph), so AFAICS the client wouldn't have to store any more data than it would if an URL only pointed to a single certificate. - -- 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 iQEVAwUBOi2OcTkCAxeYt5gVAQFr3Qf+OkKj2waBCPQHFqeUcua5e9TCPG9luVDf b7i0K/tyfHlN3kut2hNPZoPxMu+bygeoSDIsDs5s6qB8r8j80bmM4rCV2SwICKYD bUXssKaZ+A9ZqX37OcP+WLtdhdoM88CaWdc1NBvnwUpv5yGnCbK1b5XHK4+VtLG2 yhesprKsdWH2ukju3xSmU9tZWPFE2zMnBX6WLwwQwX6K4mKqCZ2sq2tBeJJD20CS LqsPOb8akk/1iY3g8ckOh6w34DX7DyC3WUwEtbjjwkBjIJnnrYUeFiop4f7TVuop eDsFf/CIVYEw+JJWKUR1Ev2L/04PhTsGXo8h6if8Y5IIsnClbNl3Pw== =l6TU -----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 Wed Dec 6 04:37:26 2000 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 EAA16469 for ; Wed, 6 Dec 2000 04:37:25 -0500 (EST) Message-ID: From: "Andreas Sterbenz" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Date: Wed, 6 Dec 2000 10:34:45 +0100 Organization: IAIK 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <003701c05f67$c540ea90$4c981b81@kant> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit > > For all RFC2246 plus the proposed AES ciphersuites the maximum size of > > a TLSCiphertext (with null compression) is data size + 5 (header) + > > 16 (padding) + 20 (MAC), i.e. for max. data 256 bytes this would be > > 297 byte or required memory. > > No, this is not correct. The overall maximum size of a TLSCiphertext > record would be 5 + 256 + 2048 = 2309 bytes (the MAC is counted in the > 256 + 2048), unless the amount of extra space allowed for padding is > reduced. You are right about the padding being 256 byte max, but the rest still holds. The TLS limits do not matter if the ciphersuites used define tighter limits. If you want to prove me wrong show it in an example. TLS client sends client hello: NULL compression, ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA (add others if you want), record size 256. Now explain how a TLS compliant server (assuming it accepts the 256 byte maximum record size) can send a record in excess of 5 + 256 + 256 + 20 = 537 byte or why a client would need more storage for the record than 537 byte. Andreas Sterbenz mailto:Andreas.Sterbenz@iaik.at --- 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 Dec 6 06:50:08 2000 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 GAA15929 for ; Wed, 6 Dec 2000 06:50:06 -0500 (EST) Date: Wed, 6 Dec 2000 11:48:06 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] RE: New AES ciphersuites draft 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 Tord.Persokrud@eto.ericsson.se on Tue, Dec 05, 2000 at 09:23:47AM +0100 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: <20001206114806.E15388@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Tord Persokrud (ETO) wrote: > Pete, concerning your point 2 below, i.e. always ensuring that two > TLS implementations supporting AES can interoperate. It would be > good, from our point of view that even our most restricted clients > supporting TLS and AES could conform to this document. Unfortunately if the interoperability requirements are reversed it creates a problem for the web people. Suppose I am very concerned about security so I want to use forward secrecy in my web browsing. I can choose to support only that ciphersuite, whereupon the server is forced to accept the extra processing load associated with it. I assume (because you are from Ericsson) that you are concerned about the opposite problem. You are producing mobile devices that don't have the processing power to do forward secrecy. One point that occurs to me is that if I am browsing the web with a mobile device, and the server insists on forward secrecy, the negotiation will take twice as long and I am going to be pretty frustrated. So the server operators will have an incentive to offer a static ciphersuite in order to keep their customers happy. In the opposite case this doesn't work, because when I am using a server I am only one of hundreds of other users. So the extra processing load that I create is not noticeable to me. Everyone experiences a small drop in performance, rather than it being that I personally experience a big one. The other point is that the MUST ciphersuites don't apply if an "application profile standard" specifies some other interoperability rule. If you were producing a mobile-specific protocol you could do exactly this. Comments appreciated as always... -- 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 Dec 6 07:06:33 2000 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 HAA19603 for ; Wed, 6 Dec 2000 07:06:32 -0500 (EST) Date: Wed, 6 Dec 2000 12:04:10 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Other AES key lengths 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 Wed, Nov 29, 2000 at 11:30:31AM +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: <20001206120410.F15388@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Hironobu SUZUKI wrote: > I don't familiar with this TLS ML discussion. Anyway, I'd like to make > a list of ciphersuites for AES 128/192/256 as below. > > TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x2F } > TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x30 } > TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x31 } > TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00,0x32 } > TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00,0x33 } > TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00,0x34 } > > TLS_RSA_WITH_AES_192_CBC_SHA = { 0x00,0x35 } > TLS_DH_DSS_WITH_AES_192_CBC_SHA = { 0x00,0x36 } > TLS_DH_RSA_WITH_AES_192_CBC_SHA = { 0x00,0x37 } > TLS_DHE_DSS_WITH_AES_192_CBC_SHA = { 0x00,0x38 } > TLS_DHE_RSA_WITH_AES_192_CBC_SHA = { 0x00,0x39 } > TLS_DH_anon_WITH_AES_192_CBC_SHA = { 0x00,0x3A } > > TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x3B } > TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x3C } > TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x3D } > TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00,0x3E } > TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00,0x3F } > TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00,0x40 } Thanks; I will probably do exactly this if the consensus is to add 192 and 256 bit ciphersuites. Eric Rescorla wrote: > I really don't think [192 bit] is necessary. Let's for the moment > say that the arguments for why we need 256 are convincing. (I don't > think so, but never mind that). I don't see why this means we need > all three lengths. I see what you are saying. The only advantage of 192 bit is better performance than 256 bit while better security than 128 bit. Also I suppose it would be cleaner to support 192 bit because then it would support all the AES options (as opposed to all the Rijndael options, of which there are many more). Also as Nelson Bolyard pointed out, it is important that we can support all the requirements of the AES FIPS. I'd be happy with either solution on this one (I'm just worried that it will become a bone of contention which wastes a lot of time). > Sure, it's possible that 192 is more secure than 128 or 256, but > if we believe that it suggests that AES is seriously broken and > we need a different backup entirely. Quite so. Ben Laurie wrote: > Its been raised already, but I don't remember seeing a resolution ... > what about block length? This will be fixed in the next draft. Andreas Sterbenz wrote: > Regarding block sizes, NIST has not asked and nobody ever really looked at > block sizes other than 128 bit. Yes, I don't think we should be supporting *block sizes* other than 128 bit. There are arguments for supporting longer keys though, even if I think that on balance it is a bad idea. I think we should stick to supporting AES features rather than the extra "bonus" Rijndael features that NIST didn't ask for. There are actually (minor) advantages to supporting different modes of operation as well, but we will never agree on anything if we go down that road! -- 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 Dec 6 07:24:26 2000 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 HAA23512 for ; Wed, 6 Dec 2000 07:24:25 -0500 (EST) Date: Wed, 6 Dec 2000 12:23:15 +0000 From: Pete Chown To: "IETF Transport Layer Security WG" Subject: [ietf-tls] AES outstanding issues 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: <20001206122315.G15388@hyena.skygate.co.uk> X-List-Host: SKYLIST.net Okay, these are the outstanding issues that I can see with the AES draft. Let's go and bang our heads against the wall -- by the time we've been going for a while we will probably be able to imagine that there is some kind of consensus! :-) 1. Key lengths. I think the options here are: a. Do nothing -- have 128-bit key lengths only. b. Add 256-bit keys. c. Add 192-bit and 256-bit keys. What do people think about these choices? I proposed that the interoperability rules should use 128-bit keys and no one has raised any objection to this. If you have an objection but have been too shy, please come forward now... :-) 2. Interoperability. Ericsson are concerned that the current interoperability rules will force mobile devices to support forward secrecy when they don't have the processing power to do so. 3. Block length. I can't see any problem here -- I will just clarify in the next draft that we are talking about 128-bit blocks. 4. I have also been sent a few minor corrections in private mail but there is nothing contentious there. These will be corrected in the next draft. If I have missed your issue please let me know. It's good fun doing this... I'll never think of UN negotiations and things in quite the same way either! :-) -- 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 Dec 6 13:42:11 2000 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 NAA13539 for ; Wed, 6 Dec 2000 13:42:10 -0500 (EST) X-Mailer: exmh version 2.0.2 2/24/98 From: marcvh@aventail.com (Marc VanHeyningen) To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Assignment of Numbers for Compression Algorithms in TLS In-reply-to: Your message of "05 Dec 2000 09:23:43 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Dec 2000 10:40:47 -0800 Message-ID: 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: <7309.976128047@aventail.com> X-List-Host: SKYLIST.net Eric Rescorla awk: > marcvh@aventail.com (Marc VanHeyningen) writes: > > Eric Rescorla sed: > > ZLIB is 0xe0, not 0x0e, and LZS is 0xd0. Under EricR's proposed > > partitioning, that means they're in the "private use" space, which was the > > general intent. > One question to ask here is whether support for these algorithms > is sufficiently widespread to merit trying to salvage the IDs. > > Marc, is your ZLIB implementation compatible with EAYs? Never tried it; by the time Eric was doing ZLIB experimentation, we had abandoned it (it seemed too slow for compressing data streams, though Moore's law may have changed that) in favor of licensing LZS from Hi/fn. We only use LZS when using TLS in the context of SOCKSv5, not for https or any of the more widely deployed protocols. Because of that, I don't see a strong case for preserving the 0xd0 identifier if LZS gets some kind of registered status. Eric's ZLIB experiments clearly have enjoy much wider distribution, so the story may be different there. - Marc -- Marc VanHeyningen marcvh@aventail.com Internet Security Architect Aventail http://www.aventail.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 Dec 6 19:24:52 2000 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 TAA16679 for ; Wed, 6 Dec 2000 19:24:51 -0500 (EST) X-Lotus-FromDomain: CERTICOM From: "Simon Blake-Wilson" To: "IETF Transport Layer Security WG" Message-ID: Date: Wed, 6 Dec 2000 19:03:03 -0500 Subject: [ietf-tls] Re: AES outstanding issues 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: <852569AE.0001E573.00@smtpmail.certicom.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Hi Pete, I'd like to support the idea that a server is required to support a range of cipher suites, while the client is required to support only one of these. It seems to me like it is in 'the general interest' to support connections from as wide a range of client devices as possible ... Best regards. Simon Pete Chown on 12/06/2000 07:23:15 AM Please respond to "IETF Transport Layer Security WG" To: "IETF Transport Layer Security WG" cc: (bcc: Simon Blake-Wilson/Certicom) Subject: [ietf-tls] AES outstanding issues Okay, these are the outstanding issues that I can see with the AES draft. Let's go and bang our heads against the wall -- by the time we've been going for a while we will probably be able to imagine that there is some kind of consensus! :-) 1. Key lengths. I think the options here are: a. Do nothing -- have 128-bit key lengths only. b. Add 256-bit keys. c. Add 192-bit and 256-bit keys. What do people think about these choices? I proposed that the interoperability rules should use 128-bit keys and no one has raised any objection to this. If you have an objection but have been too shy, please come forward now... :-) 2. Interoperability. Ericsson are concerned that the current interoperability rules will force mobile devices to support forward secrecy when they don't have the processing power to do so. 3. Block length. I can't see any problem here -- I will just clarify in the next draft that we are talking about 128-bit blocks. 4. I have also been sent a few minor corrections in private mail but there is nothing contentious there. These will be corrected in the next draft. If I have missed your issue please let me know. It's good fun doing this... I'll never think of UN negotiations and things in quite the same way either! :-) -- Pete --- 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 Thu Dec 7 05:43:38 2000 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 FAA25648 for ; Thu, 7 Dec 2000 05:43:32 -0500 (EST) Date: Thu, 7 Dec 2000 11:42:15 +0100 From: Bodo Moeller To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-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 Tue, Nov 28, 2000 at 06:01:58AM -0500 List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <20001207114215.A2349@cdc.informatik.tu-darmstadt.de> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 8bit On Tue, Nov 28, 2000 at 06:01:58AM -0500, Internet-Drafts@ietf.org wrote: > Title : Wireless Extensions to TLS > Author(s) : S. Blake-Wilson > Filename : draft-ietf-tls-wireless-00.txt > Pages : 13 > Date : 27-Nov-00 < 2.3. Hello Extensions < < The extension format for extended client hellos and extended server < hellos is: < < struct { < ExtensionType extensionType; < opaque unknown_extension<0..2^16-1>; < } Extension; < < Here: < < - "extensionType" identifies the particular extension type. < < - "unknown_extension" contains information specific to the particular < extension type. Why do you call it "unknown_extension"? One would hope that client and server do know the extensions that they actually use. Why not call it opaque extension_data<0..2^16-1> or opaque extension_parameters<0..2^16-1> or something like that? < 3.1. Maximum Record Size Negotiation < Once a maximum record size other than 2^14 has been successfully < negotiated during a TLS handshake, both the client and server pass the < negotiated maximum record size value to the TLS record layer along with < the negotiated security parameters. (Note that it may be desirable in < the future to update the TLS security parameters to include the maximum < record size value.) During the subsequent session after exchange of < change cipher spec messages, the client and server MUST ensure that no < messages larger than the negotiated size are sent. What exactly does "Once a maximum record size ... has been .. negotiated" mean? Since possibly the client cannot handle large records at all, the ServerHello message should already be sent using small records. The other "negotiated security parameters" to be passed to the TLS record layer have not yet been determined at this stage, though, so if the maximum record size is passed to the record layer along with these security parameters, then the handshake might contain records that are too large for the client to handle. What is supposed to happen if a renegotiation is performed? Does the maximum record size survive into the new session without having to be negotiated again? < 3.2. Client Certificate URLs < Servers receiving "CertificateorURL" shall attempt to retrieve the < client's certificate chain from the URL (if necessary), and then process the < certificate chain as usual. The specification should give some details on what the data to be obtained from the URL should look like -- just a DER-encoded octet stream, or a TLS "Certificate" object as defined in RFC 2246, or whatever. < 3.3. Trusted CA Indication < Wireless clients which, due to memory limitations, possess only a small < number of CA root keys, may wish to indicate to servers which root keys < they possess, in order to avoid repeated handshake failures. < Here "TrustedAuthorities" provides a list of CA root key identifiers < that the client possesses. Each CA root key is identified via either: < < - "null" - no CA root key identity supplied. < < - "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA < and ECDSA keys, this is the hash of the "subjectPublicKey" value. For < RSA keys, this is the hash of the byte string representation of the < modulus.) < < - "x509_name" - contains the X.509 distinguished name of the CA. By giving just one of these, it is not necessarily possible to uniquely determine the intended issuer and key. A CA may have two certificates using exactly the same distinguished name (RSA and DSA certs, say), but there might also be certificates naming different issuers and containing identical keys -- so in extreme cases both the "key_hash_sha" and "x509_name" would have to be specified. In less pathological situations where giving just one of these is enough, the client usually still cannot know which one it should use. Maybe the CA has started to issue DSA certs, so "key_hash_sha" should be used. But maybe a new root certificate uses the same key and a different distinguished name (I'm not really sure why anyone would want to do this -- trademark disputes, possibly; anyway, it certainly is legal), so "x509_name" might be necessary. For the "key_hash_sha" case, why not hash all of "subjectPublicKey" for RSA keys? A CA might use related RSA keys (same modulus, different exponents) for different roles, so hashing just the modulus may not suffice. < 3.5. Truncated MACs < In order to negotiate the use of truncated MACs, clients MAY include an < extension of type "truncated_MAC" in the extended client hello. The < "unknown_extension" field of this extension shall contain < "MACTruncations", where: < < 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; < < Here "MACTruncations" contains a list of MAC truncation sizes suggested < by the client. [...] This allows for rollback attacks if the *minimum* of truncated MAC sizes that are acceptable to both the client and the server has become unsecure. To make sure that the server and not the attacker can decide which MAC size of those that are acceptable to both the client and the server is used (e.g., the maximum), the server's signature in the ServerKeyExchange message should cover all of the ClientHello message instead of just ClientHello.random. Similarly (at least if no ServerKeyExchange message is used) the EncryptedPreMasterSecret message should contain a hash of the ClientHello message instead of just client_version. (These changes are desirable for other reasons anyway: Attackers who can crack export-weakend ephemeral DH or RSA keys in real-time [i.e., before the server switches to a new ephemeral key] currently can force clients and servers that are not export-crippled to use export ciphers suites. If the signature in the ServerKeyExchange and the encrypted data in the EncryptedPreMasterSecret are changed as above, this problem can be avoided; however, backwards compatibility will allow for protocol version rollback attacks, so we cannot really solve this existing problem in the near future. But we can avoid similar problems for new protocol variants, such as TLS with truncated 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 Dec 8 00:32:03 2000 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 AAA29131 for ; Fri, 8 Dec 2000 00:31:58 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a215.dialup.zetnet.co.uk [194.247.44.215] claimed to be zetnet.co.uk Message-ID: Date: Fri, 08 Dec 2000 05:26:09 +0000 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" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A3070F1.72BCE0B2@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Internet-Drafts@ietf.org wrote: > http://www.ietf.org/internet-drafts/draft-ietf-tls-wireless-00.txt > > Wireless Extensions to TLS > This draft will be referred to for all extensions, including those that don't have anything to do with wireless, so it should probably be called just something like "Extensions to TLS" (especially if the dns_name extension is also included). For example: Extensions to TLS ... 1. Introduction This document describes an extension mechanism that can be used to add functionality to the Transport Layer Security protocol [TLS]. The focus of most of the extensions defined here is on support for wireless and limited memory environments. An extension designed to support virtual hosting of TLS servers is also defined. Wireless environments often suffer from a number of constraints not commonly present in wired environments - these constraints may include bandwidth limitations, computational power limitations, memory limitations, and battery life limitations. Use within wireless environments was not one of the initial design criteria of the TLS protocol. As a result, implementations of TLS within wireless environments face a number of challenges. The extensions described here focus on extending the functionality provided by the TLS protocol message formats. Other issues, such as the addition of "wireless-friendly" cipher suites, are deferred or left to other specifications. Although not an extension as such, this document also encourages servers to use small session identifiers; this is again motivated by support for limited memory environments. ... > - Allow TLS clients and servers to negotiate the use of truncated MACs. > This functionality is desirable in order to conserve bandwidth in > wireless networks. I strongly feel that this should not be negotiated separately from the ciphersuite. We can specify that the new AES ciphersuites always use an 80-bit MAC; that would not result in any loss of security (given that SSL/TLS requires the session to be immediately aborted if a MAC is incorrect, so the forgery probability would be limited to 2^-80 per session). Reasons for not negotiating MAC size separately: - The security and efficiency effects of truncating the MAC to a particular size will vary between different MAC algorithms (for example they vary between HMAC and UMAC, and it's quite possible that UMAC-based ciphersuites will be added to TLS at some point). Even though the proposed mechanism allows different sizes for different MAC algorithms, configuring that could be quite complicated for users and server administrators. - Future ciphersuites might merge the encryption and MAC into a single algorithm for efficiency (e.g. using one of the modes described in the recent AES modes conference; see ). In that case it is not clear that specifying the MAC output size makes sense. - Negotiating different parts of the ciphersuite orthogonally has been discussed before and rejected, IMHO for sound reasons. In particular, requiring each combination to be defined explicitly limits the number of combinations that have to be considered in analysis. - APIs for SSL/TLS libraries may assume that a list of ciphersuites is all that needs to be given in order to specify a policy on which algorithm variants are considered secure. In general, this would not be true any more if separate MAC size negotiation was added. - In practice making new ciphersuites have truncated MACs is just as good as being able to negotiate them for any ciphersuite, since any (client, server) pair that both implement the extension would also presumably implement at least some of the AES ciphersuites, and would probably negotiate one of them almost all the time. I.e. I suggest removing the truncated_MAC extension, and making the AES ciphersuites always use 80-bit MACs (i.e. *_SHA_80). I also think dns_name should be included. Here is a suggested syntax, taking into account the previous discussions on this topic: opaque DNSName<1..2^16-1>; enum { success(0), unrecognised_name(1), (255) } DNSStatusCode; The extension sent by the client is of type DNSName, which represents the fully qualified domain name of the server, as understood by the client. This value is intended to be used by servers which support multiple "virtual" servers on a single underlying network address. A server that understands this extension MAY use this value to decide which certificate to use in subsequent negotiations. A DNS name is represented as an octet string using UTF-8 encoding, subject to any further standardisation by the IETF DNS working group of how non-ASCII names are handled. [[reference to DNS RFC?]] [[Are dotted-decimal IP addresses allowed/useful?]] The response by the server is of type DNSStatusCode. A 'success' response means that the server has taken the name into account in deciding which certificate to use. An 'unrecognised_name' response means that although the server implementation understood the extension, it does not recognise the DNS name as belonging to a (possibly virtual) server it is responsible for. Clients SHOULD include a dns_name extension whenever they locate a server by its domain name, unless an application profile for the protocol being used over TLS specifies otherwise. The defined extension types would then be enum { dns_name(0), max_record_size(1), client_certificate_url(2), trusted_key_ids(3), status_request(4), (65535) } ExtensionType; > Finally note that it is possible to alternatively define > "unknown_extension" using a selection on "extensionType" (instead of > just defining it as type "opaque"). This approach appears to have pros > and cons - using a selection is more restrictive and thus less prone to > implementation errors, but using "opaque" ensures inclusion of the > length and thus ensures that users can skip extensions they don't > understand. We would particularly welcome comments on this issue. The length has to be included, because it's essential that extensions that are not understood can be skipped. The above paragraph should not appear in the next draft, of course. > 3. Wireless Extensions Just say "Extensions", since they're not specific to wireless. > 3.1. Maximum Record Size Negotiation An example of maximum TLSCompressed and TLSCiphertext sizes should be added (see my other post). > 3.2. Client Certificate URLs I think the contents of the URL should be a complete certificate chain. > struct{ > Certificate_or_URL certificate_transport_type; > select (Certificate_or_URL) { > case certificate: > ASN.1Cert certificate_list<0..2^24-1>; > case url: > opaque url<0..2^8-1>; > } certificate_transport_body; > } CertificateorURL; Should this say URI rather than URL? > enum{ certificate(1), url(2), (255) } Certificate_or_URL ; > > (Nevertheless, the handshake message is identified as being of type > "certificate".) Since it is encoded differently, it should be given a new handshake message type. Even though it would not matter much in this particular case, in general I don't think that overloading a message type to contain different information depending on whether an extension has been accepted is a good idea. > 3.3. Trusted CA Indication > struct { > IdentifierType identifier_type; > select (identifier_type) { > case null: struct {}; > case key_hash_sha: KeyHash; > case x509_name: DistinguishedName; Add here default: opaque unknown_identifier<0..2^16-1>; for future extensibility, and make KeyHash variable length so that all the types are encoded the same. > } identifier; > } TrustedAuthority; > > enum { null(0), key_hash_sha(1), x509_name(2),(255)} > IdentifierType; > > opaque DistinguishedName<1..2^16-1>; > > opaque KeyHash[20]; > > Here "TrustedAuthorities" provides a list of CA root key identifiers > that the client possesses. Each CA root key is identified via either: > > - "null" - no CA root key identity supplied. I don't see the point of this. It appears to only be used in section 3.6, and there it would be simpler for the case where the authorities are implicitly known to be encoded as a zero-length sequence of TrustedAuthorities. (It is not useful to be able to represent the fact that a client does not trust any authorities, since then it could never accept a connection.) > - "key_hash_sha" - contains the SHA-1 hash of the CA root key. (For DSA > and ECDSA keys, this is the hash of the "subjectPublicKey" value. For > RSA keys, this is the hash of the byte string representation of the > modulus.) IMHO this should be the hash of an unambiguous encoding. The above isn't unambiguous: - an RSA key has a public exponent as well as a modulus, - technically an RSA modulus might have the same representation as a DSA/ECDSA SubjectPublicKey value. Although there doesn't appear to be any attack as a result of this, it would be more straightforward for the hash to be of the SubjectPublicKey value for RSA as well as DSA/ECDSA keys (DER-encoded, i.e. exactly as it appears in the certificate). Alternatively it could be a hash of the whole certificate. ... > The syntax used by TLS for session identifiers is: > > opaque SessionID<0..32>; > > In order to encourage use of small session identifiers, servers SHOULD > select session identifiers whose length is 8 bytes or less. Session identifiers MUST have negligable probability of being repeated within, say, 24 hours, since if a client tries to connect with an identifier that has been reused, the handshake will break. Since use of small session identifiers is not (and does not need to be) an extension, it should probably be moved out of section 3 to its own section. > 3.5. Truncated MACs As explained above, I think this should be removed. If it is not removed, though, the padding of MAC sizes that are not a multiple of 8 bits is ambiguous. > 3.6. OCSP > (Nevertheless, the handshake message is identified as being of type > "certificate".) Same comment here as for CertificateorURL. > Here "ocsp_response" contains a complete, DER-encoded OCSP response. Specify the name of the ASN.1 type from [OCSP]. > Clients requesting an OCSP response, and receiving an OCSP response in > a "CertificateAndOCSPResponse" field: > > - MUST process the certificate as if it was received in a "Certificate" > message, and; > > - MAY check the OCSP response and abort the handshake if the response > is not satisfactory. For the security considerations: If a client requests an OCSP response, it must take into account that an attacker's server using a compromised key could pretend not to support the extension. In that case it should either try to verify the certificate by some other method (e.g., using OCSP directly, so that this extension is just treated as an optimisation), or its reaction should be the same as if the OSCP response was invalid. In particular, it is *never* reasonable to simply ignore the fact that a server appeared not to support status_request, and proceed anyway. - -- 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 iQEVAwUBOjBvWzkCAxeYt5gVAQHQXwf9G2VMgp8ze1Q/NdBIMGW2HQozOvAxHbkS i9JRNXapfYNZ7v45N/gUBBI2txqYSwTohqsVoGXOIPdzhrhhiecxWxBH/t+I/6CJ NZ3n5QFQnpOZiBXrj1/oHp7kbQ05/dY9ya4Buer/zhuyGkUJ9lvJbz1HhtxAsWmn 7OvIEizFXleuGtoNaVwlhD9KdVy4IeeDIfhyj4jR7vZ8J5kKhC9UnTG9FylOGqhx 8Sj45g5z2i86avLpH4WidUZpkYnm9cUFDJCDtj00wOwPQexxb5Sc5glJgYaYv7AL pcFcNW49mEtLV8wZVsT1c90aoRt8z9jZ94envN4hNkbiKCJTNqB1IA== =vJUh -----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 Dec 8 00:32:31 2000 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 AAA29321 for ; Fri, 8 Dec 2000 00:32:29 -0500 (EST) X-Authentication-Warning: irwell.zetnet.co.uk: Host man-a215.dialup.zetnet.co.uk [194.247.44.215] claimed to be zetnet.co.uk Message-ID: Date: Fri, 08 Dec 2000 05:26:54 +0000 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" Subject: [ietf-tls] Re: I-D ACTION:draft-ietf-tls-wireless-00.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom X-Message-Id: <3A30711E.A7B938CB@zetnet.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Andreas Sterbenz wrote: > > > > For all RFC2246 plus the proposed AES ciphersuites the maximum size of > > > a TLSCiphertext (with null compression) is data size + 5 (header) + > > > 16 (padding) + 20 (MAC), i.e. for max. data 256 bytes this would be > > > 297 byte or required memory. > > > > No, this is not correct. The overall maximum size of a TLSCiphertext > > record would be 5 + 256 + 2048 = 2309 bytes (the MAC is counted in the > > 256 + 2048), unless the amount of extra space allowed for padding is > > reduced. > > You are right about the padding being 256 byte max, but the rest still > holds. The TLS limits do not matter if the ciphersuites used define > tighter limits. I stand corrected - as you say the maximum size is at most 5 + 256 + 256 + 20 = 537 bytes for all currently defined ciphersuites with NULL compression. I was thinking that the TLSCiphertext had to be decrypted before checking the length, but in fact there is no problem (security or otherwise) if an implementation aborts with a decryption_failed alert whenever a TLSCiphertext.length is greater than possible for a valid record. (On a strict reading of the spec, the alert should be record_overflow when the length is > 2^14 + 2048, and otherwise decryption_failed when it is > max_record_size + 512 + mac_size for a block cipher or > max_record_size + 256 for a stream cipher, but it doesn't really matter which alert is used.) Since it took 3 tries for us to arrive at the correct method of determining the maximum size, it must not be obvious, though, so perhaps there needs to be a paragraph in the draft saying that the maximum record sizes depend on the negotiated ciphersuite and compression method, and giving an example. It should also clarify that a fatal decryption_failed *or* record_overflow abort occurs when a record is larger than that. - -- 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 iQEVAwUBOi8iqjkCAxeYt5gVAQFlYwgAy+E3PE9QkzACBH1mvOKBQE3V2lfgO8Ko mSf9Abmhq7pCv3WmN96dKkR9uLZ5C0aq/dpju83cFxWH1WogUZNaWMsz0jz0u8PH PZEbDiFeXgunBvK2ogmxBOZS4LwdvnQYZ/qJcSMqoQHViOfy0IoSHNIsIf3g5YdR cS7Jp1F1/euV/WrSSYATcDcNN9bsz6Cko3tVm7L/FXiTE23ZF0jxxp6ePyapWc00 MtZil8qv3bwQ7xFacZTdI4AMwkLQxyQaJfRnNNRhRDX/Go7gbxSVzaUXLem0tjNg K/GjCBXBKqP/ui6Y1FVGi4zSJtUDO0gScdP8nNmYeL0r0ivozepmWQ== =h2pk -----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 Dec 11 09:13:29 2000 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 JAA25819 for ; Mon, 11 Dec 2000 09:13:28 -0500 (EST) Message-ID: Date: Mon, 11 Dec 2000 14:13:10 +0000 From: Ben Laurie X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: AES outstanding issues 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: <3A34E0F6.B5474A75@algroup.co.uk> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit Pete Chown wrote: > > Okay, these are the outstanding issues that I can see with the AES > draft. Let's go and bang our heads against the wall -- by the time > we've been going for a while we will probably be able to imagine that > there is some kind of consensus! :-) > > 1. Key lengths. I think the options here are: > > a. Do nothing -- have 128-bit key lengths only. > > b. Add 256-bit keys. > > c. Add 192-bit and 256-bit keys. > > What do people think about these choices? I proposed that the > interoperability rules should use 128-bit keys and no one has > raised any objection to this. If you have an objection but have > been too shy, please come forward now... :-) I think at least b, and c if we can be bothered. > 2. Interoperability. Ericsson are concerned that the current > interoperability rules will force mobile devices to support > forward secrecy when they don't have the processing power to do > so. Then they are broken. Forward secrecy should not be optional. We should probably allow consenting adults that don't care to configure it away though. > 3. Block length. I can't see any problem here -- I will just clarify > in the next draft that we are talking about 128-bit blocks. Agreed. 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 Dec 14 00:37:33 2000 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 AAA21266 for ; Thu, 14 Dec 2000 00:37:31 -0500 (EST) Message-ID: From: FRousseau@chrysalis-its.com To: "IETF Transport Layer Security WG" Cc: ietf-pkix@imc.org Subject: [ietf-tls] New Time and Space Based Key Size Equivalents for RSA and Diffie- Hellman Date: Thu, 14 Dec 2000 00:36:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0658F.D7D4218A" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <918C70B01822D411A87400B0D0204DFFAD7CE6@panda.chrysalis-its.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0658F.D7D4218A Content-Type: text/plain; charset="iso-8859-1" I am sorry for the multiple postings, but I thought this particular subject, although probably quite controversial, might be of interest to the many peoples following these mailing lists, especially because of the upcoming adoption of the AES algorithm by many IETF protocols. As symmetric keys grow, they can be attacked by more processors without a change in processor technology since the memory requirements for breaking symmetric keys remain trivial. However, for the Number Field Sieve (NFS) algorithm, which is currently the most efficient method to break RSA keys, this is not true. Based on this premise, the "time and space" based RSA key size equivalents previously published in the RSA Labs Bulletin #13 of April 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently been extended to cover all the AES symmetric key sizes in the latest draft of ANSI X9.44, which will eventually become the ANSI standard for RSA key transport: Time and Space Symmetric Equivalent Key Size RSA Key Size (in bits) (in bits) 64 450 128 1620 192 2500 256 4200 These "time and space" based key sizes equivalents assume that both time and memory are binding constraints in order to break RSA keys. This same draft also indicates that beyond RSA key sizes of 768 bits one can no longer effectively utilize 32-bit processors with the NFS algorithm because the required memory exceeds what can be addressed in 32 bits; one is forced to use 64-bit machines. Beyond RSA key sizes of about 2500 bits, the memory requirements for the NFS algorithm exceed what can be addressed even on 64 bit machines. For your information, here are also the estimated "time" only based RSA key size equivalents for solving the NFS problem from the same ANSI draft: Time Only Symmetric Equivalent Key Size RSA Key Size (in bits) (in bits) 64 512 128 2550 192 6700 256 13500 Note that either of these sets of RSA key size equivalents could be used with Diffie-Hellman for solving the value of "p" since the NFS algorithm is also the most efficient method to break Diffie-Hellman algorithm today. Note also that these time only equivalents numbers are slightly smaller than those from ANSI X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in Hilarie Orman's Internet Draft (i.e. draft-orman-public-key-lengths-01.txt). Shouldn't IETF standards mention these new "time and space" based key size equivalents in addition to existing "time" only based key size equivalents, and possibly even suggest that "time and space" based key size equivalents be used for RSA and Diffie-Hellman? Why mandate larger equivalent key sizes when smaller equivalent key sizes can probably suffice? Food for thought! Cheers, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 --- 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_001_01C0658F.D7D4218A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable New Time and Space Based Key Size Equivalents for RSA and = Diffie-Hellman

I am sorry for the multiple postings, but I thought = this particular subject, although probably quite controversial, might = be of interest to the many peoples following these mailing lists, = especially because of the upcoming adoption of the AES algorithm by = many IETF protocols.

As symmetric keys grow, they can be attacked by more = processors without a change in processor technology since the memory = requirements for breaking symmetric keys remain trivial.  However, = for the Number Field Sieve (NFS) algorithm, which is currently the most = efficient method to break RSA keys, this is not true.  Based on = this premise, the "time and space" based RSA key size = equivalents previously published in the RSA Labs Bulletin #13 of April = 2000 by Robert Silverman (http://www.rsalabs.com/bulletins/) have recently = been extended to cover all the AES symmetric key sizes in the latest = draft of ANSI X9.44, which will eventually become the ANSI standard for = RSA key transport:

        =         =         Time and = Space
Symmetric       =         Equivalent
Key Size        =         RSA Key Size
(in bits)       =         (in bits)

64      =         =         450
128     =         =         1620
192     =         =         2500
256     =         =         4200

These "time and space" based key sizes = equivalents assume that both time and memory are binding constraints in = order to break RSA keys.  This same draft also indicates that = beyond RSA key sizes of 768 bits one can no longer effectively utilize = 32-bit processors with the NFS algorithm because the required memory = exceeds what can be addressed in 32 bits; one is forced to use 64-bit = machines.  Beyond RSA key sizes of about 2500 bits, the memory = requirements for the NFS algorithm exceed what can be addressed even on = 64 bit machines.

For your information, here are also the estimated = "time" only based RSA key size equivalents for solving the = NFS problem from the same ANSI draft:

        =         =         Time = Only
Symmetric       =         Equivalent
Key Size        =         RSA Key Size
(in bits)       =         (in bits)

64      =         =         512
128     =         =         2550
192     =         =         6700
256     =         =         13500

Note that either of these sets of RSA key size = equivalents could be used with Diffie-Hellman for solving the value of = "p" since the NFS algorithm is also the most efficient method = to break Diffie-Hellman algorithm today.  Note also that these = time only equivalents numbers are slightly smaller than those from ANSI = X9.42 for Diffie-Hellman (i.e. 2550 vs 3072 for 128 bits, 6700 vs 7680 = for 192 bits and 13500 vs 15360 for 256 bits) and the numbers in = Hilarie Orman's Internet Draft (i.e. = draft-orman-public-key-lengths-01.txt).

Shouldn't IETF standards mention these new "time = and space" based key size equivalents in addition to existing = "time" only based key size equivalents, and possibly even = suggest that "time and space" based key size equivalents be = used for RSA and Diffie-Hellman?  Why mandate larger equivalent = key sizes when smaller equivalent key sizes can probably = suffice?

Food for thought!

Cheers,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

---
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_001_01C0658F.D7D4218A-- From bounce-ietf-tls-3458737@lists.certicom.com Fri Dec 22 12:14:48 2000 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 MAA07556 for ; Fri, 22 Dec 2000 12:14:46 -0500 (EST) Message-ID: From: FRousseau@chrysalis-its.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Suggested Finished Message Processing Improvement Date: Fri, 22 Dec 2000 12:14:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06C3A.ACEA802A" List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <918C70B01822D411A87400B0D0204DFF72F58A@panda.chrysalis-its.com> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C06C3A.ACEA802A Content-Type: text/plain; charset="iso-8859-1" At the San Diego IETF meeting, Win Treese indicated that if anyone wanted to suggest minor changes to the TLS protocol, now was our last chance to submit them before it would advance to a Draft Standard. I am not sure if this is what Win intended or if it was ever discussed on this mailing list before, but here is a suggested change for the "finished message" to improve its processing, especially on the server side. As you know, Section 7.4.9 of RFC2246 mandates that the handshake_messages for the finished message must include the concatenation of all the data from all messages up to but not including this message. From all the messages in the handshake_messages, the optional server certificate message, which is a static message from the server, is always the largest of the handshake protocol. We would like to suggest that for the server certificate message, instead of using the whole certificate message in the handshake_messages, it would be more efficient to only include the appropriate hash of the certificate message (e.g. MD5 and SHA-1). These two hashes of the server certificate message could always be pre-compute by a server and easily be computed by clients for the optional client certificate verify message and the client own finished message. The benefit of this approach is the fact that a server could cache these two hashes of its server certificate message. Then for each session with a client, a server would only need to compute the two hashes needed for the verify_data from all the other shorter messages with the appropriate hash of its server certificate message. The finished message could then look like this: struct { opaque verify_data[12]; } Finished; verify_data PRF(master_secret, finished_label, MD5([[MD5(certificate)]] + handshake_messages) + SHA-1([[SHA-1(certificate)]] + handshake_messages)) [0..11]; finished_label For Finished messages sent by the client, the string "client finished". For Finished messages sent by the server, the string "server finished". handshake_messages All of the data from all handshake messages up to but not including this message and the optional server certificate message. This is only data visible at the handshake layer and does not include record layer headers. This is the concatenation of all the Handshake structures as defined in 7.4 exchanged thus far. certificate The optional server certificate message. It is a fatal error if a finished message is not preceded by a change cipher spec message at the appropriate point in the handshake. The hash contained in finished messages sent by the server incorporate Sender.server; those sent by the client incorporate Sender.client. The value handshake_messages includes all handshake messages starting at client hello up to, but not including, this finished message and the server certificate message. This may be different from handshake_messages in Section 7.4.8 because it would include the certificate verify message (if sent). Also, the handshake_messages for the finished message sent by the client will be different from that for the finished message sent by the server, because the one which is sent second will include the prior one. Note that as indicated above, the client certificate verify message under Section 7.4.8 would similarly be impacted by this suggested change since it also uses the handshake_messages. The syntax of md5_hash and sha_hash could then become: CertificateVerify.signature.md5_hash MD5([[MD5(certificate)]] + handshake_messages); Certificate.signature.sha_hash SHA([[SHA-1(certificate)]] + handshake_messages); certificate The optional server certificate message. handshake_messages All handshake messages sent or received starting at client hello up to but not including this message and the server certificate message, including the type and length fields of the handshake messages. This is the concatenation of all the Handshake structures as defined in 7.4 exchanged thus far. Finally, the client and server finished messages when a client and server resume a previous session would not be impacted. What do others thing of this suggested change? Merry Xmas and Happy New Year, Francois ___________________________________ Francois Rousseau Director of Standards and Conformance Chrysalis-ITS 1688 Woodward Drive Ottawa, Ontario, CANADA, K2C 3R7 frousseau@chrysalis-its.com Tel. (613) 723-5076 ext. 419 http://www.chrysalis-its.com Fax. (613) 723-5078 --- 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_001_01C06C3A.ACEA802A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suggested Finished Message Processing Improvement

At the San Diego IETF meeting, Win Treese indicated = that if anyone wanted to suggest minor changes to the TLS protocol, now = was our last chance to submit them before it would advance to a Draft = Standard.

I am not sure if this is what Win intended or if it = was ever discussed on this mailing list before, but here is a suggested = change for the "finished message" to improve its processing, = especially on the server side.

As you know, Section 7.4.9 of RFC2246 mandates that = the handshake_messages for the finished message must include the = concatenation of all the data from all messages up to but not including = this message.  From all the messages in the handshake_messages, = the optional server certificate message, which is a static message from = the server, is always the largest of the handshake protocol.  We = would like to suggest that for the server certificate message, instead = of using the whole certificate message in the handshake_messages, it = would be more efficient to only include the appropriate hash of the = certificate message (e.g. MD5 and SHA-1).  These two hashes of the = server certificate message could always be pre-compute by a server and = easily be computed by clients for the optional client certificate = verify message and the client own finished message.

The benefit of this approach is the fact that a = server could cache these two hashes of its server certificate message. = Then for each session with a client, a server would only need to = compute the two hashes needed for the verify_data from all the other = shorter messages with the appropriate hash of its server certificate = message.

The finished message could then look like = this:

   struct {
       opaque = verify_data[12];
   } Finished;

   verify_data
       = PRF(master_secret, finished_label, MD5([[MD5(certificate)]] +
       = handshake_messages) + SHA-1([[SHA-1(certificate)]] +
       = handshake_messages)) [0..11];

   finished_label
       For Finished = messages sent by the client, the string "client
       finished". = For Finished messages sent by the server, the
       string = "server finished".

   handshake_messages
       All of the data = from all handshake messages up to but not
       including this = message and the optional server certificate
       message. This = is only data visible at the handshake layer and
       does not = include record layer headers. This is the
       concatenation = of all the Handshake structures as defined in
       7.4 exchanged = thus far.

   certificate
       The optional = server certificate message.

   It is a fatal error if a finished = message is not preceded by a change
   cipher spec message at the appropriate = point in the handshake.

   The hash contained in finished messages = sent by the server
   incorporate Sender.server; those sent = by the client incorporate
   Sender.client. The value = handshake_messages includes all handshake
   messages starting at client hello up = to, but not including, this
   finished message and the server = certificate message. This may be
   different from handshake_messages in = Section 7.4.8 because it would
   include the certificate verify message = (if sent). Also, the
   handshake_messages for the finished = message sent by the client will
   be different from that for the finished = message sent by the server,
   because the one which is sent second = will include the prior one.

Note that as indicated above, the client certificate = verify message under Section 7.4.8 would similarly be impacted by this = suggested change since it also uses the handshake_messages.  The = syntax of md5_hash and sha_hash could then become:

   = CertificateVerify.signature.md5_hash
       = MD5([[MD5(certificate)]] + handshake_messages);

   Certificate.signature.sha_hash
       = SHA([[SHA-1(certificate)]] + handshake_messages);

   certificate
       The optional = server certificate message.

   handshake_messages
       All handshake = messages sent or received starting at client
       hello up to but = not including this message and the server
       certificate = message, including the type and length fields of
       the handshake = messages. This is the concatenation of all the
       Handshake = structures as defined in 7.4 exchanged thus far.

Finally, the client and server finished messages when = a client and server resume a previous session would not be = impacted.

What do others thing of this suggested change?

Merry Xmas and Happy New Year,

Francois
___________________________________
Francois Rousseau
Director of Standards and Conformance
Chrysalis-ITS
1688 Woodward Drive
Ottawa, Ontario, CANADA, K2C 3R7
frousseau@chrysalis-its.com      Tel. = (613) 723-5076 ext. 419
http://www.chrysalis-its.com   &nbs= p; Fax. (613) 723-5078

---
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_001_01C06C3A.ACEA802A-- From bounce-ietf-tls-3458737@lists.certicom.com Fri Dec 22 13:26:34 2000 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 NAA09804 for ; Fri, 22 Dec 2000 13:26:31 -0500 (EST) Sender: bounce-ietf-tls-3458737@lists.certicom.com To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvement 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: 22 Dec 2000 10:30:35 -0800 In-Reply-To: FRousseau@chrysalis-its.com's message of "Fri, 22 Dec 2000 12:14:42 -0500" 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 FRousseau@chrysalis-its.com writes: > What do others thing of this suggested change? While one might argue that this would be an improvement, it would completely break existing implementations and would therefore require changing the version number and quite possible recycling to Proposed. Doesn't seem worth it to me. -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 Dec 22 14:03:06 2000 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 OAA10699 for ; Fri, 22 Dec 2000 14:03:05 -0500 (EST) Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Fri, 22 Dec 2000 12:02:44 -0700 From: "Baber Amin" To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvement 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: 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 OAA10699 I agree, it will break existing implementation and add extra code paths, which as we all know always adds bugs :) Baber Amin >>> ekr@speedy.rtfm.com 12/22/00 11:30AM >>> FRousseau@chrysalis-its.com writes: > What do others thing of this suggested change? While one might argue that this would be an improvement, it would completely break existing implementations and would therefore require changing the version number and quite possible recycling to Proposed. Doesn't seem worth it to me. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ --- You are currently subscribed to ietf-tls as: BAMIN@novell.com To unsubscribe send a blank email to leave-ietf-tls-3174427R@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 Dec 22 14:03:20 2000 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 OAA10710 for ; Fri, 22 Dec 2000 14:03:20 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 22 Dec 2000 14:03:05 -0500 (Eastern Standard Time) From: Paul Koning To: "IETF Transport Layer Security WG" Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvement X-Mailer: VM 6.75 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid List-Unsubscribe: List-Subscribe: List-Owner: X-List-Host: Certicom Reply-To: "IETF Transport Layer Security WG" X-Message-Id: <14915.42345.963000.589531@gargle.gargle.HOWL> Sender: bounce-ietf-tls-3458737@lists.certicom.com X-List-Host: SKYLIST.net Content-Transfer-Encoding: 7bit I tend to agree with Eric that this is probably not a good time to make incompatible protocol changes. At the risk of being told to go back to the archives, I'll add another comment... there seems to be a fair amount of opportunity for removing computational complexity from the protocol. Right now it is very heavily biased to throwing lots of cryptographic functions into the mix to be very sure that there aren't weaknesses. Other protocols (e.g., IKE) are much more minimalist, for example they never hash the same stuff with two hash algorithms. Rather than tweak a single bottleneck now, how about revisiting things more globally for TLS V2.0? paul --- 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