Re: [Cfrg] considering new topics for CFRG

Adam Back <adam@cypherspace.org> Wed, 08 January 2014 08:54 UTC

Return-Path: <adam@cypherspace.org>
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 B80C81ADF53 for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 00:54:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] 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 cnHs57EELVkK for <cfrg@ietfa.amsl.com>; Wed, 8 Jan 2014 00:54:32 -0800 (PST)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 996A71ADF4C for <cfrg@irtf.org>; Wed, 8 Jan 2014 00:54:32 -0800 (PST)
Received: from netbook (c107-70.i07-27.onvol.net [92.251.107.70]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MRGbv-1Vp6vz0iJb-00UCmc; Wed, 08 Jan 2014 03:54:19 -0500
Received: by netbook (Postfix, from userid 1000) id 43D9A2E49E1; Wed, 8 Jan 2014 09:54:10 +0100 (CET)
Received: by flare (hashcash-sendmail, from uid 1000); Wed, 8 Jan 2014 09:54:08 +0100
Date: Wed, 8 Jan 2014 09:54:08 +0100
From: Adam Back <adam@cypherspace.org>
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>
Message-ID: <20140108085408.GA1864@netbook.cypherspace.org>
References: <52C755AA.70200@cisco.com> <CEED2882.2B867%paul@marvell.com> <52C9F739.1020301@cisco.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B7D6E094@SC-VEXCH2.marvell.com> <52CB30B4.9090206@cs.tcd.ie> <91BE5B4B-AE45-4C05-A423-EDF744A54766@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <91BE5B4B-AE45-4C05-A423-EDF744A54766@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Hashcash: 1:20:140108:pritikin@cisco.com::RGRniCV5YeQ1wt5d:0000000000000000000 00000000000000000000000005bi
X-Hashcash: 1:20:140108:stephen.farrell@cs.tcd.ie::8RIcPMo1ZGHbyWW2:000000000000 0000000000000000000000001gil
X-Hashcash: 1:20:140108:turners@ieca.com::QBnqTch2YUKXXvT6:00aRv
X-Hashcash: 1:20:140108:mcgrew@cisco.com::oxf5YbvKktyTmSQE:03e7x
X-Hashcash: 1:20:140108:cfrg@irtf.org::wJPVVMVfOO7Bcq0K:00001BXD
X-Hashcash: 1:20:140108:adam@cypherspace.org::ZODQT64qL7LSMPfx:00000000000000000 0000000000000000000000002OIv
X-Provags-ID: V02:K0:B3Y9SUiYHhBVTcfkU3SBz/VBq5Mm1O1o0EW/kgJlG1q Q9+Bpvd43cOLqyalRU4pjFQpQfZIayGNZSlQO5S4uw0NcOJYC+ epp9odR7I8MOTKq+Zbjvvw6+A2kPBngRiv66gqTEoMcbmeKPwa kff95gIyIO35k9LJ1l3nkSmW/uE36xzTXSf7TMNZkAh9pgs8yf 2UIq+di6OoEveHG6uFvnWsCVQTqUFxnWhZlLzIdpSQK4W3CzaC qIJr9sAeiagKpagcP6QNr4scl94rr63zRwln52eNNDO5ynAbya jqouC/aRejyjFmP561keKZPPnUJ4+A73UJPzAZbRQwPe0ZDgdm 5YuNQZfrGGrQa8B5NlxbGi8LK2d8+rZlMA5bqlMT1
Cc: Adam Back <adam@cypherspace.org>, Sean Turner <turners@ieca.com>, "David McGrew \(mcgrew\)" <mcgrew@cisco.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: Wed, 08 Jan 2014 08:54:34 -0000

That is a good idea.  Without engaging in any hyperbole, most of the
complexity problems with actually coding TLS and the LoC of it come from the
cert format X509 including ASN.1 and X500 naming by reference.  TLS
specification itself is simple & clean, where it fails format complexity is
by abandoning that cleaness and referring to X509 which imports ASN.1 and
the multiple encoding, security risk of a complex compiled format language,
multiple encodings CER/DER/BER and X500 by reference.  Some of the X509
imported choices and level of flexibility in there are the antithesis of
KISS for a wire format and a security protocol.  (Complexity is the enemy of
security).

Even OpenPGP has a lot of bit-twiddling, such that if you try to implement
it, it becomes complex.  I found it took me 5x longer to match the format on
that after coding the obvious canonical TLS like format.  There is some
superfluous complexity & bit-twiddling in the OpenPGP format.

I would go further therefore and not try to work-around the ASN.1, X509,
X500 complexity with profile and special case parser hacks.

The best choice I argue would be make a simple format using TLS existing BNF
format that is extremely clean and simple, reboot the format from scratch
and do it the way it should have been done in a TLS BNF native format with
narrow focus on the job at hand to avoid even OpenPGP levels of mission
creep.

Adam

On Wed, Jan 08, 2014 at 02:31:39AM +0000, Max Pritikin (pritikin) wrote:
>
>With the advent of DICE (DTLS in Constrained Environments), and similar attempts to discuss optimizations, it would seem that any discussion of "next generation" PKI discussions should include discussion on how to optimize the X.509 certificate/chain format. That appears to be missing in this conversation so far.
>
>I agree that any replacement for our current PKI is going to run into the same complexities. So, rather than assume they don't exist, would it be reasonable to look at how to optimize the existing work?
>
>Some off the cuff examples to frame what I mean:
>- Define a specific lightweight trust anchor format (yes, we can all use X.509 certs. But what about a canonical smaller format?)
>- Optimized version of the X.509 cert itself:
>	Perhaps a compressed format similar to the (old, abandoned and incomplete)  http://tools.ietf.org/html/draft-pritikin-comp-x509-00 draft for compressed certs?
>	Perhaps a v4 format that is restructured to provide easier/quicker parsing
>	Or if a non-ASN1 format is truly preferred then such a format could be defined that is can carry the same semantics as the existing PKI (namely, if the problem is ASN1 then we can fix that without also re-inventing all the rest)
>	
>Approaching the questions from this angle leads me to ask what _exactly_ the concerns with the current PKI are. Is it the ASN1, the CA infrastructure, the certificate chains, the cruft in each individual certificate, or?
>
>Thanks,
>
>- max
>
>
>
>On Jan 6, 2014, at 3: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.
>>
>>> 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.
>>
>> 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).
>>
>> 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.
>>
>> And there's the saag list [4] which is for general security
>> topics if none of the above fit.
>>
>> 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, 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;-). One could argue that that's why
>> of all the "large DB of public keys" approaches, only CT
>> seems to be left standing.
>>
>> One other thing - listing the problems with the current PKI
>> is not likely to be a useful place to start. 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;-)
>>
>> 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.
>>
>> [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
>>
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org
>> http://www.irtf.org/mailman/listinfo/cfrg
>
>_______________________________________________
>Cfrg mailing list
>Cfrg@irtf.org
>http://www.irtf.org/mailman/listinfo/cfrg