Subject: RE: [Hipsec] Digital Signature Algorithms

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 21 Oct 2004 09:51:19 -0700

> -----Original Message-----
> From: Miika Komu [mailto:[email-masked]] 
> Sent: Wednesday, October 20, 2004 11:57 PM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [Hipsec] Digital Signature Algorithms

> Using RSA as the default algorithm makes dynamically created R1s less
> appealing from a performance point of view. In a way, this 
> limits the way
> implementations will be done in the real world.

I am not convinced that the above is true.  The tradeoff seems to 
be about a factor of two in sign performance in software 
implementations, but some cycles will be recouped by faster
verification, and in hardware, it might be a wash (e.g.,
http://www.safenet-inc.com/Library/3/SafeXcel-1741_ProductBrief.pdf).

Tom
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 21 Oct 2004 11:21:21 -0700

> From: Pekka Nikander [mailto:[email-masked]] 
> Sent: Thursday, October 21, 2004 10:36 AM
> To: Henderson, Thomas R
> > My only point on that outline was that, unless there was some
> > negotiation extension, it would be difficult to move away from
> > DSA or RSA in opportunistic mode in the future, while maintaining
> > backward compatibility.  Maybe this is obvious, but I was just
> > pointing out the implication.
> 
> I see.  But, if we need to move away from DSA or RSA for
> security reasons, I'm afraid that we can't maintain backward
> compatibility.  Independent of what kind of a negotiation
> mechanism you would have, you would be vulnerable to
> bidding-down attacks.

good point.

> 
> Maybe we should add a paragraph to the security considerations
> section:
> 
>     If an initiator wants to use opportunistic mode, it is
>     vulnerable to man-in-the-middle attacks.  Furthermore,
>     the available HI types are limited to the MUST implement
>     algorithms, as per <xref target="XXX">.  Hence, if a future
>     specification deprecates the current MUST implement algorithm(s)
>     and replaces it (them) with some new one(s), backward 
> compatibility
>     cannot be preserved.  However, given the generally insecure
>     nature of the opportunistic mode, this is not considered to
>     be a serious problem.
> 

I would delete the last sentence (opportunistic is not "generally
insecure" although it has a specific security vulnerability), 
otherwise I would support adding that paragraph.

Tom