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

[Eric Rescorla <[e-mail]>]

On Mon, Nov 27, 2017 at 8:30 AM, Black, David <[e-mail]> wrote:

> Inline ...
>
> > On Fri, Nov 24, 2017 at 1:33 PM, Eric Rescorla <[e-mail]> wrote:
> > > 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.
> >
> > Whether this is acceptable to mandate or not really depends on the
> > goals of session resumption. If the goal is simply to save compute
> > resources for key exchange, then this seems like a reasonable change
> > to make; but if the goal is to drive down time-to-first-byte-delivered
> > to no more than a normal TCP connection, then this will negate that
> > advantage, significant especially for lengthy paths.
> >
> > If tcpinc were primarily about confidentiality against active
> > attackers, I think I'd come down on the side of safety against bad
> > implementations; but, as the primary goal of tcpinc is to prevent
> > pervasive passive surveillance, I think the balance tips the other
> > way: to favor performance over misuse tolerance.
>
> [David>]  I agree with Kyle here.  In addition, a new key exchange is
> cheaper for tcpcrypt by comparison to TLS (e.g., because tcpcrypt does not
> authenticate), so if the properties of a new tcpcrypt key exchange are
> wanted, that's what should be done, IMHO.
>

I'm not sure why you call this the properties of a new key exchange.
Non-reuse of keys is a basic property of key establishment schemes.


> I also agree with David Black that I feel like there's a lot of scope
> > creep here: frankly, I'm not comfortable making substantive changes to
> > the core protocol without doing another WGLC.
> >
> > > 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.
> >
> > This may be the best compromise: it provides a measure of misuse
> > tolerance within the existing performance constraints.
>
> [David>] Hmm - this doesn’t do much for confidentiality with stream
> ciphers like AES GCM (the single "MUST implement" cipher for tcpcrypt) , as
> if reuse happens, then the attacker XORs the two matching ciphertext
> streams yielding an XOR of the plaintext streams in which the first n bytes
> of XOR'd nonces can safely be ignored.
>

> If the intent was that the nonces participate in key derivation, then the
> keys would need to be re-derived after the first message following
> resumption is received


Huh? I think we're talking past each other here.

My suggestion was to send a nonce before you send any ciphertext and then
derive the traffic keys from ss[i] and the nonce. That's why this only
works properly asymmetrically.


- it's a better idea to move that key derivation into setting up the TCP
> connection for resumption.   One consequence of nonce participation in key
> derivation is that pre-calculation of resumption keying material prior to
> the TCP handshake is no longer possible.  I would hope that a one-byte
> nonce in each direction will suffice, as the goal is reuse prevention, not
> injection of significant new entropy.  If significant new entropy is
> wanted, start over with a new key exchange, IMHO.
>

To have strong reuse prevention you need a long enough nonce that you have
a low probability of collision.

One concern here is that an implementation might have a defect where it
improperly erases ss[i] after use, in which case an attacker might
repeatedly exercise that defect and thus get key reuse.

-Ekr


Here's a sketch of one way in which this could be done.  First, reduce the
> resumption identifier size to 16 bytes from the current 18, and then send 8
> bytes of resumption ID + 1 byte of nonce in each direction for resumption
> in place of the current 9 bytes of resumption ID.  Those nonces then need
> to be folded into the existing tcpcrypt CPRF key generation framework that
> takes a 1-byte value in addition to the key.   One possibility (feels like
> a bit of a hack) is to take the upper half of the current 1-byte CONST
> value space for this purpose by forcing the most significant bit of each
> nonce to 1, and then running CPRF twice to include both nonces:
>         ss_a[i] = CPRF(ss[i], nonce_a | 0x80, K_LEN)
>         ss_ab[i] = CPRF(ss_a[i], nonce_b |0x80, K_LEN)
> After this, the master keys, mk[i], are generated from ss_ab[i] instead of
> ss[i].
>
> The result is 7 bits of nonce in each direction, so 14 bits of reuse
> resistance.  That seems ok, since reuse is not supposed to happen in the
> first place.  OTOH, there's no useful anti-replay resistance here, as one
> would need much larger nonces for that, so it's good that anti-replay is a
> non-goal.  However, Kyle's concern about changes to the core protocol
> applies to this sort of design, even though it doesn't add a new round-trip.
>
> > Kyle
>