[Cfrg] Comments on PAKE Selection

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:cfrg-bounces@irtf.org] On Behalf Of cfrg-request@irtf.org
Sent: Friday, July 26, 2019 9:36 AM
To: cfrg@irtf.org
Subject: Cfrg Digest, Vol 171, Issue 37

Send Cfrg mailing list submissions to
	cfrg@irtf.org

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
	cfrg-request@irtf.org

You can reach the person managing the list at
	cfrg-owner@irtf.org

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 <watsonbladd@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] using hash2curve in a protocol
Message-ID:
	<CACsn0c=jOStaHXpREY9fJM3K88JAdQdY4UKdtzmEOoK65osCCw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"

On Wed, Jul 24, 2019 at 11:05 AM Dan Harkins <dharkins@lounge.org> 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: ??????? ????????  <vdolmatov@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Cc: IRTF CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] Raw minutes of today's meeting
Message-ID: <F58C04AD-E054-4978-BC26-0F9DFA78A9CC@gmail.com>
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 <ynir.ietf@gmail.com> ???????(?):
> 
> 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
> Cfrg@irtf.org
> 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
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

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

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