Re: [Cfrg] considering new topics for CFRG

David McGrew <mcgrew@cisco.com> Sun, 26 January 2014 09:17 UTC

Return-Path: <mcgrew@cisco.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EF61A0118 for <cfrg@ietfa.amsl.com>; Sun, 26 Jan 2014 01:17:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level:
X-Spam-Status: No, score=-15.036 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_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 4QNVJ4Ub6u_E for <cfrg@ietfa.amsl.com>; Sun, 26 Jan 2014 01:17:51 -0800 (PST)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6EB1A0115 for <cfrg@irtf.org>; Sun, 26 Jan 2014 01:17:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7359; q=dns/txt; s=iport; t=1390727870; x=1391937470; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=n3KowWvQaZuKwnHKQrXQLDesjqs+feKEoBZFPa+x2uQ=; b=XgXr3QDRaIJWj6PbC0PHWRa6HcUUrj02lSVyXSgpkSBg7f3vv2VJMCxb os9vPLBSWtX8Ke2po/RpHaB88nGDSWz+Ie44Gk/QVNgY6OCmfg8wzJ3Bs i2ncLINyhWcDTtXW5whjNc1uBs2FZSUsA6Imz7Vk69okd0PtN37jpF1ZD s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmUGAKTR5FKrRDoI/2dsb2JhbABRCYMMOFCDA7lWgQUWdIIlAQEBAwEBAQEgDwEFNgsFBwQLEQEDAQEBAgIFHgMCAg8CFh8DBggGDQEFAgIFh3QHCQWrUJwtF4Epiz+BSgMEVAcGgmmBSQEDiUiOX4EyhRWGGYU+g0segSw
X-IronPort-AV: E=Sophos;i="4.95,723,1384300800"; d="scan'208";a="104025909"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 26 Jan 2014 09:17:49 +0000
Received: from [10.0.2.15] (sjc-vpn7-1844.cisco.com [10.21.151.52]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s0Q9Hj0x010418; Sun, 26 Jan 2014 09:17:46 GMT
Message-ID: <52E4D2B8.20902@cisco.com>
Date: Sun, 26 Jan 2014 04:17:44 -0500
From: David McGrew <mcgrew@cisco.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130922 Icedove/17.0.9
MIME-Version: 1.0
To: Paul Lambert <paul@marvell.com>
References: <CEF1A5BF.2BBC6%paul@marvell.com> <20140110171000.15EB92280EA@palinka.tinho.net> <3C4AAD4B5304AB44A6BA85173B4675CABA9C8FFD@MSMR-GH1-UEA03.corp.nsa.gov> <CF068ACA.2D33A%paul@marvell.com> <52E25DD0.9020703@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B80AF535@SC-VEXCH2.marvell.com>
In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D018B80AF535@SC-VEXCH2.marvell.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Sean Turner <turners@ieca.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] considering new topics for CFRG
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2014 09:17:55 -0000

Hi Paul,

On 01/24/2014 05:38 PM, Paul Lambert wrote:
> David,
>
>
> ]Hi Kevin and Paul,
> ]
> ]I think the key-centric stuff is interesting and worthwhile, but to some
> ]extent it is outside the scope of CFRG.
> Perhaps yes since it's not just number theory.  However I'm not sure
> where else any discussion would belong in the IETF.  I also just noticed my
> response to Dan's last question on this topic is still dormant
> in my drafts box, so I will dump one more note to this list ...
> Advice on any forum to discuss non-X.509 public key architectures
> would be appreciated.
>
> ] Can I ask that the CFRG
> ]presentation on this topic cover the crypto mechanisms and protocols
> ]that are relevant for a key-centric architecture, rather than focus on
> ]the public-key authentication architecture itself?
>
> ???

What I'm asking is just that the presentation cover topics in the RG 
charter.   From the list you provide below, it looks like this won't be 
a problem.

> Protocols should be defined by the use cases and architecture.
>
> The grab-bag of mechanisms is still an interesting list, but
> Might be confusing when taken out-of-context from the use
> Case analysis and overall architecture.

Yes, by all means explain the architecture.

>    I've already been
> asking related questions to the list.  Mechanism specific
> topics related to a 'key centric' architecture might
> include:
>   - public key algorithms and alternative algorithms
>     (like Edwards curves)
>   - public key algorithm representation, identification and enumeration
>     (partial proposal previously posted to list on naming
>     ... no response)
>   - definition of cipher suites in to facilitate
>     the clear semantics of public key usage in combination
>     with the other necessary cryptographic mechanisms.
>     Public keys and associated hashes, kdfs, encryption
>     Are handled in various ways in Internet protocols.
>     If the semantics of a public key is to be well defined, it
>     needs to be clearly associated with a set of appropriate
>     algorithms.

Good topic, IMO.

>   - privacy and anonymity mechanisms related to encodings
>     of key and key identifiers

Another good topic.

>   - definition and of suitable crypto
>     mechanisms/standards for generation of key identifiers

And another.

