Re: [Curdle] AD Review of draft-ietf-curdle-gss-keyex-sha2-05

[Eric Rescorla <[e-mail]>]

On Thu, Apr 26, 2018 at 4:46 AM, Hubert Kario <[e-mail]> wrote:

> On Wednesday, 25 April 2018 21:55:21 CEST Eric Rescorla wrote:
> > On Wed, Apr 25, 2018 at 11:53 AM, Hubert Kario <[e-mail]>
> wrote:
> > > On Friday, 13 April 2018 15:41:37 CEST Eric Rescorla wrote:
> > > > On Thu, Apr 12, 2018 at 11:29 AM, Hubert Kario <[e-mail]>
> > >
>
> > > > > > >      This section defers to [RFC7546] as the source of
> information
> > >
> > > on
> > >
> > > > > GSS-
> > > > >
> > > > > > >      API context establishment operations, Section 3 being the
> > > > > > >      most
> > > > > > >      relevant.  All Security Considerations described in
> [RFC7546]
> > > > >
> > > > > apply
> > > > >
> > > > > > >      here too.
> > > > > >
> > > > > > >      The Client:
> > > > > > This section should be refactored to put all the EC mechanics
> (which
> > > > > > are symmetrical) in one place.
> > > > >
> > > > > I don't think I understand what changes you'd like to see
> > > > >
> > > > > both FFDH and ECDH are symmetrical... both client and server need
> to
> > > > > perform
> > > > > the same operations...
> > > >
> > > > Yes, That's why it's confusing to describe their operations in order
> > >
> > > rather
> > >
> > > > than
> > > > the behavior that a DH peer does and then just the points where they
> are
> > > > inserted in the protocol. Compare, for instance, the TLS 1.3
> > >
> > > specification,
> > >
> > > > where both KeyShare (https://tools.ietf.org/html/d
> > > > raft-ietf-tls-tls13-28#page-53) and
> > > > the DH computations (https://tools.ietf.org/html/d
> > > > raft-ietf-tls-tls13-28#section-7.4) are
> > > > described in an endpoint agnostic manner. DH is inherently
> symmetrical.
> > >
> > > the actions performed in context of GSSAPI-infused key exchange aren't
> >
> > Neither are they in TLS, but we managed to put the DH part in one place.
>
> That's not true:
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.2.8.1
> https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.2.8.2


My point was that they're not separated between Client and Server,


> > RFC 7748 says that the verification is optional, I don't see why making
it
> > mandatory is incorrect for SSH. For nist curves, the verification is
about
> > public key, not shared secret, it's just performed in the same step.
>
> I think we're talking past each other. The TLS spec requires that:
>
> - You do public key validation for FFDHE and NIST curves
> - You do output validation for CFRG curves.
>
> Unless I am misreading your text, you are requiring that you also do
output
> validation for the NIST curves. Is that correct? If so, can you provide a
> source for why?

http://www.secg.org/sec1-v2.pdf Section 3.3.1. step 2 of the "Calculate a
> shared secret value as follows" algorithm.
>

Sorry for the delay on this. I've been asking cryptographers. What I
understand
is that this is redundant for these NIST curves as long as you check
the input points, which we do. However, maybe for other curves it is a
problem.
I guess it's OK to leave here.

-Ekr