Re: [saag] keys under doormats: is our doormat ok?
Dave Crocker <dhc2@dcrocker.net> Mon, 13 July 2015 19:38 UTC
Return-Path: <dhc2@dcrocker.net>
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 2008F1B2DD0 for <saag@ietfa.amsl.com>; Mon, 13 Jul 2015 12:38:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32sOj23wStwG for <saag@ietfa.amsl.com>; Mon, 13 Jul 2015 12:38:16 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EAEB1B2DCE for <saag@ietf.org>; Mon, 13 Jul 2015 12:38:16 -0700 (PDT)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id t6DJcCY1007230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <saag@ietf.org>; Mon, 13 Jul 2015 12:38:16 -0700
Message-ID: <55A413A1.70500@dcrocker.net>
Date: Mon, 13 Jul 2015 12:38:09 -0700
From: Dave Crocker <dhc2@dcrocker.net>
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: "saag@ietf.org" <saag@ietf.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> <55A2E9F4.3010908@dcrocker.net> <DM2PR0301MB0655B31EDD0584E2C9019E07A89C0@DM2PR0301MB0655.namprd03.prod.outlook.com>
In-Reply-To: <DM2PR0301MB0655B31EDD0584E2C9019E07A89C0@DM2PR0301MB0655.namprd03.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 13 Jul 2015 12:38:16 -0700 (PDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/saag/4DDFd4GwWDnL4ytz5-asW_kBcdg>
Subject: Re: [saag] keys under doormats: is our doormat ok?
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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 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. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net
- [saag] keys under doormats: is our doormat ok? Stephen Farrell
- Re: [saag] keys under doormats: is our doormat ok? Simon Josefsson
- Re: [saag] keys under doormats: is our doormat ok? Paul Hoffman
- Re: [saag] keys under doormats: is our doormat ok? Ira McDonald
- Re: [saag] keys under doormats: is our doormat ok? Yoav Nir
- Re: [saag] keys under doormats: is our doormat ok? joel jaeggli
- Re: [saag] keys under doormats: is our doormat ok? Carsten Bormann
- Re: [saag] keys under doormats: is our doormat ok? Dave Crocker
- Re: [saag] keys under doormats: is our doormat ok? Christian Huitema
- Re: [saag] keys under doormats: is our doormat ok? Watson Ladd
- Re: [saag] keys under doormats: is our doormat ok? Stephen Farrell
- Re: [saag] keys under doormats: is our doormat ok? Sam Hartman
- Re: [saag] keys under doormats: is our doormat ok? Eliot Lear
- Re: [saag] keys under doormats: is our doormat ok? Michael Richardson
- Re: [saag] keys under doormats: is our doormat ok? Dave Crocker
- Re: [saag] keys under doormats: is our doormat ok? Stephen Farrell
- Re: [saag] keys under doormats: is our doormat ok? Stephen Farrell
- Re: [saag] keys under doormats: is our doormat ok? Stephen Farrell
- Re: [saag] keys under doormats: is our doormat ok? Stephen Farrell