Re: [TLS] [Cfrg] Citing specs in specs

Paul Lambert <paul@marvell.com> Fri, 14 March 2014 05:56 UTC

Return-Path: <paul@marvell.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5999A1A0043; Thu, 13 Mar 2014 22:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.567
X-Spam-Level:
X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev6znW8QVzaL; Thu, 13 Mar 2014 22:56:31 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB61A0040; Thu, 13 Mar 2014 22:56:30 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s2E5tqEk021400; Thu, 13 Mar 2014 22:56:13 -0700
Received: from sc-owa.marvell.com ([199.233.58.135]) by mx0b-0016f401.pphosted.com with ESMTP id 1jkm8rshvs-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 13 Mar 2014 22:56:13 -0700
Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA.marvell.com ([::1]) with mapi; Thu, 13 Mar 2014 22:56:12 -0700
From: Paul Lambert <paul@marvell.com>
To: David McGrew <mcgrew@cisco.com>, Watson Ladd <watsonbladd@gmail.com>
Date: Thu, 13 Mar 2014 22:56:08 -0700
Thread-Topic: [TLS] [Cfrg] Citing specs in specs
Thread-Index: Ac8/ShpmJ0NbR9RRTZ2b/aiqk1wNOg==
Message-ID: <CF47E638.3591A%paul@marvell.com>
References: <530FDC7A.4060404@cisco.com> <CABqy+srTqCXjOR4DMNgWyxf2pZ7dwZfWyznhBuJaY5w8VeuR4Q@mail.gmail.com> <5310B12E.4070603@cisco.com> <CABqy+srrbtdHOckjPqTj5SFuQwQEqXBjgc8kwagMi8E6ZRf=qg@mail.gmail.com> <28A7736F-A791-4552-8D42-DB99AC7B7F9B@vpnc.org> <CF37EA5F.338D8%paul@marvell.com> <CACsn0cmewBrOzaRF5XXC1p1A_gUSwkdE1_7V-1x8nta-ESyA+A@mail.gmail.com> <CF38F2D4.33940%paul@marvell.com> <2A0EFB9C05D0164E98F19BB0AF3708C711EF97AD05@USMBX1.msg.corp.akamai.com> <7BAC95F5A7E67643AAFB2C31BEE662D018B8516C6E@SC-VEXCH2.marvell.com> <7A2637AF-5A16-404B-B7A1-49FB17D5345A@callas.org> <CF3B846F.3415E%paul@marvell.com> <CACsn0cnyvkD1X5JDPJaoB83jZeFrj=uugMmWG9nPB+4jaC+POw@mail.gmail.com> <CF3BC8BA.34258%paul@marvell.com> <CACsn0c=OBvLfG+Sv1vYbhF9F6+mYSoYEji3SUtUzd7ZLP0fXHw@mail.gmail.com> <5317065E.1090007@cisco.com>
In-Reply-To: <5317065E.1090007@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.9.131030
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-14_03:2014-03-14, 2014-03-14, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1403130207
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/V2Vqu4cDUEWP9T6FbfoAgnj33vY
Cc: "cfrg@irtf.org" <cfrg@irtf.org>, Jon Callas <jon@callas.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] [Cfrg] Citing specs in specs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 05:56:32 -0000

On 3/5/14, 7:11 PM, "David McGrew" <mcgrew@cisco.com> wrote:

>On 03/04/2014 12:02 PM, Watson Ladd wrote:
>> Dear all,
>> This is provisionally my last word on the matter.
>>
>> Any consensus based process only works if people will block a largely
>> formed consensus for a good reason only. A document being unclear, or
>> having unanalyzed security properties, or major issues with regards to
>> alternatives not being discussed are good reasons. But the argument
>> that Paul I think is making, that until the CFRG produces a draft ala
>> RFC 6090 for Edwards curve we cannot use them, is fundamentally
>> unconvincing.
>>
>> First off, let me note that black box implementations of Curve25519
>> using the paper are possible: I've written them, Adam Langley has
>> written them, as have lots of other people. So that leaves the
>> argument that the implementations require too much knowledge about
>> cryptography, and that such an issue is worth blocking specs.

I was never advocating blocking these specifications.

The use of Edwards and Montgomery curves for Internet protocols are
relatively new.  There are gaps in the documentation of these new
mechanisms that should be filled at some point. I was trying to
constructively point to worked examples from twenty years of ECC
specifications.

