Re: [Cfrg] considering new topics for CFRG

Paul Lambert <paul@marvell.com> Tue, 07 January 2014 21:05 UTC

Return-Path: <paul@marvell.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 461D41AE089 for <cfrg@ietfa.amsl.com>; Tue, 7 Jan 2014 13:05:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.883
X-Spam-Level:
X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] 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 LGcZvPv46DTh for <cfrg@ietfa.amsl.com>; Tue, 7 Jan 2014 13:05:57 -0800 (PST)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id 572201AE1BD for <cfrg@irtf.org>; Tue, 7 Jan 2014 13:05:55 -0800 (PST)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s07L5YJu031031; Tue, 7 Jan 2014 13:05:34 -0800
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1h6q2mmh1f-11 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 07 Jan 2014 13:05:33 -0800
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Tue, 7 Jan 2014 13:05:33 -0800
From: Paul Lambert <paul@marvell.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, David McGrew <mcgrew@cisco.com>
Date: Tue, 7 Jan 2014 13:05:31 -0800
Thread-Topic: [Cfrg] considering new topics for CFRG
Thread-Index: Ac8L7DPlSNyDTq1RSV6NQ9KNvyIusg==
Message-ID: <CEF1A5BF.2BBC6%paul@marvell.com>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com> <52CB30B4.9090206@cs.tcd.ie>
In-Reply-To: <52CB30B4.9090206@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="euc-kr"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-01-07_07:2014-01-07, 2014-01-07, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1401070132
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: Tue, 07 Jan 2014 21:05:59 -0000


On 1/6/14, 2:39 PM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>; wrote:

>
>
>On 01/06/2014 08:32 PM, Paul Lambert wrote:
>>> > This is an intriguing thought, but probably something out of scope
>>>for
>>> > CFRG.   (Seems more like a PKNG thing if I understand you right.)
>>
>> There was an IETF PKNG that died with no visible results.
>
>That was an IRTF RG. IMO it never had a cadre of researchers
>nor a sufficient set of IETF participants who were interested
>in a nextgen thing.
Yes - no visible results.
Note - I’m biased against even using the ‘I’ infrastructure terminology.
This was used to reflect the need for coordination required for CAs and
the original ideas of X.500

>
>> This is an area where the IETF seems either too unfocused or mired
>> in existing PKI to make progress.  Hence it's on my wish list ...
>> Let me know if you have any suggestion for other viable forums in IETF
>> for such a topic.
>
>We have a list where we discussed certificate transparency but
>which has a broader remit. [1] That's discussing whether or
>not to start a new CT WG in the IETF at the moment.
Excellent work.  Currently a bandaid to X.509 PKI.  The Merkle tree
mechanism do have broader applicability but are just one mechanism that
could be part of a new framework.
A tree/log based approach is useful for validating the time sequence
relationship of events. It can help with making claims based on time
ordering (perhaps for names).

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.

>
>There's the wpkops WG for operational issues related to the
>web PKI. [2] They could do with help in terms of cycles to do
>already-identified work (not hugely interesting for a
>security/crypto researcher though probably).
Old PKI … not a good venue.
>
>The PKIX list [3] is still open, and would be a good place to
>talk about any X.509-related PKI stuff. Not so good for non
>X.509 based PKI though maybe unless for an approach that's
>very much evolutionary and starts from X.509.
Yes. Wrong forum.
>
>And there's the saag list [4] which is for general security
>topics if none of the above fit.
Yes - but not useable for sustained conversations.
>
>So stuff is happening and there are places to discuss and
>propose stuff. And Sean and I would be quite happy to try
>help PKI nextgen stuff progress in the IETF should there
>be credible proposals.
>
>However, current PKI is not an easy thing to displace, no
>matter how much you dislike parts or all of it. The main
>reasons IMO are that replacements are likely to suffer a lot
>of the same (or equivalent) complexity since its a complex
>problem, 
Maybe ...

>and that any credible replacement will take at least
>a few years to work out and them 5-10 to get deployed which
>seems to be beyond the horizon for researchers (speaking as
>one who chases funding;-).
Perhaps … but it depends on the market and application.
IPv6 … 20-30 years.
X.509 in TLS in browsers … 5-10 years
New applications … instantly

>One could argue that that's why
>of all the "large DB of public keys" approaches, only CT
>seems to be left standing.
For fixing DNS names used in TLS

>
>One other thing - listing the problems with the current PKI
>is not likely to be a useful place to start.
Yes. It’s been done.

>We know those,
>and any credible approach would start with a fairly well
>worked out proposal, including consideration of that 5-10
>year overlap period. Its not easy;-)
Please note that I was not suggesting that we replace
X.509 directly in TLS and DNS:
>   - A public key based ¹trust¹ architecture to
>     determine ³who can do what² (not based on X.509 or PGP)


This is a broader applications than just
a DNS name. New features would accelerate adoption in new markets.

Paul

>
>Having said all that though, CT is I think a good proof of
>concept that the large-DB-of-public-keys thing could be
>a runner, and we have learned a lot about the wrinkles in
>X.509 based PKI over the years so there is hope maybe.
>
>S.
>
>PS: For any of [1]-[4] please check the archives before
>diving in, or ask someone who might be familiar, which
>could include me.
… You did not list SDSI/SPKI archives or PGP


>
>[1] https://www.ietf.org/mailman/listinfo/therightkey
>[2] http://tools.ietf.org/wg/wpkops/
>[3] https://www.ietf.org/mailman/listinfo/pkix
>[4] https://www.ietf.org/mailman/listinfo/saag
>
>
>