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

Stephen Farrell <> Mon, 13 July 2015 13:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 839C41B2AAA for <>; Mon, 13 Jul 2015 06:28:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PXIi-OyQsRUu for <>; Mon, 13 Jul 2015 06:28:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F90D1B2AA7 for <>; Mon, 13 Jul 2015 06:28:52 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CD42BDD0; Mon, 13 Jul 2015 14:28:51 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id emD799YSVs-T; Mon, 13 Jul 2015 14:28:50 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id A29F0BDCB; Mon, 13 Jul 2015 14:28:50 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1436794130; bh=qn3Zk63sWTIZg02IKZKewIO3WqWRUVfcVlS8jvnDfzg=; h=Date:From:To:Subject:References:In-Reply-To:From; b=wz5hM7c43jqjSMOmj9J3uAhDckH/N2If5T3700phLG0vXiqsW7TxEWePtLdqBS/6v 3qCXOucnqAlPR9EHYgb7UTFKSTzYQzMe7wRkv+s7QtNd6DMZbFFT75YjEXJ5p8ZQGi ex88UPvsJqL1soS00JN3StNiy4JmU5DRQZVVenBA=
Message-ID: <>
Date: Mon, 13 Jul 2015 14:28:50 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To:, "" <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: Mon, 13 Jul 2015 13:28:54 -0000


On 12/07/15 23:28, Dave Crocker wrote:
> 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. 

Just as a point of information for those who're considering there
may be external-to-the-IETF benefits in some form of renewal of
the relevant content from RFC 1984...

One reason I figured RFC 1984 is still ok is that the IAB have quite
recently weighed in with an even stronger recommendation "that
encryption be deployed throughout the protocol stack." [1] And while
that's an IAB statement and hasn't been through the IETF consensus
process, and while that doesn't directly touch on mandated-key-escrow-
silliness, it does refer back to RFC 1984, as well as going further.

So I reckon that from a non-IETF perspective, [1] probably achieves
as much as we'd achieve with any easy method of "renewing" RFC 1984.
(I'm also not sure what "renewing" 1984 might mean exactly but I'm
sure we could figure some mechanics that'd work and if it turns out
I'm wrong above and folks do want some such thing, I'll of course
try help get that done.)

Now, if we wanted to consider putting some equivalent to [1] through
the IETF consensus process then that would have a substantive effect
on IETF work and wouldn't just be something done for appearance's sake.
But that's a different day's work. That'd be more fun maybe, but also
more controversial I'm sure, and would probably take a while to get
right since we'd arguably need more clarity on the effects of having
much more ciphertext in the network. Anyway, I was thinking we might
want to start work on something like that after the MARNEW workshop
in September. [2] (And speaking of which: tomorrow's the deadline for
initial submissions for that workshop).