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

Eric Rescorla <ekr@rtfm.com> Mon, 27 November 2017 16:44 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF06127337 for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 08:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZVjguXdk3Xh for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 08:44:30 -0800 (PST)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A76BA126B6D for <tcpinc@ietf.org>; Mon, 27 Nov 2017 08:44:28 -0800 (PST)
Received: by mail-yw0-x235.google.com with SMTP id p74so12101848ywe.2 for <tcpinc@ietf.org>; Mon, 27 Nov 2017 08:44:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cQv4rDw5yYocM8RzNiU6NbyRn5QckBwx2dk4lnHpzqk=; b=t3XWz6NGItlMOqFdhWCkXelf6UVUkYPWPZ1AMW5Gk0JSfzBryhMahPSBPBMYws8DGz Vv8JQBVriTpTi4nOYRmD1r+5tTuHMEc1Ggqb0u8r4cqWXnWdCHLS2AsD3mFB5JqPDqj0 vXuUMfMg4ERKsa1TIgacJHlJ0DtcmNzcYX3ewTo9jhn9PxDr5mSm6325KYaXCvBPkuyc o+mDetZMWt4tVy5QTcRVeNwRDRaFaqYFle/5o4HtZ1U5h8vtusBQ+02/62iNYt9Qu6Iw AZwDOd1I7ZZIeeHnNzzEI/5KvAge+BWrJvBs5rFjFzDMoIWq7ktdPubTZ8aqMjnBhfMP /1hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cQv4rDw5yYocM8RzNiU6NbyRn5QckBwx2dk4lnHpzqk=; b=LMKIaGMpdP3dPjTXxejLc1pSFLY16LK0g11EK905bbOm1nCK6B4HN2Jl5hBUeBFBZf tAtE3dOLUaZU1jGqsqv4HYUu0oLKV0py/4chotWJwa09Rq83nh2FWWdRanZXVmFJbUkw 4ZJPjYb+71IYJ+TIB0PCU7V55BPuiGJO5VajoD0KINADZlGjkmFrg7ZfKINBWlUlxrMZ op63aHEGz79pi9KoNeFb63twXnW1bNcS8QTAYgk00xy2GLx3a6Hu3RPEL7SyqtE0xRd4 2zZCcrpPTemyVNgZUPJ56OzGVNVQrOaJxLcIJqI6LmJeI45fpilPQkItAjxLzFeVXGpq 8Kkw==
X-Gm-Message-State: AJaThX7BDwGmcSR9+kYLHCj53cjSXTrrEc93FTZoouWvrfTu5j4ir3Yp XktJaiiP4XU/in/p719TRku7e/Au7QvT3DajZ2ftMA==
X-Google-Smtp-Source: AGs4zMZY2UzNVEowTXmUDwBj8hsu2FUAPWqBzMRdHUNAJjDPGABr/uhZXIw3LYFiWV0vTkM28AIFZBj3vhQbZ2D7jcI=
X-Received: by 10.129.173.94 with SMTP id l30mr25791503ywk.5.1511801067749; Mon, 27 Nov 2017 08:44:27 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Mon, 27 Nov 2017 08:43:47 -0800 (PST)
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD8937F@MX307CL04.corp.emc.com>
References: <151036992713.398.18032326140786383584.idtracker@ietfa.amsl.com> <20171117121703.GE57159@scs.stanford.edu> <CABcZeBMBnMB425pu5bc9kjuAqjRDnuVYQK=8P9vQBwURctCTZQ@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD6E57E@MX307CL04.corp.emc.com> <20171124182842.GA80062@scs.stanford.edu> <CABcZeBORGhsgWem3P6GS=1qfkwBEZxX=CBGCOoU3R_+MsO4FrQ@mail.gmail.com> <CAJU8_nXA_1L_XVJAMGj+L4JY-so+LO79pxt_s=BTLWj_g47f_Q@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD8937F@MX307CL04.corp.emc.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 27 Nov 2017 08:43:47 -0800
Message-ID: <CABcZeBNJHJX8H+vnkkUEMDtiSz5NKKF4gA32nY9yZUUrAyA6SA@mail.gmail.com>
To: "Black, David" <David.Black@dell.com>
Cc: Kyle Rose <krose@krose.org>, Daniel B Giffin <dbg@scs.stanford.edu>, tcpinc <tcpinc@ietf.org>, "tcpinc-chairs@ietf.org" <tcpinc-chairs@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-tcpinc-tcpcrypt@ietf.org" <draft-ietf-tcpinc-tcpcrypt@ietf.org>
Content-Type: multipart/alternative; boundary="f403045ea7169d585e055ef99dcc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/rRNeuf4BbezSG3hgNTYCwH56Hw4>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Nov 2017 16:44:32 -0000

On Mon, Nov 27, 2017 at 8:30 AM, Black, David <David.Black@dell.com>; wrote:

> Inline ...
>
> > On Fri, Nov 24, 2017 at 1:33 PM, Eric Rescorla <ekr@rtfm.com>; 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
>