Re: [Cfrg] considering new topics for CFRG

Watson Ladd <watsonbladd@gmail.com> Wed, 08 January 2014 04:18 UTC

Return-Path: <watsonbladd@gmail.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 E26521AE268 for <cfrg@ietfa.amsl.com>; Tue, 7 Jan 2014 20:18:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_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 hVjkU1QFVTHt for <cfrg@ietfa.amsl.com>; Tue, 7 Jan 2014 20:18:21 -0800 (PST)
Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B16CD1AE1FB for <cfrg@irtf.org>; Tue, 7 Jan 2014 20:18:20 -0800 (PST)
Received: by mail-wg0-f47.google.com with SMTP id n12so944127wgh.26 for <cfrg@irtf.org>; Tue, 07 Jan 2014 20:18:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=rG5xSVXB+4FA0+9Inku7E8AXgMeIs5tFo7Jj6lCeSZI=; b=KwptScTX8HHC2p5kMs6sVLxhGMLR5QxXZPBa3w4hgA47PUfOVsW/T3079o4fsHl0Vx 5rRf9b6jxJQAJ/LmNz7fQBSVx+7yMMd3dedhY+vaXkVV8yelqf2kwCadkWyJeyFCe9Rs AZX7S0W6lXoN8Lw9bcdh3dhUdhtRaWENlaZEGidUrdFVyvgZ8yZfQJwwyFWAqV9DRqPY MzCyQytE9BC0UKF//Aqz5CVeURMLgnXujPAq42/QMtPW+inDkXY8JORXF+23RN5O/xkX I+b4/jCIRkTg2gL6B01jXsZHmeIeIsNsgvajYqFD+d6dHLn7jht6t57UmxEixU+MMB+r cjRQ==
MIME-Version: 1.0
X-Received: by 10.194.175.66 with SMTP id by2mr8959990wjc.59.1389154691072; Tue, 07 Jan 2014 20:18:11 -0800 (PST)
Received: by 10.194.242.131 with HTTP; Tue, 7 Jan 2014 20:18:10 -0800 (PST)
In-Reply-To: <91BE5B4B-AE45-4C05-A423-EDF744A54766@cisco.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> <91BE5B4B-AE45-4C05-A423-EDF744A54766@cisco.com>
Date: Tue, 7 Jan 2014 20:18:10 -0800
Message-ID: <CACsn0c=xKP-GsxpFU=OSvjpWYJSo8PTt5=0V23NkEnADC3XCPw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: 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 04:18:24 -0000

On Tue, Jan 7, 2014 at 6:31 PM, Max Pritikin (pritikin)
<pritikin@cisco.com>; 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?

For the PKI WG yes. For us no.
>
> 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?

>From my perspective, it's a long and sad story about the semantics,
rather than the cruft.

First off, X.509 is as the name indicates part of a larger standard of
X.500 directory services, of which LDAP is a component.
LDAP was designed for hierarchical organizations: hence things like OU
etc. It works very well for this: the DOD uses it for access control
across a massive organization.

The problem is that this doesn't apply cleanly to the internet: PayPal
isn't part of Verisign in any meaningful sense, so why is Verisign
signing its certificate? (I just made this up: don't quibble) It gets
worse: with subdomains the idea of an intermediate certificate was
invented, but it took a while for the powers of the intermediate
certificate to be reined in with name restrictions.

The story gets worse when it comes to processing revocations. The DOD
has a CRL that is truly a wonder to behold, and OCSP doesn't work in
certain environments. The result is OCSP stapling, but it requires
cooperation from website admins, who I believe would refuse to pour
water on a burning man if it required a configuration change to a
webserver.

All of this annoyance and ugliness would be fine, if it wasn't for the
invisible hand. To the people paying for certs one CA is as good as
another, and the cheapest one wins. But that means extensive
verification and security measures aren't taken: commercial CAs will
meet the bare minimum to stay in the browser maker's good graces.
Anything more cuts into profits. Now, they aren't all like this, but a
lot of them are. End users have no idea what is really going on, and
can't make informed decisions. Heck, I don't know which CA's do a good
job and which don't.

Mix the three of these up, and we get things like Diginotar,
Turktrust, the recent flap over the French intermediate certificate
being stolen. Each one of these broke the security of the web for
everyone.

Lastly, X509 is good at expressing authenticity, bad at expressing
authority. It's not the only one with this problem: tracing who can
log in to what with SSH can be a real problem when transitivity is
noticed. Certificate transparency and pinning are ways around this,
but CT opposed by enough CAs to make it hard, and pinning requires
some work.

The net effect is Gmail has more security for me than Vanguard because
Gmail pins their certificate in Chrome, but Vanguard hasn't. Needless
to say this is very, very, subideal.  Furthermore, a huge number of
people can invisibly hijack any site they want.

None of this is that tied to what mistakes the standard groups made in
designing the mechanism, but rather the semantics they expressed
aren't a good fit for what we want. DANE is somewhat better, but won't
stop c1t1bank and related phishing fun.

Anyway, I think CFRG has very little role to play here. The issues are
mainly semantic, and there are several WGs addressing these issues.
Without a clear demand for our input I don't see why we need to spend
time on this.
Sincerely,
Watson Ladd
>
> 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



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin