Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Fri, 27 June 2014 11:52 UTC
Return-Path: <prvs=125531a8e3=uri@ll.mit.edu>
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 CC1AC1B2B12 for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 04:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.85
X-Spam-Level:
X-Spam-Status: No, score=-4.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 iXuBTvnOb4fQ for <tls@ietfa.amsl.com>; Fri, 27 Jun 2014 04:52:46 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7371B3180 for <tls@ietf.org>; Fri, 27 Jun 2014 04:52:45 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s5RBqeqU000559; Fri, 27 Jun 2014 07:52:40 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'stephen.farrell@cs.tcd.ie'" <stephen.farrell@cs.tcd.ie>, "'ekr@rtfm.com'" <ekr@rtfm.com>, "'msj@nthpermutation.com'" <msj@nthpermutation.com>
Thread-Topic: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
Thread-Index: AQHPkf5MsZ81bnB1ZUS9pvv4HYn3bQ==
Date: Fri, 27 Jun 2014 11:52:40 +0000
Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC16B433@LLE2K10-MBX01.mitll.ad.local>
In-Reply-To: <53AD56D2.7060200@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [155.34.14.22]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.14, 0.0.0000 definitions=2014-06-27_03:2014-06-27,2014-06-27,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1406270123
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kjqhH5OGmfzNqH_NjrhSqk-XKdw
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,
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, 27 Jun 2014 11:52:49 -0000
All good points! I'd like to underscore that verifiably-random generated curves are likely to provide worse performance than, e.g., 25519 - but have a better chance of not bringing any cryptographic surprises later on. And in the (unlikely) case one of them does - the replacement path would be far simpler. -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: <uri@ll.mit.edu> Lexington, MA 02420-9185 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: <https://www.ll.mit.edu/labcertificateauthority.html> DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] Sent: Friday, June 27, 2014 07:34 AM To: Eric Rescorla <ekr@rtfm.com>; Michael StJohns <msj@nthpermutation.com> Cc: tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p, Hiya, On 26/06/14 23:10, Eric Rescorla wrote: > Also, this seems like a bigger topic than TLS. Perhaps the > AD should sponsor a discussion in SAAG? Yes, this is not TLS specific, though its probably not really possible to have no discussion of it here since TLS is likely the first large "customer" for 25519 in the IETF, if the WG choose to go that route. CFRG is definitely a better location for any detailed crypto discussion, i.e. for all algorithm internals. As noted before there was no indication from CFRG at the interim that 25519 is problematic. That's not quite as ringing an endorsement as has been represented here, but I figure cryptographers are going to be like lawyers for this - they'll never all agree an algorithm/curve is perfect;-) So its also possible CFRG might come up with more curves that they also like and that's fine. If someone wants more curves generated, CFRG is the place to chat about that and not here. But at that interim 25519 was definitely considered ok for use in IETF protocols - there was no dissent when I (more than once) directly asked that question and said that I wanted to hear dissent should there be any. The proximate cause for my question was allocating a codepoint for ed25519 for ssh, which has happened and the associated draft has completed IETF LC, also without any criticism of the use of 25519. I'm waiting for an updated I-D on that before putting it on an IESG telechat for approval, but my reading of the IETC LC was that there were no cryptographic issues raised at all. That IETF LC is also evidence that the IETF consider 25519 is ok. That said, when/if TLS decide to use it, I expect there'll be more interest in the IETF LC for that, so we'll see what happens then. For now anyway, my interpretation is that we don't have any cryptographic (nor declared IPR) reason to not use 25519 if a WG choose to want it. However, there is some more work to be done to document that so it can be used by WGs. I think that's being done by CFRG though, but if not, or if there are more generic bits that need discussion then saag seems like a fine list for that. If you think such a discussion on saag is needed then please ping me offlist to explain exactly what we need to discuss there (since I'm not clear about that). In the meanwhile most of this thread does seem to me to better belong on the CFRG list and is basically a distraction for TLS. Also, I have to say the language in Mike's original mail was, at best, unfortunate, e.g. "small but vocal minority agitating" is not likely to kick off a calm reasoned debate, and is definitely not going to help the TLS WG keep focused on its work so I really hope folks don't respond in kind, and if the chairs want to loudly stomp on threads with such language (regardless of source and mostly regardless of topic) they have my full backing. Cheers, S. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] On Curve25519 and other possibilities (e.g.… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] On Curve25519 and other possibilities (… Eric Rescorla
- Re: [TLS] On Curve25519 and other possibilities (… Hanno Böck
- Re: [TLS] On Curve25519 and other possibilities (… Martin Thomson
- Re: [TLS] On Curve25519 and other possibilities (… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] On Curve25519 and other possibilities (… Adam Langley
- Re: [TLS] On Curve25519 and other possibilities (… Viktor Dukhovni
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Salz, Rich
- Re: [TLS] On Curve25519 and other possibilities (… Peter Gutmann
- Re: [TLS] On Curve25519 and other possibilities (… Peter Gutmann
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Viktor Dukhovni
- Re: [TLS] On Curve25519 and other possibilities (… Alyssa Rowan
- [TLS] Hardware Implementations .. Re: On Curve255… Hannes Tschofenig
- Re: [TLS] Hardware Implementations .. Re: On Curv… Joachim Strömbergson
- Re: [TLS] On Curve25519 and other possibilities (… Paul Hoffman
- Re: [TLS] Hardware Implementations .. Re: On Curv… Hannes Tschofenig
- Re: [TLS] On Curve25519 and other possibilities (… Stephen Farrell
- Re: [TLS] On Curve25519 and other possibilities (… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] On Curve25519 and other possibilities (… Andrey Jivsov
- Re: [TLS] On Curve25519 and other possibilities (… Nigel Smart
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Alyssa Rowan
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Andrey Jivsov
- Re: [TLS] On Curve25519 and other possibilities (… Eric Rescorla
- Re: [TLS] On Curve25519 and other possibilities (… Andrey Jivsov
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Andrey Jivsov
- Re: [TLS] On Curve25519 and other possibilities (… Eric Rescorla
- Re: [TLS] On Curve25519 and other possibilities (… Salz, Rich
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Eric Rescorla
- Re: [TLS] On Curve25519 and other possibilities (… Dan Brown
- Re: [TLS] On Curve25519 and other possibilities (… Stephen Farrell
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Eric Rescorla
- Re: [TLS] Off-topic: RC4 Peter Yee
- [TLS] On counting Paul Hoffman
- Re: [TLS] On Curve25519 and other possibilities (… Salz, Rich
- Re: [TLS] On counting Adam Caudill
- [TLS] Off-topic: RC4 Paul Hoffman
- Re: [TLS] On Curve25519 and other possibilities (… Salz, Rich
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Salz, Rich
- Re: [TLS] On Curve25519 and other possibilities (… Nigel Smart
- Re: [TLS] On Curve25519 standardization Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Michael StJohns
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Fedor Brunner
- Re: [TLS] On Curve25519 and other possibilities (… Peter Gutmann
- Re: [TLS] On Curve25519 and other possibilities (… Johannes Merkle
- Re: [TLS] On Curve25519 and other possibilities (… Watson Ladd
- Re: [TLS] On Curve25519 and other possibilities (… Andrey Jivsov
- Re: [TLS] On Curve25519 and other possibilities (… Johannes Merkle
- Re: [TLS] On Curve25519 and other possibilities (… Alyssa Rowan
- Re: [TLS] On Curve25519 and other possibilities (… Johannes Merkle
- Re: [TLS] On Curve25519 and other possibilities (… Blumenthal, Uri - 0668 - MITLL