>   - definition of suitable encoding mechanism for binary
>     identifiers and keys (human readable)
>   - clear definition and enumeration of crypto mechanisms
>     suitable for particular public key types
>     (e.g. earlier discussion of encrypting and signing
>     with the same public key)
>   - cryptographic protocols using public keys to
>     support various types of authentication and
>     the bootstrapping of 'key centric' identities.
>     The protocols need to be tuned to the use case
>     requirements.
>
> On protocols ... is the discussion of set theoretic
> protocol semantics (like RT) a viable topic area for this group?
> Or ... is this group limited to number theoretic discussions?

Short answer: no.   Long answer: please see the charter at 
http://irtf.org/cfrg

>
> ]]Not trying to discourage work in this area, just trying to make sure
> ]that agenda time covers algorithms and protocols first.
>
> First - when you say agenda, is it the yet to be scheduled
> invited F2F presentation (likely would have been July)
> or the agenda of this mailing list?

We requested a slot at IETF 89 in London, 
http://www.ietf.org/meeting/89/index.html and when I said "agenda" I was 
referring to that meeting.   Yes, I realize now that you will be at IETF 
90 but not IETF 89.

>
> Algorithms would never be the first thing I'd present.
> So, your limitations are very discouraging.  I was at first
> enthusiastic that there was any interest in my proposed
> set of architectural concepts. Now, rather than being able to
> present a coherent set of ideas, you are telling me to
> focus on the 'math/crypto'.  The architectural concepts
> need to defined before the math.   I'd be happy to have
> review of material prior to a f2f presentation and
> adjustments could be made at that point.
>
> I will just move my work to non-IETF forums if
> contributions are discouraged or if they are not able
> to make any impact. The impact of a 'research' group
> is questionable by definition and I fear I am wasting
> my time participating on this mailing list.

I think you misunderstood me.   As you know, one of the responsibilities 
of a chair is to make sure that either the group stays within its 
charter, or changes its charter when needed.   At any rate, after seeing 
the list of topics that you intend to address, I don't have any concerns.

David

>   
>
> Paul
>
> ]
> ]David
> ]
> ]On 01/23/2014 01:37 PM, Paul Lambert wrote:
> ]> Hi Kevin,
> ]>
> ]> On 1/22/14, 9:29 AM, "Igoe, Kevin M." <kmigoe@nsa.gov> wrote:
> ]>
> ]>> If we were to put "key centric" on the CFRG agenda for IETF-89, do we
> ]>> have a speaker willing to give a presentation?
> ]> Thank you for your interest in the topic. I would be very willing and
> ]> interested in presenting on Œkey centric¹, however for the first time
> ]> in many years the IETF is occurring the same week as the Wi-Fi
> ]> Alliance Š so I¹m not available that week.
> ]>
> ]>> If this is too short of a
> ]>> deadline to meet, we can always have a presentation at a later
> ]meeting?
> ]> Yes.  That would work well.
> ]>
> ]> Paul
> ]>
> ]>> Three options:
> ]>> 	1) discuss at nest meeting
> ]>> 	2) discuss in the near future but not at the next meeting
> ]>> 	3) no support for a presentation in the near future. Maybe
> ]sometime
> ]>> later.
> ]>> 	4) Utter silence on the mailing list.
> ]>>
> ]>> As to #4, the Germans have a saying "Keine Antwort ist auch eine
> ]Antwort"
> ]>> (no is answer is also an answer).
> ]>>
> ]>>> -----Original Message-----
> ]>>> From: Cfrg [mailto:cfrg-bounces@irtf.org] On Behalf Of dan@geer.org
> ]>>> Sent: Friday, January 10, 2014 12:10 PM
> ]>>> To: Paul Lambert
> ]>>> Cc: Sean Turner; David McGrew; cfrg@irtf.org
> ]>>> Subject: Re: [Cfrg] considering new topics for CFRG
> ]>>>
> ]>>>
> ]>>>   > A useful mechanism, but it would be better to start with
> ]>>> reexamining and  > redefining our usage of public keys.
> ]>>> Specifically - I'm an advocate of  > keys as the primary
> ]identifiers.  A "key centric"
> ]>>> approach is a dual model
> ]>>>   > to Kohnfelder/X.509   The SDSI/SPKI work did progress work in
> ]this
> ]>>>   > direction, but failed for a variety of reasons.
> ]>>>
> ]>>> Key-centric versus name-centric identity is The Question, is it not?
> ]>>>
> ]>>> I rather doubt that the Administration's push for the NSTIC is
> ]>>> likely to settle in on key-centricity, but might you elaborate on
> ]>>> your preference for it?  I'm sympathetic to it on the grounds that
> ]>>> it directly enables multi-personna and, thus, data segmentation.
> ]>>>
> ]>>> If I'm being obtuse, feel free to say so.
> ]>>>
> ]>>> --dan
> ]>>>
> ]>>> _______________________________________________
> ]>>> Cfrg mailing list
> ]>>> Cfrg@irtf.org
> ]>>> http://www.irtf.org/mailman/listinfo/cfrg
> ]> .
> ]>
>