Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS authentication

Ben Laurie <ben@links.org> Fri, 09 December 2011 17:47 UTC

Return-Path: <benlaurie@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8A621F87FC for <pkix@ietfa.amsl.com>; Fri, 9 Dec 2011 09:47:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MHAYjt6C65T for <pkix@ietfa.amsl.com>; Fri, 9 Dec 2011 09:47:51 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E986221F87D9 for <pkix@ietf.org>; Fri, 9 Dec 2011 09:47:50 -0800 (PST)
Received: by vbbez10 with SMTP id ez10so2703000vbb.31 for <pkix@ietf.org>; Fri, 09 Dec 2011 09:47:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iYEqMR76FevtipEgeBawbBEr2CL4k5SD6ANv8wSIamc=; b=CmH2vhFfwMsC1ZA1TqXBzCJmNZxW+8Ir3NRAD8qAO8Z8PFHYGnTsxCN7XCMaENs6at Qd/XspjO33YUUQvPZkSu0PBdlQu80TRR1Yb2OXqyGrpuvCmrjppmgV+KOfR4J5AhUTWn xq8vHiRv2L5K1cKjp2R8j3kolNoovRJon/RHA=
MIME-Version: 1.0
Received: by 10.52.66.35 with SMTP id c3mr5743336vdt.17.1323452869317; Fri, 09 Dec 2011 09:47:49 -0800 (PST)
Sender: benlaurie@gmail.com
Received: by 10.52.71.146 with HTTP; Fri, 9 Dec 2011 09:47:49 -0800 (PST)
In-Reply-To: <CB079A55.2E22%tmiller@mitre.org>
References: <CAG5KPzxFEhU_j5dVVm7bZh=hw4wyVF7wYofR67RbitMp-Ou+9Q@mail.gmail.com> <CB079A55.2E22%tmiller@mitre.org>
Date: Fri, 09 Dec 2011 17:47:49 +0000
X-Google-Sender-Auth: plrEXN_9zarT_CZqcKqeY2l05X8
Message-ID: <CAG5KPzzymkdnLm8TG3y6htOthcmnHn=SAKUgcaHuVT+d0_5L+w@mail.gmail.com>
From: Ben Laurie <ben@links.org>
To: "Miller, Timothy J." <tmiller@mitre.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IETF PKIX WG <pkix@ietf.org>
Subject: Re: [pkix] fyi: Sovereign Keys: an EFF proposal for more secure TLS authentication
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 17:47:51 -0000

On Fri, Dec 9, 2011 at 5:32 PM, Miller, Timothy J. <tmiller@mitre.org> wrote:
> On 12/9/11 9:30 AM, "Ben Laurie" <ben@links.org> wrote:
>
>>Then you need to read the full paper, because it is _not_ equivalent
>>to a second CA.
>
> I have, and I said *functionally* equivalent, not *operationally*
> equivalent.
>
> Look at it this way:  The CA tells a user "I say this name is bound to
> this key."  Your notary basically says "Yeah, what he said."  The words
> are different but the message is the same.
>
> Note that the only way you can support detection of a colluding notary is
> to use what you've defined as a side channel.  The client needs to check
> with the notary's public list to show that a server-provided proof set
> isn't valid--a fact you recognize in the paper but not on the summary.

The summary says "clients check these proofs".

> This is part of the "reconsider your arguments" comment.
>
> Also, you missed a fraud case in your discussion.  What happens if a CA
> fraudulently issues a cert *and* registers it with a non-colluding notary?

The legitimate owner notices and takes action.

> The notary has no interaction with the entity the cert identifies, and
> can only take the CA's word for it. So the cert goes on the viewable list,
> the proof set goes to the fraudulent user, and the user gets spoofed.

Correct. However, this fact is detected.

>
> Finally, IMHO you place undue faith in the ability to "untrust" a notary;
> if the notary list comes from the browser makers--who by your own argument
> have a *proven* inability to manage roots of trust--then why should the
> notary list supplied and updated by the same source be somehow more
> trustworthy?

Because their current inability is thrust upon them, not caused by
incompetence or unreliability.

> On a side note, these aren't personal comments.  You placed the work in
> the public sphere in what appears to be a solicitation for comments and
> criticism.  I'm not particularly invested other than just trying to help
> improve the work.

Indeed, we are happy to receive comments, thankyou for your interest.