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 9:56 AM, Kyle Rose <[e-mail]> wrote:

> On Sat, Nov 11, 2017 at 11:12 AM, Eric Rescorla <[e-mail]> wrote:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > https://mozphab-ietf.devsvcdev.mozaws.net/D3970
> >
> >    2^64 bytes in the underlying TCP datastream (which would cause the
> >    "offset" field to wrap) before re-keying.
> >
> > In TLS and other WGs, we have adopted the practice of
> > salting the nonce with a secret per-connection value to avoid
> > large-scale surveillance attacks. Why did you opt to use a weaker
> > construction. See:
> > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> html#security-record-layer
> > and https://eprint.iacr.org/2016/564.
>
> I think I need some clarification on the point here. From the relevant
> passage in the TLS 1.3 draft:
>
> q( In order to prevent mass cryptanalysis when the same plaintext is
> repeatedly encrypted by different users under the same key (as is
> commonly the case for HTTP), the nonce is formed by mixing the
> sequence number with a secret per-connection initialization vector
> derived along with the traffic keys. See [BT16] for analysis of this
> construction. )
>
> 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.




>    FIN flag set, it MUST immediately send a frame (with empty
> >    application data if necessary) with "rekey = 1".
> >
> > I don't think that the algorithm in this section
> > necessarily works properly, because you have to handle rekeys in
> > sequence:
> >
> > Frame 1 [0:999]
> > Frame 2 [1000:1999, rekey=1]
> > Frame 3 [2000:2999, rekey=1]
> >
> > Now what happens if the frames are re-ordered so you get Frame 3 and
> > then Frame 2. You will try to decrypt Frame 3 with generation 2 and
> > Frame 2 with generation 3, neither of which will work (though you
> > might be able to interpret the text loosely to have you try to decrypt
> > Frame 2 with generation 2). Note that if you were to resequence before
> > processing, this wouldn't happen.
> >
> > At minimum I think some clarification is needed here.
>
> 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?


> Given that you are allowing P-256 and point reuse, you
> > should be requiring point validation. See:
> > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> html#rfc.section.4.2.8.2
> > https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.
> html#elliptic-curve-diffie-hellman
> >
> > You should probably also be requiring Curve25519 output validation.
>
> Agreed.
>
> > You still seem to need to specify an MTI symmetric algorithm.
>
> Daniel noted this in his October 25 email, but you are right: I can't
> seem to find it in the latest draft, either. Did that change get lost?
>

I am not sure.



> ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> >
> > The design of session resumption here essentially precludes doing
> > tcpcrypt resumption across servers (as one does with TLS) because you
> > need extremely tight control of ss[i] or you have catastrophic
> > results. Was this a deliberate choice by the WG?
>
> The idea of doing something more ticket-like was discussed, but David
> pointed out (in the thread here:
> https://www.ietf.org/mail-archive/web/tcpinc/current/msg00919.html)
> that tickets might not meet the charter mandate for forward secrecy. I
> don't recall discussing the implications of mismanaging ss[i], but
> I'll defer to Daniel on that point. Same goes for the following:
>

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).

-Ekr