Re: [Curdle] Looking for comments on draft-ietf-curdle-ssh-kex-sha2

[Simo Sorce <[e-mail]>]

On Thu, 2020-11-26 at 22:46 +0200, Tero Kivinen wrote:
> Mark D. Baushke writes:
> > I could add this informative reference:
> > 
> >     Karthikeyan Bhargavan, Gaeutan Leurent. Transcript Collision Attacks:
> >     Breaking Authentication in TLS, IKE, and SSH. Network and Distributed
> >     System Security Symposium -- NDSS 2016, Feb 2016, San Diego, United
> >     States. 10.14722/ndss.2016.23418 . hal-01244855
> >     URL: https://hal.inria.fr/hal-01244855/document
> > 
> > to the informative section of the RFC and try to add additional
> > theoretical justification against SHA-1, is this really necessary?
> 
> I think it would be good idea to add that reference, even when it do
> consider that attack against ssh impractical with 2^77 work, but it do
> warn about not including weak ciphers in the list, and warn about the
> group exchange. 
> 
> > The paper does show that the group exchange (RFC4419) use of *-sha1 may
> > be somewhat easier to attack than the fixed group, but I have already
> > listed that as 'SHOULD NOT' in my -12 draft.
> 
> This could refer to this same paper.
> 
> > The real question here is if "SHOULD NOT" is the correct implementation
> > guidance for all use of diffie-hellman-group14-sha1 in key exchanges
> > which is a big jump from "MUST" right now. All of the other *-sha1
> > exchanges in the draft are listed as "SHOULD NOT" already.
> 
> I think it can still be SHOULD, just to keep backward compatibility
> with old devices. It does not need to be enabled by policy in default
> configuration, but sometimes you need to connect those devices, and it
> is painful if you need to find old version of some ssh client just to
> be able to connect to them.

A MAY is probably more adequate in this case. It means you can provide
it, but you are not out of spec if you decide not to implement it, and
not implementing it should be a valid choice.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc