[Hipsec] Digital Signature Algorithms

So, what people think? We have (at least) four alternatives:

1) Stay at current: DSA mandatory

2) Both DSA and RSA mandatory

3) DSA mandatory, RSA SHOULD

4) Change the mandatory to RSA

Opinions?

/petri

Jari Arkko wrote:
> I'd be fine with just one algorithm (for now).
> And my slight preference for that algorithm is
> RSA...
> 
> --Jari
> 
> Julien Laganier wrote:
> 
>> On Wednesday 13 October 2004 08:02, Pekka Nikander wrote:
>>
>>>> So how does people feel about making both DSA and RSA mandatory
>>>> in HIP?
>>>
>>>
>>> I don't have any strong opinions.  IIRC, the usual IETF crypto
>>> guidelines state that
>>>
>>>   a) there must be at least one common MUST implement
>>>      algorithm that is considered secure enough
>>>
>>>   b) the algorithms must be negotiable so that if the
>>>      currently MUST implement turns out to be insecure,
>>>      the implementations can be easily upgraded to use
>>>      some other, new MUST implement algorithm
>>>
>>> Anyone care to check what the guidelines and other
>>> documents actually say?
>>>
>>>   draft-ietf-ipsec-ikev2-algorithms-05.txt
>>
>>
>>
>> This one doesn't talk about RSA or DSS (only DH, PRF and HMAC). RSA 
>> and DSS usage seems to be both MUST in draft-ietf-ipsec-ikev2-17.txt.
>> However, an interesting thing is the new requirements keywords defined 
>> in draft-ietf-ipsec-ikev2-algorithms-05.txt:
>>
>> SHOULD+            This term means the same as SHOULD. However it is
>>                    likely that an algorithm marked as SHOULD+ will be
>>                    promoted at some future time to be a MUST.
>> SHOULD-            This terms means the same as SHOULD. However an
>>                    algorithm marked as SHOULD- may be deprecated to a
>>                    MAY in a future version of this document.
>> MUST-              This term means the same as MUST. However we
>>                    expect at some point that this algorithm will no
>>                    longer be a MUST in a future document. Although
>>                    its status will be determined at a later time,it
>>                    is reasonable to expect that if a future revision
>>                    of a document alters the status of a MUST-
>>                    algorithm, it will remain at least a SHOULD or a
>>                    SHOULD-.
>>
>>
>>>   draft-iab-auth-mech-03.txt
>>
>>
>>
>> It said:
>>
>> --------------------
>> While the desire to support legacy authentication systems is under-
>> standable, it should be resisted to the extent possible. Having mul-
>> tiple equivalent mechanisms dramatically increases both implementa-
>> tion complexity and interoperability problems. When designing a new
>> system, designers should choose a very small number of authentication
>> mechanisms, with no more than one of any given class.
>> --------------------
>>
>> And later
>>
>> --------------------
>> 13.2. Use As Few Mechanisms as You Can
>>
>> Preferably, systems should have only one form of authentication. The
>> more methods of authentication a system allows, the more things there
>> are to go wrong. Remember that a chain is only as strong as its weak-
>> est link. In general, there are two reasons why systems allow more
>> than one authentication mechanism. The first is that you're
>> retrofitting a system which already has a large number of authentica-
>> tion mechanisms which cannot be displaced. The second is that users
>> have widely different environments which for some reason cannot use
>> the same authentication mechanism conveniently (e.g. some users have
>> tokens and some do not).
>>
>> Naturally, designers need to take such considerations into account
>> but they should take reasonable steps to minimize the number of mech-
>> anisms. Designers should take special care to minimize the number of
>> equivalent mechanisms. For instance, a system that provides a chal-
>> lenge/response mechanism and a public key based mechanism is a rea-
>> sonable design, one that provides three different challenge/response
>> mechanisms is not.
>>
>> This doesn't mean that designers should not use security frameworks
>> where multiple mechanisms are appropriate, but it does mean that they
>> should be avoided unless necessary. Where generic security frameworks
>> are used, they supported mechanisms should be carefully profiled to a
>> minimal set.
>> --------------------
>>
>>
>>>   crypto forum?
>>
>>
>>
>> I can ask them.
>>
>>
>>> From a robustness point of view, it would of course good to
>>> have multiple MUST implement algorithms.  OTOH, I think
>>> that there should also be some guidelines how to use them
>>> so that the chances of interoperability are maintained
>>> even in the case that one of the hosts only supports one
>>> algorithm, e.g., due to policy reasons.
>>>
>>> Maybe we could have DSA as MUST and RSA as SHOULD?
>>>
>>> --Pekka
>>
>>
>>
>> I'm a bit confused by what I've read on the subject: IKEv2 has DSA as 
>> MUST and RSA as MUST, but draft-iab-auth-mech says that it should be 
>> avoided unless necessary.
>>
>> If RSA is a SHOULD, HIP will probably needs a mean to negotiate HI 
>> algorithm capabilities (between RSA and DSA), so I tend to think that 
>> we should have both as MUST.
>>
>> Is there any other opinions the subject?
>>
>> Thanks,
>>
>> --julien
>> _______________________________________________
>> Hipsec mailing list
>> Hipsec@honor.trusecure.com
>> http://honor.trusecure.com/mailman/listinfo/hipsec
>>
>>
> 
> _______________________________________________
> Hipsec mailing list
> Hipsec@honor.trusecure.com
> http://honor.trusecure.com/mailman/listinfo/hipsec
> 
> 