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 <d...@scs.stanford.edu> > 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] _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc