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

[Kathleen Moriarty <[e-mail]>]

Hi Mark,

On Fri, Sep 15, 2017 at 3:59 PM, Mark D. Baushke <[e-mail]> wrote:
> Kathleen Moriarty <[e-mail]> writes:
>
>> Mark,
>>
>> Thanks for your detailed response, I appreciate it.  Inline.
>
> Trimmed response, likewise inline.
>
>> On Fri, Sep 15, 2017 at 2:25 PM, Mark D. Baushke <[e-mail]> wrote:
>> > Salz, Rich <[e-mail]> writes:
>> >
>> Embedded equipment is a tough problem.
>
> Yes.
>
>> So for this, your worried about new purchases.
>
>> 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.
>
> Well, one hopes that with a million dollar piece of equipment, there is
> a support cotract and a way to update the software in that box.

One would think, but that's a real example and nothing could be done.
It's not uncommon either.

>
> I was more concerned with needing to sell software to manage thousands
> of very low price embedded devices and still be able to inter-operate
> between the management station and the devices.
>
> For example, a conformant implementation that MUST use 2048 bit keys,
> but needs to talk to a device only able to use 1024 bit keys has a
> problem. Likewise if the embedded devices only support
> diffie-hellman-group1-sha1 as they were two small and slow to manage
> with diffie-hellman-group14-sha1 when deployed as a read-only device.
>
> Does my management station get to talk to those old devices when MUST is
> present and exact conformance to the specification is mandated?

OK, thanks for providing that example, it's helpful and I see your
point better now.

>
>> 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.
>
> Yes, and I really appreciate that we are getting this into the archive.
>
>> > 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.
>
> So, using words like 'desirable' rather than recommended or should?
> I guess that might be a way to approach it for this particular draft.
>
> I am less certain how to deal with the more general issue of algorithm
> deprecation in the security area. Guessing wrong can be very expensive.
>
>> 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.
>
> Yes, I had used that in early drafts of draft-ietf-curdle-ssh-kex-sha2
> and eventually removed it due to comments not liking it.

Hmm, I still see a table with the SHOULD, MUST, etc. listed out for
that draft?  I don't see the use of SHOULD +/-, MUST +/- and think it
might help in cases like this draft where you have mushy guidance.

I still think some warning that 2048 as the minimum recommendation may
change to 3072 or greater in a couple of years should be in a non
normative statement for developers to plan ahead as a minimum.

>
>> 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?
>
> I do not think that moving to 'a min value of 2048  SHOULD+ be used'
> will do much to help this particular case.

I would actually be recommending min value of SHOULD - as it will not
be recommended in a few years and is on a decline.  SHOULD + typically
indicates that it will be required as a MUST next, whereas in this
case, it will be deprecated in a few years.

Thanks,
Kathleen

>
>         -- Mark



-- 

Best regards,
Kathleen