Re: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT)

Rob Austein <sra@hactrn.net> Wed, 15 February 2017 04:28 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB111299C9; Tue, 14 Feb 2017 20:28:23 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 tFTUx9ubHI4P; Tue, 14 Feb 2017 20:28:22 -0800 (PST)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69331299C4; Tue, 14 Feb 2017 20:28:22 -0800 (PST)
Received: from minas-ithil.hactrn.net (c-73-47-197-23.hsd1.ma.comcast.net [73.47.197.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id 534381398E; Wed, 15 Feb 2017 04:28:21 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 1220447982A2; Tue, 14 Feb 2017 23:28:21 -0500 (EST)
Date: Tue, 14 Feb 2017 23:28:20 -0500
From: Rob Austein <sra@hactrn.net>
To: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
In-Reply-To: <148709685964.10062.11055042165542175129.idtracker@ietfa.amsl.com>
References: <148709685964.10062.11055042165542175129.idtracker@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170215042821.1220447982A2@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/38RAfJL1u8lIaMcTRKGeskPFbl8>
Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis@ietf.org, Chris Morrow <morrowc@ops-netman.net>, sidr-chairs@ietf.org, The IESG <iesg@ietf.org>, sidr@ietf.org
Subject: Re: [sidr] Kathleen Moriarty's No Objection on draft-ietf-sidr-rpki-rtr-rfc6810-bis-08: (with COMMENT)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Feb 2017 04:28:24 -0000

At Tue, 14 Feb 2017 10:27:39 -0800, Kathleen Moriarty wrote:
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for your work on this draft.  The first question is more of a nit,
> the second is more important.
> 
> Section 9.1
> I suggest saying man-in-the-middle instead of monkey-in-the-middle as we
> use the latter typically in documents and I don't think there's anything
> particularly unique to a monkey-in-the-middle attack, but correct me if I
> am wrong.  I think it's just an alternate name for man-in-the-middle as
> result of Dug Song's tool sniff on monkey.org.  If monkey-in-the-middle
> is important for some reason, could you include a reference?

Authors are unrepentant middle-aged hippies who prefer to avoid
gratuitously sexist language even when it is traditional.

> Section 9.3
> Why isn't MD5 deprecated or discouraged more in this section?

Unchanged from RFC 6810, as, sadly, is the implementation status of
better channel security mechanisms on the relevant platforms.  Since
we have no realistic hope of belling that particular cat anytime soon,
we did not think it productive to reopen that discussion.

See discussion of Transport Security in Security Considerations.