Re: [TLS] Confirming Consensus on supporting only AEAD ciphers

Fedor Brunner <fedor.brunner@azet.sk> Tue, 06 May 2014 09:24 UTC

Return-Path: <fedor.brunner@azet.sk>
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 14A931A0780 for <tls@ietfa.amsl.com>; Tue, 6 May 2014 02:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.746
X-Spam-Level:
X-Spam-Status: No, score=-0.746 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, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=no
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 YeiLrf5FKIyX for <tls@ietfa.amsl.com>; Tue, 6 May 2014 02:24:30 -0700 (PDT)
Received: from smtp-01-out.s.azet.sk (smtp-06-out.s.azet.sk [91.235.53.31]) by ietfa.amsl.com (Postfix) with ESMTP id A5E751A0299 for <tls@ietf.org>; Tue, 6 May 2014 02:24:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=azet.sk; s=azet; t=1399368264; bh=srZiI/5H3BaRGyAhhm50B/wHmAWeAg8+KbAP2zXlTOA=; h=Date:From:To:Subject:References:In-Reply-To:From; b=aHskz2rVvZ04+HUOs+hp1rLb+xjbPIcXdEt+tuIeaAfX5KBsup6uKmu3EpXpfZc/V YRpQsnPsIBSlOtb4CRVsKSCBPxH4PJxcDE3XVFdYkhYhJXJAv0mmtLwNUAlWCOgOTY 9hDI+/vDioLkqo/xRanP4BDLGN2/rn3kAUZs6dbQ=
X-Virus-Scanned: by AntiSpam at azet.sk
Received: from [0.0.0.0] (tor.pm-ib.de [83.133.106.73]) (Authenticated sender: fedor.brunner@azet.sk) by smtp.azet.sk (Postfix) with ESMTPA id 8FD667D for <tls@ietf.org>; Tue, 6 May 2014 11:24:18 +0200 (CEST)
X-SenderID: Sendmail Sender-ID Filter v1.0.0 smtp.azet.sk 8FD667D
Authentication-Results: smtp.azet.sk; sender-id=fail (NotPermitted) header.from=fedor.brunner@azet.sk; auth=pass (PLAIN); spf=fail (NotPermitted) smtp.mfrom=fedor.brunner@azet.sk
Message-ID: <5368AA3A.8010206@azet.sk>
Date: Tue, 06 May 2014 11:24:10 +0200
From: Fedor Brunner <fedor.brunner@azet.sk>
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C738AC0A34B@uxcn10-tdc06.UoA.auckland.ac.nz> <CAK6vND9oFo8ieRmmESHXBHGjdsk2QUnJZYUWqVAY03Wgz=jfNw@mail.gmail.com> <535FD8AE.6050007@pobox.com> <CABkgnnW=5wpnifnPC_UJOPN_guwmqymxNYQLbiBMsGSDfL2Ogw@mail.gmail.com> <535FE275.6090701@pobox.com>
In-Reply-To: <535FE275.6090701@pobox.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zMoQ3S35_DKvfKs7LUAeLsa0L54
Subject: Re: [TLS] Confirming Consensus on supporting only AEAD ciphers
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: Tue, 06 May 2014 09:24:32 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


On 29.04.2014 19:33, Michael D'Errico wrote:
> Martin Thomson wrote:
>>> I suggest [not naming a mandatory-to-implement cipher suite in the
>>> TLS 1.3 spec.].  There are too many [cipher suites] to choose from
>>> and nobody will listen anyway.
>>
>> That's a recipe for interoperability failure.
>
> I'm suggesting that the TLS 1.3 spec. is not the place for this piece
> of information since it is a moving target:
>
>     TLS 1.0 required TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
>     TLS 1.1 required TLS_RSA_WITH_3DES_EDE_CBC_SHA.
>     TLS 1.2 required TLS_RSA_WITH_AES_128_CBC_SHA
>
> Current consensus says none of those previously-mandatory ciphers will
> even be compatible with TLS 1.3.
>
> A Best Current Practice document like draft-sheffer-tls-bcp-02 that
> tracks best practices is more useful than having the TLS spec. become
> obsolete soon after it's published.  BTW that draft suggests these
> cipher suites:
>
>     TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
>     TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
>     TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
>     TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

There are good reasons why not to use AES-GCM in software implementation
of TLS

https://www.imperialviolet.org/2012/10/21/nist.html
https://www.imperialviolet.org/2013/10/07/chacha20.html

Chacha20+Poly1305 is more efficient on CPUs without special instructions
to implement AES and GCM. Also secure implementation which doesn't leaks
timing information on such CPUs is easier.

Fedor

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJTaKo6XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4QkVFQ0NBRDcyNzU1RTk2RTQwMzlEQjc2
RTE3NDA5NTQwNTY2M0FEAAoJEG4XQJVAVmOt47sQAJN2v9TIpA+1eEcJoK0yIEem
cKhPpZaYwKhKnthk4RYnV/hBFn6/Ij59p14Als+e5ZdMLB6uiqwurgEoRi7OKZRK
QFKyhrqOrjqX2UrhKbPY6wPJ+WY+Qq8PA8OA0KAp3etSTgcopaCTBEUSUkaMiqiG
RJ8MzrzyQQALPP+/gODaBIa0MF8y2jOdqAqn7IUaKM9auYeSwEaRzMfhKFITvrkC
a/YZnEB1KkqezKvxocAUw3ttV2kAiFJyGPHPA3GB0nUamw3CUspFIBIuZ9sjv1OW
ih90AfsobMdm1lZrZwn1WHdValUKYy3VRg2NEH+AgLfhaMbnOgBlCBR3c1edxhAX
Dl6o8VmAI0HAOYKWhLxC9NkpPPbOqXJk8r29R+Ch89fdXHXmRMJ9StK5LKP+gKCx
qvVIK3Dp3ITxB5jULX6O1mrI6oGKRpirwlD3ixNujJ+wmc4AmJ3ALiniWOPv6b3T
wn/4jikp2IkUnddVyMZOaYSjpflhcnO/WOA0p0nmtprIyD61FQ5w6MMPoEkcXOfz
ngMxYS9Pr0+OwbaAhkaJpbXLre3Txc/JcW1Bi/z7o/MCWqApkAW5xhQrKUcDRzNb
ToJ5CX9beSvQHr90H7o/JbNsivJEim9vLLWO7yOiC1Gv/LYHhoElc7fk4o/t1kWG
WFxsQZshTrSIZArecUVb
=avO6
-----END PGP SIGNATURE-----