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

Amanda Baber <amanda.baber@iana.org> Mon, 13 November 2017 21:21 UTC

Return-Path: <amanda.baber@iana.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 A886512940B; Mon, 13 Nov 2017 13:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 HjfjbRuv_kd9; Mon, 13 Nov 2017 13:21:53 -0800 (PST)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEB41201F8; Mon, 13 Nov 2017 13:21:53 -0800 (PST)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 13 Nov 2017 13:21:51 -0800
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1178.000; Mon, 13 Nov 2017 13:21:51 -0800
From: Amanda Baber <amanda.baber@iana.org>
To: David Mazieres <dm-list-tcpcrypt@scs.stanford.edu>, "Black, David" <David.Black@dell.com>, Eric Rescorla <ekr@rtfm.com>
CC: "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>
Thread-Topic: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13: (with DISCUSS and COMMENT)
Thread-Index: AQHTWpFJtLjOSSQLGkWnxslSGGU/yqMQuYCAgAABhgCAACMUgIAAAKYAgAAE5YCAATG0gIAAAZkAgAALwQCAAFE3gIAAHmEAgACdFICAACxtgA==
Date: Mon, 13 Nov 2017 21:21:49 +0000
Message-ID: <3C97B6FC-F964-464E-83DD-4843DAFE0424@iana.org>
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>
In-Reply-To: <87vaieow9k.fsf@ta.scs.stanford.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.0.47.234]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="B_3593424107_2029942911"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/LuCThIfnyb5pXZcntGmOyTff3qg>
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:21:55 -0000

Hi David,

See [AB] below for a note about registration procedures.  

Thanks,
Amanda

> --[3]-- IANA registry policy for TEP registry
>
>> Final point:  I only have a tcpcrypt review from Barry Leiba.  Should I
>> apply his suggestion of "IETF review" instead of "RFC Required"?  I
>> originally wanted "Specification Required" because I thought the
>> designated expert review it implied would be sufficient.  Mirja talked
>> me up to "RFC Required," which I thought was more strict.  However, does
>> the RFC Required not in fact demand any kind of expert review?  (Looking
>> at RFC8126, it doesn't seem to.)  I would be perfectly happy with an
>> IRTF or Independent Submission stream RFC so long as a designated expert
>> agrees the document is not a waste of a code point.
>
> This is somewhat in tension with the previous topic - how much review is sufficient to ensure that a weak TEP doesn't impact the security of all others?  The degree of review increases from Specification Required to RFC Required to IETF Review - if the need to ban potentially flawed vanity crypto hashes in TEPs is serious, then IETF Review seems justified, even though it imposes process costs on getting new TEPs approved.  In all cases, IANA will have a designated expert to advise on the registration, "RFC Required" adds the IESG taking a look, and IETF Review adds a lot more attention from the IETF security community.   More eyes tend to find more things ...

As long as "RFC required" involves a designated expert, that would be my
preference.  It's also what I think we arrived at after a bunch of
discussion with Mirja.  I don't think the choice of conservative hash
function requires more than a designated expert review, because it's not
controversial or hard to check.  So is the status quo okay on this
point?

[AB] To include a designated expert requirement here, you would need to combine registration procedures. “Expert Review with RFC Required” would work.

David