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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 7:00 AM, Kyle Rose <[e-mail]> wrote:

> On Mon, Nov 13, 2017 at 10:09 AM, Eric Rescorla <[e-mail]> wrote:
> > On Mon, Nov 13, 2017 at 9:56 AM, Kyle Rose <[e-mail]> wrote:
> >> What is the situation, commonly the case for HTTP, in which different
> >>
> >> users would be using the same key for encryption?
> >
> >
> > That's not the assumption. It's a time-space tradeoff. Say you have a
> > 128-bit
> > key. The attacker computes the value:
> >
> >   Encrypt(K, "GET / HTTP/1.1") [or whatever]
> >
> > For a feasible subset of the key space (e.g., 2^80 or so). It then
> captures
> > a large fraction of the traffic on the Internet and looks for matches for
> > one
> > of these strings. If it has a match, it now immediately knows the key.
> Given
> > the amount of traffic on the Internet, this is just maybe barely feasible
> > with
> > 128-bit keys. However, with a randomized (secret) nonce, it becomes
> > infeasible.
>
> 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.


>> I'm confused. The byte stream will be delivered in-order via TCP
> >> sequence semantics, so receiving frames (TLV within the TCP
> >> bytestream) out-of-order should not be possible. If a MitM reordered
> >> the frames, the receiver would either drop the frame or close the
> >> connection following a failure to authenticate upon decryption:
> >>
> >> q( 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. )
> >
> >
> > Maybe I'm misunderstanding tcpcrypt, so let me ask a preliminary
> > question:
> >
> > Say you have two TCP segments protected using tcpcrypt, N and N+1
> > If the receiver receives N+1 before N, how does it behave?
>
> Tcpcrypt lives entirely within the ordered TCP data stream. If N+1
> arrives before N, that payload will not be delivered to the tcpcrypt
> engine until after N arrives, in accordance with the in-order
> semantics of TCP payload delivery.


Right. I plead jet lag.

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.





> > I don't think the issue here is tickets, but rather the lack of a nonce.
> > The point is that (say) the implementation fails to properly delete
> > ss[i] after encrypting some data. Then if an attacker can force
> > you to reuse ss[i], it can potentially recover data. This would not
> > be the case if you mixed in a nonce from both sides (the way that
> > TLS and IKE do).
>
> 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.

-Ekr