IETF Logo Mail Archive

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

Sam Hartman <hartmans-ietf@mit.edu> Mon, 13 July 2015 14:47 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3171A1B2B57 for <saag@ietfa.amsl.com>; Mon, 13 Jul 2015 07:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.664
X-Spam-Level:
X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 pMruMorgzmJb for <saag@ietfa.amsl.com>; Mon, 13 Jul 2015 07:47:38 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 748471B2B53 for <saag@ietf.org>; Mon, 13 Jul 2015 07:47:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 764C120733; Mon, 13 Jul 2015 10:47:34 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bSt1ThsfR2D; Mon, 13 Jul 2015 10:47:33 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 13 Jul 2015 10:47:33 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8F4C682145; Mon, 13 Jul 2015 10:47:35 -0400 (EDT)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Carsten Bormann <cabo@tzi.org>
References: <55A26484.7050807@cs.tcd.ie> <87fv4ts9l2.fsf@latte.josefsson.org> <C64F2343-6937-44EB-BBA6-6D744BBC79A1@vpnc.org> <CAN40gSui7XrVtuZHLOyGs09ZJc5d20SN9AB4Ftnmav7z-tCW=g@mail.gmail.com> <CAGvU-a7CocoadpHP0f+_JCctfVG6y4Qtn0Cu_v9UxKNh=4+ajg@mail.gmail.com> <55A2AD94.3040604@tzi.org>
Date: Mon, 13 Jul 2015 10:47:35 -0400
In-Reply-To: <55A2AD94.3040604@tzi.org> (Carsten Bormann's message of "Sun, 12 Jul 2015 20:10:28 +0200")
Message-ID: <tsl7fq4f720.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/oHJaYpRCSaXx5VDk420Rh4RnQ14>
Cc: Simon Josefsson <simon@josefsson.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "saag@ietf.org" <saag@ietf.org>
Subject: Re: [saag] keys under doormats: is our doormat ok?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2015 14:47:40 -0000

>>>>> "Carsten" == Carsten Bormann <cabo@tzi.org> writes:

    >> 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.

    Carsten> I completely agree.

    Carsten> Just as we elevated RFC 20 to STD, we could still elevate
    Carsten> it to BCP -- a status that, IIRC, was just becoming
    Carsten> available at the time RFC 1984 was published.

My only concern about RFC 1984 is that as far as I can tell it doesn't
represent consensus or policy.
It documents the sense of the room at one point in time.

I'm not sure that matters, but in terms of anything formal, an IESG
statement or BCP would have more formal weight as I read our processes.
If it happens that the community still agrees with RFC 1984, that formal
weight doesn't matter much.

I have found that when I use RFC 1984 as an argument that we should not
consider key recovery in design (and this has happened a few times over
the years) I do get pushback that it has no formal standing.

Truthfully though I'm not sure it matters much.  Those who favor key
recovery in a given instance can find some other explanation to justify
the technical tradeoff they prefer--generally in terms of permitting
helpful intermediates or the like.
All RFC 1984 does is change how we phrase our arguments, and I suspect
that will be true no matter how we revise it.

v2.23.0 | Report a Bug | By Email