Re: [Cfrg] On Dragonfly

[David McGrew <[e-mail]>]

Thanks Watson,

On 02/05/2014 11:19 AM, Watson Ladd wrote:
> Dear all,
> First let me apologize to Paul Lambert. My remark on his cryptographic
> capabilities was uncalled for, and detracted from my argument, and I
> am sorry to have said it. Unfortunately it will remain as a monument
> to human frailty forever on the internet. (insert commas ad libertam)

it is notoriously difficult for an online group forum to maintain an 
even temper, because text does such a poor job of communicating 
emotional nuances that are so important in social cues.

>
> Secondly, I was unaware that there was a strong presumption in favor
> of RFC publication of any protocol.

Not "any protocol".   The question with dragonfly is: should we leave 
the draft as it is, or improve it and document the security 
considerations accurately?    The latter choice clearly does better by 
the Internet community.

> I do not think this presumption is
> wise, but that is for another day.
>
> Thirdly, let me clearly explain where I now stand on Dragonfly, after
> discovering what kind of reduction is possible.
>
> Dragonfly requires that each password element be used between a single
> pair of nodes, who
> have only one outstanding exchange between them. This requirement is
> surprising, and Dan Harkins agrees it should go in the draft.
>
> In the ROM, given that, we can reduce to Dragonfly between two nodes,
> with a strict ordering of interactions, and I believe this can be
> reduced to some reasonable computational assumption. I haven't done it
> yet, so I don't know what that assumption looks like. My belief that
> this wasn't possible was due to a slide of Dan's from IETF 88 which
> was completely wrong: just because something similar doesn't reduce,
> doesn't mean the protocol you actually make reduces! I should have
> read it as a challenge, not a limitation, earlier. This removes my
> biggest objection.

Very cool, I look forward to hearing more on this.

>
> Anyway, I don't have much more to say on the issue. I do think that
> the earlier IEEE standardization, followed by several IETF protocols
> supporting, and only now a decent analysis, raises significant
> questions as to the prudent exercise of cryptographic engineering. I
> would be quite dismayed to learn that a bridge I go over every day was
> only now being examined to determine if it was designed to support the
> weight of traffic.

I agree, there are lessons that could be learned, and what interests me 
most is how CFRG could improve the process.   I would love to see some 
recommendations or considerations get written up.   There are a lot of 
different and useful perspectives and backgrounds in CFRG. You had 
suggested at some point writing up a draft on security models and 
proofs, which could be part these recommendations.   I would like to 
hear from others on what they think about this. (Note: I'm not asking 
you to start writing a draft, I just wanted to re-start the discussion 
on this point.)

We also have the option of engaging more with standards activities in 
IETF.   Many individuals on the list are so engaged, but on the other 
hand, the academically oriented people on the list likely do not follow 
those standards activities.   Would it be useful to have a summary of 
new standards activities that use crypto get presented to CFRG?   I 
would guess that we could find volunteers to put together a presentation 
or a long email on that topic.

David

> Sincerely,
> Watson Ladd
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> http://www.irtf.org/mailman/listinfo/cfrg
>