Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08

Benjamin Kaduk <kaduk@mit.edu> Tue, 31 December 2019 02:37 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3112002E; Mon, 30 Dec 2019 18:37:14 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 GwUCuJIrzpHB; Mon, 30 Dec 2019 18:37:13 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 E168312008F; Mon, 30 Dec 2019 18:37:12 -0800 (PST)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xBV2b8lA025151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Dec 2019 21:37:10 -0500
Date: Mon, 30 Dec 2019 18:37:07 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Randy Bush <randy@psg.com>
Cc: last-call@ietf.org, secdir@ietf.org
Message-ID: <20191231023707.GR35479@kduck.mit.edu>
References: <157720267698.19361.11750709876624228448@ietfa.amsl.com> <CAAyEnSOx-MH0Ua6o9j-zMKwLktvYGXzBUw1ZkuO49BWD+1yxRQ@mail.gmail.com> <24070.38156.658126.30539@fireball.acr.fi> <760F7FE4-B10B-42FA-B3FF-0F73BEFEC953@akamai.com> <F73568E4-2AD0-4C9F-AD03-EBA831D569AB@nohats.ca> <CACsn0c=KkDzwXYMzWW88_OcX8GpJ92e3yrXeWR=v0SdQRYzxFQ@mail.gmail.com> <m2sgl4i92o.wl-randy@psg.com> <20191229033101.GE35479@kduck.mit.edu> <m2lfqvitcz.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <m2lfqvitcz.wl-randy@psg.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/bN706gg3e21BHGNTDcRxPTqMKzY>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-foudil-securitytxt-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Dec 2019 02:37:15 -0000

On Sat, Dec 28, 2019 at 09:38:36PM -0800, Randy Bush wrote:
> 
> >> these half-assed "the market demands something" panaceas provide
> >> false solutions we have to clean up later; emphasis on that last
> >> clause.  rwhois anyone?  the highway is littered with whitepages
> >> roadkill.  today there is a massive problem with authority in the IRR
> >> (which some RIRs throw in with whois); and retrofitting a solution is
> >> now years in blah blah blah.
> >> 
> >> no one is asking for the perfect over the good.  but it is our
> >> obligation, before putting the ietf stamp on it, for it to be as good
> >> as we can reasonably get for the time.  this proposal is not, as has
> >> been enumerated time and again as it has been shoved through the
> >> process over objections.
> >> 
> >> imiho, tero's review stands.
> > 
> > I do note the second 'i', but I have to say that to me, "shoved
> > through the process over objections" sounds like a pretty serious
> > process violation that ought to be remedied.
> 
> that may be what you heard, but that is not what i said, or at least
> meant to say.
> 
> > I'd like to better understand what you see as the process violation
> > (if any) here, so that I can try to remedy it.
> 
> if i had a process objection, i would say it quite clearly.  i have a
> reputation to maintain :)

Okay, thanks for clarifying.

> technical objections have been raised all along the path of this
> document.  many of them ignored and repeated, many covered in tero's
> most excellent secdir review.  but the draft marched on.  today sm
> raised new issues.

Well, I do remember some objections raised when this draft was still at
SAAG/SECDISPATCH, but I also assigned it a document shepherd and refused to
touch it myself until the shepherd had worked with the authors to address
those comments to the extent that we understood them.  (That was mostly
comments from Paul Wouters, if I remember correctly; there may have been
others.)  So I'm not sure which objections you think have been ignored
while "the draft marched on" -- my intent was to get the initial objections
addressed (and yes, sometimes that was by attempting to make them "out of
scope", which does not always work well), and the next step in the process
is AD review followed by IETF LC.  Having more issues raised during a
single IETF LC isn't surprising (though it is perhaps unusual, with many
drafts getting no LC comments other than directorate reviews, which is
probably a different thread), so "ignored and repeated" and "but the draft
marched on" feel a bit like hyperbole to me.  But maybe I messed up and we
missed something; I'm sure you won't be shy about telling me if that's the
case.

> but you're a security guy, have the badge and all, even if your name is
> not steve.  read the darn thing and tell us what you think of it as
> reasonable and prudent secops practice.

I mean, I read it when I did the AD evaluation, and what I recall thinking
is that it proposes a mechanism that's useful in some cases but potentially
harmful in other cases, so the trick would be to get the writing to be
clear about the risks.  Having it already being in use tends to tilt the
scales towards "document the thing so that the semantics are well-defined",
though that does not absolve us of the duty to accurately document the
drawbacks and risks.  It's a mixed bag, and you'll need to think before
relying on the information in the file, but that's hardly unique to this
mechanism.

-Ben