Subject: [Hipsec] Digital Signature Algorithms

From: [email-masked] (Henderson, Thomas R)
Date: Thu Oct 21 11:09:00 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Wednesday, October 20, 2004 10:43 PM
> To: Henderson, Thomas R
> Cc: [email-masked]
> Subject: Re: [Hipsec] Digital Signature Algorithms
>=20
>=20
> Tom,
>=20
> > I am not worried about negotiation or evolving this
> > for now, but it seems difficult, if only HITs are known
> > before the handshake, to use anything but RSA.  If we
> > ever go away from "MUST" RSA, we may have to consider
> > some extensions for negotiation.
>=20
> I don't quite understand this.  If all you have is a HIT,
> you can't do anything else but use the algorithm associated
> with the HIT.  If you don't know the key type of the HI
> from which the remote HIT was generated from, you can always
> test.  You'll get the key in an R1.  If you get a HI that
> you can't handle, you have no other option but trying another
> HIT.  So, as far as I can see, there is no need for a negotiation.

Yes, I agree with this.  If an initiator wants to talk HIP with
this responder, it has no other choice than to send opportunistic
I1, and hope that the R1 comes from the same machine (maybe
there might be some way to securely establish linkage between
this RSA HI and the first HIT, specified in some future extension).

>=20
> The problematic case is the opportunistic mode, but for that
> we outlined the interoperability requirements.
>=20

My only point on that outline was that, unless there was some=20
negotiation extension, it would be difficult to move away from=20
DSA or RSA in opportunistic mode in the future, while maintaining
backward compatibility.  Maybe this is obvious, but I was just=20
pointing out the implication.  I don't think we need more
complexity than what you proposed.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Thu Oct 21 12:26:01 2004

> My only point on that outline was that, unless there was some
> negotiation extension, it would be difficult to move away from
> 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.

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.

Or something like that?  The above text is slightly vague,
but I'm just too tired right now to provide a better one.
Any takers?

> I don't think we need more complexity than what you proposed.

Good.

--Pekka