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

[Kyle Rose <[e-mail]>]

On Mon, Nov 13, 2017 at 3:21 PM, Eric Rescorla <[e-mail]> wrote:
>> Interesting. I don't have a strong opinion about this one, but if
>> there are no (or cheap) tradeoffs, it seems reasonable to use this
>> construction.
>
> The countermeasure that TLS uses seems pretty cheap.

SGTM. Daniel can chime in here in case he strongly disagrees.

> Now that you've reminded me of this, it's worth noting that the following
> text
> probably could use some expansion:
>
>    When a frame is received, tcpcrypt reconstructs the associated data
>    and frame nonce values (the former contains only data sent in the
>    clear, and the latter is implicit in the TCP stream), and provides
>    these and the ciphertext value to the the AEAD decryption operation.
>    The output of this operation is either a plaintext value "P" or the
>    special symbol FAIL.  In the latter case, the implementation MUST
>    either drop the TCP segment(s) containing the frame or abort the
>    connection; but if it aborts, the implementation MUST raise an error
>    condition distinct from the end-of-file condition.
>
> Presumably the theory here is that there is some sort of benign damage
> to the packets that nevertheless passed the TCP checksum, and the retransmit
> might succeed. However, in order for this to work properly, you have to
> withhold
> ACKs for those segments until you have verified them (or if you are using
> SACK, renege on the segments once they become in-order and you determine
> they are bogus). Otherwise, the sender will not retransmit, and you'll never
> be
> able to recover. This probably needs to be covered in this spec.

Good call. This is a good illustration that tcpcrypt actually operates
at the transport layer, or that there is an intrinsic/unavoidable
layer violation, if the intent of an implementation is to discard a
bad packet rather than abort the connection.

>> I like the idea of added defense-in-depth against faulty
>> implementations, but it's not clear to me what tradeoffs this involves
>> re: (e.g.) SYN data on resumption, or on number of round trips, or on
>> the latency-to-first-payload-byte. I'd like Daniel to chime in here.
>
> I suspect that latency is in fact the issue here, but there's probably
> *some* way around this. Half-baked probably broken idea: what if each side
> sent
> a nonce before it started encrypting and mixed that into its *sending*
> keys. Then at least you would have diversity for the keys, though no
> anti-replay.

I like that this involves no tradeoffs other than some bytes for the
nonce. I don't think I'd want any changes at this point that
complicate the protocol or add round trips or latency, especially
since SYN data is not currently an issue for any TEP.

Do you think we need any additional language in security considerations?

Kyle