[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ciphersuites for IKEv2, revised



Dan McDonald <danmcd@east.sun.com> writes:

> Thanks for this most recent update.

Yes, thank you for the update..

> I'm still not convinced of the goodness of suites in general, but if the WG
> insists, I have to fall in with Michael that you should cordon off sections
> for IKE, AH, and ESP.

I, too, am not convinced of the goodness of suites _in the protocol_.
I completely agree that suites should be defined in the user interface
presented to the user, but on-the-wire I still believe that all the
algorithms should be negotiated a-la-carte.

I've been catching up on wg mail over the last few days, and this WG
seems to continually flip-flop between suites and a-la-carte.  I had
_THOUGHT_ that we had concensus on:

        1) the on-the-wire protocol would negotiate a-la-carte
        2) the UI would present suites to the user

What happened to this concensus that we had in December?

As an implementor, it's significantly easier to design plug-and-play
algorithms.  I see no reason to constrain an implementation to some
set of suites.  I don't believe it will hurt interoperability to
negotiate a-la-carte, and in fact I think it makes for a simpler
specification to do so.

But again, the user interface can lump these choices into named suites
for the user to choose.  I have no problem with creating a set of
known, named suites for users.

Can someone explain the benefit of forcing negotiation by suites?  The
only argument I've heard is hardware crypto -- but in that case it can
just make a set of a-la-carte proposals that meet its capabilities.

> Dan

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       derek@ihtfp.com             www.ihtfp.com