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:57 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 3701D128D69 for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 09:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=unavailable 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 ti0bBxVZfl5k for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 09:57:41 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 1E39D1292AE for <tcpinc@ietf.org>; Mon, 27 Nov 2017 09:57:41 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id b85so33557461qkc.13 for <tcpinc@ietf.org>; Mon, 27 Nov 2017 09:57:41 -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=G6qGBjNmzUf1D47ZWpVLnhEULrX6qFM/wbr7n9qaPlc=; b=CBWLd1RmKluIJG61bW5VjgwLwTFXLv6u6D+pjYiVpo6195bNDiu5/73lL++4twbsX/ otlDrWMWG5ARMxRTfzkOO+/EvSNlYKHbdK9pTN1QcMslQCbqeUXalaPHFetvgavB743o pAU5no7eHqxDOiB6+sr1FOoon2D2TqUwYmF0k=
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=G6qGBjNmzUf1D47ZWpVLnhEULrX6qFM/wbr7n9qaPlc=; b=f4US/Ru4Pq5keB3VZxOi1y9e5HBSPD2Yt2tPhi5Lj0TarzY4STXLBWrFYA/VdHxuhY YAeRH61w7bIt57fUdRFvi2S6KVMMNQ4wRIMrSCjfNbNIQ0SoJRQLRXDfa5gFx2C3y7tU 2MjYKJP7erTMwDT/C381aIOvoANYuu5BT22ceDaljhBax/vFuNvrgvTnq2D58AZKc0Vw 0Kz2vNxO+qqfOMz9v/5KDgX7bQO0NBFqOgjS/EiKu8viumx37rKCddBieTT2D00y7EYZ dWg5Ne0ScTBc4kEZG6PpTerTCS6JiaCEGDpubdtnddL0BO59JSi1MoEhufWIXGLcUT7i 2zlw==
X-Gm-Message-State: AJaThX7TevnjSyEd5k9sng91womVjourPwrCGKKyd8gtV1lcS357haxa 48CpYnBt37OY2odmpvUetjX1TdK3IGQJjEdPXg7ki+ZnsFA=
X-Google-Smtp-Source: AGs4zMZ0x/VD9T28I1RGIkVltNrjIrgr93JVZW549WgyGZulfoQILMERE7mEiV9vvG7emJHs8bEMbMEwD5XLl3SKshc=
X-Received: by 10.55.16.162 with SMTP id 34mr61418508qkq.78.1511805460012; Mon, 27 Nov 2017 09:57:40 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.195.1 with HTTP; Mon, 27 Nov 2017 09:57:39 -0800 (PST)
X-Originating-IP: [2001:4878:a000:3000:3180:77a4:e5cf:f855]
In-Reply-To: <CABcZeBP2mN-Y3GFda3mqawFuFFqtzpwpsceseE5FNMH1iSpFPQ@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> <CABcZeBP2mN-Y3GFda3mqawFuFFqtzpwpsceseE5FNMH1iSpFPQ@mail.gmail.com>
From: Kyle Rose <krose@krose.org>
Date: Mon, 27 Nov 2017 12:57:39 -0500
Message-ID: <CAJU8_nWk_Opuj+m4jv79qwFMUGqi5=JMk3S_3QfJLahOjL+77g@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/P2F80IRR0_c6PaMBEgE2gPXNIz4>
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:57:43 -0000

On Mon, Nov 27, 2017 at 12:36 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
> On Mon, Nov 27, 2017 at 9:24 AM, Kyle Rose <krose@krose.org>; wrote:
> 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.

For a server pool, I completely agree.

> 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 would be interested in an (OOB) conversation on your thoughts here.

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

I was referring specifically to the resumption tradeoffs (rate vs.
performance). That said, all I can find is this:

https://www.ietf.org/mail-archive/web/tcpinc/current/msg00919.html

which doesn't actually talk about that tradeoff, but rather about the
charter's requirement for forward secrecy.

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

No, I think you're right that this wasn't widely understood, or at
least not discussed. That wasn't what I was referring to, however: I
do think the brittleness is worth at least discussing on the list
(check) and seeing if there's consensus to make a change to the
protocol or to add a crystal clear warning to the draft explaining the
critical importance of not reusing SIDs.

Kyle