Re: speaking of keys

[Stephen Kent <kent@bbn.com>]

At 4:09 PM -0500 12/6/02, Michael Richardson wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>
>>>>>>  "Stephen" == Stephen Kent <kent@bbn.com> 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