[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@mozart.cs.berkeley.edu> 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