Re: [Cfrg] Fwd: New Version Notification for draft-harkins-pkex-00.txt

   One more thing...

On 9/12/16 8:20 AM, Andy Lutomirski wrote:
>
> This appears to be more or less the same protocol described in the 
> 802.11 DPP drafts.  It was terminally insecure then and it appears to 
> be just as terminally insecure now.  If it's really necessary for some 
> reason, I can reiterate the multiple ways I found to break it after 
> half an hour of thinking.
>
> This protocol needs to be replaced, starting from scratch.  By "from 
> scratch", I mean that a real PAKE should be used, in its intended 
> form.  The result will not even need to mention "groups", because 
> there is no reason at all for the tiny bit of protocol layered above 
> the PAKE to care that the exchanged keys are anything other than 
> opaque strings.
>

   You do not seem to understand the value of the owner of a trusted
public key providing proof-of-possession of the corresponding private key.
Have you ever wondered why CSRs get signed? Think about it. If the protocol
treated a public key the way it would treat the string "Hello World" then it
would be quite useless.

   That said, no one is stopping you from writing the protocol that you
think is necessary. In fact, I'd love to see it.

   Dan.

> --Andy
>
>
> On Sep 12, 2016 2:19 AM, "Dan Harkins" <dharkins@lounge.org 
> <mailto:dharkins@lounge.org>> wrote:
>
>
>       Hello,
>
>       In the current PAKE requirements draft there is an application
>     described for which we have no candidate protocols. Namely,
>
>       "In addition to key retrieval from escrow, there is also the variant
>        of two parties exchanging public keys using a PAKE in lieu of
>        certificates.  In this variant, public keys can be encrypted using a
>        password.  Authentication key distribution can be performed because
>        each side knows the private key associated with its unencrypted
>        public key and can also decrypt the peer's public key.  This
>        technique can be used to transform a short, one-time code into a
>        long-term public key."
>
>     So I have written an I-D that proposes just such a protocol. I
>     solicit review and criticism.
>
>       regards,
>
>       Dan.
>
>     -------- Forwarded Message --------
>     A new version of I-D, draft-harkins-pkex-00.txt
>
>     has been successfully submitted by Dan Harkins and posted to the
>     IETF repository.
>
>     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
>     <https://www.ietf.org/internet-drafts/draft-harkins-pkex-00.txt>
>     Status:https://datatracker.ietf.org/doc/draft-harkins-pkex/
>     <https://datatracker.ietf.org/doc/draft-harkins-pkex/>
>     Htmlized:https://tools.ietf.org/html/draft-harkins-pkex-00
>     <https://tools.ietf.org/html/draft-harkins-pkex-00>
>
>
>     Abstract:
>         This memo describes a password-authenticated protocol to allow two
>         devices to exchange "raw" (uncertified) public keys and establish
>         trust that the keys belong to their respective identities.
>
>                                                                                        
>
>
>     Please note that it may take a couple of minutes from the time of submission
>     until the htmlized version and diff are available attools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>     _______________________________________________ Cfrg mailing list
>     Cfrg@irtf.org <mailto:Cfrg@irtf.org>
>     https://www.irtf.org/mailman/listinfo/cfrg
>     <https://www.irtf.org/mailman/listinfo/cfrg> 
>