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

Daniel B Giffin <dbg@scs.stanford.edu> Tue, 28 November 2017 04:11 UTC

Return-Path: <dbg@scs.stanford.edu>
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 0805C129443; Mon, 27 Nov 2017 20:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AGO-AKyNcXAI; Mon, 27 Nov 2017 20:11:27 -0800 (PST)
Received: from market.scs.stanford.edu (www.scs.stanford.edu [IPv6:2001:470:806d:1::9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F50412943F; Mon, 27 Nov 2017 20:11:27 -0800 (PST)
Received: from market.scs.stanford.edu (localhost [127.0.0.1]) by market.scs.stanford.edu (8.15.2/8.15.2) with ESMTP id vAS4BPPU076772; Mon, 27 Nov 2017 20:11:25 -0800 (PST)
Received: (from dbg@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vAS4BOuZ000711; Mon, 27 Nov 2017 20:11:24 -0800 (PST)
Date: Mon, 27 Nov 2017 20:11:24 -0800
From: Daniel B Giffin <dbg@scs.stanford.edu>
To: "Black, David" <David.Black@dell.com>
Cc: Kyle Rose <krose@krose.org>, Eric Rescorla <ekr@rtfm.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>, David Mazieres expires 2018-01-14 PST <mazieres-ddragqirgwht7ezx2d39a3jw72@temporary-address.scs.stanford.edu>
Message-ID: <20171128041124.GA42654@scs.stanford.edu>
References: <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> <CAJU8_nWk_Opuj+m4jv79qwFMUGqi5=JMk3S_3QfJLahOjL+77g@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD89888@MX307CL04.corp.emc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362FD89888@MX307CL04.corp.emc.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/HuYht1xbPx8sIO73clnpLzE9gmo>
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: Tue, 28 Nov 2017 04:11:29 -0000

Whether or not we decide to go back to the WG to discuss the
mechanics of session resumption, we could make lightweight
changes to the current protocol in this last call that would
facilitate any "upgrades" that appear necessary after
deployment has begun.

To wit, we propose:

  - Replace the first byte of INIT1_MAGIC and INIT2_MAGIC
    with a "version" byte.  Implementations of the current
    protocol must send a zero version-byte, and must ignore
    what they receive.

  - When receiving ENO suboptions for tcpcrypt TEPs with
    v=1, which are "resumption suboptions": if the
    resumption identifier-half is not the expected length
    (9 bytes), treat this suboption as a bare TEP byte with
    v=0; that is, an invitation to fresh key-exchange with
    that TEP.  This *almost* goes without saying; the
    current draft doesn't say what to do in this case of
    "malformatted" resumption identifiers.

The version byte is intended to allow implementations of
future protocol versions to identify each other (by sending
the highest version they support), which then allows them to
perform "advanced" resumption signaling later.

And specifying how "advanced" resumption suboptions collapse
into simple TEP advertizements (instead of being ignored
altogether) ensures backwards compatibility with the current
protocol, even without the version mechanism.

These changes would permit several backwards-compatible
resumption mechanisms to be added later:

  - Ekr's idea to send nonces on the first ACK in each
    direction
  - David Black's idea to combine some nonce-bytes with the
    resumption identifiers
  - Ekr's idea to send nonces in an extra handshake in the
    TCP datastream

Again, we don't intend to reject the possibility of more
agressive changes, but if we want to go ahead with something
now then the above minor changes provide an upgrade path if
it becomes necessary.

If this sounds attractive, the above changes can be added to
the new draft (ready in the next 24 hours) that addresses
recent reviews.

d