Subject: [Cfrg] On Dragonfly

From: Watson Ladd <[email-masked]>
Date: Wed, 5 Feb 2014 08:19:17 -0800

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)

Secondly, I was unaware that there was a strong presumption in favor
of RFC publication of any protocol. 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.

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.

Sincerely,
Watson Ladd

---

From: David McGrew <[email-masked]>
Date: Thu, 06 Feb 2014 08:15:32 -0500

Thanks Watson,

> 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.

> 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

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

> only now being examined to determine if it was designed to support the

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
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg
>