Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt

Andy Lutomirski <luto@amacapital.net> Tue, 13 September 2016 22:36 UTC

Return-Path: <luto@amacapital.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B8812B0B9 for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 15:36:47 -0700 (PDT)
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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=amacapital-net.20150623.gappssmtp.com
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 s5RshjuoypYm for <cfrg@ietfa.amsl.com>; Tue, 13 Sep 2016 15:36:45 -0700 (PDT)
Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A5312B0C1 for <cfrg@irtf.org>; Tue, 13 Sep 2016 15:36:44 -0700 (PDT)
Received: by mail-yb0-x22c.google.com with SMTP id i66so3367683yba.0 for <cfrg@irtf.org>; Tue, 13 Sep 2016 15:36:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bNADUvxcFOmocNwsCKK6xbjiDFPqIIfpqrKaoTbxdNQ=; b=dls1ka7YPK7l8lMFVJZjFJ/jJJib7bEmx0K/Cu6VM278BBI8F8MU/mjGV9NOa8sDnB BF8pZpWMBOQ2m9N1kZ3UZ0nyf2khkjE4qGkLprS3Uo6Ald2+EOELRf0D6wfxO1Rarjdb dTqN6VNLQDaa6W9lKc0ligPPpaC/RHBdj68PdRKG0GYygAx6u5jKaTqCoBmBjF7kNY0J EBGm82az8qt5trMi/Ln24PYfsjTzkmxKWnPZGjgvlXhyMsTyW0G8ZH3mb1pPJvkT0tfp JbZ8PEKOeg/MJoLFsZbKkSPGv1l9SsY8hJ8ZIuhfjqB48YfBQLockvF/1aUB9dQWpRvA Z3rg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bNADUvxcFOmocNwsCKK6xbjiDFPqIIfpqrKaoTbxdNQ=; b=I2J4piXmYKIXo6OPmmHz72YH2UkexewDB0RmmRm43xx56PumJn4BkcfIHMFB1tpbcr +I18+mpRsx08dj80wlbmvbT8YY/YXrLDsKOz21zCet4zJhzAl0bb/aPAnr7uX1O47bLl +w/YApeQ/AMqP1tfpyeRGGDpkDCayktDNOKBgMkYi1fhBJSSI07Ul7X3AoA4bW2JaamB wrsZLrPYusLZR4S4MUq9B7gwwXpyHvBNk9b3NCVyqSfoHBpJrZM7CRnef11vx1AHKdMl jsIUV9P4nbLOPPm7UP5DKPZuCxQKBu8pWd0kMnIl0ol8XQ4j9s0QfliS+o677GvSLqA3 XpuQ==
X-Gm-Message-State: AE9vXwMFhfDJ9oUxOvSKLtEMEENMvrLuQT2pTXQnRqWQ272fjMChnlT/8fZGOrKYvfEb0Tnc5/mFmaALjU8oTtTf
X-Received: by 10.37.196.197 with SMTP id u188mr3734556ybf.19.1473806204146; Tue, 13 Sep 2016 15:36:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.51.23 with HTTP; Tue, 13 Sep 2016 15:36:23 -0700 (PDT)
In-Reply-To: <69fce1b2-d68f-bd70-a969-f36d419ae734@lounge.org>
References: <D3FC35C1.9FC94%paul@marvell.com> <56878156-5fdf-9541-f9e2-882ab54a1632@lounge.org> <D3FC63E7.9FF36%paul@marvell.com> <8c36f26a-59b4-e483-c1e5-12a083f4b0b0@lounge.org> <D3FD4294.A005A%paul@marvell.com> <CALCETrX2sf+Ajiiyqj=bm8V2s2jTyYSyURMxfchPXw488rUP2Q@mail.gmail.com> <35b47674-90bc-926c-3a5f-bbe36291ce0e@lounge.org> <CALCETrUyCTRyBcq5nYQEmc7VRmRURQX75uKTxcpQ40q2sXSb8Q@mail.gmail.com> <69fce1b2-d68f-bd70-a969-f36d419ae734@lounge.org>
From: Andy Lutomirski <luto@amacapital.net>
Date: Tue, 13 Sep 2016 15:36:23 -0700
Message-ID: <CALCETrWRntrxDxMN9Hnt2a-RnnLSzcV_K3Q5nff9zukx1XpfQQ@mail.gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/m7LSsHIF1T21f-_8UVuMwnVPcoQ>
Cc: "Adrangi, Farid" <farid.adrangi@intel.com>, "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] Wack-A-Mole and PKEX 3.0 -> Re: Fwd: New Version Notification for draft-harkins-pkex-00.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 22:36:48 -0000

