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

[Eric Rescorla <[e-mail]>]

On Thu, Nov 8, 2018 at 1:19 PM Daniel B Giffin <[e-mail]> wrote:

> Eric Rescorla wrote:
> [..]
> > 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?
>
> The draft currently says:
>
>    Key-agreement schemes ECDHE-Curve25519 and ECDHE-Curve448 use the
>    functions X25519 and X448, respectively, to perform the Diffie-Helman
>    protocol as described in [RFC7748].  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].  [...]
>
> This requires, perhaps too gently, the (Montgomery ladder)
> algorithm in RFC 7748.
>

OK, I did not read it that way. It would be fine with me if you made this
sharper. I.e., "Implementations MUST use the Montgomery ladder as specified
in [RFC7748] and MUST check whether..."



> But it is not clear exactly what "additional checks" are
> required (reject all invalid keys?),


Yeah, I agree that this isn't maximally clear.


and for what purpose
> (ensure some "contributory behavior" property?)
>

Yes.


It seems the only observable difference would be that other
> algorithms might abort on some invalid DH inputs that the
> RFC 7748 algorithm accepts.
>
> So there are two orthogonal questions here:
>
> - Should tcpcrypt allow implementations that behave
>   differently from RFC 7748?
>
> - Given that tcpcrypt does not depend on any "contributory
>   behavior" property, is there any use in requiring DH input
>   validation?
>

See my response to David. Elsewhere we have been opting for belt and
suspenders.

-Ekr


> If other algorithms are allowed *and* input validation is
> required, it seems we will have to explain more clearly what
> validation entails.
>
> d
>
>