Re: [TLS] On Curve25519 and other possibilities (e.g. ietf256p, ietf384p, ietf521p,

Michael StJohns <msj@nthpermutation.com> Mon, 30 June 2014 21:20 UTC

Return-Path: <msj@nthpermutation.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 EC0BE1A0ACF for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 14:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 YOOlLs1HwH1a for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 14:20:30 -0700 (PDT)
Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBAC31A0AA2 for <tls@ietf.org>; Mon, 30 Jun 2014 14:20:29 -0700 (PDT)
Received: by mail-qg0-f49.google.com with SMTP id f51so2514307qge.36 for <tls@ietf.org>; Mon, 30 Jun 2014 14:20:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RXg7Pl8uPpfKhj0h4Aqs2tLhEjsD1O4N+fFvC8zC/1U=; b=K4cSKDJtthQV24Ldnp/ath+hWerSlRShoIyOGJdFKWLp1CJ5lUkIj+l0Rzu3Gr2jyU cTklHf6ZNqjWDXGVPxaHYN3db3ObuQLlKnSdJZTcEOhtLRddJa3h/driUHkOuCD+Ottv 3D1oOenFvrG9IMDWNnV+tQ50wixkkgLCH4H+kVP75X1UO/To1fOck4t9RABrfvn03ZDP OR0H044p16q8Wb2l6w3e20FepzcI83gQ0ZAaX/CFhMUeRPN9NuKndPxA8PiQRayDnKbg rbfUF/qD9Zcgy9YX9+IoAaEmnZ8eIRwJbqGor9fryieSuJdVLJhedEXCJr3JUg3/0oZ0 otZA==
X-Gm-Message-State: ALoCoQmf4pU+gRNVobXhFnXtWbsfUV/W80d512eB2dyqVykduREh4MemG/lFAMyL8MB1s5E9EVxu
X-Received: by 10.140.31.119 with SMTP id e110mr61004898qge.74.1404163228917; Mon, 30 Jun 2014 14:20:28 -0700 (PDT)
Received: from ?IPv6:2601:a:2a00:390:b4d7:6f3f:f3ac:4c6? ([2601:a:2a00:390:b4d7:6f3f:f3ac:4c6]) by mx.google.com with ESMTPSA id b49sm2795935qgb.27.2014.06.30.14.20.28 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Jun 2014 14:20:28 -0700 (PDT)
Message-ID: <53B1D49D.10404@nthpermutation.com>
Date: Mon, 30 Jun 2014 17:20:29 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tls@ietf.org
References: <53B1B77C.2060201@cs.bris.ac.uk>
In-Reply-To: <53B1B77C.2060201@cs.bris.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DY6BS1WvPevgtMDFmNApz2zJP50
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: Mon, 30 Jun 2014 21:20:31 -0000

On 6/30/2014 3:16 PM, Nigel Smart wrote:
> What's the difference between defining a cryptographic protocol (i.e. 
> TLS 1.3)
> which could have lots of problems/be cracked/have a back door; and 
> defining
> a cryptographic algorithm which could have lots of problems/be 
> cracked/have
> a back door? Experience shows us that defining cryptographic protocols
> (key agreement/secure channels) is more prone to problems than defining
> cryptographic primtives (AES, ECC). 

If the math is insecure then the cryptographic standard is insecure as 
is everything that depends on it.

If the cryptographic standard is insecure then the cryptographic 
protocols are insecure (but hopefully you can plug in something else - 
e.g. DES vs AES).

If the cryptographic protocol is insecure then the applications are 
insecure (but hopefully you can plug in something else e.g.  TLS1.0 vs 
TLS1.1 vs TLS1.2 vs ??).

Oh yeah - if the implementation is insecure, it doesn't really matter 
whether or not you got everything else right.

So the difference is really about what depends on the protocol vs the 
standard vs the math, and you get more dependencies the closer you are 
to the math.

I tend to agree with you about the problems with defining crypto 
protocols, but at least they are*protocols* which is somewhat within the 
IETF's scope of expertise.  They're also a lot easier for the 
non-crypto-math people to get their heads around.  Crafting a 
cryptographic protocol is still a specialty expertise though.  At least 
TLS13 will have *lots* of eyes on it.  Given the huge set of plugin 
cryptography in TLS, hopefully at least some of it will be secure enough.

Mike