Re: [Cfrg] Raw minutes of today's meeting

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