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

From: Paul Lambert <[email-masked]>
Date: Mon, 12 Sep 2016 19:59:39 +0000

Dan,
>Name:		draft-harkins-pkex
>Revision:	00
>Title:		PKEX
>Document date:	2016-09-12
>Group:		Individual Submission
>Pages:		9
>URL:            
>https://www.ietf.org/internet-drafts/draft-harkins-pkex-00.txt
>

To prevent confusion on the nature and functionality it might be better to
call this protocol PKEX 3.0.

The PKEX 2.0 was already the subject of discussion on this list. I am
encouraged to see that you acknowledge that PKEX 2.0 had some issues that
included a MiTM attack. This attack is documented in:
	https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-rev
iew-and-pkex.ppt

Comments on PKEX 3.0:

1) Qi term and Hunt-and-Peck
        PKEX 2.0:  Qi = H(Alice)*Pwe
                     Where Pwe = dhp(pw)    dhp() is dragonfly
hunt-and-peck
        PKEX 3.0: Qi = H(Alice|pw)*Pi
                      Where Pi might be dhp(pw) or role specific fixed
   For PKEX 3.0, I do not see how you can make the Pi and Pr terms be
unique if you use hunt-and-peck.
   Putting the Œpw¹ into the scalar versus a ECC point is more efficient
and is an improvement
2) Qi term and identity
        PKEX 3.0: Qi = H(Alice|pw)*Pi
     The use of ŒAlice¹ is problematic.  There is no indication in this
write-up how Bob learns
     ŒAlice¹ or Alice learns to identify Bob as ŒBob¹
     In your IEEE submissions for PKEX 2.0, Alice and Bob are identified
as MAC addresses (mac_a and mac_b).
     As shown in slide 8 of:
              
https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-revi
ew-and-pkex.ppt
     the use of MAC addresses is problematic because they can readily be
spoofed.
    If the goal of this protocol is to exchange Œraw¹ publc keys there
should not be a requirement
    to strt with a known identity.
    The binding of this type of protocol to a network address prevents
usage in tunneling, proxy applications where the
    external visible address may change (e.g. IPsec and NAT)
3) PKEX ŒEncryption¹ and public key transport
          PKEX 2.0:
            a, A = a*G (long term)          b, B = b*G (longterm)
            Qi = H(Alice)*Pwe                Qr = H(Bob)*Pwe
            M = A + Qa                       N = B + Qr
            --->M
                                             N<---
            --->u
                                             v<‹

             The M=A+Qa term was a major aspect of dictionary and MiTM
attacks

          PKEX 3.0:
            a, A = a*G (long term)         b, B = b*G (longterm)
            x, X = x*G  (ephemeral)        y, Y = y*G (ephemeral)
            Qi = H(Alice|pw)*Pi            Qr = H(Bob|pw)*Pr
            M = X + Qa                     N = Y + Qr
            --->M
                                            N<---
            u=f(a,Y,M,N,A,Y,pw,X,Y)         v=f(b,X,N,M,B,X,pw,Y,X)
            --->u
                                            v<---

            R = A + Z                       T= B + Z
            --->R

                                            T<---

        This is a significant change and may be an improvement in
security. Hard to tell yet.
        The protocol has gone from a 4-step to 6-step protocol. Seems like
4-steps should be enough ...

4) How is PKEX used?
   "At this point, if the parties didn't fail they have each other's
   public key and trust that it belongs to the peer's stated identlty.
   They can use the public key in another protocol to authenticate that
   identity.²
   ??? Not sure what a Œstated identity¹ means or how it is useful.
   What is the next protocol, how does this work as a system.

5) PKEX is not a key establishment protocol
   PKEX  generates and then throws away a pair-wise unique key pair.
   Seems like this class of exchange should also provide such key material.

6) is the goal to be a PAKE plus authenticated public keys (PAKE+Auth)?
   If so, clarity on the use of the derived pair-wise key would be useful.
   More interesting is if a PAKE is the right base mechanism to
Œintroduce¹ public keys.
   Short authentication strings (SAS) were brought up in the PKEX 2.0
discussions and might be
   a interesting line of pursuit for a useful protocol.

The extension of a PAKE (like SPAKE) to carry long-term public keys is one
possible design path.  For PKEX 4.0 9IMHO) a more generically useful
exchange could be built using a SIGMA-I type authenticated DH exchange.
The proof of holding the passphrase could be carried within the encrypted
portions of the authentication exchange. Such a SIGMA based design could
also readily be tweaked to generate a SAS. Seems like the same protocol
could be used to optionally support OWE-like requirements.

