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