Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

"Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu> Tue, 17 September 2013 13:29 UTC

Return-Path: <prvs=29725b1cf4=uri@ll.mit.edu>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECFA11E8122 for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 06:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.99
X-Spam-Level:
X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbf3rgx1Qo1W for <tls@ietfa.amsl.com>; Tue, 17 Sep 2013 06:29:45 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0D79511E8221 for <tls@ietf.org>; Tue, 17 Sep 2013 06:29:44 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r8HDQ1O3000908; Tue, 17 Sep 2013 09:29:36 -0400
From: "Blumenthal, Uri - 0558 - MITLL" <uri@ll.mit.edu>
To: "'mrex@sap.com'" <mrex@sap.com>, "'yaronf.ietf@gmail.com'" <yaronf.ietf@gmail.com>
Date: Tue, 17 Sep 2013 09:29:28 -0400
Thread-Topic: [TLS] draft-sheffer-tls-bcp: DH recommendations
Thread-Index: Ac6zp+6qwObFjsMHQnSsSBdCp+ytugAAfoV1
In-Reply-To: <20130917131435.8AE601A974@ld9781.wdf.sap.corp>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
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.10.8794, 1.0.431, 0.0.0000 definitions=2013-09-17_05:2013-09-17, 2013-09-17, 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-1305240000 definitions=main-1309170048
Message-Id: <20130917132945.0D79511E8221@ietfa.amsl.com>
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 17 Sep 2013 13:29:50 -0000

 Sure I'd agree with ECC implementations being more vulnerable to side-channel attacks than say RSA.

Patent-wise, the ECC situation now reminds me that of pre-pre-2000 RSA, when IETF and especially implementers wouldn't touch it with a 10-foot pole. 

I wish NSA lawyers did a better job negotiating with Certicom. 

My personal $0.02. 
--
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: Martin Rex [mailto:mrex@sap.com]
Sent: Tuesday, September 17, 2013 09:14 AM
To: Yaron Sheffer <yaronf.ietf@gmail.com>;
Cc: tls@ietf.org <tls@ietf.org>;
Subject: Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

Yaron Sheffer wrote:
> So yes, I agree. Here's from our work-in-progress -01 version:
> 
> As currently specified and implemented, elliptic curve groups are 
> preferable over modular DH groups: they are easier and safer to use 
> within TLS.

Elliptic curve crypto is still fenced with non-expired patent claims,
requires an implementation of elliptic curve algorithms and the
relevant TLS extensions (something which is FAR from universally
available) and elliptic curve technology is considerably more
sensitive to side channel (=timing) attacks that DH, RSA & DSA.

-Martin
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls