[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