Hope these comments are useful ...

Paul

---

From: Dan Harkins <[email-masked]>
Date: Mon, 12 Sep 2016 13:43:15 -0700

Paul,

> unique if you use hunt-and-peck.

   Well it's actually the same way that the fixed elements get
fixed for SPAKE2. The requirement is that the discrete logarithm
not be known and hunting-and-pecking based on an input string will
give you that. I suggest you look at SPAKE2 on how it generates
the fixed elements that it requires.

> as MAC addresses (mac_a and mac_b).

   They are identities, not mac addresses. Authentication requires some
identity to authenticate so to use a public key for authentication in some
protocol like TLS or IKEv2 requires that the public key be bound to an
identity. How they learn each others identities to bind to the exchanged
public keys is not germane to the exchange.

>      to strt with a known identity.

   The goal is to exchange public keys that will be suitable for use in
an authentication protocol like TLS or IKEv2. If there is no identity bound
to the public key (as in a certificate) then what you get is 
"authentication"
and not authentication.
> security. Hard to tell yet.

   That is the question I am asking. So?
>     What is the next protocol, how does this work as a system.

   This is a cryptographic protocol and I am asking for cryptographic
review of it. How it fits into a system is not relevant to the protocol
or whether it is secure or not.
>     Seems like this class of exchange should also provide such key material.

   The goals and properties of the protocol are stated in the document.

>     More interesting is if a PAKE is the right base mechanism to

   There are no derived pair-wise keys to provide clarity on.
> Hope these comments are useful ...

Sadly no, not really. They are not about the protocol but, instead, about
incorrect assumptions on what identities are and irrelevant things about how
this protocol fits into some larger system or about other protocols that 
have
nothing to do with this (OWE? Huh?). If you have any comments on this 
protocol
in this draft I would like to hear them.

   Dan.

---

From: Paul Lambert <[email-masked]>
Date: Mon, 12 Sep 2016 21:57:06 +0000

Dan,

>the fixed elements that it requires.

Yes, I am very familiar with SPAKE2. It uses two unique fixed points that
stay the same for every protocol run.

The Dragonfly Hunt-and-Peck is designed to run on every new passphrase and
includes protection for side channel attacks that are not required for a
fixed value. 

The reference to Dragonfly is gratuitous and the specification would be
better served simply referencing the points and/or process in SPAKE2.

>identity. 

Ok … but the reason you are proposing this PKEX 3.0 is to replace PKEX 1.0
used in the Wi-Fi Alliance program to replace Wi-FI Protected Setup (WPS).
You specifically are using MAC addresses in this context for ‘identity’.

Also - if your goal is to start with raw keys, the key is a form of
identity and knowledge of a peer’s ownership of a particular key are
adequate for useful access control decisions. Other attributes of a key
(besides it’s value and ownership) are best exchanged and validated after
authentication and key setup.

>How they learn each others identities to bind to the exchanged

I disagree fundamentally. We need useful protocols that consider the
system implications of their application in real world environments. While
it’s convenient to create a modular design. The function of all of the
modules needs to be described.

This protocol already assumes that Alice knows the string or octets (
‘Alice’ )that are the identity of it’s peer Alice. If this is a Wi-Fi
device, what is this identity and how is it used?

>to the public key (as in a certificate) then what you get is

?? I think you are throwing up a smoke screen. The thread on PKEX started
as a review of one piece of the Wi-Fi Alliance DPP protocol. Right now the
way DPP seems to work if I wish to establish a P2P connection is:

1) 6 messages for PKEX
2) 2 messages for “DPP Authentication” (normally three, but PKEX used as
bootstrap)
3) 2 messages exchanged for configuration
4) 2 messages for DPP Connector Exchange
5) 4 messages for 802.11 4-way key setup

This is 16 messages to setup a P2P connection.
I believe we need to be discussing "the whole fish and not just the fish
nose.”

>or whether it is secure or not.

Why bother reviewing the security if the properties of the protocol are
not what is required.

I see no reason to pursue review of any protocol without clear
requirements and ideas on it’s application.

>   The goals and properties of the protocol are stated in the document.

Yes … you have in your mind the subsequent use of another two protocols
that are not described as part of this document to provide a “full” set of
security services.

PKEX goes to some length to not expose the long-term public keys.  This is
a good thing, but then later in DPP the “DPP Connector Exchange” directly
exposes these long-term values losing any privacy services you were trying
for with PKEX 3.0