On Tue, Sep 13, 2016 at 2:03 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
> On 9/13/16 12:57 PM, Andy Lutomirski wrote:
>>
>> On Tue, Sep 13, 2016 at 12:24 PM, Dan Harkins <dharkins@lounge.org> wrote:
>>>
>>> On 9/13/16 9:51 AM, Andy Lutomirski wrote:
>>>>
>>>> On Tue, Sep 13, 2016 at 7:36 AM, Paul Lambert <paul@marvell.com> wrote:
>>>>>

>>>>
>>>> Here's roughly what PKEX tries to achieve (I think):  Alice and Bob
>>>> each know a password, and Alice and Bob are assumed to be the only
>>>> parties that know that password.  Alice can run PKEX and, if the
>>>> protocol succeeds, she knows that (1) a public key B, (2) that Bob
>>>> claims that the holder of the private key b is Bob and (3) that Bob
>>>> actually has the ability to perform private key operations using b.
>>>> Bob learns the same things about Alice and her keys.  There are whole
>>>> bunch of properties about offline attack that the protocol ought to
>>>> have.
>>>
>>>
>>>    Yes, that's a good list and let me add that Alice also knows that
>>> b is the private analog to the public key B. Also an important feature.
>>
>> What does that mean?  Alice doesn't know b.  She knows that there
>> exists a number b such that B = b*G, but that's not interesting.  She
>> does not, and cannot, know that Bob actually knows b unless Bob tells
>> it to her (which would be a terrible idea) because b might reside on
>> an HSM.
>
>
>   I didn't say she knows b. She knows that Bob knows b. That knowledge
> is what PKEX provides.
>

[...]

>>
>> Please elaborate.  What exactly breaks in TLS if I somehow obtain an
>> apparently valid certificate for andy.lutomirski.com that lists
>> Google's private key?  I certainly can't get any browser to identify
>> me as andy.lutomirski.com using such a certificate because I have no
>> ability to perform private key operations.  I sure hope that none of
>> the TLS variants are subject to identity misbinding attacks.
>
>
>   You're thinking about it backwards. What if I got a valid certificate
> for google.com that lists Dan Harkins' public key? Maybe I'm blackmailing
> some poor schlep at google. Maybe I gave him my signature on my public
> key and threatened him to run Andy Lutomirski's insecure enrollment
> protocol,
> or else. It would be better if the poor schlep would be able to say,
> "there's
> nothing I can do, the protocol is secure, we're not running the Andy
> Lutomirski
> protocol!"
>

I'm extremely confused here.  Unless I'm misunderstanding you, this is
backwards from what I quoted above.

Before a CA issues a certificate for Google, the CA needs to verify
that the private key referenced by the certificate is a private key
that Google intends to authorize.  So your public key shouldn't be
accepted because Google doesn't intend for your public key to be used
to identify Google.  In this example, it's immaterial whether anyone
involved actually knows your private key.

What I'm saying is: I don't see why a newly-designed enrollment
protocol should attempt to prevent you from getting a certificate for
your own domain that references Google's public key.  Google's
security is not compromised if you possess a certificate for
danharkins.com that has Google's public key listed.