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

[Daniel B Giffin <[e-mail]>]

Eric Rescorla wrote:
> As it happens, I was able to take a look. Several notes from my review:
> 
> - Not all algorithms take a 12 byte nonce, so you probably want to allow
> some generality
> here.
> - I'm not sure you still need the NONCE_MAGIC value.

Yes, I agree on the above.  I will change this to do the
same as TLS: zero-pad the record number (frame offset for
tcpcrypt) to the nonce size.

> - Do you want to cover SACK in the section about how you handle
> deprotection failures.

I suppose that makes sense.  I'll try to propose new
language there shortly.

> On Fri, Nov 17, 2017 at 8:17 PM, Daniel B Giffin <[e-mail]>
> wrote
> >
> > > Given that you are allowing P-256 and point reuse, you
> > > should be requiring point validation. See:
> > > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> > html#rfc.section.4.2.8.2
> > > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> > html#elliptic-curve-diffie-hellman
> >
> > Yes, thank you.  For the NIST curves, I have added:
> >
> >         Implementations MUST validate these "pubkey" values according to
> > the
> >   algorithm in [ieee1363] Section A.16.10.
> >
> > But I see that TLS refers to ANSI X9.62 for validation, even
> > though it refers to IEEE1363 for DH computation.  Is there a
> > good reason not to stick with the one source?
> >
> 
> TBH, not sure. Filed an issue on TLS for that.
> 
> 
> > Also, I guess there's no need to check on-the-curve if we
> > allow only compressed format, and it's not perfectly clear
> > to me whether we need to check group membership, but I'd
> > really rather not have all these details in this document if
> > there's a good way to cite it out.
> >
> 
> I think your text is fine.

Great.

> > You should probably also be requiring Curve25519 output validation.
> >
> > I think you're saying we should check that the DH result is
> > not zero?
> >
> > No harm, I suppose, but I'm going to try to get guidance on
> > whether it's necessary.
> >
> 
> It's the way we're going in the security area. Is there some reason not to.

Okay, having done some more reading about this, it sounds
like a zero check on the output is not at all sufficient to
ensure "contributory" behavior from the X25519 function:

  https://moderncrypto.org/mail-archive/curves/2017/000896.html

And because our key-derivation function gets fresh
randomness from each host's nonce, I don't believe we need
to get this contribution from the DH function.  (I mostly
have a confirmation from Dan Boneh on this, but have asked
for more clarity to be sure we can make this claim
confidently; I'll report back as soon as I can.)

In RFC7748, which we're referencing for how to perform
X25519, it says in Section 6.1:

	 Both now share K = X25519(a, X25519(b, 9)) = X25519(b, X25519(a, 9))
   as a shared secret.  Both MAY check, without leaking extra
   information about the value of K, whether K is the all-zero value and
   abort if so (see below).  Alice and Bob can then use a key-derivation
   function that includes K, K_A, and K_B to derive a symmetric key.

   The check for the all-zero value results from the fact that the
   X25519 function produces that value if it operates on an input
   corresponding to a point with small order, where the order divides
   the cofactor of the curve (see Section 7).  The check may be
   performed by ORing all the bytes together and checking whether the
   result is zero, as this eliminates standard side-channels in software
   implementations.

So I guess tcpcrypt's instruction is "MAY abort" due to this
reference.  I believe this does not break anything
(good-faith implementations will not cause each other to
abort), but it doesn't sound like it solves anything either.

Even if we wanted to "validate" X25519 pubkeys, I am not
sure how to do that.  The only instruction I can find is to
compare the received pubkeys against this list of about a
dozen bad values:

  https://cr.yp.to/ecdh.html#validate

If there is some IETF discussion of best practice, can you
point me to it?  The closest I could find is in CFRG from
2015:

	https://www.ietf.org/mail-archive/web/cfrg/current/msg06558.html

For now, I think my tentative proposal is to make no
changes: that is, continue to reference RFC7748 and make no
mention of public-key validation for X25519.

> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
[skipped for now]