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 17:37 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 46798128D69 for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 09:37:38 -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 4ou_NwVgEbdW for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 09:37:35 -0800 (PST)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 4CEDC126557 for <tcpinc@ietf.org>; Mon, 27 Nov 2017 09:37:35 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id z125so10733909ywb.0 for <tcpinc@ietf.org>; Mon, 27 Nov 2017 09:37:35 -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=SLr+PQhl2Gy28eEdtvHswjc7pEIvDQShrrRpJkLtRlc=; b=mQUYXFVcYwVAqDhL/tlVDLao+PkEYKcGnEYkKgQpYUHAim/a8BukynH7qr8JcBor3f JBo+5N4eThHC+5cYe3cfe5wpcdsyssymv9xutX0aNEYM20izmQG6gf7+oP1sbuxSiuJV g6nJDNdV/6//L+lhTAFwkj+A6f/2XyXb3X2GSA/f/XYqFvMnsE3jtJeURtO26abY70Rd V7m+bT/cxKPHJx/wQgkxTNB2JEVoY8jIz2zVemvt6LQa7xf1/BtYnClgZ9bdznywrQog 9EqJhehVURwCXF3T4oI4GmMx1ydcI4zXnW5X87GnOQtiwOrSHzZsuMuALHRhclP301Zz mbTw==
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=SLr+PQhl2Gy28eEdtvHswjc7pEIvDQShrrRpJkLtRlc=; b=jSJmzAxReugMePR//C4HtnRH87XIXcU8NUh0Ou8sAyoaGYSa88c+SUd3JNrmKLfiGj ywocx2P+VZzNAQByGUgv1mACczSjTheFgw9Is8ePB3xzxbq35mL7sSzTD4TKNLHsoI+/ a6lD7m5j/kTJ4AML66mhQkGHC+GUogwVnRULCmhrRKmBstafUiEQyAOkFz3+KgUJ019d ihL0Lb8gai2feRzN0/Z/gIohbXvjHUqSwZjXYguPdGw3+/l7crL4X+q6sM8iP/A+k101 6nkMWg+lPknHaTa220Y4MMGYvaIyuccgxBMOm4VjJsP3D+wkhWpPNytKmVYDGnWKTCk5 vHaQ==
X-Gm-Message-State: AJaThX7i6JHYlsox3gOWF/5UIPRojKNdUAYPBmx/k4VZ0gAudJlF1651 zqgClgTY5Cf0Brf9zZ9oqzf/90Wm4vAJLroj8UkeQS4uLFM=
X-Google-Smtp-Source: AGs4zMaFsHcs/yLBT2FSj3WognjlIQBH9barWncArkHtL6ARNeMR38zY3Dx2p3EtDNk6IQ43In6A/PYRyOD1eWRJNfw=
X-Received: by 10.129.87.210 with SMTP id l201mr25970137ywb.2.1511804254367; Mon, 27 Nov 2017 09:37:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Mon, 27 Nov 2017 09:36:53 -0800 (PST)
In-Reply-To: <CAJU8_nWMn0_SSLUH+reS5La4J7t0uEN5u2zC8XFRXDMOffc1Qg@mail.gmail.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> <CABcZeBNQEs6BKnxzQOuN4A4qvEDsk8kGQLt6S9Wy0OXsJ3u5cw@mail.gmail.com> <CAJU8_nWMn0_SSLUH+reS5La4J7t0uEN5u2zC8XFRXDMOffc1Qg@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 27 Nov 2017 09:36:53 -0800
Message-ID: <CABcZeBP2mN-Y3GFda3mqawFuFFqtzpwpsceseE5FNMH1iSpFPQ@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: Daniel B Giffin <dbg@scs.stanford.edu>, "Black, David" <David.Black@dell.com>, 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="001a114575768d46a6055efa5ba6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/38b0Y1gJCziXMZRTFBmrwgENeys>
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 17:37:38 -0000

On Mon, Nov 27, 2017 at 9:24 AM, Kyle Rose <krose@krose.org>; wrote:

> On Mon, Nov 27, 2017 at 10:07 AM, Eric Rescorla <ekr@rtfm.com>; wrote:
> > On Mon, Nov 27, 2017 at 5:36 AM, Kyle Rose <krose@krose.org>; wrote:
> >> 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.
> >
> > Hmm.... This seems like kind of an odd argument given that the design of
> > tcpcrypt explicitly eschews the kind of techniques that have been found
> > to be important to high resumption rates in protocols such as TLS.
>
> Were you thinking of stateless resumption (e.g., tickets) or something
> else here?


Yes.



> My recollection from a mailing list discussion on tickets
> was that ENO and tcpcrypt deliberately make some tradeoffs in session
> resumption for performance given the constraints of TCP, specifically
> in terms of option space: there simply isn't enough option space to
> encode sufficient state, and the realities of middlebox ossification
> probably dead-end enhancements like EDO on the public internet.
>

> Speaking personally (not as chair), I also feel like tcpinc sits in a
> niche in which stateless resumption adds more complexity than is
> justified by the probable use cases. That's probably begging the
> question some, as stateless resumption might alter that distribution,
> but it's not clear the extra round trip for repeated connections to
> the same machine would be tolerable for many WAN use cases in legacy
> protocols, where tcpinc is focused.
>

I don't really think it's really worth relitigating this; I'm merely
observing
that if you want high resumption rates then you want stateless resumption.
As for the question of option space, I'm not persuaded it wouldn't
be possible to have stateless resumption with the same number of
round trip times if you were willing to be a bit more careful about
how you handled failure.


>> 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.
> >
> > I agree that you should do another WGLC if you make this change (or
> either
> > change, for that matter.) But I don't think that's a reason not to make
> > changes.
>
> Agreed (though I am not sure Mirja will be happy to hear that). My
> comment about scope creep is simply that the WG came to a consensus on
> this topic (resumption tradeoffs) long ago, so I'm not sure we should
> be second guessing that judgment at IETF LC.
>

I'm not sure what you think is being second guessed. Taking a step back, the
way we got here is that I observed that the specific resumption design here
is extremely brittle (and far more brittle than in other protocols that we
design)
and that the warnings about how you had to handle the keys were insufficient
to allow the users to know. This then turned into a discussion about how
to make the protocol less brittle. It's certainly within the WG's
discretion to
not address this (though I personally think you ought to) but if so, it's
imperative
that it be adequately documented what the risks are, which the current text
does not do.

With that said, it's not clear to me that the WG actually did have consensus
that this brittleness was a good tradeoff. Was this property in fact widely
understood? Speaking only for myself, it really only came into focus for me
when I did my review.

-Ekr


> Kyle
>