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

[Kathleen Moriarty <[e-mail]>]

Mark,

Thanks for your detailed response, I appreciate it.  Inline.

On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke <[e-mail]> wrote:
> 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.

Embedded equipment is a tough problem.  So for this, your worried
about new purchases.  Sales should go way down with the SHOULD at this
point and I wouldn't let an organization I managed chose a product
that didn't support the minimum recommendation at this point, so it is
really an issue if there is no competitor and the only choice doesn't
meet the minimum SHOULD.  If it's already purchased, then we are
talking an audit issue and possibly not having funds to buy  some
million dollar piece of equipment that happens to support less than
2048.  Hmm, in the past, I've done thing to mitigate threats like
isolating such hosts when the threat warranted measures.  I see your
point, I'm just trying to walk through real instances of issues to
make sure we are considering options well.

>
> 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.

Hmm, than it would be good to make a note of this so those who are
replacing embedded equipment make the leap to a higher value than
2048.  This can be in the non normative text.

>
> 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...

It's technically not, but I see what you are saying.

There are a few published RFCs (I think some CMS RFCs) that took on a
notion of SHOULD - and SHOULD + as well as MUST + MUST -.  I see the
JOSE algorithms RFC also uses recommended + and recommended -.  The
minus shows that although this is kinda okay now, it really isn't
recommended and shouldn't be in new products.

Do you think that approach could help to allow some flexibility, but
also show 1024 is on it's way out the door and 2048 will follow soon?

Thanks,
Kathleen
>
> The above is my personal opinion and may not represent that of the
> company with which I am affiliated.
>
>         -- Mark



-- 

Best regards,
Kathleen