Re: [tcpinc] Comments on tcpcrypt draft

[Mirja Kühlewind <[e-mail]>]

Hi Kyle, hi tcpcrpyt authors, hi all,

just one comment from my side on your first comment below (not as chair but as author of other docs). It’s a ticky thing to keep the spec short and crisp while providing some explanation why a specific solution has been chosen. In general I prefer your proposal below to keep the protocol spec as short as possible and have an extra section for all the rational behind the choices made. I believe this is the better approach because there are people who 'only' want to implement the spec and any additional discussion about why something is done in some way and not another way might rather confuse people than help them to implement something correctly. However, sometimes there might be also some explanation needed to actually implement it correct. As I said, tricky bit...

In case of tcpcrypt, I’d image that it might not be super easy to split this up. However, I would recommend the authors to give it a try and figure out if that makes sense at all.

Further, at this point it would be important to have feedback from someone who implemented tcpcrypt (just) based on the spec. Therefore again, please let us know if you have any plan for implementing tcpcrypt+tcp-eno!

Mirja


> Am 06.03.2016 um 19:46 schrieb 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
> 
> _______________________________________________
> Tcpinc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpinc