Re: [TLS] Certificate validation can of worms
Watson Ladd <watsonbladd@gmail.com> Sat, 05 April 2014 05:15 UTC
Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2915B1A01CA for <tls@ietfa.amsl.com>; Fri, 4 Apr 2014 22:15:49 -0700 (PDT)
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 s0c1qTpqxBSn for <tls@ietfa.amsl.com>; Fri, 4 Apr 2014 22:15:44 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 30FE21A00A8 for <tls@ietf.org>; Fri, 4 Apr 2014 22:15:44 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id f10so4008265yha.17 for <tls@ietf.org>; Fri, 04 Apr 2014 22:15:39 -0700 (PDT)
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; bh=Ucj2UhG3FOafzOG/zuI/8/JPwBY6h/dZlDR8VN0aOlc=; b=eTavOB93giHdjlkcV/573crbBR1PgcAkln/5YMVIx2WIM9X7/gSR8T+f7Hra5ZJptD uQvq/ElxJctFV2uSLAv8j+FpKsR3Or/6HGN7ydwRFvVKEBtcbAwrhNmu616c5USZSqB0 PyOceVtJ1tXmSYX9RvonK/zKTBFseWlyzmr10I6s5y7/EGoaAPIhkEcSfZzy2ZTY1PN8 kdOboLVYVo/l0E0PDZJB75sxa7dnB0XFYysFhzINd88JUH/aLYGbLdA3Daioc3B1tdHS J9739G0kp2tPqdwNXXlxHik5BsU+xbK8BeEo5oiUyhUnfW7IB0fz5xryXhWXE6PxqapP Q1CA==
MIME-Version: 1.0
X-Received: by 10.236.30.230 with SMTP id k66mr22694795yha.57.1396674939354; Fri, 04 Apr 2014 22:15:39 -0700 (PDT)
Received: by 10.170.63.197 with HTTP; Fri, 4 Apr 2014 22:15:39 -0700 (PDT)
In-Reply-To: <CAK3OfOgidRuVC5WFqDAjZsbq_GBs7Jm2cRkAeeQ=t6GL_NTSyg@mail.gmail.com>
References: <CACsn0ckFoqQ=hwp=Wxjjrt6LavLoKSUCyBCp=TvWvJ3DsuhUsw@mail.gmail.com> <CAK3OfOgidRuVC5WFqDAjZsbq_GBs7Jm2cRkAeeQ=t6GL_NTSyg@mail.gmail.com>
Date: Fri, 04 Apr 2014 22:15:39 -0700
Message-ID: <CACsn0ckVvU09GB7tPtH0a4yPmvVCQebLmDcsgRJ6aeV7zRYGbQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OZdfDP2xZna8cCcwlEwoekRxDJI
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Certificate validation can of worms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Apr 2014 05:15:49 -0000
On Fri, Apr 4, 2014 at 9:17 PM, Nico Williams <nico@cryptonector.com> wrote: > On Apr 4, 2014 8:36 PM, "Watson Ladd" <watsonbladd@gmail.com> wrote: >> 1: How will DANE make this worse? >> 2: Is this really the best we can do? What features of X509 led to >> these problems? > > Let's take #2 first. Here's two entrants: > > - x.509 naming is impossibly difficult to deal with (see RFC4514); > > - stapled OCSP is how it should have been from day one -- CRLs add a ton of > complexity You are ignoring the reason we have CRLs in the first place: stapled OCSP assumes all devices are globally connected and so can get OCSP. Furthermore, neither naming nor OCSP/CRLs were involved in this research, although the complexity may have lead to corners being cut in the rest of the code. > Back to #1: DNSSEC is a PKI, but with better naming and fewer root CAs. > We're going to need CT for DNSSEC. Well, you're assuming that all implementations will agree on DNSSEC validity. Even if they do, DANE connects to the X509 ecosystem. This raises the problem of validating the parts between the TLS connection and the link to DANE. > >> 3: This focused on server authentication. How does client authentication >> fare? > > Very differently. For user authentication I think something more like > Persona (still PK, but not Internet-scale PKI) is better. We really need a > standard account & device enrollment protocol to make user PK work well -- > then we can land wherever on the PKI..web-of-trust..ad-hoc spectrum the > market likes best. Enrollment and accounts are secondary to making sure everyone agrees on what a valid certificate looks like. If you don't have that, you can't trust the results of authentication. This research analyzed server certificates only. It didn't have user certificates to play with. Furthermore, if X509 implementors got this wrong, how do we get it right? Sincerely, Watson Ladd > > Nico > -- -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin
- [TLS] Certificate validation can of worms Watson Ladd
- Re: [TLS] Certificate validation can of worms Yan Zhu
- Re: [TLS] Certificate validation can of worms Peter Gutmann
- Re: [TLS] Certificate validation can of worms Nico Williams
- Re: [TLS] Certificate validation can of worms Watson Ladd
- Re: [TLS] Certificate validation can of worms Kurt Roeckx
- Re: [TLS] Certificate validation can of worms Nico Williams
- Re: [TLS] Certificate validation can of worms Nico Williams
- Re: [TLS] Certificate validation can of worms Kemp, David P.
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Santosh Chokhani
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Rob Stradling
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Watson Ladd
- Re: [TLS] Certificate validation can of worms Nikos Mavrogiannopoulos
- Re: [TLS] Certificate validation can of worms Phillip Hallam-Baker
- Re: [TLS] Certificate validation can of worms Watson Ladd
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Santosh Chokhani
- Re: [TLS] Certificate validation can of worms Nico Williams
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Martin Rex
- Re: [TLS] Certificate validation can of worms Phillip Hallam-Baker
- Re: [TLS] Certificate validation can of worms Santosh Chokhani
- Re: [TLS] Certificate validation can of worms Santosh Chokhani
- Re: [TLS] Certificate validation can of worms Santosh Chokhani