Date: Sat, 24 Jun 95 01:05:27 -0400 From: "Phillip M. Hallam-Baker" To: hallam@w3.org, crypto-security-reading-group@theory.lcs.mit.edu, rogaway@cs.ucdavis.edu Subject: Re: IPSEC proposal I've not had time to go through the specifics yet but comments on the comments seem in order:- > RECOMMENDATION 1: Remove all mention of (message) "integrity" and > speak only in terms of (message) authenticity. In the absence of an established framework of trust integrity can mean very little. > 2. ENCRYPTION DOES NOT GUARANTEE INTEGRITY This was the bug in SSL which lead to the initial simplistic suggestion to be abandoned. The SSL spec is now longer than the S-HTTP spec which it is suposedly the simplification of. Why do people writing socket level stuff seem to think they can get an encryption mechanism to get them authenticity? If it takes X bits to transport the message they must expect to send at least one extra bit to convey the assertion that it is genuine. Since they probably want more than a 50% random chance they should expect to pay at least 128 bits like everyone else and not try to be cheapskates. > 3. IT IS WORTHLESS TO ENCRYPT KNOWN HEADERS Isn't this worse than that? Its like a gift of free known plaintext. This is the sort of stuff the Brits created "gardening" for. They went so far as to lay mines at known grid locations where they knew the NAZis would find them so they could use the message to break the days cipher. > RECOMMENDATION 3: Modify the architecture to forbid or deprecate > the encryption of known headers. FORBID IT STRONGLY ! > 4. DON'T ENCRYPT MESSAGE AUTHENTICATION CODES > RECOMMENDATION 4: Mandate that, when an ESP and an AH are both > used, the scope of the authentication includes the encrypted > packet (and not vice versa). This is lossage of high order that derrives from an old PEM idea. They were obsessed with various tunnelling and gatwaying type ideas and wanted to be able to encrrypt stuff which had previously only been signed. The thing I never understood is why it should be prohibitted to know that an encrypted document was genuine. I can think of many cases where its usefull to know that a document is genuine even if one is not allowed to open it. It might possibly derrive from some limitations in RSAREF concerning what can be signed. I can't remember offhand if signing could be restarted as encryption could. Since I'm no longer outside the USA I don't have access to RSAREF anymore. > RECOMMENDATION 5: Describe cryptographic transforms completely > independently of their intended usage. Any "parent" document (the > user of a transform) is responsible for specifying how to to use > an arbitrary transform (of the proper signature) to carry out its > business. > > It is easy to dismiss the above recommendation as "organizational." Most of programming is organisational. One has to organise the idea that took five minutes to think up into code, hopefull not taking too many months in the process. > I worry about the process by which cryptographic mechanisms emerge > and get standardized. A committee can not do good cryptographic > design. Reading [Schneier] does not qualify one to do cryptographic > design. A set of requirements should be understood and then propos- > als should be sought (from the few relevant people) responsive to > those requirements. I'd like to suggest another condition. One cannot do good design if one tries to comunicate in the wrong language. ASCII is not the right language to discuss cryptography. I have direct experience of the problems that trying to explain things by email in straight ASCII create. There was quite a confusion caused by two people having different ideas of what H(x) implied, both of which were entirely logical interpretations of the texts. The IETF approach is still that ASCII was good enough to build the ARPAnet, FTP and the Pyramid of Cheops. Therefore we must stick to it in the days of bit mapped graphics displays in case there is a Texan running ITS on a PDP3 at the end of a 300 baud dialup he wirewraped by hand. The problem is that I'm not immediately sure what is meant by : >Recall that it went from MAC_a(x) = MD5(a.x.a) to MAC_a(x) = MD5(MD5(x).a). After a few minutes I can make sense of it. But if we must use an ASCII only syntax lets use one that works, such as LISP. The parentheses of LISP are simply the price one pays for not having an adequate presentation mechanism. Trying to do ASCII mathematics is a disaster. It can work for small sections of equations but for large blobs o' code its a reall hazard. In the same way I'm still looking for an RFC to manage to give a correct grammar for some RFC822 type headers. >It makes one wonder: are we on a path which > will lead to meaningful and scientific standards -- or are people > just guessing? I introduced a similar change into the Message Digest Authentication spec for HTTP. The reason was to allow passwords to be used to create a shared secret that was salted both by username and host. The mechanism simply provides an advanage when implementing the system. Its possible that somone had a bright idea to carry over the same change but I can't see it being of any use. [I think that we should seriously think about allowing SHA as the hash mechanism. After all won't everyone soon have a Fortessa card to do this in hardawre?] This si very troubling if someone can come up with 10 good objections to a protocol then there are quite likely many more still to be found. Maybe even a really glaring error nobody has noticed amongst all the details. My main worry is that the next IETF is in Stockholm and there are not going to be many attendees. However we do have a lot of Web type crypto people going to talk about payment schemes. I think that the best way to stop this juggernaut is to come up with something to throw the train off the tracks till the next conference. Phill H-B To: rivest@theory.lcs.mit.edu Subject: Comments on the IPSEC Internet drafts. (interim fix) Date: Fri, 30 Jun 1995 03:53:33 -0400 From: Phillip Hallam-Baker Ron, This is an attempt to frame comments on the IPSEC note. I have tried to avoid conclusions which point to substantial delays and emphasised editing changes as opposed to major architectural overhauls. This is because the more minor the fault discovered in the specification the more likely it is that it will be considered. http://www.w3.org/hypertext/WWW/Security/ipsec_comments.html Its amazing the difference that emphasis alone makes to the readability of the document. If it were permitted to use algebraic notation it is probable that the initial spec would have been of the same quality as Amir's IKP paper. I also tried to avoid the note looking too much like an electronic petition letter and so have deliberately not commented on all Phil's proposals nor mentioned any other input. Might as well make use of the fact that the proximity of offices is not immediately apparent from MIT/W3C internet domain names. Oh well, no time to write something better. I also had a go at writing a more comprehensive treatment of the keyed digest problem. So far I've not got much further than drafting out various threat tree and constraint network type analysis. I need a notation for constraint networks which allows the concept of "computationaly hard" to be incorporated. I'm looking at a labeled graph at the moment but its easier to do it on paper than in digital form thus far. I'm drafting out the comments as a specification for a KD "Keyed Digest" series of specs. Since there is no time for something better I'm sticking to common use and the cryptobytes modes. If possible I'd like to get a draft out in time for Stockholm, the cloosing period being a week away. By suggesting KD1...KD6 there is an implication of a series that might incorporate say a KD7 being a dedicated keyed digest function. Its a placeholder draft designed to wedge a door open rather than be a finished specification. http://www.w3.org/hypertext/WWW/Security/keyed_digest.html I'll stick in a few GIFs with the constraint graph pictures in at some point. Phill - ---------------------------------5721460332053 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 Comments on the IPSEC Internet drafts. Dr Phillip M. Hallam-Baker World Wide Web Consortium This document is available as hypertext at the following URL: http://www.w3.org/hypertext/WWW/Security/ipsec_comments.html This is in response to the call for comments on the following internet draft proposals: draft-ietf-ipsec-arch-02.txt, draft-ietf-ipsec-auth-02.txt, draft-ietf-ipsec-esp-01.txt, draft-ietf-ipsec-ah-md5-03.txt, draft-ietf-ipsec-esp-des-cbc-04.txt Executive summary I believe that these documents require further work before they are ready for adoption as proposed standards. The documents as currently written define a framework that is insufficiently generic. Introduction This response was in art stimulated by comments made by Phil Rogaway in his note: draft-rogaway-ipsec-comments-00.txt It is worth noting in passing that ASCII text is a sub-optimal means of expressing cryptographic systems. The ambiguity of natural language renders it a cumbersome notation for what are essentially mathematical concepts. Many of the problems with the drafts would almost certainly had been rectified at an earlier stage if the means of expression had permitted a more rigorously algebraic approach. Natural language encourages reference to specific examples rather than concentration on the high level abstractions crucial to the task. Conspicuously lacking from the standards documents is a grounding of the concepts in a well developed formalism such as the specification languages Z or VDM. It is to be hoped that future standards development will recognize the significant advantages that a well chosen and appropriate notation for discourse provides and that plain ASCII text alone is not such a notation. If ASCII text does not permit adequate expression of such notations that should be considered a reason to consider another form of notation and not a reason not to employ such an analysis. Use of a message digest function for authenticity checking. The specifications auth-02 and ah-md5-03 imply that a message digest function should be used to ensure authenticity. This makes two questionable assumptions. First that such a use is an appropriate use of a digest function and second that digest functions are appropriate for this task. A message digest is a function of a single variable, a keyed digest is a function of two variables. It is clearly undesirable to confuse the two. The use of a digest function and a shared secret to produce a symmetric key secret function is a relatively new concept, one that has received little attention in the literature. Most cryptographic digest functions have been designed as an adjunct to a public key signature scheme. Such use makes flaws such as a possibility of an extension attack unimportant. When applying a cryptographic component designed with one purpose in mind for a different purpose careful evaluation of the new requirements is essential. Even if a mode of use of a message digest function has the necessary properties for security it does not follow that such use is appropriate. It is probable that an algorithm specifically designed for the purpose of ensuring authenticity would be more satisfactory. The construction of a keyed digest function from cryptographic primitives such as hash functions and ciphers is in general concerned with preventing the exploitation of specific weaknesses in specific algorithms. As a consequence it is not useful to separate consideration of the underlying hash function from the mode of operation employed to construct a keyed digest function. It is therefore considered undesirable to specify modes of operation for cryptographic primitives in a manner analogous to DES. Although such a modular approach would be of assistance in building libraries the security of M1(H1) and M2(H2) does not imply the security of M1(H2) or M2(H1). On the specific keyed digest mechanism proposed There is at present no known attack against MD5 which renders it unsuitable for keyed digest use. It is however susceptible to two specific forms of attack, an extension attack and an attack on the internal compressor function which may be used to synthesize collisions. In such circumstances a decision to base IP security on a theoretically untested mode of operation of this specific algorithm might be considered a brave step. Alternative keyed digest algorithms. I do not propose to suggest an alternative keyed digest algorithm within the timeframe for responses to the standards documents nor even to provide a complete statement of requirements for such an algorithm. I believe however that it is better that it is better to mention no keyed digest mechanism in the architectural documents at the present time rather than mandate all implementations to implement an algorithm that has at best no strong foundations in the proposed mode of usage and at worst may be suspect. It is clearly desirable that a keyed digest function be resistant to extension attacks and have no known weaknesses such as the MD5 compressor function attack. Additionally it is desirable that the key be involved in the calculation process throughout the digest process. This may be considered an aesthetic requirement, that the calculation process should be symmetric involving commensurate calculations on both inputs. Proposal: The IPSEC architecture should be phrased in terms of a fast symmetric key signature mechanism rather than assume that a generic hash function should be employed for this purpose. This proposal corresponds to a strong endorsement of Rogaway's recommendation number 5. Encryption of known plaintext. Cryptanalysis using known or chosen plaintext is considerably easier than direct attack. Encryption of known headers is thus clearly undesirable since it provides a direct route to formation of a known plaintext attack and may open a route to construction of a chosen plaintext attack. A specific form of attack must be considered which exploits weaknesses in multiple cryptographic components. If for example a system employed related keys to ensure encryption and authenticity a chosen plaintext attack on the privacy component might provide information to compromise the authenticity mechanism. Proposal: Encryption of known headers should be prohibited. This proposal corresponds to a strengthening of Rogaway's recommendation number 3. Encryption of message digests. The encryption of message digest functions of encrypted text should be considered undesirable. Consider the difficulty of solving the the following constraint set for m: * e = E (k, m) * d = E (k, H(m)) Compared to the difficulty of solving for m in the following case: * e = E (k, m) * d = H (E (k, m)) In the first case we have two independent equations in m. In the second only one. It is possible therefore for the second mode of operation to provide unconditional security in certain situations (e.g. m is an unknown genuinely random value fewer bits in length than the key) whereas this is not possible in the first case. Proposal: It is proposed that the scope of any digest function should encompass the encrypted text and not vice versa. This proposal corresponds to a strengthening of Rogaway's recomendation number 4. Key sizes A limitation of key sizes to 64 bits may be considered in future to be the cryptographic equivalent of the original Arpanet decision to limit addresses to 32 bits. I concur with Rogaway's proposal that the key sizes of at least 128 bits should be permitted. I prefer Rivest's proposal that key sizes should be arbitrary or subject to a generous limit. Attack model It is important that the security assurances of the system be understood. Two tools for analyzing such assurances are threat trees and constraint networks. It is strongly advised that such analysis be performed. The construction of threat trees from a taxonomy of risks is a well established technique for constructing an attack model for a system. Such an analysis has been of great assistance to the author in consideration of transaction level protocols. A common reason for failure of cryptographic systems is the creation of unintended correlations between components which although individually secure fail in particular combinations. An example of this being the DES-CBC TIC mode in PM. Such unintended correlations may often be uncovered by construction of constraint networks corresponding to the data structures and algorithms employed. Such an analysis is most effective if subjected to automated verification. Summary of proposals. * Eliminate references to message digest functions where a keyed digest usage is actually intended. * Do not encrypt known headers. * Do not specify public constraints on encrypted objects, specifically do not incorporate message digests of message plaintext even if these are encrypted. * Allow arbitrary key sizes. * A comprehensive attack model consisting of as a minimum threat tree and constraint network analysis should be compiled. In addition it is strongly recommended that even if IETF procedures insist on the precedence of ASCII text renditions of specification documents that a document detailing the architecture in algebraic terms be compiled. - ---------------------------------5721460332053-- ------- End of Forwarded Message