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

Watson Ladd <watsonbladd@gmail.com> Mon, 30 June 2014 22:21 UTC

Return-Path: <watsonbladd@gmail.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 A70611A0AF4 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 15:21:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-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 pGAWgvOlVjL4 for <tls@ietfa.amsl.com>; Mon, 30 Jun 2014 15:21:34 -0700 (PDT)
Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD961A0ADE for <tls@ietf.org>; Mon, 30 Jun 2014 15:21:33 -0700 (PDT)
Received: by mail-qc0-f169.google.com with SMTP id c9so7833837qcz.0 for <tls@ietf.org>; Mon, 30 Jun 2014 15:21:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jmgj9EQW+px68b0LLUpS6RokNuHotcBWp9p7Mie5Ygo=; b=vNZhzYiXfrG6sGcMaoauU5NANGp1VGRTzFZJkVLIBVFeTdj2bqPj1ZSCL0A8FBWdGs temrz80LocSnsE7EWd8sM+iqwxVuepiqfyOKYvUZVAd2IlmQVvl3sJp2wwwWvQMn/NTr 8ocIqCs+JAqRHvlhEWLEqk+YGY+aD9mjHfACJvKiu0YSXra/TEnwvZTWj7TE2eEgaPo8 9pDCZ1k0gKchxp2CvZlL3JZSzgoTJODjdfA022nb/oTFQINHHsFiY4Ed0o29fRMvwxjI gDQvYd/O5IrTV+rRxyxTfVFBZApcv/4+Bb1ZkC2bBW+Vn/zG97MGFmhj51TUH4OvHm7y /SRQ==
MIME-Version: 1.0
X-Received: by 10.140.47.48 with SMTP id l45mr24121308qga.24.1404166892952; Mon, 30 Jun 2014 15:21:32 -0700 (PDT)
Received: by 10.140.27.173 with HTTP; Mon, 30 Jun 2014 15:21:32 -0700 (PDT)
Received: by 10.140.27.173 with HTTP; Mon, 30 Jun 2014 15:21:32 -0700 (PDT)
In-Reply-To: <53B1D49D.10404@nthpermutation.com>
References: <53B1B77C.2060201@cs.bris.ac.uk> <53B1D49D.10404@nthpermutation.com>
Date: Mon, 30 Jun 2014 15:21:32 -0700
Message-ID: <CACsn0cmo8WXX8k=mUXZacbAp-5Ctq+gqFRMLzZykXH95JBShKw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a11c16606dc235704fd1514ed
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E60m5L30j_Ilyhi1IFqmlI7915Q
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 22:21:35 -0000

On Jun 30, 2014 2:20 PM, "Michael StJohns" <msj@nthpermutation.com> wrote:
>
> 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.

Not really: TLS 1.0 had an obvious flaw, BEAST. Kerberos went through 5
versions, each one broken before the next. However easily it looks to
understand,  you didn't find Triple Handshake. Did you really understand
TLS, or just think you did?

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.

Any improvement won't come from lots of eyes. It will come from a few
cryptographers sitting down and ripping stuff to shreds.

Plugin cryptography hasn't made it easy to kill RC4.
Sincerely,
Watson Ladd
>
> Mike
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls