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

Re: speaking of keys

At 4:09 PM -0500 12/6/02, Michael Richardson wrote:
-----BEGIN PGP SIGNED MESSAGE-----


"Stephen" == Stephen Kent <kent@xxxxxxx> writes:
Stephen> Also, let's remember that the key size is not the only factor in
Stephen> determining the security of these systems. It's tempting to raise

Absolutely.

Stephen> software implementation on a user WS/laptop where there are lots more
Stephen> likely ways that the security of the traffic will be compromised
Stephen> (other than solving the discrete log problem for a 1024-bit group)
Stephen> and where the performance hit will be most visible and thus may
Stephen> eventually motivate an individual to NOT use IPsec at all.

  I think that we can write a MAY for a smaller size (i.e. 1024).
  The reason to pick something for the MUST is interoperability. That is the
only reason.

Stephen> I don't have a problem with a MAY for bigger groups, but I really
Stephen> think it is most appropriate to focus on the management facility to
Stephen> allow user communities to select their own, of whatever size they
Stephen> feel is appropriate.

It has been a long time since anyone has talked about APIs.

  Bill Sommerfeld has promised to take us (IPSP specifically) down that path
again, and it is high time that we do this. I do not think that applications
writers should have to deal with DH modulus size. I think that we should have
a direct mapping that gives minimum modulus sizes for particular levels of
security.


Michael,

I don't think we need an API here, although that might be nice long term. What we need is a set if MUSTs in IKE v2 that mandate the provision of (local?) management controls over the specification of DH groups, not just the ones already specified. We have provisions in IKE for passing group parameters, but I have been told that they are not generally supported, and thus rarely if ever used. For my purposes, I would be happy with a way for a community to specify the parameters and inserts them into all of the community members' systems via a management interface, and then use a locally managed (but globally unique) ID, e.g., an OID, to refer to the parameters. However, I realize that this would not be supportive of the opportunistic encryption model you have proposed, so maybe this approach is not sufficient for all.

Steve