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

Re: speaking of keys

At 10:49 AM -0500 12/11/02, Michael Richardson wrote:
-----BEGIN PGP SIGNED MESSAGE-----


"David" == David Wagner <daw@xxxxxxxxxxxxxxxxxxxxxx> writes:
David> But is it too small for the MUST requirement in the RFC?

David> As I see it, we have to balance two costs here. If we require a
David> 1024-bit modulus, there is a risk it will get broken in our lifetime.
David> If we require a 2048-bit modulus, some people will not use IPSEC because
David> it is too slow (this is not just a risk; this is for sure). How do we
David> balance these two?

  I don't understand this argument. MUST doesn't mean that you have to use it
in an exchange, it means that you must support it. The purpose of the MUST is
to encourage interopability. It doesn't have to the fastest, nor the
cheapest. It has to be there for the long term.

I have to disagree slightly. We can only rely on vendors to implement the MUSTs, by definition, for any standard. Thus it is reasonable for users to generally default to the MUSTs (algorithms, modes, key lengths, ...) to ensure interoperability. I realize that there are exceptions to this, but if we choose a single MUST value that we all agree would be secure long term, then we should expect people will use only it, consistent with Paul Hoffman's observation about VPN products.

If we choose more than one MUST value, then we should be able to rely on interoperability on either value, and people at least have an ability to pick one as a default. My original concern was that they might default to the biggest value (on the "bigger is better" theory of operation) and then we would get bad press re the expense of IPsec/IKE.

Maybe we can't avoid this, but that was the concern I originally voiced. Another way of approaching this might be to mandate support for larger group sizes, but not yet mandate support for SPECIFIC groups at these larger sizes. That way user communities would be free to choose groups at bigger sizes and be assured of interoperability among various vendor products, but we could avoid creating defaults that we know users would select mindlessly.

I am comfortable with mandating the current 1024 group because it is so widely used in existing IPsec implementations that this would be a good default in terms of ensuring interoperability in a backwards compatible context. If we mandate a specific 1500ish bit group, that would seem reasonable for folks who are concerned about the entropy of 1024-bit groups, based on what I have seen on this thread. Anything bigger could be selected as a private group for use in a community that feels that it needs a bigger key size and is comfortable with the performance implications based on their set of implementations. In any case, so long as we mandate that larger groups up to some size can be supported by the underlying software/hardware, user communities are free to select such groups and be confident that their implementations will work (if we mandate suitable management interfaces to enable this ...).


  If you are building a system where you control all components you may
configure it anyway that you like. So, if Verizon's new IP-mobile-phone needs
to use 1024 bit moduli, and they won't let me use a third party handset, they
can do what they like.

  Now, if asking for 1536 or 2048 bit moduli causes the software to always
use more resources than you can afford (i.e. 256 byte buffers for bignums
rather than 128 byte buffers), then this is a problem. Is that really a
concern here?

That is one possible concern. In developing this standard we have a delicate balancing act. On one hand we don't want to impose constraints that would impede high speed hardware implementations, but on the other hand we also don't want to impose undue burdens on software either.

Steve