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 13:36 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 A534F127517 for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 05:36:39 -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 DE8F0lzZOXyb for <tcpinc@ietfa.amsl.com>; Mon, 27 Nov 2017 05:36:38 -0800 (PST)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 7E50B12895E for <tcpinc@ietf.org>; Mon, 27 Nov 2017 05:36:36 -0800 (PST)
Received: by mail-qk0-x234.google.com with SMTP id b85so32378449qkc.13 for <tcpinc@ietf.org>; Mon, 27 Nov 2017 05:36:36 -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=hO7QadCG/2n5VDg/6P+b6jgKit3k+MKb7QYuRGc6RB4=; b=LNkm7yFMEmhqqjnlhPhHSkjqBOhcLrknOT/6aJ9SEZVFJ5AVB8Abdkf0KjAHEqmunx Y+SqdjBfIgMlWiN+QNO6FY0/ywA0IYiaHAybtz2KnqSWMGO9ZqEuolZGxyJhreaYjz7b cym0FJy7JPuriyzwhHOf4/5YQ37wQzhNiSQ38=
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=hO7QadCG/2n5VDg/6P+b6jgKit3k+MKb7QYuRGc6RB4=; b=cx0Crxzfu1XH4EYC14+iINsTh3BOvbCDfhgX7UHKxt3OLqwHctt6t+d7VcF9wxQJwL F9g9MiLE2v0rnMO/eiN19bgo1Ly2CHll6fW6+fGbHLAFJ5dY6v9MzNTLrB385u5uB7s1 YpJbTy6OKtuOZ3GjdLewLl7sM/SJ6vni4ghZTDSQ8bPiFWphIGZ+RbfpvfmHdQBTE37U PsA09cRz8EM3d6WQ2gFDcKZUedEgkm1XW5vmm2prhyZLi7Sa61WdvGu6GOekgKpTM3gg lfKlago5I1sR/QhzHNLCDMt5VjDR7Vud39ZlU8+bWViJHX+WXCJWGboGXpcQJI2Xv8YR 2enQ==
X-Gm-Message-State: AJaThX5w/UAwCyc1itEyDiLcRO9KCNLC8OWWH1cV5DG9nHIW5zuXpMTi pjtvBMfdZWUFY0XnUdUOB5aSAgMEpr5jg0zXwwVsCQ==
X-Google-Smtp-Source: AGs4zMYx3iRNQLFU8F062eW9KXB8B2XMm2fqUqrjsVxMiJ/nGaQZF3sV1udwj/NxgeimJg9TMcyDwQOicP0cudaQKEU=
X-Received: by 10.55.217.151 with SMTP id q23mr36316539qkl.9.1511789795313; Mon, 27 Nov 2017 05:36:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.12.195.1 with HTTP; Mon, 27 Nov 2017 05:36:34 -0800 (PST)
X-Originating-IP: [2001:470:1f07:121:922b:34ff:fe5d:efa3]
In-Reply-To: <CABcZeBORGhsgWem3P6GS=1qfkwBEZxX=CBGCOoU3R_+MsO4FrQ@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>
From: Kyle Rose <krose@krose.org>
Date: Mon, 27 Nov 2017 08:36:34 -0500
Message-ID: <CAJU8_nXA_1L_XVJAMGj+L4JY-so+LO79pxt_s=BTLWj_g47f_Q@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/mPrl3Of5YJ4BgqVHnjw56_6L7eo>
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 13:36:40 -0000

On Fri, Nov 24, 2017 at 1:33 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
> 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.

Whether this is acceptable to mandate or not really depends on the
goals of session resumption. If the goal is simply to save compute
resources for key exchange, then this seems like a reasonable change
to make; but if the goal is to drive down time-to-first-byte-delivered
to no more than a normal TCP connection, then this will negate that
advantage, significant especially for lengthy paths.

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.

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.

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

This may be the best compromise: it provides a measure of misuse
tolerance within the existing performance constraints.

Kyle