IETF-SSH archive

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

Re: [psg.com #460] IESG - Transport - Oakley





On Sunday, June 13, 2004 22:53:49 +1000 Damien Miller <djm%mindrot.org@localhost> wrote:

Niels Möller wrote:
I also argue this way. If we need to change anything at all at this
stage (and it seems the IESG has a valid concern), then I think we
should do it the simple way and get it over with.

Mandating one more fix group, diffie-hellman-group14-sha1, is a simple
change to the spec, and a 20-line change to update an implementation.

Agreed, so long as the diffie-hellman-group1-sha1 remains a MUST.

Yes, there is a strong interoperability argument for keeping diffie-hellman-group1-sha1. Not only is there a very large installed base, but there are many distinct implementations. Expecting every implementor to support the new group and every user to deploy a new version overnight would be unreasonable.

I'd like to see DH-GEX recommended,

Me too.

but I think that can be done in the
DH-GEX draft itself when it is advanced.

Yeah, but it would be better to do it in the core specification, where the recommendation will have more visibility. IIRC all DH-GEX needs is some cleanup wrt copyright issues (and, by now, new boilerplate). If that can happen soon it doesn't seem like it would be unreasonable to have a normative reference to it.


Is it still appropriate to use sha1 (rather than sha256) with group
14? Staying with sha1 has the advantage that it reduces the number of
cryptographic algorithms that must be included in a minimalistic
implementation of the protocol.

I don't know, but it certainly would be desirable to stick with sha1. For one thing, it means the new method can be specified in one sentence, and as you note, implemented very nearly as easily.


It might be desirable to RECOMMEND or even REQUIRE that diffie-hellman-group14-sha1 be listed _before_ diffie-hellman-group1-sha1, so that its use is preferred when both sides support it. And of course, I imagine that implementors will provide policy options to turn off support for either group.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+%cmu.edu@localhost>
  Sr. Research Systems Programmer
  School of Computer Science - Research Computing Facility
  Carnegie Mellon University - Pittsburgh, PA




Home | Main Index | Thread Index | Old Index