Re: [Cfrg] A little room for AES-192 in TLS?

"Salz, Rich" <> Tue, 17 January 2017 14:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A1EBA129470 for <>; Tue, 17 Jan 2017 06:48:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.9
X-Spam-Status: No, score=-5.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FRr44LtAH5Zo for <>; Tue, 17 Jan 2017 06:48:04 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A6F9B12946E for <>; Tue, 17 Jan 2017 06:48:04 -0800 (PST)
Received: from (localhost.localdomain []) by postfix.imss70 (Postfix) with ESMTP id E44C920007A; Tue, 17 Jan 2017 14:48:03 +0000 (GMT)
Received: from ( []) by (Postfix) with ESMTP id CEA7C200080; Tue, 17 Jan 2017 14:48:03 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a1; t=1484664483; bh=Uha9anzgdKS3JwSO2Bb8buTgi8fkfEd+w+M5++nfNWI=; l=1659; h=From:To:Date:References:In-Reply-To:From; b=PSgkCJ84293j3vb9UNv61nvUXHuxlp+nMfy3+0y3sxSL69/oOG+QMrBVqjB3YLiEe Guv9aCY8tH8xftav1xxvY79SqBV8p+ZXzxjV4vcF5QQi3EK3gXqsyqPtc+ktZ4ir+E s4UwdMtS7us2NZU2QjTDDS7ncDHwbd3yVc3W13BQ=
Received: from ( []) by (Postfix) with ESMTP id B388798084; Tue, 17 Jan 2017 14:48:03 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 17 Jan 2017 09:48:03 -0500
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Tue, 17 Jan 2017 09:48:03 -0500
From: "Salz, Rich" <>
To: Leonard den Ottolander <>, "" <>
Thread-Topic: [Cfrg] A little room for AES-192 in TLS?
Thread-Index: AQHSb3JE35QdAtT7x0CRQruWUbnzSqE7gsUAgAAVHoCAAAfRAIAAE5+AgAAI+oCAABAygP//rfNwgAGQsoD//7Uu0A==
Date: Tue, 17 Jan 2017 14:48:02 +0000
Message-ID: <>
References: <> <1484577818.5104.1.camel@quad> <> <> <> <> <1484593651.5104.49.camel@quad> <> <1484662079.5135.49.camel@quad>
In-Reply-To: <1484662079.5135.49.camel@quad>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Cfrg] A little room for AES-192 in TLS?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Jan 2017 14:48:05 -0000

> Are you suggesting that because this research is 8 years old its findings are
> not valid?

Yes, kinda.  If the sky really was falling eight years ago, then where are the other papers?

> "The most disturbing aspect of the new attacks is that AES-256 can no longer
> be considered as a safe black box construction, which can be dropped into
> any security application with little thought about how it is used."

Well, luckily, that is not the case with TLS.  The particular attack about keys, as has been explained, isn't relevant to AES-in-TLS.  Your compromise, while not only outside the typical IETF scope, has been shown to fail as the other side will abort the connection.

> work best against AES-256 (which was supposed to be the strongest member
> of the AES family), and do not currently seem to work against AES-128."

Luckily we use AES128.

> And you cannot argue nobody wants to use it as it is not available for use. If I
> wanted to I could not use AES-192 except in private use scenario's as noone
> is offering such ciphers, i.e.


> I
> acknowledge adding ciphers is not a zero effort, but to describe it as complex
> is inaccurate.

We disagree.

You can write up an individual RFC that defines AES192 ciphers for use in TLS, and ask IANA to register them, and then "let the market decide."  I suggest you focus on a couple, and not try for full parity by defining a couple of dozen, as the registrar is likely to reject it.

Or you can keep posting here (and as previously pointed out, more appropriately the TLS list) and see if you can convince anyone.