Subject: [Cfrg] Comments on PAKE Selection

From: Wang Guilin <[email-masked]>
Date: Fri, 26 Jul 2019 02:46:40 +0000

Dear all, 

I have tried but failed to join CFRG meeting a few hours ago remotely (4am in Singapore). So, not sure if any colleagues have given similar comments already. 

Comment 1: It is great to see that CFRG has decided to do PAKE selection. After seeing the full time schedule in Stanislav's presentation slides, my first feeling is that the selection period is very short, only about 3.5 months. Is this practical for reviewers having sufficient time to thoroughly compare and study candidate schemes? Also, nominators may also have challenges to improve their nominated scheme to better satisfy the requirements proposed. If not really, should we consider to extend this time schedule? 

Comment 2: Due to the importance of forward security in communications, I would like to suggest that forward security should be considered as one additional requirement for the PAKE selection. 

Thanks,

Guilin

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, July 26, 2019 9:36 AM
To: [email-masked]
Subject: Cfrg Digest, Vol 171, Issue 37

Send Cfrg mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.irtf.org/mailman/listinfo/cfrg
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of Cfrg digest..."

Today's Topics:

   1. Re: using hash2curve in a protocol (Watson Ladd)
   2. Re: Raw minutes of today's meeting (??????? ????????)

----------------------------------------------------------------------

Message: 1
Date: Thu, 25 Jul 2019 15:19:40 -0700
From: Watson Ladd <[email-masked]>
To: Dan Harkins <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] using hash2curve in a protocol
Message-ID:
	<CACsn0c=[email-masked]>
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 24, 2019 at 11:05 AM Dan Harkins <[email-masked]> wrote:
>
>
>    Hello,
>
>    The hash-to-curve draft is still a work in progress but I want to 
> use it to fix a broken protocol. The protocol in question is EAP-pwd 
> defined in RFC 5931. It does a "hunting and pecking loop" method of 
> hashing to a curve that is similar, but worse, than the technique 
> described in RFC 7664. (The method of obtaining a secret element in a 
> MODP group is similarly broken). It is susceptible to side channel 
> attack and I want to use the hash-to-curve draft to fix it.

Why not use a PAKE that comes out of the competition? And are you sure the result of your chosen modification is actually secure?

------------------------------

Message: 2
Date: Thu, 25 Jul 2019 21:36:12 -0400
From: ??????? ????????  <[email-masked]>
To: Yoav Nir <[email-masked]>
Cc: IRTF CFRG <[email-masked]>
Subject: Re: [Cfrg] Raw minutes of today's meeting
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