So … no, the goals of the protocol are adequately stated in this document.

>   There are no derived pair-wise keys to provide clarity on.

This was constructive evaluation from a system perspective. You should be
able to significantly reduce the number of messages exchanged and greatly
improve the overall efficiency of the system solution.

>Have

If you feel that the way the protocol fits into a system is irrelevant,
then the protocol itself is irrelevant.

>nothing to do with this (OWE? Huh?).

Yes it does … ideally we would not be partitioning our protocols so that
each new use case is a new protocol.  Yes, I know you don’t share this
perspective.

>If you have any comments on this
>protocol

They were given but not heard.

I’m done reviewing PKEX 3.0.  Lacking any clear articulation of protocol
requirements or overall system functionality the PKEX 3.0 protocol is
irrelevant. PKEX 3.0 is not appropriate for inclusion into IEEE 802.11 or
inclusion into the WI-FI Alliance program for the Device Provisioning
Protocol (DPP).  

Paul

---

From: Dan Harkins <[email-masked]>
Date: Tue, 13 Sep 2016 01:05:42 -0700

Paul,

> You specifically are using MAC addresses in this context for ‘identity’.

   I asked for a review of the protocol. Whatever reasons for writing 
the I-D
I have are not relevant to the security of the protocol. This is not Wi-Fi
Protected Setup and it's not a Wi-Fi Alliance program. It's the Crypto
Forum Research Group of the Internet Research Task Force.
> authentication and key setup.

   Yes, you need to have knowledge of a peer's ownership of a particular
key. And you need something like PKEX to obtain that knowledge. You
can't, for example, just do a Diffie-Hellman key exchange and then infer
anything about peer ownership of the public key received in the exchange
for the simple reason that it is not an authenticated exchange.

   There's a chicken-and-egg issue here. You want to do an authenticated
Diffie-Hellman and infer some ownership of the public key used. But how
do you authenticate the Diffie-Hellman in order to justify your inference
of ownership? You don't get authentication out of whole cloth.

   PKEX allows you to obtain trust that a public key actually does belong
to a particular identity, and that kind of trust is _essential_ if the
key is going to be used for any other protocol that uses such "raw"
public keys for authentication.

> I believe we need to be discussing "the whole fish and not just the fish

   Now this is a smokescreen. I never said anything about P2P or DPP
or 4-way key set up. I'm just asking for a review of a PAKE exchange
in an I-D.

> inclusion into the WI-FI Alliance program for the Device Provisioning

   Done? You never reviewed it!

   I would greatly appreciate a review of the protocol itself and not a
soliloquy on it's appropriateness for some program of a secretive
organization (Wi-Fi Alliance) that requires NDAs to see what it's doing.

   Dan.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 13 Sep 2016 14:36:51 +0000

Dan,

>I have are not relevant to the security of the protocol.

A useful protocol is designed for a purpose and has requirements and
constraints based on it’s intended application.

>This is not Wi-Fi

The discussion of PKEX 2.0 started on this list as part of a review and
discussions of the WI-Fi Alliance DPP protocol.

PKEX 2.0 was defined in IEEE 802.11ai, and referenced by the Wi-FI
Alliance DPP project (aka replacement for WPS).

PKEX 2.0 was removed today from IEEE specification given the identified
issues.
	https://mentor.ieee.org/802.11/dcn/16/11-16-1142-01-00ai-cryptographic-rev
iew-and-pkex.ppt

PKEX 3.0 now appears as a IETF draft.

PKEX 3.0 is an improvement over PKEX 2.0 … but you may want to add some
acknowledgements to this new RFC that others contributed to your better
understanding of the limitations of PKEX 2.0 to create the current draft.

>or 4-way key set up.

No, you mentioned above that PKEX could be used for TLS or IKEv2. PKEX 1.0
was developed in IEEE 802.11ai for Wi-Fi communications.

PKEX 2.0 is deeply embedded into the WI-FI Alliance program to replace
WPS. PKEX 3.0 maintains the same usage model as PKEX 2.0

With enough tries … PKEX 3.0 or PKEX n.0 could be deemed secure. Including
the validated exchange of public keys in a PAKE exchange is a very
interesting mechanism. Usage constraints of such a protocol still may make
it inappropriate for particular applications.

Given the target usage of the protocol it’s security and system
applicability are both critical topics.

> I'm just asking for a review of a PAKE exchange
>in an I-D.

