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

[Andy Lutomirski <[e-mail]>]

On Tue, Sep 13, 2016 at 2:03 PM, Dan Harkins <[e-mail]> wrote:
>
> On 9/13/16 12:57 PM, Andy Lutomirski wrote:
>>
>> On Tue, Sep 13, 2016 at 12:24 PM, Dan Harkins <[e-mail]> wrote:
>>>
>>> On 9/13/16 9:51 AM, Andy Lutomirski wrote:
>>>>
>>>> On Tue, Sep 13, 2016 at 7:36 AM, Paul Lambert <[e-mail]> 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.