[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