Subject: [Cfrg] comments on safecurves draft and goals

From: David McGrew <[email-masked]>
Date: Tue, 14 Jan 2014 16:46:23 -0500

Hi Watson,

I am glad that you started the process of generating an RFC that 
introduces some improved ECC techniques; thanks for doing this.   I want 
to get you some high level feedback, speaking as an RG member, not an RG 
chair.

I think that CFRG should support this work, either by having it become 
an RG draft, or through ongoing review and coordination with the IETF 
Securiy Area.

What would have the most positive impact is a draft that is something 
like RFC609 for Montgomery and/or Edwards curves, which includes:

- complete descriptions for all relevant algorithms (including things 
like octet/integer conversions), and guidance about implementation 
techniques (especially important considering resistance to side channel 
attacks),

- stable normative references for all algorithms,

- definitions and references for mathematical things that a typical 
software or hardware engineer would not know about,

- a description of what interoperability is possible,

- a rationale that explains the design choices, and summarizes the 
security and provides references to appropriate security analyses, and

- a section on intellectual property, which describes what is known 
about the IPR situation.   Of course, the IETF IPR disclosure rules 
apply, so the IETF process for patents will apply.

It might make sense to borrow some of the structure (and perhaps even 
text, such as octet conversions and ECDH) from RFC6090.   I can provide 
you with the source XML if you want.

Ideally, there should be a section on "implementation experience", which 
provides feedback from multiple implementers.

I would guess that this work is something that Dan and Tanja are willing 
to contribute to, say by allowing us to use some of the text (including 
the excellent list of references) on the safecurves site.

A good way to think about this work is: it should provide enough 
information that someone can implement the primitives, and will be 
guaranteed interoperability with someone else's independent 
implementation.   It should provide such a good a self-contained 
rationale for the design and its security that someone who works for a 
vendor or an end-user could use it to justify adopting this 
technology.   And t should enable an implementer to understand the IPR 
landscape surrounding their implementation.

I hope that it doesn't seem like I am raising the bar to make your work 
harder; that is certainly not my goal.   What I am going for is: having 
this work make the biggest and most positive impact.

I saw from your recent note that you have a new version in the works; 
that's great.

David