Re: speaking of keys

[Michael Richardson <mcr@sandelman.ottawa.on.ca>]

-----BEGIN PGP SIGNED MESSAGE-----


>>>>> "Stephen" == Stephen Kent <kent@bbn.com> writes:
    Stephen> I have to disagree slightly. We can only rely on vendors to implement 
    Stephen> the MUSTs, by definition, for any standard. Thus it is reasonable for 
    Stephen> users to generally default to the MUSTs (algorithms, modes, key 
    Stephen> lengths, ...) to ensure interoperability. I realize that there are 

  While I don't disagree with any of your words, I think that you are making
too strong a case here. i.e. overconstraining us. The key missing word is:

  "Thus it is reasonable for users to generally default to the MUSTs
   to ensure interoperability without pre-arrangement. "
                              ^^^^^^^^^^^^^^^^^^^^^^^

  IPsec, as used in VPNs, is not like TCP as used by SMTP, (or TLS as used in
HTTPS). In a VPN, you are generally dealing with nodes that are there by
*pre-arrangement*. Therefore, you can have things like policy MIBs/PIBs, and
pre-configured root CAs for the certificates, etc..
  I've said this before, and I'll say it again - I strongly think that we
would make a lot more progress in the *IPsec* WG (whose job it is to produce
tools, not solutions) if the VPN folks would write a VPN-profile of IPsec. 
  It doesn't have to be long, but it can have things like:
     You MUST support 1024 bit DH
or   You MUST support CRMF (to pick a random PKIX acronym)
     ...
 
  To my knowledge, the only place where IPsec is being used without
pre-arrangement is in FreeS/WAN's Opportunistic Encryption, and we are very
specific in saying what our profile our IPsec is.
  
  To a large extent, I don't know if any parameter type MUSTs are really
appropriate in either the base RFC2401 or base IKE drafts. I would much
prefer that they were in specific profiles of IPsec.

  But, if we are putting MUSTs into the standard, then they are there for
interoperability *without pre-arrangement*. That excludes pretty much *ALL*
VPNs uses. 

  Arguing over whether or not 80 or 128 bits of entropy is enough to key AES
out of any context of the data that is being protected is really bizarre.
  You just do not prescribe security that way - how are we to say what
appropriate cost is when we have no definition of risk or benefit?

  I really think that the rest of your message gets trapped into this mindset.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Finger me for keys

iQCVAwUBPgS/SoqHRg3pndX9AQF/4gP8DaK/f6uhHrRlsTtyDBnjwV0HmUO6ZKoU
PCAqVacxSSdUsm1rkNrQKIciT7aqYSsRZIh4+VTWysZ72FLa1JGb7/IJ3wnqW6lz
MP+e86mnpe6jrcGh9W0t3eACNdzA7bTn4TA6cpK1OI4a3BJ4zvqnK3v+byDUOWhV
/cKrCOcDKW8=
=18NU
-----END PGP SIGNATURE-----