PKEX is NOT quite a PAKE. The protocol as defined does not provide ‘key
establishment’. A shared key is developed, but then not used.  This could
be changed easily.  This odd definition is based on your system
perspective that PKEX fits within a suite of modular protocol exchanges.
This sounds nice, but this creates some unusual interfaces and many extra
message exchanges. (Constructive Comment #3 make PKEX a PAKE)

Given that shared keys are established and PKEX 3.1 is a PAKE, it’s worth
consideration as a new “PAKE+" class of exchange that establishes a shared
key and exchanges authenticated public keys

If you keep the current modularity where the is no maintained shared
secret, it’s a new animal … a password authenticated public key protocol
(PAPK or whatever).

>organization (Wi-Fi Alliance) that requires NDAs to see what it's doing.

This mailing list was invited to review the Wi-Fi Alliance DPP
specification:

	https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi
_DPP_Tech_Spec_v0_0_23.pdf

DPP Page 27:
  "Step 1: Bootstrapping of trust
  The public keys of the devices are transferred from one device to
another. This
  places a trust that the public key belongs to the peer device. This can
be performed
  using either the Out-of-Band (OOB) mechanism for devices with limited
capability or
  using in-band bootstrapping (PKEX frames) for devices which have a user
interface.”

DPP Page 27:

  "This bootstrapping technique should never be run multiple times with the
same code. Using this bootstrapping technique more than once with a
different code but the
same bootstrapping key can enable a dictionary attack (to recover the
code) by the entity
that obtained the bootstrapping key the first time.
The PKEX protocol (from section 11.6.12 of published version of Draft
P802.11ai) is used to
establish trust in a peer’s bootstrapping key, and correspondingly allow
the peer to establish
trust in the device’s bootstrapping key, using a shared code."

	
PKEX imposes a shared one-time secret as a means to ‘setup’ two devices
with rich user interfaces.
This is a suboptimal design and goes against most notions of good user
experience.

PKEX might be interesting for other use cases

Paul

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 13 Sep 2016 09:51:43 -0700

> it inappropriate for particular applications.

Can we take a step back and ponder *why* a protocol that exchanges
public keys and proves possession of the corresponding private keys is
useful?

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.

For the purpose of pairing two devices that intend to communicate
using public-key crypto, property (1) is obviously critical.  In my
mind, property (2) should be sufficient.  I'm asking why property (3)
is useful.

Here's an example of a bad protocol where you need property (3).
Suppose that Bob writes a message that says "Please send me $100" and
signs it using b.  Alice receives that message with appropriate
assurances from someone she trusts that she should pay $100.  She
further learns via an *unauthenticated* channel that the money should
go to Bob.  She looks up Bob's public key B, checks the signature,
decides that only Bob could have sent the message, and sends Bob $100.

This protocol requires property (3).  But it's insecure in general
anyway because digital signatures don't provide the guarantee that
Alice is relying on: in many digital signature protocols, Charlie can
take a signed message and generate a brand new key pair that appears
to have also signed that message.

But this protocol is just silly and shouldn't need property (3) at
all.  Bob should sign the message "Pay me, Bob, $100 to this account"
and Alice should look up the key that Bob says is safe to use to
identify him (property (2)) and check the signature.  Problem solved
(and it's now using digital signatures correctly, too).

So what is DPP doing that makes property (3) useful in pairing?

---

From: Dan Harkins <[email-masked]>
Date: Tue, 13 Sep 2016 12:24:10 -0700

> bunch of properties about offline attack that the protocol ought to

   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.

   If there are any other "properties about offline attacks that the 
protocol
ought to have" that are not already listed in PKEX I'd like to hear about
them. Thank you in advance.

> mind, property (2) should be sufficient.  I'm asking why property (3)

   PKEX is, as the intro states, intended to provide trust to public keys
so they can be used in a different exchange that uses "raw" public keys
like TLS and IKEv2.

   Now both TLS and IKEv2 offer security guarantees about the authenticated
state of a successful run of the protocol and these are based, in part, on
the assurances placed in the public keys used in authentication. For 
instance,
that the certificate was not issued to someone who could not prove 
ownership of
the public key.

   So PKEX has to provide, to the best of its ability, the same sorts of
assurances a CA does to public keys in order for it to be able to exchange
public keys with sufficient trust to enable them to be used in protocols 
like
TLS and IKEv2.

> (and it's now using digital signatures correctly, too).

   Instead of addressing this ridiculous straw man of a protocol let me
refer you to the seminal work of Hugo Krawczyk: "SIGMA: The SIGn-and-MAc
Approach to Authenticated Diffie-Hellman and its Use in the IKE
Protocols." I strongly suggest you read the whole thing very closely but
pay special attention to the "identity mis-binding" attack he describes
against STS "when parties can register public keys without proving knowledge
of the corresponding signature key."

> So what is DPP doing that makes property (3) useful in pairing?

   Who cares? The property is not only useful it's critical!

   Dan.

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 13 Sep 2016 12:57:34 -0700

> 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.

>
>   If there are any other "properties about offline attacks that the protocol

A strong concept of what various parties (Alice, Bob, and any
potential MITM) can and cannot do to attack a weak password, online
and offline, even if Alice and Bob go and leak the entire output of
the protocol along with a and b afterwards.  The literature on PAKEs
should contain something usable here.

> so they can be used in a different exchange that uses "raw" public keys

This doesn't mean anything to me.  I don't trust public keys.  I trust
certain things about the people who are able to use those keys in the
future.

> that the certificate was not issued to someone who could not prove ownership
> of
> the public key.

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.

> of the corresponding signature key."

Do you mean this bit, quoted directly from the paper?

> Thus, for the STS to be secure one must assume that a secure external mechanism for proof of possession of signature keys is enforced. As we will see both the ISO protocol discussed in Section 4 and the SIGMA protocols presented here do not require such a mechanism.

A large part of that paper is about developing a protocol that does
*not* require property (3).

>   Who cares? The property is not only useful it's critical!

It's only critical if DPP is poorly designed.  See above.

There's a good reason not to provide property (3), though: unless you
provide a genuine zero-knowledge proof of knowledge of the private
key, you are now at risk from cross-protocol attacks and the overall
protocol that uses your primitive needs to be checked for
cross-protocol attacks.  For example, here's a proof of possession of
a private key that is exceedingly dangerous:

Alice -> Bob (encrypted, authenticated, etc): N_a
Bob -> Alice (encrypted, authenticated, etc.): b * N_a

Bob has just proved knowledge of b very convincingly to Alice.  But
Alice can use this protocol as an oracle to sign arbitrary messages
from Bob.

Another problem with proving knowledge of the private key as a
built-in part of the protocol is that it ties the protocol to the
public-key cryptosystem.  If Bob is merely transmitting a bit string B
(with property (2) -- Alice trusts that Bob intended to send that bit
string), then B could be an encryption-only key, it could be on any
group, it could be a key of different underlying type entirely (e.g. a
hash-based signature key or a lattice key), etc.  If you prove
possession of b, then your protocol depends on the cryptosystem.  It
also may rule out restrictive HSMs -- suppose that Bob stores b on an
HSM that can *only* do ECDSA.  (This is probably a good idea in many
cases.)  Bob can't run your protocol.

---

From: Dan Harkins <[email-masked]>
Date: Tue, 13 Sep 2016 14:03:44 -0700

> it to her (which would be a terrible idea) because b might reside on

   I didn't say she knows b. She knows that Bob knows b. That knowledge
is what PKEX provides.

> should contain something usable here.

   Perhaps I was too soon in offering thanks. In any event, the offer 
stands.
If you can think of any properties that PKEX ought to have that it doesn't
I'd like to hear of them.

> certain things about the people who are able to use those keys in the

   Are you just being contrarian as a protective defense? I can't tell. You
may not trust public keys but if you obtained one via PKEX you could have
a certain amount of trust in one that you did not have before. A part of
this trust will be a binding to a person "who [is] able to use [that] key
in the future." So PKEX is offering you exactly what you want. Not that you
will admit it.
> 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!"
> *not* require property (3).

   Indeed it is. Designing protocols that are resistant to an identity
mis-binding attack is a goal. It is not an excuse to create identities
that can be mis-bound.

   Given the hygienic problem your suggested protocols have had I think it
is imperative every assurance that can be made of a key be made in case it
is used in one of your wacky protocols.

> It's only critical if DPP is poorly designed.  See above.

   Well then you should focus your attention on DPP then. This is
not DPP.
> Alice can use this protocol as an oracle to sign arbitrary messages

   Once again, your ability to create a ridiculously insecure straw man
protocol says nothing about PKEX. But it does quite strongly demonstrate
the need for true and strong proof-of-possession of any protocol that
creates trust in a public key.
> cases.)  Bob can't run your protocol.

   Once again you have looked at the PKEX draft (in this case section 3),
noticed a statement and constructed some issue out of it. It's like you're
telling a car company, "You might've said I had to change the oil but I
never did, and now the engine seized. So the entire problem is with your
design of the car."

   It's odd for someone to argue for less integrity in a key but then,
here you are. You shouldn't be surprised that your campaign for less
integrity in public keys is not a popular one.

   Dan.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 13 Sep 2016 14:56:01 -0700

<Massive exchange everyone has given up on chopped>

What assurance do we have that PKEX actually satisfies the security
claims claimed for it? Don't you think a conference paper is a better
place to put a new protocol then an IRTF mailing list consisting of
people almost entirely unqualified to do the sort of analysis you are
calling for, and with no proof of security, or even formal security
claims put forward?

The commitments do not bind properly: this is obvious. It is not clear
what the KDF is used for, or what properties it requires. Furthermore,
there is no reason to believe that the identities are "trusted":
clearly anyone with the shared password can register whatever keys
they want with whatever identities they desire.  All that is
ostensibly known is that someone who knows the private key and the
password has participated in the protocol. It is clear this is an
inherent property of an protocol.

>
>   Dan.
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 13 Sep 2016 15:36:23 -0700

>   I didn't say she knows b. She knows that Bob knows b. That knowledge

[...]

> nothing I can do, the protocol is secure, we're not running the Andy

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.

---

From: Dan Harkins <[email-masked]>
Date: Tue, 13 Sep 2016 16:17:58 -0700

> danharkins.com that has Google's public key listed.

   For one thing, a CA is only as good as its word. And if it allows people
to get certificates for identities that bind to other people's public keys
then its word is shit.

   So let's say you're doing some work for an int'l human rights 
organization.
But now you've been caught with kiddie porn and are being blackmailed by the
authorities. Now the gov't is trying to force you to get a certificate
with your identity (what you refer to as "your own domain") but with a
public key that belongs to the FBI (what you refer to as "Google's public
key"). This will allow the FBI to connect to the human rights group (since
it has the private key) and the human rights group will treat any 
authenticated
connection as being you and not the FBI. Oops!

   Again, you're arguing for less integrity in certified keys and that is
a very untenable position.

   Dan.

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 13 Sep 2016 16:24:12 -0700

> connection as being you and not the FBI. Oops!

I don't see how confirming access to the private key helps.  Wouldn't
the gov't just force the victim to get a certificate with a fresh key
and then give the private key to the FBI?  Or, even better, force the
victim to give their existing private key to the FBI, thus preventing
any funny business at all from being seen in the CT logs?

---

From: Dan Harkins <[email-masked]>
Date: Tue, 13 Sep 2016 16:43:07 -0700

> calling for, and with no proof of security, or even formal security

   Well I don't think that most people on this list are entirely
unqualified to evaluate a PAKE. They may be busy or disinterested
or turned off by unprofessional bluster concerning "attacks" against
PKEX but I don't think they're unqualified.

   A conference paper is a decent idea. But I don't think that
obviates getting CFRG review.

> The commitments do not bind properly: this is obvious.

   They bind to the password which is bound to the identities. What
obvious thing am I missing?

> It is not clear
> what the KDF is used for, or what properties it requires.

   It derives a session key (that can, for instance, be exposed in
a Reveal query). What properties do you think it needs to have in
order for the protocol to be secure? Are you bringing up a referencing
issue (that is, the I-D should point to some NIST FIPS on a KDF?) or
is this a fundamental issue with the protocol itself?

> Furthermore,
   Each party to the exchange commits to a particular identity when
it commits to a particular public key. From the point-of-view of the
protocol I don't see an issue.

   But it is necessary for you to bind the peer's claimed identity to the
password at provisioning time. As Paul mentioned, Bob has to know the
identity "Alice" before the protocol begins and therefore he can affix
the password to "Alice" when provisioned. Only an identity of "Alice"
is able to exchange a public key protected by the provisioned password.

This is a very good comment. The draft is obviously not explicit on
this binding and it should be.

   Dan.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 26 Sep 2016 12:51:03 -0700

> obvious thing am I missing?

F(x) is 2-1 for elliptic curve keys.
> is this a fundamental issue with the protocol itself?

I am not the one claiming this protocol is secure, nor did I design
it. I would expect you would have some idea what requirements the KDF
must meet. Does it need to be collision resistant, for instance?

> is able to exchange a public key protected by the provisioned password.

I think I am less confused now: you are assuming the password is
shared between two endpoints with known identities. In this case there
is no problem.