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

Daniel B Giffin <dbg@scs.stanford.edu> Fri, 24 November 2017 18:28 UTC

Return-Path: <dbg@scs.stanford.edu>
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 A1CB6127419 for <tcpinc@ietfa.amsl.com>; Fri, 24 Nov 2017 10:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 AzbVnlhTbAba for <tcpinc@ietfa.amsl.com>; Fri, 24 Nov 2017 10:28:45 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (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 26990127058 for <tcpinc@ietf.org>; Fri, 24 Nov 2017 10:28:45 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vAOIShnj084890; Fri, 24 Nov 2017 10:28:43 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAOISgle018656; Fri, 24 Nov 2017 10:28:42 -0800 (PST)
Date: Fri, 24 Nov 2017 10:28:42 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: "Black, David" <David.Black@dell.com>
Cc: Eric Rescorla <ekr@rtfm.com>, tcpinc <tcpinc@ietf.org>, Kyle Rose <krose@krose.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>
Message-ID: <20171124182842.GA80062@scs.stanford.edu>
References: <151036992713.398.18032326140786383584.idtracker@ietfa.amsl.com> <20171117121703.GE57159@scs.stanford.edu> <CABcZeBMBnMB425pu5bc9kjuAqjRDnuVYQK=8P9vQBwURctCTZQ@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD6E57E@MX307CL04.corp.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD6E57E@MX307CL04.corp.emc.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/wTVzWqRCG8ZbyVZcDFIJGrRFuW0>
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: Fri, 24 Nov 2017 18:28:47 -0000

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.

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 <ekr@rtfm.com>;
> Date: 11/18/17 5:05 PM (GMT-06:00)
> To: Daniel B Giffin <dbg@scs.stanford.edu>;
> Cc: tcpinc <tcpinc@ietf.org>;, Kyle Rose <krose@krose.org>;, tcpinc-chairs@ietf.org, The IESG <iesg@ietf.org>;, draft-ietf-tcpinc-tcpcrypt@ietf.org
> 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