Subject: [Cfrg] tentative agenda for CFRG at IETF 89

From: David McGrew <[email-masked]>
Date: Thu, 27 Feb 2014 19:46:50 -0500

Hi,

the tentative agenda for the CFRG meeting is below.  The plan is go over 
the status of all of the drafts, very briefly for those drafts that will 
be discussed later in the meeting.   Then we will have some 
presentations on a bunch of interesting topics.

Unfortunately, no one has volunteered (yet?) to give a presentation or 
lead a discussion on the new elliptic curve crypto mechanisms. So we 
will likely review the status, and then have a brief discussion.

The TLS WG has asked for the CFRG opinion on ChaCha+Poly1305.    We also 
should be offering an opinion on the new ECC mechanisms.   Some 
questions for you: should we take on draft-ladd-safecurves-03 as an RG 
draft?   Should we recommend its adoption in TLS?

Comments welcome; please copy the whole list.

thanks,

David and Kevin

--

CFRG @ IETF 89 Agenda

Agenda Bashing
Documents
    RFCs published
        OCB
    Review status of CFRG drafts:
        draft-irtf-cfrg-augpake-01, Augmented Password-Authenticated Key 
Exchange (AugPAKE), 2014-02-04
        draft-irtf-cfrg-dragonfly-03, Dragonfly Key Exchange, 2014-02-03
        draft-irtf-cfrg-zss-02, ZSS Short Signature Scheme for 
Supersingular and BN Curves, 2013-12-11
        draft-irtf-cfrg-zssbn-01, ZSS Short Signature Scheme for BN 
Curves, 2013-09-11
        draft-nir-cfrg-chacha20-poly1305-01, ChaCha20 and Poly1305 for 
IETF protocols, 2014-01-30
        draft-urien-cfrg-cose-00, Cloud of Secure Elements(CoSE), 2014-02-10
        draft-irtf-cfrg-cipher-catalog-01, Ciphers in Use in the 
Internet, 2012-10-22  (expired)
     Review status of other drafts of interest to the RG
        draft-ladd-safecurves-03, Additional Elliptic Curves for IETF 
protocols, 2014-01-15
        draft-mcgrew-aero-01, Authenticated Encryption with Replay 
prOtection (AERO), 2014-2-14

Password Authenticated Key Exchange
    Presentation on AugPAKE [email-masked] 
<mailto:[email-masked]>
    DragonFly quick status update

New Authenticated Encryption Mechanisms
        Presentation on ChaCha+Poly1305 - [email-masked]
        DISCUSSION: feedback on ChaCha+Poly1305 requested by TLS WG
        Presentation on Authenticated Encryption using Replay Protection 
(AERO)  draft-mcgrew-srtp-aero-01 [email-masked] <mailto:[email-masked]>

New Elliptic Curve Crypto
        Status of non-standard curves
        DISCUSSION: feedback on non-standard curves requested by TLS WG
        Deterministic RBGs - [email-masked]

Consideration of new topics
    Post-quantum crypto
    Key-centric architectures
    <other?>

---

From: Robert Ransom <[email-masked]>
Date: Thu, 27 Feb 2014 19:17:03 -0800

On 2/27/14, David McGrew <[email-masked]> wrote:

> draft?

I strongly oppose adoption of draft-ladd-safecurves-03 as an RG draft or an RFC:

* In draft-ladd-safecurves-00, the ‘author’ merely copied a pile of
curve equations into an I-D and tried to pass it off as his own useful
contribution.  draft-ladd-safecurves-03 still takes a fundamentally
wrong approach in specifying several specific curves, when what is
needed is a document describing how the whole class of Montgomery and
Edwards curves is currently used and can be used in future
applications.

* It repeatedly claims to specify a ‘standard’ for ECC on those
curves; however, the draft is ‘Informational’, and it specifies point
formats for Curve25519 which are deliberately incompatible with the
existing standard practices among implementations.  Thus, it is
attempting to specify a new ‘standard’ in a non-standards-track
Internet document, in clear defiance of IETF policy.

* It contains several factual inaccuracies.

* It takes a condescending tone toward implementors, while omitting
critical details needed to apply what little information it provides
to other Montgomery and Edwards curves.

* None of the text of the draft explains any aspect of the use of
Montgomery and Edwards curves or any background information in a
useful level of detail.  It is not useful even as a starting point for
an RFC on this topic.

* The author has repeatedly disregarded advice from other RG members
regarding this draft, usually with unnecessary hostility.  I have not
yet seen any reason to believe that he will change his behaviour.  If
he is chosen as the editor of an RG document at this time, I will not
waste my effort on attempting to contribute to it.

I have nearly finished writing a relatively elementary exposition of
the background in abstract algebra and (Weierstrass-form) elliptic
curves needed to properly explain Montgomery and Edwards curves and
their use in cryptography.  I intend to send it to the CFRG mailing
list either tonight or tomorrow for review.  After that, the portion
of a document describing Montgomery and Edwards curves themselves (as
currently used) should be relatively easy.

> Should we recommend its adoption in TLS?

draft-ladd-safecurves is not needed in order to adopt Curve25519 for use in TLS.

Dr. Bernstein's Curve25519 paper specifies the existing standard for
scalar multiplication on Curve25519 in sufficient detail to serve as a
normative reference for RFCs specifying its use in ECDH in IETF
protocols.  I believe that Curve25519 should be recommended for
adoption in TLS, and that a future version of
draft-josefsson-tls-curve25519 (which addresses the comments made on
the TLS list regarding the (current) -04 version) will be suitable for
publication as an RFC.

Robert Ransom

---

From: David McGrew <[email-masked]>
Date: Fri, 28 Feb 2014 10:54:22 -0500

Hi Robert,

> waste my effort on attempting to contribute to it.

That makes your position clear.

> currently used) should be relatively easy.

Thanks for the offer to contribute here.

> the TLS list regarding the (current) -04 version) will be suitable for

I am wary of relying on the curve25519 paper as a normative reference.   
Perhaps your goal here is to provide an informational document (the 
draft that you mention above) that offers implementation guidance, 
instead of a normative reference?

David

> .

---

From: Robert Ransom <[email-masked]>
Date: Fri, 28 Feb 2014 20:16:40 -0800

> Thanks for the offer to contribute here.

I've sent that document to the list now (attached to ‘Review of ECC topics’).

> instead of a normative reference?

RFC 4492 (ECC ciphersuites for TLS) cites ANSI X9.62, IEEE 1363, and a
few documents labeled as ‘standards’ by the corporations which
authored them as normative references.  It cannot be implemented
without the information in ANSI X9.62 and IEEE 1363.  ANSI X9.62 is
available from ANSI for 100 USD; IEEE 1363 is available from ANSI for
168 USD.

It is true that the author of the Curve25519 paper is neither a large
corporation nor an organization with “Standards” in its name, and did
not label Curve25519 as a ‘standard’ in the paper's title.  However,
the Curve25519 scalar multiplication function specified in the paper
became a ‘standard’, in the sense which IETF claims to use the word,
when software developers came to the rough consensus that it was a
good cryptographic primitive to use, and wrote and deployed running
code which implements it.  The Curve25519 paper is available for free
from the URL <http://cr.yp.to/ecdh/curve25519-20060209.pdf>.

What is your objection to using the Curve25519 paper as a normative
reference for the standard Curve25519 scalar multiplication function?

Robert Ransom