[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: swIPe stuff


  *> From kent@BBN.COM Tue Mar  1 08:21:08 1994
  *> To: "Perry E. Metzger" <pmetzger@lehman.com>
  *> Cc: Phil Karn <karn@qualcomm.com>, iab-retreat@ISI.EDU, mobile-ip@ossi.com,
  *>         ipsec@ans.net
  *> In-Reply-To: Your message of "Mon, 28 Feb 1994 17:02:49 EST."
  *>              <199402282206.RAA16535@lehman.com> 
  *> Subject: swIPe stuff
  *> Date: Tue, 01 Mar 94 10:58:25 -0500
  *> From: Steve Kent <kent@BBN.COM>
  *> Content-Length: 1595
  *> X-Lines: 31
  *> 
  *> Perry,
  *> 
  *> 	The IAB policy on cryptography is consistent with the general
  *> thurst of your observation, i.e., we have adopted a stance that calls
  *> for the use of cryptography to provide high quality security as
  *> applicable throughout the Internet, irrespective of national policies.
  *> However, mindful of international (not just U.S.) controls (export and
  *> internal use) on crypto, we also suggest using crypto in a focused
  *> way.  Thus, where crypto for authentication/integrity can achieve
  *> security goals and encryoption for confidentiality is not required, we
  *> advocate use of crypto in the former fashion.  Some countries are more
  *> restrictive about what forms of crypto their citizens can easily use
  *> within their own country.  Not calling for crypto for confidentialtiy
  *> where crypto for authentication and integrity will suffice facillitates
  *> interoperable, international communication.
  *> 
  *> 	In terms of integrity checks, my point was that strong checks,
  *> e.g., hashes, are really required.  This is not what we put in non-
  *> security protocols, and so use of encryption without security-
  *> oriented integrity checks is dangerous.  Use of the integrity checks
  *> alone is a good approach for circumstances where confidentiality is

Dr. Kent,

Good approach to what?

  *> not required.  
  *> 
  *> 	As for OFB being a strange case, use of CBC has a different,
  *> but analogous set of problems for the last enciphered block.  Even a
  *> mode like CBC has some subtle vulnerabilities, if used with a weak
  *> integrity check like the IP checksum.  The best bet is use of a good
  *> hash function, either in conjunction with encryption, signed, or with
  *> a secret seed quantity.
  *> 
  *> Steve
  *> 

Sorry, I must have dozed off there somewhere, I have lost track of
what the discussion is about.

Bob Braden
Follow-Ups: