Re: [Curdle] Kathleen Moriarty's Yes on draft-ietf-curdle-ssh-dh-group-exchange-05: (with COMMENT)

["Mark D. Baushke" <[e-mail]>]

Salz, Rich <[e-mail]> writes:

> ➢ Ok, so why can't that just be done the next time the deployed base
> > is ready? Is there a reason why the deployed base needs to be
> > compliant with this RFC? Or will making 2048 a MUST help to drive the
> > change?
> 
> That’s an excellent question; I think Dennis and other authors should
> reply ☺

My biggest change for the core SSH protocol is that governmental
agencies are mandating compliance to the standards if SSH is to be used
in a product. By updating the standards from a SHOULD to a MUST without
consideration for a large installed base of embedded equipment, we may
find that many products are being excluded from being used when the
'standard' they define is bumped.

For draft-ietf-curdle-ssh-dh-group-exchange, RFC4419 does not use the
word "MUST" for the current 1024 bit value. So, in this case, just
updating a SHOULD from a SHOULD seems reasonable to me. If it were a
MUST, then I would probably advocate for SHOULD NOT as the step down.

For example, I would have no objection to adding text which says that
the min value in the SSH_MSG_KEY_DH_GEX_REQUEST SHOULD NOT be less than
2048.

fwiw: I also suspect that 2048 will not survive more than another couple
of years and would not mind saying that "n SHOULD be 3072 or greater". I
do not believe that view is accepted by everyone, so 2048 bits is what
is in place for now.

I worry more about more of core SSH compliance changes.

For example, diffie-hellman-group1-sha1 which is in the original SSH
RFCs as a MUST implement is too weak. My draft moves it from a MUST
implement from the SSH core standards to a SHOULD NOT. I stopped short
of going to a MUST NOT as I believe there needs to be a transition
period for the implementations out there to become compliant. I say this
because I have observed some standards (NIAP an Common Criteria)
currently want exact complaince to the standand RFCs they list. For a
large embedded installed base, it will likely take a long time for those
boxes to be updated (if they even can be updated in all cases).

Is SHOULD NOT stronger than SHOULD? It may not be, but somehow it feels
stronger...

The above is my personal opinion and may not represent that of the
company with which I am affiliated.

	-- Mark