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

[David Mazieres <[e-mail]>]

Eric Rescorla <[e-mail]> writes:

>    When a frame is received, tcpcrypt reconstructs the associated data
>    and frame ID values (the former contains only data sent in the clear,
>    and the latter is implicit in the TCP stream), computes the nonce "N"
>    as above, and provides these and the ciphertext value to 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 SHOULD abort the connection and raise an error
>    condition distinct from the end-of-file condition.  But if none of
>    the TCP segment(s) containing the frame have been acknowledged and
>    retransmission could potentially result in a valid frame, an
>    implementation MAY instead drop these segments (and "renege" if they
>    have been SACKed, according to [RFC2018] Section 8).
>
> Looking through this again, why is this the right guidance? It seems
> like:
>
> 1. You shouldn't ACK data that you can't verify, because it's confusing
> to the other side. This seems like one of the arguments for tcpcrypt
> rather than protocols that run over top of TCP.

This obviously isn't how the original tcpcrypt worked, but the working
group decided that for middlebox robustness, tcpcrypt should not protect
the integrity of the TCP header (including ACK bits).  As it is, nothing
requires TCP segments to align with tcpcrypt frames.  If the recipient
lucks out and hasn't ACKed any of the corrupt data, then maybe hope a
retransmission is better, although middleboxes might prevent sequence
numbers from being overwritten anyway.  Since that's a rather fringe
case, if you only do one thing it needs to be aborting the connection.

> 2. You would get better resistance to connection failure if you instead
> decrypted packets and then ACKed.

Not especially, because tcpcrypt doesn't protect the header, so an
active attacker can just inject bad packets and desynchronize the TCP
connection.  There does exist a protocol that does better--namely the
original version of tcpcrypt, but for various reasons the working group
ultimately rejected this design (over my objections), and it's too late
to revisit the decision at this point.

> Is the situation that sometimes you have to ACK? I haven't thought
> this through. Perhaps you should recommend against ACKing if you
> don't have to.

The ACKing is effectively dictated by RFC793 (+SACK).

> I also notice you don't require checking that the result of the
> X25519 function is nonzero. We hve been requiring this in other
> IETF protocols.

Seems like a vanishingly low-probability event, but I see no problem to
adding such a requirement.  Do you have some language to suggest?  Maybe
we could cut and paste out of another RFC with already approved
language?

>    the number of past connections that are vulnerable.  Of course,
>    placing private keys in persistent storage introduces severe risks
>    that they will not be destroyed reliably and in a timely fashion, and
>    SHOULD be avoided at all costs.
>
> This seems a bit over the top. Either it's this serious and you need
> a MUST, or it's not this serious, and you should tone it down.

It is serious, especially with SSDs.  The reason not to make it a MUST
is that some implementations may be unable to avoid it--like a virtual
machine that gets transparently paged to disk.  That could still be okay
if, say, the swap partition is encrypted with an ephemeral key.

>    To meet that ideal, it might appear natural to also mandate ECDHE
>    using P-256, as this scheme is well-studied, widely implemented, and
>    sufficiently different from the Curve25519-based scheme that it is
>    unlikely they will both suffer from a single (non-quantum)
>    cryptanalytic advance.
>
> I'm not sure how persuasive this argument is. Wouldn't an efficient
> discrete log algorithm in generic groups affect both of these functions.
> As far as I know, it's not known that no such algorithm exists.

In fact, there are lower bounds on generic-group discrete-log attacks.
See, for example, this recent Eurocrypt paper:

        https://www.henrycg.com/files/academic/papers/eurocrypt18discrete.pdf

But it sounds like you actually agree with us that we don't need to
mandate P-256, so I'm not sure what you are suggesting here.

David