Re: [TLS] Consensus Call on MTI Algorithms

Dave Garrett <davemgarrett@gmail.com> Wed, 01 April 2015 18:43 UTC

Return-Path: <davemgarrett@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 69AB91A1A14 for <tls@ietfa.amsl.com>; Wed, 1 Apr 2015 11:43:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 mMbueXYt8z0u for <tls@ietfa.amsl.com>; Wed, 1 Apr 2015 11:43:23 -0700 (PDT)
Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F39EA1A1AA8 for <tls@ietf.org>; Wed, 1 Apr 2015 11:43:22 -0700 (PDT)
Received: by qcrf4 with SMTP id f4so36519758qcr.0 for <tls@ietf.org>; Wed, 01 Apr 2015 11:43:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=NVG6aohHQIOrDiUQzKyoPcgU7oz7A38ptuC6djskGzg=; b=Va1IulANRQjPABnQfqpUMTh/gq4axzu8pftpSxcpOZtL4Iucm6QQxde4kLLaH3O3Ta MQsKbdtGG+NWUbw3FTRhs3eFBJpIKoZ805h9f9O8Qsln1Dp7GwZBURA0zIahh1jTiIc7 W9dpmtHRDH+iRBsA77mXauqTHT7eB09wXt/uHWm2lzKKQHA3bbY7RQeqnjCg4vAjkQrK 5umKetBKSUxTmsi4+t5pX8hIv/aUvexTQb1yt76JL49j480fZisUuDYPfzkr9Brr90mc NgaxwBcW5zOMiSsm2qkkhGrNiYZyzF5wFsupo5AdVQjYJ0O1ltHiV3B5wZVvIE95/8qh aQ8w==
X-Received: by 10.140.81.242 with SMTP id f105mr55693822qgd.33.1427913802316; Wed, 01 Apr 2015 11:43:22 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id q193sm1825540qha.14.2015.04.01.11.43.21 (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 01 Apr 2015 11:43:21 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org
Date: Wed, 01 Apr 2015 14:43:20 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-71-generic-pae; KDE/4.4.5; i686; ; )
References: <CAOgPGoBk+E=cNV1ufBaQ0n7=CJQ34zukPixKCEdpmMLBX=Kg_w@mail.gmail.com>
In-Reply-To: <CAOgPGoBk+E=cNV1ufBaQ0n7=CJQ34zukPixKCEdpmMLBX=Kg_w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201504011443.20607.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/5fSpoMW07HauHOWcI-QA5prwmBs>
Subject: Re: [TLS] Consensus Call on MTI Algorithms
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: Wed, 01 Apr 2015 18:43:24 -0000

On Wednesday, April 01, 2015 02:12:19 pm Joseph Salowey wrote:
> o Symmetric:
>         MUST AES-GCM 128
>         SHOULD ChaCha20-Poly1305

Some of us would rather have both be MTI in order to force the cipher ecosystem to not be entirely reliant on AES. (there was discussion prior on-list) I don't think a SHOULD is unacceptable, though.

> o Hash:
>         MUST SHA-256

Can we add an official MUST NOT for MD5? I assume this is generally wanted.

> o Key Agreement: ECDH
>         MUST P-256
>         SHOULD 25519

I think Curve25519 should be a MUST at this point. I think TLS 1.3 should have an MTI curve that can pass the safety guidelines on safecurves.cr.yp.to, as this topic does get brought up from time to time. (P256 probably should be MTI too) The entire point of the CFRG drama is to get better standardized curves to replace things, so I think it's reasonable to require support.

> o Signature:
>         MUST ECDSA P-256
>         MUST RSA

Any consideration for whatever CFRG wants to add here? (I don't have an opinion on the subject; just asking)

That said, the current proposal is straightforward and not unreasonable. However, I argue that adoption of relatively new standards with TLS 1.3 should not be considered optional.


Dave