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

[Spencer Dawkins at IETF <[e-mail]>]

Speaking as someone whose primary connection to crypto is transporting
bytes whether the transport protocol can understand them or not ...

On Fri, Sep 15, 2017 at 3:41 PM, Kathleen Moriarty <
[e-mail]> wrote:

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

I've had a comment with someone within the last 24 hours about whether
having text that says, roughly, if you're using less than 2048 bits and
can't go higher, you should probably expect that if this does become a
MUST, that might happen very suddenly ("attack + CERT advisory + vendors
who can go higher turning off anything lower than 2048 = you can only talk
to people who can't do 2048, and they're all vulnerable to a known exploit"
is a layperson's understanding, but I hope that's not too muddy to make
sense).

If that was a decent idea, and "you might want to be adding 3072 if you
can't do it now" is a good idea, this is turning into an advisory section,
and I like that, even if you don't have consensus for normative statements
now.

Is that going to make things better? (I'm assuming it won't make them
perfect)

Spencer


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