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

Kyle Rose <krose@krose.org> Mon, 27 November 2017 17:24 UTC

Return-Path: <krose@krose.org>
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 DEA6B128D69 for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 09:24:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 v2-aRNwlHkQq for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 09:24:18 -0800 (PST)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 0DE04128BBB for <tcpinc@ietf.org>; Mon, 27 Nov 2017 09:24:18 -0800 (PST)
Received: by mail-qt0-x231.google.com with SMTP id i40so28834115qti.8 for <tcpinc@ietf.org>; Mon, 27 Nov 2017 09:24:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NKqx+lC6nlHQOfNFnhR3T5+KlVRX5Ef8hni17ks3+Fk=; b=WllPv92slyaQ4dma8JmSAfjrZDldGqr7KzIqBM1KGkxdbN6x7BiI5oq0CM2kUYqABp uMNo2J9j6uqBSnqIwb7XrVJWkfUTClQfxe4/BuG+NSr0rkKNcx/n7XoHLqEsP5MjbAL/ vZlbXo0Go+vu+Ff4HQsP3b5TRHZEyU8LvCXjo=
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=NKqx+lC6nlHQOfNFnhR3T5+KlVRX5Ef8hni17ks3+Fk=; b=KQ9S+K10NvQtxZG72ThtQThpGNvoHTKnVIS/5GsyCMwd3/vHURBkToTHtMewaAifIo z6y2up6lrw2I0QhZFAtcpFLRJjTzje1uXccFj0c5txt7qQ70uHOVMwVzimlA7qlRJU04 zALhXyfjtyDKcSPRuFSTHZekPC1Xz8WUuMPUg/rq7zWpS17MZnO/Y+sbKdmvQvLq7dh/ AwbHsvvNAv01uQ3zCO9BaGc9yOjwsSnOrMAlQs32oGp24IZQCAWhxqAILNN1bE5xwtZK PdhqOnVRmapODVIypPpvPws+aX0lZvYsOH6SEPUmUhcsaIMhmhguEBCFnlec0cBqFDW+ hUiA==
X-Gm-Message-State: AJaThX4/32i/WIvjb4jJeq7E0dPg6gU0FIYi0AvHev0yq/rrdLSgKN4W gVjKTjQ6rcVqLTBBQ4qIY+Wram/7YX9/EsyjbJ7fhA==
X-Google-Smtp-Source: AGs4zMaxtMZkfbZWfgRwk3qATftmIVcIyf7kSAPcOkWK7eyMF0WeKuJreTZ+mmdnavpFd7YK86XlqdcqTGOkejEO41I=
X-Received: by 10.200.28.7 with SMTP id a7mr61260842qtk.206.1511803456957; Mon, 27 Nov 2017 09:24:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.195.1 with HTTP; Mon, 27 Nov 2017 09:24:15 -0800 (PST)
X-Originating-IP: [72.246.0.14]
In-Reply-To: <CABcZeBNQEs6BKnxzQOuN4A4qvEDsk8kGQLt6S9Wy0OXsJ3u5cw@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>
From: Kyle Rose <krose@krose.org>
Date: Mon, 27 Nov 2017 12:24:15 -0500
Message-ID: <CAJU8_nWMn0_SSLUH+reS5La4J7t0uEN5u2zC8XFRXDMOffc1Qg@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
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: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/jqGtCk9ziersO_phzxLkzM32sfQ>
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:24:20 -0000

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

Kyle