[tcpinc] Comments on tcpcrypt draft

[Kyle Rose <[e-mail]>]

Removing chair hat for this thread.


Section 3 general comments: There seems to be a lot of exposition here
beyond what is explicitly required to implement the protocol. I might
use section 3 to describe the wire protocol without any explanations
or security analysis of design choices, leaving those explanations for
a later section. Accordingly, I might bring the specifications of
INIT1 and INIT2 into section 3. I'm curious to know what experienced
draft authors think about the options here.

3.1 "An extract function is used to generate a pseudo-random key":
"Key" or "secret"? TLS 1.3 refers to the output of this key agreement
as the "ephemeral secret". It might be helpful to harmonize on
terminology. It's additionally confusing because this key is used to
derive the "pre-master secret", which is then used to derive further
keys; and this bit sequence is never used directly as the key for a
cipher or MAC.

3.1 "A collision-resistant function is one on which, for sufficiently
large L, an attacker cannot find...": I think this is unclear: L is
not a function of the function chosen, but if "F"="family" might be a
function of the family from which the function is chosen (though .
Alternatively, is there a normative reference for this so the
definition of CPRF can simply be dropped?

3.3 "when and only when": Precise and clear to me, but academic
language-ish? Would be interested in others' opinions on this.

3.3 "This document reserves and associates four 'cs' values with
tcpcrypt, as listed in Table 1": Registry?

3.4 "ephemeral public keys...SHOULD NOT ever be written to persistent
storage": I agree for the private keys, but as written this states
that the public keys shouldn't be written out either, which doesn't
matter at all.

3.4 For harmonization with TLS terminology, I might suggest:

ECDHE output = "ephemeral secret"
PRK = "master secret"

3.4 "param := ...": Why this notation, where param is separate from PMS?

3.4 "PRK := Extract (N_A, ...": Why is N_A used as the salt here
instead of N_A || N_B? I see that N_B is included in INIT2, but this
just seems like an arbitrary choice without any explanation anywhere I
can find.

3.4 "SID[0]...will with overwhelming probability be unique for each
individual TCP connection": It feels like this belongs in a later
security analysis section: for one thing, the uniqueness doesn't seem
to be used elsewhere in section 3, and (as I said earlier) it feels
like the doc would be better structured to separate the protocol
description from any statements about its security properties, which
qualify simply as "noise" to someone trying to implement it.

3.4 "There is no 'key confirmation' step in tcpcrypt...": Again, I'd
move this later.

3.4 "If key negotiation is compromised and yields two different
keys,...": This means collisions in SID[i](0..8) (72 bits) will result
in failed connections, which will lead to a frequency of something
like 1 out of every 2^36 connections wherever the session cache on the
passive opener cannot distinguish between different active openers. Is
this actually a problem? Not clear: should there be requirements
around how active and passive openers partition their session caches?
If naïve clients or servers use one big pool, you can expect to see
this problem quite frequently at internet scale, with billions of
connections per second.

3.5 The session cache section feels like it should also be split up
into descriptions of protocol requirements and digressions (e.g., "the
only cost is the additional ten bytes...").

3.5 "The only cost is the additional ten bytes...": And the key exchange.

3.5 "The active opener MUST use the lowest value of 'i' that has not
already appeared in a resumption suboption...": 'i' doesn't appear in
the resumption suboption: SID[i] does.

3.6 "Each chunk is placed in the 'data' portion of a frame's
'plaintext' value, which is then encrypted to yield the frame's
'ciphertext' field.": This language is confusing. I envision a "frame"
as a segment of communication, not as an intermediate value in a
computation, which is all the plaintext is in this case.

3.6 "Chunks must be small enough that the ciphertext (slightly longer
than the plaintext)...": Maybe "(as defined by the AEAD cipher used,
but typically slightly longer than the plaintext)"?

3.6 "An 'associated data' value...": Is it worth looking at Damien
Miller et al.'s construction for encrypted lengths?
https://tools.ietf.org/html/draft-josefsson-ssh-chacha20-poly1305-openssh-00
 Tcpcrypt is still in the draft stage, so it may be worth looking at
this now to see if there's any value there.

3.8 "more than one concurrent re-key operation": What does it mean for
two re-key operations to be concurrent?

4.1 "The four-byte field 'message_len'": This is to accommodate really
long keys (e.g., PQC)?

4.1 Any particular reason for INIT1 to have both message_len and N_A?
If the format changes in the future, INIT1_MAGIC could just be revved.

4.2.1 "an integrity 'tag'": This is never defined.

4.2.2 Should the associated data of the first data frame include the
INIT1 message? It's included in the PRK, but is key derivation the
right place to put what amounts to authentication of the handshake
transcript?

4.2.3 Magic numbers are specified here, but not in INIT1_MAGIC, which
is in the lonely appendix. Inconsistent layout.

4.2.3 Clear from this that a cipher MUST re-key at least every 2^64 bytes.

Section 5 general comments: I wonder if this belongs in this document
at all, or whether it should be moved to a separate API document.

Section 6: "A tcpcrypt implementation MUST support at least the
schemes ECDHE-P256 and ECDHE-P521": I wonder if, now that the safe
curves stuff has moved through CFRG, whether we should MTI curve25519
and curve448 instead.

Section 9: I wonder whether these should be a la carte or suites:
should ENO choose the combination of KX and AEAD cipher at the same
time? One way, you potentially get combinatorial explosion, which
might be a problem with limited ENO option space as algorithms get
replaced; the other, you get weird combinations of algorithms as
judged by security margin, and a more complicated handshake. I'd love
to hear opinions on this.

Kyle