Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Nov 5, 2018 at 6:02 AM David Mazieres <
[e-mail]> wrote:

> Eric Rescorla <[e-mail]> writes:
>
> > On Sun, Nov 4, 2018 at 5:29 AM David Mazieres <
> > [e-mail]> wrote:
> >
> >> I've posted a new draft in the usual place:
> >>
> >>         https://datatracker.ietf.org/doc/draft-ietf-tcpinc-tcpcrypt/
> >>
> >> Please let us know if the diffs satisfy your concerns:
> >>
> >>
> >>
> https://www.ietf.org/rfcdiff?url1=draft-ietf-tcpinc-tcpcrypt-13&url2=draft-ietf-tcpinc-tcpcrypt-14&difftype=--html
> >
> >
> > I am not an EC expert, but my impression based on the discussion in TLS
> was
> > that checking for the zero value for X25519 was not sufficient defense
> > against malicious peers if you didn't use the 7748 computations, hence
> the
> > language in 8446. Do you believe otherwise?
>
> I don't understand what you are asking for here.  Section 7 of RFC7748
> is mostly advice applicable to tcpcrypt's authors, which we are
> following--for instance by including the entire transcript with nonces
> in the session key computation so as not to depend on "contributory
> behavior" of the Diffie-Hellman parameters.  What is it that you want us
> to specify in our RFC for tcpcrypt implementers?
>

I provided the text I recommend in my note of November 1.

"   For these curves, implementations SHOULD use the approach specified
   in [RFC7748] to calculate the Diffie-Hellman shared secret.
   Implementations MUST check whether the computed Diffie-Hellman shared
   secret is the all-zero value and abort if so, as described in
   Section 6 of [RFC7748].  If implementors use an alternative
   implementation of these elliptic curves, they SHOULD perform the
   additional checks specified in Section 7 of [RFC7748].
"

I agree that this isn't maximally clear in 7748, but it does involve
checking that you
are on-curve.



> The only think tcpcrypt cares about for malicious peers is preventing
> session ID reuse, which the design indeed appropriately prevents.
>

Generally, we've decided to adopt a belt and suspenders approach here,
namely:

1. Trying to ensure that the DH function can't be forced into a small set
of values
by one side.
2. Merging in the transcript so even if the DH function isn't contributive,
you can't
force the output keys into a small range.

I agree that tcpcrypt does (2). What I am looking for is also (1).

-Ekr


Otherwise, if a malicious peer causes a connection to be aborted or
> leaks the session key--well, that's something they could have done
> anyway.
>
> Can you be more concrete about what you are worried about and what you
> want us to do about it?-
>
> David
>