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

Eric Rescorla <ekr@rtfm.com> Fri, 24 November 2017 18:34 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 F2A1B127419 for <tcpinc@ietfa.amsl.com>; Fri, 24 Nov 2017 10:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 O1z69m-EOlSd for <tcpinc@ietfa.amsl.com>; Fri, 24 Nov 2017 10:34:38 -0800 (PST)
Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 2C27E127977 for <tcpinc@ietf.org>; Fri, 24 Nov 2017 10:34:36 -0800 (PST)
Received: by mail-yb0-x22a.google.com with SMTP id n185so8293402yba.6 for <tcpinc@ietf.org>; Fri, 24 Nov 2017 10:34:36 -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=Pvf2WUchHYmK3/RqiUePx/AWa8uxKHhUViG5rnH4YrU=; b=jX8wPAtQHtl7CPa3DlTXCSI88sMk7suPfRrHEU2V40eKPMIbUcbSFEdxeGI29J4MXm DlsaAOfH7XB1sZwVfdolOmiEYnekKHKDHkCHUbdMngkpH6FTkmT7Q5iw1Les6VUlRqOw stbJ5EOn5ScE9v/iX0Tc0si6/mIYh5ZZMtn6CbjpZ1DNQ3xN8Xk0pPyJZ+C1m6dtLeQy c2PmIDcCCGARjDGhbTKx9cjvVNm3fO+Ci8euJeV3k4s+dus3/pDdYgmiPDDnYKGgiIcs nABubCYKu1VWB9JcVoSg5M/q8G9orRKXQMVlWlHDFc0FyF4n6er+1zlBWiYtI66QjHa7 kyHQ==
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=Pvf2WUchHYmK3/RqiUePx/AWa8uxKHhUViG5rnH4YrU=; b=AMulLaIfXWM0/LOwQJbv5+y1/Gkv8UTviZE9qLIW4BUH7eZOzNlOQOVVdR/Vtlga8l Zu0WIgpmb2oYfhfo80cxmxbBkTmOGY014hFKra3PE8s8tQD1vN7h40ckfimJBY6seAVV 6hW1rrIVJi3ZqGqW9YZroMQuI2PuADsbr3f10IRwFb5RydRNiGwEb4U/pKb1rG87bmBo RwLCjnsLuHJJh822rRTzmNA+obfJr0TWPTrsqHbwXvrIXv/KC7d5P4u5Jizs+OfEMXgm UcXaMmyXqnsWiA+OKmBLNn0ASHYBZU10YjYBWl9QFubAr0AEjMukY9r6OiUXKpI9pT06 yiZw==
X-Gm-Message-State: AJaThX4IN991y5Qz/NDz3AR9pDv4jf+PkXsPk3rv9pJOgfDdMrVsBA4e wHgkfCUTgnjdcmxfz+n9a/F6y389zyGKLnNnrnAPNQ==
X-Google-Smtp-Source: AGs4zMbAsogNql5KAI3AGrsoxQQo+hB+q6n1DTmCKPwfvfal4cjevUcyztNu3bwKDiV8aiMIuFcVgs3ULy1+ra8ML4Y=
X-Received: by 10.37.107.82 with SMTP id o18mr17897686ybm.293.1511548475305; Fri, 24 Nov 2017 10:34:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Fri, 24 Nov 2017 10:33:54 -0800 (PST)
In-Reply-To: <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> <20171124182842.GA80062@scs.stanford.edu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 24 Nov 2017 10:33:54 -0800
Message-ID: <CABcZeBORGhsgWem3P6GS=1qfkwBEZxX=CBGCOoU3R_+MsO4FrQ@mail.gmail.com>
To: Daniel B Giffin <dbg@scs.stanford.edu>
Cc: "Black, David" <David.Black@dell.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>
Content-Type: multipart/alternative; boundary="089e08267d30ee895b055ebecddf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/toaZ9ChG0d2ZUG0oZXUQICsASo4>
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:34:41 -0000

On Fri, Nov 24, 2017 at 10:28 AM, Daniel B Giffin <dbg@scs.stanford.edu>;
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 <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
>