Re: [saag] keys under doormats: is our doormat ok?

Dave Crocker <> Sun, 12 July 2015 22:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8D2501A8958 for <>; Sun, 12 Jul 2015 15:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wf7-hU2MTeQS for <>; Sun, 12 Jul 2015 15:28:10 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2C6D81A8953 for <>; Sun, 12 Jul 2015 15:28:10 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t6CMS67r026682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Sun, 12 Jul 2015 15:28:09 -0700
Message-ID: <>
Date: Sun, 12 Jul 2015 15:28:04 -0700
From: Dave Crocker <>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 ( []); Sun, 12 Jul 2015 15:28:09 -0700 (PDT)
Archived-At: <>
Subject: Re: [saag] keys under doormats: is our doormat ok?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 12 Jul 2015 22:28:12 -0000

On 7/12/2015 11:10 AM, Carsten Bormann wrote:
>> I disagree. Publishing an update signals that our opinion has evolved.
>> It hasn't, even if the technology has evolved to make software the focus
>> rather than hardware. Besides, this kind of document is a huge rathole,
>> and I don't believe any minimal changes would be worth the hassle.
> I completely agree.
> Just as we elevated RFC 20 to STD, we could still elevate it to BCP -- a
> status that, IIRC, was just becoming available at the time RFC 1984 was
> published.

First, in the world of politics -- and any other environment that has
folk looking to squash views they don't like -- people will use anything
they can find to undermine such views.  The fact that a decision is 20
years old really does sway some folk.  It does not matter whether it
should.  What matters is whether such folk matter.

As often as we have people conducting protracted threads on IETF lists
with silly crazies, on the off-chance that someone, somewhere, will take
the crazy seriously, we need to pay attention to the potential that the
IETF position of 20 years ago will be dismissed because it was made 20
years ago.

     The question is not merely whether our views have changed,
     but whether they apply to the current issue as well as the
     one 20 years ago.

     To have a consensus view that the current issue is the same
     as 20 years ago is an example of something that constitutes new
     work.  So even if we think there is nothing new to say, there is
     something extremely important to say that is new.

I will suggest that it would be worth publishing a revised version of
the previous RFC, with the addition of some text that explains how that
previous decision applies to the current topic.  And or how the current
topic is the same as the previous topic and that the IETF position
remains now as it was then.

I will also suggest that we ought to have the IETF review of the draft
RFC for this include a segment at an IETF plenary.  However we aren't
likely to get a draft at that stage by 10 days from now and we almost
certainly should not wait until the next IETF.

So I suggest that one of the plenaries contain a capsule summary --
bulleted list -- of the points folk think should be made in the
revision, and that a 'sense of the room' be taken during the plenary.
And that the result of that polling be cited in the IETF's documentation
about the intended draft and then in the draft itself.

I'm glad to offer review services for the bulleted list and/or the draft.


Dave Crocker
Brandenburg InternetWorking