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

David Mazieres <dm-list-tcpcrypt@scs.stanford.edu> Mon, 13 November 2017 21:24 UTC

Return-Path: <dm-list-tcpcrypt@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 6BCF512940B; Mon, 13 Nov 2017 13:24:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 BqDlO6d7UtrY; Mon, 13 Nov 2017 13:24:01 -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 A52421201F8; Mon, 13 Nov 2017 13:24:01 -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 vADLO0It083375; Mon, 13 Nov 2017 13:24:00 -0800 (PST)
Received: (from dm@localhost) by market.scs.stanford.edu (8.15.2/8.15.2/Submit) id vADLO0OQ067518; Mon, 13 Nov 2017 13:24:00 -0800 (PST)
From: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "Black, David" <David.Black@dell.com>, "tcpinc@ietf.org" <tcpinc@ietf.org>, Kyle Rose <krose@krose.org>, "tcpinc-chairs@ietf.org" <tcpinc-chairs@ietf.org>, "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "draft-ietf-tcpinc-tcpeno@ietf.org" <draft-ietf-tcpinc-tcpeno@ietf.org>
In-Reply-To: <CABcZeBPxOaK3DN5u0ohizt8rAQ+tShMuOcdpJBJ-2fmMJuQWgA@mail.gmail.com>
References: <151036581280.449.10740505473540594433.idtracker@ietfa.amsl.com> <CE03DB3D7B45C245BCA0D243277949362FD495EF@MX307CL04.corp.emc.com> <CABcZeBPfk6Pi=_UPvTBaS9jQBYjExUdqkdX5Q--iUuyCv_qZtw@mail.gmail.com> <CAJU8_nWpVhm4oTT+SLyG-nk=ww7nBU-DaVe86rUU-LGGqJvHvQ@mail.gmail.com> <CABcZeBO0TD0KnpTfe6CbHUoiS=FmGiGW6r_mFMH_9bYFWKqKLA@mail.gmail.com> <CABcZeBNp=1c1cx0+nJezjWy_Q4N9-PUeQuqOU_k7A7KhRj18EQ@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD4BB57@MX307CL04.corp.emc.com> <CABcZeBPL2mVFtsL77Bdr=BUf7cb+qe_+Wxq42AtoohHmSmJaCg@mail.gmail.com> <CE03DB3D7B45C245BCA0D243277949362FD4BDAB@MX307CL04.corp.emc.com> <877euu7hy0.fsf@ta.scs.stanford.edu> <CE03DB3D7B45C245BCA0D243277949362FD4D450@MX307CL04.corp.emc.com> <87vaieow9k.fsf@ta.scs.stanford.edu> <CABcZeBPxOaK3DN5u0ohizt8rAQ+tShMuOcdpJBJ-2fmMJuQWgA@mail.gmail.com>
Reply-To: David Mazieres expires 2018-02-11 PST <mazieres-52aiupydaksbwarupqdqnp264w@temporary-address.scs.stanford.edu>
Date: Mon, 13 Nov 2017 13:24:00 -0800
Message-ID: <87o9o5g9e7.fsf@ta.scs.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/KtIa7H9PbiQdnDrkJPDQwosA8WE>
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (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, 13 Nov 2017 21:24:02 -0000

Eric Rescorla <ekr@rtfm.com> writes:

> To be honest, I think this document is working too hard in both cases to
> try to legislate that people don't do things that we think are bad. The
> bottom
> line is that in both cases the boundaries around what we think is OK and
> what we think is not are kind of fuzzy (as you illustrate above with
> Curve25519). Rather than try to write RFC 2919 language about this,
> it would be better to simply describe the consequences of bad choices,
> and say that the function must be collision resistant, and stop.

I don't understand the RFC2919 reference.  Did you mean a different RFC,
or is there some IETF lore about this being an overly-specified RFC?

The thing is, there is definitely historical precedent for intentionally
choosing weak crypto algorithms.  And while I hope the truly bad old
days are behind us, I still think it's important that we abstract some
base level of security out of TCP-ENO so that most applications don't
need to whitelist TEP identifiers.

David