Re: [Crypto-panel] Fwd: [Cfrg] Adoption call for draft-harkins-pkex-05

[Stephen Farrell <[e-mail]>]

Hiya,

On 05/08/18 14:34, Alexey Melnikov wrote:
> Dear Crypto Panel members,
> 
> Does anybody else wants to weigh in on whether this draft should be
> taken as a new work item by CFRG. (If you already replied on the CFRG
> mailing list, you don't need to state your opinion again.)

I just re-scanned the mails to the list on this going back to
2016. I also flicked through the draft.

1. I'm not a fan of PAKEs in general, they generally seem to
be solutions looking for problems. And there are so many of
'em and so many variations they cause, like this protocol! I
do recognise though that CFRG seems to have reached consensus
that PAKEs are worth spending time on. (So, I'm in the rough
there.) That said, I also think CFRG's best work is done when
there's a need for the output(s) concerned, and I'm not clear
that that applies in this case (or with PAKEs generally;-).

2. Section 3 says: "Due to the nature of the exchange, only DSA
([DSS]) and ECDSA ([X9.62]) keys can be exchanged with PKEX."
I think that's a showstopper, as deployments of this protocol
would need to be replaced if use of DSA/ECDSA wasn't desired.
If that restriction can't be removed, then I don't think this
ought be adopted.

3. As to the lack of proofs, I don't think that ought be a
problem at this stage, if the RG adopt the work on condition
that it not be published as an RFC until relevant proofs are
available. I do think that requiring (relevant) proofs be
available for CFRG primitives seems like a reasonable ask,
but I guess the RG would need to be asked about that as a
general question. (All that said, the main author is well
used to fighting and winning the long fight, so adoption in
this case will likely mean the eventual publication of an
RFC, no matter what conditions are imposed.)

Mostly because of #2, (but admitting my #1 bias:-), I'm
against adopting this. I'd be fine with sending this mail to
the list if that's useful, but it might not be useful, given
that it could start two hard-to-resolve debates.

If the issues related to #1 (real need), #2 (mechanisms with
limited agility) and #3 (need for proofs to go with novel
mechanisms) were put to the RG, and if you got consensus one
way or another as to the direction(s) folks want to take, that
might be useful in  resolving questions like these.

(In case it helps, and in case it's not clear:-) My take on
those would be 1: a real need is needed, 2: in general, say no
to mechanisms that are tightly bound to specific algs, lastly,
3: yes, for novel mechanisms, require relevant proofs unless
there's a good argument that that's not needed.

Cheers,
S.

PS: As a nit, the title seems fairly misleading to me.

> 
> Thank you,
> Alexey
> 
> -------- Forwarded Message --------
> Subject: [Cfrg] Adoption call for draft-harkins-pkex-05
> Date: Sun, 8 Apr 2018 12:41:58 +0100
> From: Alexey Melnikov <[e-mail]>
> To: [e-mail] <[e-mail]>
> 
> Dear CFRG participants,
> This message is starting a 2 weeks adoption call for
> draft-harkins-pkex-05 (Public Key Exchange). From the document's
> Introduction:
> 
>    [RFC7250] further states that "the main security challenge [to using
>    'raw' public keys] is how to associate the public key with a specific
>    entity.  Without a secure binding between identifier and key, the
>    protocol will be vulnerable to man-in-the- middle attacks."
> 
>    The Public Key Exchange (PKEX) is designed to fill that gap: it
>    establishes a secure binding between exchanged public keys and
>    identifiers, it provides proof-of-possession of the exchanged public
>    keys to each peer, and it enables the establishment of trust in
>    public keys that can subsequently be used to facilitate
>    authentication in other authentication and key exchange protocols.
>    At the end of a successful run of PKEX the two peers will have trust
>    in each others exchanged public keys and also share an authenticated
>    symmetric key which may be discarded or used for another purpose.
> 
> The adoption call will last for 2 weeks and will end on April 22nd.
> 
> Thank you,
> Kenny and Alexey
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
> 
> _______________________________________________
> Crypto-panel mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/crypto-panel
>