Subject: Re: [tcpinc] Spencer Dawkins' Yes on draft-ietf-tcpinc-tcpcrypt-08: (with COMMENT)

From: Daniel B Giffin <[email-masked]>
Date: Fri, 17 Nov 2017 00:56:55 -0800

Hi Spencer, I just noticed I didn't address some of these
points you made on a previous draft ...

Spencer Dawkins wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I really like this draft, and I can understand it fairly well. I do have some
> questions to go along with my Yes ballot.
> 
> This SHOULD NOT
> 
>   o  "PK_A", "PK_B": ephemeral public keys for hosts A and B,
>       respectively.  These, as well as their corresponding private keys,
>       are short-lived values that SHOULD be refreshed periodically.  The
>       private keys SHOULD NOT ever be written to persistent storage.
> 
> is just begging for some justification as to why this is important enough to be
> a SHOULD NOT, and not important enough to be a MUST NOT. Could you give an
> example of a reason why this would be a good idea?

Thanks, others have said something similar, and I've made
the requirements more strict.

> It's likely that everyone but me knows why
> 
>                 resume[i] = CPRF(ss[i], CONST_RESUME, 18)
> 
> is "18" and not some other integer, but there's no explanation or reference
> that I could find explaining why.

Yes, I realize this is mysterious but not sure it is useful
to explain.  It is a tradeoff between getting a low
probability of resumption-identifier collision, and getting
a low probability of wasted TCP option bytes.

> It would be helpful to explain why
> 
>   In a particular SYN segment, a host SHOULD NOT send more than one
>    resumption suboption,
> 
> is a SHOULD NOT, since it's allowed, so doing so must have some purpose.

You're right.  How about:

   In a particular SYN segment, a host SHOULD NOT send more than one
   resumption suboption (because this consumes TCP option space and is
   unlikely to be a useful practice), and MUST NOT send more than one
   resumption suboption with the same TEP identifier.  But in addition

> This
> 
>   A host SHOULD NOT initiate more than one concurrent re-key operation
>    if it has no data to send; that is, it should not initiate re-keying
>    with an empty encryption frame more than once while its record of the
>    remote generation number is less than its own.
> 
> is allowed - could you explain why a host would need to violate that SHOULD NOT?

You're right, I don't think there is any reason to allow it.
I've changed to MUST.

> Just for my benefit - Section 8.3 explains why ECDHE using Curve25519 has been
> chosen as MTI, but also explains why ECDHE using P-256 has not been chosen as a
> second MTI. Is the intention to discourage use of ECDHE using P-256 at all,
> based on the concerns expressed about making it MTI?

The intention is to not burden every implementor with the
requirement to implement algorithms (the NIST ones) that can
be difficult to handle correctly; and otherwise to let
implementors and administrators make their own decisions.

> Also for my benefit, but somewhat more worrying - is the working group fairly
> confident that a specifying second MTI key management scheme will be possible
> at some point, that does not trip over the problems described in [nist-ecc] and
> can be implemented in kernels, or is conforming to the guidance in [RFC7696]
> going to be problematic? I see Mirja mentioned SEC discussions about only one
> MTI key management mechanism being chosen now, but my question is a little
> different - I'm asking if the situation is likely to improve anytime soon.

(David Black has addressed this.)

Thanks for your review!

daniel