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

"Black, David" <David.Black@dell.com> Mon, 27 November 2017 16:30 UTC

Return-Path: <David.Black@dell.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 07E71128854; Mon, 27 Nov 2017 08:30:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=hwjNnuVU; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=f8YHcV/O
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 Zrm5zWk_LIDF; Mon, 27 Nov 2017 08:30:53 -0800 (PST)
Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49114127337; Mon, 27 Nov 2017 08:30:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1511800253; x=1543336253; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8Vmp0Ou1H+9rMAKQvdjJjOXN3RSW0f+nAtDyfGf/PyE=; b=hwjNnuVUjGgp/hM540+OQVpFWmJDOTzYt/nEfuQc5xapR0sWtKw+KoV/ oto3dA2D6G8gAmFHFF3co/YBcWfdTQnciV1nVag1ShiO52sIlt0VFR3VZ ynnn5J92r+Xcf4qf0E4+5CyBzbvJNmDJqFyafaDjTRgSzlUHgADh5OHBX s=;
IronPort-PHdr: 9a23:7S40+RR5blThmN4V6zy06eoA0dpsv+yvbD5Q0YIujvd0So/mwa67ZBODt8tkgFKBZ4jH8fUM07OQ6PGwHzRYqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjSwbLdxIRmssQndqtQdjJd/JKo21hbHuGZDdf5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXMTRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KpwVhTmlDkIOCI48GHPi8x/kqRboA66pxdix4LYeZyZOOZicq/Ye94RWGhPUdtLVyFZAo2ycZYBD/YPM+hboYnypVoOogexCwajH+7v1iRHi3vq0aEmz+gsEwfL1xEgEdIUt3TUqc34OKkPXOCx1qbH0TbDY+tL0jnz8ofIbBEhruyCUbltdsffx1MgFx3EjlqNs4DoIjeV2f4RvGiY9OdvSPygi2ojqw1rvjevwcIsh5DPi4kIyV7E7T10zYc2KNGiVkJ2b8CoHIFNuyyaOIZ6WMcvTmJwtCon1rEKo4C3cSYJxZg9yBPSZOaLf5WG7x/gTOqRLyl3iXF5dL+6ghu/8ketx+nyVsSx0FtFszBKnsfJu3wQyhDc8c2KR/Rz80qi2TuC0R3Y5PteLkAuj6XbLoYswrs3lpUOr0vOBjT2mEDqjK+OcUUk5/So5/znYrr4op+cMJd5hR/lMqs0lcGzG/k3PRYKX2if4Oi806Dj/VHiT7VNk/02lLTWvI7AKcQavq65AwpV04k55xmjCDem1cwUnXgBLF1bZBKKl4nkNlLULPzmA/qznU6gnCpryv3JJLHsBpbAImDGkLj7fLZ970BcyBA0zdBa/59aBKsOIOzyWkDsrtDVExs5PBaozObkE9hyy50RWWaLAqODLKzStlqI6vo1I+aQfI8VpCr9K/896vHzl382g1EdfbWw0ZsWdn+4AvpmL1yFYXXwmtcBEGEKsRYnQOz2lFKCSSJcZ2yyXqIk+jE2E4OmApnfRoCjmrCB2z27HpJObGBcFl+MCWvod5mDW/oUaSKdPNRhkjMfWLigVYAhyR+uuBX9y7p9Iere4jcYuo771Nhp++3Tkgk/9SBoAMSF0mGNSX17knoUSD82xq9/oFZ9ykyY3Kh5nfNYCdJT6+lOUgcgOp7W1/Z6BMzqWgLdYteJT06rQsm6DjEpT9IxxcMBbl18G9q8khDD0TCmA7gPl7yEV9QI9ff/znz8b/x60HuOgKo7iEIrashVMnarwKll+F6XT6PTkk7RrauxfqMG2CeFoGqA10KUoE9dFgV3VPOWc2oYYx6ch9Dw7UCGB5OnF7UreEMV5cecK6cMQNnghlZuSPrnPJLVZGfnyDT4PgqB2r7ZNNmiQG4axiiITRFcyw0=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2FEAACPPBxah2Ka6ERcHAEBAQQBAQoBAYJsgSZ+JweDeIogjxSBfZZtgU5DCoU7AhqEVT8YAQEBAQEBAQEBAQIQAQEBCgsJCCgvgjgkAQ5IIQUyAQEBAQEBAQEBAQEBAQEBAQEBFwI9EwEBGAEBAQECAQ4VEQwfBhQBBAsCAQgOCgICBiACAgIwFRACBAENBQiKEggBpkqCJ4MQh2oBAQEBAQEEAQEBAQEBARkIgQ+CK4E2UYFWgWcBgh2BDoUegxMxgjKiRQYCqFiWDQIEAgQFAhqBOh+CCm+Cd4JPEwwZgU53iROBFAEBAQ
X-IPAS-Result: A2FEAACPPBxah2Ka6ERcHAEBAQQBAQoBAYJsgSZ+JweDeIogjxSBfZZtgU5DCoU7AhqEVT8YAQEBAQEBAQEBAQIQAQEBCgsJCCgvgjgkAQ5IIQUyAQEBAQEBAQEBAQEBAQEBAQEBFwI9EwEBGAEBAQECAQ4VEQwfBhQBBAsCAQgOCgICBiACAgIwFRACBAENBQiKEggBpkqCJ4MQh2oBAQEBAQEEAQEBAQEBARkIgQ+CK4E2UYFWgWcBgh2BDoUegxMxgjKiRQYCqFiWDQIEAgQFAhqBOh+CCm+Cd4JPEwwZgU53iROBFAEBAQ
Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2017 10:30:52 -0600
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Nov 2017 22:30:51 +0600
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vARGUl0v030840 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 27 Nov 2017 11:30:50 -0500
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vARGUl0v030840
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1511800251; bh=rH3tO/qcpMkpy/PYYgTOwAvPxck=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=f8YHcV/OmBBxLfGxiE0H9uP4rpyAOE3mcPwXmSpY3R8H6KsXOkrDn6QwYbG2JiN9q 4AzvdXJO/zcsWhKp6cUTYcFkrPOzOkao5YNgDMeLYJrJOPTr1cRifq0yZEn4J9iIuu w9cSuwaCIe+sbpcQixA1ArneJFaldV3DJzLHkuu0=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vARGUl0v030840
Received: from mailusrhubprd03.lss.emc.com (mailusrhubprd03.lss.emc.com [10.253.24.21]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 27 Nov 2017 11:30:40 -0500
Received: from MXHUB311.corp.emc.com (MXHUB311.corp.emc.com [10.146.3.89]) by mailusrhubprd03.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vARGUhMK017805 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 27 Nov 2017 11:30:43 -0500
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB311.corp.emc.com ([10.146.3.89]) with mapi id 14.03.0352.000; Mon, 27 Nov 2017 11:30:43 -0500
To: Kyle Rose <krose@krose.org>, Eric Rescorla <ekr@rtfm.com>
CC: 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>
Thread-Topic: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpcrypt-09: (with DISCUSS and COMMENT)
Thread-Index: AQHTWprePuW0lReuTEGF9kEkArM1jaMY2o+AgAJHWQCAAsH4LIAGXtcAgAABdACABGPsAP//vTuA
Date: Mon, 27 Nov 2017 16:30:42 +0000
Message-ID: <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>
In-Reply-To: <CAJU8_nXA_1L_XVJAMGj+L4JY-so+LO79pxt_s=BTLWj_g47f_Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd03.lss.emc.com
X-RSA-Classifications: public
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/HKflYDvXhW9LwV58_uNfNd-cTp8>
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:30:55 -0000

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

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