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

Dave Crocker <> Mon, 13 July 2015 19:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2008F1B2DD0 for <>; Mon, 13 Jul 2015 12:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 32sOj23wStwG for <>; Mon, 13 Jul 2015 12:38:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EAEB1B2DCE for <>; Mon, 13 Jul 2015 12:38:16 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t6DJcCY1007230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <>; Mon, 13 Jul 2015 12:38:16 -0700
Message-ID: <>
Date: Mon, 13 Jul 2015 12:38:09 -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 ( []); Mon, 13 Jul 2015 12:38:16 -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: Mon, 13 Jul 2015 19:38:18 -0000

On 7/12/2015 5:23 PM, Christian Huitema wrote:
>> 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 ofthe room' be taken during the
>> plenary.
> General agreement, but I would rather not call this a revision.
> Maybe something like "reaffirm."

It's more than reaffirm. Possibly quite a bit more.

The existing document has a very strong focus on export control
and sharing of keys. The current issue is backdoors, and the like.
While the existing document does list the need for private keys to be
private, it's not really dealt with in the surrounding text. Changing
that would be a substantive, compatible addition to the existing document.

Also the existing document does not contain an explicit and affirmative
statement of the basic, high-level requirements on a security mechanism.

The closest it comes to a statement of principle in the document is:

     Security mechanisms being developed in the Internet Engineering
     Task Force to meet these needs require and depend on the
     international use of adequate cryptographic technology.

The sentence after that applies the above to the particulars that the
document addresses:

     Ready access to such technology is therefore a key factor in the
     future growth of the Internet as a motor for international
     commerce and communication.

"Access" was the issue of the day. Today's issue is not the same,
though of course it is firmly attached to the first of the above statements.

In effect, the document could benefit from discussion at a higher level
and at a lower level. The higher level is a more complete statement of
the purpose, benefit and necessity of effective communication privacy,
and clarity about what that benefit means to users.

At the lower level, the document could benefit from some pragmatics,
along the lines of what Stephen has suggested: What should a working
group dealing with this realm of technology do and not do?

When we approve something purporting to provide a component of
'security', what basic expectations of that mechanism or system should
its consumers expect from it? To put it a bit grandly, what is the
'philosophy' of security that the IETF is applying?

For example, I believe the current issue hinges on an IETF belief that
those who choose to do encryption should be able to control who is
authorized and able to do the decryption.

Also there has been quite a bit of public discussion, this time around,
and the document should reflect on that activity.

On 7/12/2015 9:47 PM, Watson Ladd wrote:> On Sun, Jul 12, 2015 at 3:28
> The other factor is that we are entirely irrelevant to the
> discussion this time around.

The current issue is the advisability and effect on use of encryption
technologies, which are known to permit independent third parties to
compromise the encryption. For all of the politics of the topic, the
issue relies on technical matters. Technical matters about which the
IETF has some expertise.

There are a number of bodies that produce technical standards in this
space. The IETF is one of them. Having one or more of such bodies
produce statements concerning the technical, operational and usage
factors affecting this topic is entirely relevant, both to our own
choices going forward, and to the current public discussion now.

On 7/13/2015 6:28 AM, Stephen Farrell wrote:
> 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.

The IAB is not the IETF. No matter how august and diligent the IAB might
be, a statement from it is not at all equivalent to a consensus
statement from the IETF.

We often forget how essential that difference is, between an IAB
statement and an IETF consensus statement. As with others who have
posted, I think we shouldn't ignore it this time.

> On 7/13/15 3:28 PM, Stephen Farrell wrote: 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.

That's a socio-political assessment and while it's easy to imagine that
Stephen is correct, it is equally easy to imagine that he is not. In
political terms, the sociopolitical difference between "a tiny body of
senior protocol designers" versus "consensus of a major international
technical standards body" could be quite significant.

In sum, I think the revised document should:

0. Establish the current context including examples of related public
contributions. One recent publication would be obvious to include...

1. Provide statements of IETF principles about the nature and
requirements for privacy-related technologies, explicitly citing
relevant examples that would violate this.

2. Explain every 'what' with a 'why'. For each thing claimed to be good
or bad, explain the implications of ignoring the claim.

3. Give guidance that IETF efforts can use in designing new mechanisms,
formats, etc.


Dave Crocker
Brandenburg InternetWorking