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

[Eric Rescorla <[e-mail]>]

On Fri, Nov 24, 2017 at 10:28 AM, Daniel B Giffin <[e-mail]>
wrote:

> Ekr: Thanks for explaining the point about session-secret
> reuse, and for proposing a reasonable coutermeasure.
>
> I agree adding nonces to the resumption handshake could be a
> useful safeguard, but there is the cost of 12 (or more)
> bytes of option-space on the first ACK in each direction.
>

Well, there are (at least) two other options:

1. You could simply accept the extra round trip and send nonces in both
directions, as you do for the non-resumption handshake. That would be
the most straighforward approach, and arguably the best one.

2. As I mentioned in my original note, you could have implementations
send a nonce in their sending direction before the first byte of ciphertext.
This isn't as good because you don't get anti-replay, but I *believe*
that it would provide strong defense against keying material reuse,
which seems like the most immediate threat.

-Ekr


And as David Black suggests, the expected setting for
> implementation of tcpcrypt ought to make safe managment of
> session secrets straightforward.  (Famous last words?)
>


> Although I'm happy to entertain more discussion about this
> tradeoff, I'm inclined to David Black's suggestion to add
> "serious warnings about avoiding resumption key reuse" to
> Security Considerations.
>
> daniel
>
> Black, David wrote:
> > Hmm - while I'm not sure whether this resumption crypto change should be
> made, I'm concerned by what may be "scope creep" here, courtesy of a use
> case difference from TLS that weakens reasoning by analogy across the two
> protocols.
> >
> > TLS is predominantly a user-space library protocol that is used with
> load-balanced server clusters, including protocol offload engines. That
> creates opportunities to move TLS state around, e.g., across TCP
> connections.
> >
> > In contrast, tcpcrypt is predominantly a kernel-space protocol whose
> state is intended to be bound to a single TCP connection. It's much harder
> and less common to extract the relevant kernel protocol state, although
> it's possible in principle.
> >
> > If this change is not made, then at a minimum, some serious warnings
> about avoiding resumption key reuse are in order,  as beyond GCM, that is a
> serious threat to all stream ciphers.
> >
> > Thanks, --David ... Sent from my Android not-so-smartphone.
> >
> >
> > -------- Original message --------
> > From: Eric Rescorla <[e-mail]>
> > Date: 11/18/17 5:05 PM (GMT-06:00)
> > To: Daniel B Giffin <[e-mail]>
> > Cc: tcpinc <[e-mail]>, Kyle Rose <[e-mail]>,
> [e-mail], The IESG <[e-mail]>,
> [e-mail]
> > Subject: Re: [tcpinc] Eric Rescorla's Discuss on
> draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)
> >
> > Hi Daniel.
> >
> > I won't have a chance to review this document until Monday, but I
> > wanted to respond not to the point about the reuse of ss[i], because I
> > think you (and others) may have understood me and thought this was
> > primarily about tickets versus session ids, which it is not.
> >
> > At a high level, tcpcrypt establishes a master secret which is then
> > used to create a chain of resumption secrets ss[i]. Each ss[i] value
> > is intended only to be used for resumption once, in which case things
> > are fine. However, because the only input to the traffic keys is
> > ss[i], if you ever reuse ss[i], the result is catastrophic
> > (potentially leading to a complete loss of integrity if the cipher is
> > AES-GCM).
> >
> > By contrast, TLS 1.3 has a similar design (the secrets are a tree, not
> > a chain) but because there is always a nonce exchange, and the nonces
> > are mixed into the traffic keys, so if you *do* reuse a secret, the
> > main impact is that the two connections in which you use the secret
> > are linkable (by the ticket ID), and of course that you don't have
> > FS. IKE PSK has a similar design, and I think it's clear that it's
> > less brittle than the design in tcpcrypt.
> >
> > This is an orthogonal question to whether the IDs used for resumption
> > are lookup keys (like in tcpcrypt) or can be self-contained (TLS 1.3
> > allows both lookup keys and self-contained IDs). Although designs
> > where one side dictates the identifier are compatible with
> > self-encrypted tickets, the need not be used that way, and are
> > compatible with FS. See, for instance:
> > https://tools.ietf.org/html/draft-ietf-tls-tls13-21#section-8.1.
> >
> > Assuming I understand the design of tcpcrypt correctly, it seems like
> > the reason for the choice not to have a nonce is that you don't have
> > room in the SYN, and you don't want to take another round trip in the
> > resumption case. However, I think you can improve on the situation
> > somewhat even within these constraints. Here's your Figure 9 from
> > ENO modified to include tcpcrypt as I understand it:
> >
> >              (1) A -> B:  SYN      ENO<TCPCRYPT sid[i] part 1>
> >              (2) B -> A:  SYN-ACK  ENO<TCPCRYPT sid[i] part 2>
> >              (3) A -> B:  ACK      ENO<>
> >
> > A can start sending encrypted traffic after sending (3) and B can
> > start sending encrypted traffic after receiving (3). Am I correct
> > so far?
> >
> > Assuming I am correct, then it seems like (B) could send a nonce
> > in message (2) and A could send a nonce in message (3), like so:
> >
> >              (1) A -> B:  SYN      ENO<TCPCRYPT sid[i] part 1>
> >              (2) B -> A:  SYN-ACK  ENO<TCPCRYPT sid[i] part 2, N_a>
> >              (3) A -> B:  ACK      ENO<TCPCRYPT N_b>
> >
> > You could then derive the keys from ss[i], N_a, and N_b, and avoid
> > brittleness associated with ss[i] reuse. Of course, you should still
> > require that people not reuse ss[i], because that gives you FS, but
> > the consequences if people fail to do so would not be so dire.
> >
> > -Ekr
>