Paul

>>
>> The simplest argument for why it is unconvincing is the date of RFC
>> 6090 vs. the dates of protocols that included Suite B and ECC. RFC
>> 4869 includes Suite B a full 4 years before RFC 6090 was published.
>> Now, it is possible that Paul's argument was valid, but simply wasn't
>> raised at the time RFC 4869 was being published. But I don't see any
>> evidence that implementors of RFC 4869 were hamstrung by the
>> nonexistence of RFC 6090.
>>
>> The second reason I am unconvinced is that I don't see why we
>> shouldn't assume the availability of standard references such as the
>> Handbook Of Elliptic and Hyperelliptic Curve Cryptography, or volume 2
>> of Knuth, to implementors. Such documents are available for far less
>> money than ISO standards, and in many regions of North America, Europe
>> and Asia, can be found for free in the library. The goal of a spec is
>> to explain to humans what is to be done: including excessive
>> information makes this much harder.
>>
>> Finally, Mr. Lambert writes in terms of the "onus" being on CFRG to
>> produce such a document, which he calls a "usable normative
>> reference". Such a bare assertion is entirely unconvincing.
>
> From our charter: "The CFRG serves as a bridge between theory and
>practice, bringing new cryptographic techniques to the Internet
>community and promoting an understanding of the use and applicability of
>these mechanisms via Informational RFCs".     We have an opportunity to
>promote the understanding, use, and applicability of newer ECC
>mechanisms, and I hope that we do so.   I woud not say we have the
>"onus" to do so, but if CFRG does anything in this area, it should do
>what its charter says.
>
>> Furthermore, CFRG owes Paul nothing. While I would be happy to review
>> such a document for accuracy, I have no obligation to review or
>> produce such a document, and the same holds for all the members of the
>> CFRG. I can just as easily say that Mr. Lambert has the onus to
>> produce such a document.
>>
>> I've changed my mind about the desirability of such a document as Mr.
>> Lambert wants. It would be nice if it existed, and it would be a nice
>> project to learn CWEB. However, I see no reason to consider the
>> absence of such a document a good reason to block
>> draft-josefsson-tls-curve25519-04.
>
>draft-josefsson-tls-curve25519-04 defines a way to use a variant of
>Curve25519 in TLS, by describing the differences between RFC4492
>(Weierstrass ECC in TLS) and Curve25519 processing, and some differences
>and clarifications relative to the Curve25519 processing described in
>the PKC2006 publication.   This is clear from the following quotes:
>
>"Private keys MUST be selected as specified in [Curve25519].  That is,
>private keys are 255-bits numbers with the following properties: ..."
>
>"ECPoint.point differs from the definition of public keys in
>[Curve25519] in two ways: ..."
>
>"Again, in line with [RFC4492] and as a departure from the convention
>chosen in [Curve25519], the x coordinate is converted to a byte  string
>using big endian order. ..."
>
>"The following subsections describe the differences between using
>Curve25519 and the curves defined by RFC 4492 for key exchange in TLS.
>... "
>
>Defining a new thing by its differences from two existing things is not
>the best way to get a clear and easy to implement specification.    The
>authors could improve clarity by brining in more of the description of
>Curve25519, or by referencing external work such as an informational
>draft/RFC that describes Curve25519 (preferably the same variant as in
>draft-josefsson-tls-curve25519).
>
>One way that RFC6090 added clarity was by clearly separating normative
>references from informative ones, and relying only on a small sufficient
>set of normative references that were early (pre-1994).   It would be
>good to have this sort of clarity for IETF work on Curve25519.
>
>It would be better to have a separate draft/RFC on Curve25519, as
>described above, because it will be clearer and more conducive to re-use
>of the mechanism across IETF protocols.   If no separate normative
>document is produced, then it will be important for
>draft-josefsson-tls-curve25519 to incorporated a more complete
>description of Curve25519.
>
>Disclaimer: I have not tried to implement
>draft-josefsson-tls-curve25519, and I'm not claiming that it is
>ambiguous.   The authors deserve thanks for writing this document. Our
>aim should be to produce clear, well-understood specifications.   Not
>all RFC are clear or well-understood, but we don't need to emulate that
>precedent.
>
>David
>
>
>
>>
>> Sincerely,
>> Watson Ladd
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>