Extremely _RAW_? Concerning my comments at least. :( its meaning is lost completely, I wonder whether it was a deliberate move. ;(

> 25 ???? 2019 ?., ? 17:19, Yoav Nir <[email-masked]> ???????(?):
> 
> CFRG Summary - IETF 105
> 
> Meeting started at 15:52
> 
> New co-chair (Nick Sullivan). New secretary (Stanislav)
> 
> Looking for volunteers for CFRG document review panel.  Need both academic and industry experience.
> 
> PAKE selection (summary by Stanislav later)
> 
> HPKE (Richard Barnes)
>     Dan Harkins: Same key-pair - same key?
>     Richard: No, we got fresh enthropy
>     Tanja Lange: it depends on how they define ephemeral
>     Adam Langley: Consider NOISE. Shows we can do something worthwhile.  Go there.  
>     Richard: What does "go there" mean?
>     Adam: Don't need to do an all too general framework
>     Richard: This is orhtogonal to the NOISE approach
>     Riad: What would you remove if it was up to you?
>     Richard: The modes in which the center is authenticated with a symetric key.
>     Riad: Remove the unauthenticated case?
>     Richard: Not sure it would streamline things much. It's already a special case.
>     Joe Sallowey: In a WG I'd say we need to take things out. In an RG - less so. But still - less is more.
>     Richard: I think we have a consolidated set. Think we should leave things as they are.
>     Richard: naming?  CASHEW: Combined Asymmetric/Symmetric Hybrid Encryption Wrapping
>     Chris Wood: Likes cashews.
>     
> MGM (Stanislav):
>     Multilinear Galois Mode
>     Scott Fluhrer: GCM also has the property that you can begin encrypting before you have the AAD
>     Stanislav: Right
>     Yoav: why not call for adoption?
>     Stanislav: I am not the designer. Maybe in the future.
>     Watson Ladd: The cited attacks don't really break GCM.
>     Stanislav: MGM has better security bounds than GCM for some attacks.
>     Watson: The slides conflict. One says MGM performs better; the other says GCM does.
>     Stanislav: Depends on context.
>     
> Pairing Friendly Curves (Shoko Yonezawa)
>     Riad: BLS12-381 is desigend for this purpose. Is it worthwhile to define 192- and 256- levels?  It's already unblievably slow.
>     Shoko: We have to consider many curves. Not all for implementers to implement because they are confused as to which curve to implement.
>     Riad: Yes, but is that level needed? Don't know that people are using 581.
>     Tanja Lange: Optimal TNFS-secure pairings on elliptic curves with composite embedding degree Georgios Fotiadis and Chloe Martindale
>     
>     Anyone has applications?  3 hands are raised.
>     
> Streebog and Kuznyechik (L?o Perrin)
>     PHB: Some jiggering going on.
>     Yoav: Why does ISO standardization matter?
>     Russ Housley: We only know that something smells funny.
>     Stanislav: Thanks for doing the analysis. There was public info before standardization. 
>                Maybe not as public as it should have been. Agree that any analysis should be done.
>                Concerns should be investigated. Papers say there are structures, not showing how it could be exploited.
>                If you find attack or hazard, I'll be happy to discuss with you.
>                For now we only have structures.
>     L?o: Right. No attack. Analyzers should have had all the information.
>     Vasily Dolmatov: Structure does not imply vulnerability. We appreciate this. It is important for transparency.
>     
> Hash to curve update (Riad Wahby)
>     (no comment)
>     Alexey: 1 more revision?  More?
>     Riad: Close to done; need to cover a few more curves. No huge changes.
>     
> PAKE Contest Update (Stanislav)
>     Vasily Dolmatov: Hopefully people from TLS or IKEv2 are here. Otherwise we need to contact them.
>     Chairs: TLS people are here.
>     Yoav: Also IKE people
>     Bjoern Haase: Could you post the place where to find the replies regarding VTBPEKE? I did not find it on the mailing list.
>     Stanislav: Yes. They're either on the lNist or the chairs posted to the list. We'll try to publish again in a convenient way.
>     
> Nick: Still looking for volunteers for the panel. Would like people to review more than one for better comparison.
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/cfrg/attachments/20190725/98b556ab/attachment.html>

------------------------------

Subject: Digest Footer

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

------------------------------

End of Cfrg Digest, Vol 171, Issue 37
*************************************

---

From: Björn Haase <[email-masked]>
Date: Fri, 26 Jul 2019 07:39:20 +0000

>Guilin wrote: I would like to suggest that forward security should be considered as one additional requirement for the PAKE selection.
I agree. That's particularly crucial if we use the PAKE-spawned confidential channel for changing passwords! I thought so far that forward security would be considered mandatory in the first place.

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 26 Jul 2019 06:50:46 -0400

Dear Björn and Guilin,

Many thanks for the comments!

About the timeline: it is stated explicitly on the plan that it may be
revised at IETF 106 if we have reasons for that.

While I believe that the forward security will obviously be considered by
the Crypto Review Panel experts, we can just add the property to the list
of questions to be considered.

Kind regards,
Stanislav

пт, 26 июля 2019 г. в 3:40, Björn Haase <[email-masked]>:

> >Guilin wrote: I would like to suggest that forward security should be
> considered as one additional requirement for the PAKE selection.
> I agree. That's particularly crucial if we use the PAKE-spawned
> confidential channel for changing passwords! I thought so far that forward
> security would be considered mandatory in the first place.
>
>
>
>
> Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu
> informieren, wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (
> https://www.endress.com/de/cookies-endress+hauser-website) nach.
>
>
>
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged material. Any review, retransmission, dissemination or other use
> of, or taking of any action in reliance upon, this information by persons
> or entities other than the intended recipient is prohibited. If you receive
> this in error, please contact the sender and delete the material from any
> computer. This e-mail does not constitute a contract offer, a contract
> amendment, or an acceptance of a contract offer unless explicitly and
> conspicuously designated or stated as such.
>
>